 Alright, we're going to get started here. Hello everyone. It's good to see here So today we're going to be talking about Helm support in Argo CD But before we get started, I'd like to introduce myself. My name is Remington Breeze. I'm a founding software engineer at acuity And an Argo project maintainer Alex would you like to introduce yourself? Sure. Thanks Remington. Everyone can hear me. Hopefully so my name is Alexander Matushansov. Yes, I'm also working at company called acuity with Remington company acuity is founded by Argo creators proud to say it and I've been a long-time maintainer of Argo project same as Remington. So, thanks. Thanks Alex All right So the differences between installing a helm application with Argo CD Versus natively with helm install. They're not always immediately obvious So to discuss the differences we actually Have to have a basic understanding of Argo CD and what it's doing behind the scenes. So that's what we're going to start with today We'll first give a high-level overview of the reconciliation process And then we're going to dive into slightly more detail to describe how Argo CD is is then applying manifests And then finally we'll discuss how this relates to its support of different config management tools Before we dive deeper into Helm specifically So installing helm applications with Argo CD has a number of benefits Which includes automatic dependency install integration with the UI And helm hook support which we'll cover here as well. And then finally Because of the automatic dependency resolution It allows conveniences around private repositories as well So after I give a simple demo of a simple helm application installed with Argo CD Alex is going to compare two popular real-world approaches to deploying helm charts with Argo CD in the wild One of which is a beta Argo CD feature which we're pretty excited to showcase to you here today And then to conclude Alex is going to give a demo of how this new feature makes it really easy to synthesize configuration from different sources All right, so to understand the differences between native helm installs and Argo CD helm installs We kind of have to take a look at how manifests get applied by Argo CD So here we have a really high-level overview of the reconciliation process And we're going to start with the visualization step which is on the bottom right So essentially Argo CD is comparing the live state of your cluster with the desired state and get It can also be an OCI repo or a helm chart, which we'll discuss a little bit more later But it's essentially running kubectl diff and it's a little bit more complex behind the scenes But for our conversation today, that's what matters So the next step is going to be applying the changes to synchronize your cluster with git And we often say that Argo CD is essentially a glorified kubectl apply And this is the step where that kubectl apply happens And then after the synchronization happens the cycle repeats and we're going to have to pull manifests again And this is essentially get clone as I mentioned it can be OCI or a helm But it's basically get clone behind the scenes And Here we have essentially the same process. It's the same diagram, but with some more detail And first on the left we have the visualization The visualization step again But you can see the components that are responsible for it and that's going to be the API server And it provides data to the user interface and we're going to show you guys the user interface later if you haven't seen it And then it also communicates with kube API to manage application custom resources And then next is the apply step which you saw last slide again So the application controller is the one that's actually performing the kubectl apply step And it's also communicating with kube API to sort the live application and cluster state in redis And then it's monitoring those application CRs for changes and then finally the part that's most relevant to us today is on the far right And that's the repository server Which which is performing that get clone that you saw before And we're going to dive into a little bit more detail with that So zooming in on the right-hand side of that graph you see that the repo server is actually not pulling raw Valid Kubernetes YAML most of the time Instead what's usually happening is that users are using a config management tool So helm is one example of this Customized in jsonnet or other examples And arg of cd supports all three out of the box customize helm and jsonnet But the question is really how do we get from this templatized version of YAML to valid Kubernetes YAML that then gets applied to your cluster Because it's pretty rare to actually just be storing the valid YAML and get so what's happening is the repository server It fetches your configuration files and then it executes a binary Against this file which spits out the valid YAML so this allows users to specify dynamic parameters since the Argoscd rendering is happening on top of what stored on git rather than the other way around and What this also means that it is that it's relatively easy to extend this process with plugins So if you have a custom templating language That you like to use or a very unique use case as long as you have a binary Which is accepting really any input and outputting valid Kubernetes YAML It can then be kind of turned into an Argoscd config management plugin But back to helm What this really means is that Argoscd is not performing a helm install as you would traditionally think of it When you install a helm application with Argoscd Instead what we're doing behind the scenes is running helm template and passing the output of helm template To keep CTL apply So the consequence is that you don't actually have a helm release when you install a helm chart with Argoscd However, the Argoscd application It kind of takes the place of this helm release and in fact it has a number of benefits over a traditional helm release So you can see here the main differences Between a helm application deployed with Argoscd versus one with a traditional helm install So on top you have traditional on bottom you have Argoscd And what you can see is that there's essentially one-to-one parity So on top is helm LS and on bottom is Argoscd at list And most of the fields match or if there's not an exact one-to-one match, there's a similar match So one of the benefits that I mentioned of using Argoscd to manage these home applications is dependency management So chart dependencies get pulled automatically and if you commit those dependencies to get ahead of time Your deployment isn't going to fail if the chart goes offline Hooks are also a pretty popular helm feature and Argoscd has a solution to make sure that The hooks that you're relying on don't disappear when you install your chart with Argoscd So Argoscd also has a concept of hooks. We call them sync hooks. There's precync and post sync and a few other types And essentially what we're doing is mapping helm hooks to Argoscd hooks There are some less popular home hook types that don't have a clear one-to-one mapping And they're not currently supported by Argoscd, but these are pretty rare Most users don't use them and Argoscd supports most of the popular use cases And then finally a really large benefit of using helm with Argoscd is the UI That's kind of a benefit of Argoscd in general, but it relates to helm as well So Argoscd is going to detect any parameters that are defined in your values yaml And it surfaces them in the user interface, which you can see in the screenshot here And I'll show it in a little bit more detail when I get to the demo So users can easily edit these parameters, which is really useful for troubleshooting So if you're in a QA or test or any non-production critical environment and you need to really quickly change something It's super easy to do so in the Argoscd interface So in this screenshot you can kind of see what happens when you do make those changes in the interface The screenshot that you'll see here is an application in Argoscd application spec And you can see that the spec has been updated with parameters It's basically a subfield under the helm field So that's what's happening behind the scenes when you when you edit that those parameters in the UI And Finally before I get to the demo I mentioned before that because Argoscd is managing the helm dependencies for you it adds some convenience around private repositories So if you're using helm install natively You must download those helm repositories and somehow figure out authentication Locally with your local environment, but because Argoscd is kind of handling this all for you We offer out-of-the-box support for HTTPS repos OCI home repos and private repos Yeah, so I'd like to turn to a demo So here I have an Argoscd application if you've never seen the Argoscd user interface This is what it looks like So we have all of the resources that are in this application displayed in a really nice tree view And what this is deploying is an off-the-shelf wordpress Helm chart and I'm actually going to show you what this repository looks like So this is what that application was pointing to this is all the files that are in that application and it's pretty simple There's a chart.yaml Read me which gives some docs and then two values.yaml files So if we look at this chart.yaml You can see that it is really just off-the-shelf wordpress. It's pinned to a version And it's it's a community maintained chart And then like I said in the higher director, we have a couple values files So in this application, I deployed it with MariaDB installed So MariaDB is a subchart of wordpress that is just included with the wordpress chart But you may have noticed that the second values file that was available is values no MariaDB So you can install this without MariaDB So we're gonna show the ability of Argo CD to quickly toggle that So if you go to the parameters section that we showed on the slides You'll see that we have these parameters similar to what you saw before but up top We have a values section and that's because Argo CD detected that there are two values files And we can actually remove the original one and add the values no Maria And I'll click save it'll take a couple seconds And you'll notice now that this application went out of sync and you'll also notice that a bunch more Parameters became available to us because instead of having a built-in DB We now have an external DB that we have to configure so Argo CD Intelligent really detected that that values file contains a lot more options And basically the reason that this application became out of sync is because pruning is turned off It's not going to delete all of these DB resources for you And Argo CD is saying. Oh, I noticed that there are components installed here that shouldn't be But instead of deleting them to get it back in sync What I'll do is just change the values file back and we'll see that this application goes back in sync and It's healthy in sync All right, so with that I'm going to pass it over to Alex and he'll take over for the rest of the presentation. Thank you Awesome, you can see my whole screen. I have just one slide and a demo and so as Remington described I'm going to talk a bit about real life use cases And as you know in real life, we do have to deal with a little bit of more complexity Not often we deploy an application that is just packaged into one Helm chart usually we need something else like we need additional services and Here is the slide that kind of tries to visualize this additional complexity And I will start from just describing what I tried to visualize here I will start from the left top corner and here I have two very Two dependencies that we see very frequently Which is a radius and and nginx or any kind of proxy and so the use cases those services are solving is Let's say you're building a Java based microservice and you need caching radius is a perfect candidate to solve this problem if you want to improve performance of your Of how your application is serving static assets nginx is a great tool and so What's important here is those popular open source projects Also have a community maintained home charts and that make total sense to use those home charts instead of replicating the work yourself But the problem is community is not going to magically deliver it into your deployment repository Instead they make those home charts available in a third party home repositories And so the obvious option that you have is to Copy them into your deployment repo, but this will bring a lot of maintenance work You need to start watching for new version Update home charts manually. So that's not Convenient at all. So the next example is Surprisingly our own home chart and so what we learned from Argo CD users and from developers that they prefer to have their own Home chart next to the source code. So and it's understandable So the use case we heard is let's say a developer wants to make a change in the cell I flag flag is used in a home chart and so if someone just change the source code Home chart will stop working and developers wants to make those changes in the same pull request So that's the justification of why home chart it makes sense to have help chart in the same source code repository with the code and so again, the process is to publish this home chart automatically with the new image into some Home repository and so finally we have one more block here So we do want to have some configuration in git And I'm talking about value files. It makes total sense because usually in those value files You store settings that are specific to your environments and that's pretty much what we are managing using github's and So the question is how do we put How do we combine all those things together and how do we teach our go CD to deliver it as one unit during deployment process? so one option Remington kind of kind of demonstrated it already. It's called umbrella chart This is not even a feature of our go CD It's just a name of a usage pattern that is available in helm itself And so as you could guess from the name idea is to create a helm chart that has no Manifests it only has a chart dot yaml file that describe Describe list of your dependencies and it has Values file specific to your environment and so it's perfectly working for many are go CD users And in fact people were using it for like years But we did heard from community about some disadvantages and so one complain is That this Chart dot yaml file. It's redundant and the reason is you can't describe the same thing in our go CD application spec You can point our go CD directly to the helm chart not to get and you can specify the value file So why why do you I force to create an umbrella chart if this value file is located in it? if you want to have this home chart in your Get repository and so we agreed to that and then we've got another complaint So our go CD has a feature Where it can follow the version basically you can provide the target version which doesn't have a fixed version instead it contains same your range expression and Argo CD is supposed to detect new Helm chart versions that matches this expression and it will automatically upgrade your application and This feature does not is not available to you if you are using umbrella helm chart So we listen to that feedback and we decided to work on it and last year We finally delivered a better solution that others is those concerns and the feature is called Multiple sources and that's pretty much a different way of deploying together a set of manifests that allocated in different sources and so as you can guess from the name Argo CD application got and you got an ability to describe multiple sources in a single application and It solves actually several use cases, but the helm use case was the primary driver to actually build that feature and Yamal on this slide demonstrates how you can deploy an engine X Using off-the-shelf engine X home chart with the value files that are stored in your private git repository And so Argos CD behind the scene will take care of Extracting content of a helm chart it will download the repo and it will make Files available of this private of this private repo available to the helm template command And that's pretty much the feature that I'm going to demonstrate right now In you will see how how you can use exactly how you can use Argos CD to deploy an application like that So I kind of I spent some time and I created an application specifically for this demo I'm kind of doing this demo backwards and the reason is I want to show you how it's up and running and then I want to make a change and demonstrate how Argos CD will detect a new version of my helm chart and Upgrade this application and another I want to demonstrate some of the functionality of this application Obviously, it's not real Payment service But it has this make payment button and every time I click it it's going to increase a counter If I refresh this page counter stays the same because I have a little back end I use radius as a database to store number of clicks So it's working perfectly except it has this terrible red background So I want to improve it a little bit and I want to make a change in my source code to have a slightly better background and so here you can see a Repository which has the source code of my application and by the way it has a helm chart as well So here is my payments helm chart. It has real templates no dependencies so it's just a Kubernetes deployment and Kubernetes service and Now I'm going to make a change It's a simple goal application that serves an index.html file plus couple IPI methods So to improve the background I can Make a change right here Okay, maybe I could think of a better color, but let's Okay, let's make it blue I agree Blue is a little better All right, so we did a change and I have a little automation that Publishes a new release publishes a new helm chart Every time I create a new release. So I need to create a new 19 release and It should trigger a workflow and workflow will create a new version of our helm chart Okay, it starts it. All right while it's running we have time to see how exactly this application is deployed And so here it is. Here is Argo CD You know how UI looks like already because Remington I showed it to us So here is my payments deployment and the rest of it the rest of this application is radius so I used a cha version of radius highly available radius and It's up and running so but the main reason main Configuration part that I want to show you is Argo CD spec as you can see it uses multiple sources And so I have three sources here one is a helm chart of my application And my my repository is just powered by a github pages and as we speak there is a workflow Github action that is pushing a new helm chart into this Helm repository So what's important here my application is supposed to be automatically upgraded every time when there is a new Helm chart published a new patch release of my home chart and Next I have a values file that are stored in my deployment repository. I'm going to show you that repository in a second Before I go there. I want to highlight this Second dependent second source, which is just the off-the-shelf helm chart that provide me radius and Now I can show you my deployment repo So deployment repo is extremely boring on purpose. It has no manifests has no helm charts It's just a value files of my let's say QA environment And so this is exactly what I wanted to achieve to only put in gith configurations that I care about and It's time to check how workflow is doing so a new home chart was created images built and pushed to github pages So if I'm lucky Argo CD It detects changes every five minutes So I had to click refresh button and it should detect a change right now. Oh, it happened So we can use Argo CD UI to see what exactly it changed and as expected Just a new image got pushed So new home chart which uses a new view new image by default. So now I can go ahead and sync sync my application so Argo CD will Perform the deployment Okay, I can see the port just got created. I Use port forwarding here. So I need to restart port forward and We can check the new background Okay, I hope I hope you like it more All right, so That's it. Thanks for listening. Please provide us feedback. So here is your it's the QR code that will lead you to Feedback form and thanks a lot for listening. We are happy to answer any questions Yeah, so I'll repeat the question so is there a way to support better way of authentication to OCR Yeah All right, maybe I so I Know that our go CD supports one way of Authenticating to OCR you can provide username and token, but maybe I'm missing some use case. Can you oh, I see Okay. Oh, so the problem is Amazon like if you use OCR that token expires periodically Okay, I think the answer is short. It's no I don't know the better way to do it unless Amazon itself supports Some kind of a service that works as a proxy and then yeah, I never heard about it to be honest, but yeah, that's So answer is not It's a good feature Oh Yeah, I will repeat the question and please correct me if I'm wrong So I think the question is how do we get cluster information into the helm chart because we needed during templating I think we kind of improving it over time step by step one Improvement was made maybe a year ago So now in the helm chart, you can know the cluster version and available and available IP eyes So literally our go CD just provided via cell I flux list of available IP eyes And so you can have if else expressions you might you might say if cluster version is less than something then do this Or you can say if extensions deployment available then do that and then we didn't want to provide Kind of full access like you cannot look up something from the managed cluster from the helm template for security reasons mainly it was it we didn't think it was secure because repo server Perform manifest generation for all tenants. So nothing stop you from doing something bad, but This config management plug plugins. It's better now because Config management plugins are running kind of in a sandbox and they cannot do that damage so the remaining step is to Migrate helm support into the same kind of architecture and then we already discussed and we are open to Support like basically look up function of helm. So it's like step-by-step improving. I hope we will get there eventually I Didn't have to change the app I wanted to just demonstrate that the feature that like users of Fargo CD wanted this automatic upgrade It it's possible. Even if you have like a helm chart and the value file Yeah, so when I made the change I Maybe I didn't explain it well the workflow that was running in background. It published in you Helm chart version. So my my registry get help. Sorry helm repository got one So zero one point nineteen version and our go CD detected it and then it used it instead of one point I Think I think the best way to roll back is to when you there is a Functionality when you can sync our go CD and you can specify what version you wanted to be synced to So you can get yeah, basically if let's say if you use git or if you use Helm you can specify exact version and so our go CD will be came out of sync But if you in a situation when there is a disaster then that's acceptable And then you can change kids to kind of match this version Dr. Run is there to work to do validation basically if you make some changes and you want to know Is Kubernetes is going to accept you manifests? Yeah, this is what it's there for and maybe maybe you're referring to a bug we recently just discuss it So if our go CD has auto sync enabled is it what you're talking about it doesn't want you to sync to any version and There was a bug where it enforces It doesn't want to sync it even if you're doing try run and we just like it's a it's a we didn't think about it So basically this restriction. I think it's already removed in master So dry run flag should not be back prevent you From syncing to any version even if how to sync is enabled So it it used to do it, but due to a mistake. So now it will be fixed Yes I Will quickly repeat just so there was a change in Helm dot 3 where helm no longer touches CRDs when upgrade is happening correct. And so Yeah, and so the question is does our go CD is it doing the same so I think answer is no So we are go CD will make a change in CRDs even if there is upgrade and I think answer is it's kind of questionable behavior I don't I know that some Helm users don't know Yeah, and so we Like we didn't hear strong feedback to make the same change in our go CD So right now our go CD will update CRDs like let's say if you if you needed to do an upgrade and your CRD has a new Versions our go CD will go ahead and update it only thing that our go CD is doing special about CRDs It never deletes them, which is also some people don't like it, but It's just if you're deleting an application, but an application included CRDs CRDs will stay So you don't have to it you can use just multiple git repositories So that I mentioned some other use cases. There's just one in other use case like let's say you have Several building blocks of the same application. You just want to combine them together. You can do it Yeah, you can just specify several git repositories. I think I will try to repeat, but I didn't follow I think probably if I understood this correctly, there is no such functionality like it basically you kind of now But the only thing that multiple source sources let you is you have this fixed source of and if you talked about our go CD Applicate our go CD project. Correct. So if you if application referencing multiple sources, those sources just must be Allowed in in that our go CD project. So no Like there is no Dynamical decisions can be made. Do you I think I don't have anything that I think I think yeah Mm-hmm. Oh, yeah Are you talking about an Auguste project? Yeah, I think the long story short is no not not at the moment Yeah, yeah, I think we're just getting a signal that we run out of time, but thanks a lot. Thank you