Red Hat OpenShift GitOps - OpenShift Commons Gathering 2022 02 09, 15 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Path to GitOps - Christian Hernandez (Red Hat) OpenShift Commons Gathering 2022

Description

OpenShift Commons Gathering 2022

Path to GitOps
Speaker: Christian Hernandez (Red Hat)

Full Agenda:
https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_on_GitOps.html
Learn more at OpenShift Commons https://commons.openshift.org

A

My name's christian hernandez, uh senior, principal technical marketing manager- and I always say that's like the longest um title I think about everyone as in anyone I meet, but I'm really um I'm also the get ops advocate here at red hat and um I'm gonna be um talking to you about how to get started with get ops right, and so this is kind of a question that I know I get a lot. I know um a lot of other people in the open, getups working group get this as well a lot of people.

A

You know we had open get. Ups, um sorry get ups con here in north america kubecon um and we got that question asked a lot so I'm gonna be talking about. um You know basically how to get there right. You know you, you want like a a uh a path on how to get to get offs. um So first, let's talk a little bit about what is get ops in general right.

A

Let's, let's lay the the lay of the land, I'm not going to go into it too deep, I'm pretty sure the other presenters have a lot with respect to what is get ups. So I'm going to be talking high level here, but just to kind of set the stage. um I always love using this quote because I think it's spot-on right. So chris short, um who is a cncf ambassador um via the new stack podcast right and that's the episode there.

A

So you can actually hear him say this, but he said that in 2018 he said get ops is a holy grail of devops, and um you know I I love this quote, because I not only think it's it's like a spot on observation, but it's also indicative of how devops has evolved into like to the forefront of of of how to manage a system and the software delivery uh system um and and and the actual systems that manage that software as well right.

A

So um devops was here before cloud native and so um devops also had to evolve right, as, as we got into the you know, as kubernetes hit the hit the scene and cloud native architecture hit the scene. um You know people were doing automation before then. um You know with with various things, and you know devops, since the practice had to evolve.

A

um You know get ops is the way the um that devops had to evolve right and so, um as as I was saying before, get ups isn't necessarily anything new um get ups at as a practice looks very similar, devops right and I keep going back to devops because um get ops is, is devops. If you, if you, you know drill down to it, and you really think about it, it's really how how it's, how devops operates a cloud native uh ecosystem? Really right, and so it's essentially it's like.

A

Okay, we have devops, we have the devops practices, we had things in the past like like puppet, and um uh you know terraform. We had you know all these automation tools, all these scripting. um How does that look like in a cloud native ecosystem? And the answer is really really get ups right so um and and the idea with get ops, and it stems from the idea of infrastructure as code.

A

Well, we treat everything as code right, so we treat not only the infrastructure but also the deployment mechanisms and also the management. More importantly, um via get workflows, rio git is a single source of truth and since the declarative, nature of kubernetes allows us to um um have a a declaration right like this. This is how um uh a declarative, instead of an imperative approach to managing a system.

A

It just fits right in right, like let's just leverage that let's leverage the fact that uh kubernetes reconciles everything, let's take, that same approach to managing the entire system, and so um um you know so it's it's kind of like that whole idea of of uh of of taking infrastructure as code and kind of just applying it all around right, and so I believe, get ops get.

A

Ups really is the proof that devops works right, the the even the ability that we're able to do some of these things means that, like devops yeah, it's it's kind of like the the mandalorian right like if you guys watch the mandalorian. This is the way right like there's, really it's a natural progression of how to manage a cloud native ecosystem and um and actually dan garfield, who you'll hear um speak um later on today. um He he came on my stream, so shameless plug.

A

I I do a um get-offs guy to the galaxy bi-weekly stream. He actually came onto my stream and and well. You know we had a chat about get ops and- um and he said really, the get ups is things we've just been wanting to do this whole entire time, but now with cloud native architecture, we're actually able to do it right.

A

So, like you know things that we've been trying to do this whole time with things like um you know like like puppet or chef right, I was a big chef guy in back in the day, um and you know with with vm snapshots- and you know all these weird, you know scripting tools. um We can actually now do it natively right with cloud, and now we actually can do it so before it was a pipe dream. Now it's actually possible, and um you know I'm gonna end this kind of little part here.

A

What is get ops um get ops is really what devops looks like in practice, and I I think another way to think about it is devops.

A

Devops is the culture and getups is the practice right, and so, um especially when dealing with cloud native, uh uh the quality of infrastructure cloud native ecosystem, so um so how to get started right. So this talks about how to get started, how you know what's the path, all this all this cool things, um so how do you get? So how do you get? How do you get started right? So if there's really real prerequisite, you know like.

A

If you want to know you know, if you want to talk to me, if you want to um you know this was actually like a gathering. You sit me down with a beer or a beverage of your choice and you ask like okay, you know what do I need to do? Really you need to get started with devops and to get started with get ops is really you need to get started with devops, and it's really a it's cliche. As it sounds. It's the truth.

A

You need to start with your culture first right, so um your organization needs to be ready in order to utilize get ops um to its fullest potential right. So I I go back. I love quoting people. I quoted dan. I quoted um chris short, I'm I'm gonna. Next, I'm gonna quote kelsey hightower in 2018 right, kelsey hightower at puppetconf, so you can actually uh search for this on youtube. Kelsey tire, uh kelsey hightower in 2018 at puppet puppetcon said you cannot rub kubernetes on your situation and make it better.

A

So the same is true for get ops, so you can't use get ups to try to fix your organization. That's not how it works. You need to fix your organization first in order to use get ups right. That fix right. That you're that you're looking for is to adopt github's culture, and so um you know prerequisite devops. I always put the phoenix project here. I think it's it's required reading from at this point from anyone um in in technology. uh If you haven't read it, you know it's it's um it's a great book!

A

Good read, fast, read amazing, um and so you know a lot of times when I say that you need to adopt devops. First people get dejected and- and I totally understand especially people in large organizations right and so um I always say, crawl walk run right. So, let's don't take a bite of that. The entire pie, all at once, right, you know, take take, take take smaller steps as long as you have that goal in mind, um you know, for many adopting a new culture is a daunting task and I totally get it.

A

I I know someone, um you know a cio level actually personal friend who he basically he wants to um change the culture right. He just took on the position and it's a daunting task right and for many organizations you know they take a few years to change their culture even before researching any tool any before researching any technology.

A

um You know right away as technologists want to jump on. Like oh you know, what's the coolest thing, it's all right, I'm a geek too I'm wearing an argo shirt. Obviously I'm a geek. I love it. I understand it, but really it's. It starts with the culture right and and but but for many there this isn't an option really um and it's not feasible for many organizations, or at least it doesn't seem like it right.

A

So one method that I see out there is that um for siloed organizations- and I really actually I should use a better word for um uh for departmentalized organizations right. They make the change at the department level within the within the the immediate group right, and so I think, making an immediate impact within your own group can do wonders right. I've also known organizations that cause company wat so like some teams that cause company company-wide change, just by being an example right um and you know it and that actually does it does work.

A

It's really cool to see it work where it's like. You know the whole entire organization delivering fast and often- and you know- and you know their uptime is really high like what are they doing so you know again, um like I said before. This is a really philosophical uh talk that I do so, but as cliche as it sounds be the change you wanna, you wanna, you wanna, see and also don't take the bite out of that pie holistically right, so prerequisite adopt uh devops look into devops, understand the culture.

A

First then, you'll be able to jump on to get ops right, and so so you know, if you're here, if you're you're, probably um you know some of you are saying all right. You know I'm already adopting devops, you know or I'm close to it right or I just want to know the best practices of get ops to see if it actually, you know what I have to change right, so I'll pull the curtain back a little bit more, um get a little bit deeper and I'll just talk about github's, best practices as a whole.

A

Right- um and I know I said you shouldn't- you- should focus on processes first before you look at tools right but, like you know it's hard to avoid it. Sometimes again, like I said before, uh I'm a geek, I jump the gun.

A

Sometimes you know you know I'm guilty of it as well, but it's important to get familiar with kind of the things you'll see out there right and um and when you, google, like get ops tools, two tools come up front right, argo city and flux, and so um argo, cd and flux are what we um I like to call get ops um the get offs controller get ops operator.

A

I don't know what you want to call it, but it sits on the kubernetes cluster and makes sure that your kubernetes cluster is constantly in sync, with your. um You know essentially get reaper right. It's called git, opsis um and they're both cncf project. They both have large communities. So it's really up to um it's really up to you right, doing your testing and see which one works best for you. um You know they're both widely adopted.

A

um So you know you you're lucky in that respect of, like you, whatever you choose, you can't really go wrong.

A

um They're kubernetes native and cloud native is uh cloud native, so they're they're built specifically for this task, and um you know another thing is templating: I'm going to go to templating uh deeper in a little bit, um but templating you'll see helm and you'll see customize out there a lot uh customize a patching framework built into kubernetes and helm, is like the de facto package manager right and I'll go deeper into them in the next few slides and then you'll see things like cluster management right.

A

So you'll see things like uh open cluster management or a red hat. What um that's the upstream but we'll red hat. We call acm right red hat um um acm, so um the cluster manager, right and so application cluster management and then you'll see like things like ansible right lansible will manage things outside of the of your kubernetes cluster. um Some people use terraform. For that. That's fine! You know. You'll you'll, you'll you'll see puppets still out there, although that's fine, how to manage things outside your cluster.

A

So these are kind of the tools that you'll see a lot out there, um and so so you decided to get ops right, so so you've decided to get off system reminds me of a pamphlet. um So you wanted to get started with get ops and you read that getups is kind of like infrastructure as code that you'll be using git. So what do you do you take all your yaml, you dump it in a git repo and to get started right. It's cool, yeah you're get opting now, but now you're running into issues right.

A

What about different clusters? What about environmental differences? What about scaling? How do I scale this out? um You know dumping everything into a git repo was cool at first but you're having trouble trying to um deploy it to different clusters right, and so um you want to avoid duplications of yaml right, because you know hey you're, you you can deploy across multiple clusters cool. But how do you manage that without copying, yaml everywhere and so um first tip you see, is customize right, so you use customize, uh it's essentially a patching framework built into kubernetes.

A

So you know I can spend a whole hour talking about customized, but the idea is that you have a base um configuration right, so you have a base configuration um with all the the yaml kind of that yaml that you initially dumped into that git repo. While you would put that in a base configuration and then you will um you overlay your changes right, so you, you kind of overlay, the deltas between environments right so, for example, if you have a deployment, maybe the scale is different between dev and uh prod.

A

Maybe the secret you're referencing is different from dev to prod. You don't have to copy that same um deployment, yaml multiple times right. You have one base, hence the name base. We use base a lot and then you overlay the deltas right. Pretty simple. um It sounds more complex than it is. It's actually really really simple to get started right. You have things like uh for those openshift users. You have like a deployment, a service and a route very common uh for kubernetes user route, same thing as ingress um in openshift.

A

We support both, but um we first came out with route, so we have route so in dev. Maybe the route is different. It'll definitely be different right. The ingress point will definitely be different in that it is from dev to test. So you kind of overlay the deltas uh keeping the the originals intact right. So it basically renders um what you what you tell it to so next is helm right. So now um now we're going into actual templating right, so helm is a uh package manager for kubernetes.

A

I'm not gonna go into very, very deep detail in hell again, you can spend a whole hours talking about helm um um and there's probably others that are smarter than I that can talk about hell in a more intelligent way, but helm is essentially think about like apt-get or dnf for kubernetes right. So you want to.

A

um The idea is, is that um you know you have a you: have a chart right or a template of what they call a helm chart and you have the values that you want to apply to that helm, chart and then helm will then um render out yaml based on those two onto your kubernetes cluster right and so on. The kubernetes cluster there's releases right of you know, for example, the bitnami is very, very popular bitnami mysql, um a cluster right.

A

So my sql, you know ha cluster, uh there's a helm chart for that, and so you know you kind of input. Things like you know, username passwords things like that right um things that you want to templatize. So this kind of looks like this um so for um uh it's essentially go go templates right and you can do things like like if statements and you know um uh loops and you can render things to yaml. So it's actually, you know it's go line template under the covers.

A

You don't really need to know that unless you're building them, um you don't really need to know that it's just the the idea is to use templating. um So that way, you're not copying that same deployment in this example there's a deployment over and over and over and over again, so um how it works right right. You have on the left here you see the values.yaml file cool yaml. um uh The values.yaml file has uh your options right. So the you know it says. Okay, here are you know, contexture equals this.

A

The mode equals that right, like it's, basically key value, key value, key value in in a in a structured um language right. So it's like here yaml, I think now we can all just say like yaml- is now the the language right, a cloud native, because I think we've all been dealing with yaml for so long um and on the right is basically how to render those. And so um you know you say: hey install this, uh install this application and then put my values there. So um you have a um you know here.

A

It'll render the deployment here. uh What's really really cool about um uh about helm and and customize. Is that since one since customize is a um a patching framework, that's built into kubernetes, like every git ops tool supports it essentially right. So you have argo city, flux, acm, right, there's even um modules for ansible to you know to um to interact with customize and helm, and so helm also is also supported by argo city influx and acm. So it's it's essentially become the de facto standard how to deploy an app.

A

um How to deploy that so really cool question. So uh would we use one versus the other? The answer is: is that it's not versus it's a yes and uh question great question right. I get to ask that a lot. It's a yes and right, you're gonna use both in tandem right, you're, gonna use one over the other. uh I know some organizations that have their application, but they're using a helm chart to deploy something that supports their application.

A

So, for example, if, like I'm a front-end developer right, I'm doing node.js and I am um I'm deploying a uh uh a front end right with some middleware and then a database back end, um I'm using the bitnami, for you know my um uh for my database deployment, so I'm using a helm chart with customize for my application and the back end so you're kind of using both um you know, you're using both right, so customize patching framework um and also the um the templating as you use, uh use, helm and so um so best practices for get workflows, and so I'm gonna kind of just kind of drill.

A

Through these uh really quick right, I have like a few slides left right, so um controversy here. Everyone knows this is a controversial subject. I always say separate your yaml from your application code. Separate them. um Yes, I'm really serious.

A

Yeah they'll have independent life cycles, so the idea is that your application code is going to have constant, commits and testing on it, whereas your deployment code doesn't really change all that often I mean it does change, but not in the same cadence, right and um and also there's other um other other things that you need to keep in mind.

A

um That goes along with this right. You use directories for environment variables, um not branches. Yes, I'm being serious right. So, like a lot of the things that developers do, that may seem natural to do with your uh get ops. Repos is actually not right. They have you know, even though you're using git you're using different, get workflows. um You're, not using branches um cost is from um from code fresh.

A

Has an amazing blog about why you would um why you don't use branches right, why you would use directories, but the idea is that a promotion right, a merge is never simple right, because, if you're merging from dev to prod you're not merging the whole thing right, you're only merging things, you know, like the like the secrets, the secrets are going to be different. The scale is going to be different. How do you only merge a subset of it? It just gets really complicated.

A

I can go on and on about that, but use directory for environments, meaning leverage, uh customize and so um use trunk based development right. So you know we're going against all grains right, don't use branches, don't use, release branches, use, uh short-lived, um feature branches right and then you work off a trunk or aka main. Yes, we're deploying for main. You can call it whatever you want, but the idea is that you have a short-lived feature branch and um you know once it's merged into the main trunk.

A

You delete your feature branch um and if you want to know more about trunk based development, you can just google trunk based development. It's the first hit and find out more about uh trunk based development, and you can, you know, hit me up on on slack or twitter and you know talk more about why um why that works, for for get ops right and so uh last, but not least, use protective branches right. So you know most people can get behind this.

A

um Basically, branch protection rules, you know don't allow force, pushes um you know, protect against accidental delay deletion and it forces code review right and approvals, so protected branches is also a a good, uh a good way, and so I see that I'm about couple minutes over, but I am done. um Thank you. Everyone this. This went a lot shorter in my head when I was practicing it christian.

A

So so thank you I'll be in the chat. If you have any questions, I'm going to be in chat all day, so um yeah so anyways I'll hand this off uh to cornelia here. So.

A