(Заранее извиняюсь за глупость этого вопроса. Я обычно программист, а не системный администратор, но я взял на себя задачу автоматизировать некоторые вещи и привести в порядок некоторые другие вещи, которые автоматизированы, но не самым лучшим образом. :-)
Я рассматривал различные инструменты для автоматизации развертывания программного обеспечения на нескольких серверах, такие как cfengine, Puppet и Chef. Пока что Puppet выглядит наиболее привлекательным, но я пока ничего не решил.
Похоже, что все эти инструменты способны отлично справляться с поддержанием актуальности данных на нескольких серверах.предварительно упакованныйпрограммное обеспечение.
Чего я не понимаю, так это: как можно использовать инструмент (например, Puppet) для управления развертываниями нашего собственного внутреннего программного обеспечения? Я думаю, что я в растерянности, потому что я видел тысячу руководств, показывающих, как поддерживать Apache ensure => latest(которыйявляетсядовольно круто), но ничего, что соответствовало бы моему сегодняшнему варианту использования, который больше похож на:
- когда человек нажимает кнопку,
- извлечь ветку A из репозитория контроля версий B
- выполните команду C, чтобы скомпилировать его
- скопировать двоичные файлы D на серверы E1–E10
- на каждом сервере выполните команду F, чтобы все изменения вступили в силу
Puppet звучит здорово, и я полностью вижу преимущество декларативной, идемпотентной конфигурации по сравнению с некоторыми скриптами оболочки, но я не видел никаких руководств по теме «вы хотите обновить свои скрипты оболочки до Puppet (или Chef, или cfengine), поэтому вот что вам следует сделать». Существует ли такое? Очевидно ли для других людей, как взять то, что предоставлено в документации Puppet, и воспроизвести нужное мне поведение? Я просто не понимаю?
На данный момент мне кажется, что человек (№ 1) вручную упаковал бы программное обеспечение (№ 2 и № 3), внешнее по отношению к Puppet, вручную обновил бы конфигурацию Puppet, что заставило бы Puppet обновить серверы... может быть? (Я немного запутался, и, я уверен, вы это заметили.)
Спасибо!
решение1
Мы используем puppet, но не используем его для развертывания наших приложений. Как вы сказали, вы можете упаковать свое программное обеспечение в deb или rpm, настроить свой личный репозиторий везде и использовать puppet для управления версиями, но вы все равно будете вынуждены ждать следующего 30-минутного обновления на всех ваших серверах.
Что бы я сделал (и это близко к тому, что делаем мы, но мы используем rails, поэтому нет этапа компиляции):
- Используйте puppet для настройки всего на сервере, кроме самого приложения. Зависимости, веб-серверы, пользователи, пути и т. д.
- Пусть ваш автоматизированный сервер сборки (bamboo, hudson, cruise control и т. д.) поместит скомпилированные артефакты в менеджер репозиториев, например Nexus.
- Используйте Capistrano для загрузки сборки на свои серверы.
У Chef, возможно, больше возможностей push-уведомлений в реальном времени; я с этим не очень знаком.
решение2
Шаги 1–3 обычно автоматизированы в процессе сборки. Обычно выходные данные этого процесса проходят цикл тестирования. Я упаковываю выходные данные, чтобы их можно было развернуть в среде интеграционного тестирования. Только если интеграционные тесты пройдены, должны выполняться шаги 4 и 5.
Ваш шаг 5 подразумевает сбой развертывания. Для чего-то вроде apache это можно обработать выключением и перезапуском во время ротации журнала. Скрипт crontab может это сделать. Если вы можете обрабатывать скользящие изменения в течение часа или около того, просто включите перезапуск в шаг развертывания 4. Puppet или cfengine являются подходящими инструментами для шага 4. Это можно запустить, обновив репозиторий после прохождения интеграционных тестов.
решение3
Поищите рецепты puppet, и вы найдете тонны готовых к производству скриптов. Да, вам придется вручную упаковывать программное обеспечение. Если вы ведете свой собственный личный репозиторий, то вы можете использовать флаг ensure=>latest. Затем напишите рецепт, чтобы указать puppet установить программное обеспечение. Рецепт должен быть размещен на главном сервере, откуда он будет распространяться на подчиненные.