Проблемы с подчеркиванием в доменном имени

Question

Позвольте мне сначала описать мою первоначальную проблему и решение:

У меня есть несколько файлов docker-compose, которые описывают различные части моего приложения. Части разрабатываются и развертываются независимо, поэтому их нельзя объединить в один составной файл. Но эти компоненты должны взаимодействовать друг с другом, и решение, которое я сейчас использую, состоит в том, чтобы иметь внешнюю сеть (мост), к которой подключаются все сервисы. Пока все хорошо, и я действительно могу подключиться к своему сервису, запущенному с помощью любого файла создания докера, если я подключен к пользовательской мостовой сети:

$ docker run --network=mynet --rm --name ping_test -it xenial-networking bash

root@0319469f7951:/# ping -c 1 proj_web_1
PING proj_web_1 (172.30.0.3) 56(84) bytes of data.
64 bytes from 172.30.0.3: icmp_seq=1 ttl=64 time=0.071 ms

--- proj_web_1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.071/0.071/0.071/0.000 ms

Почему я использую proj_web_1? Потому что это запись DNS, которую создает Docker.

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

Никто ... кроме django кажется:

ERROR Invalid HTTP_HOST header: 'proj_web_1:8000'. The domain name provided is not valid according to RFC 1034/1035.
172.30.0.5 - admin [07/May/2018:05:41:53 +0000] "OPTIONS /api/v1/expansions/ HTTP/1.1" 400 58663 "-" "python-requests/2.18.4"

Похоже, что docker-compose не поддерживает с использованием дефисов вместо подчеркивания.

Возможно, я могу обойти это , включив DEBUG в моем сервисе django.

Есть ли более чистый способ включить это без запуска в режиме отладки django? Есть ли способ заставить docker compose прекратить использовать подчеркивание?

Answer 1

Кросс-составные сетевые подключения

При запуске проекта составления службы доступны как по их полному имени (включая префикс имени проекта, например, myproject_web_1), так и по имени службы (как указано в файле compose), например. web. Краткое имя - псевдоним сети , что означает, что любой контейнер, подключенный к той же сети, может получить доступ к контейнеру через это имя.

По умолчанию docker-compose создает сеть для каждого составного проекта (projectname_default), чтобы все службы в составном проекте могли обмениваться данными. Поскольку эта сеть создается для каждого проекта индивидуально, два составных проекта не совместно используют одну и ту же сеть, а их службы изолированы от других составных проектов.

Однако возможно, чтобы составные проекты (или отдельные службы в составном проекте) находились в одной сети.

Пример 1 - использование общей сети для всего проекта

В следующих файлах составления указано пользовательское имя для сети по умолчанию; оба compose-файла по умолчанию используют сеть sharednet, что означает, что сервисы для обоих проектов compose будут подключены к одной сети:

Создать файл 1 (compose1.yml):

version: '3.5'
services:
  compose1service:
    image: busybox
    tty: true

networks:
  default:
    name: sharednet

Создать файл 2 (compose2.yml):

version: '3.5'
services:
  compose2service:
    image: busybox
    tty: true

networks:
  default:
    name: sharednet

Чтобы проиллюстрировать это:

Запустите оба файла компоновки:

docker-compose -f compose1.yml --project-name=compose1 up -d
docker-compose -f compose2.yml --project-name=compose2 up -d

Использование короткого (compose2service) имени для проверки связи compose2service изнутри службы в контейнере compose1service работает;

docker exec compose1_compose1service_1 ping -c1 compose2service
PING compose2service (172.20.0.3): 56 data bytes
64 bytes from 172.20.0.3: seq=0 ttl=64 time=0.134 ms

--- compose2service ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.134/0.134/0.134 ms

И наоборот:

docker exec compose2_compose2service_1 ping -c1 compose1service
PING compose1service (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: seq=0 ttl=64 time=0.151 ms

--- compose1service ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.151/0.151/0.151 ms

Как и полное имя (включая префикс проекта);

docker exec compose2_compose2service_1 ping -c1 compose1_compose1service_1
PING compose1_compose1service_1 (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: seq=0 ttl=64 time=0.151 ms

--- compose1_compose1service_1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.151/0.151/0.151 ms

Пример 2 - использование общей сети для какой-либо службы в проекте

В этом примере оба составных проекта имеют свою собственную («по умолчанию») сеть, но, кроме того, добавляется общая сеть, чтобы некоторые службы могли подключаться к службам в другом составном проекте.

Создать файл 1 (compose3.yml):

version: '3.5'
services:
  compose3service:
    image: busybox
    tty: true
    networks:
      - default
      - sharednet

  compose3otherservice:
    image: busybox
    tty: true

networks:
  sharednet:
    name: mysharednetwork

Примечание : если вы указываете, к каким сетям должен быть подключен сервис, вы переопределяете значения по умолчанию, что означает, что сервис больше не подключается автоматически к сети default. Включите сеть default в список сетей, чтобы служба могла взаимодействовать с другими службами в составном проекте.

Создать файл 2 (compose4.yml):

version: '3.5'
services:
  compose4service:
    image: busybox
    tty: true
    networks:
      - default
      - sharednet

  compose4otherservice:
    image: busybox
    tty: true

networks:
  sharednet:
    name: mysharednetwork

Запустите оба файла компоновки:

docker-compose -f compose3.yml --project-name=compose3 up -d
docker-compose -f compose4.yml --project-name=compose4 up -d

Опять же, ping из службы compose3service в compose4service в других работах по созданию проекта (либо по короткому имени, либо по полному имени);

docker exec compose3_compose3service_1 ping -c1 compose4service
PING compose4service (172.22.0.3): 56 data bytes
64 bytes from 172.22.0.3: seq=0 ttl=64 time=0.110 ms

--- compose4service ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.110/0.110/0.110 ms


docker exec compose3_compose3service_1 ping -c1 compose4_compose4service_1
PING compose4_compose4service_1 (172.22.0.3): 56 data bytes
64 bytes from 172.22.0.3: seq=0 ttl=64 time=0.093 ms

--- compose4_compose4service_1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.093/0.093/0.093 ms

Однако попытка подключиться к compose4otherservice не удастся, поскольку эта служба не подключена к сети mysharednetwork:

docker exec compose3_compose3service_1 ping -c1 compose4otherservice
ping: bad address 'compose4otherservice'

docker exec compose3_compose3service_1 ping -c1 compose4_compose4otherservice_1
ping: bad address 'compose4_compose4otherservice_1'

Примечание

Следует соблюдать осторожность, если два составных проекта имеют службу с одинаковым именем (например, оба имеют службу с именем web). В таких ситуациях web может произвольно разрешить службу web из любого проекта.

Answer 2

Я могу обойти проблему, используя сетевой псевдоним, избегая подчеркивания:

  web:
    restart: always
    environment:
      - DJANGO_SECRET_KEY=local
      - DJANGO_CONFIGURATION=Develop
    build:
      context: ./
      args:
        - REGISTRY
    image: web
    command: ./run-gunicorn.sh
    volumes:
      - ./:/code
    depends_on:
      - postgres
    networks:
      spp:
        aliases:
          - projweb

И теперь я могу достичь этого:

root@a9c0fde612a1:/# ping -c 1 projweb
PING projweb (172.30.0.4) 56(84) bytes of data.
64 bytes from svc_web_1.spp (172.30.0.4): icmp_seq=1 ttl=64 time=0.082 ms

--- projweb ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.082/0.082/0.082/0.000 ms