Docker — самый безопасный способ загрузки нового контента в производство

#docker #backup #restore #volumes

#docker #резервное копирование #восстановить #тома

Вопрос:

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

Итак, у меня есть идея создавать новое изображение каждый раз, когда я хочу загрузить новый контент. Затем я загружаю этот образ на компьютер и загружаю rm / deploy контейнер и смотрю, работает ли он — если нет, я извлекаю старый образ. Если код работает, я могу удалить свое старое изображение. Это правильный / безопасный способ обновления производственных компьютеров или мне нужно приступить к резервному копированию и восстановлению? Я имею в виду, что я прочитал это руководство https://www.thegeekdiary.com/how-to-backup-and-restore-docker-containers / но я не совсем понимаю, как восстановить мои тома.

Любое предложение было бы неплохо. Спасибо

Ответ №1:

Это довольно обычный способ использования Docker. Убедитесь, что вы присвоили каждой сборке отдельный тег, например, отметку даты или идентификатор системы управления версиями. Вы можете выполнить обновление, например

 # CONTAINER=...
# IMAGE=...
# OLD_TAG=...
# NEW_TAG=...

# Shell function to run `docker run`
start_the_container() {
  docker run ... --name "$CONTAINER" "$IMAGE:$1"
}

# Shut down the old container
docker stop "$CONTAINER"
docker rm "$CONTAINER"

# Launch the new container
start_the_container "$NEW_TAG"

# Did it work?
if check_if_container_started_successfully; then
  # Delete the old image
  docker rmi "$IMAGE:$OLD_TAG"
else
  # Roll back
  docker stop "$CONTAINER"
  docker rm "$CONTAINER"
  start_the_container "$OLD_TAG"
  docker rmi "$IMAGE:$NEW_TAG"
fi
  

Единственная docker run команда здесь находится в start_the_container функции оболочки; если у вас есть параметры переменной среды или подключения тома, вы можете поместить их туда, и старые тома будут повторно подключены к новому контейнеру. Вам действительно необходимо создать резервную копию содержимого тома, но это может быть отдельно от процесса обновления. Вам не потребуется создавать резервные копии или восстанавливать содержимое файловых систем контейнера сверх этого.

Если вы используете Kubernetes, изменение image: в спецификации развертывания делает это автоматически. Фактически он запустит новый контейнер (ы) перед остановкой старого (ов), чтобы вы получили обновление с нулевым временем простоя; ключевыми элементами для этого являются идентификация запущенных контейнеров и подключение их к какому-либо балансировщику нагрузки, который может маршрутизировать входящие запросы.

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