Как связать Docker-контейнеры, не заставляя приложение читать переменные окружения

[Mutineer]

А зачем докер записывает номер порта в имя переменной окружения? Ведь тогда чтобы узнать номер порта нужно уже знать номер порта, что как-то странно

[masterclass]

В докере встроенный механизм NAT, запись вида 5432:5432 подразумевает, что внешний и внутренний порт (на хосте и внутри контейнера) — 5432. Но возможны варианты что они будут не совпадать. Например, если на одном хосте запускаются два контейнера с базами postgresql — у обоих внутренние порты будут 5432, но внешние порты с хоста будут разные. Подробнее тут: docs.docker.com/reference/builder/#expose

[mickvav]

Эмм, а если в докере встроенный NAT, зачем тогда топикстартеру socat?

[aratak]

Для того, чтобы те службы, которые запущены хрен знает где, были доступны на локалхосте. Другими словами описанным механизмом можно запустить приложение в докере даже если оно и не думало запускаться в докере и не читает настройки подключения к различным сервисам из переменных окружения, а тупо пытается подключиться к локахосту. Хотя, быть может, я не настолько знаком с технологией NAT, чтобы понять ваш вопрос до конца :)

[dvapelnik]

я с такими приложениями не сталкивался — для всех приложений есть конфиг, в котором указывается что куда должно подключаться (IP:port). актуальным использованием вижу такую ситуацию: вы ведете разработку веб-приложения, которое коннетктится к редису, мемкешу, какой-нибудь БД и деплоите это приложение на сервер, где у эти все сервисы запущены на локалхосте, и для того, чтобы было легко деплоить можно сокатом перекидывать всё со слинкованных контейнеров на локалхост главного контейнера — тогда приложение нормально будет деплоиться обычной выгрузкой файлов

я о сокате не знал, а тепер знаю — за это спасибо

[mickvav]

Рискну предположить, что в просто линуксе можно попробовать сказать что-то вроде iptables -t nat -I PREROUTING -i lo -p tcp --dport ПОРТ -j DNAT --to-destination ХОСТ --to-port ПОРТНАХОСТЕ. Может, понадобится что-то ещё, например поменять SNAT- ом адрес отправителя в цепочке POSTROUTING, но тогда все манипуляции будут в ядре, что даст плюс в производительность решения. socat, на мой вкус — скорее быстрый в применении костыль для прототипирования, чем рабочая лошадка.

[Cheater]

Тезис «конфигурировать ПО надо через переменные окружения» — ОЧЕНЬ спорный.

Зависимость приложения от переменных окружения гораздо менее прозрачная, чем от переменных текстового конфига или от входных параметров. В конфиге аккумулированы все переменные (как правило, там указывают абсолютно все параметры и ненужное закомментаривают), он более-менее самодокументирован; в случае же переменных окружения задача аккуратно изолировать их в одном месте ложится целиком на совесть разработчика, и мало кто решает её так, как надо. Гораздо чаще разработчик где-то в глубинах кода втыкает что-то вроде «if $MYENV=xxx», в особо тяжёлых случаях ещё и не документировав MYENV. Особенно этим страдают приложения на интерпретируемых языках.

[aratak]

Кто вам мешает взять лучшее от двух миров?

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

Вот вам достаточно говорящий пример `settings.yml` с erb-шаблонизатором:

github:
  key: <%= ENV.fetch('GITHUB_ID', nil) %>
  secret: <%= ENV.fetch('GITHUB_SECRET', nil) %>

facebook:
  key: <%= ENV.fetch('FACEBOOK_ID', nil) %>
  secret: <%= ENV.fetch('FACEBOOK_SECRET', nil) %>

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

[Cheater]

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

[sllh]

Вообще это костыли, без нормального конфигурейшн-менеждера ни одно приложение не взлетит. Специально под докеры заточены www.ansible.com/home
Все остальное — это «я написал сайт и запихну его в докер, потому что это модно».

[aratak]

Не понимаю сути вашего комментария. Вы хотите сказать, что все, что не управляется шефом-ансиблем-паппетом, то не стоит внимания? Или у вас есть какое-нибудь конструктивное замечание?

[Nail]

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

[neo_13]

Отчего же?
CoreOS использует
Docker Weave
Я думаю, такого «добра» достаточно.

[neo_13]

Неправильно линки оформил
Исправлю положение
CoreOS использует Flannel
Weave отдельный проект
Как по мне, Weave реальный кандидат для применения, для меня, по крайней мере.

[aratak]

Дела с несколькими серверами обстоят точно так же как с докером, так и без докера. Вы же не жалуетесь на мультисерверность архитектуры в обычном случае? У вас всегда есть возможность запустить контейнер с выставленным портом в наружу и задача станет похожей на задачу управления несколькими серверами.

Другое дело, что есть инструменты, которые позволяют создавать свою абстракцию в виде облака серверов, но это уже совсем другая история, которая выходит за рамки этой статьи.

[sandricmora]

Kubernetes скоро из беты выйдет, там нетворкинг вообще из коробки в виде сервисов, который полностью поддерживает спецификацию docker links. А вообще docker пишет свой libnetwork, coreos использует flanneld, существует отдельный weave, да и consul у hashicorp есть (это я про links.sh). Ambassador паттерн был актуален где то год назад. Статья немного запоздала imho (точнее не запоздала, а показала реализацию того, что все написали еще год назад).

[shuron]

Это типа вариант Ambassador pattern

[Eternalko]

Первая статья на хабре про докер которая о чем-то новом и интересном.