Подходят ли инструменты управления конфигурацией для использования в качестве инструментов развертывания?

В конце моего ответа на вопрос: Как DevOps может помочь улучшить процедуры условного депонирования? У Тенсибая возник вопрос:

Что может понадобиться Капистрано поверх марионетки или шеф-повара?

Мой ответ состоял в том, чтобы опубликовать ссылку на статью Ноа Гиббса "Нужны ли нам и Капистрано, и шеф-повар?" , Лично я все же согласен с мнением Ноа, что наиболее уместно:

• Для развертывания используйте специальный инструмент развертывания, такой как Capistrano.
• используйте специальный инструмент управления конфигурацией, такой как Chef, для управления конфигурацией.

Фундаментальный подход, который использует каждый тип инструмента для выполнения своей задачи, очень отличается:

• Инструменты управления конфигурацией - это создание и поддержание желаемого состояния системы, они по своей природе идемпотентны. Примерами инструментов управления конфигурацией являются Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

• Средства развертывания - это доставка версий программного обеспечения в среду хостинга, они предоставляют функциональные возможности для поддержки нескольких версий программного обеспечения на нескольких машинах и управления тем, какая версия является «текущей», они по своей природе являются обязательными по своей природе. Примерами средств развертывания являются Capistrano , Octopus Deploy , Deployer и Command.io .

Я действительно считаю, что инструменты управления конфигурацией могут выполнять работу инструментов развертывания, и в случае неизменяемой инфраструктуры они являются наиболее подходящим инструментом для этой работы, поскольку не нужно поддерживать версии программного обеспечения на целевом объекте.

Вопрос: Достигли ли инструменты управления конфигурацией, такие как Chef, Ansible и Puppet, настолько, что они способны выполнять как идемпотентные, так и императивные модели?

В таком контексте типичный совет должен быть немедленно применим: используйте правильный инструмент для работы.

Но тогда вы также не можете игнорировать в наше время почти вирулентную тенденцию программных инструментов расширять функциональность в более или менее смежные области и фактически становиться наборами инструментов по разным причинам: иметь отличные функции, расширять клиентскую базу, получать больше прибыли и т. Д.

Например, многие инструменты управления файлами включают функции просмотра изображений, а многие инструменты обработки изображений включают функции управления файлами. Вы можете перемещать файлы и просматривать изображения с помощью любого из инструментов, часто одинаково хорошо.

Из-за этого вполне возможно, что целые части процесса разработки программного обеспечения покрываются / перекрываются несколькими инструментами (наборами), даже если их основная функция / возможности отличаются.

Так что это действительно сводится к той функциональности, которую вы хотите достичь в вашем конкретном процессе, и к тому, насколько хорошо тот или иной инструмент выполняет работу в вашем контексте . Субъективность / предпочтения / удобство включены.

Делать этот вопрос в первую очередь основанным на мнении;)

Инструменты управления конфигурацией используются для приведения системы в известное состояние. Инструменты развертывания развертывают новые программные файлы и программные данные в системе. В конце концов, оба типа инструментов делают некоторую комбинацию:

• Определите текущее состояние системы.
• Передача файлов в систему.
• Добавить или изменить постоянные данные (например, файлы конфигурации, данные базы данных, параметры реестра)
• Запустите или перезапустите программы.

Инструменты управления конфигурацией имеют декларативные языки, которые определяют состояние системы. Инструменты развертывания имеют обязательные языки, которые заставляют систему что-то делать. Человек DevOps должен сделать оба.

Используя инструмент развертывания Capistrano, неуклюже использовать свой язык, чтобы сообщить системе, что веб-сервер активен. Вы должны выполнить команду для перезапуска веб-сервера, а другую - для проверки работоспособности веб-сервера. Это вызов для перевода веб-сервера в известное состояние.

Используя инструмент управления конфигурацией Ansible, перезапустить веб-сервер неудобно. Язык позволяет сообщать веб-серверу о том, что он «включен», но если вы хотите, чтобы он был перезапущен, вы должны установить его состояние «перезапущено». Но нет простого способа проверить, был ли перезапущен веб-сервер. Это помеха в Ansible для включения одноразовых операций.

Некоторые люди предпочитают выполнять оба типа работ с помощью одного инструмента и обходить неровные края. Другие люди предпочитают иметь два инструмента, чтобы сделать почти то же самое, но без грубых краев. Чтобы ответить на вопрос, «уместность» - дело вкуса. Этот ответ объясняет почему.

TL; DR : Просто используйте Ansbile, это как инструмент настройки и развертывания :)

Существует несколько типов развертывания:

• Приложение на основе (файлы, архивы пакетов)

• На основе контейнеров (включает виртуальные машины, среду обитания, LXC, Docker)

• На основе функций (Микро услуги / Лямбда / Функции)

Я предполагаю, что в этом случае мы говорим только об обновлениях приложений на серверах.

Для развертывания вам необходимо выполнить две вещи:

1. Правильные файлы или пакеты необходимо перенести на сервер.
2. Конфигурация и сервисные состояния должны измениться.

Теперь для (1) вы можете использовать несколько стратегий:

• Хранилища артефактов / Синхронизация
• Репозитории пакетов / Менеджеры пакетов
• Система контроля версий / Обновление + Компиляция (опционально)
• Протоколы передачи файлов (scp, rsync, ftp)
• Инструменты развертывания

Для (2) вы можете использовать:

• Инструменты управления конфигурацией
• Инструменты развертывания

Таким образом, хотя инструменты развертывания представляют собой один из способов развертывания, они не всегда являются лучшей стратегией. Иногда вы хотите использовать комбинацию этих способов для развертывания. Скорее всего, вы уже используете менеджеры пакетов, по крайней мере, на своих серверах. Скорее всего, вы все равно запускаете инструменты настройки. Проблема с некоторыми инструментами конфигурации заключалась в правильном согласовании между несколькими серверами, но теперь даже Chef и Puppet могут делать это довольно хорошо. Ansible всегда был хорош в этом.

Исходя из личного опыта , я использовал все комбинации, но в настоящее время мы используем Capistrano для развертывания и Ansible sync для управления конфигурацией, а также VCS и репозитории пакетов для передачи файлов, но есть проблемы с Capistrano, и мы планируем перейти от него к Unify на Ansible для развертывания, обслуживания и управления конфигурацией.

Развертывание приложения сложно определить, так как в нем много подзадач. Системы управления Config превосходны в задачах моделирования, которые сходятся и работают с «каково желаемое состояние системы». В контексте развертывания приложений это отлично подходит для таких вещей, как развертывание битов на машине, управление файлами конфигурации и настройка системных служб. То, для чего это крайне плохо, - это процедурные вещи, в частности миграция баз данных и перезапуск служб. Я обычно пытаюсь поместить сходящуюся логику в Chef и позволить внешнему процедурному инструменту (обычно в моем случае это Fabric) обрабатывать несколько оставшихся битов, а также упорядочивать фактические сходящиеся значения.

Так что, в принципе, вы должны использовать обе части, для которых они лучше всего подходят.

Для программного обеспечения и развертывания кода на существующем сервере или в контейнере Docker ответ относительно прост: нет, вам не нужно и то, и другое, но вам может потребоваться и то и другое, если другой инструмент или утилита добавляет ценность и является подходящим инструментом для работы. Однако все становится сложнее при развертывании серверов и операционных систем.

Одним из преимуществ менталитета DevOps является обработка инфраструктуры как кода и частое развертывание или уничтожение виртуальных машин или даже «голого железа» в высокоэластичной среде. Ваша система управления конфигурацией не может легко загружать по сети и запускать ваш сервер для вас, а также не может управлять репозиториями, пакетами и обновлениями / исправлениями для вас во время и после развертываний или, в некоторых случаях, лицензирования и предоставления прав.

Для Amazon Web Services по большей части это довольно удобно для управления через API, но для тех из нас, кому приходится управлять собственными дата-центрами, это не вариант. По этой причине проект Foreman (и Red Hat, который переименует его ) сочли необходимым объединить вместе Katello , Candlepin и менеджер конфигурации, такой как Ansible, Foreman или Puppet, при развертывании сценария Katello .

Таким образом, хотя вы можете обойтись без использования инструментов управления конфигурацией для развертывания программного кода на стороне разработчика, а на стороне Ops, есть несколько случаев, когда ответ звучит громко: нет, инструменты управления конфигурацией не Уместно использовать в качестве инструментов развертывания "Это потребует серьезного переосмысления колеса и нецелесообразно. Вместо этого вы должны использовать свои инструменты управления конфигурацией, чтобы начать развертывание в другом инструменте.