Как Docker и Ansible подходят для реализации Continuos Delivery/Continuous Deployment

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

Прежде всего, индивидуально, мне комфортно с AWS, я знаю, что такое Ansible, логика этого и его цель. У меня нет одинакового уровня понимания Docker, но я понял эту идею. Я прошел через множество интернет-ресурсов, но я не могу получить общую картину.

То, с чем я боролся, - это то, как они сочетаются. Используя Ansible, я могу управлять своей инфраструктурой как кодом; создание экземпляров EC2, установка пакетов... Я даже могу развернуть полное приложение, потянув его код, изменив конфигурационные файлы и запустив веб-сервер. Docker - это сам инструмент, который упаковывает приложение и гарантирует, что его можно запустить везде, где вы его развертываете.

Мои проблемы:

Как Docker (или Ansible и Docker) расширяют процесс непрерывной интеграции!?

Предположим, что у нас есть репозиторий исходного кода, члены команды заканчивают работу над функцией, и они продвигают свою работу. Дженкинс обнаруживает это, запускает все тестовые комплекты приемки/единицы измерения/интеграции, и, если они все прошли, он объявляет его как стабильную сборку. Как Docker подходит здесь? Я имею в виду, когда команда подталкивает их работу, Дженкинс должен вытащить источник файла Docker, закодированный в приложении, создать образ приложения, запустить контейнер и запустить все тесты против него или он запускает тесты классическим способом, и если все хорошо, тогда он создает изображение Docker из файла Docker и сохраняет его в закрытом месте? Если Дженкинс пометит конечное изображение, например, x.y.z!?

Конфигурация контейнеров докеров:

Предположим, что у нас есть изображение, построенное где-то Jenkins, как обрабатывать развертывание одного и того же изображения в разных средах и даже различные параметры конфигурации (конфигурация Vhosts, узлы базы данных, URL-адреса очередей, конечные точки S3 и т.д.). ) Каков самый гибкий способ решения этой проблемы без нарушения принципов Docker? Поддерживаются ли эти конфигурации в изображении при его создании или при запуске контейнера на основе его, если да, то как они вставляются?

Несвязанный и докер:

Ansible предоставляет модуль Docker для управления контейнерами Docker. Предполагая, что я решил проблемы, упомянутые выше, когда я хочу развернуть новую версию xtz моего приложения, я рассказываю Ansible, чтобы вытащить это изображение из того места, где оно было сохранено, запустите контейнер приложения, поэтому, как ввести параметры конфигурации!? Нужно ли Ansible регистрировать изображение Docker, прежде чем оно запустится (это звучит безумно для меня) и используйте его шаблоны Jinja2 так же, как и классический хост!? Если нет, как это обрабатывается?!

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

Пожалуйста, очень полезно прочитать ваши впечатления и решения, потому что это похоже на общий рабочий процесс. Заранее спасибо. Буду признателен за любую оказанную помощь.

Ответ 1

Я хотел бы ответить по частям

Как Docker (или Ansible и Docker) расширяют процесс непрерывной интеграции!?

Поскольку изображения докеров одинаковы везде, вы используете свои изображения докеров, как если бы они были производственными изображениями. Поэтому, когда кто-то совершил код, вы создаете образ докера. Вы проводите тесты против него. Когда все тесты проходят, вы соответствующим образом помечаете это изображение. Поскольку докер работает быстро, это допустимый рабочий процесс. Кроме того, изменения докеров изменяются; поэтому ваши изображения будут иметь минимальное влияние на хранение. Также, когда ваши тесты терпят неудачу, вы также можете сохранить это изображение. Таким образом, разработчик потянет это изображение и легко проверит, почему ваши тесты не удались. Разработчик может выбрать запуск тестов на своей машине, так как изображения докеров в дженкинсах и их машине не отличаются.

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

Конфигурация контейнеров докеров:

Если вы используете частный репозиторий, и вы должны его использовать, изменения конфигурации не будут сильно влиять на объем жесткого диска. Поэтому, кроме конфигураций безопасности, таких как пароли db, вы можете применить изменения конфигурации к изображениям докеров ( "Выпекать конфигурацию в контейнере" ). Затем вы можете использовать возможность использования не сохраненных конфигураций для развернутых изображений до/после запуска с использованием переменных окружения или томов докеров.

https://dantehranian.wordpress.com/2015/03/25/how-should-i-get-application-configuration-into-my-docker-containers/

Должен ли Ansible регистрировать изображение Docker перед его запуском ( это звучит безумно для меня) и использовать его шаблоны Jinja2 одинаково с классическим хостом!? Если нет, как это обрабатывается?!

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

Ответ 2

Что касается вопроса о работе с несколькими конфигурациями среды с использованием одного и того же изображения Docker, я планировал использовать инструмент Service Discovery, такой как Consul, в качестве централизованного средства управления конфигурацией и собственностью. Итак, когда вы запускаете свой контейнер, вы устанавливаете ENV var, который сообщает ему, какое приложение (appID), и какую конфигурацию среды он должен использовать (например, MyApplication: Dev), и он вытащит свою конфигурацию из Consul при запуске. Я все еще должен исследовать безопасность вокруг Консула (например, если мы храним учетные данные подключения к базе данных там, например, как мы ограничиваем, кто может запрашивать/обновлять эти значения). Я не хочу просто использовать это для контейнеров, но все приложения в целом. Еще одна интересная возможность - изменить конфигурационное значение в Consul и вернуть его обратно в приложение, чтобы немедленно применить изменения (возможно, как конечная точка REST в вашем приложении, чтобы нажимать изменения и динамически применять их). Конечно, ваше приложение должно быть написано для поддержки этого!

Вам может быть интересно проверить статьи блога Мартина Фаулера в неизменяемой инфраструктуре и на Phoenix servers.

Ответ 3

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

Определение различных сред - предположим, что вы создали другую роль Ansible для каждой среды, которую вы запускаете, мы определяем переменную среды, определяющую среду, к которой мы хотим принадлежать контейнеру. Затем мы загружаем подходящий файл конфигурации из ведра S3 с использованием переменной env, установленной ранее в контейнер (что должно быть возможно, если вы поставляете AWS-кредиты или предоставляете серверу роль IAM) и вставляйте эти параметры в код при его создании.
Ansible не нужно регистрироваться в приложении docker, но решение немного сложно. Я пробовал два способа решения этой проблемы, и оба они не идеальны. Первый - загрузить файл конфигурации как часть командной строки образа докере и создать приложение при запуске контейнера. Хотя это решение работает - оно нарушает философию Docker и делает изображение очень подверженным ошибкам. Другим решением является нажатие нескольких изображений на ваш репозиторий концентратора докеров, а затем вытягивание соответствующего изображения в соответствии с окружающей средой.

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