Обновления приложения в контейнерах Докера?
Я думаю, что проблема здесь состоит в том, что Fedora не использует sysV систему runlevels больше (у меня была подобная проблема с Archlinux), таким образом, выше примеров больше не работает. Вместо этого это использует цели systemd, которые могут быть указаны как следующее:
kernel=vmlinuz parameter_and_so_on systemd.unit=multi-user
многопользовательские начальные загрузки в то, что равно sysV 3 runlevel. Если это не помогает использовать: systemd.unit=rescue Который подобен SysV 1 runlevel.
Когда Вы сделанная фиксация просто удаляете это из конца строки. Включить выполнение к графической цели когда Вы сделанная выполненная фиксация: systemctl start graphical.target Или просто перезагрузка и удаляет параметр в командной строке личинки.
Править: Я видел, что существует не в моей системе (как в эскерах также) kernel= строка cmd я думаю, что корректная строка добавляет это, должна быть также linux= или intrd=
TL;DR[118347]: Если вы не встроите его в себя, этого не произойдет.
Эффективный способ сделать это - просто написать пользовательский стартовый скрипт для вашего контейнера, указанного в [118348]CMD[118349] в вашем [118350]Dockerfile[118351]. В этом файле выполните [118352]apt-get update && apt-get upgrade -qqy[118353] перед тем, как начать то, что вы запустили.
Затем у вас есть пара способов гарантировать, что обновления попадут в контейнер:
Определите задание cron в операционной системе вашего хоста, чтобы перезагрузить контейнер по расписанию, таким образом, имея его обновление и обновление по расписанию.
Подпишитесь на обновления безопасности для части программного обеспечения, затем, при обновлении затронутого пакета, перезагрузите контейнер.
Это не самая простая вещь для оптимизации и автоматизации, но это возможно. [118006]
Я не согласен с принятым ответом. Во-первых, необходимо проектировать контейнеры с учетом разделения состояний (в случае MySQL это означает, что по крайней мере /var/lib/mysql идет в своем собственном томе ). Во-вторых, вы должны определить стратегию обновления; современное состояние заключается в создании версионных образов для каждого набора обновлений apt-пакетов и их тестировании перед сменой тома данных с работающего контейнера на новый. Это может включать либо время простоя, либо отсутствие простоя вообще, если вы используете что-то вроде hipache.
Эта установка, хотя и более дорогая по сравнению с первоначальной установкой, используется компаниями с большим количеством контейнеров и со временем будет дешевле в обслуживании.
Более того, обновление пакетов может в конечном итоге сломать ваши работающие контейнеры, поэтому их применение к работающим контейнерам не является лучшей практикой - так как это не значит, что вы не используете устаревшее программное обеспечение.