Vaavaan

Если у вас сервера куда вы хотите устанавливать софт работают под определенным дистрибутивом (например Ubuntu), то, скорее всего, вы перед внедрением окончательное тестирование и подготовку к развертыванию будете делать на машине с аналогичным дистрибутивом (или на виртуалке).

Чего это?
Вы же про Докер пишете. Не надо с ним этого.
Можешь хоть под Window сидеть хоть под MacOSX хоть под RedHat
Внутри Докера у тебя будет то, что нужно.

При работе контейнера тратятся вычислительные ресурсы на обслуживание ядра прописанного в контейнере. Да и зачем собирать контейнер на дистрибутиве отличном от того который уже есть на сервере.

Слазите в исходники ядра и посмотрите. Там несколько десятков ассебмлерных команд это "затормаживают". Подсказать сколько в секунду таких команд на процессоре 2,5 ГГц или сами догадаетесь?

Собирать контейнер нужно на том, который тебе нужен для работы.
Идея контейнеров в том, что тебе плевать на то, что снаружи контейнера.

Для чего нужно увеличивать вертикальное количество слоев в сервере, который должен выполнять и так в большинстве случаев только одну функцию. Зачем нужна инкапсуляция в капсуле? В высоконагруженных системах (100 и более серверов) может понадобится ставить на один физический сервер несколько независимых систем с разным окружением?

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

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

Зачем ставить другую ОС? Как правило не ставят. В конейнере всегда одна. Но если захотят - поставят другую. И благодаря контейнерам ты этого и не заметишь.
Очередная ОС займет всего то +50 мегабайтов.

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

Некоторые зависимости противоречивы. Нельзя одновременно поставить. На голую ОС.
А в разные контейнеры - можно.

Все изменяемые данные, например картинки, ccs, js

Это неизменяемые части приложения. Они должны располагаться внутри Докеровского образа. Каждый раз при изменении css - образ перестраивается. Поскольку он инкрементальный - это быстро и не тратит много место на диске.

и загруженные пользователями файлы хранить в volume образе.

Не обязательно как файлы.

Можешь загружаемые пользователем файлы класть по сети на S3 или OpenStack Swift хранилище. Есть софт - эти вещи можно взвести и локально. А можно использовать и внешние серверы. Например, с помощью Ceph Object Storage.

Скажем Ceph автоматически размазывает данные на несколько серверов (полубэкап получается).

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

Kubernetes, Yandex Cocaine (cocaine-runtime, cocaine-plugins, cocaine-tool)+Yandex Elliptics, Nomad+Consul+Registrator+Prometheus+Grafana, CloudFoundary, OpenShift, OpenStack, CoreOS, Docker Swarm, EtcD, Fleet, GoCircuit, Helios, AWS ECS, HTCondor, Hadoop YARN, Nagios/Zabbix/Sensu, SkyDNS, SmartStack, Puppet, Ansible, Chef, doozerd, CloudFormation, Boto, Fog, Heat и пр.

Что то из выше перечисленного - законченные платформы, что то кусочки из которых можете сложить свою платформу.

Rancher не сырой. Сырая RancherOS. Можно использовать другую.

Mesos вы использовали голый что ли? К нему нужна Aurora, Maraphon, Singularity.

Они все заточены под дикое количество нод. Ничто не мешает использовать и на 5 нодах. Правда, к примеру, Mesos из-за его Zookeeper неоправдано хочет минимум 16 гигабайтов на ноду.

В принципе достаточно Consul для многих вещей.
Пример:
https://medium.com/@ladislavGazo/easy-routing-and-...