GitLab GitOps, 15 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitOps Series - The Applications

Description

GitOps is the use of a git repository as a single source of truth for all infrastructure and application deployment code. In this video we will walk through the process of deploying applications to three different Kubernetes services with a single common workflow. These deployments are performed by GitLab CI using AutoDevOps which uses Helm under the hood to deploy to Kubernetes.

See the code at: https://gitlab.com/gitops-demo

Learn more about GitOps: https://about.gitlab.com/topics/gitops/

A

Hello today we're going to talk about get-ups. What is get ups get ups is using a git repository as a single source of truth for all infrastructure and application deployments.

A

Specifically today in this video we're going to talk about application deployments in previous videos, we talked about infrastructure deployments, so with application deployment, we've got we're using git lab as the single source of truth and the git repository we're using auto devops in conjunction with helm and kubernetes to deploy our applications. So, let's jump in and look at it in a previous video I deployed three different clusters out to three different public clouds. So I've got three kubernetes clusters, one in Amazon, one in Google and one in Microsoft.

A

Azure I've got four different applications, name one: that's ASP another dotnet, a third Python, a ruby application and a spring application, so I've got five applications that I can deploy. Let's take a look first thing: I'm going to do, I mean, might get ups demo group I'm going to look at my applications and show you that the kubernetes clusters are all registered to get get lab. Here's my or cluster my Google cluster and my Amazon cluster, these environmental scopes represent which applications I would like deployed to which location.

A

Let's take a look at app number one: this is a dot end application, it's the equivalent of a HelloWorld application. So nothing fancy in here. If we look at the CI file, that's in here we've got a few modifications specific to this application. First thing we do is import the main, auto dev ops, template set a couple of variables override a few commands for stages that are more applicable to net code and finally, at the bottom here I see that I've set my environment automatically to deploy production into aks.

A

Now I've already run this pipeline, but let me show you quickly what it looks like here's, the latest pipeline, all of my tests have pasts I did a build. This came out of Auto dev ops creates a docker container, uploads it to the built-in docker registry. I. Do all my testing, including my container scanning my license management. My SAS and my unit tests I can see the output of this I can see my security results here. I can see my license report here and finally, this job deploys it into production.

A

If I go to my operations section here, I can see the different environments. I've got my aks production environment.

A

I can monitor this. This environment.

A

I can see my HTTP error rates, my latency rates throughput. This is all powered by Prometheus integrated into the kubernetes cluster I.

A

Could also launch the environment directly from here and I can see. I have a live URL running on IKS that launches my application. There's there's very little code other than what's built in to get lab that defines how this is deployed. Auto DevOps automatically creates a helmet art and deploys it to kubernetes in IKS.

A

Let's take a look at a different example.

A

If I look at a spring application, I can see in my spring app I, don't have a doc or a get lab CI file in this one I do, however, have a docker file, so this docker file was manually created for this application very little very simple, docker file using plain generic Auto DevOps, meaning no overrides.

A

Able to produce a very similar, build test and production run.

A

In this environment, I can look at my metrics I.

A

Get the same, the same metrics, the error rates, Layton sees throughputs, etc.

A

And in this case, my application is running automatically in in a container on kubernetes in my gke cluster.

A

We'll look at one more example here, my ruby application.

A

Application by Python application.

A

A

Get lab CI file with a couple of overrides a few overrides for test after importing the main Auto DevOps template a few overrides for test, and in this case e KS.

A

My pipeline runs in the same manner.

A

Running my build all of my tests, including my security tests, my production run and a performance analysis test.

A

I can see here when I look at my environment, I'm deployed to eks and I can open up this live environment, my Python application and see that it's running any KS. All of this is a consistent interface with the exact same workflow, making it simple to deploy to any major cloud running kubernetes integrated with git lab I.

A

Think one of the most important things to note here is that everything lives in the git repository the infrastructure code lives in the infrastructure repositories and the application code lives in the application repositories. There are no changes made outside of the git repository. Everything is done within get lab as code, either in the CI file or in the infrastructure file and for certain things like secrets, we define those as environmental variables in in the CI section that allows us to keep our our secret secret and to keep all of our deployment definitions in git.

A

So we have a nice stateful declarative deployment of all applications and get a high-level view here of all my applications. From the operations dashboard and I can see, all of my applications have been deployed. Some have some small warnings, but all all running, happily, that's it for today. Thank you so much you.