Skip to content

Commit ce1f573

Browse files
committed
feat: add gitlab ci integrations
1 parent b166791 commit ce1f573

File tree

6 files changed

+272
-12
lines changed

6 files changed

+272
-12
lines changed
Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
---
2+
id: gitlab-ci
3+
sidebar_label: Gitlab CI
4+
---
5+
6+
# Gitlab CI Integration
7+
8+
## Introduction
9+
10+
In the GitOps section, we have introduced how to integrate KCL with GitOps. In this section, we will continue to provide sample solutions for KCL and CI integrations. We hope to implement the end-to-end application development process by using containers, Continuous Integration (CI) for generation, and GitOps for Continuous Deployment (CD). In this scheme, we use a **Flask application** and **Gitlab CI** as examples.
11+
12+
> Note: You can use any containerized application and different CI systems such as **Github Actions**, **Jenkins CI**, etc. in this solution.
13+
14+
The overall workflow is as follows:
15+
16+
+ Develop application code and submit it to the Gitlab repository to trigger CI.
17+
+ Gitlab generate container images from application code and push them to the `docker.io` container registry.
18+
+ Gitlab CI automatically synchronizes and updates the KCL manifest deployment file based on the version of the container image in the docker.io container registry.
19+
20+
## How to
21+
22+
We put the application source code and infrature deployment code in different repos, which can be maintained by different roles to achieve the separation of concerns.
23+
24+
+ Get the application code
25+
26+
```shell
27+
git clone https://gitlab.com/kcl-lang/flask-demo.io.git/
28+
cd flask-demo
29+
```
30+
31+
## Summary
32+
33+
This is a web application written in Python. We can use the `Dockerfile` in the application directory to generate a container image of this application, and also use Gitlab CI to automatically build a image named `flask_demo`, the CI configuration is as follows
34+
35+
```yaml
36+
stages:
37+
- publish
38+
- deploy
39+
40+
publish:
41+
stage: publish
42+
image:
43+
name: cnych/kaniko-executor:v0.22.0
44+
entrypoint: [""]
45+
script:
46+
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
47+
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile ./Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
48+
only:
49+
- main
50+
51+
deploy:
52+
stage: deploy
53+
image: cnych/kustomize:v1.0
54+
before_script:
55+
- git remote set-url origin https://gitlab.com/kcl-lang/flask-demo
56+
- git config --global user.email "[email protected]"
57+
- git config --global user.name "GitLab CI/CD"
58+
# Install KCL
59+
- wget -q https://kcl-lang.io/script/install.sh -O - | /bin/bash
60+
script:
61+
- git checkout -B main
62+
- cd deployment
63+
# Image auto update
64+
- /usr/local/kclvm/bin/kcl -d -O config.containers.flask_demo.image="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
65+
- git commit -am '[skip ci] image update to $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA'
66+
- git push origin main
67+
only:
68+
- main
69+
```
70+
71+
We need the workflow in the source code repository to automatically trigger the workflow in the deployment manifest repository. At this point, we need to config `Settings -> CI/CD -> Variables` including `CI_REGISTRY`, `CI_REGISTRY_IMAGE`, `CI_REGISTRY_USER`, `CI_REGISTRY_PASSWORD`, `CI_USERNAME` and `CI_PASSWORD` and update application code to trigger automation build and deploy.
72+
73+
![](/img/docs/user_docs/guides/ci-integration/gitlab-ci-variables.jpg)
74+
75+
### 2. Commit the Application Code
76+
77+
After submitting in the `flask-demo` repository, Gitlab will automatically build a container image and push it to the Docker hub. It will also then trigger the Action of the `flask-demo-kcl-manifest` repository and modify the image value in the deployment manifest repository through [KCL Automation API](/docs/user_docs/guides/automation). Now let's create a submission in the `flask-demo` repository, and we can see that the code submission triggers the Gitlab CI process for the application repository `Build -> Pipelines` page.
78+
79+
### 3. Configuration Automatic Update
80+
81+
After the Gitlab CI process in the application repository is completed, a automatic update configuration CI will be triggered in the repository where the KCL configuration is stored and submitted to the main branch of the `flask-demo` repository.
82+
83+
+ We can obtain the deployment manifest source code for compilation and validation
84+
85+
```shell
86+
git checkout main && git pull && cd deploy && kcl
87+
```
88+
89+
The output YAML is
90+
91+
```yaml
92+
apiVersion: apps/v1
93+
kind: Deployment
94+
metadata:
95+
name: flask_demo
96+
labels:
97+
app: flask_demo
98+
spec:
99+
replicas: 1
100+
selector:
101+
matchLabels:
102+
app: flask_demo
103+
template:
104+
metadata:
105+
labels:
106+
app: flask_demo
107+
spec:
108+
containers:
109+
- name: flask_demo
110+
image: "kcllang/flask_demo:6428cff4309afc8c1c40ad180bb9cfd82546be3e"
111+
ports:
112+
- protocol: TCP
113+
containerPort: 5000
114+
---
115+
apiVersion: v1
116+
kind: Service
117+
metadata:
118+
name: flask_demo
119+
labels:
120+
app: flask_demo
121+
spec:
122+
type: NodePort
123+
selector:
124+
app: flask_demo
125+
ports:
126+
- port: 5000
127+
protocol: TCP
128+
targetPort: 5000
129+
```
130+
131+
From the above configuration, it can be seen that the image of the resource is indeed automatically updated to the newly constructed image value. In addition, we can also use the **Argo CD KCL plugin** to automatically synchronize data from the Git repository and deploy the application to the Kubernetes cluster.
132+
133+
## Summary
134+
135+
By integrating KCL and Gitlab CI, we can automate the modification and deployment configuration of any application output container image, in order to achieve end-to-end application development process and improve R&D deployment efficiency.

docs/user_docs/guides/ci-integration/_2-gitlab-ci.md

Lines changed: 0 additions & 12 deletions
This file was deleted.

flask-demo

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Subproject commit f92091e155becdc8f5dc180d4e1c2875a99448b0

pages

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Subproject commit ebefa42d9b2745b3e41038c51abbb4fcaff20ffd
Loading
Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
---
2+
id: gitlab-ci
3+
sidebar_label: Gitlab CI
4+
---
5+
6+
# Gitlab CI Integration
7+
8+
## Introduction
9+
10+
In the GitOps section, we have introduced how to integrate KCL with GitOps. In this section, we will continue to provide sample solutions for KCL and CI integrations. We hope to implement the end-to-end application development process by using containers, Continuous Integration (CI) for generation, and GitOps for Continuous Deployment (CD). In this scheme, we use a **Flask application** and **Gitlab CI** as examples.
11+
12+
> Note: You can use any containerized application and different CI systems such as **Github Actions**, **Jenkins CI**, etc. in this solution.
13+
14+
The overall workflow is as follows:
15+
16+
+ Develop application code and submit it to the Gitlab repository to trigger CI.
17+
+ Gitlab generate container images from application code and push them to the `docker.io` container registry.
18+
+ Gitlab CI automatically synchronizes and updates the KCL manifest deployment file based on the version of the container image in the docker.io container registry.
19+
20+
## How to
21+
22+
We put the application source code and infrature deployment code in different repos, which can be maintained by different roles to achieve the separation of concerns.
23+
24+
+ Get the application code
25+
26+
```shell
27+
git clone https://gitlab.com/kcl-lang/flask-demo.io.git/
28+
cd flask-demo
29+
```
30+
31+
## Summary
32+
33+
This is a web application written in Python. We can use the `Dockerfile` in the application directory to generate a container image of this application, and also use Gitlab CI to automatically build a image named `flask_demo`, the CI configuration is as follows
34+
35+
```yaml
36+
stages:
37+
- publish
38+
- deploy
39+
40+
publish:
41+
stage: publish
42+
image:
43+
name: cnych/kaniko-executor:v0.22.0
44+
entrypoint: [""]
45+
script:
46+
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
47+
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile ./Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
48+
only:
49+
- main
50+
51+
deploy:
52+
stage: deploy
53+
image: cnych/kustomize:v1.0
54+
before_script:
55+
- git remote set-url origin https://gitlab.com/kcl-lang/flask-demo
56+
- git config --global user.email "[email protected]"
57+
- git config --global user.name "GitLab CI/CD"
58+
# Install KCL
59+
- wget -q https://kcl-lang.io/script/install.sh -O - | /bin/bash
60+
script:
61+
- git checkout -B main
62+
- cd deployment
63+
# Image auto update
64+
- /usr/local/kclvm/bin/kcl -d -O config.containers.flask_demo.image="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
65+
- git commit -am '[skip ci] image update to $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA'
66+
- git push origin main
67+
only:
68+
- main
69+
```
70+
71+
We need the workflow in the source code repository to automatically trigger the workflow in the deployment manifest repository. At this point, we need to config `Settings -> CI/CD -> Variables` including `CI_REGISTRY`, `CI_REGISTRY_IMAGE`, `CI_REGISTRY_USER`, `CI_REGISTRY_PASSWORD`, `CI_USERNAME` and `CI_PASSWORD` and update application code to trigger automation build and deploy.
72+
73+
![](/img/docs/user_docs/guides/ci-integration/gitlab-ci-variables.jpg)
74+
75+
### 2. Commit the Application Code
76+
77+
After submitting in the `flask-demo` repository, Gitlab will automatically build a container image and push it to the Docker hub. It will also then trigger the Action of the `flask-demo-kcl-manifest` repository and modify the image value in the deployment manifest repository through [KCL Automation API](/docs/user_docs/guides/automation). Now let's create a submission in the `flask-demo` repository, and we can see that the code submission triggers the Gitlab CI process for the application repository `Build -> Pipelines` page.
78+
79+
### 3. Configuration Automatic Update
80+
81+
After the Gitlab CI process in the application repository is completed, a automatic update configuration CI will be triggered in the repository where the KCL configuration is stored and submitted to the main branch of the `flask-demo` repository.
82+
83+
+ We can obtain the deployment manifest source code for compilation and validation
84+
85+
```shell
86+
git checkout main && git pull && cd deploy && kcl
87+
```
88+
89+
The output YAML is
90+
91+
```yaml
92+
apiVersion: apps/v1
93+
kind: Deployment
94+
metadata:
95+
name: flask_demo
96+
labels:
97+
app: flask_demo
98+
spec:
99+
replicas: 1
100+
selector:
101+
matchLabels:
102+
app: flask_demo
103+
template:
104+
metadata:
105+
labels:
106+
app: flask_demo
107+
spec:
108+
containers:
109+
- name: flask_demo
110+
image: "kcllang/flask_demo:6428cff4309afc8c1c40ad180bb9cfd82546be3e"
111+
ports:
112+
- protocol: TCP
113+
containerPort: 5000
114+
---
115+
apiVersion: v1
116+
kind: Service
117+
metadata:
118+
name: flask_demo
119+
labels:
120+
app: flask_demo
121+
spec:
122+
type: NodePort
123+
selector:
124+
app: flask_demo
125+
ports:
126+
- port: 5000
127+
protocol: TCP
128+
targetPort: 5000
129+
```
130+
131+
From the above configuration, it can be seen that the image of the resource is indeed automatically updated to the newly constructed image value. In addition, we can also use the **Argo CD KCL plugin** to automatically synchronize data from the Git repository and deploy the application to the Kubernetes cluster.
132+
133+
## Summary
134+
135+
By integrating KCL and Gitlab CI, we can automate the modification and deployment configuration of any application output container image, in order to achieve end-to-end application development process and improve R&D deployment efficiency.

0 commit comments

Comments
 (0)