Как подготовить один докер-контейнер для каждой ветви кода для CD

Question

Мы используем конвейеры bitbucket для CI.

Я хочу автоматизировать поток CD так, чтобы при каждом нажатии на новую / существующую ветвь скажите feature_abc (нормализовано), последний код этой ветки должен быть развернут с помощью контейнера Docker на моем блоке ec2 и сопоставлен с субдомен, имя которого совпадает с именем ветви, то есть feature_abc.mydomain.com для команды QA, чтобы начать тестирование предстоящих изменений этой ветви.

Как это сделать?

Нужно ли где-нибудь использовать ткань в автоматизации, или docker-compose может это сделать?

P.S .: Я опытный разработчик Python / Django, но новичок в Docker. Прочитал в Интернете много материалов о dockerfile и docker-compose.yml и запутался.

Answer 1

Это определенно возможно, но не только с помощью инструментов Docker. Вам примерно необходимо:

1. Сделайте так, чтобы ваша система CI пометила изображение именем ветки
2. Пусть система CD выберет порт и развернет образ на этом порту
3. Установите сетевой балансировщик нагрузки , который перенаправляет «обычные» порты для вашей службы ( например, , 80 для HTTP) на определенный порт, который вы развернули на
4. Развертывание Маршрута 53 DNS-запись с именем ветви, указывающим на балансировщик нагрузки
5. Когда вы заметите, что ветвь исчезла, отмените эти шаги

Я ссылался на определенные субпродукты AWS, так как вы указали EC2, но та же самая важная последовательность должна работать в любой среде (даже в локальной среде, использующей HAProxy и BIND на шагах 3 и 4). (Кроме того, единственное, что действительно специфично для Docker в этой последовательности, - это система упаковки и унифицированный способ указать порт хоста для конкретного экземпляра контейнера.)

Вы можете рассмотреть инструменты более высокого уровня для управления этими вещами. Ansible , например, имеет "модули" для запуска контейнеров Docker на удаленных хостах , создания AWS NLB и создания записей маршрута 53, Terraform может управлять облачными ресурсами (но поддерживать его состояние в соответствии с регулярным автоматическим повторным развертыванием может быть сложно).

Вы также можете рассмотреть структуру развертывания более высокого уровня. Эта последовательность развертывания в основном в точности соответствует тому, что вы делаете, например, в ECS Kubernetes - это еще большие инвестиции, но его объекты Service имеют, как стандартную опцию, возможность создавать балансировщики нагрузки и (с надстройкой) создавать DNS запись для вас ; но опять же, «протолкнуть образ и создать для него Deployment and Service» - это совершенно обычный способ развертывания чего-либо в Kubernetes, и нет ничего особенного в ветвях, отличных от заданных по умолчанию.