background

I checked a lot of information on the Internet, and a large part of the information is just a part of the writing, or a case of the document, which does not have universality.

This article does a variety of disorderly article integration and supplement.

Order of data:

  1. The official documentation
  2. All kinds of blog

There are three ways to implement the configuration of Gitlab CI and Docker in the official documentation. This article writes the first way to use shell, which is also the simplest way.

Introduction to the

Gitlab-ci stands for GITlab Continuous Integration. The idea is that every push to GitLab will trigger a script execution, and the content of the script will include a series of customized content such as test, compile, and deploy. This paper uses the continuous integration of GitLab-CI to achieve automatic deployment. Webhook deployment is much more powerful and convenient than before.

The principle of

Automatic deployment involves several roles, which are described as follows

  • Gitlab-ci this is a set of continuous integration system for GitLab. It is GitLab’s own system, which is attached to the server where you install GitLab. No need to think twice. .gitlab-ci.yml is responsible for script parsing.
  • Gitlab-runner is the bearer of script execution, and Runner is responsible for the running of script part of.gitlab-ci.yml. Gitlab-ci browsed the. Gitlab-ci. yml file in the project and assigned each Runner to run the corresponding script according to the rules in it. These scripts are used either for test projects or for deployment.
  • .gitlab-ci.yml This is a file in the root of a Git project that records a series of phases and execution rules. Gitlab-ci parses the push and calls Runner to run it based on what’s inside.

1 Preparations

1.1 gitlab environment

This can be set up as a private GitLab space or, for convenience, an official hosted repository.

Once the GitLab warehouse is set up, the GitLab CI is automatically installed. (Old version not applicable)

1.2 equipped withdockerandgitlab-runnerThe cloud server of the environment

  • Install the docker

  • Install GitLab – Runner

    The official website has detailed installation steps, the link is as follows:

    Docs.gitlab.com/runner/inst…

    Run the following command to install gitlab-ci-multi-Runner on the centOS

$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash $ yum  install gitlab-ci-multi-runnerCopy the code

That’s the Gitlab-Ci-multi-Runner

1.3 Project Code

Just say HelloWorld.

Add the Docker image name to pom.xml and prefix the image name in the properties

< properties > < Java version > 1.8 < / Java version > < docker. Image. The prefix > springboot < / docker. Image. The prefix > < / properties >Copy the code

Add Docker build plugins to plugins:

<! -- Docker maven plugin --> <plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> < version > 1.0.0 < / version > < configuration > < imageName > ${docker. Image. The prefix} / ${project. The artifactId} < / imageName > <dockerDirectory>src/main/docker</dockerDirectory> <resources> <resource> <targetPath>/</targetPath> <directory>${project.build.directory}</directory> <include>${project.build.finalName}.jar</include> </resource> </resources> </configuration> </plugin>Copy the code

1.4Dockerfilefile

Springboot (hello-docker) = springBoot (hello-docker) = springBoot (hello-docker)

Create a Dockerfile file under the directory SRC /main/docker. The Dockerfile file tells you how to build the image.

FROM its: 11.0.3 JDK - stretch RUN ln - sf/usr/share/zoneinfo/Asia/Shanghai/etc/localtime RUN echo 'Asia/Shanghai' >/etc/timezone VOLUME/TMP ADD subject-lib-0.0.1- snapshot.jar app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]Copy the code

1.5. .gitlab-ci.ymlfile

Gitlab provides a handy configuration tool, which is.gitlab-ci.yml. Place this file in the root directory of project.

Take Java SpringBoot project as an example, to configure a job that generates a docke R image, each time the project is tagged, the job execution will be triggered to generate an image, and the version of the image is the name of the tag.

The contents of.gitlab-ci.yml are as follows:

After_script: - docker rmI $(Docker images-q-f dangling=true) # Workflow workflow - build - test - deploy job_build: stage: build script: - mvn clean install job_test: stage: test script: - mvn test job_deploy: stage: deploy script: -if [$(docker ps -aq --filter name=hello-docker)]; then docker rm -f hello-docker; -docker run -d -p 8070:8070 --name hello-docker gyq/hello-docker only: -masterCopy the code

Only specifies that only the Git tags action and Triggers can trigger a task

< span style = “box-sizing: border-box; color: RGB (74, 74, 74); display: inherit! Important; word-break: inherit! Important;

Tags are used to filter qualified runners

The default script location is the project root directory, runner will first remove the entire project, and then run the job in the project root directory.

The usage of the gitlab-ci.yml file can be found in the official configuration documentation

2 Environment Configuration

2.1 Configuring Rights

When running tasks on runner, gitlab-Runner account is used. This account does not have root permission. If you want to use higher permission, you can raise the rights to Gitlab-Runner account.

Because only docker commands need higher permissions, you can use the way to create docker user groups to solve the problem. Run the following command as user root on runner:

usermod -aG docker gitlab-runner
Copy the code

Verify whether gitlab-runner has access to Docker:

sudo -u gitlab-runner -H docker info
Copy the code

Of course, you can also directly switch to the gitlab-runner user to check whether the docker command has permission

Permissions are important, so be sure to set them

2.2 Register the Runner server that performs the deployment task for the project

Register the runner with gitlab-CI, otherwise how will Gitlab-CI know who to call when the push event arrives? We can also find the difference between webhook mode and Webhook mode. In Webhook mode, we actively configure a connection to GitLab. Gitlab-runners just need to register.

So let’s register

$ gitlab-ci-multi-runner register
# guide will let you enter gitlab url, enter your url, such as http://gitlab.example.com/
# bootstrap will ask you to enter the token and go to the appropriate project to find the token, e.g. Ase12c235qazd32
# bootstrap will let you type a tag, a project may have more than one runner, according to the tag, enter a number of runners, such as web,hook,deploy
# bootstrap will ask you if automatic deployment is triggered without a tag, so I chose true for testing purposes
# boot will ask you if you want to lock the runner only for this project, I chose no by default
# boot will tell you to type executor, which is how to execute the script, shell.
Copy the code

Then you will be registered, and you can see the runner information you have registered in the corresponding position in GitLab.

3 Submit updates for automatic deployment

3.1. Commit code to git Master branch

After the runner registers successfully, the git command is used to submit updates to the master branch. If the master branch is modified, the Job will be executed.

3.2. Wait for the Job task to complete

You can view the job status and logs on the Gitlab page

3.3 Test Results

View ports to check for updates to the code

Reference documentation

[Backend] GitLab gitLab-CI automatic deployment

GitLab – CI and GitLab – Runner

How to use Docker in GitLab Continuous Integration

Use Gitlab CI/DI to automatically generate docker images

GitLab+Docker rapid construction CI/CD automated deployment

[Docker start Get Permission Denied]

Linux Add a user or add root permission to the user

communication

If you have any questions while reading this article, please feel free to comment on them to improve the mistakes or unclear expression of the article.

The public,