Обновление контейнера Docker новым кодом

У меня есть бот python, я написал, что я обратился к контейнеру docker, который запускается через

docker run -dit --restart unless-stopped \
  -v /home/dockeradmin/pythonApp/:/pythonApp \
  --name python-bot-app  python-bot

Это очень распространенный способ запуска контейнеров в среде разработки, такой как ваш ноутбук. Имя на контейнере позволяет легко найти контейнер и управлять им. Монтирование Тома включает текущий код в контейнере поверх всего, что было встроено в образ в том же месте. Если вы перезагрузите контейнер, монтирование Тома перезапустит приложение с этим новым кодом в контейнере, который должен означать, что тестирование изменения в python включает только:

docker container restart python-bot

Мой вопрос, однако, заключается в том, как обновить мой контейнер docker, когда я изменяю код для моего проекта python.

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

1. контрольный код изменяется на управление версиями
2. пусть сервер сборки обнаружит эти изменения и создаст новый образ с уникальным тегом
3. передайте этот образ на сервер реестра
4. разверните этот образ в среде dev, CI, stage и prod в соответствии с политикой вашей организации

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

Сейчас я обычно просто перестраиваю изображение, останавливаю / обрезаю контейнер, а затем снова запускаю его, однако это кажется чрезвычайно расточительным.

В реализации с одним узлом вы можете начать с docker-compose, чтобы заменить контейнер, и он будет обрабатывать шаги остановки и перезапуска для вас. Когда вы попадете в многоузловую среду, вы захотите, чтобы режим Swarm или Kubernetes обрабатывали текущие обновления вашего приложения, обеспечивая HA и избегая любого сбоя во время обновления вашего приложения.

При работе с контейнерами вы минимизируете потери, эффективно распределяя изображение по слоям, повторно используя кэш сборки и отправляя изображения с помощью сервера реестра. Слои файловой системы Docker строятся друг на друге для создания образа, и если вы измените только несколько файлов в последнем слое, то только те изменения отправляются при развертывании обновленного образа. Любые изменения в приложении будут включать в себя как минимум перезапуск этого приложения, а контейнер-это всего лишь несколько дополнительных вызовов API ядра для запуска этого приложения с настройками для создания собственного пространства имен и ограничений. Единственное дополнение, которое вы имеете при воссоздании контейнера против перезапуска, - это немного добавленной уборки, чтобы удалить старые образы и, возможно, некоторые остановленные контейнеры. Но преимущество, которое вы получаете, зная, что ваш вся окружающая среда воспроизводима без какого-либо дрейфа состояний, который стоит дополнительных усилий.