Docker Gitlab CI развертывает проект Spring Boot

Я сейчас изучаю эту часть, но среда у всех может быть разной, поэтому я не могу найти блог, который может полноценно работать без ошибок, поэтому я написал его сам и записал весь процесс строительства.

Установка Docker здесь описываться не будет, в принципе достаточно нескольких строчек команд, если не знаете, то можете поискать в других блогах. Среда, которую я использую локально, выглядит следующим образом:

• Ubuntu16.04
• Docker19.03
• Инструменты управления: плагин IDEA Docker

Процесс развертывания подробно описан ниже.

предисловие

Друзья, которые читают этот блог, должны сосредоточиться на Gitlab CI, поэтому предполагается, что каждый имеет определенное представление о Docker и самом Gitlab и осваивает базовое использование.

Что касается CI/CD и Gitlab CI, я не планирую здесь говорить об этом, цель этой статьи — боевые действия. можно прочитать ссылки 1-2.

Установите Gitlab CE и Gitlab Runner.

Изучать Docker рекомендуется под системой Linux.С усложнением использования образов и контейнеров ям под Win будет все больше и больше. Построение Gitlab CE очень простое, просто используйте официальный образ docker run напрямую. Однако, поскольку нам также необходимо развернуть Runner и управлять несколькими контейнерами, лучше использовать Docker-Compose, поэтому он используется здесь.

Вы можете обратиться к моей предыдущей статье,Решите проблему с разрешением на установку Gitlab Volume с помощью Windows Docker., в котором также упоминается, как установить его с помощью Docker-Compose. Здесь я приведу непосредственно файл конфигурации.

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"

Конкретные инструкции заключаются в следующем (здесь не объясняется структура файла docker-compose.yml):

• #1: Это номер версии файла docker-compose, который соответствует версии docker, которая четко указана в официальной документации docker. Обычно достаточно 3.
• #2: Текущее развертывание использует последнюю официальную версию образа Gitlab.
• #3: Имя хоста заполняет адрес входа в Gitlab после успешного развертывания. Поскольку докер, который я использую, не является локальным, я настраиваю IP-адрес и пишу localhost локально. Текущая конфигурация означает, что доступ к странице Gitlab осуществляется через порт 7780 из 172.17.193.109.
• #4: GITLAB_OMNIBUS_CONFIG — это параметр конфигурации Gitlab, соответствующий/etc/gitlab/gitlab.rb. Все пары ключ-значение в этом файле можно настроить здесь, и они будут автоматически настроены при запуске контейнера. Конечно, вы также можете вручную изменить файл gitlab.rb после запуска контейнера Gitlab.
• # 5: Настройте два порта, которые необходимо использовать. Внутренний порт контейнера Gitlab по умолчанию 80 используется для доступа к странице Gitlab, а 22 используется для подключения ssh к удаленному репозиторию. Выполните сопоставление экстрасети для них соответственно.
• # 6: Отображение тома, три тома соответствуют официальным документам.
• #7: Здесь используется образ gitlab-runner.Gitlab-ci-multi-runner, используемый некоторыми блогами, является старой версией, а последний образ единообразно изменен на gitlab-runner.

Далее можно запускать непосредственно в корневом каталоге docker-compose.yml.

docker-compose up -d

В настоящее время вы можете увидеть плагин IDEA для Docker.

Это означает, что контейнер инициализируется, подождите некоторое время, откройте настроенный ранее ip:port, и вы увидите страницу Gitlab. При первом использовании вам необходимо сбросить пароль учетной записи root. Следующий шаг — использовать его в обычном режиме. На данный момент игнорируйте gitlab-runner, я расскажу о нем позже, в настоящее время нет необходимости выполнять какие-либо работы по настройке, пока он запускается нормально.

Создайте проект Spring Boot

Далее, проект, который мы создали с помощью Gitlab CI, представляет собой проект hello world на основе Spring Boot, поэтому давайте сначала создадим его. Чтобы упростить этот процесс, мы напрямую выбираем шаблон Spring Boot при создании нового проекта, который создаст для нас проект hello world и включит Dockerfile.

Структура проекта такая же, как мы создали вручную. Тогда подготовительная работа в основном делается в это время. Прежде чем приступить к процессу Gitlab CI, мы можем представить, какие шаги может выполнить Gitlab CI в процессе развертывания проекта Spring Boot. Наша конечная цель — автоматически создавать код, который мы отправляем в удаленный репозиторий через Gitlab CI, и запускать его в новом контейнере. Тогда конкретные шаги должны состоять из 2 шагов:

1. Извлеките последний код и упакуйте его в банку.
2. Контейнеризируйте банку, встройте ее в образ Docker и запустите.

Затем следующая операция основывается на этих двух шагах.

Настроить бегунов

После установки Gitlab-Runner и создания проекта нам нужно зарегистрировать конкретный раннер для нашего проекта для выполнения задач CI.

Сначала открываем настройки проекта Gitlab--->CI/CD--->Auto DevOps. См. URL-адрес и токен регистрации.

Зайдите в контейнер gitlab-runner (exec /bin/bash) и выполните регистрацию gitlab-runner, чтобы начать регистрацию.

root@bb6040f1cd04:/# gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=43 revision=a987417a version=12.2.0
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://172.17.193.109:7780/
Please enter the gitlab-ci token for 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!

Согласно шагам введите по очереди соответствующие значения, и регистрация будет завершена, если регистрация прошла успешно. В это время обновите страницу Gitlab, и вы увидите бегун, который только что был успешно зарегистрирован.

Поскольку мы только что настроили некоторую базовую информацию в соответствии с процессом, и есть дополнительные параметры, которые необходимо настроить, нам необходимо изменить соответствующий файл конфигурации. Вы можете напрямую изменить сопоставление с локальным/home/cache/gitlab/runner-configв каталогеconfig.toml. Каждый раз, когда бегун настраивается, в файле конфигурации создается [[бегунки]].

[[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]

Где изменить:

• № 1: Значение по умолчанию — false, и его необходимо изменить на true. При значении false проверка работоспособности будет выполняться при построении CI, что отнимает много времени и все равно дает сбой.Если установлено значение true, проверка будет пропущена автоматически, а причина не исследована.
• # 2: Если локально есть среда maven, вы можете повесить ее локально, чтобы вы могли напрямую использовать локальную среду при обработке зависимостей, и вы можете использовать источник изображения Alibaba Cloud.

Затем нужно запустить раннер для работы, а затем настроить Gitlab-CI.

Контейнеризация и конфигурация Gitlab CI Auto DevOps

Контейнеризация — это процесс преобразования jar в образ Docker. Давайте изменим Dockerfile, который был автоматически сгенерирован ранее:

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

Затем добавьте файл конфигурации для ядра Gitlab CI —.gitlab-ci.yml, и поместите его в корневой каталог проекта. Когда создается проект Gitlab, конвейер Auto DevOps будет включен по умолчанию. Когда код помещается в хранилище, он автоматически проверяет, содержит ли корневой каталог.gitlab-ci.yml, если таковые имеются, для автоматической сборки, тестирования и развертывания приложений на основе предопределенных конфигураций непрерывной интеграции и непрерывной доставки. Затем давайте посмотрим на конкретный файл конфигурации:

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  # 镜像名称
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

Конкретные инструкции:

• #1: Зеркала, которые нужно использовать
• # 2: Некоторые переменные среды, которые необходимо настроить. Если локальный не может быть настроенDOCKER_HOST.
• #3: Настройка кеша После настройки загруженные maven зависимости можно кэшировать, и нет необходимости повторять загрузку в следующий раз.
• #4: Настройте дополнительные службы, которые необходимо использовать. docker: dind, похоже, это вещь для запуска докера в докере, что требуется при построении проекта.
• # 5: этапы, это концепция в Gitlab CI. Этапы означают этапы сборки, которые представляют собой некоторые последовательные процессы выполнения. Конкретное выполнение зависит от заданий.
• # 6 : Одно из определенных заданий для сборки пакета jar. Внутри для обработки вводится образ maven, который отвечает за выполнение процесса package. script - это сценарий, который должен быть выполнен.
• # 7: Одно из определенных заданий для создания образов Docker. Отвечает за выполнение процесса развертывания. В частности, выполнить сборку и запуск. Единственный узел указывает, что отслеживается только основная ветвь.

Итак, вся работа по настройке завершена, затем Git выполняет commit&push, и начинается автоматическая сборка. Вернитесь на страницу Gitlab, чтобы увидеть процесс сборки.

Видно, что конвейер в текущем Auto DevOps запущен, и одновременно будут выполняться всего два этапа (упаковка, развертывание). Логи можно просматривать поэтапно.

После завершения двух этапов вы можете напрямую получить доступ к ранее настроенному порту 5000 в браузере и увидеть страницу hello, spring.

Суммировать

В этой статье рассказывается о развертывании Gitlab в Docker и экспериментах с его функциями CI. Такие инструменты, как Gitlab CI, по-прежнему имеют смысл для тестирования и развертывания в рабочей среде как с точки зрения спецификации, так и с точки зрения удобства. Docker предоставляет удобную среду развертывания, особенно для таких сценариев, как наша компания, требующих межплатформенных вызовов.

References

• Что такое CI/CD?
• Непрерывная интеграция с GitLab CI
• Continuous delivery of a Spring Boot application with GitLab CI and Kubernetes
• Создание среды GitLab-CI и сводка конфигурации CI проекта SpringBoot

Эта статья была впервые написана 25 сентября 2019 г. Информация, описанная в статье, могла быть изменена, пожалуйста, используйте ее с осторожностью.