Docker. Как очистить каталог /var/lib/docker/aufs/diff/?

Я чистил папку вручную, предварительно остановив сервис докера.
Видел такие же советы, но если будете делать так же - на свой страх и риск.

Системный вариант: docker image prune

Разве Composer бесполезен в 2017?

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

Где искать middle/senior backend программиста?

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

Continuous delivery, Continuous integration, Docker при "многоверсионном" приложении. Как организовать?

Решение в лоб - завести в гите ветки на каждую платформу (release_vk, release_..), в CI будет собираться образ сразу с исходным кодом, помечаться тегом платформы, деплоится по тегу на сервера(latest_vk, latest_...).

На мой взгляд - самое правильное решение, вопрос только в синхронизации функционала основного кода и веток платформ - придется постоянно мерджить или ребэйсить.
Либо, как вариант - форки от основного проекта. Отдельный репозиторий под каждую платформу наследуемый от основного.

2) Разные версии приложений запускаются на одних и тех-же серверах, т.е. запросы к api идут dns-балансировкой, стоит nginx на фронте, который раскидывает запросы уже на остальные контейнеры, фактически на другой nginx, который уже рулит контейнером с php.
Схема кажется немного избыточна nginx->nginx->php, в итоге на сервере дофигища разных процессов, особенно nginx.

В идеологии докера это правильное решение. К тому же легко масштабируемое - при необходимости можно каждую версию вынести на отдельный сервер.

Подскажите, а статика у вас тоже проксируется? Или отдается непосредственно первым nginx?

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

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

В rails можно обойтись без второго nginx (пользоваться встроенной пумой, например), в PHP встроенный сервер (мне по крайней мере) не удалось адекватно использовать, поэтому так же ставлю nginx + php-fpm.

Можно не проксировать статику, а отдавать самим прокси (если статики много) или внутренний nginx заменить на что-то более легкое. Так же посмотреть базовые контейнеры - возможно стоит использовать Alpine в базе каких-то контейнеров.

Если проксируете своей сборкой nginx - смотрите в сторону jwilder/nginx-proxy - там все автоматизировано.
Docker-compose - думаю, что используете, но если нет, то стоит.

И лучше всего, конечно, сами контейнеры по максимуму универсально использовать - если билдите свои контейнеры, то делать свой универсальный контейнер (того же nginx или php) и использовать его (вместо множества отдельно собираемых одинаковых) - в этом случае сборки будут использовать один образ вместо кучи разных, а в случае необходимости изменения контейнера - наследовать от него частные и вносить в него уже конкретные изменения.
Ну и т. д.

Continuous delivery, Continuous integration, Docker при "многоверсионном" приложении. Как организовать?

Безусловно, для разработки volume - самое оно, но для прода - ну такое..., должна быть веская причина.

Лучше делать при сборке через копирование файлов в контейнер?

смотрите в сторону mogilefs и т.д.

Спасибо за наводку, как раз ищу варианты.

Как оптимизировать Yii2?

Согласен про XDebug - под докером у нас тормозил проект раза в два.

Как работать с портами контейнеров в docker?

Для чего каждому пользователю выделяете отдельный порт?
Обычно, если это не какая-то специфическая задача, достаточно одного порта.