Динамическое изменение параметров запущенных Docker-контейнеров

Docker позволяет в ряде случаев изменять настройки уже запущенных контейнеров: переименовать их, скорректировать политику перезапуска и изменить многие лимиты ресурсов через docker update. Изменения образа, биндингов портов и монтирований томов нельзя надёжно делать «на лету» — правильный путь обычно заключается в создании нового контейнера с исправленной конфигурацией. Если вы всё же вынуждены править внутренние файлы Docker, делайте это крайне осторожно и по инструкции.

Quick Links

• Renaming a Container

• Changing the Restart Policy

• Changing Hardware Resource Limits

• When Not To Use These Commands?

• What About Other Properties (Image/Ports/Volumes)?

• Danger Zone: Changing Other Container Properties

• Conclusion

Введение

Docker-контейнеры по умолчанию проектируются как эфемерные и неизменяемые единицы. На практике иногда требуется оперативно подправить отдельные параметры уже запущенного контейнера: дать запоминающееся имя, скорректировать политику перезапуска перед перезагрузкой хоста или увеличить/уменьшить лимиты CPU и памяти. В этом руководстве мы пошагово разберём поддерживаемые Docker CLI операции, сценарии, когда их применять, и безопасные альтернативы.

Важно знать в двух строках

• “docker rename” — безопасно меняет имя контейнера.
• “docker update” — изменяет политику перезапуска и большинство ресурсных лимитов для запущенных Linux-контейнеров.

Переименование контейнера

Имена контейнеров задаются через флаг

--name

при запуске docker run. Если имя не указано, демон Docker присвоит случайное имя. Имена удобны для ссылок на контейнер в командах CLI: так не нужно постоянно искать ID через docker ps.

Команда для переименования:

# docker rename  
docker rename old_name new_name

Пояснение

• При переименовании Docker обновляет внутреннюю запись и новый имя становится доступным для команд CLI.
• Если контейнер управляется внешним инструментом (например, docker-compose), переименование может сделать его “невидимым” для этого инструмента — см. раздел о ситуациях, когда не следует использовать команды напрямую.

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

Изменение политики перезапуска

Политики перезапуска управляют поведением контейнера при перезапуске демона Docker или восстановлении хоста. Доступны политики: “no”, “on-failure[:max-retries]”, “always” и “unless-stopped”. Они позволяют заставить контейнер автоматически стартовать, оставаться в состоянии остановлен или стартовать условно.

Docker поддерживает динамическую смену политики перезапуска через docker update:

docker update --restart unless-stopped demo_container

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

Короткая шпаргалка по политикам

• no — контейнер не будет запускаться автоматически.
• on-failure[:N] — запуск только при ненулевом коде выхода; опционально ограничение по числу повторов.
• always — всегда запускать контейнер после рестарта демона.
• unless-stopped — как always, но не перезапускает контейнер, явно остановленный пользователем.

Изменение лимитов аппаратных ресурсов

Команда docker update позволяет модифицировать ресурсы, назначенные контейнеру: CPU, память, blkio и ограничения процессов. Нужно указать один или несколько ID/имён контейнеров и флаги с целевыми значениями.

Доступные флаги (кратко):

• --blkio-weight — относительный вес Block IO (значение 10–1000).
• --cpus — число виртуальных CPU, доступных контейнеру (например, 0.5, 2, 4).
• --cpu-shares — относительный вес CPU (приоритет планировщика).
• --memory — лимит памяти (например, 1024M или 1G).
• --memory-swap — общий лимит памяти + swap; -1 означает без ограничений.
• --kernel-memory — лимит kernel memory (нужна остановка контейнера перед применением).
• --pids-limit — максимальное число PID внутри контейнера.

Пример изменения CPU и памяти для нескольких контейнеров:

docker update --cpus 4 --memory 1024M first_container second_container

Ограничения и особенности

• Большинство флагов можно применять к запущенным Linux-контейнерам. Для --kernel-memory контейнер нужно предварительно остановить: docker stop.
• Эти флаги не поддерживаются для Windows-контейнеров.
• Изменение лимитов может повлиять на QoS и поведение приложений внутри контейнера — тестируйте на стейджинге.

Совет по локализации единиц

В командах оставляйте синтаксис и единицы как в Docker (M, G). В тексте документации можно пояснить: 1024M ≈ 1 ГБ.

Когда не следует использовать эти команды?

Команды docker update и docker rename подходят для отдельных контейнеров, созданных вручную через docker run. Использование их для контейнеров, управляемых сторонними инструментами (Compose, Swarm, Kubernetes, systemd unit-ов и др.), часто приводит к рассинхронизации состояния.

Почему это плохо

• В docker-compose контейнеры и их ресурсы описываются декларативно в docker-compose.yml. Повторный запуск docker-compose up восстановит параметры из файла и затрёт ваши изменения.
• Инструмент, управляющий стеком (CI/CD, оркестратор), может не распознать вручную переименованный контейнер и попытаться создать новый или удалить существующий.

Рекомендация

Если вы пользуетесь инструментом управления контейнерами — вносите изменения туда и пересоздавайте контейнеры через него. Для Compose: измените docker-compose.yml и выполните

docker-compose up -d

Это минимизирует риск «осиротевших» контейнеров и неожиданных побочных эффектов.

Что насчёт других свойств (образ/порты/тома)?

Docker CLI позволяет динамически менять имя, политику рестарта и большинство ресурсных ограничений. Но такие параметры как образ контейнера, привязки портов и монтирования томов нельзя надёжно изменить для уже запущенной инстанции.

Правильный подход — создать новый контейнер

Если нужно обновить образ, порт или томы, уничтожьте текущую инстанцию и запустите новую с нужными параметрами. Контейнеры проектируются как статeless; для сохранения данных используйте тома.

Пример сохранения тома между контейнерами:

docker run -v config-volume:/usr/lib/config --name demo example-image:v1

docker rm demo

# Существующие данные в /usr/lib/config сохраняются
docker run -v config-volume:/usr/lib/config --name demo2 example-image:v2

Таким образом данные в config-volume сохраняются, а вы получаете новую инстанцию с обновлённым образом.

Опасная зона: изменение других свойств контейнера

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

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

1. Остановите контейнер:

docker stop my-container

2. Найдите полный ID контейнера (не усечённый):

docker inspect  | jq | grep Id

3. Откройте файл конфигурации контейнера на хосте:

/var/lib/docker/containers//config.v2.json

4. Внесите изменения (например, PortBindings, Env, Cmd, Entrypoint). Примеры формата:

Добавление биндинга порта:

{
    "PortBindings": {
        "80/tcp": {
            "HostIp": "",
            "HostPort": "8080"
        }
    }
}

Добавление переменных окружения:

{
    "Env": [
        "FOO=bar",
        "CUSTOM_VARIABLE=example"
    ]
}

5. Перезапустите сервис Docker и контейнер:

sudo service docker restart

docker start my-container

Примечания и ограничения

• Изменения не работают для запущенных контейнеров — предварительно останавливайте.
• Любая ошибка в JSON-файле может привести к некорректной работе контейнера или демона Docker.
• Этот метод не рекомендуется в продуктиве и лучше использовать только как крайний вариант восстановления.

Руководство действий (SOP) для изменения конфигурации контейнера

Цель: безопасно внести поддерживаемые изменения (имя, рестарт, ресурсы) или корректно пересоздать контейнер, если требуется менять образ/порты/тома.

Шаги для поддерживаемых изменений

1. Определите контейнер: docker ps --format "{{.Names}} {{.ID}} {{.Status}}".
2. Если нужно переименовать: docker rename old_name new_name.
3. Если нужно сменить политику рестарта: docker update --restart .
4. Для ресурсов: docker update --cpus X --memory YM .
5. Проверьте изменения: docker inspect | jq .HostConfig.
6. Наблюдайте метрики приложения после изменения.

Шаги при необходимости изменения образа/портов/томов

1. Обновите декларативные файлы (docker-compose.yml, Kubernetes manifests).
2. Подготовьте миграцию данных: убедитесь, что все важные данные в томах.
3. Остановите старый контейнер: docker stop и docker rm.
4. Запустите новый контейнер с нужными параметрами.
5. Проверьте логирование и подключаемые сервисы.

Дерево решений (Mermaid)

flowchart TD
  A'Нужно изменить контейнер?' --> B{Что менять?}
  B -->|Имя| C[Использовать docker rename]
  B -->|Рестарт/Ресурсы| D[Использовать docker update]
  B -->|Образ/Порты/Тома| E[Пересоздать контейнер с docker run или через Compose]
  E --> F{Контейнер управляется Compose?}
  F -->|Да| G[Изменить docker-compose.yml и docker-compose up -d]
  F -->|Нет| H[docker stop; docker rm; docker run ...]
  D --> I[Проверить метрики и логи]
  C --> I
  G --> I
  H --> I

Контрольные списки по ролям

Оператор/Сисадмин

• Проверить, управляет ли стек внешняя система (Compose/Swarm/K8s).
• Сделать бэкап критичных томов.
• Применить docker update для ресурсных правок.
• Наблюдать метрики 15–30 минут.

Разработчик

• Обновить docker-compose.yml или Dockerfile для постоянных изменений.
• Проверить совместимость приложения с новыми лимитами.
• Написать тесты производительности для новых конфигураций.

DevOps-инженер

• Обновить CI/CD pipeline для пересоздания контейнеров.
• Автоматизировать валидацию конфигурации (linting YAML/JSON).

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

• Для переименования: контейнер доступен под новым именем, сервисы подключаются корректно.
• Для изменения политики рестарта: после перезапуска демона контейнер ведёт себя в соответствии с новым правилом.
• Для изменения ресурсов: приложение остаётся работоспособным и не падает по OOM/CPU starvation в течение контрольного окна.
• Для пересоздания контейнера: данные в томах сохранены, новый контейнер обрабатывает трафик без регрессий.

Тестовые сценарии и приёмка

• Негативный тест: установить слишком маленький memory limit и убедиться, что приложение упадёт или будет OOM-killed.
• Позитивный тест: увеличить CPU и провести нагрузочное тестирование — производительность должна вырасти или оставаться стабильной.
• Интеграционный тест: после пересоздания контейнера все зависимости (СУБД, внешние API) работают корректно.

Риски и меры

Когда ручное редактирование оправдано (контрпример)

Контрафакты:

• Экстренный восстановительный сценарий, когда автоматизированный pipeline недоступен и нужно быстро вернуть сервис онлайн.
• Тестовые и локальные окружения, где риски низкие и вы хотите быстро проверить гипотезу.

В остальных случаях используйте пересоздание контейнера через декларативные конфигурации.

Краткий глоссарий (1 строка)

• Контейнер — изолированная инстанция приложения, созданная из образа.
• Образ — слепок файловой системы и метаданных для контейнера.
• Том (volume) — механизм хранения данных вне жизненного цикла контейнера.
• Политика рестарта — правило автоматики старта контейнера при перезапуске демона/хоста.

Локальные советы и подводные камни

• На Windows-хостах флаги ресурсов применимы только к Linux-контейнерам.
• Для production окружений автоматизируйте изменения через инфраструктурные инструменты.
• Никогда не правьте config.v2.json на рабочем хосте без бэкапа и плана отката.

Социальный анонс (кратко)

Если вы управляете Docker-контейнерами: можно безопасно менять имена, политику перезапуска и ресурсы через CLI. Для изменений образа/портов/томов пересоздавайте контейнеры и держите конфигурацию декларативной.

Заключение

Docker проектировался под принцип “заменять, а не править” — это упрощает автоматизацию и предотвращает конфликты конфигураций. Тем не менее, поддерживаемые операции (переименование, изменение политики рестарта и большинства ресурсных лимитов) полезны в оперативных задачах. Всегда отдавайте приоритет декларативным инструментам управления (Compose, Kubernetes) и используйте прямое редактирование внутренних файлов Docker только как крайний и хорошо контролируемый шаг.

Короткое резюме

• Меняйте имя и лимиты ресурсов с помощью docker rename и docker update.
• Не изменяйте образ/порты/тома на лету — пересоздавайте контейнеры.
• Если контейнер управляется Compose, изменяйте docker-compose.yml и перезапускайте стек.
• Ручное редактирование /var/lib/docker/containers//config.v2.json — опасно и неподдерживаемо; используйте только при крайней необходимости.