В частности, если вы используете средство шаблонизации серверов, такое как Docker или Packer, оно уже покрывает большинство ваших нужд, связанных с управлением конфигурацией. После создания образа из Dockerfile или шаблона Packer вам остается лишь инициализировать для него инфраструктуру, здесь лучше всего подходят средства инициализации ресурсов.
Тем не менее, если вы не применяете инструменты для шаблонизации серверов, хорошей альтернативой будет связка из средств управления конфигурацией и инициализации ресурсов. Например, вы можете инициализировать серверы с помощью Terraform и затем запустить Chef, чтобы сконфигурировать каждый из них.
Выбор между изменяемой и неизменяемой инфраструктурой
Обычно в средствах управления конфигурацией, таких как Chef, Puppet, Ansible и SaltStack, по умолчанию применяется парадигма изменяемой инфраструктуры. Например, если приказать Chef установить новую версию OpenSSL, процесс обновления ПО запустится на существующем сервере, где и произойдут все изменения. Со временем обновления накапливаются, а вместе с ними и история изменений сервера. В итоге у каждого сервера появляются небольшие отличия по сравнению со всеми остальными серверами, что приводит к неочевидным ошибкам в конфигурации, которые трудно диагностировать и воспроизводить (та же проблема с дрейфом конфигурации, возникающая при ручном управлении серверами, хотя благодаря средствам управления конфигурацией у нее куда менее серьезные последствия). Их сложно обнаружить даже с использованием автоматических тестов. Измененная конфигурация может нормально работать в ходе тестирования и при этом вести себя совсем иначе на боевом сервере, который, в отличие от тестовой среды, месяцами накапливал обновления.
Если вы применяете средства инициализации ресурсов наподобие Terraform для развертывания системных образов Docker или Packer, большинство изменений будет заключаться в создании совершенно новых серверов. Например, чтобы развернуть новую версию OpenSSL, вы включаете ее в новый образ Packer, который развертывается на группе новых узлов, а затем удаляете старые узлы. Поскольку при каждом развертывании используются неизменяемые образы и свежие серверы, этот подход уменьшает вероятность дрейфа конфигурации, упрощает отслеживание того, какое ПО установлено на каждом сервере, и позволяет легко развернуть любую предыдущую версию ПО (любой предыдущий образ) в любой момент. Это также повышает эффективность вашего автоматического тестирования, поскольку неизменяемый образ, прошедший проверку в тестовой среде, скорее всего, будет вести себя аналогично и в промышленных условиях.
