Мое локальное приложение-контейнер докеров состоит из 4 образов: React, Django, nginx, postgres. Он отлично работает локально (хотя, конечно, мне нужно вручную перейти на 127.1.1.0 на моем локальном компьютере, чтобы просмотреть приложение)
Я хочу, чтобы другие люди также могли просматривать это приложение, если на их локальном компьютере установлен Docker, поэтому, используя шаги, описанные в документации по Docker, я отправил все четыре изображения в Docker Hub. 
Я сбит с толку остальной документацией, как, например, когда я попробовал пример с использованием имени моего локального образа докера, как показано ниже,
docker run -d -p 3000:8000 --restart=always --name myport myport_nginx ,
подтянулся только сервис образов nginx, который смог запуститься как отдельный контейнер, но остальные сервисы не вызывались.
Таким образом, мой вопрос: как мне определить эти четыре изображения, чтобы они были подключены так, как они находятся на моем локальном компьютере, и чтобы любой, у кого есть локальный докер, мог получить мой репозиторий и проверить мое приложение, перейдя на 127.0.0.1 на его локальный компьютер. Я знаю, что dockerbub аналогичен github, и это должно быть прямолинейно, но как-то моя голова запуталась, и я хотел бы получить некоторые пояснения.
Ниже приведен файл dockercompose.yml, используемый для сборки приложения в первом экземпляре. Я знаю, что можно изменить мой .yaml, чтобы одно изображение могло вызывать и запускать все остальные три, и мне нужна помощь в этом, если это возможно или является хорошей практикой.
version: "3.7"
services:
django:
build:
context: ./backend
dockerfile: Dockerfile
volumes:
- django_static_volume:/usr/src/app/static
expose:
- 8000
env_file:
- ./backend/.env
command: gunicorn mainapp.wsgi:application --bind 0.0.0.0:8000
ports:
- "8000:8000"
depends_on:
- db
db:
image: postgres:12.0-alpine
volumes:
- postgres_data:/var/lib/postgresql/data/
env_file:
- ./postgres/.env
react:
build:
context: ./frontend
dockerfile: Dockerfile
args:
- API_SERVER=${ENV_API_SERVER}
volumes:
- react_static_volume:/usr/src/app/build/static
expose:
- 3000
env_file:
- .env
command: serve -s build -l 3000
depends_on:
- django
nginx:
restart: always
build: ./nginx
volumes:
- django_static_volume:/usr/src/app/django_files/static
- react_static_volume:/usr/src/app/react_files/static
ports:
- 80:80
depends_on:
- react
- django
volumes:
postgres_data:
django_static_volume:
react_static_volume:





команда должна быть docker-compose up. docker run запустит только один контейнер. Docker Compose официальные документы
Давайте сосредоточимся на одной услуге. Вам нужно будет внести аналогичные изменения во все из них.
react:
build:
context: ./frontend
dockerfile: Dockerfile
Это создает каталог frontend в вашей системе местный. Вам нужно заменить это на строку image:, указывающую на ваш образ Docker Hub.
args:
- API_SERVER=${ENV_API_SERVER}
Это компилируется в определенный URL-адрес изображения, которое вы отправляете в Docker Hub. Другие потребители могут быть не в состоянии использовать это. Если ваш обратный прокси-контейнер nginx уже обслуживает как приложение React, так и серверный API на одном хосте и разных URL-адресах, вы можете использовать URL-адрес только для пути, такой как /api, и не настраивать его.
volumes:
- react_static_volume:/usr/src/app/build/static
Это заменяет статические файлы в вашем приложении содержимым именованного тома. Если вы каким-то образом изменили это локально, у других ваших потребителей этого не будет; если вы обновите образ, именованный том останется без изменений, а обновленные файлы в образе не будут видны. Я бы порекомендовал удалить именованные тома, подобные этому. (Ваш nginx контейнер должен COPY вставить статические файлы в свой образ.)
expose:
- 3000
Это ничего не делает и может быть безопасно удалено.
env_file:
- .env
Этот файл .env существует только в вашей локальной системе. Вы можете либо распространять этот файл, либо преобразовать его во встроенные environment: переменные, либо, в зависимости от настроек, исправить их с помощью инструкций Dockerfile ENV.
command: serve -s build -l 3000
Это переопределяет CMD изображения и не должно быть необходимым.
depends_on:
- django
Это отлично.
После очистки всего этого для этой службы я ожидал бы чего-то большего, например:
react:
image: 2fresh/frontend
depends_on:
- django
Вам может быть полезно иметь файл docker-compose.override.yml рядом с docker-compose.yml. Это предоставляет определения, которые вам нужны только для локальной разработки, например, как build: изображения. Два файла будут объединены, и сочетание build: и image: указывает Compose, какое имя использовать для созданного образа.
# docker-compose.override.yml
version: '3.8'
services:
react:
build: ./frontend
# all other settings in main docker-compose.yml file
Да, идея вашего ответа сработала для меня: создать файл yaml для создания докеров, который не требует каких-либо локальных зависимостей, чтобы любой, у кого установлен докер, мог использовать мой файл docker-comp-yaml и запускать docker compose до вставай
Я использую docker composé для сборки и запуска образов на локальном докере, но как мне использовать docker composé для прямой загрузки и запуска 4 репозиториев из docker hub в виде единого контейнера?