OCB: GitOps in OpenShift using Helm and ArgoCD

[Music] hello everyone and welcome to another openshift commons we have a great show for you today i'm really excited about well i'm excited about all of them but today we have christian hernandez he is get ops rockstar right openshift if you haven't watched the get ops happy hour please check that out that's on thursdays and he'll plug it later we also have andrew block distinguished architect and openshift guru pretty much everything and then cmak is also joining us today and he is um an openshift product manager and he covers all the stuff that you are interested in right get pipelines a bunch of stuff so again it's an amazing group we have today and we are going to kick it off with this get offs and open shift with argo cd and home and christian please take it away yeah so uh thank you very much again uh my name is uh christian hernandez um technical marketing manager at red hat and overall git ops enthusiast right and so what i'm going to do is i'm just going to give a brief overview of get ops and argo city leaving plenty of wiggle room for any questions or any comments that may come up and um and then i'll hand it over to uh andrew who is um like um like what was said a uh a a general um uh guru in terms of uh all things open shift uh including helm so holy claw you're thinking of polyglot polyglot yeah exactly um so it's it's one of the things that's i kind of just start with is what is what is get ops right and it's really by definition get ops is when the entire infrastructure your application deployment everything is fully um saved and installed represented in a git repository right so generically that's that's that's what's uh what git ops is right so everything in your having to do with your environment is on git and so um i usually just like to leave it at that leave it kind of uh enough breathing room for there because uh get ops is a it's an ever-changing ever-evolving thing and it's really is a journey right so i um you know it's you know i used to be in sales right and we we always talk about like journeys and you know it's we that that term kind of gets overused a lot but this is literally i actually truly mean a get ops journey right um and it's it's really a evolution of what we brought with like the idea of devops and agile and um and actually chris short as as you may know the uh the host of openshift.tv in 2018 literally said get ops is a holy grail of devops right so it's really a um really weird you know the idea of devops practices where we want to get to get ops is really that end goal right where everything is um described in a git repository and everyone can get them involved so um so really like why get us right so it's like you know you hear this buzzword it's like well why why would i want okay why would i want get ups right and so um these are some of the challenges that get ops addresses right um i'll call a call out a few of these things like it takes weeks or even months to get to get me an environment um you know my application behaves differently in production i didn't test these are some of the things that i that i in in my life um have heard personally um and things like production deployments have very low success rates so if when you take a look at some of these uh things that get ups addresses these are actually some of the things that devops um addresses right so it's like oh what's really what what's what's the difference right between like get ops devops like what's how are they all tied together people a lot of the times people use these um you know um if it fits right in right they'll say devops and get ups you know especially us that that are really into get ups uh you know um talk about devops because while devops is actually a culture right um get ops is actually that culture in practice right so it's it's really um um as as again as chris short put it i guess the best which is why i always quote him any time i present get ops is that um uh get ups is literally the holy grail right it's like i have a git repo that everyone can contribute to and it manages uh my infrastructure um anytime via pull request right so um so some of the benefits right you get it is that since it's all in get all change or auditable meaning like you have this convenient trail of all the changes that you've made in your environment right anything as simple as uh someone scaled this uh the cluster from three nodes to four nodes that's in get someone deployed a new version of application that's get that's in get so every all the um benefits you get from git is uh you you know by extension you get it in get offs right so all changes are auditable um you get that standard wolf roll forward roll backwards and bit of a embedded um in events of a failure so you have the ability to you know just i can get just like in your code repository if you roll out a change and that change breaks something you can always roll back to a previous git commit right or get tagged um disaster recovery is is you know i'll i'll put it simply reapply the current state of the manifest meaning you just reapply you know you you lose a cluster you just reapply what you have there um in your last known good state and then you have the cluster up and running there was a there was a good article actually um i believe it was it was written actually by weaveworks who talked about a customer that uh essentially they um they restored their cluster in about 15 minutes right so they were went from down to fully operational back in 15 minutes and most of that time was um getting you know storage backups up and running so the experience is really pushes and pull requests right so you make a pull request anytime you want to make a change that change can come from anywhere right um there's obviously release skates in place but the idea is the um you know if i as a administrator can make a pull request to the deployment code of the application because i want it to behave differently and vice versa right so it's really um you know you you have this whole convenience way of working together inside of git right so it's we've um get already has that the um uh the it has the the practice of us working together built in and we just take advantage so um and get ops really is for everyone right so a lot of the times um people think that git ops is really like a developer tool and for a lot of time it is right you're you're literally deploying code um using this practice right and i'll go over in a bit a little bit about things like um the sync tools but in actuality it's really for everyone right it's really it's a devops tool right it's devops in practice so you can't have devops without the ops either so it's really for developers for operations for sre teams for um it's really uh it's really not as geared specifically towards any any core user group so um and so they're so open shift and get ops right so um i always i always make the the comparison right and i think it's gonna be because my tagline is like it's like peanut butter and chocolate right so it's um you know get ops is a declarative method to um to declare what's in your cluster and openshift is a declarative environment right it's built on kubernetes um and um and so you know you have a declarative way of deploying your application in your infrastructure stack and now you have a a method a platform that does that right so it kind of just like fits together right so um all the declarations are in yaml files right so it's visually stored you can have openshift uh suck that in and have it either modify operators or actually just do simple deployments like if you have just like a deployment um a simple deployment service route sort of thing um it's all stored in git right so that's it's a it's a perfectly match so some of the get off principles so now this this is the part where i always always talk about how like this is a journey this is where we are um this is where we are like now right this is kind of kind of the the idea that's where we are currently of like how to use get ops and openshift right so um i always recommend separate application source code from your manifest yaml right so um in the beginning i have always i always had the application source code and the yaml uh manifest deployment in um in the same repo actually um it's a lot better if you maintain those separately right so they have they have um source code commits are independent from deployment commits so um all your deployment manifests are in standard kubernetes manifests right um everyone says that there's a uh you know i'm a yaml engineer now it doesn't have to be ammo right it could be json as well but um all those manifests are standard kubernetes manifests um stored and get right so um one of the big things is that what you want to do is you want to avoid duplication of yaml right across environments and i'll go over i'll go over that in a little bit um how that looks like but um and manifest should be applied with standard openshift indicates tooling right so it there's really nothing new here that you haven't really been doing if you've been working with kubernetes um or or openshift there there there's not really any new uh tools right per se right there's there's a couple new tools but um it really is just kind of like a standard uh open shift in kate's tooling here so um so really like i said before your your day two looks looks really a lot like um um like what you've been doing normally right for for the developers out there it's really just kind of like what you've always been doing right you've been doing a pull request um you know you merge the pull requests and you run your pipeline and it just you know it just automatically happens right so uh for the operation guys i mean for me from an operations background this is a little change um but it's it's um it's really something that's been there for a long time entire tested and true right so for from an operations guy from that when you hear that that kind of just calms my nerves okay it's tired tested true people have been doing it for a long long time for years is this whole um process of get um pull requests and merges right and automation so um so all the changes are triggered from get um i remember one day this was a long long time ago i saw um a talk by kelsey kelsey hightower right some of you may know him um he this is really really early on kubernetes right this is like kubernetes alpha and he was talking about like kubernetes is how you design a system when i take your ssh keys away right um get now uh get ops now not only am i taking your ssh keys away i'm taking away your cube ct all the way right so it's it's everything is driven from git right and that's that's the whole that's the whole idea so so there's um um one of the one of the things that get ops uses right and i think one of the things that's uh become very popular is a syncing tool right so um uh a sync tool is really just um it's it's it's built on native kubernetes uh primitives right it's it's the whole crd and you know custom resource custom resource definition um that's built in kubernetes right the way to extend the kubernetes api is how these sync tools are um are built upon right so some of the things that um a sync tool would do right uh the example on the right here as you see is argo cd but um you automatically detect drift and um and you correct it right so it's it's built on that um control loop that uh that's just built natively in kubernetes right it'll see desired state and it'll see current state and it'll try to reconcile that right and so some of the popular uh get ops tools for syncing is like things like argo cd uh acm ansible flux cd uh those are kind of just some of the big ones that bubble up um when you're looking for tools that do the syncing right so um it's really um nothing new in the kubernetes um and new i mean that relative to kubernetes right is basically you're taking the concept of crds and crs and we built a tool around that to make sure their cluster is um completely um in sync right so once you get like the cr implant crd in place right once you get your sync tool there's a way to uh represent your entire stack in um in a manifest right so for example the example on the right here shows an argo cd application is what they call an application and you basically tell it things like what server i want to deploy it on uh what project i want to deploy it to what you know what the what the repo url what the path is what the uh the branch or tag name is if i want it automated right do i want to prune anything that's not in that name space all right so you can kind of just declare declaratively say i have an application i want this to be deployed in this cluster and i want you to watch this repo right um and the entire stack right is in isn't get right all name spaces deployments ingress definition secrets right um operator manifest um and so usually the the sync tool has a way of defining that right and this is kind of right here again the example here is with uh argo cd so so the synchronization is this is a basic workflow right um this is not like the end result workflow but this is kind of just conceptually so you get uh get an idea the real workflow is a little bit more complex than this but the idea is from a 10 million foot view is you make a change in get right either someone merges a pull request so you have some sort of automation that automatically approves certain pull requests um and merges it uh the the sync tool will either be either via polling or a push event or whatever or in case like if you're using a sync tool like argo cd that's hap happens in the control loop automatically well then check the status right it'll check to see okay hey um the declared state says one thing and the um the the current states is something else so i'm going to go ahead and synchronize i'm going to reconcile those two um so it'll change anything it needs to change um and then it will then you know do that in cluster so so one of the things um one of the uh one of the issues right so um there's there's certain challenges that come with get offs right um and there's like you know again i could do you know a whole hour a whole couple hours about this um but really is to avoid uh yellow duplication right so that's like one of the big things right so i i i can deploy these across multiple environments but how do i how do i manage this right um without you know i i have like 10 environments how do i manage this without having 10 versions of the same yam all right so um you know that's one of the um one of the things that you have to look out for and um one of the things is did you use templating tools right so there's all kinds of templating tools um where you take a a core yaml file and then you templatize that um right so you have one core and then you may be changing a few um um pinching a few things in that yaml file right so some of the popular templating tools are really customized and and helm so now um now that we uh have gotten to this part right is to templating tools with uh with helm i'm gonna go ahead and pass it over to uh to andrew talk about a little bit about helm awesome thanks a lot christian let me go ahead and share my screen we can go from there hopefully everyone can see the screen so for those of you who don't know helm is a package manager for kubernetes applications so those of you who are familiar with typical package managers on your operating system dnf yum apt-get brew which is kind of the unofficial for mac os helen has become the de facto packaging mechanism for packaging different components in a kubernetes application into getting it deployed to a kubernetes environment hell movie consists of three primary pieces first one is a chart a chart really is just a set of related kubernetes manifests a typical application can consist of one or more different types of kubernetes manifest everything from a deployment a service maybe a config map anything that can be deployed to kubernetes environment and encapsulated into it into a single atomic unit goes into a chart now once you create these charts where do you want to store them make them more distributable those go into a chart repository very much like a an image repository like quay for example and finally a release a release is when you want to install a chart from a repository potentially each instantiation that specific instance that's deployed to a kubernetes environment is called a release so how does helm work really it's just a combination of multiple components all being orchestrated through a command line tool so you have your chart and associated templates values which are the configuration inputs so think of it as templates are their dynamic abilities to customize what your kubernetes manifest may look like so in certain cases you may want to customize the image location the types of resources that you want to apply to your application maybe a liveness or readiness probe along with other components those get combined with values those are the injected the injected inputs for customizing those specific templates so in certain cases i want to use my dev image or my prod image depending on what environment i have using the helm command line tool we'll go ahead instantiate the two of those together and put them into a release that then gets installed to a kubernetes environment so here's an example of what a helm template does look like as you can see a lot of the bracketed uh fields those are the components that will be dynamically templatized and replaced by the values or other types of injection instantiated injection at runtime so for those of you who are familiar with the helm um context uh values.build.url so when you go in and specify that you want to build from a certain uri you either provide that as a default value that's provided potentially within your helm chart or you can override that value at runtime and for an example a value file looks very similar to what it what it is here on the left so basically build.uri is this github url for some quick starts that then gets combined at runtime using the helm install command and then you can specify a specific file so you do helm install you give it the name of the release you want to create you give it the location of the chart whether it be from a repository or a local directory on your physical machine and you specify optionally a set of values files or value of inputs and those go ahead and create the different type of resources that will be installed to your openshift in kubernetes environment now this is where very much a christian said the peanut butter and the chocolate start coming together because we can go ahead and extend the capabilities that christian mentioned earlier regarding using git ops argo cd in this reconciler loop and integrate it with helm you can add charts that are stored in git repositories or helm repositories so you can use many of the same principles that you've already leveraged as well as including overrides for different chart values whether they be complete files themselves or individual parameters and we'll walk through that as part of the demonstration today and all of this can be managed what via the the argo cd user interface as well as the cli okay demo time my favorite time of the day uh what we're going to show today is a git ops approach for managing applications as helm charts we're going to leverage a the quarkus red hat helmet chart which is in alpha you know we're still curating it to be able to deploy a quarkus based application to an openshift environment and we're going to explicitly demonstrate how to integrate argo cd to really show you how git ops can be used to manage not only your open jet cluster but also using helm sound good awesome i know i'm excited yeah all right give me one second i need to unshare my screen for one second while i go find the super secret password the cluster this is what i've been waiting for so come back we'll come back on the screen sorry what was the password uh uh one two three four the same as my luggage there you go so in the background i've actually deployed an argo cd environment oh maybe i'm maybe i waited too long go back here go ahead to arco cd and we'll go ahead and log back in with the openshift integration and now we have our argo cd environment so those of you in the chat who here has never used argo cd we're going to kind of walk through how to use argo cd together and how to add a phone chart to it and then have it managed by get outs so just to browse around for those of you who are unfamiliar with it this is the home screen for argo cd where you can define a set of different applications and christian please feel free to interrupt me at being the all master of get offs in case you have any areas that you want to inject yourself into for sure all right yeah all right so inside the configuration page we have a set of repositories that we can set up certificates are important especially when working in large you know typical organizations that might have self-signed or industry um provided certificates you can add those so that your uh get your github server argo cd can trust those destinations projects allow you to go ahead and configure different types of permissioning so let's say you want to have certain teams get access to perform certain actions in certain openshift projects and name spaces you can configure it there as well as customizing the type of resources that you want to have be deployed so let's say you don't want to give them access to create custom resource definitions or other specific type of resources you can you can create a white list and blacklist items as well but in in particular i actually cheated here because it's i actually went ahead and added a the hell the get ops helm quarkus application repository which will allow us to basically kind of get really fast into this demo because we have a short amount of time so this is our sample application which is basically a hello world for quarkus quarkus is a lightweight java framework super supersonic sub-atomic java for spinning up a java application very quickly very little runtime very similar if you're familiar with spring boot even faster but using that microservices architecture for developing java applications in the cloud actually this would be the application and it is basically hello world so we're going to we're going to kind of demonstrate that in argo cd so to add a helm chart to argo cd very much like you would any other git ops based application we'll go ahead and click on create we'll give it a name and we'll give it the name of the repository which is basically get off helm quarkus and of course it took that go ahead and there we go let's go ahead and put the project which is default the uh the default project comes by default no pun intended with your kubernetes with your argo cd based application now christian do you want to talk about sync policy yeah so there is a um the sync policy does uh you can choose one or two things right there's a manual um manual sync policy meaning that it'll just create the definition right it'll just basically create the instance in inargo but not do anything right um yeah it'll wait for you to manually do the syncing each time uh it happens um either via an api call or whether you actually click the button that says sync um or automatic right so you can do an automatic sync policy meaning it'll it'll continuously monitor that repository and it'll um automatically apply changes as they happen so i'm gonna i'm gonna go ahead and try to provide uh perform the automatic sync policy so you have here also the the idea here is i'd like to call out real quick is the prune resources right so the prune resources meaning that if it finds something um on in in the name space you're uh deploying to um that's not in the repo it'll delete it right so it'll uh you have the um uh you have the choice of either keeping things it doesn't know about or deleting things it doesn't know about so that's that's a very important thing to call out i also told it to go ahead and auto create a namespace so if i wanna if i wanna go ahead and deploy to a specific namespace it doesn't exist on the cluster go ahead and create that as well so i get a chance to pick from my configured repositories i said i want to use the um get ops helm quarkus application repository and that's not the one i actually wanted to deploy which is kind of strange let's double check that really fast this is basically my source control okay cool what we're going to do here is we're going to specify where is uh where is my helm chart and my helm chart should be located at let's go ahead and double check that here which is hmm don't you love live demos when things actually go exactly yeah it'll always yeah so we want to specify where earlier yeah we want to specify where the helm chart happens to be located so the helm chart is located here in the redhead developer organization so we'll go here and demonstrate that and we specify we want the corpus chart we want to send it to the [Music] local cluster which is basically you know if you're familiar with kubernetes is kubernetes.default.svc which is the connection to the kubernetes api in the local environment and we want to send it to basically the same name of the of the application which is get ops helm quercus and we got a chance to override these value files now if you're familiar with with um helm you'll mention you'll notice that there are a number of values everything from at least from this chart everything from where your image is located where the if you're performing a build you can go in and build your application you can on the deployment side you can specify all the different parameters that you want to have for your application so what we can do is we can either provide a file itself or we can override certain values and i am and i'm going to go ahead and actually override a few values number one we already have an image deployed it's already out there in quite a i o we're just going to go ahead and leverage it so i'm going to turn builds to false i'm going to scroll down and skip all the build stuff don't worry about that we're going to go down all the way to the bottom and we're going to specify the image name and the image tag and once again i'm going to cheat here just because like a good cooking show just going to go ahead and uh go down and find the values that i want to leverage and if you're familiar with customize i am using customize here which we'll show a little bit later on uh on how to automate this entire process so christian do you want to kind of talk about customize for a second while i go ahead and finish this up yeah so customize is um another um a way to template um kubernetes resources right so like the idea is that you have a single um deployment manifest is just take a simple example of a deployment manifest um and you know you you want to change certain things depending on which environment it's on right so for example um the the most common use case is the image right so the image that you deploy in development is different than um deploying in production the only difference is the image but the manifest is the exact same so what you can do with customizing you say hey when you deploy to this cluster use this image when you deploy to the other cluster deploy the other image right and it's done using json patching or you know any any other there's there's a lot of ways to patch a customize and you can do again another hour and just customize but that's the that's the idea of customize so all we had to do here was we modified two override values we modified the image name basically just pointing to an image out there in quita i o and we modified the build dot enabled to false and we're going to go ahead and click on create and argo cd is going to create this application if you notice it is deploying a set of resources it's going to set up a service a deployment as well as a replica set and a pod this is just an instantiation of our chart now you can one of the benefits is you can play with this chart right now i'm using the default chart and if you go over to the developer perspective in openshift you'll find this chart and i don't need to see that so if you go to add this is brand new um let's go ahead and just pick on this just to have it there's an entire argo there's an entire helm chart section of the opengl developer perspective to add you can scroll down all the way to the bottom and you'll see there's a brand new helm chart this is the same one that i'm using in this demo right now so you can go ahead and give it a try in your environment obviously still alpha so just it's still you know work in progress as you see helen or argo cd was able to synchronize this application and we have a route that we that was created so we can access it externally argo cd makes it really easy for you to query different resources on the cluster itself all from a single interface very much like the opengl web console we scroll all the way to the bottom we can then see the url of the application go ahead copy it open up a brand new tab and you'll see we have oh github's github loves helm just like that it's great but this doesn't really it gets us there we got we got you know deployed we did we showcased how and a helm chair can go ahead and be used with argo cd but we really didn't really emphasize the get ops based approach i know christian's like this is nice but we can do better right that's right that's right we can so we can we can do we have the technology we can do we have the technology so inside this example application on the main branch is the application itself which is basically you know hello world quarkus basics you know if you want to go ahead and deploy the application and build it yourself on your local machine you can do that but there's a get ops branch that contains all the different manifests that you can use to not only demonstrate or spin up this demo in your environment but we're going to leverage it to be able to manage our argosy manifest right now so let's go ahead and basically go back to our applications page we have one application we'll just switch over to the linear view and we're going to use customize to basically stand up state environment sound good let's do it all right so on here i'm going to go ahead and basically i have a set of manifests and i have this bootstrap application a bootstrap application in is basically what they call in the argo cd world is an app of apps basically it's an app that can deploy other apps so i'm going to basically run use customize locally to create an app of apps that will deploy and basically manage the application basically the one that we created previously but it's also going to create another application that will deploy the same application but slightly different for the with different values for the production environment that will allow us to does it with with helm it makes it very easy to change some of the small parameters that really drive the configuration of your application let's go ahead and let's spin that up so i'm going to do oc um oc apply dash k will basically instead allow us to use customized instantiation argo cd face and it's going to go ahead and templatize all those customization resources and as you see here we have two new applications that were created one is this bootstrap application that basically includes two app of apps one would be the application that we created previously the get ops helm quarkx app but we have this brand new one get ops helm focus prod that represents our production application we're using the same charts we're just providing different values and we'll walk through that right now so if we click on that sorry go click on that you'll see this is basically very similar everything's been synced everything's all green everything's working great we go look at the application details and we scroll over to parameters you'll see we actually have a different parameter here under environment name under deploy.m.name we have a new environment variable called environment and a value called prod our application will go ahead and look for that environment variable and change how the application reacts so if you recall in our development environment or our non-production environment we have a little blue background let's go ahead and look at the route that's exposed via this production application go here to the route wait for the manifest to load all the way to the bottom we have a different url representing our production environment we'll go ahead and open a new tab you'll see we have our same application but we have a different background that represents our production application so as you saw really easy for us to manage our get up get our home base installation and configuration all through our go cd have it roll out and have it all be managed in a get out based approach christian anything that you want to add i just want to add one little quick thing you you mentioned and i think it's worth uh calling out as you mentioned you have an application called an app an app of apps right so this is uh something that um that a lot of us do right in the in the get ops world is we do an app of apps meaning it's uh we try to solve the chicken egg problem right it's like how do i deploy my application automatically without manually deploying it right so there's this concept of an application that does nothing but deploy your application right so it's kind of um uh we try to solve that chicken egg problem there with the apple apps i'd like to call it call that put up which is something i do a lot right is the app of apps as well so this really is the end of the demo uh i know i'm interested in your feedback and especially the feedback of others here on the call karina cmac you know i'm going to probably turn it over to sir to not see karina in front of me uh karina do you have any uh areas that you want to start addressing as we start moving towards the panel discussion well we did have some questions in the chat so i wanted to make sure that we get those answered and cmac has been awesome in answering those so let's just um bring that out so first we have how are data migrations handled in the event of a rollback with get ops see mac do you want to dive into that one sure actually to create it for like multiple people answering that but the like generally i think as a as a high level like conceptually you shouldn't see git ups as something that like addresses all the problems around deployment it focuses really on on a single thing and solve that really really well it focuses on it driven workflows for everything not just for your development when you're developing code but also driving your operation that's the single problem that is solved but as a consequence of that you get a lot of visibility and auditability and traceability because of the git provider i think that's what it focuses on when it comes particularly to rollback and switching between versions so it doesn't really itself do anything for your data automatically it so relies on the and the application teams and the operators to be aware of their their architectures and the way that they use argo cd or they use the github process to be aware of the changes in data and work that into their process that said argo cd gives you a couple of tools to to be able to work with it for example it was mentioned in a chat with christian perhaps or should like that mention about the the hooks there are books in argos city that you can tell and tell say saturate that before you sing perform these operations for example after you sing do this other operation which could be used perhaps for backing up their schema for example restoring and things like that and there are also a lot of discussions around uh like regardless of what kind of process this this is not a question related to github truly is related to any type of deployment how do we manage role bike regardless of how you perform the rollback and when it comes to data so there are a lot of conversations and and guidelines also on the application architecture how the application itself could be more resilient for changing to to the database schema for example so that from one version to other it it doesn't immediately break if their the schema doesn't match the expectation or the application also of the schema for the database for example is also lifecycle managed so that the multiple schemas were are supported at the same time for a single version of the application and so to summarize it really it doesn't give you the silver bullet for or how do you do with your data when you're rolling back but it gives you a little bit of more flexibility if you want and and still responsibilities on the on the team itself and the operators to use those flexibility they'll use those tools and plan for how how to manage the data between changes and version things um yeah yeah i just like to just kind of add a little bit uh to what cmc was saying um is just there's the tools are out there to do the things that you need to do right source hooks uh there's actually a good a good demo by intuit that does um that uses hooks to put up a um if um under construction page while they do some maintenance and once the maintenance finishes it deletes the um that's uh that page right by kind of just doing kind of showing the idea of a b deployment and schema changes and things like that so it's it's really heavily dependent on the process and the tools that you've uh and how you leverage the tools to do that process so we also had other questions in the chat um let me find the next one i love that we have a lot of chat going on all right i guess for h a purpose is it better to have argo cd as an external cluster from openshift i don't know who wants to take this on cmx i can talk about a little bit so if you look at the role of argo cd in this process it is really in charge of your deployment to make sure what you have described in your git repo it is what you are seeing on your cluster so what happens if our cd is down let's say you completely remove it undeployed all together and the only thing that happens is that uh you you cannot do any new deployments through this kiddos process so no new releases will be rolled out right i just want to put in perspective the the criticality of the role of argo cd for the application itself the applications that are deployed and running and nothing is really happening to them which is if you think about it and not using github's process it is essentially what you're doing today right you deploy the application and you are done for the day till the next time you want to deploy your application in between there is nothing else happening around deployment in between two releases to your production uh it is as if in the github sport your your github's engine is non-existing between those two releases so it is like from customers perspective from a lot of our customers that i work with and it it's not as it hasn't been as critical as buying into the overhead of running uh like thinking about ha for argo cd or in multiple instances or having separate management clusters for argo cd that adds all of this have they at the for the high availability that you gain there are more management costs on operational costs to to gain that and we haven't seen many of those instances but if that is needed is required so that is definitely one approach to externalize it from from the cluster that is uh that your application is running on uh there are other approaches uh around uh hay of the the controllers itself uh to be discussed are there ways to to achieve that but um i haven't seen it very often i don't know if christian or or should we can the call there are others that have seen more use cases around this customers most of my customers you know are less concerned about that aspect because they find the benefits that come with get ops and argo cd outweigh the risks because this one this is actually providing more uptime and availability than what they had previously and sam i hope that answered your question i'm learning stuff too about argo cd all right so where and how should passwords for different environments be stored i think shabook answered this andrew yeah you're welcome too go ahead christian yeah well there's really two schools of thought right in terms of just secrets secrets in general right um is uh either use something like sealed secrets right where you're encrypting um encrypting the secret before you put it in get um or you use something like uh like vault right you use some sort of secret management management system right they both have the pros and cons um and there's still kind of discussion going on in the community in terms of what is actually get ops using vault is actually get ops is it we don't know um or is sealed secret's still the way to go so there's there's there's two methods of doing it right i don't think either method is right or wrong um it's really what it works for you i like using sealed secrets um which is because i'm more of a get ups you know everything and get right i'm trying to push myself towards um everything and get as much as i can but yeah really secret management um and storing secrets uh encryption really is is your friend there um especially if you're really just putting secrets in your git repository in your environment so first of all you have your own personal get repo inside the environment right so like they're it's behind a firewall behind you know multiple layers of security so um you're just adding one more layer of the encryption on top of that so you want to add something no i think we occurred i think we've answered and we've covered everything on it thank you secrets all right and there is a request for the link to the intuit demo if anybody do you have that handy intuitive yeah i have it handy i i forgot to um i put it in in the twitch chat i forgot to put it here i'll i'll put it in on the awesome thank you blue jeans here okay let's see um can you share the repo with the customized home charts that you were deploying from another request for you andrew i can i'll put that in the chat in a second and let's see all right i'm trying to scroll through all the the chats which is awesome hey carlos well argo cd still apply or more like flex cd will fit here yeah i think the the question by carlos was something around whether we can use githubs for clustered state and i answered that i think yes the answer is yes it's very common to maintain cluster configuration on kit but of course to a large extent as long as you can describe it using manifests that's how you would do it um so for that you could do it with argo cd or flux both both work equally with it nice and let's see because carlos also asked you guys covered get ops for keeping the app state but what about keeping the state of the cluster also in git so that that so that i know christian has talked about that and showed it on his get ops hour with chris short a lot so definitely take a look at that if you haven't on his happy hour i believe you're doing one on storage this week right yeah this week the thursday shameless plug uh get off sappy hour we're talking about storage and get ups so on this thursday at 3 p.m uh eastern time so all right eastern that's awesome all right um let's see and were you using a helm chart stored as files and git or a helm chart released in a helm repo so i did answer this one i was using a get a get based repository but one of the benefits of the red home charts they are stored as releases themselves or i did as a chart repository itself so i could have easily gone ahead and used that option in our go i just chose to use get nice thanks and uh all right manifest files should be stored in a separate repo apart from application code repo should manifest files also be stored separate to the application configuration files which differs per environment who wants to so i definitely would keep them separate um you could it really depends at least putting out a different branch is key so these have a different release cycle but i've i've seen i've seen from my customers they do almost every single type you could think of um there is a long conversation of whether you should use a single flat repository with different folders or different branches so that's that's certainly a big question and one for discussion in the whole get off space yeah yeah that's that's definitely something that has i don't think technically has been solved yet but i am a fan of different repos for different things because they have different life cycles and lcs mono repo are separate repose i think you already answered that right definitely separate i typically do it separate but just for demonstration purposes i threw it all into one for this example could you please double click on configuring event triggers event triggers sorry that activate your get ops pipelines for example when someone changes an application deployment descriptor yaml and checks it into a github repo what's the underlying tooling pipeline tooling so what you can do is it really depends you can use web hooks in your git tool to be able to invoke like an argo cd sync or argo cd will just natively be able to pull the change on a regular basis it depends on how fast you want the chain to be applied and rolled out nice all right that's it for the questions in the chat it's awesome all right so we have a few more minutes if anybody has any last minute questions but so given all the questions that have been asked and between all of you i mean are there any other things that you want people to take away from this discussion today because i think we have a lot of follow-on uh freezos and demos and everything after this one deeper dive so all right sam says maybe spoiled questions so what is the state of acm versus argo cd i don't think that's a versus uh see mac do you want to take that one uh yes sure so it is exactly like you said a partner so there are two tools that sit really well together if you want to apply git ups across uh all of your infrastructure right so we say infrastructure has code practices uh we when we talk about argo cd and take time on a ci cd the lot immediately lands on the application side and we with a little bit of touch of infrastructure because kubernetes is a declarative platform and openshift really takes it to the extreme with being able to configure everything through yaml that you put in git repo but it doesn't go really further lower than that so if i want to provision a cluster we we usually don't talk about that how do i go from nothing to a cluster on azure and then rule out my application to it right or if i want to also enforce that once the cluster is up on azure there are certain um operators installment or the way around there's some certain operators are not installing it there are enforcement of policies on it so that's where ac and that's the power that acn brings to to the game and it could be the combination of argo cd that it expands the git ups store your github's capabilities beyond just the open shift infrastructure and all the layers on top and it pushes all the way down to cluster provisioning and policy governance and aspect like that and in our cd it's in fact going to be a component within acn as well that that drives the githubs process there and really marries well to those provisioning capables of acm and policy part of it so this is something that you would see uh rolled out gradually over the next six months in um as well and we have another question so with multiple repos comes the issue of versioning app version config version manifest version how do we handle versioning will each of these get their own version numbers i don't know who i would say oh definitely you want you want you would definitely want to make because just think about it you may have your application have a different lifecycle in your configuration your application may be static for years but your database password or configurations may change let's say you get a brand new image repository location your application may never change but the configuration will so that lifecycle should be managed separately great question all right well we have two minutes to go um so freddie i know you dropped in a link there do you have a question about it or okay christian already answered yeah yeah do nope can you explain to the people who can't see yeah so yeah the people who can't uh that's watching the recording they're asking about the argo flux join forces that was an idea they had um a while back and they decided to go separate ways right so um they decided to they had different goals so they decided to work on um a different approach to uh to that goal so i can quickly activate in general what that means for the community and customers in the industry um so we have a working group where we are all participating together to ensure that the basic get ops principles the best practices we should all have general agreement on that so respect to which tool you use your paradigm shouldn't be shifted that should still be similar the typical kidops principles or the devops principles that we're talking about thank you all right so omar thanks for the um this next question all right so promotion from dev to prod for example and approval gates best practices would somebody like to talk about best practices for permitting yeah that's part of the ci process really more than anything else um is the it's uh you know argo cd is is just does the cd aspect of it the ci process of approval gates and um going from dev to prod that's all done in the ci process right so there's there's been a lot so jenkins did a really good um uh good job of like globbing them together that's why it's ci cd right but really now that we're separating the responsibilities is your ci process does a lot of that um that gating and um that release process and the um the sync tool in this case argo cd is only is only responsible for actually doing the change that it was told to do so um the approval gates will definitely just still be in your normal ci process um the cd process that's that's that's further downstream thank you all right i think that's um we definitely have a lot of follow-up stuff and more sessions i'm loving this um so we are out of time though and thank you so much christian cmac andrew for you know presentation and demo and the great conversation all the q a lots of great chat so thanks again and for everybody else thanks for joining us and all your questions and we will see you soon so thanks again for joining us in this openshift commons thanks everyone thank you [Music] you

Channel: OpenShift

Views: 1,004

Rating: 4.8000002 out of 5

Keywords: OpenShift, Console, Customization, Red Hat

Id: NW6inU_KGsk

Length: 63min 2sec (3782 seconds)

Published: Thu Jan 07 2021