Quickly deploy using GitLab and build DevOps projects in K8s

Author: Zhang Haili, Ambassador and Talented Speaker of KubeSphere Community, Deputy Head of Community User Committee Shanghai Station

Original link: https://kubesphere.com.cn/blogs/kubesphere-gitlab-devops/

At the beginning of the new year, "GitLab" cooperated with Qingyun (QingCloud public cloud service and KubeSphere container platform), Shanghai Cloud Axis (ZStack Cloud cloud platform and ZStack Cube hyper-converged all-in-one machine), Baode Computing, Shanghai Hengyue and other domestic Well-known cloud manufacturers and server manufacturers, the first GitNative series product solutions, launched the 'GitNative integrated DevOps platform' and 'GitNative CI/CD pipeline engine' that support public cloud, private cloud, and local data center deployment for different deployment environments and application scenarios ' solution."

When I saw the above news in the community, I felt a "tiger body shocked". I am really happy to see that the domestic cloud community and cloud manufacturers can cooperate with such down-to-earth commercial products in the field of DevOps. I believe The emergence of more such cross-border cooperation products will also promote the further development of our domestic DevOps community and products. So for our small partners in the open source community, through the DevOps capabilities provided by the GitLab Community Edition and the KubeSphere platform, you can actually try to build a similar DevOps platform to experience the charm of the GitOps system in the Kubernetes era.

Therefore, we will share with you this time to practice deploying GitLab CE (Community Edition Community Edition) on KubeSphere and building a DevOps project linked to it.

Preconditions

Install KubeSphere

There are two ways to install KubeSphere. One is to install directly on Linux, you can refer to the document: Install KubeSphere on Linux; the other is to install in existing Kubernetes, you can refer to the document: Install KubeSphere 16209ccc897c37 in .

Enable DevOps Suite in KubeSphere

To enable DevOps suite in KubeSphere, please refer to the document: Enable Pluggable Components · KubeSphere DevOps System . After the installation is complete, you can see the Jenkins avatar icon in the "System Components" section of the "Platform Management" page.

KubeSphere DevOps system based on Jenkins is specially designed for CI/CD workflow in Kubernetes, it provides a one-stop solution to help development and operation and maintenance teams build, test and publish applications in a very simple way Kubernetes. It also has plugin management, Binary-to-Image (B2I) , Source-to-Image (S2I) , code dependency cache, code quality analysis and other functions. The text will only cover the part of KubeSphere DevOps on the use of pipelines.

Install GitLab CE

Let's create an enterprise space named devops for this walkthrough, and create a project named gitlab for GitLab CE deployment.

Deploy GitLab applications from the application repository

First of all, we still need to add GitLab's official Helm Chart warehouse to the devops enterprise space. It is recommended to use this self-management method to ensure that the warehouse content is synchronized in time. Add the following GitLab repository (repository URL: https://charts.gitlab.io/ ) through "Application Repository" under "Application Management".

Next, enter the previously created gitlab project, and create a GitLab application from the "Application" page under "Application Load": select "Create from Application Template" to get the following interface. Since there are many Helm Charts that can be installed in the warehouse, pay attention to the selection. The application indicated by the red box (at the time of writing the latest version of Chart is 5.7.0 , for GitLab version 14.7.0 ).

The following step is very important, and you need to configure the parameters of the Helm Chart deployment application. Since GitLab has a lot of default configurable items (thousands of lines), this time we only select to rewrite the relevant parameters of the minimum function set that can guarantee basic business use. For the meaning of each parameter, please refer to the parameter Comment on the line above the item (and pay attention to the Note section). For other configuration items, please refer to GitLab Helm Chart Quick Start Guide and complete property list .

global:
  ## 确保使用的版本是 Community Edition
  edition: ce
  
  ## 全局 Host 配置：https://docs.gitlab.cn/charts/charts/globals.html#host-%E9%85%8D%E7%BD%AE
  #【注意】这里我们只绑定 GitLab 主体服务的域名，其它都可以使用默认值（不影响演练使用）
  hosts:
    #【注意】这个基础域名需要是 “部署 GitLab 的集群” 内可以访问的域名，否则各组件互联可能存在问题
    domain: example.com
    #【注意】我们演练环境为了部署方便不启用 HTTPS，否则需要提供和填写的基础域名对应的证书
    https: false
    gitlab: 
      name: gitlab.example.com

  ## 全局 Ingress 配置：https://docs.gitlab.cn/charts/charts/globals.html#ingress-%E9%85%8D%E7%BD%AE
  ingress:
    #【注意】我们由于全面关闭 HTTPS，所以这里也需要关闭 GitLab 自带的证书生成器
    configureCertmanager: false
    #【注意】由于默认是使用自带 Nginx，即使用 "gitlab-nginx"，需要改为 KubeSphere 网关适配的值
    class: nginx
    #【注意】默认是 true，需要强制关闭 HTTPS，和其它配置保持一致
    tls:
      enabled: false
  
## 自带的 cert-manager 配置：https://github.com/jetstack/cert-manager
#【注意】这里强制选择不安装 cert-manager
certmanager:
  installCRDs: false
  install: false
  
## 自带的 Nginx Ingress 配置：https://docs.gitlab.cn/charts/charts/nginx/
#【注意】由于演练会直接使用 KubeSphere 项目/集群网关，这里直接关闭此项的安装配置
nginx-ingress:
  enabled: false
  
## 自带的工件仓库组件：https://docs.gitlab.cn/charts/charts/registry/
#【注意】由于不开启 HTTPS，使用各类工件仓库会有问题，这里建议就直接关闭此项安装配置
registry:
  enabled: false
    
## 自带的 MinIO 配置：https://docs.gitlab.cn/charts/charts/minio/
#【注意】由于可以后续自行在 KubeSphere 中开启应用路由，这里建议直接关闭网关路由配置
minio:
  ingress:
    enabled: false
  
## 自带的 GitLab Runner 配置：https://docs.gitlab.cn/charts/charts/gitlab/gitlab-runner/
#【注意】由于演练环境我们直接接入 KubeSphere DevOps 做 CI/CD，这里建议就先不安装 Runner 
gitlab-runner:
  install: false

Although it has been deployed with the minimum feature set, the deployment process is still relatively long due to the high cost of deployed services and their resources. After the deployment is complete, you can view the status of all workloads in the "Workload" section of the gitlab application.

At this time, the gitlab application state is in the process of being created at , which is caused by the application deployment timeout. As long as all workloads can enter the running state normally, it will not affect the normal use of the application.

Due to the long deployment time, it is easy to cause the comfort bucket task of the MinIO component to fail. It is recommended to check the gitlab-minio-create-buckets-1 task under "Application Load". If it fails, you can "re-run" through the "More Operations" on the left side of the details page, and finally get Completed (1/1) status can be considered successful.

After confirming that all workloads are running, if you have previously configured the cluster or project gateway and enabled the domain name resolution of gitlab.example.com , you can directly access the domain name to open the GitLab site page.

For how to set up a cluster or project gateway in KubeSphere, you can refer to our previous technical blog . Also make sure that your gateway can directly use the HTTP standard **80** port to provide access!

Create a sample project in GitLab

First let's log into GitLab. The initial password of GitLab is saved as Secret. We can go back to the project home page and search for initial in the "Secret Dictionary" under "Configuration" to find the entry for gitlab-initial-root-password . Click on the dictionary entry and click the eye icon on the far right in the "Data" section to display the contents of the password data item.

Copy the password and use root as the username to log in to GitLab and get the interface as shown below.

Click the "New Project" button to enter the page for creating a project. Through "Create from Template", we can create a sample project for later pipeline drills.

Let us choose the project template NodeJS Express to create an application. All templates can preview the content through the Preview button. After using the template, you will get the following interface for creating a project.

Fill in your preferred project name, and select the default Private in Project Visibility to create a private project, which is convenient for subsequent demonstrations if you access the private project. After importing, you can get the following project page.

Turn off Auto DevOps and create a Jenkinsfile

Since we will use KubeSphere DevOps in the future, and GitLab has the Auto DevOps function enabled by default (it will automatically provide pipeline support for projects without CI configuration), in order to avoid confusion, we temporarily turn off Auto DevOps.

Find the file and function shortcut entry area in the middle of the project page, click the "Auto DevOps enabled" button block, enter the configuration page, uncheck Default to Auto DevOps pipeline and "Save changes" to complete the closing of the Auto DevOps function.

Next, we also need to create a Jenkinsfile for this project for subsequent KubeSphere DevOps pipeline builds. Create a file named Jenkinsfile directly under the master branch, and fill in the following content.

pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
                echo 'Hello World'
            }
        }
    }
    post { 
        always { 
            echo 'I will always say Hello again!'
        }
    }
}

Pipelining GitLab with KubeSphere DevOps

We first create a DevOps project named demo in the enterprise space at devops for a follow-up walkthrough of how to create a pipeline for GitLab.

Bind GitLab with KubeSphere Jenkins

Since the default GitLab service bound by KubeSphere Jenkins is the official gitlab.com , it is necessary to re-bind to the private GitLab service we created before creating the pipeline.

First, we need to open the KubeSphere Jenkins page. For the convenience of operation, we directly open the NodePort for kubesphere-devops-system under the devops-jenkins namespace.

Use the KubeSphere account to log in to Jenkins ( If the login fails, it may be an account synchronization problem, you can change the password once and try again ). Enter the system configuration page through "Manage Jenkins ➡️ Configure System", find GitLab Servers configuration area, and click "Add GitLab Server" to start adding our GitLab service.

As shown in the figure above, there are three configuration items that need to be filled in or edited:

• Server URL : Fill in the access method of the GitLab service we just deployed here (if it is a domain name access, it must be a domain name that can also be reached by Jenkins)
• Crendentials : Select or create a credential item for Jenkins here. The credential needs to be the Personal Access Token of a user in GitLab (we will continue to explain how to create it below)
• Web Hook : This must be checked Manage Web Hooks , which is used for us to synchronize the status of Jenkins Pipeline to our GitLab service later

Create Jenkins Credential for GitLab Personal Access Token

First, let's go back to GitLab, you can directly access the creation page of Personal Access Tokens through <gitlab-url>/-/profile/personal_access_tokens (for example, [http://gitlab.example.com/-/profile/personal_access_tokens](http://gitlab.example.com:30433/-/profile/personal_access_tokens) can be used in this article). As requested by Jenkins, we create a token named jenkins with api `read_repository `write_repository permissions, copy the token string for later use.

Then we go back to the Jenkins home page and enter the credential creation page from "Manage Jenkins ➡️ Manage Credentials ➡️ Stores scoped to Jenkins ➡️ Jenkins ➡️ Global crendentials (unrestricted)".

Click "Add Credentials" on the left panel to start creating the credential. After filling in, click Ok to save to complete the credential creation:

• Kind select GitLab Personal Access Token
• Scope select the default Global , ID fill in any ID that does not cause naming conflicts
• Token Fill in the GitLab token string you just copied for backup (ignore the string length prompt)

After completing this part of the configuration, the status of the KubeSphere DevOps pipeline will also be linked with the status of the Pipeline in our GitLab. You can see the effect in the video.

• https://www.bilibili.com/video/BV18U4y1T7tv

Create a KubeSphere DevOps pipeline using Jenkinsfile

Let's go into the demo DevOps project we created earlier and start "creating" the pipeline.

In the "Create Pipeline" dialog box that pops up, we fill in a pipeline "name" and click the "Code repository (optional)" area below to bind the code repository.

After entering the "Select Code Repository" panel, we select GitLab tab, and then in the "GitLab Server Address" drop-down box, select the GitLab CE server that we added to Jenkins in the previous section.
Since we are practicing private repository access, we need to select a credential to access the private code repository. If it has not been created before, here we click the green "Create Credential" link to start creating it.

In the pop-up "Create Credential" dialog box, enter the "Name" and select the type as username and password; then enter our account root in the "Username" text box, before entering it in "Password/Token" The initial password obtained from the secret dictionary.

After saving the certificate through the "OK" button, go back to the "Select Code Panel", select the just created gitlab-root in the "Certificate" drop-down box, and then fill in our account root in the "Project Group/Owner" text library, click " You can see all the code repositories under the root account in the "Code Repository" drop-down box. Here we can see and select the previously created example project root/nodejs-demo .

After confirming and saving the configuration through the ☑️ button, you will return to the "Create Pipeline" panel again. At this time, you can see that the root/nodejs-demo project we selected has appeared in the "Code Repository". Click "Next" to enter the "Advanced Settings" tab, here we Without any additional configuration, just click "OK" to create the pipeline. After the creation is successful, we can see the following "branch number" is 0 and a healthy pipeline.

A moment later, click to enter the new file pipeline, and you can see that the system has scanned the master branch with Jenkinsfile and has started to run the pipeline.

Click master branch to enter the branch details page. Regardless of whether the operation is successful or unsuccessful, you can further click the serial number in the "Run ID" column to view the detailed operation log and products.

After waiting for a period of time, the operation is successful, and you can see the interface shown in the following figure by entering the operation record with the operation ID of 1 . Further, we can click the "View Log" button in the upper right corner to understand the detailed pipeline execution.

Note: For a multi-branch pipeline, the checkout scm step will be executed by default, and then the pipeline content defined in the Jenkinsfile will be executed.

Create a KubeSphere DevOps pipeline using a graphical editor

This section can refer to the official KubeSphere documentation: DevOps User Guide / Using DevOps / Creating a Pipeline Using the Graphical Editing Panel

KubeSphere DevOps pipelines can also be created through the graphical editing interface. Let's go back to demo DevOps project home page and "create" a new pipeline. This time, in the "Create Pipeline" panel, we do not bind the code repository, just "Next" and "Create" a pipeline named gui directly.

After entering the pipeline details page, we can see the "Edit Pipeline" button on the right panel. After clicking, in the "Select Pipeline Template" dialog box that pops up, we select custom pipeline.

The other two pipeline templates contain more complete examples of CI / CD pipeline construction, but the content is relatively complex. You are welcome to choose and experience offline!

Let's try to reproduce the two steps of the previous section with a graphical editor, that is, pull up the code and print a Hello World message. First, we click the + button on the left panel, and then select one of the added stage blocks.

Then we click "+ Add Step" on the stage block on the left, and select the step git in the "Add Step" panel on the right, and fill in the address of our sample code repository in the pop-up dialog box. HTTP Git address ( For example, [http://gitlab.example.com/root/nodejs-demo.git](http://gitlab.example.com/root/nodejs-demo.git) ), the certificate is gitlab-root created before, and the branch is master .

After completion, we draw the gourd according to the pattern, add a print message step again and fill Hello World! as the content, and finally get the overall effect as shown in the following figure.

After editing, click "OK" and then "OK" to save the pipeline. After returning to the details page, you can use the "Run" button in the upper right corner to execute the pipeline.

After the operation is successful, you can view the pipeline operation record again, and view the operation log, and get the result as shown in the following figure.

[Extra] Use SSH to access the GitLab code repository in the Kubernetes cluster

The access methods of the code repository described above are all in the form of HTTP, but the most commonly used access method in real work is the SSH access method. Is it possible to pull and push the code directly through git clone [e-mail]:root/nodejs-demo.git ?

The answer is yes: yes! But there is a big hole to pay attention to - the default SSH port is 22 , but after adding a layer of Kubernetes network, regardless of whether this default port is used or not, it is necessary to deal with how GitLab exposes the SSH service to the outside world.

Assuming we can accept rebinding a port to use GitLab SSH, we can do this:

• First, we go back to the GitLab deployment project, find gitlab-shell service and open the NodePort external access port for it

• Based on this port, change the addresses accessed by Git to the form of ssh://git@<gitlab-url>:<gitlab-shell-port>/<username>/<repo>.git , such as ssh://[e-mail]:32222/root/nodejs-demo.git

Written at the end: Thank you for being so patient with this entire tutorial! If you think it is a bit challenging to deploy these contents by yourself, I recommend you to take a look at some commercial products of GitLab and KubeSphere Cloud , so that professional people can do professional things and free everyone's time better. Polish your business product. I also look forward to seeing more positive interactions between open source communities and commercial products, and together we will promote our domestic software industry to "take the lead in the year of the tiger, and be more generous than ever"!
This article is published by the blog OpenWrite !