Наш эксперт Михаил Сергеев подготовил подробный материал (в двух форматах: статья и видеоурок), из которого вы узнаете:
- Что такое Gitlab, CI/CD, Helm;
- Как установить Gitlab в кластер Kubernetes;
- Как получить SSL сертификаты от Let`s Encrypt;
- Как настроить автоматический деплой нашего приложения.
Что такое GitLab, CI/CD, Helm
GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD-пайплайн и другими функциями. Код изначально был написан на Ruby, а некоторые его части были позже переписаны на Go.
Наиболее распространёнными альтернативами GitLab стали GitHub и Bitbucket. Интересный факт, что GitHub ориентирован на большие команды разработчиков, поскольку его выкупила Microsoft. А Bitbucket ориентирован на небольшие закрытые команды. Таким образом, каждый проект занимает свою нишу на рынке. Основное же преимущество GitLab заключается в возможности развернуть его на своих мощностях (на своём сервере) и хранить все данные у себя. А GitHub и Bitbucket являются онлайн сервисами, и весь код хранится на удалённых серверах, не подконтрольных группе разработчиков.
В целях безопасности специалисты рекомендуют использовать GitLab и хранить весь код у себя. Это кроссплатформенное программное обеспечение, позволяющее устанавливать его на различные операционные системы.
Helm — менеджер пакетов для Kubernetes.
Helm позволяет разработчикам программного обеспечения развёртывать и тестировать среду самым простым способом.
Требуется меньше времени, чтобы перейти от разработки к тестированию и продакшену.
Помимо повышения производительности, Helm предоставляет разработчикам удобный способ упаковки и отправки приложений конечным пользователям для установки.
Например, разработчик создаёт Helm Charts и передаёт его пользователю. Пользователь запускает Helm Charts и устанавливает приложение разработчика. Helm устанавливает приложение со всеми зависимостями.
На данном уроке мы с помощью Helm развернём GitLab в Kubernetes кластере. Потом мы создадим Helm Charts своего приложения и с помощью него настроим автоматический деплой (разворачивание новой версии программы) нашего приложения через GitLab.
Также нам понадобится сертификат Let’s Encrypt для защиты нашего приложения.
Let’s Encrypt — центр сертификации, предоставляющий бесплатные криптографические сертификаты X.509 для шифрования передаваемых через интернет данных по HTTPS и другим протоколам, используемым серверами в Интернете. Процесс выдачи сертификатов полностью автоматизирован.
Если не защищать своё приложение сертификатом, то все передаваемые через интернет данные могут стать доступны третьим лицам. Поэтому обязательно необходимо устанавливать сертификаты для защиты своего веб-приложения.
CI (Continuous Integration) — это технология автоматизации тестирования и сборки приложения.
CD (Continuous Delivery) — это технология автоматизации тестирования и сборки приложения и деплоя приложения.Установим Gitlab в кластер Kubernetes
Используемые в уроке команды:
#### Kubernetes алиасы echo "alias k='kubectl'" >> ~/.bashrc echo "alias kg='kubectl get'" >> ~/.bashrc echo "alias kgp='kubectl get po'" >> ~/.bashrc echo "alias kd='kubectl delete -f'" >> ~/.bashrc echo "alias ka='kubectl apply -f'" >> ~/.bashrc echo "alias ke='kubectl exec -it'" >> ~/.bashrc echo "alias k1='kubectl describe'" >> ~/.bashrc echo "alias kl='kubectl logs'" >> ~/.bashrc echo "alias kgs='kubectl get svc -A'" >> ~/.bashrc echo "alias kr='kubectl rollout restart deployment'" >> ~/.bashrc echo "alias krs='kubectl rollout restart sts'" >> ~/.bashrc echo "alias kpa='kubectl get po -A'" >> ~/.bashrc source ~/.bashrc
Рис.1 Установка GitLab и подключение к кластеру Kubernetes. Базы данных не рекомендуется заворачивать в кластере Kubernetes, особенно на сетевом хранилище, поскольку тогда всё работает значительно медленнее. Если у вас база данных, то установите её отдельно на виртуальный или физический сервер. Это, прежде всего, относится к высоконагруженным базам, использующим много ресурсов.
Установку Helm смотрите на официальном сайте Helm ( https://helm.sh/), где есть документация и инструкция по установке. Установка возможна на разные ОС.
Рис.2 Установка Helm Устанавливайте его на тот же ПК, с которого будете обращаться к кластеру Kubernetes. У нас он уже установлен (версия 3.7), поэтому приступим к установке GitLab.
Рис.3 Установка GitLab Рекомендуется создать директорию, в которой будут храниться конфигурации Helm Charts.
Давайте создадим папку для хранения конфигураций, например, Helms. Заходим в неё и добавляем адрес репозитария. Процесс похож на добавление репозитория в Ubuntu.
Скачиваем заархивированный установочной пакет. Для удобства скопируем файл с настройками. Мы выбрали способ установки, отличный от предлагаемого на сайте. Поскольку тут очень много настроек и их удобнее править, чем установить через консоль. Плюс мы можем файл с настройками редактировать и обновлять.
Есть две редакции GitLab: бесплатная Community Edition (CЕ) и платная Enterprise Edition (ЕЕ) Существуют её варианты: Starter, Premium и Ultimate). В платную версию добавлены различные дополнительные функции. Для её использования нужно приобрести лицензию на необходимое количество пользователей. После ввода лицензионного ключа разблокируются платные функции. Если раньше была разница в установщиках, то сейчас её нет, и можно устанавливать сразу платную Enterprise Edition. Их функционал будет идентичен, кроме дополнительных функций.
Первое, что нам необходимо, это домен. Можно использовать как свой домен, либо создать через сервис https://sslip.io.
Рис.4 Создание домена через сервис sslip.ioСмысл в том, что если вам нужно быстро выпустить сертификат через Let's Encrypt для IP адреса, но при этом нет возможности или долго прикручивать домен, его можно мгновенно сгенерировать через этот сервис. Есть также аналоги, например, https://nip.io/
Рис.5 Создание домена через сервис https://nip.io/. # Установка GitLab mkdir /helms cd /helms helm repo add gitlab https://charts.gitlab.io/ helm repo update helm pull gitlab/gitlab tar zxf gitlab-6.5.4.tgz rm -f gitlab-6.5.4.tgz cp gitlab/values.yaml gitlab.yaml vi gitlab.yaml k create ns gitlab helm upgrade --install gitlab -n gitlab -f gitlab.yaml gitlab/
Рис.6 Установка GitLab Полная установка занимает продолжительное время, ввиду большого количества разнообразных операций.
Рис.7 Установка GitLab. Проверка режима "докер" в "докере" Не забудьте включить режим privileged: true в файле gitlab.yaml, чтобы работал режим "докер" в "докере"
Так же необходимо добавить права для того, чтобы гитлаб мог создавать хелм-чарты:
k create clusterrolebinding gitlab-cluster-admin --clusterrole=cluster-admin --group=system:serviceaccounts --namespace=gitlab
Для обеспечения отказоустойчивости поды дублируются. Если один падает, то используется его копия.
Рис.8 Список подов GitLab 
Рис.9 Сервисы GitLab Теперь проверим доступность GitLab, введя в адресной строке браузера https://gitlab.195.208.185.64.sslip.io
Загрузится панель авторизации GitLab Enterprise Edition (по адресу https://gitlab.195.208.185.64.sslip.io/users/sign_in). Проверяем наше защищённое соединение https и выданный нам сертификат.
Рассмотрим, как вытащить из Kubernetes наш логин и пароль. Все пароли как правило хранятся в секретах (sekret).
Рис.10 Хранение пароля в secret # Получение пароля root от GitLab - вариант 1:
kg secret gitlab-gitlab-initial-root-password -n gitlab -o yaml
echo "hash" | base64 -d ; echo
# вариант 2:
kg secret gitlab-gitlab-initial-root-password -n gitlab -o jsonpath="{.data.password}" | base64 -d ; echo
Пароль можно посмотреть в YAML формате. Получаем наш пароль в зашифрованном виде. После расшифровки получаем длинный пароль, который лучше сразу поменять и проверить, войдя в GitLab Enterprise Edition.
Рис.11 Просмотр пароля в YAML формате. Вводим root и наш декодированный длинный пароль.
Далее рекомендуется заблокировать для всех доступ к GitLab, поскольку он является не пабликом проекта, а частью его внутренней инфраструктуры. Доступ должны иметь только сотрудники, например, через VPN.
Сгенерируем пару ключей: публичный и приватный. Приватный ключ нужно хранить у себя и никому не показывать (можно его зашифровать для большей надёжности). В открытом виде приватный ключ лучше не хранить в сетевых сервисах, поскольку его могут украсть. А публичный ключ может храниться где угодно.
Рис.12 Генерация SSH-ключа. # Установка агента
helm repo add gitlab https://charts.gitlab.io
helm repo update
helm upgrade --install ga gitlab/gitlab-agent \
--namespace gitlab \
--create-namespace \
--set image.tag=v15.5.1 \
--set config.token=viny9iKyEYxzzxGmPwsK1XFSnYkv4TQ3NwEt3KNqnyZczGebcA \
--set config.kasAddress=wss://kas.195.208.185.64.sslip.io
После установки агента переходим в кластер Kubernetes и проверяем подключение агента. Будет написано Name – devel, Connection status – Connected.
# CI - переменные: KUBE_INGRESS_BASE_DOMAIN 195-208-185-64.sslip.io KUBE_NAMESPACE gitlab POSTGRES_ENABLED false TEST_DISABLED true
Этих 4 переменных нам будут достаточно. Их можно также определить в файле GitLab CI в самом репозитории, но намного безопаснее их определить в настройках GitLab в разделе CI/CD. Поскольку в этот раздел закрыт доступ пользователям с правами девелопер. А в файл GitLab CI может зайти любой авторизованный пользователь.
## Файлы: #.gitlab/auto-deploy-values.yaml service: internalPort: 80 externalPort: 80 ingress: annotations: cert-manager.io/issuer: gitlab-issuer # Dockerfile FROM ubuntu:22.04 ARG DEBIAN_FRONTEND=noninteractive RUN apt update && apt install apache2 php -y RUN rm /var/www/html/* -f COPY ./index.php /var/www/html/index.php WORKDIR /var/www/html CMD ["apachectl", "-D", "FOREGROUND"] EXPOSE 80
Рис.13 Создание файла # Инициализация и пуш гит-репозитория: git init git add . git remote add origin ssh://git@192.168.0.7:31438/dev/l1.git git commit -m "Initial commit" git push --set-upstream origin master
Рис.14 Инициализация и пуш гит-репозитория Получим SSL сертификаты от Let`s Encrypt
Certbot генерирует сертификаты автоматически
# Информация о сертификатах: kg Issuers, ClusterIssuers, Certificates, CertificateRequests, Orders, Challenges -n gitlab ### Важно # Любая автоматизация деплоя — это не безопасно, используйте её с осторожностью. # Удалить GitLab: helm repo remove gitlab helm uninstall -n gitlab