Непрерывное развертывание контейнеризованных приложений Managed Service for Kubernetes

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. Для этого установите приложение 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.yandex/<идентификатор_реестра>.
      • 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 с планом инфраструктуры.

   2. Удалите конфигурационный файл k8s-and-registry-for-gitlab.tf.

   3. Проверьте корректность файлов конфигурации Terraform с помощью команды:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

   4. Подтвердите изменение ресурсов.

      1. Выполните команду для просмотра планируемых изменений:

         terraform plan
         

         Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

      2. Если вас устраивают планируемые изменения, внесите их:

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

            terraform apply
            

         2. Подтвердите изменение ресурсов.

         3. Дождитесь завершения операции.

      Все ресурсы, которые были описаны в конфигурационном файле k8s-and-registry-for-gitlab.tf, будут удалены.

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

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

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