Мы сталкиваемся с интересным спором и распадаемся на два лагеря. Меня интересуют конкретные проблемы, связанные с идеей или ошибками, которые мы можем упустить. На самом деле все, что может помочь нам принять решение или указать на вещи, которые мы не учитываем. Я немного знаю, что это обходится без правила «не мнения», но я надеюсь, что это все еще приемлемый вопрос. Извините за длину, но есть немало нюансов.
1) Одна сторона (моя - я не без предвзятости) находит модель неизменяемого сервера очень интересной для облачных систем. С этой целью мы прототипировали перемещение всех компонентов нашей инфраструктуры в Docker. Наши пользовательские приложения собираются через Jenkins непосредственно в образы Docker, которые развертываются в локальном реестре Docker. Затем мы создали большой набор ролей Ansible и playbook, который способен подключиться к пустому серверу, установить Docker, а затем сказать Docker, что нужно установить все контейнеры по мере необходимости. Через пару минут все приложение и вся поддерживающая его инфраструктура подключены и работают - ведение журнала, мониторинг, создание / заполнение базы данных и т. Д. Готовая машина представляет собой автономную среду контроля качества или разработки с точной копией применение. Наш план по масштабированию этого заключается в том, чтобы создать новые Playbooks для создания новых серверов AWS из базового доверенного AMI (вероятно, очень простой образ), выполнить скользящее развертывание рабочего приложения для управления конфигурацией и выпусками и, как правило, никогда больше не редактировать серверы просто сделай их заново. Я не беспокоюсь о том, чтобы то, что я описал, работало на практике - просто если это разумная модель.
2) Другой лагерь хочет использовать Puppet для управления конфигурацией, Ansible для развертывания наших пользовательских приложений, которые представляют собой тарболы, созданные в процессе сборки, Foreman для обработки запуска и управления процессом в целом и Katello для выполнения некоторого базового управление изображениями. Релизы будут включать изменение конфигурации Puppet по мере необходимости и развертывание обновленных компонентов Ansible с некоторой степенью координации Foreman. Серверы были бы построены достаточно быстро, если бы нам потребовались новые, но цель не в том, чтобы сделать их одноразовыми в рамках стандартного процесса. Это ближе к модели сервера Phoenix, хотя и с долгим сроком службы.
Итак, мой вопрос действительно сводится к следующему: действительно ли модель неизменяемого сервера с инструментами, как я их описал выше, настолько реалистична, как кажется? Мне нравится идея, что наш промежуточный процесс может буквально создавать полный клон приложений в реальном времени, позволяя QA забивать его, а затем просто перевернуть хранилище базы данных и некоторые настройки DNS, чтобы заставить его работать.
Или на практике модель неизменного сервера дает сбой? У нас есть большой опыт работы как с AWS, так и с облачными средами, так что это не совсем проблема - скорее вопрос о том, как надежно развернуть достаточно сложное приложение в будущем. Это особенно интересно, поскольку мы выпускаем довольно часто.
У нас есть Ansible, который делает большинство необходимых вещей, кроме фактического создания серверов EC2 для нас, и это не сложно. Мне сложно понять, зачем вам вообще НУЖНА Марионетка / Бригадир / Кателло в этой модели. Docker намного чище и проще, чем пользовательские сценарии развертывания в любом инструменте, который я могу сказать. Ansible кажется намного проще в использовании, чем Puppet, когда вы перестаете беспокоиться о необходимости настраивать их на месте и просто собираете их заново с новой конфигурацией. Я поклонник принципа KISS, особенно в области автоматизации, где действует закон Мерфи. ИМО, чем меньше машин, тем лучше.
Будем очень признательны за любые мысли / комментарии или предложения по подходу!
В нашей компании мы успешно внедрили Puppet в унаследованную инфраструктуру клиента. Мы также используем контейнеры Docker для запуска специальной службы (которая на самом деле представляет собой старое приложение, обрезанное и скрученное, чтобы поместиться в контейнеры).
Я не был доволен контейнерами, когда впервые начал работать с ними (да ... приложение размером 30 КБ становится тяжелым изображением на 200 МБ), но когда мне пришлось воссоздавать всю среду после небольшой катастрофы, я передумал. Думаю, Docker был придуман именно для этого: быстрое и частое развертывание без забот о конфигурации сервера. Если вы правильно спроектируете контейнеры, вы сможете легко переключаться между облачными провайдерами, ноутбуками разработчиков и центрами обработки данных для совместного размещения. Потому что все, что вам нужно, это ванильный Linux-бокс с демоном Docker.
Я также использовал Puppet в своем предыдущем проекте, и мой опыт показывает, что неизменяемый сервер может быть реализован скорее с помощью Docker, чем Puppet или Chef. Я считаю, что инструменты управления конфигурацией более полезны для поставщиков облачных услуг, чем для команды разработчиков.
Вот мои 2 цента евро.
Предлагаемые вами 2 варианта являются допустимыми для достижения (некоторой) неизменности.
Я думаю, вам следует выбрать тот, с которым вам удобнее.
Однако из того, что вы пишете, кажется, что консенсуса еще нет.
Может, тогда потребуется третий вариант? ;)
Однако неизменность как таковая - это не цель, а средство обеспечения других свойств (отсутствие дрейфа конфигурации, лучшая стабильность, ...).
Я бы четко сформулировал свои цели, поставил несколько показателей для их проверки и провел несколько тестов, используя 2 варианта. Затем у вас будет несколько цифр, чтобы выбрать ту, которая больше всего соответствует вашему бизнесу.
Удачи!