Типа такого

О, сейчас попробую

Посмотри синтаксис композа

Как там точно

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

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

а в чем отличие ?

Отличие в том, что с таким синтасисом создается _директория_ /tmp/file.sock на хосте, а не копируется файл из контейнера

промаунти диру в которой будет сокет и всё

не работает

что не работает то

Когда я делаю на хосте "curl --unix-socket  /tmp/app.socket "http:/..."  у меня curl: (7) Couldn't connect to server Если я то же самое делаю в контейнере, то всё окей

т.е. если сокет внутри volume, то я не могу с хоста через него общаться

хм

а это наверно логично.

ща.

Логично, согласен :)

ну да

это ж ipc

они типа в разных неймспейсах наверно

похоже

и что лучше сделать?

контейнеры ведь могут друг с другом через сокеты общаться?

для теста в докер ране сказать ipc="host"

--ipc

Всё равно curl: (7) Couldn't connect to server

docker-compose.yml: version: '2' services: app: build: . ipc: host volumes: - "./tmp:/tmp/"

Видать остается прибивать порты и роутить их через проксирующий нгинкс

сокеты же это ipc ? поидее если ipc=host то сокет созданный контейнером должен ок читаться и на хосте, нет разве ?

-v /tmp/file.sock:/tmp/file.sock

Никогда не делай так

Никогда не делай так

Почему?

Почему?

Перезапусти слушающий процесс в контейнере и все развалится.

Перезапусти слушающий процесс в контейнере и все развалится.

Зачем перезапускаешь процесс в контейнере? Оно(контейнер) не для того

Он может перезапуститься сам

В итоге я отказался от идеи с сокетами. Вместо этого решил поднять ещё один контейнер с нджинксом и пытаюсь проксировать запросы к приложениям по имени хоста

Но не тут-то было!

…no resolver defined to resolve <container>!

В сети предлагают ставить dnsmasq в контейнер с нджинксом

Он может перезапуститься сам

При перезапуске процесса в контейнере котейнер должен перезапуститься, нет?

В сети предлагают ставить dnsmasq в контейнер с нджинксом

Нет, для dnsmasq нужен отдельный контейнер

…no resolver defined to resolve <container>!

server { location ~ ^/some_url/(.*)$ { resolver 127.0.0.1; proxy_pass http://container1/$1; } }

server { location ~ ^/some_url/(.*)$ { resolver 127.0.0.1; proxy_pass http://container1/$1; } }

И куда указывает 127.0.0.1 в контейнере? :)

в dnsmasq

В сети предлагают ставить dnsmasq в контейнер с нджинксом

https://github.com/aacebedo/dnsdock

если просто указать resolver 127.0.0.1, то не работает потому-что нужен dnsmasq?

Нет, для dnsmasq нужен отдельный контейнер

это шутка или так правда нужно? :D

это шутка или так правда нужно? :D

50/50. Одепты утверждают что 1 сервис - 1 процесс

как тогда нджинкс узнает айпи контейнера с dnsmasq?

Что делать с тем же кроном в контейнере?

я докер-композ использую, если это важно

У тебя все в композе ты можешь внутри композа ходить по именам контейнеров если они у тебя есть в links

по именам-то я хожу, но нджинкс не резолвит по именам без днс

т.е. приложения отвечают при запросе из нджинкс контейнера типа curl http://<container>:4000/...

а вот сам нджинкс их не видит

В итоге я отказался от идеи с сокетами. Вместо этого решил поднять ещё один контейнер с нджинксом и пытаюсь проксировать запросы к приложениям по имени хоста

так --link поди не указал, никакой dns в общем то не нужен, для базового взаимодействия контейнеров там всё что надо докер умеет сам

мне иногда кажется что перед использованием докера надо форматировать мозг.

просто тупо в ноль

Зачем? :)

ибо из полезных знаний нужно только архитектура пс и юникса

думаешь одного мозга хватит, без целительно эвтаназии?

а вот поведенческие реалии надо удалять

как гланды

Зачем? :)

Степан, докер _требует_ принципиально другого подхода.

а это ведь всякие свармы пока относительно экзотика

Степан, докер _требует_ принципиально другого подхода.

Какого?

можно принести с собой старые игрушки в песочницу, но играть там будет не интересно.

как получше то объяснить ?

ERROR: S client not available

если добавить links, nginx в контейнере всё равно не резолвит остальные контейнеры по хостнеймам

надо обязательно считать что у вас микросервисы. и горизонтальная масштабируемость

я вот как то пока не могу для себе обосновать, зачем нгинкс, вообще туда пихать, ну кроме как в случае чтоб красиво пруф оф концепты показывать

и еще считать что _всё_ не локальное.

и что писать на винт _нельзя_

если добавить links, nginx в контейнере всё равно не резолвит остальные контейнеры по хостнеймам

ну покажи уж что ли композ свой

version: '2' services: galton_nginx: image: nginx container_name: galton_nginx ports: - "4000:80" volumes: - ./default.conf:/etc/nginx/conf.d/default.conf links: - moscow_russia_car moscow_russia_car: image: urbica/galton hostname: moscow_russia_car container_name: moscow_russia_car volumes: - ./extracts:/extracts - ./data/moscow_russia_car:/data command: ["https://s3.amazonaws.com/metro-extracts.mapzen.com/moscow_russia.osm.pbf", "car"] как-то так

и что писать на винт _нельзя_

Что?

Что?

а вот так. писать можно только в базу данных.

которая не в докере.

а вот так. писать можно только в базу данных.

И логи тоже?

version: '2' services: galton_nginx: image: nginx container_name: galton_nginx ports: - "4000:80" volumes: - ./default.conf:/etc/nginx/conf.d/default.conf links: - moscow_russia_car moscow_russia_car: image: urbica/galton hostname: moscow_russia_car container_name: moscow_russia_car volumes: - ./extracts:/extracts - ./data/moscow_russia_car:/data command: ["https://s3.amazonaws.com/metro-extracts.mapzen.com/moscow_russia.osm.pbf", "car"] как-то так

вроде похоже на правду, а имена попроше не пробовал, ну или пингануть из тестового контейнера

цепочка рассуждений выглядит так 1. докер непременно сломается. 2. ваш баг будет уникальный и его починят через 3 месяца минимум 3. ваш баг будет мешать вам жить два раза в день 4. для решения проблем вам надо будет перезагрузить хост 5. перезагрузка хоста — простой 6. данные надо хранить 7. идеальный файловых систем которые позволяет писать в сеть пока нету. но есть условно не плохие. но сложные. 8. докер очень не простой способ стрельнуть себе в ногу. 9. я за докер :) #docker #молодец #этаужасно

И логи тоже?

и логи тоже.

вроде похоже на правду, а имена попроше не пробовал, ну или пингануть из тестового контейнера

из контейнера всё пингуется, проблема не в докере, а в нджинксе, который не резолвит контейнеры по именам

враньё всё он пингует

и поэтому надо куда-то прикручивать днс-маск

ресолвит

и поэтому надо куда-то прикручивать днс-маск

надо выкинуть линки

и заменить их на network диретиву

тогда включится внутренний днс и все будет хорошо

такого я ещё не пробовал

и логи тоже.

Чем и в какую базу вы пишите логи из доккер контейнера? Как оно ведет себя при падении сети на хосте? Как оно ведет себя при падении базы?

Чем и в какую базу вы пишите логи из доккер контейнера? Как оно ведет себя при падении сети на хосте? Как оно ведет себя при падении базы?

в journal

у меня работает так: nginx: restart: always hostname: nginx privileged: true image: serhio/openresty:somaxconn ports: - 80:80 - 443:443 - 7013:7013 - 7015:7015 - 7020:7020 links: - "phpfpm0:php0" в конфиге nginx upstream backend { least_conn; server php0:9000; }

из него journalbeat

Ясно понятно спасибо

Степан, докер _требует_ принципиально другого подхода.

Во многих моментах докер - это шаг назад

Во многих моментах докер - это шаг назад

ага да.

но он упрощает деланье демо.

да ты шо, а пацаны то и не знали