Неизменяемые образы Linux — как далеко я могу и должен зайти?

Неизменяемость — это круто для обеспечения согласованности, предсказуемости и надежности, и я не вижу причин, по которым мне не следует стремиться к неизменности на уровне ОС при развертывании моего приложения на Linux VPS от разных облачных провайдеров по всему миру. Мир. С такими инструментами, как Packer, помогающими создавать образы ОС, похоже, это тоже правильный путь.

Для некоторых облачных провайдеров (например, Digital Ocean) я могу создать образ локально в формате qcow2 или raw, а затем загрузить готовый образ облачному провайдеру для развертывания при создании новых VPS.Кажется, это лучший вариант.

Но другие облачные провайдеры (например, Hetzner в Германии) не поддерживают импорт ваших собственных образов ОС — вместо этого вам нужно создать образ в их инфраструктуре на основе одного из их исходных образов, а затем вы можете сделать моментальный снимок окончательной установки в многоразовый образ. изображение, когда все настроено правильно. На самом деле это также то, что делает «Hetzner Cloud Builder» от Packer.

Но как я тогда гарантирую, что окончательное изображение Hetzner имеет точный такая же установка CentOS 8 (вплоть до точно такого же набора установленных RPM-пакетов с точно такими же номерами версий), что и у всех других облачных провайдеров?

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

Существует ли такой инструмент, или я должен думать об этом совершенно по-другому?

Некоторые могут возразить, что RPM-пакеты CentOS всегда следует просто обновлять до новейшей доступной версии, но тогда я не могу гарантировать, что все облачные провайдеры используют одну и ту же установку ОС, что потенциально может повлиять на предсказуемость и надежность моего сервиса.

Вместо этого я хочу иметь возможность тщательно протестировать полную установку (ОС + приложение) перед ее развертыванием у любого облачного провайдера, а затем развертывание должно быть одинаковым для всех облачных провайдеров. Именно так мы делаем вещи на уровне приложений, используя образы Docker, и я не понимаю, почему мы должны соглашаться на меньшее на уровне ОС.

Есть ли какие-нибудь советы от коллег DevSecOps о том, как достичь этих целей?

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

С дистрибутивом, использующим отдельные пакеты, скажем, CentOS с использованием rpm, вы можете поддерживать свой собственный репозиторий обновлений. Ограничьтесь только теми пакетами, которые вы используете. Регулярно загружайте обновления в репозиторий для тестирования, скажем, каждые 4 недели. Некоторое время протестируйте этот замороженный набор пакетов, а затем перейдите в свой стабильный репозиторий. Настройте все хосты для автоматического обновления с вашего зеркала, возможно, по расписанию. Когда автоматизация устанавливает пакет как часть развертывания вещи, его версия известна, потому что она исходит от вашего зеркала. Однако отдельные хосты могут иметь проблемы с применением пакетной транзакции и устаревать.Подумайте о том, чтобы запросить у каждого хоста в парке версии особенно важных пакетов, возможно, определенных обновлений безопасности.

Достаточно просто клонировать установку ОС как другой экземпляр. Однако образы дистрибутивов на основе пакетов на самом деле не являются неизменяемыми, менеджер пакетов по-прежнему доступен в экземпляре, а привилегированные пользователи по-прежнему могут изменять что-то в дереве /usr.

Рассмотрим дистрибутив, основанный на обновлении на основе изображений, например CoreOS. Обновления должны быть помещены в образ и перезагружены, чтобы они вступили в силу. Настройка ограничена небольшим количеством метаданных. CoreOS, в частности, предназначен только для размещения контейнеров, но это может быть вашим вариантом использования. Fedora CoreOS 34.20210904.3.0 обладает преимуществом воспроизводимости и представляет собой четко определенный набор программного обеспечения.

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

Сейчас самое время оценить ваш выбор дистрибутива по другим причинам. CentOS Linux 8 заканчивается в декабре 2021 года. CentOS Stream является заменой, однако она является восходящей, а не нижестоящей по сравнению с RHEL.

На самом деле, как только вы создали виртуальную машину в Hetzner, вы можете загрузить ее на выбранный вами LiveCD, в котором есть такие вещи, как CloneZilla или SystemRescue, которые вы можете использовать для дампа/восстановления вашего образа.

Я на самом деле считаю, что образы CloneZilla более переносимы между различными поставщиками облачных VPS.

Но как тогда я могу гарантировать, что окончательный образ Hetzner имеет точно такую ​​же установку CentOS 8 (вплоть до точно такого же набора установленных RPM-пакетов с точно такими же номерами версий), что и у всех других облачных провайдеров?

Если я правильно понимаю, что вы хотите, я бы пошел к любому инструменту "infra-test", например осмотр который позволяет вам описать, что вы хотите иметь в своем целевом образе/VM.

Мы используем его для проверки наших соляной стек/солтпроект код, использующий его в сочетании с Кухня таким образом (мы запускаем его в задании на нашем инструменте CI)

• Создайте N виртуальных машин с кухней (может использоваться с Docker, Vagrant, а также с облачными провайдерами)
• обеспечение каждая машина со своим профилем, с Salt, Ansible, Chef, Puppet или как там
• проверять результирующее состояние машины с Inspec

Inspec позволяет вам создавать своего рода «модульные тесты», но для инфраструктуры/системы: вы можете легко проверить присутствие или отсутствие пользователей и групп, установленные пакеты и их версию, запущенные службы, порты TCP/UDP, правила брандмауэра...

(Я также использую Packer для создания образов, но на данный момент я не использую Inspec в этом контексте: мы считаем, что код, используемый для создания этого образа, уже был протестирован предыдущим заданием CI)

Итак, переходя к вашей проблеме: я бы добавил в вашу настройку Packer шаг проверки Inspec. Более того, кажется, что он уже интегрирован в Packer в качестве провайдера. https://www.packer.io/docs/provisioners/inspec (что я только что обнаружил)