Stepan
Ну когда я делаю docker run, я же не переопределяю энтрипоинт
Павел
либо command:, на самом деле.
Sergei
https://docs.docker.com/compose/compose-file/#/command
Stepan
да, в этом случае мне тоже нужно явно указать энтрипоинт получается
Павел
не-не, Сергей правильно сослался на документацию к command:
Stepan
я имею в виду, что мне нужно знать и явно указать как запускается image?
Павел
ну вот аналогом docker run image arg1 arg2 будет директива command: arg1 arg2
Stepan
например в image есть какой-то энтрипоинт и я его запускаю через docker run передавая аргументы
Stepan
а-а-а-а
Stepan
т.е. эти аргументы будут передаваться в энтрипоинт указанный в image?
Павел
энтрипоинт тут ни при чем, равно как и переменные окружения.
Stepan
просто в примере первым параметром идёт bundle, а это выполняемая программа
Павел
просто в примере первым параметром идёт bundle, а это выполняемая программа
если для образа установлен entrypoint cmd то при запуске docker run image arg1 arg2 стартует cmd arg1 arg2, аналогично с command: arg1 arg2 если entrypoint не установлен, то, емнип, произойдет попытка выполнить arg1 arg2 как есть.
Stepan
О, теперь понял. Спасибо, @pavel_sutyrin! Пойду тыкать
Aleksey
господа, там чо то докер говорит про экспериментал фичу HTTP Routing Mesh (HRM)
Aleksey
чего это ?
Aleksey
а то вдруг мне ее надо срочно в прод!
Aleksey
о
Aleksey
The HTTP Routing Mesh works on the application-layer (L7) where the admin assigns a label to the service that corresponds to the host address. The external load balancer routes the hostnames to the nodes and the Routing Mesh send the traffic across the nodes in the cluster to the correct containers for the service.
Stepan
Можно ещё один нубский вопрос? Как мне лучше поступить, если у меня много однотипных приложений в контейнерах, которые я поднимаю docker-compose и все они работают на одном порту? Маппить кучу хостовых портов и писать большой конфиг для нджинкс, в котором у серверов отличается только порт кажется глупым. Раньше приложения слушали на юникс сокетах и нджинкс проксировал запросы к сокетам, но если я запускаю приложение в контейнере слушаюшим сокет и кладу этот сокет в volume, я не могу достучаться до приложения с хостовой машины. Кто-нибудь может что-нибудь посоветовать?
Alf 🙀
-v /tmp/file.sock:/tmp/file.sock
Alf 🙀
Типа такого
Stepan
О, сейчас попробую
Alf 🙀
Посмотри синтаксис композа
Alf 🙀
Как там точно
Stepan
Как я понял, такой синтаксис используется для примонтирования хостового файла в контейнер, у меня-же обратная ситуация, мне нужно чтобы сокет из контейнера был доступен в хостовой машине
Stepan
Отличие в том, что с таким синтасисом создается _директория_ /tmp/file.sock на хосте, а не копируется файл из контейнера
Denis
промаунти диру в которой будет сокет и всё
Stepan
не работает
Denis
что не работает то
Stepan
Когда я делаю на хосте "curl --unix-socket  /tmp/app.socket "http:/..."  у меня curl: (7) Couldn't connect to server Если я то же самое делаю в контейнере, то всё окей
Stepan
т.е. если сокет внутри volume, то я не могу с хоста через него общаться
Denis
хм
Denis
а это наверно логично.
Denis
ща.
Stepan
Логично, согласен :)
Denis
ну да
Denis
это ж ipc
Denis
они типа в разных неймспейсах наверно
Stepan
похоже
Stepan
и что лучше сделать?
Stepan
контейнеры ведь могут друг с другом через сокеты общаться?
Denis
для теста в докер ране сказать ipc="host"
Denis
--ipc
Stepan
Всё равно curl: (7) Couldn't connect to server
Stepan
docker-compose.yml: version: '2' services: app: build: . ipc: host volumes: - "./tmp:/tmp/"
Alf 🙀
Видать остается прибивать порты и роутить их через проксирующий нгинкс
Denis
сокеты же это ipc ? поидее если ipc=host то сокет созданный контейнером должен ок читаться и на хосте, нет разве ?
Roman
-v /tmp/file.sock:/tmp/file.sock
Никогда не делай так
Roman
Почему?
Перезапусти слушающий процесс в контейнере и все развалится.
Alf 🙀
Перезапусти слушающий процесс в контейнере и все развалится.
Зачем перезапускаешь процесс в контейнере? Оно(контейнер) не для того
Evgeny
Он может перезапуститься сам
Stepan
В итоге я отказался от идеи с сокетами. Вместо этого решил поднять ещё один контейнер с нджинксом и пытаюсь проксировать запросы к приложениям по имени хоста
Stepan
Но не тут-то было!
Stepan
…no resolver defined to resolve <container>!
Stepan
В сети предлагают ставить dnsmasq в контейнер с нджинксом
Alf 🙀
Он может перезапуститься сам
При перезапуске процесса в контейнере котейнер должен перезапуститься, нет?
Roman
В сети предлагают ставить dnsmasq в контейнер с нджинксом
Нет, для dnsmasq нужен отдельный контейнер
Dan
…no resolver defined to resolve <container>!
server { location ~ ^/some_url/(.*)$ { resolver 127.0.0.1; proxy_pass http://container1/$1; } }
Roman
server { location ~ ^/some_url/(.*)$ { resolver 127.0.0.1; proxy_pass http://container1/$1; } }
И куда указывает 127.0.0.1 в контейнере? :)
Dan
в dnsmasq
Stepan
если просто указать resolver 127.0.0.1, то не работает потому-что нужен dnsmasq?
Stepan
Нет, для dnsmasq нужен отдельный контейнер
это шутка или так правда нужно? :D
Roman
это шутка или так правда нужно? :D
50/50. Одепты утверждают что 1 сервис - 1 процесс
Stepan
как тогда нджинкс узнает айпи контейнера с dnsmasq?
Roman
Что делать с тем же кроном в контейнере?
Stepan
я докер-композ использую, если это важно
Alf 🙀
У тебя все в композе ты можешь внутри композа ходить по именам контейнеров если они у тебя есть в links
Stepan
по именам-то я хожу, но нджинкс не резолвит по именам без днс
Stepan
т.е. приложения отвечают при запросе из нджинкс контейнера типа curl http://<container>:4000/...
Stepan
а вот сам нджинкс их не видит
Andrey
В итоге я отказался от идеи с сокетами. Вместо этого решил поднять ещё один контейнер с нджинксом и пытаюсь проксировать запросы к приложениям по имени хоста
так --link поди не указал, никакой dns в общем то не нужен, для базового взаимодействия контейнеров там всё что надо докер умеет сам
Aleksey
мне иногда кажется что перед использованием докера надо форматировать мозг.