Материал подготовлен командой Simple-Server для администраторов VPS и выделенных серверов. Команды и пути проверяйте на тестовой машине перед production.
Кратко о задаче
Оба этих инструмента DevOps предлагают множество полезных функций для взаимодействия с функционалом Kube, однако GitLab — лучшее решение, если мы говорим об управлении несколькими кластерами Kubernetes. GitLab обеспечивает эффективное управление манифестами в репозиториях Git, позволяя структурировать их в мультиоблачной среде.
Главное преимущество GitLab в данном случае заключается в оптимальной иерархической структуре, позволяющей определять неограниченное количество групп. В свою очередь, GitHub накладывает целый ряд ограничений, которые не дают возможности определять иерархические группы вовсе. Именно поэтому для решения мультиоблачных задач стоит выбирать именно GitLab. Теперь расскажем пошагово о том, как это делать.
Перед тем как работать с GitLab на нашем сервере, нужно развернуть и настроить его. Для этого мы написали подробную статью по установке и настройке. При этом стоит учесть, что минимальные требования для нормальной работы GitLab на сервере (4 ГБ ОЗУ и 4 ядра) могут быть увеличены в зависимости от нагрузки на поддерживаемые кластеры.
Шаг 2. Создаем иерархические группы
GitLab позволяет определять группы внутри других групп, наследуя все переменные среды родительских групп. Для этого нужно сначала определить файл Kubeconfig в родительской группе, после чего можно использовать переменные среды во всех связанных проектах. В качестве примера рассмотрим 3 кластера Kubernetes в разных средах, таких как Simple-Server, Google Cloud и Azure. Сначала создаем группу и иерархию проектов.
Каждая группа представляет определенный кластер Kubernetes, и во всех наборах есть файлы манифеста, связанные с конкретными проектами. Например, мы можем создать проект с именем api-gateway в группе twc-pl-1. Таким образом, манифесты в рамках проекта будут предназначены для развертывания в нашем кластере Kubernetes (twc, то есть в облачной инфраструктуре Simple-Server.Cloud), расположенном в регионе pl-1 (регион взят для примера, он может быть и другим).
Также добавим, что для просмотра кластеров Kubernetes на уровне группы, на левой боковой панели нужно выбрать Search или go to. И после этого выбираем Operate > Kubernetes.
Шаг 3. Помещаем KubeConfig в переменные среды на уровне групп
Каждому проекту в группе GitLab можно настроить доступы к общим переменным среды, установленным как в родительской группе, так и на более высоких уровнях. Для этого нужно правильно настроить конфигурационный файл Kubeconfig, в котором прописаны учетные данные для подключения к серверу API Kubernetes. Это делается в настройках группы по следующему пути: Group Name -> CI/CD Settings -> Variables -> Add Variable.
Таким образом, нам нужно поместить файлы Kubeconfig всех наших кластеров Kubernetes в те группы, которые соотносятся с ними.
Шаг 4. Разворачиваем приложение с помощью GitLab CI
Теперь внутри каждого проекта создадим файлы манифеста и развернем их с помощью конвейера GitLab CI. Вот как это делается (на нашем примере api-gateway в группе twc-pl-1):
.
├── gitlab-ci.yml
└── manifests
├── configmap.yaml
├── deployment.yaml
└── service.yamlСвои манифесты внутри файла gitlab-ci.yml можно развернуть таким образом:
stages:
- deploy
deploy:
stage: deploy
image: bitnami/kubectl
script: |
for f in manifests/*
do
kubectl apply -f $f
doneОбратите внимание, что переменную среды Kubeconfig мы определяем в родительской группе, поэтому определять ее для каждого отдельного проекта излишне.
Разумеется, GitLab позволяет делегировать управление своими группами и проектами и членам команды, причем сделать это можно в соответствии с иерархией. При назначении доступа на уровне группы все проекты в группе будут наследовать единую модель доступа, что очень удобно, так как исключает изменение настроек доступа для каждого проекта.
Шаг 6. Инкапсулируем код CI/CD
Здесь для нас очень полезной оказывается функция создания шаблонов — еще один козырь GitLab в сравнении с главным конкурентом. Определяем общий шаблон для своего конвейера и включаем его везде, где нужно. Теперь, если нам понадобится изменить код, внесение изменений будет глобальным, а не в каждый отдельный проект.
Для инкапсулирования кода CI/CD создаем проект для его хранения, после чего включаем его в другие проекты. Внутри проекта шаблона должен находиться файл install.yml с содержимым, соответствующим содержимому файла gitlab-ci.yml (см. пример кода в шаге 3). Теперь обновляем все наши проекты и помещаем обновленные данные в файл gitlab-ci.yml, вот так:
include:
- project: 'cd/template'
ref: 'main'
file: 'install.yml'Вот и всё, на этом настройку группы кластеров Kubernetes можно считать завершенной.
Подведем итог. Мы научились создавать иерархические группы в GitLab, настраивать KubeConfig на уровне групп, развертывать приложение с помощью GitLab CI, назначать доступы пользователям и инкапсулировать код CI/CD для автоматизации управления проектом. Также теперь вы знаете, почему GitLab подходит для этих задач лучше, чем GitHub.
Нужен сервер для практики? Арендуйте VPS/VDS в России — root-доступ, NVMe, DDoS-защита и поддержка 24/7.