Shulou(Shulou.com)06/02 Report--

Jieshao

In this article, we will show you how to connect the Auto DevOps capabilities of GitLab with Kubernetes clusters managed by Rancher, taking advantage of the capabilities of authorized cluster endpoints introduced in Rancher v2.2.0. Through this article, you will have a comprehensive understanding of how GitLab integrates with Kubernetes, and how Rancher uses authorized cluster endpoints to simplify the process of this integration. This article is ideal for Kubernetes administrators, DevOps engineers, or anyone who wants to integrate their development workflow with Kubernetes.

Background

What is GitLab Auto DevOps?

Auto DevOps is a feature introduced in GitLab 10.0 that allows users to set up DevOps pipes that automatically detect, build, test, and deploy projects. Using GitLab Auto DevOps with Kubernetes clusters means that users can deploy applications without configuring CI / CD resources and other tools.

What is the authorized cluster endpoint of Rancher?

Starting with v2.2.0, Rancher introduced a new feature called Authorized Cluster Endpoint, which allows users to access Kubernetes directly without proxying through Rancher. Prior to v2.2.0, if you wanted to communicate directly with the downstream Kubernetes cluster, the user had to manually retrieve the kubeconfig file and the API server address from each node. This not only increases the complexity of the operation, but also does not provide a mechanism to control the refinement permissions available when managing the cluster through Rancher.

Starting with Rancher v2.2.0, when deploying Rancher-managed clusters, the authorized Cluster Endpoint (ACE) feature is enabled by default. ACE pushes some of the Rancher authentication and authorization mechanisms to downstream Kubernetes clusters, allowing Rancher users to connect directly to these clusters while still complying with security policies.

If you have explicitly granted permissions to a user in some projects, these permissions will automatically take effect when the user connects using an authorized cluster endpoint. Now, whether users are connected to the Kubernetes cluster via Rancher or directly, security can be guaranteed.

This is explained in more detail in the documentation that authorizes the cluster endpoint function:

Https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint

Note that currently, authorizing cluster endpoints is only applicable to downstream Kubernetes launched with Rancher Kubernetes Engine (RKE). In order to interface GitLab Auto DevOps with the Kubernetes cluster managed by Rancher, you need to be ready for implementation:

A GitLab.com account, or an account on a self-hosted GitLab instance (if Auto DevOps is enabled): the GitLab.com account needs to be configured with Auto DevOps. If you are using a self-managed GitLab instance, you can refer to this GitLab document to learn how to enable Auto DevOps: https://docs.gitlab.com/ee/topics/autodevops/

Run a Rancher instance of version 2.2.0 or later: you can start Rancher (https://rancher.com/quick-start/) in single node mode, or you can create a HA installation (https://rancher.com/docs/rancher/v2.x/en/installation/ha/).

Kubernetes cluster managed by Rancher: you also need a cluster that is configured through RKE and managed on Rancher. In addition, there needs to be an administrator user in the cluster, and if you are using GitLab.com, you need to access the control plane node through the public network.

Set up Rancher and Kubernetes

First, we need to set up Rancher and Kubernetes first. The first part of the process mainly involves the collection of information.

Note that for simplicity, these steps use the default admin account in Rancher. Best practices require that you use an independent user to perform such a process and restrict that user's permissions to the cluster where GitLab is being integrated.

Log in to Rancher and navigate to the downstream cluster you want to integrate. In this demonstration, we will create a cluster called testing on the EC2 instance, which runs in Amazon:

On the dashboard of the cluster, click the Kubeconfig File button at the top. This opens the file for the kubeconfig cluster, which includes information about authorizing the cluster endpoint.

The first entry in the kubeconfig file is through the cluster endpoint of the Rancher server. Scroll down to identify the authorized cluster endpoint for this cluster, which is listed as a separate cluster entry:

In my example, the name of this cluster is testing-testing-2, and the endpoint server is the public IP provided by AWS.

Copy the values of the server and certificate-authority-data fields, excluding quotation marks, and save them.

Scroll down further in the kubeconfig file and find your user name and token:

Copy the token field (excluding quotation marks) and save it.

Next, decode the base64 version of the certificate authority data, convert it back to the original version, and save it. Depending on your tool, some possible options include:

Set up the GitLab project

With the information we gathered from Rancher, we can now configure GitLab. We will first create a new project in GitLab that will integrate with our Kubernetes cluster using Auto DevOps functionality.

First, log in to GitLab, and then select New Project.

On the New Project page, select the create from template tab. This will provide you with a list of template projects to use. Select NodeJS Express, and then click Use template:

Name the project and set the visibility level to Public. Click create Project when you are finished.

Note that as I write this article, the visibility level can be set to "private", but this is GitLab's Auto DevOps experiment. In the menu pane on the left side of the project page, select Settings > CI / CD. Expand the Environment variables section and set the following variables:

We will disable the features shown in the following figure this time because our simple example does not need them for the time being, and they will extend the time required for deployment. In a real project, you can enable some of these options based on your actual needs:

Click Save variable to complete the GitLab project configuration.

Connect GitLab and Rancher

We are now ready to integrate our GitLab project with a Rancher-managed Kubernetes cluster.

In GitLab, select the newly cloned project. In the left menu, select Action > Kubernetes. Click the green add Kubernetes Cluster button. On the next page, select the add existing Cluster tab.

Complete the appropriate fields according to the following information:

Click add Kubernetes Cluster. GitLab will add the cluster and create a new namespace in it. You can check the Rancher interface to confirm that the newly created namespace has been created successfully.

Note that the first thing GitLab does when connecting to the cluster is to create a namespace for the project. If you do not see the creation of namespaces after a period of time, there may be some problems.

After you add the cluster to the GitLab, a list of applications to install into the cluster is displayed. The first one is Helm Tiller. To continue, click install to add it to the cluster.

Next, install Ingress, which will allow GitLab to route traffic to your application:

Depending on how you are configured to join the group, your entry endpoints may or may not be populated automatically. In this tutorial, I will use the xip.io hostname to point to traffic to a single node. As for your use case, you may need to set the wildcard field and point it to this ingress (or point to your node IP, etc.).

Once the ingress is deployed, scroll to the top of the page and locate the basic Domain field. Enter the public IP address of one of the nodes, and then enter .xip.io. This will create a wildcard field that resolves to the IP address, which is sufficient for our example:

Next, in the navigation bar, select Settings > CI / CD. Expand the automatic DevOps section and select the default automatic DevOps pipes box. This not only means that Auto DevOps has been set to the default value, but it can also trigger the build. Set the deployment Policy to continue deploying to production:

After checking the Auto DevOps box, the pipe operation will begin. Navigate to the CI / CD > pipe in GitLab. You should see something similar to the following figure, which indicates that GitLab is deploying your application:

Verify deployment in Rancher

Let's go back to Rancher and take a look at our deployment to see how the resources are converted to Kubernetes objects in the Rancher interface.

In Rancher, navigate to your entry, and then click Projects / Namespaces in the top navigation menu.

GitLab creates two namespaces on your behalf: one is gitlab-managed-apps, and the other is the only application namespace. The gitlab-managed-apps namespace contains resources, such as nginx and Helm tiller instances used to deploy the application. The only namespace for that application contains the deployment of the application.

To further visualize these, we can move these namespaces to our Default project. You can also use any other project. Click the move button, and then select the project you want:

After moving the namespace, navigate to the project to which they belong, and then navigate to the Workloads page. This page displays your new deployment in its application-specific namespace:

Note the 443 / https link under the deployment name. Click this link and you can jump to the ingress of the wildcard domain for your deployment. If all goes well, you will see this page that symbolizes success:

Conclusion

Congratulations! You have just successfully connected GitLab's Auto DevOps to a Rancher-managed Kubernetes cluster using authorized cluster endpoints for a more secure and direct connection!

When exploring other areas of Rancher, you may notice other objects that GitLab has created for you in your name. For example, the load balancing tab displays the deployed L7 ingress and the hostname created. You can also view the internal services of the deployed application under the Service Discovery tab.

GitLab's Auto DevOps feature is not only easy to use, but also customizable and powerful. In the demonstration of this article, we disabled some advanced features, such as automated testing, dependency scanning, and license management. These features can also be re-enabled at a later stage and provide more unexpected convenience and value to your development environment by configuring GitLab. In addition to Auto DevOps, GitLab also provides A. gitlab-ci.yml file for CI / CD, which allows users to make more extension customizations. You can learn more in the GitLab documentation:

Https://docs.gitlab.com

One of the great values of building CI / CD pipeline Kubernetes on Kubernetes and Rancher is to optimize the development process for enterprises, and the integration of CI workflow and Kubernetes is an important part of most teams.

Tomorrow night, Rancher will hold a free online training on "how to build a CI/CD assembly line". In this live broadcast, we will share:

How to dock GitLab

Build an image

Publish the image to the built-in image repository

Publish an image to a remote repository

Deploy applications through pipelining

Publish your own apps through the app store

How to set up pipeline notification

You can go to the link: http://live.vhall.com/729465809 to book this course, and use the same link to watch the live broadcast on Wednesday night!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.