Comments 12
Давайте придумаем ещё один стандарт. Обложим его документацией и тестами, ведь мы хотим этого избежать в ansible. Навсидку мне видится внешний генератор ansible-конфигов по +/- конечному набору сценариев.
Можете поделиться по какой причине контейнеры "запрещены службой безопасности"? Чем они для безопасника опаснее того же vim, nginx или ядра Linux? Я без иронии, мне действительно интересно.
Если такая боль с попыткой удовлетворить всех и вся, то может посмотреть в сторону ПАК?
По поводу контейнеров — причины бывают разные, и не всегда они рациональны с технической точки зрения, но они напрямую диктуются моделью угроз конкретной организации. Комментарии к требованиям ИБ получить, чаще всего, не удаётся — это внутренняя политика, и спорить с ней бесполезно. Приходится принимать как данность и искать обходные пути.
Про ПАК — да, это один из вариантов и мы его используем, но ПАК тоже не панацея. Он решает проблему совместимости на уровне ОС, но не решает проблему доставки самого приложения и его зависимостей. Плюс ПАК — это ещё один слой, который надо внедрять и поддерживать. А обновление ПАК никто не отменял: новая версия ОС, новый патч безопасности — и вы снова проходите весь цикл тестирования и согласования.
Я что-то не очень понимаю.
Разве docker compose не решает эту проблему? Там же есть всё то же самое.
Ну и вообще, какой-то странный у вас подход.
Зачем вам писать и поддерживать роль ansible?
Не логичнее ли поставлять для каждого свой способ установки.
Для k8s - helm chart
Для docker - image и docker compose
Для "классической инфры" - пакет, сконцентрируйтесь на парочке дистрибутивов и предоставляйте пакеты для них, например RPM и DEB и уже закрыто 90% используемых в enterpise дистрибутивов.
Разве docker compose не решает эту проблему?
Решает — и не только он один. Все они имеют одну общую базу: это просто обёртки над Linux Namespaces, cgroups и файловыми системами (overlayfs). По сути, CRI-O, Docker (containerd) и Podman, в основе работают с одними и теми же примитивами ядра. Технологически — да, это прекрасно работает, когда контейнеры разрешены и есть инфраструктура под них.
Но проблема, которую я описываю в статье, находится на уровень выше. Она не в том, как запустить изолированный процесс, а в том:
как доставить артефакт (образ, бинарник, пакет) в произвольное окружение, где может не быть registry;
как применить конфигурацию, уникальную для каждого заказчика (сети, прокси, хранилища, сертификаты);
как обеспечить обратную совместимость, когда на одной версии ОС работает один набор зависимостей, а на другой — другой.
Docker Compose справляется со своей задачей — описать многоконтейнерное приложение в среде Docker. Но даже если контейнеры разрешены, Compose не рассчитан на развертывание на 10+ машинах (а есть 100 и 200, такие случаи не редки) — это инструмент для локальной разработки или небольших кластеров, а не для массового продакшена.
Не логичнее ли поставлять для каждого свой способ установки.
Это мы и делаем сейчас, и именно это приводит к разрастанию инфраструктурной кодовой базы. Helm-чарт, Docker-образ, RPM, DEB, плюс скрипты для Alt Linux, Astra, РЕД ОС — и вот у вас уже не один способ установки, а пять, и каждый нужно тестировать, поддерживать и синхронизировать с новой версией приложения. Количество ресурсов для поддержки ограничено. А если заказчик вообще не использует контейнеры, Compose и Helm становятся бесполезны.
Поэтому я и предлагаю не плодить способы установки, а подумать о том, как унифицировать процесс доставки так, чтобы он не превращался в ещё один продукт, который нужно разрабатывать и поддерживать. В таком случае мы всегда будем работать с одним и тем же артефактом, но в абсолютно разных окружениях
сконцентрируйтесь на парочке дистрибутивов
в enterprise так не работает. Заказчик платит деньги и хочет, чтобы работало на его инфраструктуре.
Шестой до сих пор живёт на CentOS 7, потому что обновление инфраструктуры — отдельный многолетний проект.
Это реальный кейс. Каждый такой кейс добавляет ещё один виток сложности в наши сценарии развёртывания.
Без нужды в оркестрации, для развертывания приложений поставляемых в виде OCI можно использовать docker/podman? Они есть большинстве дистрибутивов, включая упомянутые Alt, РЕД ОС и Astra.
Если же в организации просто исторически сложилось, что контейнеры под запретом без объяснений, то дополнительной инфраструктуры для хранения образов в виде OCI репозиториев не будет, что как понимаю и ведёт к невозможности использования Horchestra
curl/wget — скачать слои образа
tar — распаковать слои
mount — смонтировать rootfs
systemd — запустить приложение как сервис
Ни в одном из этих пунктов нет Docker/Podman. OCI-образ — это просто tar-архив с корневой файловой системой и JSON-манифестом. И работает этот механизм начиная с версии ядра 3.18. В случае, если у клиента контейнеры под запретом и нет registry, то мы всегда можем принести на флешке OCI-layout, который после создания systemd .mount и .service будет работать абсолютно так же, как и после запуска через docker compose up или установки системного пакета.
Докер типа запрещён из каких-то там соображений, зато там можно самописный недодокер под управлением самописного недокуба с никем не проверенным на безопасность API, ага.
В результате система состоит всего из двух компонентов
А кубернетес это пять бинарей, угу.
Всё верно говорите: недодокер и недокубер. Зачем писать кубер и докер, когда они уже есть и они то как раз не нужны!
В документации по кубу есть информация об Aggregation Layer, там как раз описано как сделать недокубер. Так же там есть информация, как сделать недодокер и настроить его для работы с кубом.
никем не проверенным на безопасность API
думаете у куба проверен и на 100% безопасный?
В результате система состоит всего из двух компонентов
Да, действительно только контроллер и агент. Оно работает абсолютно без каких-либо зависимостей!
Horchestra: когда Kubernetes нельзя, а Ansible становится второй кодовой базой