Hi. I'm after some getting started advice for work...
# azure
m
Hi. I'm after some getting started advice for working with Pulumi and Azure using C#. I am looking to roll out an Application Gateway that, over time, will have new rules (pools, listeners, routing rules etc) added to it. Rolling out the initial deploy seems straight forward enough but I am unsure how to manage the rules etc that get added to it over time. For example if tomorrow I roll out WebApp1 I will need to add some rules to the App Gateway to allow that to be published. If I later roll out WebApp2, it will need its own set of rules adding to the App Gateway. It would seem to make sense that these WebApp specific rules are handled by the Pulumi program/stack that is deploying each WebApp rather than the original project/stack that deployed the Application Gateway. How do I achieve this i.e. have one deployment that creates the Application Gateway and other projects that can add rules to it without destroying any existing rules. Ideally I would also like to be able to redeploy the original Application Gateway project itself without having it overwrite/erase any rules added by the WebApp projects.
t
I believe an Application Gateway is currently a single resource, including all the rules, so you can’t spread it over multiple stacks
m
Thanks @tall-librarian-49374 😞
@tall-librarian-49374 just a quick follow-up on this, if I use an ARM template to incrementally push out additional rules is there any way to stop the Pulumi project I have made for creating the App Gateway itself from erasing these when it deploys? I guess I'm asking if there is the concept of an incremental deploy within Pulumi (when not doing an ARM template deploy)?
t
If a resource is managed by Pulumi, it is considered fully managed. Unfortunately, I don’t have experience with managing App Gateways, so I can’t really advise from own experience.
m
thanks again
a
Just as an aside since I'm doing something similar with k8s, I don't "really" care what happens to the underlying cluster as long as the IP addresses don't change. Can you create a public IP address that is durable and created in a separate stack, and then create/re-create your AAG using that public IP any time you need, with all of the rules (old and new)?
I do have two stacks. One for standing up the actual k8s cluster, and one for all of the resources that I put into the cluster. The resources stack references the k8s stack so that it can get the .kube/config file for the k8s provider.
m
Thanks for the suggestion Dave. I'm not sure how I would keep track of all the rules though? If I have once stack to run up the basic AAG with the public IP and then another bunch of stacks that all want to publish themselves behind it how would I collate that set of results? Would I have to do a Get on the AAG first to read in any existing rules and build up from that?
a
No.. I was thinking on stack for the public IP and anything else, and then one stack that you just use over and over to update the AAG with all of the needed rules.
Two stacks.. potentially just replacing the AAG every time with a new one, but keeping the public IP in place for every iteration of the AAG
Just to be clear. I haven't looked at how to create an AAG (with pulumi) yet.. but I will be looking into it.. I'm currently using an Nginx Ingress Controller in our k8s cluster, but the original plan was to use an AAG Ingress Controller, which would create and manage the rules for the k8s cluster as resources are added to it.