При развертывании приложений на серверах обычно существует разделение между тем, что приложение связывает с собой, и тем, что оно ожидает от платформы (операционная система и установленные пакеты). Одним из аспектов этого является то, что платформу можно обновлять независимо от приложения. Это полезно, например, когда необходимо срочно применить обновления безопасности к пакетам, предоставляемым платформой, без перестройки всего приложения.
Традиционно обновления безопасности применялись просто путем выполнения команды диспетчера пакетов для установки обновленных версий пакетов в операционной системе (например, «yum update» в RHEL). Но с появлением контейнерных технологий, таких как Docker, образы контейнеров по сути объединяют оба приложения. и платформа, каков канонический способ поддерживать систему с контейнерами в актуальном состоянии? И у хоста, и у контейнеров есть свои собственные независимые наборы пакетов, которые необходимо обновить, и обновление на хосте не будет обновлять никакие пакеты внутри контейнеров. С выпуском RHEL 7, в котором особенно представлены контейнеры Docker, было бы интересно услышать, какой способ обработки обновлений безопасности контейнеров рекомендуется Redhat.
Мысли о нескольких вариантах:
Так что ни один из этих подходов не кажется удовлетворительным.
Образ Docker объединяет приложение и «платформу», это правильно. Но обычно образ состоит из базового образа и самого приложения.
Итак, канонический способ обработки обновлений безопасности - обновить базовый образ, а затем перестроить образ приложения.
Контейнеры должны быть легкими и взаимозаменяемыми. Если у вашего контейнера есть проблемы с безопасностью, вы перестраиваете версию контейнера, в которую были внесены исправления, и развертываете новый контейнер. (многие контейнеры используют стандартный базовый образ, который использует стандартные инструменты управления пакетами, такие как apt-get, для установки своих зависимостей, при повторной сборке обновления будут извлечены из репозиториев)
Вы можете вносить исправления внутри контейнеров, но это плохо масштабируется.
В SUSE Enterprise Linux это выполняется автоматически с помощью zypper-docker (1).
как правило, это даже хуже, чем те три варианта, которые вы предоставили. Большинство образов докеров не создаются с помощью диспетчеров пакетов, поэтому вы не можете просто использовать оболочку образа докера и выпустить обновление. Вам нужно будет либо перестроить, либо заново получить образ докера.
Тот факт, что вам нужно перестроить или что вы ждете от других, чтобы восстановить исправления безопасности, в большинстве случаев кажется необоснованным.
Я рассматривал возможность развертывания гидролокатора и радара в контейнерах докеров, но знание того, что они не собираются получать регулярные обновления безопасности, которые получает мой контейнер, является нарушением сделки. Управление обновлениями безопасности для моего контейнера - это достаточно хлопот, и вам не придется как-то вручную применять обновления безопасности для каждого образа докера отдельно.
Во-первых, многие из ваших обновлений, которые вы традиционно запускали в прошлом, просто не будут находиться внутри самого контейнера. Контейнер должен быть довольно легким и небольшим подмножеством полной файловой системы, к которой вы привыкли видеть в прошлом. Пакеты, которые вам нужно обновить, будут теми, которые являются частью вашего DockerFile, и, поскольку у вас есть DockerFile, вы должны иметь возможность отслеживать те пакеты и идентификаторы контейнеров, которые нуждаются в обновлении. Пользовательский интерфейс Cloudstein, который скоро будет выпущен, отслеживает эти ингредиенты DockerFile для вас, чтобы можно было создать схему обновления, которая лучше всего подходит для их контейнеров. Надеюсь это поможет