Черновой ответ, потому что у всех детали могут отличаться - делайте как Вам удобнее.

1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.

2. Идеально - один контейнер - один сервис. Но для целей разработки можно использовать контейнеры как средство доставки чего бы то ни было и там рождаются кадавры с несколькими сервисами в одном контейнере. Но для продакшена это не очень.

3. ansible, gitlab-ci

4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы

5. никак. Она с докерами никак не дружит.

6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.

> Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?

Совсем высокоуровнего - да, так.

Ответить на вопрос можно только зная финансовые возможности и зная какие задачи будут выполняться на ПК
В целом - выглядит относительно сбалансированно. Единственное, что ssd на 120ГиБ - это катастрофически мало. Рекомендую рассматривать модели объемом 256ГиБ - 512ГиБ. Тогда не будете испытывать болей навроде "винда накачала апдейтов - место закончилось"

ну, все написано - когда монтируете, то можете только файл на файл или каталог на каталог монтировать. Иногда бывает, что если в volume слева указан файл, который на хосте не существует, то докер сходит с ума. И создает вместо него каталог с правами root:root.
Какое может быть решение? Для начала прекратить пользоваться упрощенным синтаксисом -v в docker run или volumes в docker-compose, а использовать расширенный синтаксис mount (который с --mount). Тогда, если на хосте нет нужного файла, то докер контейнер ТУПО не стартанет и будет внятное сообщение об ошибке вроде:

docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /home/local/georg.gaal/formulas.
See 'docker run --help'.

При этом Вы еще бонусом и получаете то, что докер не будет пытаться изменить права на каталог. А создаваемые внутри файлы будут с теми правами, которые установлены внутри контейнера - сплошная лепота. Минус в том, что все необходимые каталоги и файлы для запуска контейнера надо создавать заранее. Т.е. уже коллегам надо отдавать докер-компоуз файл плюс bash-скрипт

Нет, keepalived не будет работать в разных ЦОД. Но есть исключение - если сделаете L2VPN или типа того.

Рассмотрите более продвинутые варианты обеспечения отказоустойчивости (вроде BGP анонсов, либо закройтесь внешним прокси вроде Qrator/cloudflare). И ОБЯЗАТЕЛЬНО ПРОКОНСУЛЬТИРУЙТЕСЬ с сотрудниками ЦОД - они наверняка хорошо знают свою инфраструктуру и могут предложить варианты (например, плавающий между ЦОДами IP адрес, если ЦОДы принадлежат одному владельцу)

> Как работает параметр user при запуске докер-контейнеров и, самое главное - как обрабатывать его при написании своих Dockerfile'ов?

никак. Параметр user это костыль, который позволяет софт запускать не от root'ового пользователя. Объяснять почему запускать в докере под пользователем 0 (root) что-либо - долго, но если кратко, то это очень плохо и не секурно. Соответственно, правильный путь Вы уже поняли:

1. определять entrypoint контейнера как свой самописанный docker-entrypoint.sh скрипт
   
2. в docker run оставить возможность передать ключ (точнее - переменную среды) USER
   
3. в docker-entrypoint.sh его (ее, переменную среды) подхватывать и изменять через chmod/chown нужные файлы в bind-mount (каталогах, доступных и в контейнере, и на хосте) и через утилиту gosu переключаться в нужного пользователя
   
4. и только как завершающий этап - запускать свой сервис в докере
   

Что еще добавить. Все эти проблемы с chown/chmod возникают только если необходимо перегонять файлы между контейнером и хостом. Если этой задачи не стоит, то и все приседания и не нужны. А если все-таки нужно, то есть еще два способа это сделать без колдования с правами:

• команда docker cp
  
• использование pipe: docker exec container_name cat MY_FILE > path_on_host или аналогично