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

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.

да, это сервер на котором происходит сборка. У меня скажем есть один мастер сервер где установлен Jenkins, и 3 агента (один на маке для сборки под iOS и два на linux для андроида и вэба).

выполняют build на клиенте

Лучше отдельный сервак. CI-ка всегда должна иметь доступ к своим слэйвам. Хотя думаю можно извратиться.

Docker + Ansible. При деплое поднимаете контейнер с новой версией приложения (старая версия в скоем контейнере и пока работает), накатываете миграции (условие - миграции одной версии не должны вести к неработоспособности старой, иначе у вас проблемы с проектированием базы), подменяете текущий контейнер на новый и тушите его. Если вдруг что-то пошло не так, запускаете скрипт который проведет операцию в обратном направлении.

Если Docker смущает своей молодостью, есть вариант с оформлением приложения в виде DEB-пакета.

А еще есть Capistrano.

p.s. Довольно интересная тема, но на большинстве проектов, с которыми довелось сталкиваться или общаться с разработчиками оных, популярна стратегия "фиксить АСАП!" (за редкими исключениями, причем даже если минута простоя стоит тысячи долларов). Обычно это связано с тем что такие ситуации не случались ибо все предварительно обкатывается на стэйджинге с копией реальных данных.