Черновой ответ, потому что у всех детали могут отличаться - делайте как Вам удобнее.
1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.
2. Идеально - один контейнер - один сервис. Но для целей разработки можно использовать контейнеры как средство доставки чего бы то ни было и там рождаются кадавры с несколькими сервисами в одном контейнере. Но для продакшена это не очень.
3. ansible, gitlab-ci
4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы
5. никак. Она с докерами никак не дружит.
6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.
> Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?
Совсем высокоуровнего - да, так.
Сложный
