ArgoCD Starter Guide: Full Tutorial for ArgoCD in Kubernetes

in this video you're going to learn Argo CD by the end of this video you're going to have a good understanding of what Argo CD is why we use it and how we can use it to automatically deploy to our kubernetes clusters this video contains both Theory and a walkthrough tutorial lab that you can follow along with that shows you how to install Argo CD and how to deploy applications using both the Argo CD web interface and command line interface so let's get started what exactly is Argo CD well Argo CD is a declarative get ops-based continuous delivery tool for kubernetes it helps us deploy and manage applications on kubernetes clusters in an automated reliable and repeatable way it does this by continuously monitoring the current live state of applications in a cluster and Compares it against the desired State defined in a get repository this is commonly referred to as making git your source of Truth for your configurations whenever a developer pushes changes to a git repository Argo CD will detect the changes and sync them to the kubernetes cluster syncing can either be a manual or automatic process depending on how you configure it it can be a pretty common pattern to just automatically sync changes from Dev and test environments but have your production applications require someone manually syncing so that's really the big picture of what you need to know for Argo CD at a high level you define your settings in a git repository and Argo CD makes sure your environments reflect what's in get let's now look at an example real world pipeline that should give you a better understanding of the complete flow so when it comes to get Ops it's a best practice to have two repositories one for your application source code and another one for your configuration code in your configuration repository you should have your kubernetes manifests Helm charts or customize files which would Define your kubernetes assets such as deployments services and configuration Maps whenever this configuration repo gets updated that's when Argo CD is going to kick in and do its sync but that's not all there is to this story let's remember that Argo CD is a continuous delivery tool we still require a pipeline for continuous integration that will test and build our application when a developer updates the application source code that's when the code is going to be tested and the image will be built and pushed to a container repository your CI pipeline then could trigger updates to your configuration repository which would cause Argo CD to sync this is a good example pipeline that many companies use when implement lamenting get Ops into their workflow now before we jump into the labs that are really going to cement your knowledge of how to use Argo CD there's two more things that you need to understand about Argo CD and that's its ability to enable Disaster Recovery as well as its ability to orchestrate deployments to multiple kubernetes clusters you see in the devops world we don't tend to back things up anymore we recreate them instead with Argo CD if you were to lose a kubernetes cluster you could just bootstrap a new cluster and point your Argo deployment to your get repository since everything is defined in code argocd would bring up the new cluster to the desired State and you're back in business one more thing to mention is that Argo CD is also not bound to a single kubernetes cluster you could have Argo CD installed on one cluster controlling the configuration of multiple clusters if any of these clusters were to fail it should be a trivial task to bring them back if you were to lose the cluster where Argo is installed it would also be recoverable as the config configuration of Argo can be stored as a yaml file so that's all the working knowledge you need to have to get started with Argo CD in the description of this video I have provided a link to my GitHub repository which contains both the helm and customize application which we will be deploying to Argo CD if you're going to follow along with the lab make sure to Fork this repository so you can make updates that will trigger Argo CD to sync on your changes other than that all you need is access to a kubernetes environment where you can install Argo CD I'm using minicube which you can download and get started with for free we're going to be using both the Argo CD web interface and CLI to deploy sync and troubleshoot the applications so let's go ahead and get started alright so I got a new Mini Cube cluster set up here and the first thing I want to do to get started with Argo CD is create a namespace and this namespace is going to be where our Argo CD is installed into so I'm going to do a cube cuddle create namespace Argo CD and the next command I'm going to do is another Cube cuddle command and it's just going to be applying the Argo CD manifest installation file so these commands are actually in my GitHub repository in the description below so if you're following along make sure to grab those commands and just to have a quick look at the command again basically it's just a cube control apply namespace Argo CD and then the Manifest file for installing arbo CD so pretty simple there if you want to verify your installation you could do a cube cuddle and get all and then specify the namespace of Argo CD and there you should see that your resources are starting to come up so not everything is up right now uh some pods are still coming online but these are all the different components that your Argo CD installation is going to require now to access Argo CD we actually need to do a little bit of port forwarding to get to the Argo CD web GUI so to access the web GUI we're going to be connecting to this service service slash argocd-server listening on Port 80 and Port 443 so we're just going to do a cube cuddle port forward specify the service namespace Argo CD and I'm gonna port forward 8080 on that service so that's port forwarding I'm going to pull up a web browser here and I'm going to bypass this certificate check and now we get to the login so the default username is admin but you will have a different password than me so in order to get the password for your Argo CD installation head on over back to the command line and we're going to use a cube cuddle command to pull the secret so the command is just a cube cuddle command to pull the Argo CD initial admin secret and then base64 decode it so that's my password I'll just throw that into my clipboard and paste it in here and I should be signed on so let's go ahead and actually deploy our first application here as that's the best way to get a good understanding of how Argo CD works so in my other tab I have my GitHub repository so in this repository I have two applications and it's actually the same application it's just wrapped differently so this is a simple kubernetes web application and the first one is deployed using Helm and the second one is deployed using customize now Hellman customize are pretty big components of deploying kubernetes applications so if you don't understand those you should get familiar with them I have other videos available so to help you learn those but if you aren't familiar with Helm or customize at the moment that's fine you should still be able to follow along with this video and get a good idea one of the cool things that I'm going to show you is actually some nuances between Helm and customized deployments which I think a lot of people don't understand why you'd use customize overhelm for example but enough of that let's get back into Argo CD and I'm going to pull this into my clipboard actually and then I'm just going to go new application and then for the application name this can be anything you want but I'm just going to call it Helm Dash web app and then I usually like to specify my environment so I'm going to say this is our Dev environment and then underneath here project name you can just select default and then after that we have a really important option which is our sync policy so you can see that there's two different options for our sync policy there's manual and there's automatic so this is a pretty simple concept to understand basically if you select manual Argo CD will detect the changes in your GitHub repository but it's not going to apply them to your kubernetes cluster so you'll actually need to go into Argo CD and hit the sync button before the changes come over for your application now if you choose automatic you won't need to click that synchronize button and Argo CD will see the changes and then just pull them over so commonly for companies just getting started with Argo CD they usually go with automatic for their Dev environments and then manual for their production until they're more comfortable with Argo CD deploying changes to production all the time we're going to start with manual as there's a couple of nuances I want you to see with Argo CD so we'll stick with that and then we have our synchronization options which will get a better understanding later when we actually start doing our synchronization but one that I want you to enable right now is auto create namespace and it does exactly what it says it's going to automatically create the namespace in your kubernetes cluster if it doesn't already exist so let's scroll down in the next section is our source and our destination so our source is our GitHub repository this is where our application configuration lives so I'm going to paste in my GitHub repository now if you're following along with this tutorial you probably want to Fork my repository and put your repository in here so you can make changes to your repository and have your Argo CD pull it so I'm putting mine in here and then underneath we want to select the path so this is just the path within the repository we're doing our Helm application first so we'll choose Helm web app and then for the destination you can see that there's just one option here which is our mini Cube kubernetes cluster so Argo CD can actually control the deployments to other kubernetes clusters if you want to and it's a pretty common scenario to have like a single installation of Argo CD controlling the deployments to multiple kubernetes clusters so if you had multiple kubernetes clusters set up you would just select which one you want to and then you would select the namespace so this was our development so we'll just I'll just call it Dev and then underneath here you can see that it's detected that this is a Helm deployment So within my Helm deployments I'll just go here you can see that there's three different value files I have like my values Dev values prod values dot yaml this is the default values yaml file I'm going to be using my values Dash Dev and it's going to pull up all the values within here and for my specific application it takes in this custom header and it outputs it to the user so whatever's in here it'll push out so I'm going to go back here and I'm going to hit create and our application should show up here and it looks like Argo CD picked it up right away and it says it's out of sync and the reason it's out of sync is because Argo CD now knows about this application it can see the GitHub repository it can see the Manifest files there but it does not see this application within our kubernetes cluster and this is because we have set it to manual syncing so in order to sync our application we need to hit this sync button and then we can just hit synchronize and you can see that it's just going to run through and synchronize our application and you can see right away it detected everything about our application it knows that it has a configuration map it knows that there's a service and a deployment and a replica set and five different pods so let's go ahead and head into kubernetes and just verify that our application actually deployed there so we'll just do Cube control get all namespace Dev and you can see that all the pods are there all five pods now if you wanted to actually access the application you could do that same port forwarding command but we want to specify in this service and then let's just map Port 888 Deport 80. which you can see the Pod is listening on here or the service is listening on Port 80 and it did not find my application because I did not specify the namespace so I'll specify the namespace of Dev and now it says it's port forwarding to it and I'm getting an error here it's actually not https uh let's change that to http and there you go you can see that our application is deployed and that message is coming up here and saying this is on the dev environment okay so that's how easy it is to deploy an application to Argo CD let's go ahead and turn on auto synchronization and actually make a change to our application and just watch Argo CD deploy to it so I'm going to head on over to Argo CD and just go to app details and I am going to scroll down here and underneath sync policy I'm just going to enable automatic syncing hit OK and that should be it and then within our application under the values Dash Dev I'm going to change the replicas from 5 down to two so I will commit the changes head on back to Argo CD hit this refresh button and you can see how quickly it picked it up sometimes it takes about 30 seconds but it picked it up and you can see that the last sync result is okay and it is pointing to this commit which matches the head so everything has been synced up properly and uh you can see that all the old pods are dying so instead of having five pods in our Dev environment we now have two and it's pretty crazy how quickly Argo CD picked up that change and implemented it all right so the next thing I want to show you is how you can actually roll back using Argo CD so right now we're in a state where we made changes and now we have two replicas but our original configuration had five replicas so let's pretend that this was like a bad configuration change that we put in and it's affecting production and we really need to revert back to our old configuration now what you would do in that situation is you could either make the change in GitHub and just apply the fixing GitHub if you know what the fix is and Argo CD would automatically pick up those changes and sync your fix over to production but if you don't know what the fix is and you just need to go back to a previous working version what you want to do is a rollback so what you would do is head on over to this history and rollbacks button and here is the complete deployment history for Argo CD now I have a couple of additional deployments to this application that I did while I wasn't recording so I probably have a longer history than you have in yours but just to demonstrate how easy it is to roll back using Argo CD you would just find the GitHub revision number that you want to roll back to and then you would click here and hit rollback and here we get a message saying that if you want to roll back you need to turn off auto sync and this makes sense because if you add auto sync turned on and you rolled back it would just sync your application back to the most recent version on GitHub so that's why you have to disable auto sync so we're okay with that we'll disable auto sync for our rollback to work and you can see that it's progressing going through here and now we are back on five pods for our deployment and it's saying out of sync because we are on an older version of our application we're on the revision that had five replicas but remember that GitHub is currently set to have only two right so live on GitHub we have replica set to two so if we wanted to just go back to our current live version we could either just manually sync again or just turn on automatic syncing so I'll just go ahead and do that so we went ahead and did that uh and it looks like it's already going through and removing those old pods so that's pretty simple for our Helm application let's go in and deploy our customized application so I'm going to hit new app and then I'm going to go custom app and let's do Dev choose default I'm going to choose automatic here and then the repository name we're using the same Repository and then for the path you can see with our customized application we have a few different options here and it's just the difference between Helm and customize with customize you use overlays so I'm going to choose our Dev overlay for our Dev environment and then I'm going to choose the kubernetes cluster namespace of Dev which I know already exists but if it didn't I could make sure that this is enabled to automatically create it and then at the bottom here you can see that it's detected that it's a customized application and our options here is basically uh the name prefix name suffix this is just basically what it names some of the automatically generated resources like configuration Maps uh we don't need to set that though so we'll just hit create and now our application is automatically being created we don't have to hit sync because we set auto sync on and if we head in there you can see that it's already deployed three pods for our customized application so if we head on over and do K get all namespace Dev you can see we have five pods uh two of them are from the hell map three of them are from the customized application now I want to demonstrate why you would use a customized application over a helmet application so I'm actually going to make two different changes here I'm going to make one to my Helm environment and one to my customized environment so I'm gonna head on over here and under Helm web app let's change the custom header and it's important that we're changing the custom header because this is a configuration map item so I'm just going to change it to Dev environment of my Helm app and then hit commit and then I am going to go over to our custom application go to overlays go to Dev and then I'm going to go to this config properties and this is where the customize application is pulling the configuration properties and I'm going to change this to Welcome to the dev environment of the customized app and we'll hit commit and Argo CD is going to detect the changes for both these applications and it's going to update them both but only one of them is going to actually represent the changes and I'll show you why so just to verify that everything is happening in Argo CD I'm going to go to Argo CD and I'm going to go to Applications and I'm just going to refresh the apps and his hip refract no you need to select them and there you go you can see that the view has been refreshed so what happened here is very important to understand you can see that the custom app says it's healthy but it's out of sync and then the helm app says it's healthy but it's synced and there's actually a very good reason for this and it's actually a little bit difficult to explain I'm going to explain it the best that I can but basically when it comes to Helm versus customize when you make a change in Helm all it did was update this configuration map with the new values but you can see that the pods never restarted so the pods have not yet picked up the changes whereas in our customize application you can see that there's two configuration Maps it has the old configuration map and the new configuration map and all the pods are much newer you can see that they're the same age as the new configuration map now the reason why our customize application says it's out of sync is because this old resource still exists and according to Argo CD there's only one configuration map this is old stuff that needs to go away so in order to get rid of this old configuration map that is no longer required let's head on over to sync and then hit prune and then synchronize and this is going to get rid of all the resources that are no longer required and there you can see that it just went and deleted that old resource that was no longer required now if you want to enable this so Argo CD does it automatically on future updates just go to app details and enable pruning of resources and now whenever the customize application gets updated the new configuration map will get created and the old one will get removed now let's go on and head on over to our Helm application so back to our Helm application go into it now when we look at our Helm application we can see that there's only one configuration map here and if we go into it and have a look you can see that it actually picked up our changes however our pods have not restarted since we've made that change so they haven't picked up the change so there's actually two ways that we could fix this the first way which is not the correct way is you could just go here and actually on the deployment and you could restart the pods and it's basically going to create a new replication set bring up two new pods and they're gonna pull over the re-pull over the new configuration map and this will actually fix it hey guys future Brad here basically the concept that I was trying to articulate is that config map should be treated as immutable objects which means you shouldn't be updating them but you should be creating a new version of them instead now customize takes care of this for you with the concept of config map generators but when it comes to helm you need to take care of this yourself so the correct way of updating our application in our Helm chart repository would have been to go into the values.yaml file and not only update the configuration value but update the configuration map name as well and then this would have created a new configuration map and then we could have pruned the old configuration map just like we did with the customized application okay so now that you have a good understanding of how to use Argo CD use using the web GUI I'm going to show you the Argo CD CLI so the easiest way to get started with the Argo CD CLI is to do a brew install Argo CD once you have Argo CD installed the next thing you need to do is use Argo CD login to log into your Argo CD server so just make sure that you still have your Cube control port forward to the Argo CD service enabled and then run the Argo CD login command and then uh just localhost 8080 and uh certificate warning I'll just hit yes and put in admin and then I need to grab my password so I'm gonna paste it in here again if you need your password just run that earlier command I showed you on using Cube cuddle to pull the Argo CD initial admin password so you can see that we are logged in now if you want to see all the commands for Argo CD just hit Argo CD and then scroll up and then you can see all the different commands that you have the one that you're going to be using the most is the Argo CD app command so I'm going to run Argo CD app and here you can see all the different Argo CD app commands and they're all pretty self-explanatory but I'll go over the most important ones here so let's go ahead and just start running them so I'm just going to do a little bit of resizing so you guys can read this but it's Argo CD app list and you need to spell Argo CD correctly so we'll do that and here we go we can see our two different applications and it tells you everything you need to know about them so the application name which cluster it's on the namespace I this is the project so it's a good way to organize it we just had default and then like the synchronization status the health the sync policy so all pretty good informational stuff here now if we want to actually create an application using the Argo cdcli you can grab the command that I'm about to put in from my GitHub repository but it's just going to be the Argo CD app create command I'll paste it in here and just go over it so we're just creating the web app custom one we're pointing to our Repository I'm specifying the path and then the destination cluster and then for everything else it's just going to pick up the default values and you can see that it was created now if we do the Argo CD app list the status is how to sync the health is missing and the sync policy is none so basically we didn't specify a sync policy so it defaulted to nosync policy so let's go ahead and sync this application so we'll do the Argo CD app sync and then specify the name and you can see that it had some issues and it actually tells you what the issue was right here so it couldn't create it because the namespace prod is not found so we didn't specify that parameter to automatically create the namespace so let's just go ahead and create this namespace using Cube cuddle and then we'll try to sync again so namespace prod is now created re-run our sync command and there we go it looks like everything is up and healthy let's do the Argo CD app list and you can see that our prod application is now synced and if we do keep control get all namespace prod you can see that prod is up and running with four pods now let's go ahead and make a change to our application I'm just going to go here and uh let's go to overlays prod replicas and just change the replicas to let's say six replicas hit commit and now we have six replicas in our configuration but if we look here and do our Argo CD app list it actually hasn't detected the change yet so let's do it again and still not picking it up let's do it one more time because it does take up to 30 seconds and there we go okay so it's out of sync now if we wanted to actually have a look at what these changes were before we synced it we could do Argo CD app diff and then put in the name and it gives us a diff exactly what the change is so we know that the changes replicas went from four to six so it's a pretty safe change if you wanted to check this in the GUI you would actually just go in and go into your application and then go to app diff and then compact View and it would tell you the same through the web console as well so pretty safe change let's go ahead and sync that using the CLI so I'll just do Argo CD app sync and sync it up and K get all namespace prod and you can see the new pods came online now if you wanted to check the history of this deployment you would just do Argo CD app history and then throw in the name and there you go we have the two we have the original deployment and then the newest now if we wanted to roll back here just do Argo CD app roll back and then you would specify the actual ID so we're currently on id1 so if we wanted to roll back to the original we would just say roll back to zero and there you go it should be back on four pods if we do Cube cuddle get pods namespace prod you can see that we have four running pods and two terminating so the CLI is pretty easy to use now I want to show just a few more commands before we get going here so if you wanted to get information about the app we'll just do Argo CD app get and specify the name tells us everything about it if you wanted to get the actual logs instead of get you would put in the logs this and you can see that this shows you the logs for our application so we have four pods and they haven't got any traffic yet so it's basically just the startup message for four different pods and uh if you wanted to actually change any parameters of Argo CD using CLI you would use the Argo CD app set command and then it gives you a list of all the different configuration items that you may want to set now the last thing I'll show with the Argo cdcli is I'll actually just delete our application so I'll go Argo CD app delete and then hit yes and it does take a minute or two to actually sync this change and actually delete all the resources uh but if we do it again you can see that the application is now gone all right so that's it for the lab tutorial on Argo CD I hope you enjoyed the lab if you haven't already check out my videos on Helm which is going to teach you everything you need to know for getting started with Helm charts and if you're interested in other devops related topics go ahead and check out the other videos on my channel thanks again for watching and I'll see you guys in the next one

Channel: DevOps Journey

Views: 54,308

Keywords: devops, devops tutorial, devops training, devops how to

Id: JLrR9RV9AFA

Length: 33min 41sec (2021 seconds)

Published: Wed Dec 21 2022