В инструментах управления конфигурацией, таких как Puppet, меня смущает то, что они великолепны и просты для настройки сервера с нуля, но каждая документация игнорирует тот случай, когда у меня есть существующие данные (например, база данных PostgreSQL), которые я хочу использовать на новый подготовленный сервер.
Прекрасный пример - миграция между хостинг-провайдерами. Конечно, Puppet настроит новый сервер с (почти) той же конфигурацией, что и предыдущий, но код настройки (манифесты Puppet) предполагает, что этот новый сервер базы данных находится в стадии зарождения, тогда как есть ценные бизнес-данные, которые необходимо восстановить.
Первоначальную настройку инфраструктуры, безусловно, стоит автоматизировать, но случаются аварии, и когда возникает необходимость в восстановлении сервера, я остаюсь с полу-ручной настройкой:
Это не может быть такой уж редкостью. Первоначальная настройка серверов без существующих данных - это одноразовое событие, но их восстановление может происходить много раз, и я уверен, что это произойдет хотя бы один раз (поэтому мы делаем резервные копии ценных данных).
Какова обычная практика написания манифестов Puppet для решения сценария, при котором узел может быть настроен во второй раз и ему необходимо восстановить данные?
Как вы справляетесь с миграцией серверов, управляемых Puppet?
Погуглить это безнадежно. Вы в основном сталкиваетесь со страницами, описывающими, как восстановить Puppet DB / server, но эта часть инфраструктуры в основном не то, от чего ваш бизнес приносит прибыль, верно?
Я понимаю, что у Puppet-сервера есть файловый сервер, но сохранение резервных данных на нем и установка надлежащего контроля доступа кажется очень утомительной по сравнению с управлением конфигурацией с помощью манифестов Puppet.
Я предполагаю, что предприятия используют решения для полного сетевого резервного копирования, такие как Bacula или Amanda, или, возможно, пользовательские решения для резервного копирования на основе Borg, Restic, Burp, Duplicati или простого rsync. Вы интегрируете их в свои манифесты Марионеток? Как?
Если вы сделаете это для полностью автоматического аварийного восстановления, это может иметь смысл, но в противном случае вам нужно подумать о том, действительно ли вы сэкономите что-нибудь, вложив значительное количество времени, необходимое для надежной (!) Автоматизации того, что должно быть очень редким. -off операция (если вам нужно делать это все время, что-то не так в вашей среде). Наличие Puppet не означает, что вам нужно все автоматизировать любой ценой ...
Тем не менее: если вам это нужно, это несложно: просто имейте решение для резервного копирования, которое поддерживает выполнение этого из Puppet - эта поддержка может быть просто запуском сценария, который делает то, что вы делали бы вручную, в противном случае внутри запуска Puppet (обязательно запустите это только один раз ...).
Использование инструментов управления конфигурацией (CM), таких как Puppet, Ansible, Chef или Salt, требует фундаментальных изменений в вашем подходе к настройке.
Если вы думаете о конфигурации как о единовременном событии, вы никогда не увидите (или не поймете) какой-либо выгоды от использования CM.
Основное преимущество CM - это возможность выразить желаемую конфигурацию в виде кода. Как только у вас появится такая возможность, конфигурация вашего сервера будет следующей:
Проверяемый. Вы можете писать модульные тесты, чтобы убедиться, что вы не вносите никаких ошибок, и все это без перезапуска службы или подготовки всей тестовой / промежуточной среды. Это экономит много времени и денег.
Воспроизводимый. Вы можете создать один сервер, два сервера, десять серверов или сотню серверов, используя одну и ту же базовую конфигурацию, без дополнительных затрат. Вы пишете код один раз и применяете его много раз. Если у вас есть стандартный набор параметров конфигурации (например, настройки демона SSH, шаги по усилению защиты), CM может их автоматизировать.
Версионный. Развернуть изменение так же просто, как сделать коммит Git. Прокатка назад изменение так же просто, как git revert. У вас есть проверяемый, доступный для аудита источник данных (ваша история Git). Вы можете разветвлять свою кодовую базу CM, вносить изменения, получать экспертную оценку и объединять эти изменения в свой master филиал.