Helmfile - How to manage Kubernetes Helm releases

helm is awesome i mean i will skip the discussion whether home is better or worse than customized but for the moment let's assume that you are using helm and i'm assuming that you're using kubernetes i mean if you're not using kubernetes then go back to 19th century right anyways you're using helm that's my assumption and if you are then you're probably experiencing pain of how to release your applications package the scam charts at scale [Applause] when you have one or two applications or three and then you maybe have two environments working with home is relatively straightforward and easy you create a help chart you modify values depending on the environment where you're running you're updating those values every time you make a new release and it's all good it's amazing but what happens when you have more applications let's say 10 100 applications and on top of that we need to multiply it with the number of environments we might have staging integration production this and that a few environments three four five six maybe ten and then multiply with the number of applications and the situation gets complicated because helm is not designed to manage our applications at scale instead it is designed to package a single application with its dependencies and create some variations of that application depending on the environment we are running in now we can create chart of charts did they just invented that term i'm not sure whether anybody calls it chart of charts anyways you can create a chart that will contain all the applications running in an environment as dependencies of that chart but then the situation becomes hard to maintain let's say or not really user friendly or not really what helm is supposed to be about so we are using helm and we have trouble how to create releases of our helm applications and how to do that at scale and that is where helm file jumps in help file tries to solve problems of running at scale applications packaged as helm charts so what is hum file if i go to the website i will see highlights of couple of points and they are let me read it a way to keep a directory of tracked value files and maintain changes in version control apply csd to configuration changes and periodically think to avoid school skew i'm not sure what's the word in environments anyway drifting environments that is somehow true but i think that it's missing the point the real advantage of help file at least from my perspective is the ability to define whole environment let's say production in one place as different helm charts with different values and different tags and images and properties and what's not right it is a way to define what is running in an environment and have a relatively straightforward how to update that definition with each new release we are creating so it is a mechanism to define releases and to run helm charts at scale it is like okay here is the definition it is helm on steroids that's what it is really so let's explore helm file in 20 minutes or less and see whether it makes sense for us to use it here's tl dr it does make sense to use it if you're not using some other tools ah that's confusing let's go to the live session hands-on and see what is it all about let's talk about setup what did i do in advance before i started recording this session not much actually a few things i cloned the repository that contains sample manifests i created the cluster you can use any kubernetes cluster but today i'm using k3d which if you're not familiar with i explored in one of the previous videos and the link to the video is up there above my head somewhere it's also in the gist now that i mentioned the gist there is a gist it's in the description of this video so go there check it out you will find all the commands that you will need if you want to follow along what i'm doing i installed helm i'm assuming that if you're watching this video you already have helm probably you wouldn't be interested how to run helmet scale if you don't have helm right i installed helm file and i installed a couple of helm plugins helm file depends on some home plugins it is sometimes painful to figure out which plugins are needed but hey documentation can always be improved now let's go and explore hemp file and see what do we get with it what is that thingy i will start with the simple definition the potentially the simplest possible hand file maybe not the simplest but very simple one and then we're going to progress towards more complex use cases so here it is helpful prometheus right let's say that we want to run prometheus in our cluster and we would like to define it using help file and this is the definition so over here we have repositories and releases and even though this looks extremely simple and it is it already shows a couple of pain points of hell right we need to manage repositories manually you know helm repo ad hem repo update instead of specifying those repositories somewhere and help file helps us with that instead of thinking oh what is the repository that contains the chart i want to install we can just specify it in a file and say hey prometheus is in this address it's similar with releases we cannot specify the namespace at least not easily in helm we need to specify dash namespace in create namespace help file will do that for us it allows us to specify the namespace the chart that should be deployed and the name that is whichever name you want right and this chart here prometeuse is actually a reference to the repository prompt use that we specified here if you're familiar with helm and i hope you are this saves you from executing a couple of commands like him repo ad specifying couple of arguments everything is defined in a file and that part is awesome and bear in mind this is simple example you will see how this gets more and more useful as we scale up if you would like to apply those releases i mean there is only one but there could be more specified in a file we would do something like um file and then we specify the path to the config file which is hempfile prometheus.yaml now if you name your config file hempfile.yaml then you don't need to specify the path otherwise you do and this is one of the things that annoy me with help file if we use global arguments and dot dash file is one of the global arguments we need to specify all those global arguments before we hit apply or any actionable or any command actually really so global arguments need to go before the command itself which is pretty annoying at least to me maybe i'm too picky anyways uh we want to apply that and we want to wait so let's hit it let's see what we'll get you see it is adding the repository prometheus ah it missed it added the repositories and there is only one but all the repositories specified to helm repo local repo list and now it is showing us the diff what will happen if we apply this and it's a long list of the resources that will be created for us simply because this is the first time we are executing this otherwise it shows the diff so later on when we start upgrading things this will be extremely useful because it will show us the difference it would be very similar to terraform plan and as a matter of fact him file apply command is a combination of hum file diff and helm file sync right so those two commands combined are actually the same as hum file apply and right now it just finished right it deployed whatever is defined in the helm file that we are using and in this case that's only primitives now let's say that we want to update our prometeus installation let's let's say if we want to remove our back from prometheus i mean you would never do that in real life but for the sake of argument let's say that we want to remove our back support for prometheus that is currently running and we could have uh we could update our home file but in this case i have another one a new one uh to save you from updating files and that this is the one right and the difference between what we had before and what we have now is that i set a couple of arguments i'm setting arabic create to false so basically removing our back from this setup no matter how silly it sounds but i wanted to show you two things here first that we can set additional values through set or values instructions in the releases right so we can customize and say hey those are the values specific for this environment those are the values specific for that and set here is equivalent to set i mean helm installed our set or hem upgrade or set command we could use values as well now let's see what we would get if we run this and the command will be slightly different because i want to introduce you to a few additional options and one additional argument is interactive right so we want to make this interactive you will see what that means we want to apply a new file which is help file prompt use our back yaml and we want to apply just as before and wait until it is finished pay attention the time specifying here now dash interactive it will do some magic you will like it so it is adding the repository just as before and now it calculated the differences so if we apply this this is what would happen right some resources in this specific case would be removed at least those resources related to armback right so we can see what will happen before it happens what will be applied or removed or destroyed or updated in our cluster and then we can make uh intelligent decision and say hey do i want to do this or not in this case let's say that we want to do this and we would type ey and then we proceed and help file will apply the differences i mean helm will apply the differences but help file allows us to inspect those differences one of my favorite use cases for this are pull request we could execute help file diff which would show us the same differences without applying without asking us anything we would get additional information that would allow us to decide whether to merge pull requests or not to the main branch and then hopefully do the ci cd pipeline or whatever we're doing to bring it all the way to production so this provides this diff or interactive mode depending on which command you're running allows us to see what will happen before it happens it is almost the same as terraform plan right and that is extremely useful it allows us to make educated decision whether we should move forward or not or whether we should merge a pull request or whatever the place is where you use this now let's just let's see how we can destroy stuff and the command is held file and we want to be interactive as well let's say we want to be asked whether we want to do that or not and the file is chem file from it use our back and we want to destroy stuff destroy since this is interactive nothing got destroyed yet the system is asking us whether we want to do that and we are getting information hey these are the releases that will be affected by destruction that will be destroyed do you want to proceed yes or no and i will say yes and then it will destroy all the resources created from the releases specified in that helper now let's expand our horizons and see how we could maybe define multiple releases altogether let's say maybe define a whole environment and everything running there one example file could be this one helm file multi yaml right and this one is slightly bigger slightly more complicated but still not a big deal the first entry in the releases is the same as before this is prometheus repository and release and then we have two additional applications in this imaginary environment we have devops toolkit and devops paradox now devos toolkit is using a local chart unlike prometheus and the same thing is with devops paradox both of them will be running in the production namespace and then we have couple of values that we want to overwrite for production specifically this will be the target that we want to use and this will be the ingress host devops toolkit something and this is yet another advantage of help file we can use environment variables so in this specific case the the ingress cost of device toolkit is devops toolkit dot and then the value of environment variable base host and this variable is required so we will get an error if you don't specify it further on we have english host for the devops paradox yet another application and this one is a slightly different syntax it says hey use environment variable devops paradox host but if that variable is not available if nobody specified it the default value will be [Music] devopsparadox.acme.com so we have default value and then we can overwrite that value with an environment variable now let's see what happens if we want to apply this so then file and then dash dash file file multi and we want to apply and we want to wait just as before and we get an error because if you paid attention you saw that the base host environment variable is required it is required env that means that we cannot apply this without specifying that environment variable so i'm going to export it as space host and let's see local post in my case because i'm running k3d in your case the base host can be should be something else if you're not running a local cluster anyway specify whatever makes sense for your cluster and then we if we execute the similar command let's say film file dashboard file file multi and let's make it interactive why not and apply weight and we will get first the diff what will happen if we execute it it takes a bit of time until it calculates everything and this is all the information of all the resources will be created updated or deleted i'm going to skip to that now and just say yes why and then it will take take a few moments until all those charts all those releases are applied so this is already a hint of how that works when running at scale right i have only three releases but you could have ten hundred thousand you could manage call production from one single place okay it took uh maybe half a minute i mean this depends on how really but anyways now it's finished we have here the summary of what happened because three releases three releases were updated those paradox toolkit promises those are the charts those are the versions and we can live happily ever after now to confirm that our environment variables were really working correctly i'm going to do cube cattle tart dash name spaces namespace actually production and then get ingresses right and you can see here that the value of the english host of devos toolkit is now devil's toolkit because that was hard coded and localhost was taken from the environment variable that i specified earlier on the other hand uh the devil's paradox host is that is using the default value since we did not specify the environment variable and there was in the config file the default value it is using that default value just to be on a safe side let me open this in a browser and confirm that it really works let's see localhost uh there was toolkit.localhost and here's my application it is running it is one of the three releases that were deployed through this config file we got permit use application one application two and we could have thousand if you want to let's take another look at the same file that we used before campfire dash multi we can see that there is room for improvement here for example namespace production is repeated for both of those right that's really repetition of the same thing over and over again and we can see that the chart in both cases is the same as the name of the release so we can reduce repetition probably hopefully somehow by creating some form of default values so let's see how we can do that how we can reduce repetition i will i will do that with only those two values namespace and chart but potentially we can do that for many many other things this is the reviewed cam file that has less repetition or maybe not less repetition because this is a very small sample but you need to imagine how this would help with the bigger sample and we have a new instruction here that says templates hey there is a template uh it will be the default template it will be called default and it will have name spaces to production and the chart set to whatever is the name of the release right so remember those two you will see soon why that matters and missing file handler born doesn't matter we will skip it for now now if you go back to the definition of uh the two releases that the toolkit and paradox we can see this new thing this is horrible syntax i hate it but anyways what this means is inject the template called default so whatever is defined in that default template over here will be injected into those releases in this case namespace and chart so we can avoid repetition by creating templates and then injecting them into releases which saves us from repeating ourselves over and over again there is one more difference here i'm introducing a new tag so this definition compared to the previous one uses templates which should produce exactly the same results and then we are updating the tag i want to show you two things at the same time right so templating should not produce any difference because it's using the same value the default template and we should only experience the upgrade of the tag so let's see whether that's really true him file and then we want to make it interactive to see what's going to happen and apply and wait now it takes a few moments until it collects all the information let's see let's see and there we are first of all we can see that only the image tag is changing right so before it was 2 9 10 now it's 2 9 18. so we can see what will change if we apply this uh definition this new definition and we can also see that templating did not produce any differences it just saved us from writing uh repeated lines of yaml so we'll say yes and then it will take a few moments until the application device toolkit in this case is upgraded we could do many many other things we can for example define environments in help file as well and then define different values depending on the environment but that should that something should be running so we could have a staging environment production environment integration environment and then which releases should go where what would be the specific values or the set values for those environments and so on and so forth we could split our definitions into multiple hemp files and then store them all in a directory called hempfile.d we could create hooks we could create layering we could define secrets and so on and so forth the amount of things that help file does is massive it is a collection of different open source projects related to helm and tying it all together adding additional functionalities it is massive now whether you want something that massive or no that's something that we might want to discuss a bit later for now let me destroy everything we did with the simple command film file destroy and there it goes everything we did is gone with a single command because just as we can apply many releases at once we can destroy many releases at once as well there are many many many pros to helm there are many amazing things it does we explored only a fraction of what it can do so let's start with pros what are some of the advantages of using helm file to begin with its ability to group releases it is the ability to define all the releases for one or for many different environments all in one place starting it and treat it all as a single unit that's absolutely amazing we always needed something like that simply dealing with dozens or hundreds of separate helm charts and executing random commands in ci cd pipelines was never a good option this allows us to define what an environment or a cluster or whole environment is and it's absolutely amazing it allows us also to define complex scenarios we can remove duplication we can define environment variables we can define default values we can create permutations of the things my head hurts when i'm trying to think of all different things and combinations we can do with helping there are secrets hooks layering a layering we can layer one helm file on top of the other one simply the amount of pros is huge i mean not necessarily pros the amount of things or the features of help file is really really impressive but the biggest one that my favorite absolute favorite is diff being able to create pull requests and then execute some pipeline that will create a diff of what it is right now running in an environment and what would happen if we apply changes to a hem chart or to a hem file that's that's gold that's absolutely absolutely amazing that's one of my favorite features of terraform and now we have it for helm in form of helm file and i love i absolutely absolutely love it now there are disadvantages as well there are cons to using helm file to begin with documentation is how to put it not very good i will not say horrible but it's really not very detailed unlike examples and help file doesn't have enough examples later on once i'm comfortable with a project and going through a project using example some quick start slots or not then i can go into detailed documentation which also by the way is not very detailed for help file another disadvantage or at least personal disadvantage or dislike is that i feel that help file might be going too far with yaml right it is allowing us to do many many different things with yaml but if i get to the level that i want that templating and environments and required environment variables and this and that if i get to the point that i need all those things which is questionable we might not need all those but if i do then i might be more comfortable than switching to some general purpose programming language maybe this is going too far with yaml maybe it would be better to use go or javascript or python or whatever is the language you want if you need all the things that they packed in on top of yaml essentially so it might be going a bit too far with jumbo but it really depends on which features you use and which features you don't use anyways helm file is very helpful in organizing releases environments clusters organizing the stuff that is floating around in many different charts and in value files and whatsoever but here comes the thing helm file goals are in a way similar to the goals of github's tools or the tools that we call github's tools today like argo cd and flux it has similar goals i mean not all of them there are definitely differences but from one point of view we can say that both count file on one hand and argo cd and flux on the other help us organize what is running where and store that information in it so from that perspective helm file on one hand and flux and argo cd and whatever else we use as and call github's tools today might be similar at least in the objectives so helm file is very helpful when we run things locally you know when you execute command it's so much easier to do help file this then hand this on that and combine many different health commands for manual execution help file is awesome it is also useful as a tool to inject into ci cd pipelines or pipelines in general but only if we want pipelines to do the deployment themselves if we don't want that and i suspect that we don't because we are moving fast towards github's world where we want to make changes to git repository which you can definitely do with help file but then use some agent that will pull those changes instead of us pushing those changes through pipelines if that's where we are going and i believe we are then help file might feel a bit antiquated what i'm really trying to say is that helm file is amazing it's great and you should adopt it right now if you're running at scale and if you're using helm directly however if you're adopting github's tools like cargo cd and flux then i think that they are overlapping in many of the things and help file might be only a complication on top of those tools generally speaking i prefer doing the deployments in defining things defining environments and releases and what's not in flux or argo cd format combining one with the other might be too much and i don't see the real benefit so to summarize if you're using helm directly the manually from a terminal or through pipelines and you want to continue doing that switch to help file help file improves young drastically but if you want to wait to organize your releases maybe just maybe you should abandon the idea to push your changes to your cluster you know from pipelines helm apply helm upgrade or whatsoever and switch into github's model where you have an agent in your cluster pooling manifests and also i personally prefer organizing releases in argo cdwa or fluxway then helm file so use helm file if you're not ready to jump into githubs and i'm not really 100 sure that you should be using it if you're adopting argo cd or flux but i might be wrong and if i'm wrong please let me know in the comments and you know what to do next subscribe hit the like button do all the things see you next time cheers

Channel: DevOps Toolkit

Views: 4,832

Keywords: helmfile, helmfile tutorial, helm, kubernetes, k8s, viktor farcic, devops, devops toolkit, helm releases, helmfile install

Id: qIJt8Iq8Zb0

Length: 29min 19sec (1759 seconds)

Published: Thu Apr 08 2021