Добавить том в запущенный Docker‑контейнер

Схема: Docker контейнер и том на хосте

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

Добавление тома к запущенному Docker контейнеру
Клонирование из существующего контейнера
Грубый хак (правка config.v2.json)

Важно: всегда делайте резервную копию данных перед изменениями томов и тестируйте изменения на стенде.

Добавление тома к запущенному контейнеру

Короткий ответ: Docker не поддерживает добавление томов к уже запущенному контейнеру через стандартные параметры запуска. Конфигурация томов задаётся при старте контейнера. Чтобы добавить том, обычно выполняют перезапуск контейнера с обновлённой командой запуска или через Docker Compose.

Почему перезапуск — хороший подход:

Перезапуск даёт предсказуемое состояние контейнера.
Большинство обновлений кода требуют перезапуска сервиса.
Версионирование запуска и инфраструктуры проще отслеживать через Git и docker-compose.yml.
Для критичных сервисов используйте многоподовое развертывание и rolling‑update, чтобы избежать простоев.

Простой пример — остановка контейнера и запуск с новым томом:

docker stop my_container

Создайте том, если нужно:

docker volume create nginx-config

Запустите контейнер с опцией –mount (пример для nginx):

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

Если вы используете Docker Compose, внесите том в docker-compose.yml. Пример файла версии 3:

version: "3.0"

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

Затем перезапустите сервисы Compose. Чтобы пересобрать образ и применить новые конфигурации:

docker-compose up -d --build

Примечание: docker-compose restart лишь перезапускает контейнеры без изменения конфигурации. Если вы хотите полностью пересоздать контейнеры с новой конфигурацией, используйте up –build или сначала docker-compose down, а затем up.

Клонирование из существующего контейнера

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

Недостатки этого подхода:

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

Шаги:

Узнайте контейнеры:

docker ps

Создайте новый образ на базе текущего контейнера:

docker commit f88f33c918d2 imagename

Запустите новый образ с дополнительным томом:

docker run -d \
  --name devtest \
  --mount source=nginx-config,target=/etc/nginx \
  imagename

После проверки можно удалить старый контейнер и старый образ, если они больше не нужны.

Грубый хак — правка config.v2.json

Коротко: Docker хранит конфигурацию контейнеров в /var/lib/docker/containers//config.v2.json. Теоретически можно отредактировать этот файл, добавить раздел MountPoints и перезапустить демон Docker — контейнеры начнут видеть новые монтирования. Это ненадёжно, не документировано и может нарушить состояние Docker. Используйте только в крайнем случае и только если понимаете риски.

Шаги (на свой страх и риск):

Перейдите в каталог контейнеров:

cd /var/lib/docker/containers

Найдите папку нужного контейнера (ID из docker ps) и сделайте бэкап config.v2.json:

cp config.v2.json config.v2.json.bak

Установите jq и отформатируйте JSON для редактирования:

jq . config.v2.json > tmp.json

В tmp.json найдите блок “MountPoints” и добавьте новый маппинг в формате:

  "MountPoints": {
    "/home/container": {
      "Source": "/var/lib/pterodactyl/volumes/c7fb3a04-e540-48a7-9704-13987f52e933",
      "Destination": "/home/container",
      "RW": true,
      "Name": "",
      "Driver": "",
      "Type": "bind",
      "Propagation": "rprivate",
      "Spec": {
        "Type": "bind",
        "Source": "/var/lib/pterodactyl/volumes/c7fb3a04-e540-48a7-9704-13987f52e933",
        "Target": "/home/container"
      },
      "SkipMountpointCreation": true
    }
  },

Сожмите JSON обратно и запишите в config.v2.json:

jq -c . tmp.json > config.v2.json

Перезапустите системный сервис Docker, чтобы применить изменения:

sudo service docker restart

Риски и ограничения:

Docker внутренне хранит состояние, и несогласованные правки могут привести к повреждению контейнеров.
Монтирование может не пройти корректно при различиях версий Docker и ОС.
Это решение не переносимо и плохо документируется в репозитории.

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

Используйте orchestration (Kubernetes, Swarm) и rolling updates — это избавит вас от ручных правок.
Храните состояние приложения в внешней базе данных или объектном хранилище, чтобы минимизировать зависимость от локальных томов.
Если нужен быстрый доступ к файлам хоста, временно подключите отдельный сервис для синхронизации (rsync/sshfs) и затем перезапустите контейнер с томом.

Ментальные модели и правила

«Идем от конфигурации, а не от состояния»: описывайте инфраструктуру кодом (IaC, docker-compose, Kubernetes manifests). Контейнеры должны быть эпемерными.
«Перезапуск как первая помощь»: если изменение можно внести при перезапуске — делайте это. Это самый предсказуемый и поддерживаемый путь.
«Минимизируй время окна изменений»: продумывайте rollout, health checks и readiness/liveness probes.

Чек‑лист перед изменениями (оператор)

Есть резервная копия важных данных тома.
Изменения зафиксированы в Git (docker-compose.yml или скрипты запуска).
План отката готов (команды остановки/запуска старой версии).
Тестовая среда проверена.
Оповещены заинтересованные стороны о возможном простое.

Роли — что делает кто

Разработчик:
- Обновляет docker-compose.yml или Dockerfile.
- Проверяет миграции данных и сценарии инициализации.
DevOps:
- Проводит деплой, следит за health checks.
- Организует rolling update или blue/green.
Администратор системы:
- Делает бэкапы, при необходимости правит конфигурации хоста.

План действий: пошаговый runbook для добавления тома (продакшен)

Подготовка:
- Сделать бэкап текущих данных (snapshot, rsync или экспорт).
- Обновить docker-compose.yml; зафиксировать изменения в Git.
Тестирование:
- Применить изменения в staging; проверить сервисы.
Ролл‑аут:
- Если у вас несколько инстансов — переводим один за другим на новую версию (rolling update).
- Если одиночный инстанс — выполнять в заданное окно техобслуживания.
Валидация:
- Проверить логи, health endpoints, отклик приложения.
Откат (если понадобится):
- Запустить предыдущую версию через docker-compose up с зафиксированным старым файлом.

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

Сервис отвечает на запросы в пределах SLA.
Новые тома доступны и читаются/записываются приложением.
Нет ошибок в логах, связанных с монтированием тома.

Проблемы и устранение неисправностей

Сценарий: контейнер не видит файлы в томе

Проверьте, что путь целевого каталога совпадает (target в –mount или правка volumes в docker-compose.yml).
Убедитесь, что права и владелец на хосте позволяют доступ (chmod/chown).
Проверьте логи Docker и вывод docker inspect на наличие информации о монтировании.

Команды для диагностики:

docker inspect my_container
docker logs my_container
docker volume ls
docker volume inspect nginx-config

Матрица рисков и смягчение

Риск	Вероятность	Влияние	Смягчение
Потеря данных	Низкая при бэкапе	Высокое	Делать бэкап и тестировать миграцию
Повреждение контейнера при ручной правке	Средняя	Высокое	Не править config.v2.json без крайней необходимости
Простои при одиночном инстансе	Высокая	Среднее	Планировать окно обслуживания, использовать blue/green

Быстрый шпаргалка команд

Остановить контейнер: docker stop
Создать том: docker volume create
Запустить с томом: docker run -d –mount source=,target=
Создать образ из контейнера: docker commit
Перезапустить docker: sudo service docker restart

FAQ

Q: Можно ли добавить том без перезапуска контейнера?

A: Официально — нет. Есть обходные пути (commit или правка config.v2.json), но они требуют осторожности и могут вызвать проблемы.

Q: Безопасно ли редактировать /var/lib/docker/containers/*/config.v2.json?

A: Нет, это нестабильный и неподдерживаемый метод. Используйте его только в экстренных случаях и только после бэкапа.

Q: Что делать, если мне нужен нулевой простой?

A: Запускайте несколько инстансов и проводите rolling update или используйте orchestration (Kubernetes) с readiness/liveness probes.

Короткое объявление для команды (100–200 слов)

Планируем добавить новый том для nginx‑конфигурации. Изменения задокументированы в docker-compose.yml и опубликованы в Git. В среде staging всё проверено. В production обновление будет выполнено через docker-compose up –build в окне обслуживания. Ожидаемое время простоя — до нескольких минут для одиночного инстанса; если потребуется, выполню rollback к предыдущему образу. В экстренных случаях доступен метод клонирования через docker commit, но он используем только как крайняя мера.

Заключение

Перезапуск контейнера с обновлённой конфигурацией — это самый безопасный и поддерживаемый путь для добавления тома. Клонирование и редактирование внутренних файлов Docker возможны, но несут риск и затрудняют поддержку. Планируйте деплой, документируйте изменения и всегда делайте бэкап данных.