Использование реестра docker для совместного использования моего приложения с несколькими образами контейнеров: Проблемы с подключением нескольких репозиториев образов

Мое локальное приложение в контейнере docker состоит из 4 образов, React, Django, nginx, postgres. Оно отлично работает локально, (хотя, конечно, мне нужно вручную перейти на 127.1.1.0 на моем локальном компьютере, чтобы просмотреть приложение)

my local docker app, I can start the container by clicking a button Я хочу, чтобы другие люди тоже могли просматривать это приложение, если у них на локальном компьютере установлен docker, поэтому, используя шаги из документации по docker, я разместил все четыре образа в docker hub. 4 separate repositories for each image as defined in the documentation best practices

Остальная часть документации вызывает у меня недоумение, так как когда я пробовал пример с использованием имени моего локального образа докера, как показано ниже, docker run -d -p 3000:8000 --restart=always --name myport myport_nginx ,

только служба nginx image была извлечена и смогла запуститься как отдельный контейнер, но остальные службы не были вызваны.

Итак, мой вопрос: как мне определить эти четыре образа, чтобы они были подключены так, как они подключены на моем локальном компьютере, и чтобы любой человек с локальным docker мог получить мое репо и проверить мое приложение, зайдя на 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 up official docs

Давайте сосредоточимся на одной службе. Вам нужно будет внести аналогичные изменения во все из них.

  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
Вернуться на верх