GitLab Configure Stage, 18 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Migrate from GMA to a Cluster Management Project

Description

This video explains the steps needed to take control of your previously installed GitLab Managed Apps, and start managing them through the a Cluster Management Project template. The video also cover the case where you have Helm v2 applications installed in your cluster.

A

I'm john cuny working for the configured team at gitlab and today I'm going to show you an example of how we can migrate from get lab, managed apps to a cluster management project template.

A

So for the purpose of this video, I will have some assumptions first, that you know what helmet is about and you have the helm, client v3 installed in your local environment as well as the helm, 223 plugin, also I'll assume that you have a project which has already a cluster associated to it.

A

So, let's start in my case. I have this website project that you can see and if I go to infrastructure kubernetes, I should see the list of cluster. So let's dig into my cluster website cluster and if I go to advanced settings, I can see that I have no cluster management project associated to this cluster.

A

Yet and that's what we're going to do if you have installed your managed apps via the ci cd old way of installing managed apps, then you probably already have a cluster here and you could create a new project for this cluster.

A

Otherwise, if you use the one-click way of installing managed apps, then probably don't have any one like. I do not right now and in each case this procedure should work yeah the same. So let's go ahead and create this project, I'm going to go to this plus icon and click on new project.

A

I'm going to choose to create from a template and scrolling down. We can find the gitlab cluster management template. Let's use this one, let's call it demo cluster manager and create project. Now.

A

Let's wait for the import to finish.

A

Okay, now I should go back to the project where I have my cluster associated to and when I try to select a management project. The new project should show up in this list.

A

For my case, it's demo cluster manager, I'm going to save changes.

A

Okay, now that I have the cluster management project associated with my cluster, I will go back to the project where I manage the cluster and the first thing I'm going to do is to start a pipeline manually, so this means going to ci cd pipelines.

A

Now, I'm going to click on run pipeline.

A

I'm going to run up applying for the massive range and I don't need any special variables to it. So I'm just going to confirm and click run pipeline again, and this pipeline has two jobs: a detect, helm, 2 releases and an apply job apply. Job only runs if the tech 2 hem 2 releases passes first.

A

If applications with helm2 releases are detected, then this job should fail. If not, it will pass, and this is because, depending on the version that you used for gitlab to install your gitlab managed apps, it could be that you install the managed apps with helm, v2 or helm v3.

A

But since this project template uses hound v3 and that's the recommended version to use from now on, we should migrate all the helm, v2 releases to helm, v3 and that's what this job is helping us to do is detect them. So if it failed, probably it has some hemp of releases, let's just check them out by clicking there. So I see the message held. The two releases found in the name. Spacecraft live, managed, apps, but we are using hundred three, so please migrate to releases using the helm two to three plugin. That's the plugin!

A

I talked to you about the beginning of this video. I can also see which releases I have installed in in my case. It's ingress and it's installed in the gitlab managed apps namespace.

A

If I had more, they would also be listed here. So now, let's go to our local environment. We can open a terminal session and I'm going to check first helm. Alas, namespace get lab, managed apps to see that I have no releases under the helm, v3 installation.

A

And now what I'm going to do? I'm going to convert the helm v2 releases to handle 3 using this command so helm? Two two three convert release the storage config maps because that's where helm2 was using uh was keeping the releases to lay out closer because we were using uh what we call tillerless helm to install the applications.

A

The name space they are installed to is gitlab managed, apps. The name of the release is ingress and we have the option of running with dry run, which basically is going to simulate. If what would happen, if you would run this command for real, we can try this one first and see what happens so. Basically, it just confirms that uh this is driver mode. No, following actions will be executed, but it basically tells us that yes, uh uh release of helm with with helmet 3 of ingress v1 will be created.

A

So let's go ahead and do this this time without the last flag that I run so we can actually execute the correct command.

A

All right so now, if I run helm elas within the namespace of get lab, managed apps again, we should see yes, the ingress is already recognized by the helm v3, although this command it does not remove the helm, v2 releases that you also have in your cluster. It just maps the release version 203 as well. So what we should do to make that job, that the text helm v2 releases pass now is actually to remove the helmet to releases history.

A

Let's say like this, although if you had more applications that were installed the founder 2, I recommend that you follow this step to migrate all the applications right now and then remove all at once, which is what we're going to do right now.

A

So we're going to run the command helm223 cleanup skip confirmation because we don't need it here: release the storage same thing till the route same thing and the namespaces get laminated apps. So it's going to clean up all the releases that we have for helm, v2, keeping us only with the helm d3 one. So you can see that we got the release deleted, as confirmed in the message below.

A

If we check with helm v3 again, we can see that the v3 versions are still in place. So now, let's go back to our pipeline.

A

That was the pipeline that was failing at the time. What we're going to do now, I'm going to click on the job that failed and I'm going to click on this button to retry that job and now we expect that it will. It won't find any more many two releases.

A

So let's see the job in detail, okay, the job succeeded. So now we can go back to the pipeline, as you can see right now, the first job passed, but the following job failed. This is actually expected.

A

The next job is the one that's going to check our cluster and decide whether our application needs to be installed or uninstalled, but since we haven't set up any configuration for our project yet, regarding which applications we want to manage, this job fails on the first run. But let's do this: let's go back to the root of the project and we're going to open up the web id. So we can change some files.

A

Right so we have this helm file in the root directory, and here we have the list of applications that we want to manage. They are all commented out by default.

A

In my case, I want to manage ingress, so I'm going to uncomment this line and remember to keep two spaces here for proper identitation.

A

Also. I want to configure ingress correctly, so I don't get like any unexpected updates or anything like this. For this we're going to open up the applications folder and go to the ingress folder here we have also a helm file.

A

This helm file describes what are the setup that we want to have for our ingress release in this case, by default we suggest to install 142 version and we want to make sure that we keep the same version that we have installed already so for this I'm going to go back to the terminal, and if you can see right here when we run the helm, elast command, we already have the version that we're running printed out, which was 141.3 right here. So I'm gonna go ahead and just use this one.

A

Instead, this should guarantee a smoother migration when we run the pipeline, the rest of the attributes just state the name of the chart and the release, and also that we are taking custom values from the values.the ml file.

A

If we check this values.mfi, which is right here, it also has a set of defaults, but I also want to make sure that if I had my previous ingress installed with some specifics, that I want to keep the same specifics, so I'm going to go back to the terminal and run this command that I've had previously put here, so helm, get values ingress in the gitlab, managed apps, namespace output, the values to a yaml result.

A

Since I'm on mac. I can use this pb copy to copy the results of this output. Already to my clipboard.

A

But just to show the results as well: I'm going to print them here for you to see what the command prints out. It's basically mlresult and I'm going to now replace on this values.tml the values that I got from my existing release, it's okay, that it's much bigger than the other one.

A

um So, finally, also what we want to do since we already know that our job that uh the tax help to the releases has passed, we can also go to the gitlab.cieml file, and here you can see the two jobs that this pipeline was running. This one describes the detect hem2 and the next one is the one that describes the one that's going to install or uninstall our applications.

A

So I'm going to go ahead and comment out all this job, because I don't need it anymore. On my pipelines, I can also completely remove it if I want as well as I could completely remove the applications that I'm not interested in installing, like fluency falco elastic stack. If I don't need them, then I can also remove those folders which I'm not going to do right now.

A

But let's commit those changes. Now, I'm going to commit directly to master in my case feel free to open a merge request. If you prefer and say start managing ingress with the manage net project and I'm going to commit.

A

Let's go back to our pipeline, so by clicking here we go back to the project and go to ci cd pipelines.

A

New pipeline has been triggered with only one job. Only the deploy stage apply job because the detect 2 we have already removed. So, let's see what it's doing.

A

What is expected right now is that uh the job detects that helm v3 already has ingress installed on your cluster, um but it's possible that some values might get changed in this deploy. But if it happens, it should be simple jobs like this one, simple, sorry, simple attributes like this one, so heritage heritage changed it from tiller to helm. That's because on helmut v2, tiller was responsible for managing these installations, whereas now with helm, v3 helm itself takes care of them. So that's why we see those changes.

A

We could see some like removals of empty lines, but that's also irrelevant, and I don't see any major diffs in the release that we had before in comparison to the release that we are doing right now. So this means that our migration was successful.

A

The job also says it succeeded and what's interesting also if we run this job again, we shouldn't even see those diffs anymore, because now there's no updates to be done, so I would just run it once more, and this should be a even cleaner output from the apply job.

A

And there we go so this time there were no updates that the job had to do in our release.

A

So if you ever want to uninstall your applications, just remember: go back to your application's helm file and just toggle the installed attribute to install them or uninstall them. Also, you can upgrade and downgrade the version of your chart and you can customize values using the values.tml, that's inside of your application, folder.

A

That was it for this tutorial. I hope this made a little bit clearer how to manage applications with the cluster management project template. Thank you.