На чем собирал контейнеры

Практика сборки контейнеров: от Docker до облачных сервисов

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

Основной инструмент: Docker и Dockerfile

Без сомнения, основным и самым распространенным инструментом для сборки образов был и остается Docker Engine вместе с языком определения сборки — Dockerfile. Это фундамент, с которого начиналось большинство проектов.

# Типичный многоступенчатый (multi-stage) Dockerfile для Python-приложения
FROM python:3.11-slim as builder

WORKDIR /app
COPY requirements.txt .
RUN pip install --user --no-wash-dir -r requirements.txt

FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .

ENV PATH=/root/.local/bin:$PATH
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app.wsgi"]

• Преимущества Docker: Стандартизация (Dockerfile — это де-факто отраслевой стандарт), простота освоения, огромное комьюнити, кэширование слоев для ускорения сборок, поддержка multi-stage builds для оптимизации итогового образа.
• Использование: Локальная разработка, CI/CD-пайплайны (где агент имеет Docker Daemon), сборка образов для docker-compose окружений.

Для CI/CD и бездемоновых окружений: Buildah, Kaniko, BuildKit

В средах, где запуск Docker Daemon невозможен или нежелателен (например, в изолированных средах CI/CD, внутри контейнеров, в Kubernetes), я переходил на другие инструменты.

• Buildah: Отличный инструмент от Red Hat для сборки OCI-совместимых образов без необходимости в демоне. Позволяет тонко контролировать каждый слой.

  # Пример командной сборки с Buildah
  buildah from ubuntu:22.04
  buildah run working-container -- apt-get update && apt-get install -y nginx
  buildah copy working-container ./index.html /var/www/html/
  buildah config --cmd ["nginx", "-g", "daemon off;"] working-container
  buildah commit working-container my-nginx-app
  

• Kaniko: Инструмент от Google, созданный специально для сборки образов внутри контейнера или Kubernetes Pod. Не требует привилегий и полностью безопасен для запуска в Kubernetes.

  # Пример задачи (Task) для Kaniko в Tekton CI/CD
  apiVersion: tekton.dev/v1beta1
  kind: Task
  metadata:
    name: build-kaniko
  spec:
    steps:
      - name: build-image
        image: gcr.io/kaniko-project/executor:latest
        args: [
          "--dockerfile=Dockerfile",
          "--context=dir://<path-to-source>",
          "--destination=gcr.io/my-project/app:latest"
        ]
  

• BuildKit: Продвинутый бэкенд для сборки, интегрированный в современные версии Docker. Использовал его для получения лучшей производительности, параллельного выполнения стадий и повышения безопасности (--secret флаг).

Облачные и платформенные сервисы

В облачных инфраструктурах я активно использовал встроенные managed-сервисы, которые интегрируются с остальными компонентами платформы.

• Google Cloud Build: Полностью управляемый сервис, где сборка описывается в cloudbuild.yaml. Отлично интегрируется с Cloud Source Repositories, GitHub и Artifact Registry.

  # cloudbuild.yaml
  steps:
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA', '.']
    - name: 'gcr.io/cloud-builders/docker'
      args: ['push', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']
  images: ['gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']
  

• GitLab CI/CD Container Registry & Build: Встроенная в GitLab возможность сборки образов с использованием собственного раннера (на котором работает Docker) или с помощью docker build команды в .gitlab-ci.yml.

  build:
    stage: build
    script:
      - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
      - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  

• GitHub Actions: Для проектов на GitHub использовал Actions с официальными action для сборки и пуша (docker/build-push-action).

  - name: Build and push
    uses: docker/build-push-action@v4
    with:
      context: .
      push: true
      tags: user/app:latest
  

• AWS CodeBuild & ECR: В экосистеме AWS использовал связку CodeBuild (для выполнения инструкций из buildspec.yml) и Amazon ECR (для хранения образов).

Оптимизация и практики

Независимо от инструмента, я всегда следовал ключевым практикам:

• Минимизация размера образа: Использование alpine или distroless базовых образов, многоступенчатых сборок, очистка кэша пакетных менеджеров в одном RUN-слое.
• Безопасность: Сканирование образов на уязвимости (Trivy, Grype, Snyk) как в пайплайне, так и в рантайме. Использование не-root пользователей.
• Идемпотентность и воспроизводимость: Фиксация версий в базовом образе (python:3.11-slim, а не python:slim) и в устанавливаемых пакетах.
• Кэширование в CI/CD: Настройка кэширования слоев образа между сборками для резкого ускорения пайплайнов.

Выбор инструмента всегда был контекстно-зависимым: для локальной разработки — docker build, для безопасного CI в Kubernetes — Kaniko, в облаке Google — Cloud Build, а для сложных, требовательных к производительности сборок — включение BuildKit. Главное — понимать принципы работы контейнеров и OCI-образов, тогда переход между инструментами сборки становится тривиальной задачей.