Как обеспечить постоянное хранилище для Docker-контейнеров

Быстрые ссылки

• Use an External Database or Object Store

• Simple Solution: Mount a Drive to a Container

• For Managed Deployments, Use a Shared File System (AWS EFS)

Docker — это система контейнеризации, предназначенная для запуска приложений в изолированной среде на любом хосте. Контейнеры по задумке должны быть максимально статeless, но если необходимо хранить данные на диске, для этого применяют тома (volumes) и bind-монты.

Используйте внешнюю базу данных или объектное хранилище

Это тот способ, который порекомендует большинство инженеров. Хранить состояние в виде файлов на диске контейнера не соответствует архитектурной модели Docker. Хотя технически это возможно, стоит задать вопрос: действительно ли вам нужно хранить данные в локальном файле?

Пример: веб-приложение в Docker, которому нужна база данных. Как правило, нет смысла запускать MySQL внутри контейнера приложения — лучше использовать управляемый сервис (RDS) или отдельный EC2-инстанс с базой, и подключать к нему контейнер напрямую. Тогда контейнер остаётся статeless: его можно остановить, пересоздать или заменить без потери данных. Для безопасного доступа используйте IAM-роли и приватные сети (VPC).

Если требуется хранить файлы пользователей (фото, видео), вместо локального диска лучше использовать объектное хранилище, например Amazon S3. S3 обычно дешевле и масштабируется лучше, чем блочные тома EBS или файловые системы EFS. При загрузке прямо в S3 вы снижаете нагрузку на контейнеры, избавляетесь от проблем синхронизации между узлами и можете запускать последующую обработку (Lambda, очереди, фоновые воркеры).

Важно: переход на внешние сервисы обычно повышает надёжность и масштабируемость. Если стоимость хранения или задержки — критичны, сопоставьте TCO и требования к I/O.

Простое решение: примонтировать диск к контейнеру

Docker предоставляет две основные модели для сохранения данных: volume mounts и bind mounts. Bind mount — это привязка конкретного пути на хосте к пути внутри контейнера. Bind-монты могут быть только для чтения или чтения/записи — файлы, записанные контейнером, будут сохраняться на диске хоста.

Лучше создавать управляемые Docker тома, а не привязываться к конкретным путям хоста. Тома удобнее бэкапить, переносить и шарить между инстансами.

Команды примера:

Создать том с CLI:

docker volume create nginx-config

Запустить контейнер и примонтировать том в /etc/nginx:

docker run -d --name devtest --mount source=nginx-config,target=/etc/nginx nginx:latest

Если выполнить docker inspect , том будет виден в секции Mounts.

Пример для Docker Compose: определите volumes в сервисе, а также перечислите тома в корне файла:

version: "3.0"
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - nginx-config:/etc/nginx/
volumes:
  nginx-config:

Compose сам создаст том. Если нужно использовать внешний том, укажите external: true:

volumes:
  cms-content:
    external: true

Если вы предпочитаете bind-монты, вместо имени тома указывайте путь хоста:

version: "3.0"
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - /docker/nginx-config/:/etc/nginx/

Документация Docker содержит подробные сценарии использования томов, если требуется более тонкая настройка.

Важно: тома и bind-монты зависят от диска конкретного хоста. В управляемых кластерах (ECS, Kubernetes) контейнер при перезапуске может оказаться на другом узле, и локальные тома не обеспечат постоянство данных.

Для управляемых развёртываний используйте общую файловую систему (AWS EFS)

В AWS ECS обычные bind- и docker-тома не решат проблему перезапуска контейнеров на разных хостах. Решение — сетевые файловые системы, которые монтируются на несколько инстансов одновременно. AWS Elastic File System (EFS) — подходящий вариант для этого сценария.

EFS — это сетевой (NFS) файловый сервис, доступный нескольким EC2-инстансам и контейнерам. Вы можете хранить статический контент, конфигурации или общие ресурсы и монтировать их к любому узлу.

Как подготовить EFS и подключить к ECS — шаги:

1. Создайте файловую систему EFS через AWS Console и запишите её ID (например, fs-12345678).
2. На любом EC2 можно вручную смонтировать EFS для проверки и правки файлов. Установите утилиты:

sudo yum install -y amazon-efs-utils

3. Смонтируйте, подставив ID:

sudo mount -t efs fs-12345678:/ /mnt/efs

Убедитесь, что установлены nfs-utils (NFS-клиент) для корректной работы.

4. В ECS создайте новую Task Definition. В интерфейсе найдите опцию “Configure Via JSON” и замените пустой ключ “volumes” на JSON с настройками сети/драйвера. Пример конфигурации тома (поменяйте адрес EFS на ваш):

"volumes": [
  {
    "name": "efs-demo",
    "host": null,
    "dockerVolumeConfiguration": {
      "autoprovision": true,
      "labels": null,
      "scope": "shared",
      "driver": "local",
      "driverOpts": {
        "type": "nfs",
        "device": ":/",
        "o": "addr=fs-XXXXXX.efs.us-east-1.amazonaws.com,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport"
      }
    }
  }
],
"family": "nginx"

Замените fs-XXXXXX.efs.us-east-1.amazonaws.com на адрес вашей EFS-файловой системы. В консоли вы увидите новый том:

После создания тома в определении задачи добавьте его как точку монтирования в контейнере: откройте редактирование контейнера и в разделе Storage And Logging выберите созданный том и укажите путь внутри контейнера.

Сохраните Task Definition и запустите кластер — контейнеры получат доступ к общей файловой системе.

Когда этот подход не подходит

• Если вы строите полностью распределённое приложение с высокой нагрузкой на чтение/запись, NFS-подход может стать узким местом. Для высоконагруженных хранилищ выбирайте специализированные СУБД или объектные хранилища.
• Для критичных к задержке операций блочное хранилище (EBS) или локальные NVMe-инстансы иногда дают лучшие показатели IOPS.
• Если приложение требует транзакционной целостности на файловой системе (ACID на уровне файлов), лучше использовать СУБД.

Альтернативные подходы

• Объектное хранилище (S3, MinIO) для больших бинарных объектов и мультимедиа.
• Управляемые базы данных (RDS, Aurora) для структурированных данных и транзакций.
• Сервисные очереди и DAG-процессы для отложенной обработки большого объёма задач.
• Локальные SSD/NVMe на вычислительных узлах для временных кешей и высокопроизводительных задач (размещение данных не критично).

Ментальные модели и эвристики

• «Стейт вне контейнера»: проектируйте контейнеры так, чтобы они могли быть безопасно пересозданы.
• «Объекты — в объектное хранилище, структура — в базу данных»: фото/видео/артефакты — S3; записи и связи — СУБД.
• «Shared FS = общий ресурс»: если несколько инстансов читают/пишут одни и те же файлы, используйте NFS-совместимую FS и учитывайте блокировки и конкуренцию.

Практическое руководство: быстрый SOP для EFS + ECS

1. Создайте EFS через AWS Console, выберите необходимые зоны и политики.
2. Создайте Security Group, разрешающую NFS (порт 2049) только между вашими ECS/EC2 инстансами.
3. На этапе Task Definition добавьте volume с драйвером local и опцией type=nfs, указав addr=ваш-сервер. Подтвердите family.
4. В контейнере добавьте точку монтирования и путь (например, /var/www/content).
5. Протестируйте монтирование на отдельном EC2 (amazon-efs-utils), проверьте права и UID/GID.
6. Настройте бэкапы (вне EFS — синхронизация в S3 или периодические снимки) и мониторинг (CloudWatch).

Чек-лист безопасности

• Ограничьте доступ к EFS через Security Groups и VPC — не открывайте NFS в публичный Интернет.
• Используйте IAM и роли для контейнеров, чтобы ограничить доступ к S3 и другим сервисам.
• Настройте права UNIX (UID/GID) внутри контейнеров, чтобы избежать непреднамеренного доступа.
• Включите шифрование данных в покое и при передаче, если требуется соответствие требованиям.

Критерии приёмки

• Контейнеры при перезапуске сохраняют доступ к файлам и видят актуальные данные.
• Производительность I/O соответствует требованиям SLA приложения.
• Доступ к файловой системе безопасно ограничен сетевыми настройками.
• Бэкап и восстановление протестированы и документированы.

Короткий глоссарий

• Bind mount — привязка пути хоста к пути контейнера.
• Volume — управляемый Docker том, абстрагированный от конкретного пути хоста.
• EFS — Elastic File System, сетевое файловое хранилище AWS (NFS).
• S3 — объектное хранилище AWS для файлов и артефактов.

Примеры, когда это проваливается

• Размещение базы данных в контейнере без внешнего бэкапа: при сбое узла данные теряются.
• Использование EFS без учёта блокировок: гонки при одновременной записи в один и тот же файл.
• Прямая запись больших объёмов в локальный диск контейнера на масштабируемой платформе: никто не гарантирует сохранность при масштабировании.

Рекомендации по миграции

• Экспортируйте данные из локальных файлов в S3 (например, с помощником aws cli или Syncthing), обновите приложение на использование S3 API.
• Для баз данных используйте дампы и инструменты репликации при миграции на RDS.
• Тестируйте рабочие процессы в staging-кластере с той же конфигурацией томов и прав доступа.

Заключение

Выбор способа хранения данных для Docker зависит от требований к доступности, задержкам, масштабу и стоимости. Для устойчивых и масштабируемых приложений предпочтительнее внешние сервисы (базы данных и объектные хранилища). Для простых задач, тестирования и локальных развёртываний — тома и bind-монты. Для управляемых кластеров (ECS) используйте EFS или другие сетевые файловые системы и следуйте чек-листам безопасности. Планируйте бэкапы и мониторинг заранее.

Важно: всегда сопоставляйте требования приложения (IOPS, задержка, консистентность) с характеристиками выбранного хранилища.

Резюме

• Проектируйте контейнеры как stateless. Храните состояние во внешних сервисах.
• Для файлов используйте S3; для транзакционных данных — управляемые СУБД.
• Локальные тома удобны для тестов; для продакшена на ECS применяйте EFS.
• Настройте сетевую безопасность, бэкапы и мониторинг.