Zhang Haili, Deputy director of Shanghai Station of KubeSphere Community Ambassador and Talented Speaker, Community Users Committee
The original link: kubesphere.com.cn/blogs/kubes…
At the beginning of the New Year, “GitLab has cooperated with QingCloud (public Cloud service and KubeSphere container platform), Shanghai Cloud (ZStack Cloud platform and ZStack Cube hyper-converged integrated machine), Baode Computing, Shanghai Hengyue and many other well-known Cloud manufacturers and server manufacturers, The first GitNative series of product solutions, for different deployment environments and application scenarios, launched the ‘GitNative Integrated DevOps platform’ and ‘GitNative CI/CD pipeline engine’ solutions that support public cloud, private cloud and local data center deployment.”
When the community saw the above news, it felt like “tiger body shock”. It was really nice to see that the domestic cloud community and cloud manufacturers could have such a down to earth commercial product cooperation in the field of DevOps. I believe that the emergence of more such cross-border cooperation products will also promote the further development of our domestic DevOps community and products. So for those of us in the open source community, the DevOps capabilities provided by GitLab Community Edition and KubeSphere platform, In fact, you can also try to build a similar DevOps platform to feel the charm of GitOps system in the era of Kubernetes.
So in this post, we will work with you to get your hands on deploying GitLab CE (Community Edition) in KubeSphere and building a DevOps project that works with it.
The premise condition
Install KubeSphere
There are two ways to install KubeSphere. Install KubeSphere on Linux. Two is in the existing Kubernetes installation, can refer to the documentation: Kubernetes installation KubeSphere.
Enable the DevOps suite in KubeSphere
To enable the DevOps suite in KubeSphere, refer to the documentation: Enabling pluggable Components · KubeSphere DevOps System. After the installation is complete, you can see Jenkins’ avatar icon in the System Building section of the Platform Management page.
Designed specifically for CI/CD workflows in Kubernetes, the Jenkins based KubeSphere DevOps system provides a one-stop solution to help development and operations teams build, test, and release applications to Kubernetes in a very simple way. It also has plug-in management, binary-to-image (B2I), source-to-image (S2I), code dependency cache, code quality analysis and other functions. The text will only cover the KubeSphere DevOps section on pipelining usage.
Install GitLab CE
For this exercise, we will create an enterprise space called DevOPS and a project called GitLab for gITLab CE deployment.
Deploy GitLab applications through the application repository
First of all, we will add GitLab’s official Helm Chart repository to the DevOPS enterprise space. This self-management approach is recommended to ensure that the contents of the repository are synchronized in a timely manner. By “application management” under the “app store” to add the following GitLab warehouse (warehouse URL: https://charts.gitlab.io/).
Next go to the GitLab project you created earlier and create the GitLab application from the Application page under Application Load: Select “Create from Application Template” to get the following interface. Since there are many Helm Chart that can be installed in the warehouse, pay attention to the application indicated by the red box (the latest version of Chart is 5.7.0 at the time of writing, and 14.7.0 for GitLab version).
The following step is very important. You need to configure the parameters for Helm Chart to deploy the application. Since the default configurable items of GitLab are very large (thousands of lines), we only select the parameters related to the minimum function set that can guarantee the use of basic business for rewriting this time. For the specific meaning of each parameter, please refer to the notes on the line of parameter items (and pay attention to the [Note] section). For additional configuration items, see the Polar Fox GitLab Helm Chart quick Start guide and its complete property list.
global:
## Make sure the version used is Community Edition
edition: ce
# # global Host configuration: https://docs.gitlab.cn/charts/charts/globals.html#host-%E9%85%8D%E7%BD%AE
[note] Here we only bind the domain name of the GitLab principal service, the default value can be used for all others.
hosts:
# [Note] The underlying domain name must be accessible within the cluster where GitLab is deployed, otherwise there may be problems with the interconnection of components
domain: example.com
# [Note] Our drill environment does not enable HTTPS for deployment convenience, otherwise we need to provide and fill in the certificate corresponding to the base domain name
https: false
gitlab:
name: gitlab.example.com
# # Ingress global configuration: https://docs.gitlab.cn/charts/charts/globals.html#ingress-%E9%85%8D%E7%BD%AE
ingress:
GitLab's certificate generator needs to be turned off as well
configureCertmanager: false
KubeSphere gateway ADAPTS to KubeSphere gateway ADAPTS to "gitlab-nginx
class: nginx
The default value is true, forcing HTTPS to be disabled, consistent with other configurations
tls:
enabled: false
# # own cert - manager configuration: https://github.com/jetstack/cert-manager
No cert-Manager installation is mandatory
certmanager:
installCRDs: false
install: false
# # own Nginx Ingress configuration: https://docs.gitlab.cn/charts/charts/nginx/
Since the walkthrough will use the KubeSphere project/cluster gateway directly, the installation and configuration of this item will be turned off
nginx-ingress:
enabled: false
# # own artifacts warehouse components: https://docs.gitlab.cn/charts/charts/registry/
# [Note] Because HTTPS is not enabled, there will be problems using various artifact repositories, so it is recommended to directly turn off this installation configuration
registry:
enabled: false
# # own MinIO configuration: https://docs.gitlab.cn/charts/charts/minio/
KubeSphere (KubeSphere, KubeSphere, KubeSphere
minio:
ingress:
enabled: false
# # own GitLab Runner configuration: https://docs.gitlab.cn/charts/charts/gitlab/gitlab-runner/
We will install KubeSphere DevOps for CI/CD
gitlab-runner:
install: false
Copy the codeAlthough it is a minimum function set deployment, the deployment process is still relatively long due to the high cost of deployed services and resources. After the deployment is complete, you can view the status of all the loads running in the “Workload” section of the GitLab application.
At this time, the GitLab application state is being created, which is caused by the application deployment timeout. As long as all workloads can enter the normal running state, the normal use of the application will not be affected.
It is recommended to check the Gitlab-minio-create-buckets 1 task under Application Load. If the task fails, click More operations on the left of the detail page to restart the task. The final completed (1/1) state is considered successful.
After confirming that all workloads are running, if you have previously configured the cluster or project gateway and enabled domain name resolution for gitlab.example.com, you can access the domain name directly to open the GitLab site page.
You can refer to our previous technical blog on how to set up a cluster or project gateway in KubeSphere. Also, make sure your gateway provides access directly using the HTTP standard **80** port!
Create a sample project in GitLab
First let’s log on to GitLab. The initial password of GitLab was saved as Secret. We can go back to the home page of the project and search for Initial in the “Secret dictionary” under “Configuration” to find the entry of Gitlab-initial-root-password. Click on the dictionary entry and click on the eye icon on the far right in the Data block to show the contents of the Password data item.
Copy the password and use root as the user name to log in to GitLab and get the interface as shown below.
Click the “New Project” button to enter the page for creating the Project. Through the “Create from Template” button, we can Create a sample Project for the pipeline drill.
Let’s choose the NodeJS Express project template to create the application. All templates can be previewed by using the Preview button. After using the template, you will get the create project interface shown below.
Create a Private project by filling in your preferred project name and selecting the default Private in project visibility for subsequent demonstrations of how to access the Private project. After the import is complete, you get the following project page.
Close Auto DevOps and create Jenkinsfile
Since we are going to use KubeSphere DevOps later, and GitLab has Auto DevOps enabled by default (it will automatically provide pipeline support for projects without CI configuration), in order to avoid confusion, we will temporarily turn off Auto DevOps.
Find the file and function shortcut entry area in the middle of the project page, click “Auto DevOps Enabled” button block, enter the configuration page, uncheck Default to Auto DevOps Pipeline and “Save changes”. The Auto DevOps function is disabled.
Next, we also need to create a Jenkinsfile for this project for subsequent KubeSphere DevOps pipeline builds. Create a file called Jenkinsfile directly under the Master branch and fill in the following.
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
echo 'I will always say Hello again! '}}}Copy the codeUse KubeSphere DevOps to provide assembly line for GitLab
We’ll start by creating a Devops project called Demo in the Devops enterprise space for a subsequent walkthrough of how to create pipelining for GitLab.
Bind GitLab to KubeSphere Jenkins
Since the default GitLab service bound by KubeSphere Jenkins is the official Gitlab.com, it needs to be re-bound to the private GitLab service we created before creating the assembly line.
First, we need to open the KubeSphere Jenkins page. For ease of operation, we directly open the NodePort for Devops-Jenkins in the KubeSphere – Devops-system namespace.
Login Jenkins using the KubeSphere account (if login fails, it may be due to account synchronization problem, you can change the password again and try again). Go to the System configuration page via “Manage Jenkins ➡️ Configure System”, go to the 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 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 accessible to Jenkins)Crendentials: Select or create a Jenkins credential entry. The credential should be a Personal Access Token of a GitLab user (we will continue to explain how to create it below).Web Hook: This must be checkedManage Web HooksThis is used for us to synchronize Jenkins Pipeline status into our GitLab service later
Create Jenkins Crendential for GitLab Personal Access Token
First of all, let’s go back to GitLab, Can be directly through the < gitlab – url > / / profile/personal_access_tokens (for example, this article can use [http://gitlab.example.com/-/profile/personal_access_tokens] ( http://gitlab.example.com:30433/-/profile/personal_access_tokens) to Access the Personal Access Tokens to create pages. As requested by Jenkins, we create a token named Jenkins with API ‘ ‘read_repository’ ‘ ‘write_repository’ permission, copy the token string for standby.
And then we go back to the Jenkins home page, From “Manage Jenkins ➡️ Manage Crendentials ➡️ Stores scoped to Jenkins ➡️ Jenkins ➡️ Global Crendentials “Enter the certificate creation page.
Click “Add Credentials” in the left panel to start creating Credentials. After filling in the Credentials, click Ok to save the Credentials:
KindchooseGitLab Personal Access TokenScopeChoose the defaultGlobal.IDFill in any ID that does not cause a naming conflictTokenFill in the standby GitLab token string you just copied (hint for string length can be ignored)
After completing this part of configuration, the state of KubeSphere DevOps Pipeline will also link with the state of Pipeline in our GitLab. You can see the effect in the video.
- www.bilibili.com/video/BV18U…
Create the KubeSphere DevOps pipeline using Jenkinsfile
Let’s go to the demoDevOps 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 the GitLab TAB and then select our previous section to add to the GitLab CE server in Jenkins from the “GitLab Server Address” drop-down box. Since we are walking through private repository access, we need to select a crediting to access the private repository. Here we click on the green “Create Credentials” link to start creating something that we didn’t create before.
In the Create Credentials dialog box that is displayed, enter name and set the user name and password. Then enter our account root in the “Username” text box and the initial password obtained from the secret dictionary in the “Password/token” text box.
Save the credentials by “OK” button and return to “Select Code Panel”. Select the newly created Gitlab-root from the drop-down box of “Credentials” and then fill in our account root in the text library of “Project Team/Owner”. Click the drop-down box of “Code Repository” to see all code repositories under root account. Here we can see and select the sample project root/nodejs-demo that we created earlier.
After confirming and saving the configuration by clicking ☑️, it 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. Upon successful creation, we can see the following healthy pipeline with a “branch count” of zero.
A moment later, click on the new file pipeline and you can see that the system has scanned the master branch with Jenkinsfile and started running the pipeline.
Click the master branch to enter the branch details page. No matter the operation succeeds or fails, you can further click the serial number in the “Operation ID” column to view the detailed operation logs and products.
Wait for a period of time for the system to run successfully. Enter the run record whose ID is 1, and the following interface is displayed. Further, we can click the “View Log” button in the upper right corner to see the detailed pipeline execution.
Note: For a multi-branch pipeline, the default is to perform the Checkout SCM step first, followed by the pipeline content defined in Jenkinsfile.
Create the KubeSphere DevOps pipeline using the graphic editor
See the Official KubeSphere documentation for this section: DevOps User Guide/Using DevOps/Creating pipelining with the Graphical Edit Panel
The KubeSphere DevOps pipeline can also be created using a graphical editing interface, so let’s go back to the demoDevOps project home page and “create” a new pipeline. This time in the “Create Pipeline” panel we do not bind the code repository, go “next” and “create” a pipeline called GUI directly.
After entering the assembly line details page, we can see the button of “Edit Assembly line” in the right panel. After clicking, we can select custom assembly line in the dialog box of “Select Assembly Line Template”.
The other two pipeline templates contain more complete CI/CD pipeline construction examples, but the content is relatively complex, you are welcome to choose your own offline experience!
Let’s try to reproduce the two steps from the previous section with the graphic editor, pulling up the code and printing a Hello World message. First, we click the + button on the left panel, and then select one of the added phase blocks.
Next, click “+ Add Steps” on the left stage block and select a Git step from the “Add Steps” panel that appears on the right. Fill in the pop-up dialog box with the address HTTP Git for our sample code repository Address (e.g., [http://gitlab.example.com/root/nodejs-demo.git] (http://gitlab.example.com/root/nodejs-demo.git)), The certificate shall be gitlab-root created before, and the branch shall be filled with Master.
Once we’re done, we’ll add another print message step and fill it in with Hello World! As content, the final result is the overall effect shown below.
After finishing editing, “OK” and “OK” are used to save the pipeline. After returning to the details page, the “Run” button in the upper right corner can be used to execute the pipeline.
After successful operation, you can check the pipeline operation record again and check the operation log, and get the result as shown in the figure below.
Use SSH to access GitLab code repository in Kubernetes cluster
All the access methods of the code warehouse mentioned above are in the form of HTTP, but the most commonly used access method in real work is SSH. Does it can be directly through the git clone [email protected]: root/nodejs – demo. Git to pull and push the code this way?
The answer is: yes! However, there is a big catch – SSH uses port 22 by default, but with the addition of a layer of Kubernetes network, whether or not you use this default port will have to deal with how GitLab exposes SSH services.
Assuming that it is acceptable to rebind a port to use GitLab SSH, we can do this:
- First, we go back to the GitLab deployment project and find
gitlab-shellService and open the NodePort external access port for it
- Based on this port, change all the addresses that Git accesses to
ssh://git@<gitlab-url>:<gitlab-shell-port>/<username>/<repo>.gitIn the form of, e.gssh://[email protected]:32222/root/nodejs-demo.git
Thank you for being so patient with this whole tutorial! If you think these things are really a bit challenging to deploy by yourself, then I recommend you to have a look at some commercial products of GitLab and KubeSphere Cloud to let professional people do professional things and release everyone’s time to better polish their business products. We also look forward to seeing more positive interactions between the open source community and commercial products, so as to promote our domestic software industry in the year of the Tiger “虎踞龙盘 today is better than ever, the world is completely changed and generous”! This article is published by OpenWrite!