Зачем нужна контейнеризация в DevOps?

Контейнеризация с Docker — это фундаментальная технология в моей работе, которая решает ключевую проблему: «у меня на локальной машине работает, а на продакшене — нет».

Как я использую Docker для построения DevOps-процессов:

• Унификация сред разработки: Я предоставляю команде Dockerfile и docker-compose.yml. Разработчик запускает docker-compose up, и получает локальное окружение (приложение, БД, кэш), идентичное продакшену, без установки в систему Postgres, Redis и т.д.

• Основа для CI/CD: В пайплайне GitLab CI каждая стадия (lint, test, build) выполняется в изолированном контейнере. Это гарантирует, что тесты проходят в чистом и воспроизводимом окружении.

  # .gitlab-ci.yml
  test:
    image: python:3.9-slim
    script:
      - pip install -r requirements.txt
      - pytest

• Единица развертывания в Kubernetes: Собранный Docker-образ (image) — это артефакт, который продвигается по всем стадиям (dev -> staging -> prod). В Kubernetes я разворачиваю не «пакет приложения», а именно контейнер, ссылаясь на тег образа в реестре (например, myapp:git-abc123).

• Изоляция и безопасность: Контейнеры позволяют изолировать сервисы друг от друга на уровне процессов и файловой системы. В моей практике это помогает ограничить последствия взлома одного сервиса и упрощает соблюдение принципа минимальных привилегий.

Практический пример: Для отладки проблем на продакшене я использую kubectl exec для запуска отладочных утилит внутри контейнера, не затрагивая хост-систему и другие сервисы. Контейнер предоставляет самодостаточную среду для диагностики.

# Запуск оболочки внутри контейнера для проверки логов или конфигов
kubectl exec -it <pod-name> -- /bin/sh
# Проверка, какие файлы лежат рядом с приложением
ls -la /app/