Где Docker место на Proxmox: решение о размещении и ловушка compose

Proxmox установлен, и вы хотите запускать контейнеры. Вопрос не «как поставить», а куда поставить. И это не вопрос вкуса, а вопрос того, сколько всего сломается, когда сломается одно.

Три размещения

Прямо на хост. Самое лёгкое и как раз то, чего делать не стоит. Хост, это слой, на который опирается всё остальное. Всё, что вы туда поставите, оказывается в радиусе поражения каждой виртуальной машины: конфликт зависимостей, заполненный диск или неудачное обновление унесут не только ваши контейнеры, а всё разом.

Внутрь системного контейнера. Легко и быстро разворачивается. Взамен вы запускаете контейнеры внутри контейнера, и у такой схемы свои острые углы: модель прав, слои файловой системы, общее ядро. Выбранная осознанно, она разумна; выбранная потому, что «так было проще», она порождает сюрпризы.

Внутрь виртуальной машины. На бумаге самое тяжёлое, на практике самое чистое. Когда контейнерная схема падает, падает одна виртуальная машина, а не ваш сервер. И когда вы захотите пересобрать, вы пересоберёте одну машину.

Единственный вопрос, который решает

«Если это сломается, что будет со всем остальным?» На хосте ответ «всё», внутри виртуальной машины ответ «одна из них». Расход ресурсов, лёгкость установки, всё это второстепенно рядом с этим ответом.

Вторая половина: compose, это программа

Файл compose выглядит как настройка. Он ею не является. Запустить его, значит выполнить код, и выполняется он с вашими правами. Две строки внутри могут отдать контейнеру всю машину.

Когда люди копируют файл compose из интернета, они не испытывают той неловкости, которую испытывают, копируя команду. Разница не в опасности, а во внешнем виде: команда выглядит как команда, а compose выглядит как файл настроек. То, что он так выглядит, не делает его безопасным.

Четыре строки, на которые надо посмотреть до запуска

Подключает ли он внутрь файловую систему хоста. Просит ли привилегированный режим. Передаёт ли внутрь собственный сокет управления контейнерами. Использует ли сеть хоста напрямую.

Эти четыре, те самые строки, что пробивают границу контейнера: если хоть одна есть, этот контейнер уже не контейнер, а сам хост. Прочитать их, десять секунд, и эти десять секунд стоят больше, чем всё остальное в этой записи.

Что делает Atlas

Atlas проверяет файлы compose и установочные сценарии до установки, и эта проверка находится на сервере, а не в интерфейсе. То есть что бы интерфейс ни отправил, проверку пропустить нельзя.

Находки приходят двумя уровнями. Красный означает нечто, выводящее контейнер за границу контейнера, то есть права, равносильные хостовым; в этом случае требуется явное согласие. Жёлтый означает то, что может быть сделано осознанно, но о чём вам обязаны сказать. Со стороны каталога приложений красный не принимается вовсе.

Есть ещё одна деталь, и она важна: анализатор не высказывает мнений, он сообщает факт. Он не говорит «это опасно», он говорит «эта строка делает то-то». Решает читающий, потому что одна и та же строка в одной установке может быть приемлема, а в другой нет.