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