GitLab CI/CD Configuration and Usage

Preface

The essence of writing code is automating work, reducing manual operations and improving efficiency. Because humans are lazy dogs by nature Programmers are no exception. For efficiency gains of all kinds (laziness), we need continuous integration tools to fully automate highly repetitive tasks such as testing, compiling, and releasing code, reducing workload, improving efficiency, and liberating productivity to contribute to the great rejuvenation of China

Back to the point, the mainstream continuous integration tools are Jenkins, GitLab CI/CD, and the like. Since we happen to be using GitLab, there's no need to mess around with Jenkins—we'll just use this~

Concept primer

The acronym CI/CD has several different meanings. The "CI" in CI/CD always refers to continuous integration, which is part of developers' automation processes. Successful CI means that new changes to application code are regularly built, tested, and merged into a shared repository. This solution can address the problem of having too many application branches in one development effort, which leads to conflicts.

The "CD" in CI/CD refers to continuous delivery and/or continuous deployment. These related concepts are sometimes used interchangeably. Both concern automation of later stages of the pipeline, but they are also sometimes used separately to indicate the degree of automation.

…… (omitting the tediously long terminology explanations)

Just remember that CI/CD is actually a process (often vividly described as a pipeline) for achieving a high degree of continuous automation and continuous monitoring in application development. It varies from case to case; the specific meaning of the term depends on how automated the CI/CD pipeline is. Many enterprises start by adding CI, then gradually automate delivery and deployment (for example, as part of cloud-native applications).

Installing Gitlab-Runner

Following the GitLab official documentation

# Download the binary for your system
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Give it permissions to execute
sudo chmod +x /usr/local/bin/gitlab-runner

# Create a GitLab CI user
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

# Install and run as service
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

The server uses CentOS 7. During actual configuration I ran into the problem that the gitlab-runner command was not recognized. I printed the environment variables with echo $PATH and found that /usr/local/bin was missing; adding it to PATH fixed it.

During installation, a gitlab-runner user is created automatically. The Runner will execute various tasks under this user. Of course, the username and Home directory can both be customized—that's the second-to-last command above.

Registering a Runner

In GitLab, go to: Menu - Admin - Overview - Runner - Register an instance Runner

A token will appear; register with the following command

sudo gitlab-runner register --url http://gitlab地址:端口/ --registration-token HjymWn4gEzHaVizpvG

During registration you'll be asked to enter some information, and at the end you need to choose an executer. Options include virtualbox, docker, shell, and the like. I chose shell here, to control project deployment by executing commands directly. I'll look into how to use the other executers later.

Once registration is done, you can see this Runner in GitLab's admin interface.

To let all projects use this Runner for deployment, you need to tweak the configuration a bit and check this box

Configuration

To let the gitlab-runner user use Docker, you need to add it to the docker group

usermod -aG docker gitlab-runner

Configuring a Docker proxy

Because our production server cannot access the internet directly, we also need to configure a Docker proxy

Edit the file: /home/gitlab-runner/.docker/config.json

{
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://proxy_ip:8080",
     "httpsProxy": "http://proxy_ip:8080",
     "noProxy": "localhost,127.0.0.1"
   }
 }
}

gitlab-ci.yml

As long as you add this file to the project's root directory and then push the code to GitLab (typically the master branch), GitLab Runner will execute the build tasks according to script.

During day-to-day development, if you don't want automatic builds, you can checkout another branch (e.g. dev) to develop, and merge into the master branch when the feature is done and ready to release.

Here I've written an example of deploying an AspNetCore application with Docker. There are also common examples for Python, Go, frontend projects, and so on; I'll update with related articles later~

variables:
  GIT_STRATEGY: none
stages:
  - deploy
deploy_job:
  stage: deploy
  only:
    - master
  script:
    - cd /home/gitlab-runner/projects/dotnet/dashboard
    - rm -rf dashboard-backend
    - git clone http://127.0.0.1:8080/deali/dashboard-backend.git
    - cd dashboard-backend
    - docker-compose up --build -d

Wrap-up

And that's the basic usage of Gitlab CI/CD—so-called "continuous integration." You could say it's super useful~

Of course it has many powerful features; this article's example only uses one of them. I'm still exploring more ways to use it, and if I learn something useful I'll update this series of articles later.

References

• Post-installation steps for Linux: https://docs.docker.com/engine/install/linux-postinstall/
• Docker proxy pitfall guide: https://www.cnblogs.com/michael9/p/12300824.html
• Automated deployment of asp.net core with Gitlab-CI: https://www.cnblogs.com/guolianyu/p/9709166.html
• What it's like using GitLab for CI/CD—it's so powerful: https://cloud.tencent.com/developer/article/1684099
• Choosing a CI/CD tool: Jenkins or GitLab CI/CD: https://www.infoq.cn/article/9hscujuukmbbwjpr0p0g
• Still using Jenkins? Try GitLab's CI/CD—it's awesome!https://juejin.cn/post/6989411087611330573