Keith Lee and Ivan Tarin – VMware Tanzu Demo: GitOps with TMC and GitLab
With VMware Tanzu Mission Control or rather TMC, you can manage all conformant Kubernetes clusters regardless of where they are running—vSphere, VMware TKG & TKGI, Public clouds (AWS, Azure, Google), Managed services (EKS, AKS, GKE), packaged distributions (OpenShift, Rancher) and DIY.
This short video shows one of Tanzu Mission Control’s capabilities GitOps, and how it’s used to manage fleets of Kubernetes clusters. Treating the actual clusters as cattle and not as pets is a best practice in the industry.
We will specifically address finer details that are not always covered like creating cluster groups. Then, manage the lifecycle by creating and upgrading Kubernetes clusters. Finally, we apply policies designating the workgroups that can edit a cluster and allow image registries to integrate. By leveraging Gitlab to store TMC files and automatically implement changes in these files.
Transcript
Welcome, GitLab, commit attendees with VMware, Tanzu Mission Control, or rather, TMC, you can manage all conferment Kubernetes clusters regardless of wherever those clusters are running. Yes, that includes V-Sphere VMware, TKG and TKGI, but also public clouds like AWS, Azure, Google and managed managed services like EKS, AKS, GKE, package distributions like Open Shift, Rencher and do it yourself. This short video shows one of Tanzu mission control capabilities getups and how it's used to manage fleets of Kubernetes clusters.
Therefore, treating the actual clusters as cattle and not as pets, which is a best practice in the industry. We will specifically address finer details that are not always covered, like creating clustered groups, then manage the lifecycle by creating and upgrading Carbonetti clusters. Finally, we apply policies designating the work groups that can edit a cluster and allow image registries to integrate by leveraging Matlab to store TMC files and automatically implement changes in these files.
We will complete our entire pipeline. We have the same capabilities in the UI or with other patterns using TMC, but we are focusing on getups. Furthermore, we will be manually executing steps that are regularly automated to show the full process.
And so being repetitive is required. GitHub allows you to manage your code through version control, but also your environment and processes. GitHub provides developers some control of the operations of their code and gives them the ability to serve themselves and become agnostic to operations.
Intensive mission control resource hierarchy. We have a cluster of groups and workspaces close to groups allow you to organize your Carbonetti clusters into logical groupings. For example, you can use cluster groups to align with business units like grouping clusters into finance or e-commerce.
Maybe you want to group your clusters as far as customers separate, you know, banks from federal from local customers or for example, you want to separate your clusters into teams like development production, front end. You can get really creative when you attach or provision a cluster in terms of mission control, you specify the cluster group to to which the cluster belongs. So cluster groups are required intensely tend to mission control.
This gives you a new level of control over multiple clusters that are related. You can then affect these groups clusters from TMC regardless if they're on the same provider or not giving you incredible flexibility in the application. You we have workspaces that allow you to take an application or a workload view of your environment and then organize or manage name spaces into logical groups across the cluster, for example, to align with development projects.
And in an attached cluster, you can have both managed and and manage name spaces. When you create a namespace in an attached or provisioned cluster, you specify the workspace it belongs to. You can also add an existing namespace to a workspace in a workspace.
You can add a new role binding that will only apply to your cluster or workspace level and assign it to other users. So the first thing we're going to do is create a brand new cluster. So in our hierarchy of objects, the group manages.
Are groups opposed because, again, we can have thousands of clusters all over different cloud providers on premise as well. All we really have to do is rename the file to Correction and change the name field collection as well. It's exactly the same file as you have in development.
And we save that file and commit to get. And we're going to check our see. To make sure that a bill treaders.
And as you can tell right there, build a wall, so you build. Scrolling down. We see that since the cluster did not exist, now teams in ground cluster.
And there we go, we have our production cost. And it's that easy to to segment on separate and group little clusters that you need to. Now to create a new cluster.
We're going to follow the pretty pretty much the same procedure. We're going to duplicate our development cluster yellow file, rename our file to production. And choose the name as well.
You change a couple of fields, like changing the cluster group to production. Want this to be highly available as well. So we're going to be listing all of the available and all the other availability zones that can manage the.
And we're going to also just make sure we change all the fields of development to production. And the last little detail, we're going to increase the word count as well. Since this is in production, you want this to be highly available and you want there to be sufficient workers to carry out the tasks that you need, and again, we save this file and commit the file to get us.
And taking our city to see the built eighty two is now one or two and scrolling down also since this cluster did not exist, it's automatically being created by transmission control. At this point, our next task is to create a production of space. So we're going to go to our workspaces and follow the same pattern.
Duplicate the file, rename it for production. Well, in the fall, we're going to change the name to production. And to have to get more triggering another.
So this new workspace gets created. We're adding our message to our source control, give us. I was reading that Mrs..
So here's to. To find any news was currently pending. Go.
However, our latest is. So in the outfit you see, again, since it didn't exist, the workspace got created by a sense of mission control. And our workspace has been added besides our default of production on the standard workspaces.
Up next, we're going to change who can access our production cost to. So we're going to duplicate our development policy before and we're going to change the name and we're also going to change the role. So whoever has access to the sports face, instead of being able to edit like they were in development, it's going to be changed to you only since this is production.
Understandably, we just want. Had to be able to count on real changes and pregnant women and the well will solve the problem to production, distinguish it from development. We're going to save this while.
And then go over to our son's little. And. Just before.
That we changed our access policy, leaving a trail, so the good thing about collapse is that it leaves a trail of reaction and you can always roll back, which is great. You can go back to your previous comment and go back to an environment you had previously was prior to about. And as you can see, the eighty four bills had been kicked off.
Spending and now it's ready to. So you can take a look at it. So what happened was that we had a policy already existing.
And it was updated on that of the successful. I'm looking at our policies in the sense of mission control, you know, explosives. You see the.
The different. Policies that we have. New development.
Now, one of the last things we're going to do is create a new production image of. So we're going to go to policies he makes and duplicate the previous energy policy that we had or our development question. So then we're going to change the name to Acme Fitness production just before.
And we're going to also do is change the. Registry. So right now, we're using Google Container Registry.
When you change that to an open source. Registry, Poltava, that does automatic scans of all these things. And we had in.
Barbara. And as you can see, there's no direct policies at the moment, so we want to. As before, calling best practices instead of, say, file.
Ensenat. Can. To find out what's going on and again, that just saving our code kicked off the new unbuild.
So when. And going back to our policies, we see our new policy has been added. Is that is.
So the very, very last thing we're going to do. His upgrader development question one, that 83. So go to our development cluster, you can see that we're currently on version one, that 17.
And we're going to raise that and go to version one that. And also the same for our other loans on their loans. And.
And saving the. Getting the message that we're operating at close to. And as expected, our newbuild kicked off.
Already, of course. There we can see our development question updating on our production posture, and they are both holding. The.
And again, we can go back to any of these states and we were in and that goes for all the clusters regardless where they are at.