Добавлю ответ на свой же вопрос.
Прошло достаточно времени и я успел посмотреть и попробовать множество инструментов связанных с 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 , было бы зачительно быстрее всё.
