werf как альтернатива Kaniko для сборки образов в Kubernetes в вашей системе CI

Kaniko больше не поддерживается, поэтому мы предлагаем обратить внимание на werf как современную альтернативу. Разбираем, чем werf отличается от других инструментов, почему он может быть удобнее для CI/CD в Kubernetes и как быстро начать его использовать в своих пайплайнах. Также рассмотрим примеры интеграции werf с популярными CI-системами.

Что такое Kaniko и зачем он был нужен

Kaniko — это инструмент от Google для сборки OCI-совместимых образов контейнеров внутри контейнеров без необходимости root-доступа и запуска Docker-демона. Он получил широкое распространение как решение для CI-сборок в Kubernetes, особенно в таких платформах, как GitHub Actions и GitLab CI.

Преимущества Kaniko

Безопасность: не требует привилегий (rootless). Kaniko может запускаться в обычном (непривилегированном) контейнере, без необходимости доступа к root. Это значительно повышает безопасность, так как сборка образа происходит изолированно и не требует доступа к системным ресурсам.

Например, в Kubernetes можно создать под с Kaniko, где контейнер работает с обычным пользователем без securityContext.runAsRoot: true. Это значит, что злоумышленник не сможет получить root-доступ через этот контейнер.

			apiVersion: v1
kind: Pod
metadata:
  name: kaniko-pod
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=Dockerfile", "--context=git://github.com/my/repo.git", "--destination=gcr.io/my-project/my-image"]
    securityContext:
      runAsUser: 1000  # Непривилегированный пользователь.
  restartPolicy: Never
		

Простота: легко запускать как задачу (Job) или контейнер в Kubernetes. Kaniko легко интегрируется в Kubernetes — он просто запускается как обычный контейнер, который выполняет сборку образа и загружает его в реестр. Не нужно устанавливать и настраивать Docker-демон.

Так выглядит запуск сборки в GitLab CI/CD с использованием Kaniko:

			build:
  image:
    name: gcr.io/kaniko-project/executor:latest
    entrypoint: [""]
  script:
    - /kaniko/executor --dockerfile Dockerfile --context $CI_PROJECT_DIR --destination registry.gitlab.com/my-group/my-image:latest
		

Совместимость: поддержка стандартных Dockerfile. Kaniko понимает обычные Dockerfile и может собрать образ из них, не требуя переписывать или адаптировать существующие инструкции.

Например, если есть обычный Dockerfile…

			FROM python:3.10
COPY . /app
RUN pip install -r /app/requirements.txt
CMD ["python", "/app/app.py"]
		

… то можно просто указать Kaniko использовать этот Dockerfile, и он построит такой же образ.

Конец поддержки Kaniko и альтернативы

В июне 2025 года публичный репозиторий Kaniko перевели в архив — теперь он доступен только для чтения, что фактически означает прекращение его активной поддержки и развития со стороны разработчиков.

Несмотря на то, что вскоре начали появляться форки (самый заметный — это chainguard-dev/kaniko), они ориентированы на режим поддержки (фикс багов и безопасность), а не на дальнейшее развитие инструмента. Поэтому многие пользователи ищут замену Kaniko — если и не сегодня, то в обозримом будущем.

Наиболее популярные в сообществе альтернативы:

• BuildKit от Docker/Moby (особенно в связке с docker buildx);
• Buildah от Red Hat из экосистемы Podman. Стал Sandbox-проектом CNCF в январе 2025 года.

Почему стоит рассмотреть werf и как начать

Помимо низкоуровневых инструментов, таких как Kaniko, BuildKit и Buildah, существует также высокоуровневое решение — werf. Это production-ready-инструмент, предназначенный не только для сборки, но и для доставки контейнеров в Kubernetes. Утилита позволяет использовать любую предпочтительную CI-систему. Является Sandbox-проектом в CNCF.

Что предлагает werf:

• Native Kubernetes-ориентированная архитектура, то есть можно легко интегрировать сборку, деплой и управление приложениями прямо в Kubernetes-кластере.
• Поддержка Buildah или BuildKit в качестве backend для сборки, причём Buildah полностью интегрирован в werf и может работать в rootless-режиме. Это позволяет собирать образы без необходимости запуска процессов с правами root.
• Удобная интеграция с другими инструментами доставки софта в Kubernetes (включая GitLab, GitHub Actions и Argo CD). Например, связка из werf и Argo CD позволяет полностью интегрировать между собой любую CI/CD-систему и Argo CD. При этом от каждого из инструментов берутся свои возможности и особенности.

• Автоматическое кэширование сборки и тегирование на основе содержимого, как результат — инкрементальные сборки и оптимальное использование container registry.
• Надёжное развёртывание и управление релизами в Kubernetes. werf расширяет возможности Helm, используя встроенный инструмент Nelm, который обеспечивает точное отслеживание состояния ресурсов, умное ожидание их готовности, мгновенное завершение проблемных релизов и применяет более надёжный метод обновления ресурсов — Server-Side Apply. При этом сохраняется полная совместимость с Helm-чартами и релизами.
• Дистрибуция релизных артефактов. Утилита упаковывает Helm-чарт и связанные с ним образы контейнеров в единый бандл, который затем можно опубликовать в OCI-совместимый реестр. Кроме того, бандлы можно копировать между реестрами, выгружать на USB-флеш-накопитель и развёртывать в Kubernetes с помощью werf или других решений, которые поддерживают работу с OCI-чартами (Helm, Flux, ArgoCD).
• Умная очистка container registry, которая автоматически удаляет неактуальные теги образов с учётом их использования в Kubernetes и истории Git, что позволяет безопасно освобождать место и контролировать рост хранилища без риска удаления нужных образов.

Примеры использования werf

Как будет выглядеть werf в CI/CD-системах? В общем случае достаточно добавить в свой пайплайн CLI-команду werf converge, которая собирает образ, пушит его в registry и выкатывает в Kubernetes.

Листинг с конфигурацией .github/workflows/converge.yml для использования werf в GitHub Actions может выглядеть так:

			name: prod
on:
  push:
    branches:
      - main

jobs:
  prod:
    name: prody
    runs-on: arc-runner-set
    container:
      image: ghcr.io/werf/werf:2-stable-ubuntu
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - run: |
          . "$(werf ci-env github --as-file)"
          werf converge
        env:
          WERF_ENV: prod
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          WERF_KUBECONFIG_BASE64: ${{ secrets.KUBECONFIG_BASE64 }}

		

А использовать werf в GitLab CI/CD можно так:

			stages:
  - prod

default:
  image:
    name: "registry.werf.io/werf/werf:2-stable"
    pull_policy: always
  before_script:
    - source "$(werf ci-env gitlab --as-file)"
  tags: ["<GitLab Runner tag>"]

prod:
  stage: prod
  script:
    - werf converge
  environment:
    name: prod
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "schedule"
      when: manual
		

Более подробные инструкции для доставки приложений в Kubernetes с werf можно найти в официальном руководстве по началу работы проекта.

В документации можно найти интерактивные сценарии, пояснения терминов, готовые CI-конфигурации и Helm-интеграцию. Всё это будет полезно и новичкам, и опытным DevOps-инженерам.

Вместо заключения

Поскольку Kaniko больше не развивается, многие могут задуматься о миграции на другой инструмент. Помимо очевидных вариантов вроде BuildKit и Buildah, рекомендуем попробовать werf. Он подойдет, если вам нужен CI-first-подход с нативной Kubernetes-интеграцией и интересны дополнительные фичи «из коробки» для CI/CD, например дистрибуция релизных артефактов и умная очистка container registry.

Чтобы попробовать werf, переходите на официальный сайт утилиты и изучайте подробную документацию с пошаговыми руководствами и примерами.

Реклама. Рекламодатель: АО «Флант». ИНН 772366143. erid: 2W5zFGNuWcp.