При развертывании приложений на серверах обычно существует разделение между тем, что приложение связывает с самим собой, и тем, что оно ожидает от платформы (операционной системы и установленных пакетов). Одним из моментов этого является то, что платформа может обновляться независимо от приложения. Это полезно, например, когда необходимо срочно применить обновления безопасности к пакетам, предоставляемым платформой, без перестройки всего приложения.
Традиционно обновления безопасности применялись простым выполнением команды диспетчера пакетов для установки обновленных версий пакетов в операционной системе (например, "yum update" на RHEL). Но с появлением контейнерных технологий, таких как Docker, где изображения контейнеров по сути объединяют оба приложения и платформа, каков канонический способ поддержания системы с контейнерами в актуальном состоянии? Как хост, так и контейнеры имеют свои собственные, независимые наборы пакетов, которые нуждаются в обновлении, и обновление на хосте не приведет к обновлению каких-либо пакетов внутри контейнеров. С выпуском RHEL 7, в котором особенно представлены контейнеры Docker, было бы интересно услышать, как Redhat рекомендует обрабатывать обновления безопасности контейнеров.
Мысли о нескольких вариантах:
Разрешение диспетчеру пакетов обновлять пакеты на хосте не приведет к обновлению пакетов внутри контейнеров.
Необходимость регенерации всех образов контейнеров для применения обновлений, по-видимому, нарушает разделение между приложением и платформой (для обновления платформы требуется доступ к процессу сборки приложения, который генерирует образы Docker).
Выполнение ручных команд внутри каждого из запущенных контейнеров кажется громоздким, и изменения могут быть перезаписаны при следующем обновлении контейнеров из артефактов выпуска приложения.
Таким образом, ни один из этих подходов не кажется удовлетворительным.
Изображение Docker объединяет приложение и "платформу", это правильно. Но обычно изображение состоит из базового изображения и фактического приложения.
Таким образом, канонический способ обработки обновлений безопасности - это обновить базовый образ, а затем перестроить образ вашего приложения.
Предполагается, что контейнеры должны быть легкими и взаимозаменяемыми. Если у вашего контейнера есть проблема с безопасностью, вы перестраиваете исправленную версию контейнера и развертываете новый контейнер. (многие контейнеры используют стандартный базовый образ, который использует стандартные инструменты управления пакетами, такие как apt-get, для установки своих зависимостей, перестройка будет извлекать обновления из репозиториев)
В то время как вы могли бы исправлять внутренние контейнеры, это не будет хорошо масштабироваться.
Прежде всего, многие из ваших обновлений, которые вы традиционно запускали в прошлом, просто не будут находиться внутри самого контейнера. Контейнер должен быть довольно легким и небольшим подмножеством полной файловой системы, которую вы привыкли видеть в прошлом. Пакеты, которые вы должны обновить, будут теми, которые являются частью вашего файла DockerFile, и поскольку у вас есть файл DockerFile, вы должны иметь возможность отслеживать те пакеты и идентификаторы контейнеров, которые нуждаются в обновлениях. Пользовательский интерфейс Cloudstein, который будет выпущен в ближайшее время, отслеживает эти компоненты DockerFile для вас, чтобы можно было создать схему обновления, которая лучше всего подходит для их контейнеров. Надеюсь, это поможет
Лучший ответ here очень помогает, потому что есть скрипт, который содержит основные командные строки, чтобы делать именно то, что сказал Йоханнес Земке:
Лучшая идея для этого, которую я видел до сих пор, - это [Project Atomic](http://www.projectatomic.io /). Хотя я не думаю, что он полностью готов к прайм-тайму.
Валько, с каким рабочим процессом ты в итоге столкнулся? Я использую долгосрочные контейнеры (например, хостинг php-cgi), и то, что я нашел до сих пор, это: “docker pull debian / jessie”, чтобы обновить образ, затем перестроить мои существующие образы, затем остановить контейнеры и запустить их снова (с новым изображением). Изображения, которые я создаю, имеют то же имя, что и предыдущие, поэтому запуск выполняется с помощью скрипта. Затем я удаляю “неназванные” изображения. Я, конечно, был бы признателен за лучший рабочий процесс.
Интересный вопрос. Я и сам удивляюсь этому. Если у вас есть 20 приложений, запущенных на одном хосте docker, вам необходимо обновить базовые образы, перестроить и перезапустить! 20 приложений, и вы даже не знаете, затронуло ли обновление системы безопасности их все или только одно из них. Вы должны перестроить образ, скажем, для Apache, когда обновление для системы безопасности затронуло, например, только libpng. Таким образом, вы в конечном итоге получаете ненужные перестройки и перезапуски…
миха: Это звучит похоже на то, что я в итоге сделал. В основном постоянно обновляя и перестраивая все изображения в рамках создания новых выпусков. И перезапуск контейнеров с использованием новых изображений.
У меня нет ответа, но на случай, если кому-то нужен простой скрипт, который может помочь автоматизировать проверку обновлений базового изображения: dockcheck