Мы сталкиваемся с интересным аргументом и попадаем в два лагеря. Я заинтересован в каких-либо конкретных проблемах с идеей или ошибками, которые мы могли бы пропустить. На самом деле, все, что может помочь нам принять решение или указать на вещи, которые мы не учитываем. Я знаю, что это немного противоречит правилу «нет мнения», но я надеюсь, что это все еще приемлемый вопрос. Извините за длину, здесь есть немало нюансов.
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 - особенно в области автоматизации, где действует закон Мерфи. Чем меньше машин, тем лучше ИМО.
Любые мысли / комментарии или предложения по поводу подхода будет принята с благодарностью!
Ответы:
В нашей компании мы успешно внедрили Puppet на устаревшей инфраструктуре заказчика. Мы также используем контейнеры Docker для запуска выделенного сервиса (который на самом деле является старым приложением, урезанным и скрученным для встраивания в контейнеры).
Я не был доволен контейнерами в первый раз, когда начал работать с ними (да… приложение размером 30 КБ становится тяжелым изображением размером 200 МБ), но когда мне пришлось воссоздать всю среду после небольшой катастрофы, я передумал. Я думаю, что Docker был изобретен именно для этого: быстрое и частое развертывание без забот о конфигурации сервера. Если вы правильно проектируете контейнеры, вы можете легко переключаться между облачными провайдерами, разработчиками ноутбуков и центрами обработки данных. Потому что все, что вам нужно, это ванильный Linux-пакет с демоном Docker.
Я также использовал Puppet в своем предыдущем проекте, и мой опыт показывает, что неизменный сервер достигается скорее с помощью Docker, чем Puppet или Chef. Я считаю, что инструменты управления конфигурацией более полезны для облачных провайдеров, а не для команды разработчиков.
источник
Вот мои 2 евроцента.
2 варианта, которые вы предлагаете, являются допустимыми для достижения (своего рода) неизменности.
Я думаю, вы должны выбрать тот, который вам удобнее.
Однако из того, что вы пишете, кажется, что консенсуса пока нет.
Возможно, третий вариант требуется тогда? ;)
Однако, как таковая неизменность является не целью, а средством обеспечения других свойств (отсутствие смещения конфигурации, лучшая стабильность, ...).
Я четко сформулировал свои цели, поставил некоторые метрики для их проверки и провел несколько тестов, используя 2 варианта. Тогда у вас будет несколько цифр, чтобы выбрать ту, которая наиболее соответствует вашему бизнесу.
Удачи!
источник