Как подружить Ansible и Docker?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Здравствуйте.

Делаем с другом проект бекенд в виде API на node.js, фронтенд на ember.js, используем postgresql и redis. Пока ведем разработку локально, но планируется три окружения: development, staging, production. Еще не деплоя ничего в свет уже есть проблемы, что на разных компах разные версии node, npm, postresql и т.д. А потом охото иметь одинаковую инфраструктуру на всех 3х типах окружений. Немного работал с Ansible, но без Docker, потому выбор пал на него.

Планируется 4 контейнера:
— контейнер с nginx, в нем же планирую положить фронтенд код
— контейнер с node.js приложением
— контейнер с postgresql БД
— контейнер с redis — используется для Pub/Sub и в качестве кеша.

Контейнер с nginx отдает фронтент и проксирует запросы к api на контейнер с node.js приложением.

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

1. Делаю 3 inventory файла для каждого окружения. Для дев и стейдженг, для всех типов серверов ip адреса будут одинаковыми.

2. Ansible должен подготовить каждый из серверов:
— создать необходимых юзеров
— установить docker

3. Получается должно быть 4 Dockfile по которым docker создаст image:
— Как правильно описывать конфиги: описание хоста в nginx, настройки postgresql, указать, что бы данные хранились не в контейнере.

4. Как построить процесс сборки? Процесс сборки должен проходить в отдельном контейнере? Сборка состоит из таких этапов:
— Взять последний код с git (в одном репозитории и фронтенд и бекенд)
— Обновить npm update для бекенда
— Запустить код стайл + тесты для бекенда
— Обновить npm update для фронтенда
— Обновить bower update для фронтенда
— Запустить код стайл + тесты для бекенда
— Сделать билд фронтенда ember build

6. Как правильно деплоить?
— Делать процесс сборки на выбранном окружении, после чего перезапускать докер контейнеры, что бы они подтянули изменения.
— Делать процесс сборки создавать новый контейнер и как-то блансировать в nginx нагрузку на него, но тогда не совсем понятно как быть для девелопмент окружения

5. Как устанавливать задачи в короне?

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

Потому если лень, отвечать, просто ткните в хорошие материалы по данной теме.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не совсем понятно зачем вам докер, какие проблемы он решает лично для вас?

Догнать состояние до идентичного можно и просто с ансибл/puppet/salt/chef, еще можно было взять vagrant и там же использовать уже имеющиеся ansible скрипты. Или взять тот же www.packer.io, и иметь одинаковые окружения на vagrant, amazon, docker, etc.

Докер хорош в продакшене, для девелопмента он не всегда годится, хотя бы потому что нормально он работает только под linux.

ps: на закуску github.com/openshift/origin

забавно наблюдать, как теперь говорят, что докер хорош только в проде, когда раньше говорили, что он только для дева и годится.

docker toolbox — и win/mac работает из коробки. я уже не говорю о docker private beta с их новым гипервизором, заточенным специально под это.

Как бы не был хорош Docker Toolbox под мак, нормальной производительности можно добиться только с Parallels Desktop, а не с донским виртуалбоксом из коробки.
Docker for Mac уже давно не private, и не beta. Но там проблемы с i/o еще хуже, чем с виртуалбоксом. Починят — можно будет сравнивать, а пока что приходится плясать с бубном

Да там нет virtualbox уже. Но volume по прежнему тормозят. И никто не борется с этим, как в vagrant не боролись так и тут.

В Docker 4 Mac нет, в тулбоксе все еще есть

Да но виртуалка с линуксом никуда не денется, никогда :)

Для какого такого девелопмента он был хорош? С трудом могу представить, зачем надо тратить силы и время на возню с докером, когда есть тот же lxc и vagrant, который пакует в tar быстрее и проще. Та и вообще один раз настроить окружение и не иметь дел с приблудами. Он собственно и выжил только потому, что люди углядели в нем профит в использовании в продакшене.

1. Можно обойтись одним inventory файлом с группами хостов ([web:production] или [stage])
2. Зачем нужен Ansible в таком случае? Я бы понял, если б вы подготавливали контейнеры и их конфиги, а для двух команд (apt-get install docker и useradd) использовать Ansible немного.. странно, что ли.
3. Я бы советовал для конфигов использовать тот же Ansible с темлпейтами, а значения хранить в .env. Возьмите docker-compose, и опишите там services и volumes. Кроме того, совет вынести код в отдельный контейнер и монтировать его в другие контейнеры
4. Можно описать шаги на уровне playbook с тегами. git pull делает CI, все остальное происходит внутри контейнера
5. Не очень понятно, какой cron имеется ввиду — контейнерный или внешнесистемный?
6. Для девелопмент можно использовать docker-compose scale=N. Вообще довольно обширная тема, могу дать список баззвордов по которым стоит погуглить: Rancher, Drone.io, Consul, Kubernetes

В playbook’ах ansible хотел описывать какие имаджи нужно взять и на каких хостах запустить, что-то типа
- name: Database docker: name: database image: postgres:9.4 state: started
Настройки описывать буду в темплейтах, а потом через docker volumes буду мапить в контейнер, все еще при помощи ansible.
Кронтаб получается в контейнер можно тоже через docker volumes засунуть.
Наверное это все может сделать docker-compose, но мне кажется в ansible это гибче.
При таком подходе мое приложение должно быть запаковано в имадж и положено на какое-то хранилище имаджей.
Кто этот имадж билдит? Он должен быть сбилжен после запуска тестов? Или тесты в нем должны выполнится? Для этого я так понимаю нужен Jenkins, etc. А какой облачный сервис можно использовать?

То есть софт вы собираетесь ставить через докерфайл, а темплейты — через ансибл на самом хосте? Мне кажется это ансибл ради докера и докер ради ансибла.

Поднять кластер, и просо запускать там контейнеры через оркестрейшен тул. Что бы поднять кластер тут можно и ansible использовать. Хосты вам нужны только как комьютинг ноды, ан них не должно быть ничего кроме докера. В идеале надо взять CoreOS или аналог. Билдить контейнеры могут тоже контейнеры.

3. Сначала почитайте про docker volumes.
Конкретно с nginx — hub.docker.com/r/jwilder/nginx-proxy — это отличный пример выноса конфигурации наружу. Быть может, вам не нужен собственный контейнер с nginx, а пригодится этот.
С данными в БД — docker volumes. hub.docker.com/_/postgres — запустите с ключом -v /path/on/your/host:/var/lib/postgresql/data и вуаля, данные будут на хосте. Или используйте named volumes: -v awesome_volume_for_db_data:/var/lib/postgresql/data
4. it depends. чем желаете собирать? jenkins? drone?
6. systemd + самописные скрипты для деплоя, или что-то вроде rancher для автоматизации всего это дела одной командой. rancher рекомендую только если ’это стоит того (сам центральный оркестратор rancher’a отжирает 700-800 мб оперативы).

Впрочем, если у вас уже сервис состоит из больше чем 5 контейнеров, и вы ещё хотите разворачивать таким же образом dev/stage/prod/test/etc окружения, попробуйте rancher.
Есть ещё проекты вроде CoreOS — но это чисто ОСь и инструменты, из коробки мало что есть. Есть kubernetes — но, думаю, вряд ли ваш масштаб и вообще overkill.

Спасибо за ответ.
Еще не совсем понятно где собирать проект, где один jenkins или drone будет жить, то есть нужен отдельный CI сервер? И может можно без них обойтись ansible запустит все команды, нужные , по логам понять если все ок, тогда делаем деплой, в так случае сборка будет происходить на дев машине

желательно иметь сервер, где будут жить git, ci (jenkins/drone), docker registry.
не понимаю при чем тут ansible — лишняя тула в контейнерном окружении, если у вас все задачи лежат в пайплайне git -> drone/jenkins -> {build, test} -> docker registry, и уже оттуда готовые образы нужно деплоить (rancher — rancher-compose утилита, например).

Підписатись на коментарі