mureevms

1. Образ и контейнер это разные сущности:
Образ - это сущность, которая образуется после команды docker build, затем которая может быть помещена в регистри или в докер хаб. Можно провести аналогию с ISO образом ОС.
Контейнер - это сущность, которая образуется после команды docker run. Т.е. контейнер - это определенным образом запущенный образ. Можно из одного образа запустить множество контейнеров

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

контейнер !== образ, а контейнер === сервисы, где сервис === образ

Контейнер != образ, факт.
Контейнер может быть сервисом, а может и не быть, все зависит от того, что внутри.
Сервис != образ. В данном случае нет понятия сервиса, это что-то внутри контейнера. Если там демон, принимающий запросы - это сервис. В широком смысле образ это образ и он ничему не равен.
2. Как будет удобно, не принципиально. Но раз уж есть compose, то через него будет удобнее
3. Нет причин не хранить docker-compose.yml в репе. Главное, чтобы в нем не было секретов. Все "ненужное" должно быть вынесено в переменные. Далее, как и сказал Дмитрий, надо правильно доставить это на прод

container_name: postgres-db

В коннекшн стринг приложения в качестве хоста БД надо указывать имя контейнера, т.е. self.HOST = 'dbpostgres-db'

Если коннектит происходит из другого контейнера, надо коннектиться по имени контейрена, т.е. так:

wait mongoose.connect(`mongodb://mongo:27017/${DB_NAME}`)

Если у вас тип executor это docker, то что находится в script выполняется в контейнере, поднятом из image. Соответственно, вы пытаетесь сделать Docker-in-Docker. Осуждаю, поскольку сильно специфично и если вы не знаете для чего именно оно вам надо, значит не надо. Выберите shell как тип экзекьютора и скриптуйте командами непосредственно из системы без дополнительной прослойки

Красным по черному же пижет, что

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

Это проблема Centos, потому что он всё. Починить можно, но не в докере, смысла не имеет. Соберите на живом дистре тоже самое

-v /data:/date:rw.

data и date

Написать скрипт, который чекает в цикле время работы каждого контейнера и если он меньше 5 минут, слать письмо/веб хук/что -то еще, скрипт поместить в крон на выполнение каждые 4 минуты

1. Всегда лучше делать явно, чем не явно. Это упростит работу другим и себе же, когда пройдет полгода.
2. Это как минимум удобно. Контейнер всегда называется одинаково, вместо дурацких автоматических названий. Опять же, пройдет полгода, вы сами читаете конфиг компоуза и видите контейнер не пойми как называется, надо будет догадаться, что имя не назначено. Зачем усложнять?
3. По ситуации, нет верного ответа
4. Относительные пути тру. А вот абсолютные зло. При относительных путях вам надо просто перенести каталог на новый сервер и все запустится. Абсолютные придется править, а это усложнение.

Как именно проверяете?
Какой UID имеет пользователь momo в контейнере? Вангую, что первый вывод без пользователя у вас в хост системе, поскольку в ней нет пользователя с таким UIDом. А UID пользователя momo в контейнере == 1002

Каждый раз делать chown на хосте под вымышленного пользователя как-то странно. Это похоже на баг.

Все имена пользователей сделаны для удобства человека, система оперирует UIDом. Chown тоже умеет указывать UID, а не username: chown -R 1002:1002 /target

У вас web:8000 перестает отвечать. Смотрите на него, может он падает. Ну и логи смотрите. Вангую, что там будет сообщение типа, что web:8000 недоступен.

%USERPROFILE%

А вообще, вот список виндовых переменных окружения