Докер: разбить структуру на полезные сети

Question

Я не совсем уверен в правильном использовании сетей докеров.

Я использую (один хост) обратный прокси-сервер и контейнеры для самого приложения, но я бы хотел настроить сети, такие как proxy, frontend и backend. Последний для проекта1, предполагая, что в конце может быть несколько проектов. Но я даже не уверен, так ли это должно быть сделано. Я думаю, что внутренний интерфейс должен быть доступен только для внешнего интерфейса, а внешний интерфейс должен быть доступен для прокси.

Итак, это моя текущая рабочая структура только с одной сетью (мостом) - что не имеет смысла:

1. Обратный прокси (сеть: обратный прокси):
   • jwilder / Nginx прокси
   • ЦПД / letsencrypt-Nginx прокси-компаньон
2. База данных
   • Монго: 3.6.2
3. Проект 1
   • один / интерфейс
   • один / бэкенд
   • два / интерфейс
   • два / бэкенд

Итак, мой первый docker-compose выглядит так:

version: '3.5'

services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    networks:
      - reverse-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/docker/nginx-proxy/vhost.d:/etc/nginx/vhost.d:rw
      - html:/usr/share/nginx/html
      - /opt/nginx/certs:/etc/nginx/certs:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro

  nginx-letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nginx-letsencrypt
    networks:
      - reverse-proxy
    depends_on:
      - nginx-proxy
    volumes:
      - /var/docker/nginx-proxy/vhost.d:/etc/nginx/vhost.d:rw
      - html:/usr/share/nginx/html
      - /opt/nginx/certs:/etc/nginx/certs:rw
      - /var/run/docker.sock:/var/run/docker.sock:rw
    environment:
      NGINX_PROXY_CONTAINER: "nginx-proxy"

  mongodb:
    container_name: mongodb
    image: mongo:3.6.2
    networks:
      - reverse-proxy

volumes:
  html:

networks:
  reverse-proxy:
    external:
      name: reverse-proxy

Это означает, что я должен был создать обратный прокси раньше. Я не уверен, что пока это правильно.

Приложения проекта - фронтенд-контейнеры и бэкэнд-контейнеры - создаются моим CI с помощью команд docker (не docker compose):

docker run
  --name project1-one-frontend
  --network reverse-proxy
  --detach
  -e VIRTUAL_HOST=project1.my-server.com
  -e LETSENCRYPT_HOST=project1.my-server.com
  -e LETSENCRYPT_EMAIL=mail@my-server.com
  project1-one-frontend:latest

Как мне разбить это на полезные сети?

Answer 1

... хотел бы настроить сети, такие как прокси, внешний и внутренний. ... Я думаю, что внутренний интерфейс должен быть доступен только для внешнего интерфейса, а внешний интерфейс должен быть доступен для прокси.

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

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

Другими словами, если app-a и app-b не могут общаться друг с другом, но им нужно общаться с общим прокси-сервером, тогда общий прокси-сервер должен быть в нескольких сетях, специфичных для приложения, а не в каждом приложении, находящемся в сети. та же общая прокси-сеть.

Это может быть намного сложнее в зависимости от вашей архитектуры. Например. одна из схем, которую я соблазнил использовать, состоит в том, чтобы каждый стек имел свой собственный обратный прокси-сервер, который подключен к частной сети приложения и к общей прокси-сети без публикации каких-либо портов. Затем глобальный обратный прокси-сервер публикует порт и обращается к каждому обратному прокси-серверу конкретного стека. Преимущество заключается в том, что глобальному обратному прокси-серверу не нужно заранее знать все потенциальные сети приложений, в то же время позволяя вам предоставлять только один порт и не иметь микросервисов, соединяющихся друг с другом через общую прокси-сеть.

Answer 2

TL; DR;Вы можете подключить несколько сетей к определенному контейнеру, что позволит вам в значительной степени изолировать трафик.

полезные сети

Точка контекста, я предполагаю извопрос «полезный» означает, что существует некоторая степень изоляции между службами.

Я думаю, что бэкэнд должен быть доступен только для веб-интерфейса, а веб-интерфейс должен быть доступен для прокси.

Это довольно просто с docker-compose.Просто укажите сети, которые вы хотите на верхнем уровне, так же, как вы сделали для reverse-proxy:

networks:
  reverse-proxy:
    external:
      name: reverse-proxy
  frontend:
  backend:

Тогда что-то вроде этого:

version: '3.5'

services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    networks:
      - reverse-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      ...

  frontend1:
    image: some/image
    networks:
      - reverse-proxy
      - backend

  backend1:
    image: some/otherimage
    networks:
      - backend

  backend2:
    image: some/otherimage
    networks:
      - backend

  ...

Настройте так,только frontend1 может достигать backend1 и backend2 . Я знаю, что это не вариант , так как вы сказали, что запускаете контейнеры приложений (веб-интерфейсы и бэкэнды) через docker run.Но я думаю, что это хорошая иллюстрация того, как примерно достичь того, что вам нужно, в сети Docker.

Так как же вы можете сделать то, что показано в docker-compose.yml выше?Я нашел это: https://success.docker.com/article/multiple-docker-networks

Подводя итог, вы можете подключить только одну сеть, используя docker run, но вы можете использовать docker network connect <container> <network> для подключения работающих контейнеров к большему количеству сетей после их запуска.

Порядок, в котором вы создаете сети, запускаете docker-compose up или запускаете различные контейнеры в своем конвейере, зависит от вас.Вы можете создавать сети внутри docker-compose.yml, если хотите, или использовать docker network create и импортировать их в свой стек docker-compose.Это зависит от того, как вы используете этот стек, и это определит порядок операций здесь.

Наверное правило, очевидно, состоит в том, что сети должны существовать до того, как вы попытаетесь присоединить их к контейнеру.,Самый простой конвейер может выглядеть как ..

1. docker-compose up со всеми сетями, определенными в docker-compose.yml

2. для каждого контейнера приложения:

   docker run контейнер

   docker network attach нужные сети