Так вы смотрите, что там за процессы-то висят - запросы или какие-то фоновые, вроде вакуума. Универсального ответа с такой куцой информацией не получится - надо диагностировать.
Очень много вопросов, часть из которых легко гуглится, а другая - без проблем рассказывается сисадмином с небольшим опытом. На Тостере такие комплексные простыни не любят - и совершенно справедливо. Декомпозируйте, иначе скорее "это задание, а не вопрос".
Звучит как набор требований, которым докер и вообще любой контейнер плохо соответствует. Зашифрованная виртуалка подходит гораздо лучше, да и то с оговорками.
Разобраться, почему у вас доступ к репозиторию запрещён. Причина может быть как с той, так и с вашей стороны (фаерволлы, РКН и т. д). Начал бы я со стандартной сетевой диагностики, сверху вниз по модели OSI.
Любая контейнеризация - это оверхед. Насколько он большой, зависит от конкретных условий - технологии, верности настройки, особенности приложения. Те же данные СУБД, например, внутри докера располагать не стоит.
Ошибка имеет отношение к маршрутизации, а не фаерволлу. Есть у вас маршрут до данного хоста или шлюз по умолчанию, способный отправить пакеты куда надо?
Используем LXC-контейнеры уже несколько лет в составе Proxmox, никаких серьёзных проблем ни разу не возникало. Сырость технологии проявляла себя крайне недолго, буквально до первого апдейта платформы после изменения в Proxmox технологии контейнеров с OpenVZ на LXC.
Почему в 2018 году OpenVZ-хостинги распространены шире - затрудняюсь ответить, видимо владельцы купили лицензию у Виртуоззо и теперь залочились на этом старье :)
До определённого размера и нагруженности базы лучше использовать в рамках одной СУБД - оверхед будет меньше, а памяти можно выдать в три раза больше, они это любят.
