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

Question

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

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

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

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

Как Docker (или анзибль и Докер) проходят процесс непрерывной интеграции !?

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

Docker конфигурации контейнеров:

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

анзибль и Docker:

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

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

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

Answer 1

Я хотел бы ответить на части

Как Docker (или анзибль и Докер) проходят процесс непрерывной интеграции !?

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

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

Docker конфигурация контейнеры:

Если вы используете частное хранилище, и вы должны использовать один, то изменения конфигурации не будут влиять на пространство на жесткий диск много. Поэтому, кроме конфигураций безопасности, таких как пароли db, вы можете применить изменения конфигурации к изображениям докеров (Baking the Configuration into the Container). Затем вы можете использовать возможность использования не сохраненных конфигураций для развернутых изображений до/после запуска с использованием переменных окружения или томов докеров.

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Возможно, вам будет интересно узнать статьи блога Мартина Фаулера по телефону immutable infrastructure и по телефону Phoenix servers.