У меня есть docker -композитный файл, который использует jwilder/nginx-proxy для предоставления ssl для образа Artifactory, который у меня запущен.
Все отлично работает из соединений вне контейнеров среды компоновки. Так что мой браузер может нормально загружать веб-приложение Artifactory, оно ssl-шифруется, и все API работает нормально из инструментов командной строки.
Проблема в том, что если я нахожусь внутри одного из контейнеров в среде Я могу пропинговать другие контейнеры в среде, но если я пытаюсь загрузить страницу из контейнера Artifactory, я получаю ошибки, говорящие об отказе в соединении.
Вот мой файл compose:
version: '3'
services:
nginx-proxy:
image: jwilder/nginx-proxy
container_name: nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- /var/run/docker.sock:/tmp/docker.sock:ro
- ./assets/certs:/etc/nginx/certs
depends_on:
- artifactory
artifactory:
image: docker.bintray.io/jfrog/artifactory-pro:latest
volumes:
- artifactory5_data:/var/opt/jfrog/artifactory
environment:
- VIRTUAL_HOST=artifactory.test
- VIRTUAL_PORT=8081
depends_on:
- node
node:
build:
context: ./nodes
dockerfile: Dockerfile
volumes:
artifactory5_data:
Dockerfile, который создает node, является просто экземпляром puppet/puppet-agent-ubuntu со сценарием точки входа, который зацикливает выполнение кукол, чтобы сохранить контейнер открытым.
Команда, которую я использую для запуска среды:
docker-compose --project-name preso up -d --scale node=3
Creating network "preso_default" with the default driver
Creating preso_node_1 ... done
Creating preso_node_2 ... done
Creating preso_node_3 ... done
Creating preso_artifactory_1 ... done
Creating nginx-proxy ... done
docker ps --all --no-trunc
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d390506f4149b6f386376f94dad1c2d34cce11d869b2033e72646856c5f9a47b jwilder/nginx-proxy "/app/docker-entrypoint.sh forego start -r" 45 seconds ago Up 43 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp nginx-proxy
1695bc05d4bd1ea0c08ec82b636ce5847649f9aa8b48814d44d5986c8577f29d docker.bintray.io/jfrog/artifactory-pro:latest "/entrypoint-artifactory.sh" 46 seconds ago Up 43 seconds 8081/tcp preso_artifactory_1
291965e80148f4670b32ef0bded891c79ef361161d3860fd33707f4805d004f0 preso_node "/bin/bash /entrypoint.sh" 47 seconds ago Up 44 seconds preso_node_3
d81f4e2a22b5d8e56e8764029f5ae0b0666e353937a70c825cce1a2c5d2d1f3a preso_node "/bin/bash /entrypoint.sh" 47 seconds ago Up 44 seconds preso_node_2
b64038d2c3ca32939686eb2cc9324cc5e935df5445570a8746d80c527b3fe95d preso_node "/bin/bash /entrypoint.sh" 47 seconds ago Up 44 seconds preso_node_1
Artifactory прекрасно загружается из командной строки на моем локальном компьютере и в браузере, но из bash внутри одного из node контейнеров, которые я получаю:
curl --insecure https://artifactory.test/artifactory
curl: (7) Failed to connect to artifactory.test port 443: Connection refused
Пинг получает меня:
Pinging artifactory.test [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Обновление : я попытался добавить имя хоста nginx -proxy в файл hosts контейнера:
echo 'nginx-proxy artifactory.test' >> /etc/hosts
Это не получилось т о работа. Pinging artifactory.test теперь по-прежнему отправляет соединения на localhost:
Pinging artifactory.test [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
При проверке pinging nginx -proxy возвращает:
Pinging nginx-proxy [172.21.0.6] with 32 bytes of data:
Reply from 172.21.0.6: bytes=32 time=0ms TTL=128
Примечание. Теперь я вижу, что при попытке перенаправить одно имя хоста к другому через хосты никогда не будет работать.
Если я добавлю IP-адрес в качестве записи hosts-файла в artifactory.test, то все будет работать именно так, как и должно.
Проблема с этим подходом Я не знаю, насколько надежно этот адрес будет назначен контейнеру nginx -прокси в среде. Если я соберу вход этих хостов в контейнеры node, он всегда будет работать?