Сергей Протько

ведь все запросы будут падать на выделенный ip, которые должен проксировать получается на docker контейнер?

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

https://fralef.me/docker-and-iptables.html - вот тут можете по подробнее почитать как это работает.

для доступа к ФС свой

Нет, для доступа к ФC используйте именованные волумы (named volumes). Контейнеры (data-only) для этог оне нужны.

Между собой без проблем, а как отправить это дело на рабочий сервер, не ручками?

docker registry, либо используем платный либо ставим у себя и там храним образы. То есть если кто-то решил обновиться до php7.0 мы должны заменить базовый контейнер, проверить что все работает, запушить... а у всх все подтянется.

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

Именно, никакого отношения к докеру. Я обычно миграции накатываю прямо при старте контейнера. Так надежнее.

Может кто поделиться ссылочкой на статью

На статью - нет, их много. Могу поделиться тем как я использую docker на своих проектах. Там описан процесс сборки и деплоя в крадце. В идеале сборкой и деплоем должен заведовать CI-сервер а не руками локально:

https://github.com/intellectsoft-uk/symfony-skeleton

Когда захожу во второй контейнер и переключаюсь на юзера docker переменная PATH сбрасывается

Ну так вы сменили "окружение" по сути. Единственный способ этого избежать - записать ее в /etc/environment.

В целом же проще будет просто поместить ваш бинарник в /usr/local/bin например.

1) nginx-proxy
2) копируйте исходники в образ (в dockerfile), собирайте либо локально либо на CI-сервере эти образы и пушьте их в docker/distribution (либо платный docker-hub либо разверните свой, это с докером делается за минут 10).
3) Прямо в контейнере с PHP. Либо заведите отдельный контейнер для php-cli и зачедите отдельный контейнер для исходников, и через volumes_from расшарьте между ними. Вариант с cron на хосте тоже достоен существования, но это не ок в большинстве случаев.
4) обновлять базовый образ. А там уж как организуетесь.
5) Можно, смотрим пункт 2.
6) Вообще тут можно схитрить. Вы можете же хранить зависимости прямо в репозитории, в смысле коммитить вендоры. Но вы этого не делаете. На момент когда запускается docker build ваших образов, все зависимости уже должны поставиться. И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.
7) как мы выяснили в пункте 6 - композера на проде быть не должно. вообще как, вы оттещенный образ со стэйджинга должны просто "мувать" на продакшен. В этом плане риски при релизе минимальны.
8) тут опять же по разному. Мне удобнее прямо из контейнера коннектиться например в sentry или graylog и скидывать туда логи. Ну или мы должны пихать логи в stdout/stderr контейнера и далее агрегировать их снаружи, тут так же есть куча вариантов.
9) все это отдельные контейнеры, все это вместе связывается башем и docker-compose. Все это разварачивается либо через docker-machine и CI либо просто через CI. Docker-machine будет "удобным" только с версии 0.7 или 0.8.

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.

ну дата контейнеры - никак. Вы можете их сдампить в образы в принципе.

В целом же алгоритм такой
- пушим образы в docker hub (или свой registry/distribution на сервере, в этом случае надо сначала задеплоить его куда-нибудь по той же схеме)
- добавляем целевую удаленную машину в docker-machine (драйвер general) - тот ставит там докеры шмокеры и в целом настраивает все
- при помощи docker-machine env переключаемся на удаленный docker-демон
- делаем docker-compose up -d или как вы там оркестрируете все. Для удобства стоит отдельный yml файлик под прод сделать и указать образы которые вы запушили.

Готово.

Docker это то что мне нужно? А может я хочу невозможного?

У Docker чуть отличается концепция, но оно даже лучше подходит.

Основная идея - каждый сервис в своем контейнере. То есть у базы данных свой контейнер, у приложения - свой, у nginx - свой отдельный контейнер. В среднем одно простенькое приложение требует 3 контейнера (приложение, база данных и web-сервер в качестве прокси). Если у вас 10 проектов то это будет 30 контейнеров. Ну и да, не забываем про data-only контейнеры, они не несут дополнительного расхода ресурсов и нужны только для удобной организации сохранения данных. Если вы используете контейнер с базой данных - то это сразу +1 data-only контейнер. Приложение может аплоадить файлы - еще один контейнер-пустышка. Звучит страшно, да?

Каждый контейнер основан на другом контейнере, например все ваши контейнеры могут базироваться на одном образе, например Debian или Ubuntu. А особенность архитектуры файловой системы контейнеров позволяет реюзать оные, что значит что у нас будет всего один базовый контейнер с убунтой на остальные 30. Ну и далее, база данных обычно у нас так же частенько одна и та же (например в моем случае это postgresql), так что 10 контейнеров для 10-ти приложений превращаются в один контейнер с базой данных и 10 контейнеров-пустышек для сохранения данных приложения.

Ну и далее, все общие вещи реюзаются между контейнерами (то есть смотрим по базовому образу).

В случае же с виртуалками у нас 10 виртуалок в которых крутится 10 операционных систем (в докере только окружение, но ядро используется на уровне хоста), 10 баз данных ну и тд. То есть докер существенно сокращает количество необходимых ресурсов и вообще прикольно.

Docker НЕ работает на windows. Точнее microsoft планирует сделать поддержку оного (если еще не сделала), но только для win server-ов. Что не ок. Так что linux в виртулку поставить придется, но только одну на все проекты. Что же до возни с самбами и прочим - тут уж как хотите. В целом же производительности обычных шаред фолдеров должно хватать (так как мы всеравно мэпим данные по большому счету на файловую систему виртуалки).

Так что можно просто скачать Docker Toolbox и работать. Для Mac OS есть еще штука под названием dinghy, которая добавляет прозрачную поддержку NFS и т.д. но для винды такого нет (только черзе vagrant). Ишус на эту тему висит в репозитории docker-machine и возможно в скором времени и это запилят.

мне не нужны танцы с виртуалками, самбой, настройкой хостов и тп?

Вообще-то это никогда не нужно, все уже придумано до нас. Есть такая штука как vagrant которая полностью решает вопрос оркестрации виртуальными машинами для изоляции окружения. Но оверхэда оно дает сильно больше.

если мы опять разбиваем приложение на куски, имея весь тот геморой, который мы имели, когда докера не было?

Отчего же? Ваше приложение может работать под арчем используя одни либы, используя при этом базу данных которая крутится под дебианом, при этом вы не паритесь о каких-то других вещах. Если вам нужна база данных - вы просто используете контейнер с оной как черный ящик. А с учетом того что у нас есть docker-compose разворачивать такую систему вообще не проблема, просто запускаем docker-compose up и все. Мы добились того же что можно было бы сделать используя один контейнер, но всю систему намного проще поддерживать.

По сути если мы разделяем наше приложение на отдельные сервисы (база данных, реверс-прокси, кэш и т.д) и при этом используем удобный формат вроде docker-compose.yml для того что бы описать что у нас там и как оно должно быть слинковано вместе, мы получаем все те плюсы которые вы указали и простоту поддержки контейнеров.

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

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

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

это LXС, он нужен для изоляции окружения, необходимого приложению для работы. То есть это такой быстрый способ развернуть приложение не парясь о зависимостях.

Залесть внутрь конечно можно, но проще сделать так:
https://github.com/audreyt/ethercalc

там есть Dockerfile по которому строится и провиженится контейнер.

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

Залезать можно по ssh и можно маунтить директории.