Всем доброго времени суток.
Я работаю системным администратором в небольшой компании myhotspot, занимающейся различными разработками в сфере IT, в том числе на ruby on rails. Естественно приходится часто устанавливать и администрировать виртуальные сервера, для чего мы с успехом используем Puppet. На Хабре уже писали про Puppet (Как стать кукловодом или Puppet для начинающих или Puppet под нагрузкой), но не описали того, о чем на мой взгляд очень важно сказать. Суть проблемы, которую я хочу описать в процессе перехода на автоматическую систему управления конфигурациями серверов под названием Puppet. О том как это проще сделать, чем нужно руководствоваться, чего стоит опасаться и как жить дальше.
Почему именно Puppet?
Многие уже слышали о нем, но немногие его используют. Многие скажут что он не нужен, я не раз уже слышал, что есть скрипты деплоя написанные нашим старшим Дядей Васей, или chef, или python Fabric, в конце концов человека ничто не заменит и я сам все сделаю! Каждое из этих мнений правильное, но мы просто решили, что надо развиваться и попробовать максимально автоматизировать и упростить установку, управление серверами с помощью Puppet. Еще одним не менее важным акцентом в пользу Puppet стало то, что у нас ruby ориентированная компания и наши программисты в случае чего смогут помочь админам в той или иной ситуации.
В чем суть проблемы?
Представьте себе компанию имеющие 10-12 виртуалок на каждой из которых крутиться 5-6 проектов с различными базами данных (mysql, mongo, postgres) и постоянно нужно производить покупку и установку новых виртуалок, проектов. Добавим необходимость все это бэкапить и получится достаточно большой объем работы. И вот прочитав о Puppet и его возможностях, собравшись с духом, вы таки решили переводить все сервера на Puppet. С чего начать? Как поступить так, чтобы архитектура работы ваших серверов была максимально эффективной и безопасной? Я не буду говорить о том, как устроен puppet и как он работает (на хабре уже были статьи на эту тему и гуглом я верю вы умеете пользоваться) я расскажу несколько советов при которых переход на него будет безболезненным и быстрым.
Документация
Первое что необходимо сделать — это проверить документацию ваших серверов. Если вы ее еще не делали, настоятельно рекомендую это сделать, что облегчит жизнь вам и вашим соотечественникам программистам. Документация должна помочь вам понять, какие модули Puppet вам нужны(rbenv, nginx) и как поступить в том или ином случае при написании манифестов для Puppet. Документация должна содержать максимально подробную информацию о том что, откуда, на каком сервере установлено и как настроен сам сервер.
Запись вида «nginx from ppa» уже поможет вам понять, что в случае с Puppet (например include nginx ) вы должны учитывать возможность автоматической установки nginx из ppa. Нужен план какие манифесты разрабатывать в первую очередь и что понадобится в перспективе.
Где Puppet master?
1) Puppet master должен стоять на самом отказоустойчивом и безопасном сервере что у вас есть. Почему? Потому что Puppet master содержит информацию о всех ваших серверах, что где находится, пароли и самое важное, что с помощью puppet злоумышленник может выполнять exec с любой командой от root на любом подключенном к Puppet master сервере. Мы держим его на amazon на самой маленькой и дешевой (в 1 год она бесплатна ) виртуалке и он ежедневно бэкапится.
2) Советует держать директорию Puppet с конфигами/манифестами (например /etc/puppet для ubuntu) в truecrypt контейнере. Зачем? Все за тем же, с целью обеспечения безопасности. В случае перезагрузки или несанкционированного проникнования по паролю или public key вы закрываете контейнер и все, радуетесь, что ваши серваки подключенные к puppet master еще живы.
Тестирование. Подключаем клиентов
Итак, вы установили Puppet master, сделали скрипт для его бэкапов и держите в контейнере все конфиги/манифесты, значит пришло время подключать Puppet agent на сервера. Первое что нужно обязательно сделать — это установить чистый, маленький виртуальный сервер для тестов! Внедрять production манифест описывающий, например, установку apache лучше только после долгих испытаний. Благодаря этому вы сможете избежать много неприятностей и облегчите разработку манифестов/модулей/скриптов для Puppet master. По поводу скриптов, если у вас есть скрипты для установки чего-либо (например mysql-server или mongodb) не торопитесь выкидывать их на помойку! Наиболее правильным переходом с вашего старого способа администрирования на новый, станет хранение этих скриптов на Puppet master с последующем выполнением их на клиенте c помощью Puppet master и exec…
Свой git server
А как же github?bitbucket? Да это надежные и правильные пути, но к сожалению и на них есть различные уязвимости, позволяющие получить доступ к вашему репозиторию с манифестами Puppet. Поэтому я настоятельно рекомендую держать все конфиги/манифесты на своем git сервере.
На данный момент наша компания готовит свой public репозиторий с готовыми модулями, документацией, для управления серверами, чтобы сделать жизнь остальным системным администаторам проще.
Автор: ximyro
