Great video - I'm trying to do this with Flux but I'm not sure how I'd get Flux to see my override values file. I definitely can't push it to the Github repo so is there a workaround for that?
I’d you are asking about using flux to install the chart, generally you want to keep your overrides in the CD tool or in a configuration storage of some sort. You can keep them in a storage bucket or you could keep them in a separate repo in GitHub and encrypt the file if it contains secrets.
@@LearnFastMakeThings yep, Flux would be installing my charts. I've got it working up to the point where I need to provide variables and secrets to a Helm chart. I'm looking at Sealed Secrets to see if that works for me. I'd appreciate any guidance you can offer. Do you perhaps have videos that go over my original scenario?
I don’t, but that’s a pretty good idea. There are a number of tools out there that make it easier to do container native dev work. Where I work my team built a tool for Kubernetes native dev workflows. It allows you to swap any running container for a dev container and keeps all your changes in the cluster. Devs don’t even need powerful machines or an IDE for coding. Thanks for the idea! I’ll need to compare a few and formulate some opinions.
@@jwisit its possible but i doubt it. my personal feelings about open source software and my work's view are unfortunately not the same. plus, its pretty implementation specific and would need some work to make it more generic
so you explined the secret part very well, but what should we do with the rest of the env variables that we might need, stuff like db name or even http port, shouild we just hard code them in the values.yaml? or treat them the same as the secrets?
Ultimately the best place for non secret config would be in a Kubernetes configmap object. It can be env variables or a config file if you choose, but yes when using helm those would go in your copy of the values.yaml file.
Just went back and watched the video again. It’s going to be the same exact pattern as the secrets, but instead of a secrets object you will create a configmap template. Set the sane defaults in values.yaml and then your override values in the “myvalues.yaml” file. Hope that helps.
This is gold! I love the way you explain concepts and also teach the industry best practices. Keep up your good work 👏
I appreciate that! Thank you so much!
My brain hurts so much after watcing these, but they are sooo gooooood.
Excellent series of videos, cheers for doing this...
Thanks man this is great!.
Glad you like it!
Super helpful! thanks dude
Glad it helped!
What was that terminal software monitoring the cluster?
It’s called K9S. K9scli.io
Great video - I'm trying to do this with Flux but I'm not sure how I'd get Flux to see my override values file. I definitely can't push it to the Github repo so is there a workaround for that?
I’d you are asking about using flux to install the chart, generally you want to keep your overrides in the CD tool or in a configuration storage of some sort. You can keep them in a storage bucket or you could keep them in a separate repo in GitHub and encrypt the file if it contains secrets.
@@LearnFastMakeThings yep, Flux would be installing my charts. I've got it working up to the point where I need to provide variables and secrets to a Helm chart. I'm looking at Sealed Secrets to see if that works for me. I'd appreciate any guidance you can offer. Do you perhaps have videos that go over my original scenario?
Do have a video on how to use something like "devspace dev" to develop locally on running kube's?
I don’t, but that’s a pretty good idea. There are a number of tools out there that make it easier to do container native dev work. Where I work my team built a tool for Kubernetes native dev workflows. It allows you to swap any running container for a dev container and keeps all your changes in the cluster. Devs don’t even need powerful machines or an IDE for coding. Thanks for the idea! I’ll need to compare a few and formulate some opinions.
@@LearnFastMakeThings Any chance your team's tool will be open sourced? :)
@@jwisit its possible but i doubt it. my personal feelings about open source software and my work's view are unfortunately not the same. plus, its pretty implementation specific and would need some work to make it more generic
so you explined the secret part very well, but what should we do with the rest of the env variables that we might need, stuff like db name or even http port, shouild we just hard code them in the values.yaml? or treat them the same as the secrets?
Ultimately the best place for non secret config would be in a Kubernetes configmap object. It can be env variables or a config file if you choose, but yes when using helm those would go in your copy of the values.yaml file.
Just went back and watched the video again. It’s going to be the same exact pattern as the secrets, but instead of a secrets object you will create a configmap template. Set the sane defaults in values.yaml and then your override values in the “myvalues.yaml” file. Hope that helps.
@@LearnFastMakeThings it does thank!
what if i need to set the ingress host as an ip?
Ingress objects do not require a host name. If you omit the host, any traffic to the IP of the loadbalancer will be evaluated by the ingress.