solo.io SoloCon 2022, 16 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Weaveworks GitOps-Core and Gloo Edge

Description

For more great content, visit https://solocon.io

SoloCon 2022: Weaveworks GitOps-Core and Gloo Edge.

Speakers: Steve Waterworth, Technical Marketing Engineer at Weaveworks; Daniel Wessels, Field Engineer-APAC at Solo.io

Session Abstract: The faster an organization can deliver new features and fixes, the better. GitOps enables the speed, and when used with progressive delivery, it provides the safety net. This session will showcase progressive delivery for Kubernetes using technologies such as Weave GitOps alongside Solo.io's Gloo Edge. Learn how to create best-in-class GitOps workflows while ensuring High Availability and Disaster Recovery.

Track: Gloo Edge and API Gateway

A

Hello, I'm steve wortworth technical marketing manager at weaveworks in this session, we're going to show you how to use githubs to deploy and manage service meshes weaveworks coined the term gitops in 2017 we have customers across many industry verticals and our key partners with major cloud providers. We contribute to and maintain a number of open source projects.

A

Weaveworks is backed by leading investors. The use of service meshes enables more dynamic deployment options. However, their configuration can be quite complex and a bit tricky to manage as we're about to show you using githubs, is a great way to operate service meshes with the safety net.

A

Before we go into the details, it's worth explaining the ideas behind gitops, the cncf working group opengitops defines the four principles of gitops as declarative. We're talking about service meshes on top of kubernetes. Everything is declared in yaml files, versioned and immutable. This is where git comes in. It maintains an immutable version. History of every commit pulled automatically and continuously reconciled.

A

These are taken care of by weave get ops. Let's look at how weave get ops works.

A

Weave get ops is built on flux, a cncf incubating project, soon to be graduated, think of weave gitops as a wrapper around flux that makes its installation and operation easier without losing any of the sophistication of flux.

A

Weave gitops continually reconciles the desired state stored in git, with the actual state running in kubernetes, when a change is merged into the monitored branch. Those changes are immediate, applied to kubernetes. Conversely, any change manually applied to kubernetes are automatically reverted back to the single source of truth. In git configuration drift is eliminated.

A

Now you know how it works. What are the advantages when using gitops to manage your kubernetes clusters? Everything is done through git. The number of people who need direct access to kubernetes and the cloud platform is significantly reduced.

A

This minimizes the administration overhead of roles based access control inside kubernetes and the distribution of kubernetes and cloud platform keys, thus enhancing security with a constant reconciliation of configuration. Git is the single source of truth. Your cluster configuration will be what is in git configuration drift is impossible.

A

Git provides a complete audit trail of who changed what and when changes can be reviewed and approved via pull requests. Once a change has been merged into the monitored branch, it is immediately applied to the kubernetes cluster, accelerating delivery.

A

If a change proves to be sub-optimal, it's easy to roll back to a previously known good configuration significantly speeding up time to recovery. This diagram shows a typical workflow for a git ops deployment. A devops engineer uses their normal workflow to create a pull request against the management repository.

A

Once this request is reviewed, approved and merged. The change is immediately applied to the cluster. Now, let's see it in action over to you, daniel.

B

Thank you, steve. uh Let's move on to the demo part of this talk, um we'll be demoing blue edge and we've worked speedops.

B

I'm daniel vessels, a field engineer with salio and aipac, specifically sydney australia.

B

At the moment, we have a newly provisioned mini cube cluster.

B

So that's ready for us, so here we can see the mini cube. Cluster was provisioned, of course it needs a bit of resources, so just have a look at that. It's got metal lb as well, not necessarily required, but I do use it for my ingress traffic and service type load balances.

B

I've also already installed the weaver github cli version 0.6.2.

B

And then I have already pre-provisioned the repositories that we will be using for the git ops demonstration, so there's two repositories: the git ups config and the blue edge with works, which is where all the shared infrastructure and applications are.

B

Let's have a quick look at kicking off the bootstrap process, so.

B

We can find these commands in the we've worked getting started page as well, um so we'll kick all of these off and then we'll have a look at what's happening as well.

B

So, let's have a look at the repositories. As I mentioned, we've got the two repositories we have essentially the blue edge. We've worked repository where we have our infrastructure shared services and that is blue edge itself and key cloak we'll be using today and on the application side uh we'll be using the pit clinic application to install. So that's what that directory is for.

B

This is essentially where you will have all your application packages and manifests already ready and we'll have a look at the different ways you may be using to install applications and services that could be either a customized yaml manifest or you could be using helm.

B

Both of those ways are available to us and we'll see them in action during the demo as well, and here we can see as a fresh repo.

B

On the github's config side, essentially the same we'll have to wait for the bootstrap process to finish before we come back here and have a look at what happens after the bootstrap and what gets layered into it.

B

Okay, so we can actually see that the bootstrap process has completed and it's completed with uh pull requests that have been created automatically to the config github config and, of course this is important in terms of get ups as well. We automation is great, but in most cases we do want some controls and with git ups we can use to get up uh to get pull requests to insert those controls as need be.

B

So let's go back here, uh have a look at the pull request um sitting there waiting for us, so if your demo fashion I'll just um approve that since we know already what is required. So this is what has been created by that git ops, github bootstrap process.

B

um So it's a similar structure to most git ops tools or some of the github stores that everyone knows in terms of customization and yaml file manifests it's gone and generated all of those for us and checked them into the repository as well.

B

So on the system side, everything is up and running um under the hood. We've worked, skidops um utilized as flux and and we'll take a bit of a look at that as well. In a minute.

B

At the moment, that's it there's no applications yet so.

B

So that's it pretty straightforward to get up and running with the we would get ops, bootstrap process, we've completed the pull request, and now we can use the we would get ops ui, and I just run that in a separate terminal, because it's using port 40, okay good. So now we can start adding our applications via this ui and again, it's very straightforward. First thing we want to do is install our shared services. So let's call it that actually internet services- and this is going to include our.

B

Blue edge installation- and it's also going to include our keycode installation, the shared services we're using here. So all I need to do is specify the repositories for where the application lives and assign temporary access.

B

B

Of course, for non-demo you'll take a closer look at the permissions that you're allowing there.

B

Okay- and here I'm pointing to the infrastructure folder, which is where my customization file sits, which will tell qskip now we will skidops um what manifests to run okay, so.

B

And then we need to specify the github's directory as well. This is where the synchronization between the git ops and the convenience cluster that happens and, of course, there's tokens. There that's required as well, so we're ready to submit our first application.

B

Excellent and again just to demonstrate git ops um process and controls. We have a pull request um that needs to be reviewed, peer-reviewed reviewed by whoever maybe manages um to make sure that um no unauthorized changes are happening.

B

Okay, good, so if we now take a look again at this, we get ops directory before we had the infrastructure level customizations and system uh which bootstrap everything.

B

Now we actually have a user object as well, which is that application shared services.

B

So if we look at that.

B

You can see that customization has again been created out of that form. We've completed, um and here you can see the the yaml manifestation of that ui form that we completed with the repositories that's required, so we could opt to have updated its own configuration and created the necessary manifests to allow it to pull in these services.

B

If we take a look on the kubernetes side, we'll now notice that key cloak is busy, installing blue edge is also being installed, and everything is starting.

B

Okay, we'll wait for those installations to also complete and from there we'll move on to the pip clinic installation as well. So let's have a look at the ui again finish that side.

B

So we now see that the shared services is an application in there and we've got great visualization um of what we have done in our get-offs repositories.

B

So this sort of visualization, of course helps us humans, um because it's not necessarily easy to see these dependencies and resources that we're operating just by looking at gibbs the kit repositories.

B

So um that's a really great feature of the new works. Git ops tool, this ui that shows you the dependencies out of the box.

B

And we can see, it's picked up the authentication again. This is based off the temporary tokens to pull out the information from kit.

B

Another way to look at the sort of progress is to use our kubernetes commands, so I've got the alias set up for to cuddle get so we firstly getting the customizations and we have a look at what has been picked up and we can see everything is happy there. It's picked up the shared services customization part of installing these shared services.

B

We are pulling in applications from helm repositories that is automatically being created as well and that's up and running, um and then, of course, once you have the helm, repository, there's a helm release so and then we can see that is busy with its installation.

B

See that's all ongoing and we can actually tell that process to help us with seeing looks like that has completed.

B

Let's take a look here: everything is up and running.

B

So another thing to to sort of look at is the fact that we have now installed glue edge and key cloak and we haven't run any tube, ctl apply, commands or any cute ctrl commands.

B

We have just used git repository and the manifests in get to effect those installations, and that's that's um another way to to look at at githubs, while kubernetes have abstracted away ssh-ing into machines for installs and configurations and getting up applications up and running.

B

Git ops is about abstracting, cube, ctl away from us and removing as much as possible humans from touching our operational um environments is, is always a good practice um so that there's no human error.

B

So that's a that's a key thing to see throughout and we'll see that throughout this demonstration we are just doing get commits to effect changes. We don't um interact with the um kubernetes api at all.

B

Okay. So let's um look at that now that we have everything installed, we can do the configuration so key cloak. We need to install and configure a couple of users just so that we can use it. Of course we need a few users to authenticate with, so we run a few configuration scripts uh from that. We need those outputs a little bit later I'll, just save them there.

B

Okay, great so key cloak is up and running now, let's install the application, so we go back to our we get ups and we add another application in this case. um Let's call it apps, so our applications are living in the same repository under the apps folder here so for our repository source.

B

Via that implication, that's okay, so give it the part and tell it where to get up to configuration. So it's.

B

B

Excellence, that's come true with the usual pull requests.

B

And there we go so we now look here: we've got the shared services and we've got the new uh application and again it's taken our form and transformed it into the necessary yaml, so that the controllers in the cluster can start acting on what is required to be configured.

B

um If we look here, applications you can see, a clinic will be installed.

B

Staging customization- and we are installing tech clinic.

B

Clinic will have its customization, which points to base.

B

So let's take a quick look at that. Pic clinic is not very robust applications and, in this case, we're just using straightforward kubernetes yaml um by customization. So in this case we're not using helm. There's no, you don't have to use helm, but if your educational package has a helm, you may want to use that, but um you can just use straightforward cumin in etamo. You can take this file and use cube. Ctrl apply, dash, f and point it to this file. So that's essentially how pet clinic works.

B

So let's go back to the ui.

B

Okay, now we can look at apps and we can see again that visualization that comes with uh weed gels. um Application is ready to test. So let's have a look on the kubernetes side, quickly default namespace and you can see. Pictonic is up and running.

B

Okay, so now we have everything in place: the application is sitting there um and I'll use another repository from our solar blogs, and if you want to go to seller, I o blogs and search on git ops. You will find many resources in there and for the rest of the demo. We can just utilize this repository, and the first thing we want to do is see that the application is up and running.

B

So to do that, we will find the gateway.

A

B

Address there's the do edge.

B

You can see it's sitting on that external ip, so browse there right. Application is up and running. What's not so great, it's plain text. So let's convert the traffic to tls.

B

Okay, to do that, we go to the application.

B

Repository and we edit its virtual service resource, the blue edge virtual service resource source, and we pointed to the tla certificate, which is a kubernetes secret.

B

So it can use that to terminate connections to this application for tls, and then we need to complete our git push.

B

So go to the application, sync that up.

B

And now it's synced up, so we change to http. Yes,.

B

Of course it's just a self-signed, certain warnings will be there, but we can see without changing any application code. Blue edge has switched to traffic to encrypted tls, and with that in place we can now add authentication. We don't want to do authentication across plain text.

B

So let's have a look at that for that we will need to edit the applications authentication policy uh again, that's a blue edge custom resource, um we'll activate that policy by the customization file and then we'll go back to the virtual service again and add the authentication section for the virtual service, which is essentially where the proxy is listening for the application.

B

So, let's start that quickly,.

B

Again, not touching the cluster or cube apply, or anything like that. If we sync up the application.

B

See that has successfully updated and now, if we go back to the application refresh, we are prompted for a long.

B

Yeah excellent, so thank you very much for looking at this demo uh back to you, steve.

A

Thanks daniel for a great demo, it really showed how you can use github to manage service meshes across your kubernetes clusters. If you want to evaluate git ops yourself, download a copy of weave github's core for free weave works, regularly, hosts hands-on workshops sign up on the events page.

A