Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 15 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sponsored Session: Red Hat - Use Kubernetes-native Integrated GitOps CI/CD Workflows

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Sponsored Session: Red Hat - Use Kubernetes-native Integrated GitOps CI/CD Workflows

Speakers: Christian Hernandez

In this demo, Christian Hernandez, Technical Marketing Manager at Red Hat, will review how to build a GitOps workflow using Kubernetes-native CI/CD tools Tekton and ArgoCD all within an OpenShift deployment. See how Operators integrate into your development pipeline to deliver a GitOps workflow.

A

Hi, my name is christian hernandez from the cloud platforms business unit over at red hat in this video, I'm going to be showing you how to build a git ops, workflow using kubernetes native ci cd tools.

A

Here I have an openshift 4.7.1 cluster, which is running kubernetes 1.20 that I'm going to be using for this demonstration, and here I have a sample application. This sample, php application for testing purposes, has a container file. Docker file that will be used for container builds in order to build this application, and I also have a deployment repository here.

A

The supplier repository is my get ups repository on how I'm going to keep this application continuously in sync in my cluster, so to get started, I'm going to go ahead and install the openshift get ops operator by going to the operator hub and typing in openshift getups oops. If I spell that right.

A

There it goes clicking, install and accepting the defaults. This will go ahead and install the red hat, openshift git ops operator, so the open ship, red hat, the red hat, openshift git ops operator what it is, it's a sort of meta operator, this operator, installs, argo, cd and tekton in order for me to use in my ci cd pipeline. So once the operator is up and running, I can go ahead and look at my installed operators making sure I'm in the openshift github's namespace.

A

I can see that it installs the ability to do an argo cd and a text on pipeline. So if I click here and look at my argo cd instance, this installs an instance of argo cd. So what I'm going to do is I'm actually going to make some customizations for my current workflow. So first, what I'm gonna do here is I'm just gonna.

A

Instead of typing this out, I'm gonna copy and paste it I'm going to uh patch the uh the instance of argo cd to ignore uh routes, openshift routes, because in my git gobs repo I am not specifying the routes. I just let the platform create them for me. Also. What I'm going to do is I'm going to set up an openshift policy to allow the argo cd service account access to my application.

A

Next, I'm going to delete the pods right, so I'm going to delete the pause in order for it to reset everything, especially since I'm updating roles and config maps I'm going to delete the pod so that way, it'll it'll kick off here.

A

So next, what I'm going to do is I'm going to install seal secrets right um installing steel secrets allows me, allows the platform to decrypt some of the secrets I have uploaded in um in the git repo.

A

So, while that's going I'll show you some other configurations, I've done in my um in my application, repo I've actually set up a web hook. This web hook uh triggers a techton pipeline anytime. I make a commit to a specific branch. In this specific um example, I'm going to be using the main branch, but you can make it listen to whatever branch you want to.

A

Going off here, double checking still secret's still waiting for oops for it to come back up. um Let's talk a little bit about my um uh my get ops, repo, my deployment, repo right. So there's there's a few things here. um I'm leveraging customize here customize is: um I have a base repo where all this um all the manifests here are the same, no matter which environment I'm deploying in and then I'm utilizing overlays for different environments right.

A

So I have the dev version, which takes the base, configuration and then patches them for uh this specific environment, for example, I'm installing uh this application, dev application in the dev name space, and I'm also patching the deployment to use a specific version of this image same for the production production.

A

What I'm overlaying is the same, I'm deploying in a different name space, and then I am using a specific image tag right, so I can use the same deployment config across multiple environments and I'm leveraging customize in order to change that, depending on the environment, I'm in so going back here see seo secrets is installed. I can go ahead now and deploy my repo again, I'm going to be using customize to deploy my application repo. Let me clear this oops.

A

There we go, I'm going to be using customize to override the default.

A

Namespace because I'm using the openshift get ops operator and then I'm just gonna use customize build and apply this to the uh to the cluster. So, as you see here, it created three different environments.

A

um Welcome dev, welcome, prod right for for my development um environment and for my production environment, and then I have a a different name space for my pipeline right and so um in order to see what's going on here, let's actually log into the argo cd interface. First, let's get the password from a secret.

A

I will then uh open this here, um integrated um ui here. That will take me to the uh oops. That's not what I wanted there. It goes. Let me reload this.

A

Accept the self-signed certificate, so let's do uh username and password.

A

So here uh you can see that I have different environments now right I have the dev environment, uh my production environment and then the pipeline, which is a different set of manifest and that's matches to what created here. So, let's take a look at the dev environment, it says everything's in sync,.

A

Let's look at the live manifests here, um so this is the um the development branch right here and then let's take a look at the production.

A

Right there, so in theory this should all be the same right so yeah. So I have um my development version here. I have an h2 that says blue and it matches uh production because they're using the same code base at this point.

A

So that's all um everything's green everything's synced up we're good to go here. So now um I'm gonna be switching over to the developer perspective um developer perspective gives the developer a set of tool, sets that um that they need in order to do uh application, development right and it's and it comes with a uh a tour.

A

So you can know uh where where's, where right, I'm gonna skip the tour since I'm already familiar and then I'm gonna go to the pipeline namespace and I'm going to go to the pipelines and, as you can see here, um there is a I set up a pipeline in order, a textile pipeline to do the changes across the environments right and so let's introduce a change and see how this works out. So let me go to my visitor studio.

A

I have the code up here already, so let's go down and change this h2 from blue to let's say something: different, uh green right, we're all familiar with that and let's do a git commit.

A

A

Get commit and let's go: uh let's go updated to green right, something useful for the for the tracking right uh get push.

A

So what what's gonna happen here? It's gonna hit that uh that web hook remember that web hook. I showed you earlier from the uh from the welcome app and that should trigger a pipeline run right. So um when that web hood uh going back to the settings and looking at the web hook here, it sees that I have a listener here, set up, protect on and that hit the web hook and that fired off a pipeline event. So this is going to go through a few phases.

A

So, let's take a look here, see what's going to go on, so I have a few steps right. So first I have the step of talking about cloning, the repo once it clones, the repo it's going to set the image tag for a specific version right. I don't use a floating tag like dev or prod.

A

I actually use the specific hash of the git commit as my image tag and it's going to build and push it into my image repository once it does that it's going to it's going to clone the deployment repository right, my githubs repository, so this is different than my application repository once it clones that it's going to um um edit the image tag on the the get ops repo to this current one that it's building um part uh part of this.

A

I have uh parallel tasks right parallel tasks in tecton is just tasks that run at the same time, um my latest always matches what my dev is and that's just something I do as part that's independent of cloning, the repo um and then once that's done, I'm going to patch the dev repo right, the dev overlay. With the new um uh the new image tag, I'm gonna commit it to the repo I'm gonna, then I'm going to patch production right.

A

So once once I um once I patch production right, I'm going to create a branch in my production, get ops repo and I'm going to submit a pr right. So this is how I do gating in tecton. Is that I submit a pr instead of automatically pushing it into production? So if I take a look at the logs here, you can see the log for each individual task. I do a git clone. I do.

A

um I do the the commit, and now um I am um pushing I'm using builder- to push the uh the steps up here. So um this pipeline could take some time. So I'm going to um I'm going to pause here. So um I'm bringing you back here to show you that I made a commit to development.

A

I want to switch back over here and look at the development environment and do a refresh here. So argo cd sees the fact that the image has changed in the repo. The image has changed. So therefore, argo cd assumes that, um since I have this set to auto sync, that I want this at the latest available dev version um and it does essentially a rolling um a rolling roll out of the new version of the image. So the image tag changed changed in git, then argo cd saw that change and automatically synced it for me.

A

So if I go to my dev environment right, remember that it said blue right now, they're both match dev prod. Now it says green right same as my commit now says. Green uh production, though stays the same as blue, so going back to the pipeline, let's see what happened here. um It finished right I committed to dev. I patched production right so production this step here is that I'm gonna uh patch patch the uh the image, the latest image here and create a branch and then create a pr.

A

So then, here now it says now you have a new pr. Let's take a look at this pr. So if I go to my git ops, repo and look at this pull request notice that um I have a new pr here, this pr here is saying that um that uh I'm gonna update to the image to the the image matching dev into prod. So if I click on files change and take a look at here, you can see that my overlays production deployment goes from this tag to this new tag that I that just happened.

A

While I built this.

A

So going back to my pull request here I can you know once I've gone through the all the code reviews and all of this all the all the process that you have in place. I can merge the pull requests you know once merge. I don't need this branch anymore, so I just delete it. But if I go back to um to my ergo here and do a refresh, you can see that it now saw that oh hey, there's been an update in get.

A

Let me complete, uh let me sync that for you and make sure you're at the version you told me um that you wanted in get which happened to just update since we're using git ops right. So now the application is done. Syncing I can go over to um you know this is the dev version. I go to production version, I do a refresh and now production shows green. So now they match as they do in the git repo. So um anytime, I want to make a change. I can either to the code base.

A

I can go back here to visual studio, make an update to the code base. If I want to change something like, um let me go back to my repo like the scale of the application, I would just do a pr to the git repo and then argo will reflect that change. So thank you for watching this video. I hope you found it informative and how you can use um kubernetes native ci cd workflows in order to build your get ops pipeline. Thank you.