In the process of project development, we often use GitLab CI/CD to automatically deploy the project, today let’s implement a Linux enabled GitLab CI/CD to automatically deploy the Go project.

We need to have a project on GitLab, so we’ll skip the demo here and start installing Runners first.

1 installation runners

GitLab has three kinds of runners, which are:

  • Shared runners are available to all groups and projects in a GitLab instance.
  • Group runners are available to all projects and subgroups in a group.
  • Specific runners are associated with specific projects. Typically, specific runners are used for one project at a time.

To put it bluntly, it means:

  • Shared Runners are all groups and projects that can use a Shared runner, operated by an administrator, usually only in small teams. GitLab is not available by default.
  • Group Runners are common and enable multiple projects within a team to be shared. Reusable Runner can support CI of a class of projects at the same time and improve resource reuse rate.
  • Specific runners are associated with a particular project and cannot be shared. Moreover, for individual events, where there is no Group layer, Specific runners are appropriate.

Runner is managed by the daemon running on the server. A daemon can manage multiple Runners. Multiple runners are registered to the specified GitLab according to token and URL.

The following tutorial is also based on Specific runners to do demonstration, first we download GitLab runner, we first enter GitLab runner download page: docs.gitlab.com/runner/inst… You can see the official installation tutorial.

The machine I am using is a Linux server of Tencent Cloud, so I need to select Install on GNU/Linux, as shown below:

If you are using another system, you can choose the corresponding download method.

Then you can enter the download page as prompted, or you can directly see the following example, download the corresponding installation package, the demonstration machine is using Centos, select the following example.

${arch} ${arch}

 # Replace ${arch} with any of the supported architectures, e.g. amd64, arm, arm64
 # A full list of architectures can be found here https://gitlab-runner-downloads.s3.amazonaws.com/latest/index.html
 curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_${arch}.rpm"
Copy the code

${arch} can be replaced with any supported architecture, so we need to change it to something like this:

 curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_amd64.rpm"
 curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_arm64.rpm"
 curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_arm.rpm"
Copy the code

This also depends on your actual machine situation to make a choice, I am currently using amD64. We can also use the uname -m command to view the architecture of the machine, as in:

My server is x86 architecture, use M1 Mac query, return the following:

You can also use your computer to access curl’s url in your browser and check whether it works.

After the test, use the curl command listed above in the terminal on the server to download the corresponding RPM package.

Because the server download is slow, I directly use the browser download, screenshot to make a demonstration.

Then use the RPM command to install

 rpm -ivh gitlab-runner_<arch>.rpm
Copy the code

If you do not need to install git, you can use yum to install Centos.

After the installation is complete, use the command

 gitlab-runner -v
Copy the code

If the following information is displayed, the installation is successful.

2 Obtain tokens in GitLab

After runner is installed, we go back to the Settings page of the GitLab project, go to CI/CD, and click the Expand button in Runners, as shown:

Click on Specific Runners and you’ll see the URL and token that Specific Runners use to register, which we need to fill out when registering runners.

Continue back to the server and start registering with Gitlab-Runner

[root@centos software]# gitlab-runner register Runtime platform arch=amd64 os=linux pid=2502549 revision=e0218c92 Version =14.3.2 Running in system-mode. Enter the GitLab instance URL (for example, https://gitlab.com/): https://gitlab.com/ Enter the registration token: NzE3jDif-xxxxxxx Enter a description for the runner: [centos]: runner1 Enter tags for the runner (comma-separated): Registering runner... succeeded runner=NzE3jDif Enter an executor: custom, docker, parallels, docker+machine, docker-ssh+machine, kubernetes, docker-ssh, shell, ssh, virtualbox: shell Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!Copy the code

Several parameters are described:

  • GitLab instance URL: write the CI/CD registered address in the screenshot above;
  • Token: Write the token used for registration in CI/CD in the screenshot above
  • Description: Enter a description
  • Tags: Optional, can also be modified on the GitLab web page, and related to tags configured in GitLab’s.gitlab-ci.yml file; For example, after setting a label for a runner, the corresponding Job must set the label before it can be executed on the runner.
  • Executor: Use the shell command. It’s simple and effective.

When we register successfully, we can see the runner in the interface of GitLab.

In this way, a runner is registered.

3 Write the. Gitlab-ci. yml file to implement automatic deployment

So far, we have successfully installed runner and completed runner registration, and then simulated a simple.gitlab-ci.yml file to realize automatic deployment of Go project.

/etc/systemd/system: /etc/systemd/system: /etc/systemd/system: /etc/systemd/system

 vim /etc/systemd/system/runner1.service
Copy the code

Then paste the following code

 [Unit]
 After=network.target
 [Service]
 User=root
 Group=root
 ExecStart=/opt/project/runner1/runner1
 Type=simple
 [Install]
 WantedBy=multi-user.target
Copy the code
  • User and Group enter the corresponding User and Group.
  • ExecStart is the directory for the packaged executable

The.gitlab-ci.yml file is provided as an example. You can refer to the official documentation of Gitlab for the syntax.

image: golang stages: - main main: stage: main script: - echo "Start to deploy!" - echo ${CI_PROJECT_DIR} -cd ${CI_PROJECT_DIR} # Set the go proxy -go env -w GO111MODULE= on-go env -w GOPROXY = https://goproxy.cn, direct # packaged to the specified directory - go build - o/opt/project/runner1 runner1 main. Go # - systemctl restart process restart runner1.service tags: - master only: - mainCopy the code

Tags in the YML file are the tags filled in when registering runner. We left them blank just now, because they can be modified in the webpage of GitLab. Click Edit at the corresponding Runner on the webpage, and you can modify them after entering.

Then change it to the configuration in the YML file.

4 Supplement: Gitlab-runner permission issues

In fact, we use systemctl daemon, but also encounter a problem is that gitlab-runner uses gitlab-runner user when executing, so it will cause insufficient permissions, and we can modify the default user of gitlab-runner to solve this problem.

 vim /etc/systemd/system/gitlab-runner.service
Copy the code

Then change –user from gitlab-runner to root.

 /usr/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--user" "root"
Copy the code

Finally, after the code push is added, you can see the state of job in JOBS in CI/CD of GitLab webpage.

This enables a basic PIPELined DEPLOYMENT of CI/CD.

If you have any questions, please leave a message and wish you all the best