One, foreword
Git Gitlab shell is used in this process
Contents that need to be prepared in advance
- A project
myweb
- Install Git locally
- A Gitlab warehouse
- Docker private repository
- gitlab runner(Gitlab-runner)
The company’s code is typically stored in a privatized deployment of Gitlab. To use Gitlab’S CI/CD, Gitlab version >8.0.0 is required
Although CI/CD is not difficult, there are many pits in the configuration process, and some concepts to understand are also more, can be divided into multiple steps, one by one.
Ii. Introduction of CI combat
1. Install and register Gitlab-Runner
Gitlab-runner requires pre-installation and registration, details
Enter Gitlab->CICD->Runner There are currently available runners
As shown, the project is available to runner
- The left runner can only be used for the current project, but needs to be activated.
- On the right is the shared runner, which can be used directly
- .gitlab-ci. yML is associated with tags of Runner
2. Run CI first
First create.gitlab-ci.yml in the root directory of the project, then configure pipeline tasks in this file, which will run in gitlab-runner.
One of the simplest. Gitlab-ci. yml files, CI_COMMIT_BRANCH and GITLAB_USER_LOGIN are gitLab-defined variables that can be used directly or you can define your own
image: "node"
stages:
- BuildImage
before_script:
- echo "before_script"
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
- echo "Hello, $GITLAB_USER_LOGIN!"
build:
tags:
- test
stage: BuildImage
image: "node"
script:
- node -v
Copy the code
Push Git repository
git add .gitlab-ci.yml
git commit -m "commit ci"
git push
Copy the code
Go to the Gitlab- > CI/CD page and you can see that a pipeline state is STUCK because there is no Gitlab-runner.
3. Use Gitlab-Runner to execute pipeline
Modified. Gitlab-ci.yml, showing only part of it
Uaek-c1 tags: -uaek-c1 stage: BuildImage image: "node" script: -node -vCopy the code
Submit the code, enter CI/CD page to see a new pipeline execution completed
Click on the new record to see the corresponding Stage, and click on the current task
You can see the details of gitlab-runner execution. Gitlab-ci.yml.
So far, you’ve seen.gitlab-ci.yml trigger to execute. Now, how to run ci specifically for this project
Iii. Actual combat configuration of the project
Build Docker image reference details
1. Add the Dockerfile and Nginx configuration file to the project
Add configuration file Dockerfile to the root directory
FROM node:10-alpine as builder
WORKDIR /data/myweb
COPY.
RUN npm install --registry=https://registry.npm.taobao.org --no-package-lock --no-save
RUN yarn publish:prod
FROM nginx:alpine as myweb
RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
&& echo "Asia/Shanghai" > /etc/timezone
WORKDIR /data/production
COPY ./nginx /etc/nginx/conf.d
COPY --from=builder /data/myweb/build /data/production
EXPOSE 80.443
Copy the code
(2) Create a new nginx/default.conf file in the root directory of the project. We overwrite the configuration file in the original Nginx image with the external nginx configuration file
server {
listen 80;
listen[: :] :80;
server_name localhost;
location / {
root /data/production;
index index.html;
try_files $uri /index.html;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root/usr/share/nginx/html; }}Copy the code
2. Configuration files
Define global variables, mirror name, namespace, mirror pull password variable name
variables:
IMAGE_HUB: "lvpf/myweb"
DOCKER_HUB_URL: "hub.docker.com/r/lvpf/myweb"
# Print some variables here, just for demonstration, look at these gitlab default variable values, can be removed
before_script:
- echo "VARIABLE CI_COMMIT_SHA IS $CI_COMMIT_SHA!"
- echo "VARIABLE CI_COMMIT_TAG IS $CI_COMMIT_TAG!"
- echo "VARIABLE CI_PROJECT_DIR IS $CI_PROJECT_DIR!"
# Stages Runs sequentially. All jobs on the same stage run in parallel
stages:
- BuildImage
# Task 1, build the Docker image
docker-image-master:
# use the Gitlab Runner tag
tags:
- uaek-c1
# task name
stage: BuildImage
Since the current runner is built for K8S, the implementation of docker build and upload requires kaniko image. For details, please see the following reference document ().
image: gcr.io/kaniko-project/executor
script:
First we need to generate a git tag for our image. The rule is: if you have a Git tag, use git tag; if not, use Git commit SHA
- IMAGE_TAG=$CI_COMMIT_SHA && if [[ -n "$CI_COMMIT_TAG" ]]; then IMAGE_TAG=$CI_COMMIT_TAG; fi
- echo $IMAGE_HUB:$IMAGE_TAG
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $DOCKER_HUB_URL:$IMAGE_TAG
The job will trigger a CI only when a new tag is created. If a new tag is created, the job will trigger a CI every time it is pushed
only:
- tags
Copy the code
3. Precautions
- Generally, the company does not push the image to the hub for security reasons, and the internal network of the company is usually disconnected. Therefore, it is necessary to build a private image warehouse
- Gitlab-runner can use many types of host machines, including cloud host, Docker, K8S, etc. The solution of image construction is slightly different, you can refer to the documents
- Some of these involve password variables that can be passed
Gitlab->Setting->CI/CD->Variables
To be used directly in.gitlab-ci.yml
Iv. Reference documents
- Gitlab CI starts fast
- Build image-docs in gitlab-Runner built by K8S
- Build image in Gitlab-Runner built by K8S