docker-compose микросервисная межконтейнерная API-связь с прокси nginx - PullRequest
Новая
       38

docker-compose микросервисная межконтейнерная API-связь с прокси nginx

0 голосов
/ 19 декабря 2018

Я пытаюсь создать файл docker-compose, который будет имитировать мою производственную среду с ее различными микросервисами.Я использую настраиваемую мостовую сеть с прокси-сервером nginx, который перенаправляет запросы портов 80 и 443 в правильные сервисные контейнеры.Файл docker-compose и файлы nginx conf вместе определяют сопоставления портов, которые позволяют прокси-контейнеру направлять трафик для каждой записи DNS в соответствующий контейнер.

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

Кажется, мне нужно добавлять сопоставление портов прокси-сервера к каждому вызову межсервисного API при работе в среде Docker.В моей производственной среде каждая служба имеет свою собственную среду и может отвечать на порты 80 и 443. Поэтому код, написанный для каждой службы, игнорирует спецификации портов и просто вызывает каждую службу по имени узла DNS.Я бы предпочел не добавлять сопоставления идентификаторов портов к каждому вызову API через различные базы кода, чтобы мои службы могли общаться друг с другом в среде Docker.

Существует ли инструмент или параметр конфигурации, который позволитмои микросервисные контейнеры для успешного вызова друг друга в Docker без необходимости использования карты прокси-порта? 

version: '3'

services:
  #---------------------
  # nginx proxy service 
  #---------------------
  nginx_proxy:
    image: nginx:alpine
    networks:
      - test_network
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./site1/site1.test.conf:/etc/nginx/conf.d/site1.test.conf"
      - "./site2/site2.test.conf:/etc/nginx/conf.d/site2.test.conf"
    container_name: nginx_proxy
  #------------
  # site1.test 
  #------------
  site1.test:
    build: alpine:latest
    networks:
      - test_network
    ports:
      - "9001:9000"
    environment:
      - "VIRTUAL_HOST=site1.test"
    volumes:
      - "./site1:/site1"
    container_name: site1.test
  #------------
  # site2.test 
  #------------
  site2.test:
    build: alpine:latest
    networks:
      - test_network
    ports:
      - "9002:9000"
    environment:
      - "VIRTUAL_HOST=site2.test"
    volumes:
      - "./site2:/site2"
    container_name: site2.test

# networks
networks:
  test_network:

1 Ответ

0 голосов
/ 19 декабря 2018

http://hostname/ всегда означает http://hostname:80/ (то есть TCP-порт 80 является портом по умолчанию для URL-адресов HTTP).Поэтому, если вы хотите, чтобы один контейнер мог достигать другого как http://othercontainer/, другой контейнер должен запускать какой-то демон HTTP на порте 80 (что, вероятно, означает, что он должен быть запущен как root в своем контейнере).).

Если ваш прокси-сервер nginx успешно маршрутизирует все контейнеры, нет ничего плохого в том, чтобы просто маршрутизировать весь межконтейнерный трафик через него (в предыдущем поколении технологий мы бы назвали эту служебную шину ).).В Docker нет простого способа сделать это, но вы можете настроить его в качестве стандартного HTTP-прокси.

Я бы предложил сделать так, чтобы все URL-адреса исходящих служб настраивались в любом случае, возможно, в качестве переменных среды.,Вы можете вообразить, что хотите запускать несколько служб вместе в среде разработки (в этом случае URL-адрес службы может быть http://localhost:9002), или в среде чистого Docker, например, как вы показываете (http://otherservice:9000), или в гибридной многопользовательской среде.Настройка хоста Docker (http://other.host.example.com:9002) или в Kubernetes (http://otherservice.default.svc.cluster.local:9000).

...