GitOps Without Pipelines With ArgoCD Image Updater

can be automated a part of continuous delivery that clones the repository modifies the manifest with the new release and pushes those changes back to git can we do that without using pipelines the short answer is yes and for a slightly longer answer well you will have to watch the video [Music] git tops is all about defining the desired state and storing it in git and then letting tools like cargo cd flux and a few others synchronize the desired state what isn't it and the actual state which are your resources which could be applications infrastructure services or anything else that means that every time we build a new release of an application we need to clone the repository that contains the desired state change a few entries in manifests and push those changes back to git we can do that manually like a git clone and then change a file using your favorite editor and then git add git comment git push or we can do that through pipelines so let me show you an example of a pipeline that does precisely that what you see on the screen is argo workflows pipeline but the same logic the same principles would apply with jenkins or github actions or tecton or whatever you are using and the logic is simple i am cloning the repository with the manifests and then i'm modifying one of the manifest by changing the tag to whatever was built in previous steps and once i'm done i'm adding and committing and pushing those changes back to the git repository from there on i do not need pipeline at least when deployment is in question because argo cd will detect those changes to the git repository and do whatever needs to be done now to be honest i might need to run some tests afterwards and do some other things and i would do those things using pipelines but not for the deployment itself that's done now through argo cd there is nothing for pipeline to do apart from modifying some manifests and pushing those changes back to git my mission today is to get rid of those steps i will not try to get rid of pipelines altogether because i still need something to build my container images to run tests to do whatever else needs to be done so my scope here is limited to the part that modifies git repository by changing some manifests and pushing changes back to that same git repo i want to get rid of that part and i want to do it with argo cd since i'm lazy i did not really want to write a completely new kubernetes controller that would do all those things monitor registry with container images figure out when i push a new image modify some git repository and so on and so forth instead i went out looking for a solution and it did not take long because argo cd has the solution and it is called argo cd image updater so let me show you how that looks like let me show you how you can streamline part of your processes or remove part of your processes from pipeline by using image updates i will soon jump into the demo but for now let me give you a brief overview of what it does image updater will monitor your container image registry it could look for all the tags or tags in specific range or with specific naming convention there are many ways how we can filter what it looks for in its essence the image updater will look for specific or all tags for a specific image and whenever we push a new image it will update automatically git repository that contains the manifests that describe the application that uses that image now that might be confusing in such a short description so let me jump straight into the demo and show you how that looks like how it works comment on certain features and at the end we are going to talk about argosy the image updater and see whether you should use it what are pros what are cons and so on and so forth now i will save you from misery of watching me setting up the initial cluster and installing argo cd and a few other things i already did all the preparation in advance if you want to replicate what i'm doing the link to the gist with all the commands is in the description so go and check it out so here's my argo cd up and running and by the way if you're not familiar with argo cd i have two things to tell you first shame on you go and check the videos i have quite a few on this channel and the links are in the description and the second is that i'm using apops here i have production application that watches specific directory in a specific git repository and in that directory i have only one application i did not want to go crazy for this demo i have only one up normally i would have many more but one up should be enough to see how image updater works the application is already up and running and what i want to do next is to see how i can use image updater to streamline new releases of that application so the first thing i need to do is install image updater it's a simple cube cattle apply command so the installation itself is very easy but we will need to make some changes to it so that it knows how to access the repository how to access the registry and a few other things to be on the safe side i'm going to double check the logs of image update and see whether everything looks okay whether i'm really ready to start using it the important thing in the locks is the last entry that says processing results applications zero image is considered zero images keep zero images updated zero and errors zero what that means is that the image updater thinks that there are no applications that should be managed and that's normal because we need to tell image updater which applications should manage so you can install it without any fear of the consequences because the image updater will do nothing unless we tell it to do something with an application or with more applications or with all our applications we need to tell it which applications it should take into account when doing whatever it needs to be doing so let me do just that let me modify the definition of the argo cd application itself not the manifest of my application but only of argo cd app i am going to add a few annotations first of all i am going to give it the list of images that it should monitor in my registry to be more precise i'm going to give it only one image but this could be a list of multiple images if an application uses more than one image next i'm going to define the write back method and set it to be git and to use a secret and that secret will be stored in argo cd namespace and it will be called git dash creds i could have told the image updater to go directly to argo cd but that's not a good idea i do not want it to work against argo cd itself i wanted to modify the definitions in my git repository because that's what git tops is all about finally to be on the safe side and to avoid potential miscommunication i will tell it to use git branch called main and that's almost all there is to it i define a couple of annotations and i will soon push that manifest to the git repository argo cd will figure it out and apply it to my cluster and from there on image updater will know that there is one application it should manage later on there might be more actually there will be more there is more but not in this demo before i push those things i owe you an explanation about container image registries by default image updater supports docker hub google container registry red hat quay registry github docker packages and github container registry bear in mind that's out of the box if you do not use one of those registries if your container images are somewhere else do not despair because that's only what comes out of the box there is a configuration file that you can use to add additional registries and from there on it can use any registry you want any registry you have this is just what comes out of the box going back to annotations if you paid attention you notice that i said that it should use git as the write back method and that there will be a secret called git credits that secret should contain authentication to my git repository i'm using github today but it could be anything else so i need to create that secret first and then i will push those changes to get do not expect from me explanation how to create kubernetes secrets just do it or use the command in the gist this is not a session about kubernetes secrets even though when i think about it i should probably make a session on kubernetes secrets nevertheless that's about it i created the secret now let me push those changes to the git triple now let's go back to the locks of the image updater again and see what it will do what will happen now that we added a few annotations to the argo cd application manifest by default image updater is pulling changes from container image registries every two minutes so it might take a couple of moments until it figures out that i added the annotation it needs and until it figures out what i have in my container image registry and while waiting for that to happen let me ask you for a favor if you like this video please click the like button and the thumbs up and all the other things that you do in youtube and if you think that the channel itself is useful please consider joining it it's the price of a single coffee and it helps tremendously when paying all the bills that need to be paid for this channel look at that output image updater figured out that my manifests are not using the tag that i might want to be using so it cloned the repository push something into the triple i will show you what it pushed in a second and from there on argo cd should detect those changes in that git repo and do whatever argo cd is doing which is synchronizing the desired in the actual state in my kubernetes cluster and if you don't want to look at all those log entries the key is in the last line that says hey applications one now it thinks that there is one application it should manage images considered also one it found one image that matches the criteria and the image is updated also one now let's see what it actually did let me go to the git repo and see what did we get what did it do we can see that it added a new file called dot argo cd source devops toolkit.yaml and since that file did not exist before it created it and it's a very simple file it just says hey customize images before six devops toolkit colon and then nine nine nine nine nine nine nine i don't know how many nines there are but there are many nice now in this case i'm using customize but it could be pure kubernetes yaml or it could be helm as well any of the trees should work customize helm or pure kubernetes yaml now going back to 999999 i don't know how many nines we have in the tag over there you might be wondering hey why did it use that tag and the answer is very simple that's the latest tag that i have in my container registry i'm using docker hub today but again it could apply to any content registry and now i realize that i forgot what i wanted to say yes that's the latest tag and i did not tell argo cd which tag to use which naming convention to use what to do so without any additional instructions you just said hey yeah i see that this is the latest tag and i see that that tag is not used in your application right now you probably want to update that application to use your latest stack in most cases that is not acceptable the last target the latest time can be anything it could be something that you want only in the development environment so we need to figure out a couple of things first of all we need to choose which version format we are using and tell image updater to use that one it would be semantic versioning or latest or digest or a name based on some regular expression i think that those four are currently supported you go to the documentation check the details if you don't want to use semantic versioning because today i am going to use semantic versioning and i think that everybody should be using semantic versioning but i might be wrong in any case what i wanted to do is tell the image updater hey use versions one and above all the way until version two why would i do that well because if i change the major version remember i'm using semantic versioning and if i change the major version that means breaking changes and in that case i might not want that much automation because hey breaking changes do not happen often and i should probably be on top of it and put a bit of extra effort into the process maybe some manual verifications whatsoever in other words i will assume that currently i'm running one of the versions one maybe 1.2.3 or whichever and i will tell image updater to keep updating my manifest automatically as long as i do not change the major version from one to two to do that is really simple and straightforward i just need to change one of the annotations that i already added to the manifest but before i do that let me double check that it really did what it's supposed to do and i will do that by going to argo cd web ui and double checking what is the current image tag of the deployment of my application and yes it works as expected it is currently using image devops toolkit with the tag 999999999 i don't know how many nines and if you're paranoid and if you do not trust argo cd itself then we can describe the deployment and see that yes the actual tag of the image in my kubernetes cluster is really nine nine nine nine nine oh it's starting to say so many nines so let's go back to taming this system and limiting it only to major releases one it can be any minor release any patch release i do not care i want to have the latest release but only within the scope of the major release one and to do that i will change the annotation image list by adding colon tilde 1 to the end where the tag normal is if you are using semantic versioning and you do not know how to define the scope of the versions that should be managed by image updater you can go to this page which explains it all it is explanation how semantic versioning works in general this is not specific to the image updater so go and check it out if you're not sure how to define the range that you need and the link is in the gist so check it out you know this link in the description all that long story short all i have to do really now is to push those changes to get but before i do that i will pull the latest version because image updater already change the repository and then i will add and comment and push you know give commands you know them already and from now on image updater will know which range of tags to use but there is still one more thing that i need to do the main thing the most important thing and that thing is to create a new release so i will build a new container image with the tag which touch should i use let's say 1.2.3 because i'm not creative today and then i will push that image to the container registry and now all that's left is to wait until image updater figures out that there is a new image and that the tag of that image is within the specified range meaning major release is one and then do the things that it needs to do and while waiting instead of contemplating about the fate of the universe or whatever you usually do while waiting for something you might want to subscribe and like and join the channel and do the things that you should be doing because let's face it if you're watching these videos for so long you like it you find it interesting you find it useful so like the video as well and we can see very similar output in the logs as we saw before it figured out that there is something it should do it modified git repository it pushed changes to the git repository and then it showed at the very end what it did meaning that hey it considered one image it updated one image and that's about it and if i go to the git repo i can see that the file that we were exploring before you know the argo cd source devops toolkit yaml now contains tag 1.2.3 and that's about it that's all there is to it it's simple it is focused on one thing and one thing only and it does that thing well or maybe not so well there are some potential issues but we are going to talk about them at the end of the video which is coming very soon but there is one more thing that i want to check first i want to confirm that image updater will not go beyond the range of versions that i specified which in my case is all major versions one so i'm going to build a new image with the tag 2.0.0 and i'm going to push that image and i'm going to wait for a while but i'm not going to force you to wait so i'm going to fast forward a minute or two and take a look at the looks of image updater and confirm through those logs that it did nothing i wanted to do nothing because i pushed a version that it should not use there is nothing in the log saying that it modified anything because version 2 is not something it should deal with and if i go to the git repository i can see that the file is untouched and we can live happily ever after now let's talk about pros and cons of argosy the image updater and see whether you should use it or not and if you should when you should use it this is a very small project and very focused project and i like that its mission is clear it is updating manifest in our git repositories automatically whenever we push a new image to a container registry and as long as the tag of that image is within the range of the versions that we wanted to manage it eliminates the need for us or pipelines to clone a git repository to modify manifest by changing the tag of the image or images we want to release to some environment and it pushes those changes back together that's all it does and that is its biggest advantage it is doing what it's supposed to do and nothing else and it is doing it fairly well but there are a couple of cons as well a couple of things i do not like not many though there are only two first of all it cannot create pull requests it would be great if it would create a pull request and then we could review the changes he did before merging it to the main line and creation of those pull requests could execute some pipelines that would validate things that would run tests and whatever else we might be doing through pipelines the second issue is a potential problem a real one or not depending on how you're organizing your manifesto let's explain what's going on image updater is adding an additional file to the directory where the manifests of the application are where the base manifests of the application are as a result it might end up in an infinite loop imagine following scenario you write some changes to your application you push those changes to the git report that application that triggers the webhook webhook notify is your favorite pipeline tool which will run a process that will build a new image run some tests do some things and at the end of those things it will push the changes to a container register from there on image updater will figure out that there are some changes over there and make the change to the manifest in that same repository and that will repeat the whole cycle you make changes to git repository image updater makes changes to the rigid repository you run a pipeline that builds container image run tests and whatever else it's doing pushes that image to content registry image updater updates the git repo and again and again and again and again in other words you cannot keep the manifests of your application in the same repository where the rest of that application is the code the tests the build scripts whatever else you're having and that's kind of limiting i do not like that part if you already have your manifest somewhere else great ignore completely this complaint but if the manifests of your application are in the same repo where the rest of that application is then you're going to have issues with the image updater if you combine it with pipelines for some other tasks because again infinite loop very dangerous you need to move your manifest somewhere else or not to use image updater and if your manifesto is somewhere else then i don't know why i'm talking to you what i would like is for image updater to update argo cd application manifest and not push some changes to the manifests of the application itself that would be absolutely awesome because then i would have freedom to organize my manifest anywhere i like i could have vargo cd applications in one repository and base manifests of my application somewhere else or i could keep them all together somewhere else or i could do any combination if there would be more flexibility about the location of the file that image updater is created besides those two complaints you know pull requests and potential infinite loop depending on where you keep your manifests image updater is fantastic it's amazing i love it and i think you should be using it if the downsides are not a deal breaker for you you

Channel: DevOps Toolkit

Views: 15,437

Keywords: devops, devops toolkit, review, tutorial, viktor farcic, argo, argo cd, argocd, argo cd image updater, argocd image updater, kubernetes, k8s, gitops, pipelines, cd/cd, ci/cd pipeline, argocd kubernetes, argocd kubernetes tutorial, argocd gitops, continuous delivery, gitops kubernetes, gitops argocd, gitops demo, argocd demo, argo cd pipeline, viktor farcic youtube, what is argocd, continuous delivery pipeline

Id: avPUQin9kzU

Length: 22min 0sec (1320 seconds)

Published: Mon Oct 25 2021

Reddit Comments

[u/quantastical]

Great vid! Did not know about it not forcing you to use semver, no idea how I missed it in the docs.

For manual promotes you'd just pipeline a tag change with this right?

[u/PFCJake]

Hey Viktor, thanks for a good video once again. This is an issue me and my team recently tackled using the "manual" approach with a script like you have in the awesome automate everything-video. I have a few comments on the ArgoCD Image updater-approach:

• Needing to split up your manifests and application code in two repositories is to me not a con. Rather, keeping them in the same is an anti pattern and against Argo CD best practices.
• My biggest reservation towards ArgoCD Image Updater is that it adds another component that executes arbitrary devops workloads if that makes sense. I want Argo Workflows to be the only actor that does this. If I keep adding new specialized tools for each potential issue I risk ending up with spagetti where things trigger each other all over the place and it becomes hard reasoning about the system.