Как в Kubernetes создать конвейерную обработку CI/CD с автодеплоем c использованием Gitlab и Helm

Published in

Southbridge

4 min readFeb 16, 2018

Со времени моих предыдущих публикаций [1] [2] о CI/CD многое изменилось. Я стал применять Helm для упаковочных приложений и перестал использовать docker-in-docker в gitlab-runner. Недавно я начал работать над несколькими микросервисами Golang.
Я решил прокешировать gitlab и разделить работу на несколько шагов для лучшей обратной связи в пользовательском интерфейсе.

Вот некоторые изменения, появившиеся в моем файле .gitlab-ci.yaml:

нет docker-in-docker;
использование кеша для программных пакетов вместо готового изображения с зависимостями;
разбиение на шаги;
автодеплой с помощью Helm.

Построение образа Golang

Поскольку golang привередлив к местоположению проекта, нужно внести некоторые изменения в работу CI. Изменения производятся в блоке before_script, который просто создает необходимые каталоги и исходный код ссылки. Предположительно официальным репозиторием проекта является gitlab.example.com/librerio/libr_files, поэтому сценарий должен выглядеть следующим образом.

variables:
  APP_PATH: /go/src/gitlab.example.com/librerio/libr_filesbefore_script:
  - mkdir -p /go/src/gitlab.example.com/librerio/
  - ln -s $PWD ${APP_PATH}
  - mkdir -p ${APP_PATH}/vendor
  - cd ${APP_PATH}

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

Согласно правилам кеширования GitLab нужно добавить каталог поставщика как в кеш, так и в артефакты. Кеш даст возможность использовать каталог между заданиями сборки, а программные изделия — внутри того же задания.

cache:
  untracked: true
  key: "$CI_BUILD_REF_NAME"
  paths:
    - vendor/setup:
  stage: setup
  image: lwolf/golang-glide:0.12.3
  script:
    - glide install -v
  artifacts:
    paths:
     - vendor/

Шаг сборки не изменился, дело в создании двоичной системы, которую я добавляю к артефактам.

build:
  stage: build
  image: lwolf/golang-glide:0.12.3
  script:
    - cd ${APP_PATH}
    - GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o release/app -ldflags '-w -s'
    - cd release
  artifacts:
    paths:
     - release/

Этап тестирования

Чтобы запустить тесты golang с отчетами о покрытии, я использую скрипт оболочки. Он выполняет все тесты в подкаталогах проекта и создает отчет о покрытии. Прежде чем опубликовать скрипт в gist, я немного изменил его, исключив каталог поставщика из тестов.

покрытие regexp для gitlab-ci: ^total:\s*\(statements\)\s*(\d+.\d+\%)

Этап развертывания

Я не использую встроенную интеграцию Gitlab с Kubernetes.

Сначала я думал о создании Kubernetes-секретов и проведении мониторинга в под gitlab-runner. Но это сложно: развертывание необходимо обновлять каждый раз, когда требуется добавить новую конфигурацию кластера. Поэтому я использую переменные CI/CD GitLab с конфигурацией Kubernetes и кодировкой base64. Каждый проект может иметь любое количество конфигураций. Процесс прост: создайте строку base64 из конфига и скопируйте его в буфер обмена. После этого поместите его в переменную kube_config (назовите ее как угодно).

cat ~/.kube/config | base64 | pbcopy

Если вы не обладаете полной установкой gitlab, подумайте о создании пользователя Kubernetes с ограниченными разрешениями.

Затем на этапе развертывания можно декодировать KUBECONFIG переменную обратно в файл и использовать ее с kubectl.

variables:
  KUBECONFIG: /etc/deploy/configdeploy:
  ...
  before_script:
    - mkdir -p /etc/deploy
    - echo ${kube_config} | base64 -d > ${KUBECONFIG}
    - kubectl config use-context homekube
    - helm init --client-only
    - helm repo add stable https://kubernetes-charts.storage.googleapis.com/
    - helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
    - helm repo update

Этап развертывания включает случай, когда у вас несколько версий одного и того же приложения.

Например, у вас есть две версии API: v1.0 и v1.1. Все, что нужно сделать, — установить appVersion в файле Chart.yaml. Система сборки проверяет версии API и развертывает или обновляет необходимую.

- export API_VERSION="$(grep "appVersion" Chart.yaml | cut -d" " -f2)"
- export RELEASE_NAME="libr-files-v${API_VERSION/./-}"
- export DEPLOYS=$(helm ls | grep $RELEASE_NAME | wc -l)
- if [ ${DEPLOYS}  -eq 0 ]; then helm install --name=${RELEASE_NAME} . --namespace=${STAGING_NAMESPACE}; else helm upgrade ${RELEASE_NAME} . --namespace=${STAGING_NAMESPACE}; fi

TL;DR;

Вот полный файл .gitlab-ci.yaml.

cache:
  untracked: true
  key: "$CI_BUILD_REF_NAME"
  paths:
    - vendor/before_script:
  - mkdir -p /go/src/gitlab.example.com/librerio/
  - ln -s $PWD ${APP_PATH}
  - mkdir -p ${APP_PATH}/vendor
  - cd ${APP_PATH}stages:
  - setup
  - test
  - build
  - release
  - deployvariables:
  CONTAINER_IMAGE: ${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_BUILD_REF_NAME}_${CI_BUILD_REF}
  CONTAINER_IMAGE_LATEST: ${CI_REGISTRY}/${CI_PROJECT_PATH}:latest
  DOCKER_DRIVER: overlay2  KUBECONFIG: /etc/deploy/config
  STAGING_NAMESPACE: app-stage
  PRODUCTION_NAMESPACE: app-prod  APP_PATH: /go/src/gitlab.example.com/librerio/libr_files
  POSTGRES_USER: gorma
  POSTGRES_DB: test-${CI_BUILD_REF}
  POSTGRES_PASSWORD: gormasetup:
  stage: setup
  image: lwolf/golang-glide:0.12.3
  script:
    - glide install -v
  artifacts:
    paths:
     - vendor/build:
  stage: build
  image: lwolf/golang-glide:0.12.3
  script:
    - cd ${APP_PATH}
    - GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o release/app -ldflags '-w -s'
    - cd release
  artifacts:
    paths:
     - release/release:
  stage: release
  image: docker:latest
  script:
    - cd ${APP_PATH}/release
    - docker login -u gitlab-ci-token -p ${CI_BUILD_TOKEN} ${CI_REGISTRY}
    - docker build -t ${CONTAINER_IMAGE} .
    - docker tag ${CONTAINER_IMAGE} ${CONTAINER_IMAGE_LATEST}
    - docker push ${CONTAINER_IMAGE}
    - docker push ${CONTAINER_IMAGE_LATEST}test:
  stage: test
  image: lwolf/golang-glide:0.12.3
  services:
    - postgres:9.6
  script:
    - cd ${APP_PATH}
    - curl -o coverage.sh https://gist.githubusercontent.com/lwolf/3764a3b6cd08387e80aa6ca3b9534b8a/raw
    - sh coverage.shdeploy_staging:
  stage: deploy
  image: lwolf/helm-kubectl-docker:v152_213
  before_script:
    - mkdir -p /etc/deploy
    - echo ${kube_config} | base64 -d > ${KUBECONFIG}
    - kubectl config use-context homekube
    - helm init --client-only
    - helm repo add stable https://kubernetes-charts.storage.googleapis.com/
    - helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
    - helm repo update
  script:
    - cd deploy/libr-files
    - helm dep build
    - export API_VERSION="$(grep "appVersion" Chart.yaml | cut -d" " -f2)"
    - export RELEASE_NAME="libr-files-v${API_VERSION/./-}"
    - export DEPLOYS=$(helm ls | grep $RELEASE_NAME | wc -l)
    - if [ ${DEPLOYS}  -eq 0 ]; then helm install --name=${RELEASE_NAME} . --namespace=${STAGING_NAMESPACE}; else helm upgrade ${RELEASE_NAME} . --namespace=${STAGING_NAMESPACE}; fi
  environment:
    name: staging
    url: https://librerio.example.com
  only:
  - master

Оригинал: HOW TO CREATE CI/CD PIPELINE WITH AUTODEPLOY TO KUBERNETES USING GITLAB AND HELM

Как в Kubernetes создать конвейерную обработку CI/CD с автодеплоем c использованием Gitlab и Helm

Построение образа Golang

Этап тестирования

Этап развертывания

TL;DR;

Written by Igor Olemskoi