Docker — архитектурные вопросы о деплое и не тольно?
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.
Зачем в наше время пилить Docker вручную, когда есть Nomad, Kubernetes, Mesos, Swarm, Cocaine или, на худой конец Consul