Автоматизация деплоя в Kubernetes с помощью GitLab CI

Архитектура CI/CD и методы интеграции GitLab с кластером Kubernetes

Добро пожаловать на курс «Автоматизация деплоя в Kubernetes с помощью GitLab CI». Это первая статья, в которой мы заложим фундамент для всех последующих практических занятий. Прежде чем писать скрипты и конфигурации, необходимо четко понимать, как взаимодействуют между собой компоненты системы, где выполняется код и каким образом команды доставки доходят до вашего кластера.

В этой статье мы разберем архитектуру CI/CD, роль GitLab Runner и основные методы «общения» между GitLab и Kubernetes.

Что такое CI/CD в контексте Kubernetes?

Аббревиатура CI/CD расшифровывается как Continuous Integration (Непрерывная интеграция) и Continuous Delivery/Deployment (Непрерывная доставка/развертывание).

В классической разработке процесс выглядел так: разработчик писал код, передавал его системному администратору, а тот вручную копировал файлы на сервер. В мире Kubernetes и микросервисов такой подход невозможен из-за сложности и масштаба систем.

При использовании GitLab CI процесс выглядит следующим образом:

CI (Integration): Разработчик отправляет код в репозиторий. GitLab автоматически запускает тесты, сборку приложения и создание Docker-образа.

CD (Delivery/Deployment): Если тесты прошли успешно, GitLab инициирует процесс обновления приложения в кластере Kubernetes, используя новые образы.

!Общая схема потока данных от кода разработчика до работающего приложения в кластере.

Ключевые компоненты архитектуры

Чтобы понять, как настроить деплой, нужно знать участников процесса. Их всего три:

1. GitLab Server

Это «мозг» операции. Здесь хранится ваш код, настройки доступа и конфигурация пайплайнов (файлы .gitlab-ci.yml). GitLab Server управляет очередью задач, но сам он не выполняет сборку или деплой.

2. GitLab Runner

Это «руки» системы. GitLab Runner — это отдельное приложение (агент), которое получает задачи от GitLab Server и выполняет их. Именно Runner запускает команды docker build, kubectl apply и другие.

> Важно понимать: когда вы пишете скрипт деплоя, этот скрипт выполняется не на сервере GitLab, а на машине, где установлен Runner.

3. Kubernetes Cluster

Это целевая среда, где должно работать ваше приложение. Кластер управляется через API-сервер. Чтобы развернуть приложение, нам нужно отправить правильные команды этому API-серверу.

Где разместить GitLab Runner?

Один из самых важных архитектурных вопросов — где именно должен находиться Runner. Существует два основных подхода.

Подход А: Внешний Runner

Runner установлен на отдельной виртуальной машине или используется общий (Shared) Runner, предоставляемый GitLab.com.

* Плюс: Простота старта (не нужно ничего инсталлировать, если используете облачные раннеры). * Минус: Для деплоя Runner должен иметь сетевой доступ к API вашего кластера Kubernetes. Это означает, что API кластера должен быть открыт в интернет, что создает потенциальные риски безопасности.

Подход Б: Runner внутри кластера

Вы устанавливаете GitLab Runner прямо внутрь вашего Kubernetes-кластера (как обычный под).

* Плюс: Безопасность. Раннеру не нужно выходить в интернет, чтобы «постучаться» в кластер — он уже внутри. API кластера можно закрыть от внешнего мира. * Плюс: Скорость. Скачивание образов и кэширование происходит быстрее внутри внутренней сети. * Минус: Требует предварительной настройки и выделения ресурсов кластера.

!Сравнение расположения Runner относительно кластера Kubernetes.

Методы интеграции GitLab и Kubernetes

Как именно Runner сообщает кластеру: «Эй, обнови приложение»? Существует несколько способов аутентификации и взаимодействия.

1. Прямое использование KUBECONFIG (Push-модель)

Это самый простой и распространенный метод для начинающих. Вы берете файл конфигурации доступа к кластеру (kubeconfig), кодируете его и сохраняете как переменную в GitLab CI/CD Variables.

В скрипте пайплайна это выглядит примерно так:

Как это работает: Runner скачивает переменную, создает временный файл с ключами доступа и использует утилиту kubectl для отправки команд в кластер.

Недостатки: * Вам нужно передавать чувствительные данные (ключи админа или сервисного аккаунта) в GitLab. * Если API кластера закрыт фаерволом, этот метод не сработает с внешними раннерами.

2. GitLab Agent for Kubernetes (Рекомендуемый метод)

Это современный способ интеграции, который решает проблемы безопасности. В кластер устанавливается специальный агент (GitLab Agent).

Как это работает: Агент устанавливает исходящее соединение с GitLab. Это работает как туннель. GitLab Server использует этот туннель, чтобы передавать команды в кластер. Вам не нужно открывать порты во внешний мир.

Преимущества агента: * Не нужно хранить KUBECONFIG в переменных CI/CD. * Работает за NAT и фаерволами. * Позволяет использовать GitOps-подходы (автоматическая синхронизация состояния).

3. Сертификатная интеграция (Устарело)

Ранее в GitLab существовала кнопка «Add Kubernetes Cluster», которая требовала вставки URL API и токена. Этот метод (Certificate-based integration) официально объявлен устаревшим (deprecated) в пользу GitLab Agent, поэтому в нашем курсе мы не будем его рассматривать.

Стратегии деплоя: Push vs Pull

Понимая архитектуру, стоит упомянуть две философии доставки кода.

Push-based (Классический CI/CD)

Именно этот подход мы будем изучать в первой части курса. GitLab (через Runner) активно «толкает» (push) изменения в кластер.

* Логика: «Я собрал новый образ -> Я запускаю команду kubectl set image». * Инструменты: Стандартные .gitlab-ci.yml пайплайны.

Pull-based (GitOps)

В этом подходе кластер сам следит за репозиторием. Внутри кластера работает оператор (например, ArgoCD или Flux, а также GitLab Agent в режиме GitOps).

* Логика: «Я вижу, что в git-репозитории изменился манифест -> Я привожу себя в соответствие с этим манифестом». * Инструменты: GitLab Agent, ArgoCD.

Резюме

Для успешной автоматизации деплоя нам нужно:

GitLab Server для хранения кода и управления процессами.

GitLab Runner, который будет выполнять «грязную работу».

Способ связи, предпочтительно через GitLab Agent или, для простых случаев, через KUBECONFIG.

В следующей статье мы перейдем от теории к практике и подготовим необходимое окружение: создадим простой кластер и настроим локальные инструменты для работы.

Готовы погрузиться в практику? Тогда до встречи в следующем уроке!

Настройка сборки Docker-образов и работа с Container Registry

Приветствую вас во второй части курса «Автоматизация деплоя в Kubernetes с помощью GitLab CI». В предыдущей статье мы разобрали архитектуру CI/CD и выяснили, что для доставки приложения в кластер нам необходим посредник — GitLab Runner, а также определились со способом взаимодействия с Kubernetes.

Однако, прежде чем что-то деплоить, нам нужно это «что-то» создать. Kubernetes не умеет работать с исходным кодом напрямую (например, с файлами .py, .js или .go). Он понимает только язык контейнеров. Поэтому наша первая практическая задача — научить GitLab автоматически упаковывать код в Docker-образ и сохранять его в доступном месте.

В этой статье мы настроим этап сборки (Build Stage), разберемся с концепцией Docker-in-Docker и научимся правильно тегировать образы для безопасного обновления.

Что такое Container Registry и зачем он нужен?

Представьте, что вы приготовили блюдо (написали код) и упаковали его в контейнер. Теперь этот контейнер нужно где-то хранить, чтобы курьер (Kubernetes) мог его забрать и доставить клиенту. Этим хранилищем выступает Container Registry (Реестр контейнеров).

!Схема пути Docker-образа: от сборки на Runner до хранения в Registry.

Существует множество реестров: Docker Hub, Google Container Registry (GCR), Amazon ECR. Но в рамках экосистемы GitLab удобнее всего использовать встроенный GitLab Container Registry. Он не требует дополнительной настройки аутентификации, так как тесно интегрирован с CI/CD пайплайнами.

Подготовка: Dockerfile

Для сборки образа нам нужен рецепт — файл Dockerfile. Предположим, у нас есть простое веб-приложение. В корне вашего репозитория должен лежать файл с примерно таким содержанием:

Без этого файла автоматизация невозможна, так как Runner не будет знать, как именно упаковать ваше приложение.

Проблема «Яйца в утке»: Docker-in-Docker

Здесь мы сталкиваемся с техническим нюансом. GitLab Runner, который выполняет ваши задачи, сам часто запускается внутри Docker-контейнера. Чтобы внутри этого контейнера собрать другой Docker-образ, нам нужна технология Docker-in-Docker (DinD).

По сути, мы просим Runner запустить сервис Docker внутри себя, чтобы иметь возможность выполнять команды docker build и docker push.

В конфигурации .gitlab-ci.yml это реализуется через ключевое слово services.

Написание пайплайна: .gitlab-ci.yml

Создадим файл .gitlab-ci.yml в корне проекта. Это инструкция для GitLab Runner. Начнем с этапа сборки.

1. Определение этапов

Сначала объявим, какие этапы (stages) будут у нас в пайплайне. Пока только один:

2. Задача сборки (Build Job)

Теперь опишем саму задачу. Нам нужно:

Использовать образ, в котором есть клиент docker.

Запустить сервис docker:dind.

Авторизоваться в реестре.

Собрать образ.

Отправить (push) образ в реестр.

Вот как это выглядит в коде:

bash CI_COMMIT_SHA

Что здесь происходит:

Мы пытаемся скачать предыдущую версию latest, чтобы использовать её как базу для кэша (|| true нужно, чтобы пайплайн не упал, если это первая сборка и образа еще нет).

В команде build мы указываем --cache-from, подсказывая Docker, где искать слои.

Мы вешаем два тега: уникальный SHA (для деплоя) и latest (для кэша следующей сборки).

Итоговый результат

После того как вы закоммитите файл .gitlab-ci.yml в репозиторий, зайдите в раздел Build -> Jobs в интерфейсе GitLab. Вы увидите запущенную задачу. Если всё настроено верно, в конце лога будет написано Job succeeded.

Затем перейдите в Deploy -> Container Registry. Там вы увидите ваш свежесобранный Docker-образ. Он готов к отправке в Kubernetes.

В следующей статье мы подготовим наш Kubernetes-кластер к приему гостей: настроим права доступа и создадим необходимые манифесты для деплоя.

Создание базового пайплайна .gitlab-ci.yml для деплоя манифестов

Приветствую вас в третьей части курса «Автоматизация деплоя в Kubernetes с помощью GitLab CI». Мы уже проделали большой путь: разобрались с архитектурой взаимодействия компонентов и научились собирать Docker-образы, сохраняя их в Container Registry. Теперь у нас есть «кирпичики» (образы), и настало время построить из них «дом» (запустить приложение в кластере).

В этой статье мы соединим все части воедино. Мы напишем манифесты Kubernetes, научимся динамически подставлять в них версии образов и настроим финальный этап пайплайна — Deploy.

Подготовка манифестов Kubernetes

Kubernetes работает декларативно. Это значит, что мы не говорим ему «запусти контейнер», а описываем желаемое состояние системы в виде YAML-файлов (манифестов), и отправляем их в API кластера. Кластер сам решает, как достичь этого состояния.

Для нашего базового примера нам понадобятся два ресурса:

Deployment: описывает, какое приложение запускать, сколько копий (реплик) держать и как их обновлять.

Service: открывает доступ к приложению внутри или снаружи кластера.

Создайте в корне вашего проекта папку k8s и поместите туда два файла.

Файл k8s/deployment.yaml

Здесь есть важный нюанс. В предыдущем уроке мы решили использовать хеш коммита (CI_REGISTRY_IMAGE:CI_REGISTRY_IMAGE:KUBE_CONFIG_FILE # 2. Проверяем связь (опционально, для отладки) - kubectl version --short # 3. Подставляем правильный тег образа в манифест - sed -i "s|__IMAGE__|CI_COMMIT_SHA|g" k8s/deployment.yaml # 4. Применяем манифесты - kubectl apply -f k8s/ yaml stages: - build - deploy

variables: # Отключаем TLS для Docker-in-Docker (если требуется) DOCKER_TLS_CERTDIR: ""

build_image: stage: build image: docker:24.0.5 services: - docker:24.0.5-dind before_script: - docker login -u CI_REGISTRY_PASSWORD CI_REGISTRY_IMAGE:CI_REGISTRY_IMAGE:KUBE_CONFIG_FILE - sed -i "s|__IMAGE__|CI_COMMIT_SHA|g" k8s/deployment.yaml - kubectl apply -f k8s/ bash kubectl get pods kubectl get svc `

Вы должны увидеть поды вашего приложения в статусе Running.

Возможные проблемы и их решение

* Ошибка x509: certificate signed by unknown authority: Обычно возникает, если GitLab Runner не доверяет сертификату вашего кластера Kubernetes. Решение: добавить сертификат CA кластера в доверенные на раннере или использовать insecure-skip-tls-verify в kubeconfig (не рекомендуется для продакшена). * Ошибка ImagePullBackOff: Кластер не может скачать образ. Причина: Kubernetes не авторизован в GitLab Registry. Решение: нужно создать секрет docker-registry в Kubernetes и добавить поле imagePullSecrets в deployment.yaml`. Мы разберем это детально в продвинутых уроках, но для быстрого старта убедитесь, что ваш реестр публичный или настройте секреты.

В этой статье мы реализовали классический Push-based подход к деплою. GitLab активно «толкает» изменения в кластер. Это просто, понятно и отлично работает для небольших проектов.

В следующем уроке мы поговорим о том, как управлять конфигурациями для разных окружений (Dev, Stage, Prod) и как сделать наш пайплайн более гибким.

Шаблонизация и управление релизами с использованием Helm и GitLab CI

Приветствую вас в четвертой части курса «Автоматизация деплоя в Kubernetes с помощью GitLab CI». В предыдущем уроке мы научились деплоить приложение, используя простые манифесты и команду sed для подмены версии образа. Это отличный способ понять основы, но в реальных проектах он быстро становится неудобным.

Представьте, что у вас не один микросервис, а десять. И для каждого нужно поддерживать отдельные файлы для Dev, Stage и Production окружений. Количество YAML-файлов начнет расти в геометрической прогрессии, превращаясь в то, что инженеры называют «YAML Hell» (YAML-ад). Любое изменение (например, добавление новой переменной окружения) придется копировать вручную в десятки файлов.

Сегодня мы изучим инструмент, который стал стандартом индустрии для решения этой проблемы — Helm. Мы разберем, как превратить наши статичные манифесты в гибкие шаблоны и настроить их автоматический деплой через GitLab CI.

Почему sed и kubectl apply недостаточно?

Вспомним наш подход из прошлого урока:

У этого метода есть несколько фундаментальных недостатков:

Сложность управления конфигурацией: Если вам нужно изменить количество реплик только для продакшена, вам придется либо создавать дубликаты файлов (deployment-prod.yaml, deployment-dev.yaml), либо писать сложные скрипты с множеством sed.

Отсутствие контроля версий релиза: kubectl apply просто меняет состояние. Если деплой прошел неудачно, нет простой команды «откати всё назад как было» (хотя kubectl rollout undo существует, он работает только для Deployment, но не для ConfigMap или Service).

Нечитаемость: Обилие плейсхолдеров вроде __IMAGE__, __PORT__, __ENV__ делает YAML-файл невалидным для локального тестирования.

Что такое Helm?

Helm — это менеджер пакетов для Kubernetes. Его часто сравнивают с apt в Ubuntu или npm в JavaScript, но для кластеров.

Helm оперирует тремя главными понятиями:

Chart (Чарт): Пакет Helm. Это набор шаблонизированных YAML-файлов. Можно сказать, что это «рецепт» вашего приложения.

Values (Значения): Конфигурационные файлы, которые заполняют шаблоны. Это «ингредиенты», которые делают рецепт уникальным для конкретного окружения.

Release (Релиз): Экземпляр чарта, запущенный в кластере Kubernetes.

!Визуализация процесса объединения шаблонов и значений в готовый релиз.

Анатомия Helm Chart

Давайте преобразуем наши манифесты из прошлого урока в Helm Chart. Для начала создадим структуру папок в корне проекта:

1. Chart.yaml

Это паспорт вашего приложения.

2. values.yaml

Здесь мы описываем переменные, которые будем использовать в шаблонах. Это единая точка правды для конфигурации.

3. Шаблонизация (templates/deployment.yaml)

Теперь самое интересное. Мы берем наш старый deployment.yaml и заменяем жестко прописанные значения на переменные из values.yaml. Helm использует язык шаблонов Go templates.

Синтаксис прост: {{ .Values.путь.к.переменной }}.

Обратите внимание: нам больше не нужны sed и плейсхолдеры __IMAGE__. Если мы запустим этот шаблон локально, Helm подставит значения из values.yaml. Если нам нужно изменить порт или количество реплик, мы просто правим values.yaml, не трогая сложную логику Deployment.

Управление окружениями (Dev, Stage, Prod)

Главная сила Helm раскрывается, когда нам нужно задеплоить одно и то же приложение в разные среды с разными настройками.

Вместо копирования папок, мы просто создаем дополнительные файлы значений:

Файл values-prod.yaml:

При деплое Helm возьмет базовый values.yaml и перезапишет его значениями из values-prod.yaml.

Интеграция Helm в GitLab CI

Теперь, когда мы подготовили чарт, давайте научим GitLab CI использовать его. Нам понадобится Docker-образ, в котором установлен клиент helm.

Обновление .gitlab-ci.yml

Изменим наш этап deploy. Вместо kubectl apply мы будем использовать команду helm upgrade --install.

Эта команда делает следующее:

Если релиза еще нет — она его устанавливает (install).

Если релиз уже есть — она обновляет его (upgrade), применяя только изменения.

Разбор команды

* upgrade --install: Универсальная команда для создания или обновления. * my-release-name: Имя релиза в кластере. * ./my-chart: Путь к папке с чартом в репозитории. * --set image.tag=KUBE_CONFIG_FILE - helm upgrade --install my-app-CI_COMMIT_SHA --values VALUES_FILE, чтобы указывать Helm, какой конфигурационный файл брать для конкретной ветки.

Преимущества перехода на Helm

Атомарность: Helm обновляет все ресурсы (Deployment, Service, Ingress, ConfigMap) как единое целое. Если что-то пошло не так, релиз помечается как failed.

История и откаты: Вы можете выполнить команду helm rollback my-release-name 1, чтобы мгновенно вернуть кластер к состоянию предыдущей версии, если новый деплой оказался с ошибками.

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

Заключение

Мы сделали огромный шаг вперед в культуре доставки кода. Теперь наш деплой — это не просто набор разрозненных команд kubectl, а управляемый, версионируемый процесс. Мы научились отделять конфигурацию (Values) от логики (Templates) и динамически управлять версиями образов.

В следующей, заключительной статье курса, мы рассмотрим вопросы безопасности: как управлять секретами, не храня пароли в Git, и как настроить автоматический откат (Rollback) при падении пайплайна.

До встречи на следующем уроке!

Управление секретами, безопасность пайплайнов и стратегии отката изменений

Поздравляю вас! Мы добрались до финальной статьи курса «Автоматизация деплоя в Kubernetes с помощью GitLab CI». Мы прошли путь от ручного запуска команд до создания гибких Helm-чартов. Теперь у нас есть работающий конвейер, который доставляет код в кластер.

Но есть одна проблема. Наш текущий пайплайн похож на дом с открытыми дверями. Мы не обсуждали, где хранить пароли от баз данных, какие права давать нашему Runner’у и что делать, если новый релиз «уложит» продакшн. В этой статье мы закроем эти двери на замок и научим нашу систему самовосстановлению.

Управление секретами: Где хранить пароли?

Первое и самое главное правило DevOps: никогда не храните секреты в Git-репозитории. Даже если репозиторий приватный.

Если вы напишете пароль от базы данных в файле values.yaml, он останется в истории коммитов навсегда. Любой разработчик, имеющий доступ к коду, увидит его. Это недопустимо.

Как передавать секреты безопасно?

В GitLab CI есть специальный механизм — CI/CD Variables. Это защищенное хранилище пар «ключ-значение». Данные оттуда попадают в пайплайн только в виде переменных окружения в момент выполнения задачи.

!Путь секрета от настроек проекта до кластера Kubernetes без сохранения в коде.

#### Шаг 1. Добавление переменной в GitLab

Зайдите в Settings -> CI/CD -> Variables. 2. Нажмите Add variable. 3. Введите Key (например, DB_PASSWORD) и Value. 4. Обязательно отметьте галочку Mask variable. Это заставит GitLab скрывать значение в логах (заменять на [MASKED]), если оно случайно будет выведено на экран.

#### Шаг 2. Проброс секрета через Helm

Теперь нам нужно передать эту переменную в наш Helm-чарт. Мы не будем писать её в файл, а используем флаг --set в команде деплоя.

В файле .gitlab-ci.yml:

#### Шаг 3. Использование секрета в Чарте

Внутри чарта мы должны создать объект Secret, который Kubernetes понимает нативно. Создайте файл templates/secret.yaml:

А в deployment.yaml мы ссылаемся на этот секрет:

Таким образом, пароль живет только в настройках GitLab и в памяти кластера Kubernetes, минуя файлы репозитория.

Безопасность пайплайна: Принцип наименьших привилегий

В первых уроках мы использовали KUBECONFIG администратора или токен с широкими правами. Для обучения это нормально, но для продакшена — опасно. Если злоумышленник захватит контроль над вашим CI-пайплайном, он получит полный доступ к кластеру.

Использование ServiceAccount

Правильный подход — создать в Kubernetes специальный ServiceAccount для GitLab Runner и выдать ему права только на конкретный namespace (пространство имен).

Вот пример RBAC (Role-Based Access Control) манифеста для создания ограниченного пользователя:

Используя токен этого аккаунта, Runner сможет управлять приложением, но не сможет удалить весь кластер или прочитать секреты других проектов.

Стратегии отката изменений (Rollback)

Даже с идеальным кодом случаются ошибки. Приложение может запуститься, но начать отдавать 500-е ошибки или падать из-за нехватки памяти. В таких случаях критически важно быстро вернуть всё «как было».

Ручной откат с помощью Helm

Helm хранит историю всех релизов. Вы можете посмотреть её командой:

Вы увидите список ревизий. Чтобы откатиться на предыдущую версию, достаточно выполнить:

Где 1 — это номер ревизии, на которую мы хотим вернуться.

Автоматический откат: Атомарные деплои

В CI/CD мы хотим автоматизировать этот процесс. Если деплой прошел неудачно, пайплайн должен сам откатить изменения и сообщить об ошибке.

Для этого в Helm существует мощнейший флаг --atomic.

Давайте обновим наш скрипт деплоя:

Что делает --atomic?

Он применяет изменения.

Он ждет (как флаг --wait), пока все поды перейдут в состояние Ready.

Если по истечении тайм-аута (в примере 5 минут) приложение не запустилось, Helm автоматически выполняет rollback к предыдущей успешной версии.

Команда возвращает код ошибки, и пайплайн в GitLab помечается красным (Failed).

Это спасает от ситуаций, когда «битый» релиз висит в полузапущенном состоянии, а пользователи видят ошибку.

Дополнительные меры защиты

Сканирование образов (Container Scanning)

GitLab умеет автоматически проверять ваши Docker-образы на наличие известных уязвимостей. Для этого достаточно добавить шаблон в ваш .gitlab-ci.yml:

Это добавит в пайплайн задачу, которая просканирует образ и покажет отчет. Если в базовом образе (например, node:14) найдена критическая дыра, вы узнаете об этом до деплоя.

Protected Branches

Убедитесь, что деплой в Production происходит только из защищенных веток (например, main или master). В настройках репозитория (Settings -> Repository -> Protected branches) ограничьте круг лиц, которые могут делать push или merge в эти ветки.

Заключение курса

Мы прошли большой путь. Давайте подведем итоги того, чему вы научились:

Архитектура: Поняли, как Runner связывается с кластером.

Сборка: Научились собирать Docker-образы и работать с Registry.

Базовый деплой: Освоили kubectl и простые манифесты.

Шаблонизация: Перешли на Helm для управления сложными конфигурациями.

Безопасность: Научились прятать секреты и настраивать автоматические откаты.

Теперь у вас есть фундамент для построения профессиональных CI/CD процессов. Мир Kubernetes огромен, и впереди еще много тем: мониторинг (Prometheus), логирование (ELK/Loki), GitOps (ArgoCD). Но база, которую вы получили здесь, позволит вам уверенно чувствовать себя в любой DevOps-команде.

Спасибо, что были с нами на этом курсе. Удачи в автоматизации!