Shulou(Shulou.com)06/02 Report--

Brief introduction

The full name of gitlab-ci means gitlab continuous integration, which means continuous integration. The central idea is that every push to gitlab will trigger a script execution, and then the content of the script includes testing, compilation, deployment and a series of custom content.

Automatic deployment involves several roles, mainly as follows

GitLab-CI

This is a continuous integration system used with GitLab, which comes with GitLab, which is installed on the server where you installed GitLab. It is responsible for script parsing of the. gitlab-ci.yml

GitLab-Runner

This is the carrier of script execution, and runner is responsible for running the script portion of .gitlab-ci.yml. After browsing the. gitlab-ci.yml file in the project, GitLab-CI assigns each Runner to run the corresponding script script according to the rules in it. Some of these scripts are for testing projects and some are for deployment.

. gitlab-ci.yml

This is a file in the root directory of the git project that records a series of phases and execution rules. GitLab-CI parses it after push and calls runner to run it according to its contents.

Pipeline

A Pipeline is actually equivalent to a build task, which can contain multiple processes, such as installing dependencies, running tests, compiling, deploying test servers, deploying production servers, and so on.

Stages

Stages represents the construction phase, which is, to put it bluntly, the process mentioned above. We can define multiple Stages in a single Pipeline, and these Stages will have the following characteristics:

All Stages will run sequentially, that is, when one Stage is complete, the next Stage will start.

The build task (Pipeline) will be successful only when all Stages are completed.

If any of the Stage fails, the subsequent Stages will not be executed and the build task (Pipeline) fails

Jobs

Jobs stands for build work, and represents work performed within a Stage. We can define multiple Jobs in Stages, and these Jobs will have the following characteristics:

Jobs in the same Stage executes in parallel

The Jobs in the same Stage will succeed only if all the Stage executes successfully.

If any Job fails, then the Stage fails, that is, the build task (Pipeline) fails

The release flow chart is as follows:

Installation and deployment

Add gitlab official Library

Curl-L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

Install the latest version of gitlab-runner

Yum-y install gitlab-runner

Start the service

Gitlab-runner list to view the status of each Runner

Gitlab-runner stop out of service

Gitlab-runner start Startup Service

Gitlab-runner restart restart service

Register

You need to get a registration token before registering.

Specific token location is: gitlab Project-> Settings-> CI / CD-> Runners Settings

The share runner token location is: Admin Area-> Runners setting

Start registration

Gitlab-runner register

[root@localhost ~] # gitlab-runner register

Runtime platform arch=amd64 os=linux pid=1784 revision=577f813d version=12.5.0

Running in system-mode.

# # enter your Gitlab URL

Please enter the gitlab-ci coordinator URL (e.g. Https://gitlab.com/):)

Http://192.168.60.133/

# # enter a registration token to register Runner

Please enter the gitlab-ci token for this runner:

SeyTs9_4mKEsYjmfPr4e

# # enter Runner description

Please enter the gitlab-ci description for this runner:

[localhost]: test

# # enter the tags of Runner

Please enter the gitlab-ci tags for this runner (comma separated):

Test

Registering runner... Succeeded runner=SeyTs9_4

# # how to input Runner

Please enter the executor: parallels, ssh, virtualbox, docker+machine, custom, docker, docker-ssh, shell, docker-ssh+machine, kubernetes:

Shell

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

The configuration file is saved in / etc/gitlab-runner/config.toml

The configuration item is similar to the following. You may need to manually add the variables builds_dir and cache_dir, and then restart the service.

[[runners]]

Name = "216XX"

Url = "https://git.XX.com/"

Token = "xxxxxx"

Executor = "shell"

Builds_dir = "/ home/gitlab-runner/builds"

Cache_dir = "/ home/gitlab-runner/cache"

[runners.cache]

If you want to process multiple build at the same time, you need to configure concurrent with a value of > 1 in the / etc/gitlab-runner/config.toml file.

Log out of runner:

Gitlab-runner unregister-url https://asdf.com/ci-token 43f334f34f34f34f4

Or

Gitlab-runner unregister-name NAME deletes a specific Runner

Let's go to the root directory of the project that needs to be published. gitlab-ci.yml script for automatic release

The .gitlab.-ci.yml file must be created in the root directory of the project

Stages:

-build

-test

-deploy

# Packaging stage

Build-job:

Stage: build

Tags:

-report

Script:

-mvn clean package-Dmaven.test.skip=true-Pprod

Only:

-master

# Test phase

Test-job:

Stage: test

Tags:

-report

Script:

-docker run-d-v $(pwd) / target:/opt/tomcat-8.5/webapps-p 8099pur8080-- name=xxxx public/tomcat-8.5

Only:

-master

# Manual deployment phase

Deploy-job:

Stage: deploy

Tags:

-report

Only:

-master

Environment:

Name: $report_v

Url: $report_url

Script:

-echo $(whoami)

-ssh-p 222 $report_host "/ test/apache-tomcat/bin/shutdown.sh"

-ssh-p 222 $report_host "rm-rf / test/tomcat/webapps/*"

-scp-P222 target/report.war $report_host:/test/tomcat/webapps

-ssh-p 222 $report_host "/ test/tomcat/bin/startup.sh"

When: manual

The variable information used in the configuration. gitlab-ci.yml file: CI / CD Settings/Variables, can also be specified directly in the .gitlab.-ci.yml file, which is configured outside for security reasons.

Write the. gitlab.-ci.yml script in the root directory of the project and then automatically trigger the build deployment

In jobs, we can see the status of the execution, whether the execution was successful or whether an error was reported.

Perform deployment manually

Parameters need to be added during the manual phase.

When: manual

Here you can see that the build_job phase task has been successfully executed, and the test_job phase task is waiting for manual deployment.

Click the test_job status to view the execution process; if an error is reported, the error message can also be displayed here.

Next we manually perform the task of deploying the test_job phase.

Refresh after execution, you can see that the execution has been successful.

Above we configured rollback and manual deployment tasks in .gitlab-ci.yml; let's take a look at rollback.

Roll back

In the task of deploy, add the following parameters:

Environment:

Name: lims3_v

We can see that there is our custom version here, and you can click in to see the previous history.

Click the rollback button behind to roll back.

QroomA:

The error is as follows:

Figure 1:

The reason is that the git version is too low, upgrade the git version to the version after 2.12.

Figure 2:

Solution:

Due to the lack of git components, you can recompile and install git

Figure 3:

It is a user rights issue:

Solution: chown-R gitlab-runner:gitlab-runner / home/gitlab-runner

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.