Неизменяемые образы Linux -Как далеко я могу и должен зайти?
Неизменность — это круто, чтобы реализовать непротиворечивость, предсказуемость и надежность, и я не вижу никаких причин, по которым я не должен стремиться к неизменности на уровне ОС-при развертывании моего приложения на Linux VPS от разных облачных провайдеров по всему миру. С такими инструментами, как Packer, помогающими создавать образы ОС, похоже, это тоже правильный путь.
Для некоторых облачных провайдеров (, например. Digital Ocean), я могу создать образ локально в формате qcow2 или в необработанном формате, а затем загрузить готовый образ в облачный провайдер для развертывания при создании новых 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-пакетов с точно такими же номерами версий), что и на всех других облачные провайдеры?
Если я правильно понимаю, что вы хотите, я бы пошел к любому инструменту «инфра-теста», например Inspec , который позволяет вам описать, что вы хотите иметь в своем целевом образе/ВМ.
Мы используем его для проверки нашего saltstack/saltproject кода, используя его вместе с Kitchen таким образом (мы запускаем его в задании на нашем инструменте CI)
createN виртуальные машины с Kitchen(можно использовать с Docker, Vagrant, а также с облачными провайдерами)provisionкаждая машина со своим профилем, с Salt, Ansible, Chef, Puppet или чем-то ещеverifyрезультирующее состояние машины с Inspec
Inspec позволяет вам создавать своего рода «модульные тесты», но для инфраструктуры/системы:вы можете легко проверить присутствие или отсутствие пользователей и групп, установленные пакеты и их версию, запущенные службы, порты TCP/UDP, правила брандмауэра...
(Я также использую Packer для создания образов, но на данный момент я не использую Inspec в этом контексте:мы считаем, что код, используемый для создания этого образа, уже был протестирован предыдущим заданием CI )
. проблема:Я бы добавил в настройки Packer шаг проверки Inspec. Кроме того, кажется, что он уже интегрирован в Packer как средство обеспечения https://www.packer.io/docs/provisioners/inspec(, которое я только что обнаружил)