 All right, here we go. Yeah, welcome to the get ups one-on-one demystifying get ups talk we will talk about Get ups today, yeah, obviously and We want to want to see that get ups is not just a buzzword. We want to Make sure that people know That not the only requirement to be Working with good ops is using git. This is not the case sadly for some people and We want for example talk about the get ups principles when something is really get up see We want to talk about the relation to other practices We want to go over an example workflow and then we want to see what available tools are out there already and Yeah, we want to show you When get ups is really get ups. So let's get started So first of all, what is get ups? GitLab has its definition of get ups is an operational framework that takes devops best practices used for application development such as version control collaboration compliance and CI CD and applies them to infrastructure automation so infrastructure automation in this case for example is also deploying new New resources for example and your network policies config maps, but just also regular deployments pots Yeah, whatever whatever there is for example in the Kubernetes Yeah, well on one hand the advantages of get up get ups is for example security and stability because you can easily roll back to a working state With just a PR. So everything. Yeah, everything is stored in a versions repository for example in a git repository and this way When you have a breaking change for example, and it really really breaks your production You can easily create a new PR and just roll back to the state where you know that it that it was working Yeah, and Get a good lab talks about collaboration because you have a centralized tool in this case for example a git and This way everyone has their Their known tool they have to use and also in a central Central part of repository for example, then yeah, we also get more transparency Because when we use a central git repository for example, we have the possibility to see every deployment for example or every config map and There we come to one one disadvantage for example when you need secrets you have the Problem, let's let's do a quads here. You don't want to store them in in git So you have to store them somewhere else for example in hashicob's vault or Seal secrets, whatever there is you will we will hear here talks today Then we'll talk about managing git managing secrets the github's way and also one challenge is Get off at scale. For example, there are a couple of known issues or Challenges, but there will also be talks today That will talk about that challenge. So Yeah, just quickly about me. I'm Nicholas. I'm a DevOps engineer at font of here in Cologne, Germany We're doing Backpacks for children for example and also shoes. That's that's the That's the market we are in and I'm also an open github's maintainer we will talk about open github's just in a second and Yeah, we use github's mostly for our middleware services and We started like one and a half years ago with using it and we are really happy with it so Let's go go over the github's principles the github's principles are defined and managed by the cncf's auto github's project, which I'm also part of That's that was founded by a couple of companies for example, AWS Microsoft Codefresh and we've works, which are who also coined the the term github's and It's part of the application delivery a special interest group in a cncf and The github's principle you see here, which is declarative version immutable pulled automatically and continuously reconciled These are firstly a first published in October 2021 and what these are I will show you on the next slide so Here we have declarative. It's pretty much the easiest to understand because Most of the people already use it like already managed their infrastructure like that already a System managed by github's must have its desired state expressed declaratively For example, we already know that from Kubernetes resources for example when we have our YAML files where we define okay We have a deployment here that consists of those parts and we want to use that That's for example the clarity declaratively defined but in this case We don't only have infrastructure as code, but all the configuration data that is needed to run a system including also the application layer for example We doesn't generally include persistent application data for example database contents. That's not managed But we include for example the credentials and configuration for that database resources and Yeah, and one one one more thing is The definition should always result in the same set of resources. So we don't want to have flaggy outputs when we have Those kind of inputs it has to be result in the same outputs every time. All right, so Then we have a versioned in immutable the desired state is stored in a way that enforces immutability Versioning and retains a complete version S3. Okay, some people would just say just use git fine That's that's totally totally possible That's But that's often misunderstood. So it's also possible to use something like a Version S3 bucket. That's also totally fine because we have the version aspect and we also have the immutability aspect So this way These are the the only requirements that are really needed That we have the second principle met and one thing, please Using the latest Tags like like the latest tag on one of your container images, for example Is not versioned. It's it's not that easy to roll back to a state. That's was working So please don't do this. This is not Not a github's Kind of kind of way to do because when you have a problem It's better to have a versioned Tag and then just roll back to the version before and then you know fine going fine again Alright, so the third principle is pulled automatically software agents automatically pull the desired state iterations from the source So the source in this case is for example our git repository the software agents that Running for example in the kubernetes cluster are constantly observing the desired state. So how should our cluster look like and how it for example looks right now, so In this principle, we just look on what is the desired state and pull it from the git repository There might be triggers for example like in a traditional CICD pipeline, which triggers the cluster to look Okay, here are some new changes. Please make sure that these are also in our cluster now but In this case Just I just want to make sure that it's that it's Understandable we are just pulling the declarations not like for example the code or something We're just the declarations of our resources and then we come to our fourth Principle which is continuously reconciled software agents continuously observe actual system state and attempt to apply the desired state So that's what I just just said We have our desired state in our cluster checks, okay What is our software agent checks? Okay? What is what is the the current state of our cluster? Do it doesn't met our desired state. So this way we just bring it all together and the software agents Tries to if if the software agent checks, okay, here is something here's something wrong My actual state in the cluster is something different than the desired state. I see in the git repository I will try to apply those desired states to my to the actual state so This way we have something Like drift detection automatically. It's this way. It's also cell feelings. This is this is a nice feature and Yeah, it this normally or typically Happens every couple of minutes. So for example Every three minutes it checks. Okay. What's the desired state was the actual state at this way We will make sure that we always have the desired state in our cluster. All right Maybe you just think okay. I heard those principles before somewhere because that's totally fine We didn't invent something totally new with GitOps. We just Built on a couple of things that are already available But we also added a little bit more. So for example the declarative principle We noted from get up now from GitOps dev ops and dev sec ops infrastructure as code and configuration as code This is something really popular Inside of our industry. So For example Helm charts use it already or when we have Terraform or something. We also have the declarative form Yeah, and now the version and immutable we also have GitOps dev sec ops and infrastructure code and some a little bit of configuration as code for example, we have the ability to for Helm charts or customize Files to be versioned and immutable. So I grade that out because some of the tools have it have the possibility to be versioned immutable But not it's not the Yeah, the normal Practice and then we have pulled automatically there. There we go a little bit Deeper we only have GitOps and dev sec ops here. It's but it's also in a close connection To the fourth. That's why I will show you that the only Practice is GitOps with the force principle because this way we have the self-healing aspect. We check. Okay. What's the desired state? What's the actual state? And if it's not the same we will try to apply it and this way We bring it this all together alright, so Here is one possible workflow. This is Pretty much the workflow we use here at fond of So let's go over it. I will make this bigger so First of all, we have a developer here. So for example, I'm creating a new feature I will create a PR with code changes and Some someone on my team checks it again reviews it and it's totally fine And then we merge it trigger our CI see CI build there we build a new container image for example in version 1.1 and we then push it to the image registry and We store our image there Then we have our image controller in our though this this one is our cluster with the GitOps deployments inside and we have an image controller Which checks every couple of minutes if there's something changed inside of our image registry and now we see okay We have a new image version here. For example one of the 1.1 and the image controller sees, okay There's this 1.1. I only know about 1.0. So let's prep the the manifest update the version inside of it and create a PR in the GitOps repository and Then another developer or I can also review it. I Check it. Okay, it's totally fine. I this that's what I what I pushed earlier and Let's let's merge it then we have it in our main branch for example the deployment manifest and our GitOps operator checks, okay The desire state changed, but I know all you know about the deployment v 1.0 But I now have the desired state of 1.1. So let's make sure that we get the actual state to the desired state It will then applies it or tries to apply it to create the deployment v 1.1 With the POTS and if this is successfully done It will then turn off the old deployment of 1.0. This is pretty much like a Like an example workflow you can use and this is how we for example push new images or push new versions to production So now we talked about like the theoretical aspects, but there are a couple of tools already That do this for example we use flux, but there is also argocd, which are both CNCF graduated projects. So they are pretty much Pretty much often used in the industry But we also have something some new projects coming up in the incubating state, which is for example captain and also in the CNCF sandbox Which is pipecd and verve you hear a lot of About those topics today in the in the other presentations. So if you're interested in one of the Projects just keep an eye open and see what interests you and there's Plus plus there are more coming because for example Some of them are really new and they will change a lot of a lot inside of the Industry or on the landscape just just keep keep your eye on the landscape It's changing Really often or they're coming new projects every now and then So I included some resources and implementations here, which are available Like I mentioned before the five projects. We talked about argocd flux captain pipecd and verve was also there Links to the websites and I also added the open github's Project there to so you can check out the principles again and also there is some glossary items when you hover over the Principles which I got more deeply What is meant with the principles? So if you're interested in it go go over there check it out and learn more about it So Today I learned hopefully That there are four principles. It's not just use git and then your github's This is hopefully More clear now That's that we have those four principles which are declarative Virtually mutable pulled automatically and continues reconciled I hope you you learn that it's That you cannot for example also use an object version object store, which is totally fine to do And that we pull That it meant that we pull the declarations of the files and not just the not not the code for example and We have the drift detection also included that we can be sure that in our cluster most often or always are only The state running that we declared in our files And some of the tools we have flux. We have august cd. We have captain pipe cd where there's a lot of Stuff going. It's super interesting and it's since it's pretty new. We will we don't know where we're going with everything, but We are on a pretty good way. I think and we will see What will come up in the next couple of months and years And I hope you learned something. I hope you're uh, have a great day today and I want to say thank you for listening