⚡️ Делимся новостью наших друзей
Получите статус сертифицированного инженера данных

Скоро в программе сертификации Yandex Cloud появятся два новых экзамена для инженеров данных. Пока они не запущены официально, мы проводим серию пилотных тестирований — чтобы собрать статистику и доработать экзамены. Те, кто успешно сдадут экзамен, получат статус сертифицированных специалистов в числе первых.

Что за экзамены?

1️⃣ Yandex Cloud Certified Data Engineer — базовый уровень, подтверждает навыки работы с сервисами платформы данных.

2️⃣ Yandex Cloud Certified Lakehouse Data Engineer — продвинутый уровень, проверяет компетенции по построению Lakehouse-платформ.

Пилоты проводятся до 4 июля. Участие бесплатное, но количество мест ограничено.
Заполняйте эту форму, чтобы зарегистрироваться. Детали на этой странице.

Как спрятать секреты, внедряя HashiCorp Vault

Выкатываешь релиз, открываешь логи - а там пароль от продовой базы. Или секреты лежат в репозитории, закоммиченные в application.yml. Переменные окружения в CI/CD создают ложное ощущение защищённости: GitLab маскирует их в интерфейсе, но при компрометации раннера все переменные видны в открытом виде.

Статические секреты создают постоянные риски для безопасности. Пароль от базы данных часто не меняется годами, потому что «если поменяем, всё упадёт». И он один на все окружения.

HashiCorp Vault решает эту проблему на уровне архитектуры, полностью исключая человеческий фактор.

Шаг 1. Интеграция с Kubernetes через Agent Injector

Этот механизм автоматически прокидывает секреты в поды. Переписывать код приложения под чтение из файлов не нужно - достаточно обернуть команду запуска в контейнере, чтобы она считывала примонтированный Vault файл перед стартом.

Добавляем аннотации к поду, и Vault монтирует секреты в его файловую систему:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-example
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "db-app"
        vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/db-app"
        vault.hashicorp.com/agent-inject-template-db-creds: |
          {{- with secret "database/creds/db-app" -}}
          export DB_USER="{{ .Data.username }}"
          export DB_PASSWORD="{{ .Data.password }}"
          {{- end }}
    spec:
      serviceAccountName: app-example
      containers:
        - name: app
          image: app:1.0.0
          command: ["/bin/sh", "-c", ". /vault/secrets/db-creds && ./main"]

⚠️ Важно: Аннотации размещаются строго в spec.template.metadata, а не на самом Deployment. Иначе инжектор просто проигнорирует под.

Медленный старт контейнера
Оптимизация образов Docker и прогон через CI

Сборка пайплайна длится 10 минут, поды стартуют 30 секунд. Образы занимают под гигабайт, каждый новый релиз тянет все зависимости заново. При масштабировании приложение замедляется из-за долгого подъёма контейнеров.

Это следствие неоптимальной сборки образов. Многие используют один Dockerfile, который устанавливает все пакеты, копирует весь исходный код и собирает приложение в одном слое. В результате образ разрастается, слои не кэшируются, каждый запуск требует загрузки гигабайтов из registry.

В CI проблема усугубляется: без кэширования слоёв каждый пайплайн скачивает базовые образы и зависимости заново. Это увеличивает время выполнения и расходует ресурсы.

🛠Решение
Многоступенчатая сборка (multi-stage build) и правильная стратегия кэширования. Разделяем сборку и исполнение: в первой стадии компилируем приложение и собираем артефакты, во второй - копируем только то, что необходимо для работы.

Классический Dockerfile для Go-приложения:

FROM golang:1.26 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# Флаги -s -w отсекают отладочную информацию, уменьшая бинарник
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o myapp ./cmd/server

# Финальная стадия — distroless содержит ca-certificates и tzdata,
# но не содержит shell и пакетного менеджера
FROM gcr.io/distroless/static:nonroot
COPY --from=builder /app/myapp /myapp
ENTRYPOINT ["/myapp"]

В финальный образ попадает только скомпилированный бинарник и минимальный набор системных библиотек. Размер сокращается с ~800 МБ до ~15 МБ. Под стартует за секунды вместо десятков секунд.

Для интерпретируемых языков (Python, Node.js) принцип аналогичен. Например, для Python создаём виртуальное окружение на этапе сборки, где есть компиляторы для пакетов с C-расширениями, а в финальный образ переносим только готовое окружение без компиляторов и лишнего мусора:

# Стадия сборки. здесь есть компиляторы для пакетов с C-расширениями
FROM python:3.13-slim AS builder
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends build-essential \
    && rm -rf /var/lib/apt/lists/*
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Финальная стадия. чистый slim без компиляторов
FROM python:3.13-slim
WORKDIR /app
COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY app.py .
CMD ["python", "app.py"]

Теперь настраиваем кэширование в GitLab CI, чтобы не пересобирать зависимости при каждом коммите. Воспользуемся современным движком docker buildx, который умеет работать с кэшем напрямую в удаленном реестре (registry) без лишних движений вроде docker pull и docker tag:

stage: build
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    DOCKER_CACHE: $CI_REGISTRY_IMAGE:cache
  script:
    # Логинимся в registry. без этого не пройдёт ни --push, ни --cache-to
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    # Инициализируем buildx-билдер с драйвером docker-container (умеет писать кэш в registry)
    - docker buildx create --use
    # Собираем образ, читая удалённый кэш и сохраняя новые слои в него же
    - docker buildx build
        --cache-from type=registry,ref=$DOCKER_CACHE
        --cache-to type=registry,ref=$DOCKER_CACHE,mode=max
        --tag $DOCKER_IMAGE
        --tag $CI_REGISTRY_IMAGE:latest
        --push .

Docker проверяет манифест удаленного кэша. Если в Dockerfile не изменились строки, влияющие на слой (например, requirements.txt или `go.mod`), тяжелые этапы установки зависимостей просто пропустятся.

Когда Argo CD не синхронизирует состояние

Развернул приложение через Argo CD, всё зелёное, синхронизация прошла успешно. Через час заходишь - висит статус OutOfSync. Непонятно, кто и что изменил. Вроде бы репозиторий не трогали, но кластер думает иначе.

Или другая ситуация: разработчик запушил изменения, Argo CD их подхватил, но деплой завис, потому что какой-то ресурс уже существует и его нельзя обновить. А на следующий день выясняется, что кто-то из коллег выполнил kubectl apply вручную, и теперь состояние кластера расходится с Git-репозиторием.

🤔 Главная проблема - непонимание источника истины. В GitOps источник истины - это Git-репозиторий. Любое изменение в кластере, сделанное в обход Git, создаёт рассинхрон. Argo CD это видит, но не знает, что с этим делать, если политики не настроены правильно.

🛠Решение - корректная настройка политик синхронизации

Для каждого приложения в Argo CD можно определить, как именно оно должно синхронизироваться с репозиторием. Вот пример конфигурации с тремя ключевыми параметрами:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: false        # Не удалять ресурсы, которых нет в Git
      selfHeal: true      # Автоматически возвращать состояние из Git при дрифте
    syncOptions:
    - CreateNamespace=true

🔹 `selfHeal: true` - самый важный параметр для борьбы с «ручными» правками. Он автоматически возвращает кластер к состоянию, описанному в Git, если кто-то изменил ресурс через kubectl edit или apply. Без этого параметра любое ручное вмешательство оставит приложение в статусе OutOfSync.
🔹 `prune: false` - осторожная настройка на этапе миграции. Мы запрещаем Argo CD удалять из кластера ресурсы, которые не описаны в Git. Это защита от случайной потери данных. Включать prune: true (что является стандартом для честного GitOps) стоит тогда, когда вы полностью уверены в чистоте своих манифестов.
🔹 `- CreateNamespace=true` - опция в syncOptions, которая указывает Argo CD автоматически создать целевой namespace в кластере, если его еще не существует. Избавляет от лишних ручных шагов.

😎Масштабируем подход: паттерн App-of-Apps
Для больших проектов используется паттерн App-of-Apps (приложение приложений). Это подход, при котором одно главное («рутовое») приложение Argo CD управляет набором других дочерних приложений.

Важно: Корневое приложение должно разворачивать дочерние манифесты строго в тот namespace, где работает сам контроллер Argo CD (обычно `argocd`), иначе система их не распознает.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/infra.git
    targetRevision: HEAD
    path: apps/
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd  # Обязательно указываем namespace Argo CD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Каждое дочернее приложение в директории apps/ описывается собственным YAML-файлом и может иметь свои уникальные политики. Например, для баз данных можно оставить prune: false, а для легковесного фронтенда - prune: true.

Дополнительно внутри дочерних ресурсов можно использовать Sync Waves (волны синхронизации), чтобы управлять очередью развертывания. Например, сначала гарантированно поднять базу данных, а только потом - зависимый бэкенд:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Ресурсы с меньшим значением волны (включая отрицательные числа) запускаются и проверяются на готовность раньше остальных.

Практический план внедрения
1. Соберите манифесты: определите все ресурсы, которые должны управляться через Argo CD, и перенесите их в Git.
2. Настройте политики безопасности: начните с selfHeal: true и prune: false для продакшена, чтобы защитить данные. На стейдже сразу включайте prune: true.
3. Подключите уведомления: настройте Argo CD Notifications в Slack или Telegram, чтобы мгновенно узнавать о сбоях синхронизации.
4. Внедрите App-of-Apps: централизуйте управление всеми сервисами кластера через один корневой репозиторий.
5. Оптимизируйте Webhooks: настройте webhook от GitHub/GitLab к Argo CD, чтобы синхронизация начиналась мгновенно при пуше, не дожидаясь стандартного 3-минутного опроса (polling).
6. Договоритесь на берегу: обучите команду главному правилу GitOps — никогда не менять ресурсы в кластере напрямую. Только через git commit и git push.

Если нарушить этот принцип, Argo CD либо молча перезапишет ваши изменения (при `selfHeal`), либо оставит кластер в перманентном рассинхроне. Единственный правильный подход: commit в Git, а не apply в консоли.

Чтобы освоить GitOps на практике, включая работу с Helm-чартами, настройку мультикластерного деплоя и управление конфигурациями, 🔥открывай демодоступы бесплатно🔥 и начинай погружаться в технологию:

* Argo CD - установка, настройка, App-of-Apps, интеграция с Helm
* Git - продвинутая работа с репозиториями, ветвление, стратегии слияния
* Helm - создание чартов, управление зависимостями, шаблонизация