Настройка pipeline авто-деплоя в Kubernetes-кластер с помощью Gitlab и Helm

Имеются два окружения staging и production(так же будут называться и namespace-ы в Kubernetes-кластере)
Настраиваем автоматический deploy в Kubernetes кластер при коммите в одну из веток
При коммите в ветку develop – деплой приложений в namespace staging
При коммите в ветку staging – деплой приложений в namespace production
С помощью GitlabCI выполняется деплой,в котором используется Helm-чарт
Будет представлен только этап деплоя(подразумевается, что этапы тестов, сборки Docker-образа и загрузки образа в Docker-репозитарий были выполнены до стадии деплоя)
В Kubernetes-кластере с помощью Helm будут запущены redis, elasticsearch, кастомное/пользовательское myapp-приложение
Предположим, myapp-приложению требуется доступ к redis, elasticsearch и внешней MongoDB-базе данных( база данных не запускается в Kubernetes-кластере, а используется внешнее сторонее решение)

Буде создан Helm-чарт для удобства деплоя вышеуказанных приложений

Алгоритм действий состоит из следующих шагов
1. Настройка интеграции Gitlab с Kubernetes
2. Создание необходимых переменных в Gitlab
3. Создание GitlabCI/CD
4. Создание Helm-чарта
5. Создание необходимых namespace в Kubernetes-кластере
6. Проверка корректной работы авто-деплоя при коммите в репозитарий

 

1.Настройка интеграции Gitlab с Kubernetes
https://gitlab.com/help/user/project/clusters/index#adding-an-existing-kubernetes-cluster

 

Создание ServiceAccount, ClusterRoleBinding, получение значений необходимых параметров: URL для API-сервера, токена, ca-crt-файла

Узнаем URL для API-сервера

Создаем serviceaccount с именем gitlab в namespace default и предоставляем этому аккаунту роль cluster-admin

Провереяем наличие созданных ресурсов serviceaccount и clusterrolebinding

После выполнения  вышеуказанной команды (ubectl apply -f gitlab-kubernetes-integration.yaml) создается новый секрет gitlab-token-…..

Просмотр существующих секретов

Получение токена из имени секрета

Получение ca.crt- файла из имени секрета

 

Настройка подключения Gitlab к Kubernetes в Gitlab WEB-интерфейсе

После чего в WEB-интерфейсе Gitlab устанавливем
Helm Tiller и Gitlab Runner

После успешной установки проверяем наличие namespace gitlab-managed-apps

И наличие двух подов,запущенных в этом namespace(gitlab-managed-apps)

 

2.Создание необходимых переменных в Gitlab
Переменные KUBE_CONFIG, CI_MONGO_URL_STAGING, CI_MONGO_URL_PRODUCTION добавляем в переменные CI/CD в Gitlab

В переменных CI_MONGO_URL_STAGING и CI_MONGO_URL_PROD также экранируем запятые(если они там присутствуют) с помощью символа обратного слеша

Значение переменной KUBE_CONFIG получается из команды

т.е. в значение переменной помещаем base64-код
Содержимое файла ~/.kube/config-password

Важно!!!! Логин и пароль смотрим в Google WEB Interface

 

3. Создание GitlabCI/CD
Создаем CI/CD с помощью файла gitlab-ci.yml

Gitlab-runner запускает контейнер из образа

, в котором уже предусановлен helm,kubectl,docker

Значение глобальной переменной KUBECONFIG, которая определяет/содержит конфигурационный файл для kubectl(для возможности корректной авторизации в Kubernetes-кластере) наполняется из переменной Gitlab с именем KUBE_CONFIG,которую мы задали на предыдущем этапе
Значение переменной NAMESPACE будет подставляться из локальных переменных окружения,указанных в параметре “variables:” в файле .gitlab-ci.yml в зависимости от ветки, в которую был сделан коммит
— при коммите в ветку develop namespace будет иметь значение staging
— при коммите в ветку production namespace будет иметь значение production
Значения переменных CI_MONGO_URL_STAGING и CI_MONGO_URL_PROD будут браться из переменных Gitlab, которые мы задали на предыдущем этапе
Команда helm…. установит Helm-чарт,если он не существовал или обновит его,если он уже существует

 

4.Создание Helm-чарта
Структура HELM-чарта имеет вид

Содержимое файлов имеет вид

Файл с описанием Helm-чарта Chart.yaml

Файл с дефолтными значениями values.yaml

Шаблон для redis

Шаблон для elasticsearch

Шаблон для приложения myapp

Структра репозитария имеет вид

 

5.Создание необходимых namespace в Kubernetes-кластере

Создаем необходимые namespace – staging и production

 

6.Проверка корректной работы авто-деплоя при коммите
Коммитим код и проверяем CI/CD в Gitlab WEB-интерфейсе

 

В командной строке проверяем
Просмотр достпных Helm-чартов

Просмотр статуса/состояния указанного Helm-чарта

 

Источник:
https://docs.gitlab.com/ee/user/project/clusters
https://about.gitlab.com/2017/09/21/how-to-create-ci-cd-pipeline-with-autodeploy-to-kubernetes-using-gitlab-and-helm/

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

Яндекс.Метрика