Как обрабатывать обновления безопасности в контейнерах Docker?

При развертывании приложений на серверах обычно существует разделение между тем, что приложение связывает с собой, и тем, что оно ожидает от платформы (операционная система и установленные пакеты). Одним из моментов этого является то, что платформа может быть обновлена ​​независимо от приложения. Это полезно, например, когда необходимо срочно применить обновления безопасности к пакетам, предоставляемым платформой, без перестройки всего приложения.

Традиционно обновления безопасности применялись просто путем выполнения команды менеджера пакетов для установки обновленных версий пакетов в операционной системе (например, «yum update» в RHEL). Но с появлением контейнерной технологии, такой как Docker, в которой образы контейнеров по существу объединяют и приложение, и платформу, каков канонический способ поддержания системы с контейнерами в актуальном состоянии? И хост, и контейнеры имеют свои собственные, независимые наборы пакетов, которые требуют обновления и обновления на хосте, не будет обновлять какие-либо пакеты внутри контейнеров. С выпуском RHEL 7, в котором контейнеры Docker особенно представлены, было бы интересно услышать, как Redhat рекомендует способ обработки обновлений безопасности контейнеров.

Мысли о нескольких вариантах:

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

Так что ни один из этих подходов не кажется удовлетворительным.

Образ Docker связывает приложение и «платформу», это правильно. Но обычно изображение состоит из базового изображения и фактического приложения.

Таким образом, канонический способ обработки обновлений безопасности - обновить базовый образ, а затем перестроить образ приложения.

Контейнеры должны быть легкими и взаимозаменяемыми. Если у вашего контейнера есть проблемы с безопасностью, вы перестраиваете исправленную версию контейнера и развертываете новый контейнер. (многие контейнеры используют стандартный базовый образ, который использует стандартные инструменты управления пакетами, такие как apt-get, для установки своих зависимостей, перестройка будет получать обновления из репозиториев)

Хотя вы можете вносить исправления в контейнеры, это не будет хорошо масштабироваться.

Это обрабатывается автоматически в SUSE Enterprise Linux с использованием zypper-docker (1)

SUSE / Zypper-докер

Докер Быстрый старт

Прежде всего, многие из ваших обновлений, которые вы традиционно запускали в прошлом, просто не будут находиться внутри самого контейнера. Контейнер должен быть довольно легким и небольшим подмножеством полной файловой системы, которую вы привыкли видеть в прошлом. Пакеты, которые вам нужно обновить, будут теми, которые являются частью вашего DockerFile, и, поскольку у вас есть DockerFile, вы сможете отслеживать те пакеты и идентификаторы контейнеров, которые требуют обновлений. Интерфейс Cloudstein, который будет выпущен в ближайшее время, отслеживает эти компоненты DockerFile для вас, чтобы можно было создать схему обновления, которая лучше всего подходит для их контейнеров. Надеюсь это поможет

как правило, это даже хуже, чем три варианта, которые вы предоставили. Большинство образов докеров не создаются с помощью менеджеров пакетов, поэтому вы не можете просто вставить оболочку в образ докера и выпустить обновление. Вам нужно будет либо восстановить, либо восстановить образ докера.

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

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