Hi, i am new to pulumi and have a question regardi...
# general
c
Hi, i am new to pulumi and have a question regarding nginx-ingress deployment incl. load balancer (i am trying on digitalocean, if this is of interest). Reading through the docs, using yaml or helm should only be used for experimenting or migrating to pulumi. I am not sure, if I should translate the ingress resources to pulumi code in order to deploy the ingress controller and load balancer? Is this feasible or should I stick to the helm chart/yaml manifest? If so, how would I retrieve the load balancers ip if deployed through a pulumi kubernetes.yaml.ConfigFile?
c
There’s no need to port helm charts to pulumi code. There’s a pulumi subprovider in the kubernets provider. https://www.pulumi.com/blog/using-helm-and-pulumi-to-define-cloud-native-infrastructure-as-code/
I would highly recommend sticking to well known helm charts over porting it yourself.
b
i'd use the yaml.configfile over helm
c
Thank you very much for your replies, this helped me a lot. I was irritated by the note on github https://github.com/pulumi/pulumi-kubernetes#deploying-a-helm-chart, stating it would be primarly for experimentation and transitioning. I also found a sample meanwhile that shows how to retrieve properties from resources created with helm or yaml using getResourceProperty() function. Thanks again for your help!
c
Largely agree with @cool-egg-852—lots of customers do precisely this. I do think it depends somewhat on what you’re doing. A common pattern in the helm ecosystem is, when a chart (usually not one of the top 5) doesn’t do exactly what you need, you end up forking it. In those cases it may or may not make sense to do a transition.
Top 5 charts are probably safe to use off the shelf—overall I’d say it really just depends what you need to do.
that said, we should consider changing our messaging here. Plenty of people are successful on helm with pulumi.
w
Being able to use helm charts is an essential interop boundary
c
Thanks for further clarification. I will keep in mind to critically reflect on "just" using a helm chart depending on my requirements. For the ingress-controller and cert-manager I'm going to start with the helm charts right now.
b
i switched from helm to the manifest files for nginx ingress and cert-manager because i got a lot of issues with upgrades
c
Oops. Can you elaborate a little which issues you've seen and why that was better when using the manifest files?
b
i think the cert-manager guys have swapped from being helm-first to manifest-first in terms of their recommendations
but upgrading from 0.6 to 0.8 (iirc) was basically a matter of manually removing a load of stuff with kubectl to get it to go through
because of CRD conflicts etc
plus helm involves installing tiller, adding a custom repo and the manifest files Just Worked
i did have a configfile transformation to change the namespace but i ended up dropping that too
c
ah, ok. I'll have a look into their docs again. I'll defineteyl try the manifest files after the helm deployment is running. Thanks for sharing your experience.
c
If you use helm with pulumi you should not install tiller. It won’t be used anyways.
Pulumi only uses helm as a template engine. Then parses the resulting manifest files.
This is why I highly suggest that you stick with helm for pulumi for anything third party that offers a chart. It’ll be much simpler for upgrades, and most documentation out there is built around helm templates. Instead of worrying about doing transformations and such to configure the app, you just have to provide helm config values. Much simpler.
c
Ok, I have the helm part already working. I'll nevertheless try it with manifest files as well, just to learn some more options I have with pulumi. There is still one thing I can't figure out from the docs and examples. If I e.g. deploy an ingress-nginx with helm, how would I retrieve the external ip of the load balancer so I can make it a Output in my pulumi stack?
Once more, thank you all for being so welcoming and helpful 🙂
c
That’s the tricky part unfortunately. However, we personally never rely upon IPs outside of the stack. We always use DNS entries. This makes it easier for us as applications don’t need to be updated if the IP changes.
c
As I read your words, I realize that this is exactly what I want to achieve, creating an A entry for this ip. I just wanted it to output (or maybe better log it) somehow. I found a code snippet that hopefully helps me getting the ip, since I will need it anyways - either for logging it or using it to create a DNS entry. Is there any documentation around on how to read such values from a yaml.ConfigFile or a helm.v2.Chart?
b
you can parse the Resource[] that it returns
but at least on azure aks we just create a static ip, give the cluster permissions to use it and then when the ingress resources result in a loadbalancer being created it selects that one
so we just base our dns off the IP that we created ourselves in pulumi - we never need to tie it directly to the ingress
g
It sounds like
getResourceProperty
may be what you’re asking about. See https://github.com/pulumi/examples/blob/master/kubernetes-ts-helm-wordpress/index.ts#L21 for an example
c
@better-rainbow-14549 Thanks for your thoughts on that. I'll remember this for the next Azure based project. This one is on digital ocean and they don't yet support assigning static ip to load balancer, so I have to go the other route.
@gorgeous-egg-16927 Thanks for the hint, I found that sample yesterday and took the snippet you marked. That worked as expected 🙂 From there I also understood where to find the respective objects in the docs. Thanks to all again for bringing me on track on this topic!