Docker. Как контролировать код, базу данных и выпуск в production?

Question

[Unknown Hero]

Доброго времени суток.

Хочу автоматизировать процесс тестирования и deploy'я для web приложений.

Сейчас этот процесс состоит из ручного вызова deploy.sh на сервере.А тестов и вовсе нет.

Что я хочу:
1. Делаю изменения в коде , делаю git commit && git push
2. Continuous Integration сервер забирает свежую версию веток production(master) и dev.
Если есть изменения , тестирует новый код , делает сборку кода готовую для deploy'я (минификации , очистки и т.д.) и заливает на нужные сервера.

И вот в этот процесс хочу внедрить docker.

Но мне не понятно:

1. После того как конечная сборка кода была сделана , нужно делать заново "docker build ... / docker commit ..." с новым кодом , делать push в docker repository , а затем обновлять (docker pull) все контейнеры на серверах на новые и перезапускать их ( "docker run ..." ) ?

Или код должен попадать в контейнеры на production/test серверах другими способами ( git pull , deb/rpm ) ?

2. Как лучше сделать контейнер базы данных для production/test ?
Читал про data containers , что можно делать отдельный контейнер , где будут храниться сами данные базы.

Но тут мои слабые знания в области ОС и файловых систем не могут дать мне на ответ - лучше ли использовать хостовую систему для хранения данных базы (docker run -v ... ) или всё же использовать data container ( docker run -volumes-from) ?

Будет ли падать скорость работы при использование этих "синхронизаций" файлов ?

Я понимаю , что нет волшебного рецепта. Хотелось бы использовать свежие технологии и решить проблему автоматизации процесса "от git push на рабочем ноуте до обновлённого сайта на production/test". Так же хотелось бы легко подключать новые сервера и делать мониторинг всех системы.

Спасибо за внимание :)

Answer 1

[Unknown Hero]

Добавлю ответ на свой же вопрос.

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

Создал 2 приложения , первый этой сам сайт для которого хотел сделать инфраструктуру , второй это инструменты администрирования, тестирования и деплоя.

Приложение для администрирование развёрнуто на 1-м сервере, на нём есть Docker Registry , Jenkins и ещё пару веб страниц с разной информацией. Всё это обернул в Nginx , работает здорово. Само приложение тоже использует Docker , но обновлять его нужно руками (ssh and etc).

Сайт ( который на самом деле состоит из бизнес логики , DAL , Postgresql , Rest API , web-frontend , web-backend и ещё пару уровней абстракции :) ) использует содержит около 10 Dockerfile.

Внутри приложения использую инструменты сборки (grunt для nodejs) и собираю приложение во время сборки образа (docker build) , либо после запуска контейнера для продолжительной разработки с помощью FIG.

После правки кода, заливаю всё в git репозиторий, Jenkins собирает образы (docker build) и отправляет в Docker Registry, после чего сообщает серверам (сейчас он 1), что нужно обновить образы (docker pull) , и перезапустить контейнеры. Там где нужно сохранить данные , использую data containers , их я не перезапуска и не трогая.
Со временем хочу сохранять состояние data containers (docker commit) и заливать их на Docker registry (docker push) для бэкапа некоторых данных.

Сервер собирает и перезапускает обновлённые контейнеры с помощью самописных bash скриптов (они не сложные ), т.к. родные для Docker инструменты для этих целей ещё в стадии разработки (Docker swarm , Docker machine , Docker compose) , а стороние решения скорее всего умрут после выхода этих инструментов.

Через Environment variables говорю контейнеру в каком он режими работает (local/test/live), но нужно это только для минификаций и уровня логгирования. В этих настройках - чем меньше различия,тем лучше.

Всё это загнал в vagrant , отлично работает ,но требует хорошое железо для разработки.

В планах:
- научиться тегировать образы, что бы можно было откатить все сервера до рабочего состояния в случае багов.
- добавить процесс автоматического тестирования и оценки качества в Jenkins (для docker приложений нужно поднимать ещё jenkins slave )
- прикрутить ansible для деплоя и прочих удобностей для администрирования. Связать его с Jenkins

Итог:
-Однин раз написал, везде использую.
- Автоматизация до уровня commit = staging deploy
- Разделение административных инструментов и сервисов от бизнес приложения.
- Независимые компоненты ,которые можно легко заменить, слабая связаность.
ну и минусы:
- одному тяжело уследить за таким зоопарком )) Был бы администратор/DevOps , было бы зачительно быстрее всё.

Comments

[Анатолий Евладов]

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

Answer 2

[Konstantin Kozhin]

Использую некоторое подобие автоматизации следующим образом:

1. На хосте запускаю скрипт, который собирает моё приложение в новый образ из Dockerfile оф. образа Rails: https://github.com/docker-library/rails/blob/3c87a...

Этот скрипт донастраивает ОС; устанавливает гемы, нужные для старта приложения; копирует код приложения из каталога репозитория на хосте (можно дописать, чтобы вытягивал сразу из репозитория). Как только образ готов, можно останавливать старый контейнер, запускать новый и полностью удалять старый.

Уверен, что можно с помощью Continuous Integration сервера полностью автоматизировать задачу.

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

2. Так как в качестве хоста для запуска Docker использую в основном виртуальные машины, то стараюсь не использовать data-контейнеры, а хранить всё на хосте через Volume директивы. Это связано в первую очередь с тем, что для каждого проекта я использую отдельную виртуальную машину. Да и так потеряться ничего не должно, и мониторить проще.

Если же нужно изолировать хранилища данных (например при расшаривании виртуальной машины между разными клиентами/проектами), то только через data-контейнеры. Тут история немного сложнее в настройке и, может быть запутаннее, но всё же так правильно с точки зрения безопасности.

Так как виртуальные машины на SSD, проблем с производительностью пока не отмечал. Да и проекты, в принципе, небольшие (до 10000 просмотров в сутки).

Answer 3

[Всеволод Калошин]

Добрый день!

Для вашей проблемы (CI & CD) существует несколько решений, это как:
- Docker Cloud (бывший Tutum)
- Last.Backend
- Rancher (с Kubernetis)
- Cloud66

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

По поводу базы данных, то я шарю volume на хост машину. Однако docker я не использовал бы для построения решения для репликации.

Comments

[Виктор Логин]

Добрый день, проясните пожалуйста в чем заключается проблема/опасность использовать реплик и docker? Мы используем реплики MongoDB запущенные в docker и хотелось бы узнать с какими проблемами мы можем столкнуться.

[Всеволод Калошин]

Виктор Логин: Не использовал монгу, поэтому ничего не могу сказать на счет именно ее.

Просто имел опыт настройки docker с PostgreSQL, и иногда возникали проблемы с повторной инициализацией базы данных после выключения и включения контейнера.
Да и как это правильно и корректно автоматизировать поднятие - хороший вопрос.
Но мы отошли от использования PostgreSQL так как не получилось корректно автоматически настроить смену master->slave и обратно slave->master в случае быстро включения выключения Master Slave машин (Azure Maintaince), мы просто перешли к SaaS решению БД.

Я думаю это все сильно зависит от доступности данных, которые хранятся в БД. Для нас критично что доступность должна быть 99,99%

[Всеволод Калошин]

Виктор Логин: Проблема была с Docker, но не связанная именно с БД. Это если сетка для контейнера была создана с помощью docker network. Иногда встроенный dns сервер перестает резолвить адреса. Решается только если задать сетку контейнера по умолчанию.

[Виктор Логин]

Всеволод Калошин: спасибо за ответ

[bamaz]

Виктор Логин: Репликация средствами БД намного более эффективная (быстрая, надежная) чем репликация образом.
Репликация образами - более простая в настроке, более универсальная.

Answer 4

[Денис]

На сколько я помню docker commit если действия происходят с контейнером а не с образом
А buid, pull и push работают именно с образами (на основе которых и создаются контейнеры)
Есть ещё save и load которые сохраняют в стдаут контейнер ну и читают соответственно
ИМХО вообще docker commit вносит сумбур