Здесь, в Braintree, мы большие поклонники Puppet для системного администрирования. В нашей постоянно меняющейся инфраструктуре Puppet позволяет нам быстро предоставлять и повторно предоставлять серверы в различных средах. Мы также большие поклонники поддержания нашей инфраструктуры простой и простой. Каждая часть инфраструктуры, которую мы должны поддерживать, имеет свою стоимость. Мы воспользовались недооцененной функцией Puppet, которая позволяет нам полностью управлять нашими серверами.
Преимущества идти без хозяина
- Детальный контроль Мы гордимся своей способностью поддерживать наш сайт в актуальном состоянии. Используя Puppet без мастера, мы жестко контролируем, как конфигурация применяется к серверу.
- Распараллеливание С централизованным сервером Puppet сервер поддерживает единственную каноническую версию конфигурации Puppet. Это вызывает конфликт, когда несколько человек пытаются внести изменения одновременно. Без мастера репозиторий системы управления версиями поддерживает каноническую версию, поэтому люди могут легко работать параллельно, если они не пытаются использовать один и тот же сервер.
- Нет единой точки отказа Запуск Puppet master — это еще один сервис, который нужно поддерживать и обеспечивать высокую доступность. Имея на одну услугу меньше, чтобы применить нашу типичную строгость HA, это большая победа.
Гайки и болты
Чтобы упростить нашу настройку без мастера, мы написали небольшой гем под названием supply_drop . Это набор задач capsitrano, которые позволяют вам предоставлять серверы с Puppet. Он пытается быть маленьким, простым и держаться подальше от вашего пути. Есть две задачи, которые делают основную часть работы. марионетка с крышкой: петля и марионетка с крышкой Noop покажет вам набор изменений, которые будут применены. Как вы могли догадаться, задача применения вносит эти изменения в поле. supply_drop использует rsync для передачи текущей конфигурации Puppet с вашего устройства на сервер, что делает ее очень быстрой.
Мы используем настройку, аналогичную многоэтапному ограничению, для управления областью применения изменений. Мы динамически создаем задачи для каждого сервера и среды, которые у нас есть. Вот пример того, как это выглядит
def tasks_for_datacenter(datacenter, servers)
task datacenter do
role :server, *servers
end
servers.each do |server|
task server do
role :server, server
end
end
end
tasks_for_datacenter :sandbox, %w(app1.sand db.sand)
tasks_for_datacenter :production, %w(app1.prod app2.prod db.prod)
Эти задачи позволяют нам применять изменения к одному серверу или всему центру обработки данных. Мы также можем использовать расширения оболочки, чтобы легко вносить изменения в подмножество серверов в данной среде. Несколько примеров:
- cap app1.prod puppet: noop показывает изменения в app1
- cap the sandbox puppet: apply применяет текущие изменения ко всем песочнице
- cap app {1,2} .prod puppet: apply применяет изменения к app1.prod и app2.prod
Рабочий процесс
Мы всегда ищем способы улучшить наш рабочий процесс, но в целом мы довольны тем, что имеем сейчас. Наши цели:
- Легко позволяйте нескольким людям вносить изменения в окружающую среду
- Проявите явное продвижение от QA до Sandbox для Production
- Сохраняйте все изменения в управлении исходным кодом, не делая журналы слишком шумными
Мы используем отдельную ветку git для каждой среды (QA -> master, Sandbox -> sandbox, Production -> production). Это позволяет нам продвигать изменения путем слияния ветвей. Кроме того, если нам нужно сделать быстрое исправление в Production, мы можем использовать эту ветвь и не влиять на Sandbox или QA до слияния. Я расскажу о нашем рабочем процессе, добавив в качестве примера новое предупреждение Nagios для Apache.
Напишите скрипт Nagios и отправьте его на веб-сервер в QA. Повторяйте, пока не будете счастливы с этим.
cap web01.qa puppet:noop cap web01.qa puppet:apply
Разместите скрипт на всех веб-серверах в центре обработки данных.
cap web0{1..n}.qa puppet:noop
cap web0{1..n}.qa puppet:apply
Измените конфигурацию центрального сервера Nagios, чтобы узнать о новом предупреждении
cap monitor.qa puppet:noop <span class="c"># Some scary changes</span>
О, хватит. Есть разница, о которой мы не знаем. Кто-то еще добавляет предупреждение Nagios. Не беспокойтесь, они уже зарегистрировались. Мы берем их изменения и пытаемся снова.
git stash git pull origin master git stash pop cap monitor.qa puppet:noop cap monitor.qa puppet:apply
Оповещение работает. Теперь мы включаем всю среду для изменений и фиксируем наши изменения. Если наш noop показывает, что мы собираемся удалить некоторые другие изменения в дополнение к нашим собственным, мы поговорим с этими разработчиками и дадим им знать, что мы сделали, и что им нужно будет извлечь из git.
git commit -am "new nagios check"
Теперь мы хотим перенести изменения в Песочницу. Поскольку мы используем git, мы можем либо объединить все изменения с master, либо просто выбрать наш единственный коммит, если есть другие вещи, которые еще не готовы.
git checkout sandbox git merge master
Затем примените изменения к Песочнице. Мы можем сделать это на серверной основе или одним махом.
cap sandbox puppet:noop cap sandbox puppet:apply
Повторите для производства. Объявите победу.
В заключении
supply_drop и Puppet позволяют нам точно контролировать, как мы применяем изменения к любому серверу в любом из наших центров обработки данных. Сопоставление его с git и достойный рабочий процесс дает вам проверяемое и повторяемое управление конфигурацией.