Непрерывное развертывание контейнеризованных приложений с помощью GitLab

GitLab — инструмент непрерывной интеграции (Continuous integration, CI).

В этом руководстве описаны:

• Сборка приложения в Docker-контейнер.
• Развертывание приложения из контейнера в кластере Yandex Managed Service for Kubernetes через GitLab с помощью инструментов Yandex Cloud.

После каждого коммита в GitLab:

• Выполнится сценарий, в котором описаны шаги сборки Docker-образа.
• Применится новая конфигурация кластера Managed Service for Kubernetes, в которой будет указано приложение для развертывания.

Чтобы настроить необходимую инфраструктуру для хранения исходного кода, сборки Docker-образа и развертывания приложения:

1. Подготовьте облако к работе.

   1. Изучите список необходимых платных ресурсов.

2. Подготовьте инфраструктуру.

3. Создайте инстанс GitLab.

4. Настройте GitLab.

5. Создайте тестовое приложение.

6. Создайте GitLab Runner.

7. Настройте аутентификацию Kubernetes в GitLab.

8. Настройте сценарий CI.

9. Проверьте результат.

Если созданные ресурсы больше не нужны, удалите их.

Подготовьте облако к работеПодготовьте облако к работе

Зарегистрируйтесь в Yandex Cloud и создайте платежный аккаунт:

1. Перейдите в консоль управления, затем войдите в Yandex Cloud или зарегистрируйтесь.
2. На странице Yandex Cloud Billing убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его и привяжите к нему облако.

Если у вас есть активный платежный аккаунт, вы можете создать или выбрать каталог, в котором будет работать ваша инфраструктура, на странице облака.

Подробнее об облаках и каталогах.

Необходимые платные ресурсыНеобходимые платные ресурсы

В стоимость поддержки инфраструктуры входит плата за следующие ресурсы:

• Диски и постоянно запущенные виртуальные машины (см. тарифы Yandex Compute Cloud).
• Использование динамического публичного IP-адреса (см. тарифы Yandex Virtual Private Cloud).
• Хранение созданных Docker-образов (см. тарифы Container Registry).
• Использование мастера Managed Service for Kubernetes (см. тарифы Managed Service for Kubernetes).

Подготовьте инфраструктуруПодготовьте инфраструктуру

Установите дополнительные зависимостиУстановите дополнительные зависимости

Установите в локальном окружении:

• Утилиту потоковой обработки JSON-файлов jq.
• Инструмент командной строки kubectl и настройте его на работу с созданным кластером Managed Service for Kubernetes.

Создайте инстанс GitLabСоздайте инстанс GitLab

Создайте инстанс Managed Service for GitLab или виртуальную машину с образом GitLab в той же облачной сети, где расположен кластер Managed Service for Kubernetes.

Настройте GitLabНастройте GitLab

Чтобы настроить GitLab и подготовить процесс непрерывной интеграции (Continuous Integration, CI), создайте новый проект и введите параметры для авторизации в CI:

Создайте тестовое приложениеСоздайте тестовое приложение

Создайте тестовое приложение, которое можно будет развернуть в кластере Yandex Managed Service for Kubernetes:

1. Добавьте в проект Dockerfile:

   1. Авторизуйтесь в GitLab.

   2. Откройте проект GitLab.

   3. В строке навигации по репозиторию нажмите кнопку и в выпадающем меню выберите пункт New file.

   4. Назовите файл Dockerfile и добавьте в него код:

      FROM alpine:3.10
      CMD echo "Hello"
      

   5. Напишите комментарий к коммиту в поле Commit message: Dockerfile for test application.

   6. Нажмите кнопку Commit changes.

2. Добавьте в проект манифест создания ресурсов кластера Managed Service for Kubernetes:

   1. Откройте проект GitLab.

   2. В строке навигации по репозиторию нажмите кнопку и в выпадающем меню выберите пункт New file.

   3. Назовите файл k8s.yaml:

      k8s.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: hello-world
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: hello-world-deployment
        namespace: hello-world
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: hello
        template:
          metadata:
            namespace: hello-world
            labels:
              app: hello
          spec:
            containers:
              - name: hello-world
                image: __VERSION__
                imagePullPolicy: Always
      

   4. Напишите комментарий к коммиту в поле Commit message: Docker image deployment config.

   5. Нажмите кнопку Commit changes.

Создайте GitLab RunnerСоздайте GitLab Runner

Чтобы запускать задачи сборки в кластере Yandex Managed Service for Kubernetes, создайте GitLab Runner.

После установки вы можете запускать автоматизированные сборки внутри своего кластера Managed Service for Kubernetes.

Подробнее про установку и настройку GitLab Runner читайте в документации GitLab.

Настройте аутентификацию Kubernetes в GitLabНастройте аутентификацию Kubernetes в GitLab

Настроить аутентификацию в GitLab можно с помощью токена сервисного аккаунта Kubernetes или приложения GitLab Agent:

Настройте сценарий CIНастройте сценарий CI

1. Создайте переменные окружения GitLab:

   1. На панели слева в GitLab перейдите в раздел Settings и во всплывающем списке выберите пункт CI/CD.

   2. Нажмите кнопку Expand напротив пункта Variables.

   3. Добавьте переменные окружения в зависимости от способа аутентификации Kubernetes в GitLab:

      Токен сервисного аккаунта

      GitLab Agent

      • KUBE_URL — адрес мастера Managed Service for Kubernetes. Узнайте его с помощью команды:

        yc managed-kubernetes cluster get <идентификатор_или_имя_кластера> --format=json \
           | jq -r .master.endpoints.external_v4_endpoint
        

      • KUBE_TOKEN — токен, который GitLab будет использовать для применения конфигурации. Используйте токен, полученный ранее.
      • CI_REGISTRY — адрес созданного ранее реестра в формате cr.yandexcloud.kz/<идентификатор_реестра>.
      • CI_REGISTRY_KEY — ключ, который GitLab будет использовать для доступа к реестру. Скопируйте содержимое файла статического ключа key.json для доступа к реестру, полученного ранее.

      Для добавления переменной:

      • Нажмите кнопку Add variable.
      • В появившемся окне в поле Key укажите имя переменной, в поле Value — значение переменной.
      • Нажмите кнопку Add variable.

2. Создайте файл конфигурации сценария CI:

   1. Откройте проект gitlab-test.

   2. В строке навигации по репозиторию нажмите кнопку и в выпадающем меню выберите пункт New file.

   3. Назовите файл .gitlab-ci.yml. Добавьте в него шаги сборки и загрузки Docker-образа и обновления конфигурации приложения в кластере Managed Service for Kubernetes. Структура файла зависит от способа аутентификации Kubernetes в GitLab:

      Токен сервисного аккаунта

      GitLab Agent

      • Для сборки контейнера с помощью kaniko без использования привилегированного режима GitLab Runner:

        .gitlab-ci.yml

        stages:
          - build
          - deploy
        
        build:
          stage: build
          image:
            name: gcr.io/kaniko-project/executor:debug
            entrypoint: [""]
          script:
            - mkdir -p /kaniko/.docker
            - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(echo -n "json_key:${CI_REGISTRY_KEY}" | base64 | tr -d '\n' )\"}}}" > /kaniko/.docker/config.json
            - >-
              /kaniko/executor
              --context "${CI_PROJECT_DIR}"
              --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
              --destination "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
        
        deploy:
          image: gcr.io/cloud-builders/kubectl:latest
          stage: deploy
          script:
            - kubectl config set-cluster k8s --server="$KUBE_URL" --insecure-skip-tls-verify=true
            - kubectl config set-credentials admin --token="$KUBE_TOKEN"
            - kubectl config set-context default --cluster=k8s --user=admin
            - kubectl config use-context default
            - sed -i "s,__VERSION__,${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}," k8s.yaml
            - kubectl apply -f k8s.yaml
        

      • Для сборки контейнера с помощью docker:dind c использованием привилегированного режима GitLab Runner:

        .gitlab-ci.yml

        stages:
          - build
          - deploy
        
        image: docker:20.10.16
        
        variables:
          DOCKER_HOST: tcp://docker:2376
          DOCKER_TLS_CERTDIR: "/certs"
          DOCKER_TLS_VERIFY: 1
          DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
          DOCKER_DRIVER: overlay2
        
        services:
          - docker:20.10.16-dind
        
        before_script:
          - for try in {1..10}; do sleep 0.5; docker info && break ; done
        
        build:
          stage: build
          script:
            - echo "${CI_REGISTRY_KEY}" | docker login ${CI_REGISTRY} -u json_key --password-stdin
            - >-
              docker build
              "${CI_PROJECT_DIR}"
              --file "${CI_PROJECT_DIR}/Dockerfile"
              --tag "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
            - docker push "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
        
        deploy:
          image: gcr.io/cloud-builders/kubectl:latest
          stage: deploy
          script:
            - kubectl config set-cluster k8s --server="$KUBE_URL" --insecure-skip-tls-verify=true
            - kubectl config set-credentials admin --token="$KUBE_TOKEN"
            - kubectl config set-context default --cluster=k8s --user=admin
            - kubectl config use-context default
            - sed -i "s,__VERSION__,${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}," k8s.yaml
            - kubectl apply -f k8s.yaml
        

      • Для сборки контейнера с помощью kaniko без использования привилегированного режима GitLab Runner:

        .gitlab-ci.yml

        stages:
          - build
          - deploy
        
        build:
          stage: build
          image:
            name: gcr.io/kaniko-project/executor:debug
            entrypoint: [""]
          script:
            - mkdir -p /kaniko/.docker
            - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(echo -n "json_key:${CI_REGISTRY_KEY}" | base64 | tr -d '\n' )\"}}}" > /kaniko/.docker/config.json
            - >-
              /kaniko/executor
              --context "${CI_PROJECT_DIR}"
              --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
              --destination "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
        
        deploy:
          image: bitnami/kubectl:latest
          stage: deploy
          script:
            - kubectl config use-context ${CI_PROJECT_PATH}:<имя_GitLab_Agent>
            - cat k8s.yaml | sed -e "s,__VERSION__,${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}," | kubectl apply -f -
        

      • Для сборки контейнера с помощью docker:dind с использованием привилегированного режима GitLab Runner:

        .gitlab-ci.yml

        stages:
          - build
          - deploy
        
        image: docker:20.10.16
        
        variables:
          DOCKER_HOST: tcp://docker:2376
          DOCKER_TLS_CERTDIR: "/certs"
          DOCKER_TLS_VERIFY: 1
          DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
          DOCKER_DRIVER: overlay2
        
        services:
          - docker:20.10.16-dind
        
        before_script:
          - for try in {1..10}; do sleep 0.5; docker info && break ; done
        
        build:
          stage: build
          script:
            - echo "${CI_REGISTRY_KEY}" | docker login ${CI_REGISTRY} -u json_key --password-stdin
            - >-
              docker build
              "${CI_PROJECT_DIR}"
              --file "${CI_PROJECT_DIR}/Dockerfile"
              --tag "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
            - docker push "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
        
        deploy:
          image: bitnami/kubectl:latest
          stage: deploy
          script:
            - kubectl config use-context ${CI_PROJECT_PATH}:<имя_GitLab_Agent>
            - cat k8s.yaml | sed -e "s,__VERSION__,${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}," | kubectl apply -f -
        

      Вместо <имя_GitLab_Agent> укажите имя агента в Managed Service for GitLab.

   4. Напишите комментарий к коммиту в поле Commit message: CI scripts.

   5. Нажмите кнопку Commit changes.

   В файле .gitlab-ci.yml описаны два шага сборки проекта:

   • Сборка Docker-образа с использованием Dockerfile и загрузка образа в Container Registry.
   • Настройка окружения для работы с Kubernetes и применение конфигурации k8s.yaml к кластеру Managed Service for Kubernetes. Таким образом приложение развертывается на созданном ранее кластере Managed Service for Kubernetes.

Проверьте результатПроверьте результат

1. После сохранения файла конфигурации .gitlab-ci.yml запустится сценарий сборки. Чтобы проверить результаты его выполнения, на панели слева в проекте gitlab-test выберите пункт Build, в выпадающем меню выберите пункт Pipelines и дождитесь успешного завершения обоих этапов сборки.

2. Чтобы проверить работу созданного приложения в кластере Managed Service for Kubernetes, посмотрите логи контейнера в кластере:

   kubectl logs deployment/hello-world-deployment -n hello-world
   

   Результат:

   Hello
   

Удалите созданные ресурсыУдалите созданные ресурсы

Некоторые ресурсы платные. Удалите ресурсы, которые вы больше не будете использовать, во избежание списания средств за них:

1. Удалите созданные Docker-образы.

2. Удалите кластер Managed Service for Kubernetes и реестр Container Registry:

   Вручную

   Terraform

   1. Удалите кластер Managed Service for Kubernetes.
   2. Удалите реестр Container Registry.
   3. Удалите созданные подсети и сети.
   4. Удалите созданные сервисные аккаунты.

   1. В терминале перейдите в директорию с планом инфраструктуры.

      Важно

      Убедитесь, что в директории нет Terraform-манифестов с ресурсами, которые вы хотите сохранить. Terraform удаляет все ресурсы, которые были созданы с помощью манифестов в текущей директории.

   2. Удалите ресурсы:

      1. Выполните команду:

         terraform destroy
         

      2. Подтвердите удаление ресурсов и дождитесь завершения операции.

      Все ресурсы, которые были описаны в Terraform-манифестах, будут удалены.

3. Удалите созданную ВМ GitLab или инстанс Managed Service for GitLab.

См. такжеСм. также

• Создание тестовых ВМ через GitLab CI.