Как правильно настроить изолированные окружения (development, staging, production)?

«Как правильно настроить изолированные окружения (development, staging, production)?» — вопрос из категории DevOps, который задают на 24% собеседований PHP Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Цель — иметь полностью воспроизводимые и изолированные окружения. Мы добиваемся этого через комбинацию инструментов:

  1. Контейнеризация (Docker): Определяем все зависимости (ОС, runtime, библиотеки) в Dockerfile. Это гарантирует идентичность среды от разработчика до продакшена.
    FROM node:18-alpine
    WORKDIR /app
    COPY package*.json ./
    RUN npm ci --only=production
    COPY . .
    CMD ["node", "server.js"]
  2. Управление конфигурацией: Конфигурация (URL БД, ключи API) хранится вне кода и подается через переменные окружения. Для локальной разработки используем .env файлы (добавленные в .gitignore), а на серверах — секреты в CI/CD (GitLab CI Variables, GitHub Secrets) или оркестраторе (Kubernetes Secrets).
    # .env.development (пример)
    DB_HOST=localhost
    API_KEY=dev_key
    LOG_LEVEL=debug
  3. Orchestration и деплой: Используем docker-compose для локального поднятия стека (приложение + БД + кэш), а для staging/prod — оркестратор вроде Kubernetes с Helm-чартами или простые docker-compose файлы, управляемые через CI/CD.
    # docker-compose.override.yml для development
    version: '3.8'
    services:
      app:
        environment:
          - NODE_ENV=development
        volumes:
          - .:/app # монтируем код для hot-reload
        command: npm run dev
  4. Инфраструктура как код (IaC): Сами сервера и их настройки описываются в коде (Terraform, Ansible), что позволяет создавать идентичные staging и production среды.

Ключевой принцип: Разница между окружениями должна быть минимальна и сводиться только к конфигурации и масштабированию. Бинарник (образ Docker) один и тот же для всех сред.