Комментарии 15
Интересно услышать, чем не подошел SaltStack?
В интернете есть много споров на эту тему и у каждого свое мнение, от себя могу добавить, что тут вопрос вкуса и удобства, ну и puppet вроде как имеет больше комьюнити.
Примерно одинаковые инструменты Chef (ruby) - Ansible (python), Puppet (ruby) - Salt (python)
Спасибо за статью, тема мне довольно близка, поэтому появился ряд вопросов.
Расскажите, пожалуйста, чем отличается puppet-master от puppet-server в вашей конфигурации, если CA вынесен на отдельную машину? Как хосты попадают в Foreman? По результатам отчёта от Puppet, создаются там в ручную/скриптами или используете деплой хостов через Foreman? Как вы обеспечиваете однообразие и актуальность puppet-классов на разных puppet серверах?
Чем отличается puppet-master от puppet-server в вашей конфигурации?
По структуре не чем не отличается, тут идет просто соединение всех puppet серверов через один мастер, чтобы server роль тоже ходила в мастер и синкалась.
Как хосты попадают в Foreman?
При заливки хоста через cloud-init выполняется коннект к puppet, а на каждой puppet ноде устанавливается foreman-proxy ( как я показал в статье ) и каждая прокси собирает данные о хостах и передает все на Foreman, а на там уже происходить управления хостами.
Как вы обеспечиваете однообразие и актуальность puppet-классов на разных puppet серверах?
Для этого и нужен git. На нем хранится манифесты и модули, которые одновременно при деплое разливаются на все сервера.
Спасибо. Если это не секрет фирмы и не под NDA, то как реализована доставка кода в puppet-server из git? При коммите в git, puppet-server сам узнаёт об этом и обновляет модули, или вы нажимаете deploy в ci-пайплайне и код отправляется на puppet-server?
У себя уже довольно давно изобретаем велосипеды на эту тему, пока всё сводится к тому, что пулим скриптом код из гита на каждом puppet-server и надеемся, что код доехал и доехал актуальный. Иногда возникают коллизии, но на этот случай прикрутили другой скрипт, который сверяет хеши коммита в модуле на puppet-server и в git.
как реализована доставка кода в puppet-server из git
Схема не сложная, мы реализовали так:
- раннер подняли с докером
- используем ансибл докер который собирает папку code(/etc/puppetlabs/code) которая лежит в git и пушит ее на все сервера puppet рекурсивно (чтобы папка code на git была идентична папке на сервере)
Мне для общего развития. У вас в рейдах вы видите состояние каждого отдельного диска какими средствами?
Если вы про сервера puppet, то это виртуалки и рейдов там нет, если вы про агентов, то это в основном хосты без рейдов, потому что linux desktop, но вопрос интересный)
А вообще у foreman есть факты которые он собирает с хоста, то есть что видит хост то видит foreman, из этой логики скорее всего он не увидит рейд железный, но возможно увидит рейд программный.
Я просто недавно отвечал в теме про сервера Линукс и выяснил этот момент. Я знаю вин и аппаратные средства НР. На уровне пятилетней давности. И для меня было открытые, что в коммерции на Линукс этот вопрос не решён в одном конкретном случае. Поэтому решил поспрашивать. У вас видимо тоже такой возможности нет. На массмаркетовом железе. Спасибо.
Мне этот фореман очень запомнился тем что ломался после каждого обновления
А ansible-pull кто нибудь пробовал? На серверах или десктопах?
Как мы построили отказоустойчивую open-source-инфраструктуру для управления пользовательскими Linux-устройствами