GitLab Automated Deployment (CI)

At present, GitLab already has the CI function, that is, the function of continuous integration. It can realize automatic testing, compilation, release, deployment and other automation work after code submission. On the content of this piece, online articles are vague. Recently, I need GitLab to automatically deploy, and I have stepped on a lot of pits. Now I record the configuration steps for your reference.

Goal : Submit the code to GitLab, and the CI function of GitLab will automatically complete the deployment.

Principle : When GitLab receives a code submission event, it interacts with the runner on the corresponding node through the configuration information of .gitlab-ci.yml.

Implementation : as follows

1. Install Runner

The Runner server can be the server where GitLab is located, the server where the program needs to be deployed, or other servers.

# 在root下执行
# 下载gitlab-runner
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-runner/yum/el7/gitlab-runner-10.5.0-1.x86_64.rpm
# 安装
rpm -ivh gitlab-runner-10.5.0-1.x86_64.rpm

2. Configure the Runner (optional)

By default, Runner performs a series of operations through the user of gitlab-runner, and its working directory is also under the user directory of gitlab-runner. If you often encounter permission problems when using the default gitlab-runner user to operate some files, you need to empower gitlab-runner. We modify it in the following way.

# 在root下执行
# 删除服务
gitlab-runner uninstall
# 添加服务
gitlab-runner install --working-directory /home/jack --user jack
# 重启服务
gitlab-runner restart
# 查看状态
gitlab-runner status
输出：gitlab-runner: Service is running!
# 查看是否生效
ps -ef | grep gitlab-runner
输出：root     17454     1  0 Mar23 ?        01:18:03 /usr/bin/gitlab-runner run --working-directory /home/jack --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user jack

3. Register Runner

First open the project interface on GitLab that needs to be automatically deployed, and find the project's Settings -> CI/CD -> Runners settings . There may be some differences in the interface of different versions of GitLab.
write picture description here

In the red area, you can see the URL and Token, which together are the only information of the project. Then execute the following command under the root user of our Runner service

# 在root下执行
# gitlab-runner register
WARNING: Running in user-mode.                     
WARNING: The user-mode requires you to manually start builds processing: 
WARNING: $ gitlab-runner run                       
WARNING: Use sudo for system-mode:                 
WARNING: $ sudo gitlab-runner...                   

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://192.168.1.200/   # 填写刚才看到的URL
Please enter the gitlab-ci token for this runner:
eHMqXjw9ELDy2StsRWXT    # 填写刚才看到的Token
Please enter the gitlab-ci description for this runner:
[dev_srv]:web_dev       # 描述一下该runner，和下面的tags相同即可 
Please enter the gitlab-ci tags for this runner (comma separated):
web_dev                 # 该runner起个名字
Whether to run untagged builds [true/false]:
[false]:                # 直接回车
Whether to lock the Runner to current project [true/false]:
[true]:                 # 直接回车
Registering runner... succeeded                     runner=eHMqXjw9
Please enter the executor: shell, ssh, docker+machine, docker, docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes:
shell                  # 填写runner执行时需要使用什么执行器，一般都填shell或者docker。
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

This completes the mutual registration of information between Runner and CI. The runner knows which project it needs to operate, and the CI also knows the existence of the runner. Then refresh the Runners settings interface and you will see the newly registered Runner.
write picture description here

A green circle in front of it means the registration is successful.

4. Configure the yml file

Add a .gitlab-ci.yml file to the project root directory. The content is as follows:

stages: 
    - deploy
deploy:
    stage: deploy
    script:
      - cp -r * /opt/web
    only:
      - dev
    tags:
      - web_dev

The deploy under stages indicates that CI needs to execute the contents of the deploy node after the code is submitted.
The script of deploy is a shell command. It should be noted here that each command starts with a bar + space.
only: Only takes effect when submitting code to the dev branch.
tags: Only the Runner that owns the tags needs to be executed.

5. Test

After submitting the code to dev once, open the CI/CD -> Pipelines interface of the project, and you can see the execution record of CI
write picture description here

If the status is failed or stucked, etc., you can click the status button to enter the detailed interface to see the error message.

write picture description here

6. Analysis

Why add cp -r * /opt/web to yml to complete the deployment?

When installing the Runner, we talked about the working directory. There is a builds directory under the working directory, and all the work of the Runner is carried out under this directory. Every time the code is submitted, the Runner will fetch the code by itself, so the Runner is located under the path of the local code repository by default. So directly execute cp -r * /opt/web to copy the program. Of course, you can add the compiled command and then deploy it. Do as you please.