At present, I am learning this part of the content, but maybe everyone’s environment is different, so I can not find a blog that can be completely operated without mistakes, so I also write it and record the whole process of building.

The installation of Docker will not be described here, basically a few lines of command can be used, if not, you can search other blogs. The environment I use locally is as follows:

  • Ubuntu16.04
  • Docker19.03
  • Management tool: IDEA Docker plug-in

The following describes the deployment process in detail.

preface

Those who read this blog should focus on Gitlab CI. Therefore, it is assumed that everyone has a certain understanding of Docker and Gitlab itself and has mastered basic usage.

CI/CD and Gitlab CI are not discussed here. The purpose of this paper is to practice CI. If you are interested in the concept of CI/CD and Gitlab CI, you can read reference 1-2.

Install Gitlab CE and Gitlab Runner

It is recommended to learn Docker in Linux system. With the increasing complexity of image and container use, more and more pits will appear in Win system. Gitlab CE construction is very simple, directly use the official image docker Run can be. However, since we need to deploy Runner and manage multiple containers, it is better to use Docker-compose, so it is used here.

Please refer to my previous article to solve the problem of Gitlab Volume permission for Windows Docker installation, which also mentioned how to use Docker-compose to install. I’ll just give you the configuration file.

version: '3'  # 1
services:
    gitlab:
      image: gitlab/gitlab-ce:latest  # 2
      container_name: "gitlab"
      restart: unless-stopped
      privileged: true
      hostname: "172.17.193.109:7780"  # 3
      environment:
        # 4
        GITLAB_OMNIBUS_CONFIG: | # external_url 'http://172.17.193.109:7780' gitlab_rails [" time_zone "] = "Asia/Shanghai" gitlab_rails["gitlab_shell_ssh_port"] = 7722 nginx["listen_port"] = 80      # 5
      ports:
        - "7780:80"
        - "7722:22"
      # 6
      volumes:
        - /home/cache/gitlab/config:/etc/gitlab
        - /home/cache/gitlab/data:/var/opt/gitlab
        - /home/cache/gitlab/logs:/var/log/gitlab
    gitlab-runner:
      container_name: gitlab-runner
      image: gitlab/gitlab-runner:latest  # 7
      restart: always
      volumes:
        - "/var/run/docker.sock:/var/run/docker.sock"
        - "/home/cache/gitlab/runner-config:/etc/gitlab-runner"
Copy the code

The skeleton of docker-comemage. yml is not explained here:

  • #1: is the version number of docker-compose file, which corresponds to the docker version and is clearly stated in the official Docker document. Usually I’ll just write 3.
  • #2: The current deployment uses the latest version of the official Gitlab image.
  • #3: Hostname specifies the entry address of Gitlab after successful deployment. Since the docker I’m using is not local, I set an IP address and write localhost locally. The current configuration means that the Gitlab page is accessed through port 7780 of 172.17.193.109.
  • #4: GITLAB_OMNIBUS_CONFIG is the Gitlab configuration parameter, corresponding/etc/gitlab/gitlab.rb. All key-value pairs in this file can be configured here and automatically configured when the container starts. You can also manually modify the gitlab.rb file after the Gitlab container is started.
  • #5: The two ports needed are configured. By default, port 80 inside the Gitlab container is used for accessing Gitlab pages and port 22 is used for SSH connections to remote repositories. Extranet mapping is performed for them respectively.
  • #6: Volume mapping, three volumes are consistent with the official document.
  • #7: Gitlab-Runner image is used here. Some blogs use the old version of Gitlab-Ci-multi-Runner. The latest image is changed to Gitlab-Runner.

Then run it directly from the root of docker-comemage. yml.

docker-compose up -d
Copy the code

At this time you can see the IDEA Docker plug-in.

This indicates that the container is being initialized. Wait for a while, open the IP :port configured previously, and you will see the Gitlab page. You need to reset the password of user root for the first time. The next step is normal use. Regardless of gitlab-Runner, which I’ll talk about later, there’s no configuration work to do at this point, just start up normally.

Create a Spring Boot project

The next project we build using Gitlab CI is a Hello World project based on Spring Boot. Let’s create it first. To simplify this process, we will directly select the Spring Boot template when creating a new project, which will generate a Hello World project for us, including a Dockerfile.

The project structure is the same as the one we created manually. So by this time the preparation is almost done. Before entering the Gitlab CI process, we can imagine what steps Gitlab CI can perform during the Spring Boot project deployment process. Our ultimate goal is that with Gitlab CI, the code that we push to the remote repository will be built automatically and run in a new container. Then there should be two specific steps:

  1. Pull the latest code and package it into a JAR.
  2. Container the jar, further build it into a Docker image and run it.

So the next operation is going to revolve around these two steps.

The configuration of Runner

After installing gitLab-Runner and creating the project, we need to register specific Runners for our project to perform CI tasks.

First we go to Gitlab project Settings –>CI/CD– >Auto DevOps. See the URL and registration token.

Enter the gitlab-runner container (exec /bin/bash) and execute the gitlab-Runner register to start the registration.

root@bb6040f1cd04:/# gitlab-runner registerRuntime Platform Arch = AMD64 OS = Linux PID =43 Revision = A987417A Version =12.2.0 Runninginsystem-mode. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): http://172.17.193.109:7780/ do enter the gitlab - ci tokenfor this runner:
zpzZ-shsCVxsJDZtAPNZ
Please enter the gitlab-ci description for this runner:
[bb6040f1cd04]: hello,spring boot!
Please enter the gitlab-ci tags for this runner (comma separated):
maven,docker
Registering runner... succeeded                     runner=zpzZ-shs
Please enter the executor: docker-ssh, shell, ssh, virtualbox, docker+machine, custom, parallels, docker-ssh+machine, kubernetes, docker:
docker
Please enter the default Docker image (e.g. ruby:2.6):
docker:latest
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Copy the code

Enter the corresponding values according to the steps. If the registration succeeds, the registration is complete. Refresh the Gitlab page at this time, you can see the runner who has just registered successfully.

Since we just configured some basic information according to the flow, there are additional parameters to configure, so we need to modify the corresponding configuration file. Can directly modify the mapping to the local/home/cache/gitlab/runner – config under the config directory. Toml. Each runner configured generates a [[runners]] in the configuration file.

[[runners]]
  name = "hello,spring boot!"
  url = "http://172.17.193.109:7780/"
  token = "u8_Y5rLQazUmBZar9eys"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = true  # 1
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"."/home/cg/.m2:/root/.m2"]  # 2
    shm_size = 0
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
Copy the code

What needs to be modified:

  • #1: Default false, need to change to true. When false, health check will be performed during CI construction, which is time-consuming and still fails. If it is set to true, the health check will be skipped automatically, and the reason is not explored at present.
  • #2: If there is a local Maven environment, you can hang it locally, so that you can use the local environment directly when handling dependencies, and you can use ali Cloud mirror source.

So runner needs to be triggered to work, and then gitlab-CI needs to be configured.

Containerization with Gitlab CI Auto DevOps configuration

Containerization is the process of converting a JAR into a Docker image. Dockerfile = Dockerfile;

FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY/ target/demo - 0.0.1 - the SNAPSHOT. Jar app. The jar
ENV PORT 5000
EXPOSE $PORT
ENTRYPOINT ["java"."-Djava.security.egd=file:/dev/./urandom"."-Dserver.port=${PORT}"."-jar"."/app.jar"]
Copy the code

Then add the configuration file –.gitlab-ci.yml for the Gitlab CI core and place it in the root directory of the project. When the Gitlab project is created, the Auto DevOps pipeline will be enabled by default. When a code is pushed to the repository, it will automatically scan the root directory for.gitlab-ci.yml. If so, Applications are built, tested, and deployed automatically based on predefined continuous integration and continuous delivery configurations. So let’s look at the specific configuration file:

image: docker:latest  # 1
variables:  # 2
  DOCKER_DRIVER: overlay2
  DOCKER_HOST: TCP: / / 172.17.193.109:2375  # docker host
  TAG: Root/hello - spring: v0.1  # mirror name
cache:  # 3
  paths:
    - .m2/repository
services:  # 4
  - docker:dind
stages:  # 5
  - package
  - deploy
maven-package:  # 6
  image: Maven: 3.5 JDK - 8 - alpine
  tags:
    - maven
  stage: package
  script:
    - mvn clean package -Dmaven.test.skip=true
  artifacts:
    paths:
      - target/*.jar
build-master:  # 7
  tags:
    - docker
  stage: deploy
  script:
    - docker build -t $TAG .
    - docker rm -f test || true
    - docker run -d --name test -p 5000: 5000 $TAG
  only:
    - master
Copy the code

Specific instructions:

  • #1: the image to use
  • #2: Some environment variables that must be configured. This parameter is not required if the configuration is localDOCKER_HOST.
  • #3: Configure the cache. After configuring the cache, maven’s downloaded dependencies can be cached so that they do not need to be downloaded again.
  • #4: Additional services needed to configure. Docker: Dind, this seems to be used to run docker in docker, needed in the construction of the project.
  • “Stages” is a term used in Gitlab CI. “Stages” is a construction stage. It is a series of processes that are executed sequentially and are Jobs dependent.
  • #6: One of the Jobs defined for building jar packages. Internally, maven images are introduced to handle the package process. Script Indicates the script to be executed.
  • #7: One of the Jobs defined for building Docker images. Responsible for executing the deploy process. Execute build and run. The only node monitors only the master branch.

Now that all of the configuration work is done, Git now commit&Push, and the automatic build begins. Go back to the Gitlab page and you can see the build process.

As you can see, the pipeline in the current Auto DevOps is already triggered, executing two phases (Package, deploy) at a time. You can view logs by stages.

When both phases are complete, you can directly access the previously configured port 5000 in your browser and see the Hello Spring page.

conclusion

This article talked about deploying Gitlab in Docker and trying to use its CI capabilities. Tools like Gitlab CI make sense for test and production deployments, both in terms of standardization and convenience. Docker provides a convenient deployment environment, especially for cross-platform invocation scenarios like our company’s.

References

  • What is CI/CD?
  • Continuous integration with GitLab CI
  • Continuous delivery of a Spring Boot application with GitLab CI and Kubernetes
  • Gitlab-ci environment construction and SpringBoot PROJECT CI configuration summary

This article was first written in 2019-09-25 and the information described in this article may have changed. Please use it with caution.