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