Привет, Хабр! С вами не опять, а снова Виктор Ашакин, DevOps-инженер компании «Флант», и мы заканчиваем приготовление экосистемы управления кодом и его развёртывания в Deckhouse Kubernetes Platform на основе Gitea. В прошлой части статьи мы сделали всё необходимое для создания тестового репозитория и написания Gitea Actions-пайплайнов и можем двигаться дальше.
В этом — завершающем — материале создадим репозиторий с кодом приложения, подготовим простенький Helm-чарт и Gitea Actions-пайплайн, в котором опишем автоматический процесс сборки и деплоя приложения в кластер Kubernetes.
Ключевым компонентом автоматизации CI/CD будет werf, Open Source-утилита, созданная «Флантом» и пополнившая ряды Sandbox-проектов CNCF. Она организует полный цикл доставки приложения в Kubernetes и использует Git как единый источник истины для состояния приложения, развёрнутого в кластере. Утилита werf позволяет собирать и упаковывать код приложения в контейнеры, эффективно кэшировать стадии и изменения при сборке, что значительно ускоряет пайплайн.
С выходом версии 2.0 и переходом на новый движок werf ещё качественнее развёртывает приложения в кластер Kubernetes. В процессе активной работы над приложениями в container registry и на раннере накапливается значительное количество ненужных образов контейнеров — werf позволяет эффективно чистить весь лишний мусор.
Все эти полезные функции мы применим в нашем пайплайне.
Подготовка тестового репозитория
Для начала создадим в Gitea тестовый репозиторий hello-world внутри организации: в правом верхнем углу кнопка «+» → Owner: your_organization → Create Repository.
Клонируем репозиторий к себе:
git clone git@your_gitea.com:team-romeo/hello-world.git cd hello-worl touch README.md git add README.md git commit -m "first commit" git pushТеперь добавим код нашего приложения. В моём случае это простая HTML-страница, которая лежит в каталоге app/index.html:
<!DOCTYPE html> <html> <body> <header> <h1> Hi! I'm another one typical nginx! </h1> <h2> Kubernetes, Kubernetes everywhere! </h2> </header> </body> </html> Теперь нужно подготовить файл werf.yaml для сборки нашего приложения. В моём примере происходит простое копирование файла в контейнер nginx. В реальной ситуации может происходить многоуровневая сборка с переиспользованием стадий сборки нескольких контейнеров.
werf нативно работает с файлами Dockerfile, но при этом мы теряем преимущество кэширования стадий сборки. Для каждого изменения состояния репозитория
будет запускаться повторный сборочный процесс, что зачастую избыточно. Зачем пересобирать приложение, если мы добавили в репозиторий Helm-чарт,
поправили README.md или файл, который в коде не участвует? Также избыточно постоянно переустанавливать в контейнере одни и те же пакеты.
Я покажу, как оптимизировать сборку с помощью werf stapel. В корне создаём файл werf.yaml — это аналог Dockerfile, сценарий сборки:
# Название приложения, оно будет использоваться в чарте как .Chart.Name project: hello-world configVersion: 1 --- image: nginx from: nginx:1.24.0-bullseye # Директива указывает, что и куда кладём, # можно задать несколько директив списком git: - add: /app to: /app # Директива указывает, что исключать при добавлении в контейнер, # также изменения в этих файлах не будут отслеживаться excludePaths: - .helm - werf.yaml - .gitea - README.md # Указываем, что на стадии install отслеживаем все файлы в каталоге /app. # Можно фильтровать файлы по маскам, например */*.html stageDependencies: install: - "*/**" # В этой директиве управляем процессом сборки, # стадии удобно комбинировать со стадиями добавления кода # Разные стадии кэшируются отдельно shell: install: - sed -i 's/Kubernetes/Deckhouse/g' app/index.html setup: - rm /etc/nginx/conf.d/default.confПроцесс сборки у меня достаточно прост: в Docker-образ nginx я помещаю каталог /app по пути /app, после выполняю команду редактирования index.html, а затем удаляю дефолтный конфиг nginx. Последний шаг нужен потому, что мы подложим наш конфиг в виде configmap для удобства редактирования и выката. Но об этом чуть позже.
В моём werf.yaml я оставил комментарии, из которых понятны структура файла и директива управления сборкой. Пример выше расширен для наглядности, но его можно максимально упростить:
project: hello-world configVersion: 1 --- image: nginx from: nginx:1.24.0-bullseye git: - add: /app to: /app stageDependencies: install: - "*/**" shell: setup: - sed -i 's/Kubernetes/Deckhouse/g' app/index.html - rm /etc/nginx/conf.d/default.confHelm-чарт
Теперь подготовим Helm-чарт приложения. По умолчанию werf ищет каталог с чартом в корне репозитория в каталоге .helm. Структура нашего чарта будет выглядеть так:
├── .helm ├── templates │ ├── deployment.yaml │ ├── ingress.yaml │ ├── nginx-config-cm.yaml │ └── service.yaml └── values.yamlСоздаём ресурсы чарта
# deployment.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Chart.Name }} labels: app: {{ .Chart.Name }} annotations: # Аннотация включает автоматическое отслеживание CM и secrets # Перезапускает под в случае изменения "pod-reloader.deckhouse.io/auto": "true" spec: revisionHistoryLimit: 1 selector: matchLabels: app: {{ .Chart.Name }} replicas: 1 template: metadata: labels: app: {{ .Chart.Name }} spec: volumes: - name: configs configMap: name: {{ .Chart.Name }} imagePullSecrets: # Название секрета для подключения к container registry - name: gitea-regsecret containers: - name: nginx image: {{ .Values.werf.image.nginx }} ports: - containerPort: 80 volumeMounts: - name: configs mountPath: /etc/nginx/nginx.conf subPath: nginx.conf --- # ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .Chart.Name }} labels: app: {{ .Chart.Name }} spec: rules: # С помощью переменной $WERF_ENV, которая передаётся при развёртывании, определяем, какой url подставить в окружение - host: {{ pluck .Values.werf.env .Values.app.url | first | default .Values.app.url._default }} http: paths: - path: "/" pathType: ImplementationSpecific backend: service: name: {{ .Chart.Name }} port: number: 80 --- # service.yaml apiVersion: v1 kind: Service metadata: name: {{ .Chart.Name }} labels: app: {{ .Chart.Name }} spec: selector: app: {{ .Chart.Name }} ports: - name: http port: 80 --- # nginx-config-cm.yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Chart.Name }} labels: app: {{ .Chart.Name }} data: nginx.conf: | error_log /dev/stderr; events { worker_connections 100000; multi_accept on; } http { charset utf-8; server { listen 80; index index.html; root /app; error_log /dev/stderr; location / { try_files $uri /index.html$is_args$args; } } } --- # values.yaml app: url: _default: 'hello-dev.example-domain.com' stage: 'hello-flant.example-domain.com' prod: 'hello.example-domain.com'Внимательный читатель заметит, что в Helm-чарте активно используется переменная .Chart.Name, но при этом сам файл chart.yaml, из которого обычно берётся эта переменная, отсутствует. Ошибки нет, .Chart.Name подставляется из переменной project: hello-world, указанной в файле werf.yaml
В манифесте deployment.yaml в директиве image: используется переменная {{ .Values.werf.image.nginx }}. При деплое werf подставит туда image:tag из стадии build. Эту переменную нужно подставлять везде, где используются собранные образы из werf.yaml.
В ресурсе ingress.yaml мы подставляем доменное имя приложения согласно окружению, в которое выкатываем приложение. Название окружения задаётся на стадии выката через ключ команды werf converge --env $ENV или через переменную окружения WERF_ENV. Подобным методом — через Helm-функцию pluck — удобно шаблонизировать переменные.
В ресурсе deployment.yaml есть аннотация "pod-reloader.deckhouse.io/auto": "true", которая показывает модулю DKP pod-reloader, что нужно следить за данным ресурсом и автоматически перезагружать контейнеры, если в связанных конфигурационных файлах или секретах произошли изменения.
Наш чарт готов, добавляем в репозиторий всё, что создали в каталоге:
git add . git commit -am 'add chart' git pushGitea Actions CI/CD-пайплайн
Gitea Actions копирует подход GitHub Actions, их синтаксисы практически идентичны. Большинство пайплайнов, написанных для GitHub Actions, скорее всего, будут работать и в Gitea Actions.
Gitea Actions поддерживает контекстные переменные от GitHub Actions. На момент написания статьи не поддерживался только метод on: workflow_dispatch (в релизе v1.22), что исключает ручной запуск пайплайна. Разработчики обещают добавить данный функционал в релизе 1.23.
Пайплайн будет состоять из двух стадий — сборки и развёртывания. Триггер для запуска пайплайна — коммит в Gitea.
Сборка (build-and-publish) — на этой стадии в раннер загружается код приложения, затем утилита werf на основании сценария сборки (werf.yaml) собирает и упаковывает код в образ Docker-контейнера. Сборка происходит на основании состояния кода, зафиксированного в коммите, который запустил пайплайн. В финале werf отправляет собранный Docker-образ в container registry.
Развёртывание (deploy) — на этой стадии werf формирует Helm-чарт (производит рендер YAML-манифестов), определяет образ, собранный на предыдущем шаге и подставляет его в Helm-чарт. Далее werf развёртывает Helm-чарт в кластере Kubernetes как Helm-релиз.
В контекстных переменных мы можем определить, из какой ветки был запущен пайплайн, на основе какого события, кто делал коммит и так далее. Эти данные позволяют задавать условия для выполнения тех или иных стадий пайплайна.
В моём примере сборка происходит из любого коммита, то есть Docker-образ будет одинаков для тестового и prod-окружения и займёт меньше места в хранилище образов. Разделение между продуктовым кодом и тестовым желательно проводить за счёт переменных окружения, которые передаются в Helm-релиз на этапе развёртывания.
Для наглядности приложение будет развёртываться в три разных окружения в зависимости от следующих условий:
-
Выкат в dev-окружение из любых веток и тегов, кроме веток master, stage и тегов с маской
release-*. -
Выкат в prod-окружение из ветки мастер или тега с маской
release-*. -
Выкат в stage-окружение из ветки stage.
Пайплайны должны находиться в каталоге .gitea/workflows и иметь формат .yaml. Создадим каталог и пайплайн с произвольным названием:
mkdir -vp .gitea/workflows vim ci-cd.yamlА теперь рассмотрим готовый пайплайн. Все пояснения будут после.
Готовый пайплайн
name: build and deploy run-name: ${{ gitea.actor }} is testing out Gitea Actions # Условие для запуска пайплайна — запушили коммит в репозиторий on: [push] # Переменные, заданные на глобальном уровне, будут доступны на глобальном уровне во всех стадиях пайплайна env: # Обязательные переменные APP_NAME: hello-world WERF_VERSION: 2 stable WERF_REPO: ${{ vars.WERF_REPO }}/${{ gitea.repository }} WERF_IMAGE_REPO_USER: ${{ vars.WERF_IMAGE_REPO_USER }} WERF_IMAGES_REPO_TOKEN: ${{ secrets.WERF_IMAGES_REPO_TOKEN }} # Устанавливаем аннотации, нужные при развёртывании (необязательные, но полезные переменные) WERF_ADD_ANNOTATION_WERF_RELEASE_CHANNEL: 'werf.io/release-channel=${{ env.WERF_VERSION }}' WERF_ADD_ANNOTATION_PROJECT_GIT: 'project.werf.io/git=${{ gitea.event.repository.html_url }}' WERF_ADD_ANNOTATION_CI_COMMIT: 'ci.werf.io/commit=${{ gitea.event.head_commit.url }}' WERF_ADD_ANNOTATION_GITEA_CI_PIPELINE_URL: 'gitea.ci.werf.io/pipeline-url=${{ gitea.event.repository.html_url }}/actions/runs/${{ gitea.run_id }}' WERF_ADD_ANNOTATION_GITEA_CI_JOB_URL: 'gitea.ci.werf.io/job-url=${{ gitea.event.repository.html_url }}/actions/runs/${{ gitea.run_id }}/jobs/${{ gitea.action }}' # Стадии пайплайна jobs: # Стадия сборки build-and-publish: name: Build and Publish # Указываем тег, определяющий раннер runs-on: werf # Обязательный шаг всех стадий, подгружаем репозиторий и его состояние steps: - name: Checkout code uses: actions/checkout@v3 with: fetch-depth: 0 # Необязательный шаг, добавлен для возможности просмотра массива переменных контекста пайплайна # Используя контекстные переменные, строим условия для запуска стадий и шагов пайплайна - name: Dump Gitea context env: JOB_CONTEXT: ${{ toJson(gitea) }} run: echo "$JOB_CONTEXT" # werf логинится в репозиторий и производит сборку - name: Build run: | source "$(~/bin/trdl use werf 2 stable)" werf cr login -u $WERF_IMAGE_REPO_USER -p ${{ secrets.WERF_IMAGES_REPO_TOKEN }} $WERF_REPO werf build # Развёртывание в dev deploy-dev: name: Deploy dev needs: build-and-publish runs-on: werf # Условие выполнения текущей стадии deploy-dev # Пайплайн запускается не из ветки master, не из ветки stage, не из тега, который начинается с release- if: gitea.ref != 'refs/heads/master' && gitea.ref != 'refs/heads/stage' && ! startsWith(gitea.ref, 'refs/tags/release-') steps: - name: Checkout code uses: actions/checkout@v3 with: fetch-depth: 0 # Шаг развёртывания приложения в кластер # Активируем werf с указанием версии, в данном случае # переменная WERF_ENV участвует в формировании Helm-чарта - name: Deploy env: WERF_ENV: dev run: | source "$(~/bin/trdl use werf ${{ env.WERF_VERSION }})" werf converge -Z # Развёртывание в prod deploy-prod: name: Deploy prod needs: build-and-publish runs-on: werf if: gitea.ref == 'refs/heads/master' || startsWith(gitea.ref, 'refs/tags/release-') steps: - name: Checkout code uses: actions/checkout@v3 with: fetch-depth: 0 - name: Deploy env: WERF_ENV: prod run: | source "$(~/bin/trdl use werf ${{ env.WERF_VERSION }})" werf converge -Z # Развёртывание в stage deploy-stage: name: Deploy stage needs: build-and-publish runs-on: werf if: gitea.ref == 'refs/heads/stage' steps: - name: Checkout code uses: actions/checkout@v3 with: fetch-depth: 0 # Добавлены ключи для converge # Меняют поведение по умолчанию # set -x добавлен для демонстрации отладки - name: Deploy env: WERF_ENV: stage run: | source "$(~/bin/trdl use werf ${{ env.WERF_VERSION }})" set -x werf converge -Z \ --env ${WERF_ENV} \ --namespace "${APP_NAME}-${WERF_ENV}" \ --release "${APP_NAME}-${WERF_ENV}"Анатомия пайплайна
Краткая структура пайплайна:
name: build and deploy # Произвольное название пайплайна on: [push] # Условие для запуска пайплайна — запушили коммит в репозиторий env: {} # Список переменных окружения, используемых в стадиях и шагах jobs: # Секция стадий build: # Стадия runs-on: werf # Лейбл раннера, на котором запустим код if: some conditions # Условия запуска стадии steps: [] # Шаги стадии deploy: needs: build-and-publish # Зависимость стадии от выполнения других стадий steps: []На верхнем уровне Gitea Actions-пайплайна задаются глобальные директивы, такие как название, триггеры запуска on: [] и переменные env: []. Триггами запуска пайплайна могут быть несколько событий, например создание issue, форк или удаление ветки. В моём случае это push изменений в репозиторий.
Директиву env: {} можно задать на разных уровнях, и переменные в разных стадиях могут переопределять друг друга. В данном случае задаются глобальные переменные, которые будут использованы на шагах сборки и развёртывания. Важно отметить, что при определении переменных доступа к container registry используются контексты vars и secrets.
env: WERF_REPO: ${{ vars.WERF_REPO }}/${{ gitea.repository }} WERF_IMAGE_REPO_USER: ${{ vars.WERF_IMAGE_REPO_USER }} WERF_IMAGES_REPO_TOKEN: ${{ secrets.WERF_IMAGES_REPO_TOKEN }}vars и secrets — это массив переменных, которые задаются в Gitea-репозитории, группе или организации. Переменные WERF_REPO, WERF_IMAGE_REPO_USER и WERF_IMAGES_REPO_TOKEN мы задавали в разделе настройки CI/CD.
Переменные вида WERF_ADD_ANNOTATION_* добавляются всем YAML-манифестам во время деплоя Helm-релиза в качестве аннотаций. По ним удобно определять
репозиторий, из которого был развёрнут ресурс, сам пайплайн и его номер. Можно перейти по ссылке и перевыкатить ресурс или отследить изменение в репозитории, которое привело к поломке.
Рассмотрим основные моменты стадий пайплайна.
Директива runs-on: werf с помощью лейбла задаёт раннер, на котором будет запущена стадия.
С помощью директивы if: определяется условие выполнения стадии. В пайплайне в директиве if: используется контекст массива переменных Gitea. if: gitea.ref != 'refs/heads/master' && gitea.ref != 'refs/heads/stage' && ! startsWith(gitea.ref, 'refs/tags/release-'). Данный контекст аналогичен контексту GitHub из GitHub Actions, он тоже поддерживается в Gitea Actions.
needs: — директива, которая задаёт зависимость одной стадии от другой, в данном случае прямая зависимость стадии выката от сборки.
Шаги steps — отдельные процессы внутри стадии. Шагами могут быть shell-команды, например run: echo "$JOB_CONTEXT" или werf build. Также можно использовать уже готовые шаги, встроенные из внешних репозиториев.
Уже готовый функционал используется в шаге Checkout code с помощью директивы uses:
- name: Checkout code uses: actions/checkout@v3 with: fetch-depth: 0На шаге Checkout code в стадию подгружается репозиторий, это нужно делать в каждой стадии пайплайна.
Рассмотрим подробнее шаги Build и Deploy.
- name: Build run: | source "$(~/bin/trdl use werf ${{ env.WERF_VERSION }})" werf cr login -u $WERF_IMAGE_REPO_USER -p ${{ secrets.WERF_IMAGES_REPO_TOKEN }} $WERF_REPO werf buildВ шаге Build с помощью | используется многострочный shell. Команда source активирует werf нужной версии, а с помощью переменной $WERF_VERSION мы можем управлять версиями. Это может быть удобно при обновлении версии или использовании нового функционала. Можно создать эту переменную на глобальном уровне организации, группы или репозитория.
werf cr login — логинимся к container registry, используя переменные и секреты. Можно обращаться к массивам vars или secrets при описании shell-команд.
werf build — запускается сборка Docker-образа на основе сценария werf.yaml.
Шаг Deploy stage:
deploy-stage: steps: - name: Deploy env: WERF_ENV: stage run: | source "$(~/bin/trdl use werf ${{ env.WERF_VERSION }})" set -x werf converge -Z \ --env ${WERF_ENV} \ --namespace "${APP_NAME}-${WERF_ENV}" \ --release "${APP_NAME}-${WERF_ENV}"На данном примере наглядно показано, как можно управлять релизами и деплоем. Что и куда будет развёртываться, определяется переменными окружения или ключами командной строки.
WERF_ENV — окружение.
WERF_NAMESPACE — пространство имён, в которое будет развёрнуто приложение, по умолчанию берётся значение project из werf.yaml + WERF_ENV (project_$WERF_ENV).
WERF_RELEASE — имя, которое будет присвоено Helm-release после развёртывания, по умолчанию аналогично WERF_NAMESPACE.
С помощью данных переменных или ключей --env, --namespace, --release мы управляем развёртыванием.
Развёртывания в dev- и prod-окружения производятся командой werf converge -Z без дополнительных ключей, так как отрабатывает поведение по умолчанию, передаём лишь WERF_ENV. Данная переменная в Helm-чарте будет доступна при обращении к встроенному массиву переменных werf {{ .Values.werf.env }}.
Коммитим изменения и отправляем их в репозиторий:
git add . git commit -am 'first deploy' git pushПроверяем, включен ли Gitea Actions: страница репозитория → Settings → Enable Repository Actions.
Теперь можно посмотреть на список пайплайнов и их стадии: страница репозитория → Actions:
Названием пайплайна будет message коммита, на котором пайплайн сработал. Давайте взглянем на стадии выполнения: здесь видно, что сборка и выкат прошли успешно.
Листинг выката:
werf выдаёт подробную информацию по своим процессам, что удобно при отладке.
В листинге выката видны название Helm-релиза и пространство имён, в которое развернулось приложение: Succeeded release "hello-world-dev" (namespace: "hello-world-dev"). В моём случае выкат был не из master-ветки, поэтому приложение было развёрнуто в dev-окружение. Соответственно, при выкате в prod-окружение Helm-release и пространство имён будут называться hello-world-prod.
Бонусом в стадию deploy можно добавить шаг werf plan — эта команда покажет план развёртывания и укажет, какие ресурсы будут изменены при следующем развертывании. А если что-то не так с Helm-чартом, то она выдаст ошибку и расскажет, в чём именно проблема.
- name: Deploy env: WERF_ENV: dev run: | source "$(~/bin/trdl use werf ${{ env.WERF_VERSION }})" werf planОчистка container registry
Со временем в container registry накапливаются Docker-образы, которые уже не нужны. Для их эффективной очистки создадим в репозитории пайплайн, который будет выполняться по расписанию и удалять устаревшие Docker-образы проекта.
Пайплайн cleanup.yaml желательно иметь в каждом репозитории, в котором для сборки и развёртывания используется werf.
Файл создаём в директории .gitea/workflows/:
# .gitea/workflows/cleanup.yaml --- name: Cleanup container registry run-name: Cleanup container registry on: schedule: - cron: '05 00 * * *' env: WERF_REPO: ${{ vars.WERF_REPO }}/${{ gitea.repository }} WERF_VERSION: '2 stable' jobs: cleanup: name: Cleanup runs-on: werf steps: - name: Checkout code uses: actions/checkout@v3 - name: Fetch all history for all tags and branches run: git fetch --prune --unshallow - name: Cleanup env: WERF_ENV: stage run: | set -x source "$(~/bin/trdl use werf ${WERF_VERSION:-'2 stable'} )" werf cleanup $WERF_REPOОсобенность пайплайна cleanup.yaml заключается в его триггере активации. Он срабатывает по расписанию и имеет cron-синтаксис:
on: schedule: - cron: '05 00 * * *'Запуск будет происходить каждый день в 00:05 согласно часовому поясу Gitea.
В финале наш репозиторий будет выглядеть так:
hello-world ├── app │ └── index.html ├── .gitea │ └── workflows │ ├── ci-cd.yaml │ └── cleanup.yaml ├── .helm │ ├── templates │ │ ├── deployment.yaml │ │ ├── ingress.yaml │ │ ├── nginx-config-cm.yaml │ │ └── service.yaml │ └── values.yaml ├── README.md └── werf.yamlЗаключение
Мы прошли долгий путь и проделали большую работу: настроили Gitea, провели его интеграцию с Deckhouse Kubernetes Platform, настроили автоматизацию CI/CD, научились писать пайплайны Gitea Actions и, наконец, познакомились с отличным лучшим инструментом CI/CD — werf.
Поздравляю, вы великолепны!
P. S.
Читайте также в нашем блоге:
ссылка на оригинал статьи https://habr.com/ru/articles/857100/
Добавить комментарий