icoz 28 дек 2014 в 02:34

Docker, SkyDNS и SkyDock — быстро и удобно

4 мин

33K

Виртуализация*DNS*

Туториал

+20

Комментарии 82

foxmuldercp 28 дек 2014 в 14:06

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

Я вот не знаю что делать в чуть другой ситуации:
Вот, допустим есть у меня 10-100-1000 контейнеров…
Но те две веб мордашки, что я пытался использовать для их руления — у меня так и не завелись…

icoz 28 дек 2014 в 14:17

Давайте по порядку:
1) уточните как «можно автоматизировать через штатную систему инициализации дистрибутива»? Самому это интересно. Да и что за дистрибутивы? Специальные типа CoreOS?
2) какие веб-мордашки вы использовали? точнее, пытались использовать…

yurtaev 28 дек 2014 в 14:24

1) уточните как «можно автоматизировать через штатную систему инициализации дистрибутива»? Самому это интересно. Да и что за дистрибутивы? Специальные типа CoreOS?

init.d, supervisord, systemd и т.д docs.docker.com/articles/host_integration/

icoz 28 дек 2014 в 14:30

Спасибо, не читал такой статьи.
Но, думаю, основная суть тут в фразе:

As of Docker 1.2, restart policies are the built-in Docker mechanism for restarting containers when they exit. If set, restart policies will be used when the Docker daemon starts up, as typically happens after a system boot. Restart policies will ensure that linked containers are started in the correct order.

farcaller 29 дек 2014 в 16:45

У меня вот такой шелл скрипт мониторит докер из runit, устанавливается в систему через ansible.

#!/bin/bash

CONTAINER_NAME=$name

ifconfig eth1 >/dev/null 2>&1
if [[ $$? -eq 0 ]]; then
  PUBILC_IF=eth0
  PRIVATE_IF=eth1
else
  PUBILC_IF=eth0
  PRIVATE_IF=eth0
fi

case "$announce_as" in
  public)  ANNOUNCE_IP="`ifconfig $$PUBILC_IF | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\\2/p'`"
           ;;
  private) ANNOUNCE_IP="`ifconfig $$PRIVATE_IF | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\\2/p'`"
           ;;
        *) ANNOUNCE_IP=""
           ;;
esac

docker inspect $$CONTAINER_NAME|grep State >/dev/null 2>&1
if [ $$? -eq 0 ]; then
  docker rm $$CONTAINER_NAME || { echo "cannot remove container $$CONTAINER_NAME"; exit 1; }
fi

docker pull $image

exec docker run \
-i --rm \
--name $$CONTAINER_NAME \
--hostname "`hostname`-$name" \
$args \
$image

а рядом лежит вот этот и обновляет skydns:

#!/bin/bash

ETCD="http://192.168.1.1:4001"
DOMAIN="net/ihdev/prod/s/$name/`hostname`"

ifconfig eth1 >/dev/null 2>&1
if [[ $$? -eq 0 ]]; then
  PUBILC_IF=eth0
  PRIVATE_IF=eth1
else
  PUBILC_IF=eth0
  PRIVATE_IF=eth0
fi

case "$announce_as" in
  public)  ANNOUNCE_IP="`ifconfig $$PUBILC_IF | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\\2/p'`"
           ;;
  private) ANNOUNCE_IP="`ifconfig $$PRIVATE_IF | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\\2/p'`"
           ;;
        *) ANNOUNCE_IP=""
           ;;
esac

enable -f /usr/lib/sleep.bash sleep

trap "{ curl -L "$$ETCD/v2/keys/skydns/$$DOMAIN" -XDELETE ; exit 0; }" SIGINT SIGTERM

while true; do
  if [[ "$announce_as" == "container" ]]; then
    ANNOUNCE_IP="`docker inspect --format '{{ .NetworkSettings.IPAddress }}' $name`"
  fi
  curl -L "$$ETCD/v2/keys/skydns/$$DOMAIN" -XPUT -d value="{\\"host\\": \\"$$ANNOUNCE_IP\\", \\"port\\": $port}" -d ttl=60 >/dev/null 2>&1
  sleep 45
done

dvapelnik 28 дек 2014 в 14:28

не советовал бы знакомиться с прелестями Docker на основе готовых решений с копипастом команд для запуска контейнера
намного интереснее и полезнее реализовать некоторую рутинную задачу в контейнере. для меня это запуск контейнеров с различными версиями ПО для вебразработки. пока дифференциация ПО заключается только в версиях PHP (5.3, 5.4, 5.5). для того, чтобы запустить проект на некоторой версии PHP — запускаем контейнер с этим сетапом ПО

icoz 28 дек 2014 в 14:42

Вы не поверите, но для меня при первом знакомстве с docker самой большой проблемой было узнать IP контейнера, чтобы суметь подключиться по ssh.
docker ps адреса не показывает. Единственное, что я сходу нашел — это docker inspect cont_name.
Поэтому первое время использовал docker inspect cont_name | grep IPAddr, пока не начитал достаточное количество документации и статей. Узнал, что есть docker attach cont_name.

quozd 28 дек 2014 в 14:45

Где-то читал, что ходить в контейнер по ssh — не правильный форкфлоу в абсолютном большинстве случаев и можно обойтись без этого.

icoz 28 дек 2014 в 14:51

Я тоже «где-то читал». Но при первом знакомстве с контейнерами где об этом узнать?
Даже man docker нет!

А про правильный воркфлоу статей что-то не особо видно…
Хм… А это мысль!

quozd 28 дек 2014 в 14:52

Пишите! С удовольствием почитал бы.

icoz 28 дек 2014 в 14:53

Я и сам бы с удовольствием почитал бы. Жаль времени крайне мало на это всё… :(

dvapelnik 6 янв 2015 в 17:12

кстати, вот нашел в своих закладках ссылку «If you run SSHD in your Docker containers, you're doing it wrong!»

dvapelnik 28 дек 2014 в 14:52

для начала можно просто запустить контейнер (все по ману)

$ sudo docker run -it imageName /bin/bash

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

$ sudo docker attach containerId

на заметку: узнать IP можно без грепа:

sudo docker inspect --format='{{.NetworkSettings.IPAddress}}' containerId

icoz 28 дек 2014 в 15:04

Параметр -it — это не поведение по умолчанию, что прискорбно для начинающего.
Вот про концепцию мало концентрированной информации, тем более на русском языке. А для человека много использовавшего виртуализации в том или ином виде — ssh вполне естественная вещь.
А про формат спасибо, кину в свою копилку знаний!

НЛО прилетело и опубликовало эту надпись здесь

icoz 28 дек 2014 в 15:21

Ну плохое на мой взгляд там есть — это оверхед на шифрование трафика, а поскольку это и так происходит на одной машине, то зачем он?
Хотя для тех, кто знакомится с докером, ничего страшного в этом нет. Всё равно, когда дойдет дело до продакшена, там уже все допрут до понимания ненужности оверхеда на ssh.

НЛО прилетело и опубликовало эту надпись здесь

dvapelnik 28 дек 2014 в 15:22

лично я вижу резон в работе с контейнером по ssh только в том случае, когда нужно достучаться к контейнеру, который развернут на удаленной машине таким образом, чтобы не было возможности попасть в консоль самой машины
тоесть, если есть домашний laptop, есть server, есть container и Вы — владелец server — не хотите давать доступ к server третьему лицу, которому нужно дать доступ c laptop к container. в таком случае, вы поднимаете на container ssh и прокидываете его порт на интерфейс server. laptop подключается к этому порту и попадает в container по ssh — вот и виртуализация на основе Docker

НЛО прилетело и опубликовало эту надпись здесь

icoz 28 дек 2014 в 15:44

Разумно. А я вот еще размышлял на тему, но пока не нашел красивого решения.
Есть laptop и server. Лениво лезть в консоль сервера для того, чтобы стянуть и запустить какой-то контейнер. Хочется запустить docker-cli на laptop, чтобы он отдавал команды docker-демону на server. Такое насколько просто замутить можно?

НЛО прилетело и опубликовало эту надпись здесь

dvapelnik 28 дек 2014 в 15:17

не по умолчанию, возможно
возможно, Вы не знали или не дошли до мануала. так вот, на сайте Docker.com есть ссылка на маны по приложению. там довольно много информации, которая очень помогает даже если с первого прочтения не ясно что это и для чего это. Потом, когда слалкиваешся с вопросом, то всплывает ман. Согласен, сначала несколько трудно и непривычно понять концепцию контейнеров, но постепенно начинаем думать в этом русле и все становится прекрасным, но с некотороыми нюансами
в частности, в разделе Dockerizing Applications есть описание использование ключей -i, -t.
Еще совет: если вы просто запустите приложение

$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world'

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

$ sudo docker run --rm ubuntu:14.04 /bin/echo 'Hello world'

shuron 28 дек 2014 в 22:36

$docker exec -it containerId /bin/bash

и вы попадете в бегущий контейнер…
Работает с версии 1.3.0 если не ошибаюсь… именно для того чтоб люди контейнеры SSH не засоряли.
P.S. пишу не только вам. Просто втреде не увидел ссылки на команду exec

grossws 4 янв 2015 в 19:52

До 1.3 простые люди делали это же просто через nsenter.

Релевантный кусок .bashrc/.zshrc:

nse() {
  if [ $# -lt 2 ] ; then
    echo "usage: nse container command args..."
  else
    container=$1
    shift
    sudo nsenter --pid --uts --mount --ipc --net --target $(docker inspect --format="{{ .State.Pid }}" $container) "$@"
  fi
}

НЛО прилетело и опубликовало эту надпись здесь

cy-ernado 28 дек 2014 в 14:55

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

Nepherhotep 28 дек 2014 в 15:08

Не повторяет ли SkyDNS линкование контейнеров? Если да, то в чем преимущество?

icoz 28 дек 2014 в 15:35

Не повторяет. Это DNS-сервис. Линкование — это механизм сообщения контейнеру адреса, порта, протокола посредством переменных окружения.
Данные переменные выставляются только в момент запуска контейнера.
Теперь представим, что у нас есть два контейнера:

docker run -d --name db some_db
docker run -d --name web --link db:db some_web_app

В случае когда упадет контейнер с именем db и будет перезапущен, нет гарантий, что он будет иметь тот же IP, что до перезапуска. Значит контейнер с именем web будет смотреть в никуда, ведь ему никто не поправил переменные окружения. Да даже если и поправил, то само приложение должно быть разработано таким образом, чтобы периодически перечитывать переменные окружения.

Со skydns+skydock нам достаточно при сборке контейнера web в настройках задать, чтобы он всегда ломился на адрес some_db.dev.docker. Даже в случае перезапуска контейнера с базой приложение достаточно быстро узнает новый IP.

Собственно skydns+skydock реализуют простой вариант service discovery. Для разработки или для побаловаться дома, не сильно забивая себе голову, этого более чем достаточно.

yurtaev 28 дек 2014 в 16:13

Рекомендую посмотреть в сторону fig и то как у них сделана линковка, а также docs.docker.com/reference/run/#managing-etchosts

icoz 28 дек 2014 в 18:50

На fig уже смотрел, но пока не вкурил.
А вот с etchosts проблема та же — если у хоста с БД сменится айпишник, то внутри контейнера это опять же никто не поправит!

yurtaev 28 дек 2014 в 19:17

Я понимаю о какой вы проблеме, но эта проблема устарела и решается стандартными средствами линковки docs.docker.com/userguide/dockerlinks/#container-linking (то что fig и использует), а вот что интереснее, это как линковать контейнеры на разных хостах.

Nepherhotep 28 дек 2014 в 20:07

А можно по-подробнее? Для чего тогда fig, если это стандартное средство линковки?

yurtaev 28 дек 2014 в 20:19

Fig нужен для того что бы описать окружение приложения и связи с другими контейнерами, по сути делает всё то что можно сделать руками, но в более человечком виде. Мне например комфортнее описать один yml файл с необходимыми параметрами чем запускать docker и передавать кучу аргументов.

P.S на 2015 год намечается расширение функционала для управления кластером github.com/docker/docker/issues/9459 + в туже сторону docker swarm & machine.

Nepherhotep 28 дек 2014 в 20:27

т.е. фактически это аналог (в некотором смысле) амазоновского task definition из ECS. А что насчет линковки — если слинкованый контейнер будет перезапущен, то в другом обновится hosts?

yurtaev 28 дек 2014 в 20:45

ECS мне не понравился, очень сыро и опять делают не так как у всех. Хотя docker machine тоже очень сырой.

По ссылке выше:

If you restart the source container, the linked containers /etc/hosts files will be automatically updated with the source container's new IP address, allowing linked communication to continue.

Nepherhotep 28 дек 2014 в 21:09

Спасибо за пояснение.
Что касается ECS, то да — сыровато, но на то оно и preview. В целом сервис выглядит довольно многообещающим, если они реализуют заявленные плюшки — интеграцию с cloudwatch, логи и т.п.

icoz 28 дек 2014 в 21:44

Ещё чуть-чуть добавлю.
fig — это средство для оркестрации (orchestration, хотя я бы дал термин дирижирование), т.е. для управления самими контейнерами, их настройками и связями.
Например, можно в удобной декларативной форме описать несколько контейнеров на базе одного образа, но с разными переменными окружения, задать взаимосвязи между ними…

Я вот всё хочу выделить немного времени и поднять с его помощью свой домашний миникластер монги, а для этого надо сделать пару шардов по 2 реплики + 1 арбитр, а это:
1) на базе mongod поднять 4 БД
2) на базе mongod поднять 2 арбитра
3) поднять mongos и передать ему настойки тех реплик
Вот как-то так…

Nepherhotep 28 дек 2014 в 22:53

Это уже интереснее. А как реализовать паттерн, когда во время запуска контейнера, нужно вызвать хук? Т.е. понятно, что можно городить свои костыли, запуская не супервизор, а специальный лаунч скрипт, который будет выполнять хук, но есть ли штатное средство для этого? В моем случае — хук должен сделать дамп базы данных и выполнить миграции, в некоторых случаях также переиндексировать документы.

НЛО прилетело и опубликовало эту надпись здесь

icoz 28 дек 2014 в 23:13

В том-то и дело, что это при сборке, а не при деплое!
Вы же не на каждый случай собираете новый образ?
В том-то и смысл, чтобы сделать один образ и запускать однотипные контейнеры с разным обвязом…
Плюс время на сборку, на раскатывание образа по машинам.

НЛО прилетело и опубликовало эту надпись здесь

Nepherhotep 28 дек 2014 в 23:23

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

Nepherhotep 28 дек 2014 в 23:27

А разве CMD — это не просто параметр, которые передается ENTRYPOINT? Т.е. к примеру CMD у меня запуск супервизора ['supervisord', '-n'] (реальный запуск выглядит так — /bin/sh -c 'supervisord -n', т.к. ENTRYPOINT не переопределен), а мне нужно еще хук после запуска, но CMD уже «занят».

icoz 29 дек 2014 в 00:01

С ENTRYPOINT и CMD есть интересная хитрость — поведение docker run с параметрами будет разным.

Напомню usage:

Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Варианты:
1) При использовании только CMD при задании параметров COMMAND и ARGS они заменят команду в CMD.
2) При использовании только ENTRYPOINT параметры не играют роли вообще — они игнорируются.
3) А вот вариант использования и CMD, и ENTRYPOINT рассмотрим подробнее.
Допустим у нас есть Dockerfile с таким содержимым:

ENTRYPOINT ['python', 'app.py']
CMD ['--help']

При простом запуске docker run my_app будет выполнена команда python app.py --help
При запуске docker run my_app --some-param будет выполнена команда python app.py --some-param.
Таким образом при помощи CMD можно менять параметры для ENTRYPOINT. Весьма интересная и удобная идея. Я таким хаком уже пользуюсь.

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

CMD ['python', 'init_db.py']
ENTRYPOINT ['python', 'app.py']

Хм… Будет время, проверю.

icoz 28 дек 2014 в 23:09

Это те вопросы, которые сейчас решает сообщество.
Есть куча уже решений для оркестрации: fig, crane, fleet из CoreOS…
И это только те, про которые я слышал и вспомнил сходу…

А так, посмотрите видео:
Docker & Puppet — как их скрестить и надо ли вам это

Видео с DevOps Meetup:
Jérôme Petazzoni, Docker, «Sysadmin tasks with Docker, aka „life without SSH“»

Docker в Badoo: от восторгов к внедрению

Teaching Dockers to use CRanes | Оснастите свои доки кранами

icoz 28 дек 2014 в 23:47

Вот ещё интересные слайды в тему.

Nepherhotep 29 дек 2014 в 00:01

Отличная подборка, спасибо!

icoz 29 дек 2014 в 00:09

Если интересно, то могу значительно побольше понаподбирать.
Кстати, очень рекомендую посмотреть цикл лекций по БД от Ильи Тетерина. Крайне интересно рассказывает.

Nepherhotep 29 дек 2014 в 00:54

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

icoz 29 дек 2014 в 02:07

An Overview And Demo Using Fig + Docker + Django

Docker for Developers — Jérôme Petazzoni

Docker Global Hack Day: Host Management by Nathan LeClaire

Docker Global Hack Day: Clustering by Andrea Luzzardi and Victor Vieux

Docker Global Hack Day #2: Full-length Presentation from San Francisco

Да и много чего интересного можно найти по «Docker Global Hack Day».

shuron 28 дек 2014 в 22:44

Может я что-то неправильно делал но если я перестартовывал аппликационный контейнер на ПХП то БД перестовала находится…
Все востанавливалось только после полной перестартовки всей цепочки… Может была специфика какая… но вот именно в этом фиг обломал меня…
Вы сами пробывали или доки цитируете?

icoz 29 дек 2014 в 01:35

Только что проверил. Всё врут. :(

Для обновления содержимого /etc/hosts и переменных окружения надо остановить и запустить контейнер.

$ docker version 
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

shuron 29 дек 2014 в 11:57

Вот вот. Что деградирует весь этот fig до уровня альтернативного (более удобного) описания запуска контейнеров, не имея никаких функций orchestration. :(

yurtaev 29 дек 2014 в 09:55

Это можно легко проверить и выполнить шаги что описаны в доке. Вот пример asciinema.org/a/15056 Вопрос в том как ваш клиент к БД обрабатывает ситуации смены IP

shuron 29 дек 2014 в 12:00

Клиенту всеравно… ему или ДНС имя или переменную окружения дай…
Но ни то ни то не сменится без перезапуска контейнера… И фиг в этом ничего не меняет… Это просто ограничения «оркестрации» с помощью докереовского линкования…
Поэтому в серьезном проекте надо что-то поинтереснее использовать. Представленное выше решени со Скай ДНС позволяет начальный уровень «оркестрации», но лишь начальный.

yurtaev 29 дек 2014 в 12:09

Я выше показал на примере что при перезапуске контейнера db в связанном с ним webapp меняется ip db в /etc/hosts

icoz 29 дек 2014 в 12:32

Круто, а как у вас так получилось? У меня не поменялось ничего, пока я не перезапустил и второй контейнер.

yurtaev 29 дек 2014 в 13:02

Поправка: я это делал не через fig, напрямую c docker. В fig действительно это не работает и требует перезапуска всех контейнеров.

Может версия у вас старая (хотя у вас тоже 1.4.1)? Или покажите порядок команд которыми запускаете докер.

icoz 29 дек 2014 в 13:46

Я тоже без fig, напрямую docker использовал.
Поднял два реальных контейнера, ко второму подцепился через docker exec my_app /bin/bash. Остановил первый, проверил во втором через env и cat /etc/hosts. Всё по старому. Стартовал первый, во втором так ничего и не поменялось.
Если кратко, то:
run db
run --link db:db my_app
exec my_app bash
#check — зафиксировал содержимое
stop db
#check — оно не изменилось
start db
#check — оно не изменилось
stop my_app
start my_app
exec…
#check — вот тут обновилось

shuron 29 дек 2014 в 19:43

Ок, интересно
На сколько я вижу там достаточно бесполезная команда restart…
Может с ней и работает, с ней я не пробовал…
А вот со stop и run не работает. Именно они однако и нужны при обновление версии зависимого контейнера… именно это частый паттерн… и тут линкинг не поможет.

yurtaev 29 дек 2014 в 20:03

Конечно если вы делаете run то это выглядит как новый контейнер, но если использовать docker start всё заработает.

shuron 29 дек 2014 в 20:11

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

icoz 29 дек 2014 в 00:06

Кстати, fig похоже умирает, ему на замену будет docker compose:
линк
линк
Инфа свежая от 04.12.2014.

shuron 29 дек 2014 в 19:38

Не то что бы умирает. Перерождается…
Да Докеры в плотную занялись Enterprise фичами.
Docker Machine, Docker Swarm, Docker Compose
что у части комьюнити вызвало в прочем диссонанс… Что понесло за собой некий раскол и альтерантивный мув сосредотачивания на контейнерах и их стандартизации только (unix way).
См. Rocket от CoreOS

dvapelnik 4 янв 2015 в 18:02

я тут ищу и не могу найти: при помощи fig можно как-то устанавливать предел использования оперативной памяти и CPU?

yurtaev 4 янв 2015 в 18:20

Есть параметр mem_limit, с остальным плохо и ждет решени #363

shuron 28 дек 2014 в 22:39

Я использовал именно такую связку именно с ДБ но отказался от этого,
так как докеризированно мног ПХП приложени не кешировало соедиенение с БД и тем самым к каждому доступу к ДБ добавился запрос к СкайДНС…
Что мне очень не понравилось в этом конкретном случае… А так да как первое решение что-бы поиграть пойдет… Но я смотрю сейчас в сторону kubernetes

НЛО прилетело и опубликовало эту надпись здесь

icoz 28 дек 2014 в 15:45

Да хорошая вещь, позволила быстро что-то запустить, посмотреть, что оно работает, но не понять воркфлоу.

amartynov 29 дек 2014 в 11:43

В качестве более легковесной альтернативы для контейнеров в пределах одного хоста хочу посоветовать обычный dnsmasq.

После установки создайте файл /etc/dnsmasq.d/docker с контентом

addn-hosts=/docker-container-hosts
interface=docker0

Теперь после добавления нового контейнера или пересоздания/перезапуска существующего надо будет выполнить примерно такой скрипт:

Код

#!/bin/bash

# виртуальный домен для контейнеров
DOMAIN=containers.example.com

# addn-hosts файл для dnsmasq
CONTAINER_HOSTS=/docker-container-hosts

echo "# Auto-generated by $0" > $CONTAINER_HOSTS
for CONTAINER in тут список имен ваших контейнеров; do
    IP=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' $CONTAINER)
    [ $IP ] && echo "$IP  $CONTAINER.$DOMAIN" >> $CONTAINER_HOSTS
done

# просим dnsmasq перечитать CONTAINER_HOSTS
pkill -x -HUP dnsmasq

Минусы:

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

Плюсы:

не нужны дополнительные контейнеры
используется стабильный софт
мгновенное обновление (TTL=0)

Идея взята отсюда.

shuron 30 дек 2014 в 00:34

Не дурно как альтернатива.
Dnsmasq по умолчанию какие-то логи замусориовает или тих?

amartynov 30 дек 2014 в 10:09

Тих, никуда не пишет.

dvapelnik 1 янв 2015 в 16:30

это можно автоматизировать. я создаю контейнер с некоторым именем, тут же дописываю этот домен в dnsmasq.conf и к контейнеру уже можно получать доступ по доменному имени: containerName.doc

warner 29 янв 2015 в 11:44

Начал недавно смотреть докер, нашёл команду docker ps -q — выдаёт список id-шников запущенных контейнеров.
Узнать их имена можно в цикле через docker inspect как у вас IP узнаётся.
получается можно модернизировать немного ваш скрипт и не нужно будет явно перечислять имена контейнеров.
Вроде вот так, к сожалению сейчас протестировать не могу, но должно работать.

for CONTAINER in `docker ps -q`; do
IP=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' $CONTAINER)
NAME=$(docker inspect --format '{{ .Config.Hostname }}' $CONTAINER)
[ $IP ] && echo "$IP  $NAME.$DOMAIN" >> $CONTAINER_HOSTS
done

теперь ещё повесить срабатывание этого скрипта на вызов команд docker run/ docker stop/ docker start и будет всегда актуальная информация в Dnsmasq

amartynov 29 янв 2015 в 11:58

Да, так ещё лучше. И теперь можно убрать проверку перед echo, т.к. обходятся только запущенные контейнеры.

HaronK 29 дек 2014 в 16:37

Недавно в моей компании также начали активно обсуждать использование docker контейнеров вместо LabManager виртуалок. Сейчас наш build инженер активно работает над заменой виртуалок на docker+puppet+skydns+skydock. Я же решил для локального использования (Oracle контейнер) найти что-то попроще. В процессе гугления был найден подход с использованием виртуального интерфейса. После небольшой модификации получилось следующее:

1. Добавить новый виртуальный интерфейс:

sudo ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0 up

или для постоянного использования добавить в /etc/network/interfaces следующие строки:

auto eth0:1
iface eth0:1 inet static
	 address 10.0.0.1
	 netmask 255.255.255.0
	 broadcast 10.0.0.255

2. Создать Docker контейнер:

sudo docker run -d --name="docker-oracle" -p 10.0.0.1:1521:1521/tcp -p 10.0.0.1:22:22/tcp docker:5000/linux_64-oracle_11

3. При необходимости добавить в /etc/hosts запись вида:

10.0.0.1    docker-oracle

При таком подходе нет необходимости держать дополнительные контейнеры (skydns, skydock).
Единственным недостатком для меня остается необходимость ручного старта контейнера после перезагрузки, но это не критично поскольку он не всегда нужен. В крайнем случае можно прописать команду старта в автозапуск.
Работает такая конфигурация уже несколько месяцев без проблем.

shuron 29 дек 2014 в 19:52

Шаг 3 не совсем ясен. где это добавляется
Если на хосте то Зачем?
Если в контейнере то как?

HaronK 29 дек 2014 в 21:16

У меня на хосте. Использую docker-oracle вместо 10.0.0.1, но это не обязательно. Мне визуально удобнее с именем работать (например, соединяться по ssh) чем с IP.

shuron 30 дек 2014 в 00:32

Но фишка в чем? что контейнер который должен получить доступ к Оракл БД статически прописывает у себя 10.0.0.1?

icoz 30 дек 2014 в 00:45

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

shuron 30 дек 2014 в 01:10

Ок… в таком случаем маловато фишки :)

HaronK 30 дек 2014 в 01:38

Да, вы правы. Сервер (основной продукт компании), работающий на хосте, соединяется с Ораклом в контейнере по IP.
Но это только для локального тестирования. Можно также и сервер засунуть в контейнер.
В целом мы собираемся использовать docker для тестирования разнообразных комбинаций. Сервер может работать в контейнере на RedHat (5.3, 6.3), Suse и Ubuntu. Есть также Solaris, но он запускается не в контейнере, а на реальной машине.
Кроме Оракла есть еще MsSql и Sybase (последние 2 работают на реальной машине под виндой). Плюс к этому есть несколько разных версий сервера (4 штуки).
Весь этот зоопарк в разнообразных комбинациях необходимо тестировать. Что-то только локально, остальное на отдельных выделеных тестовых машинах. Но на тестовых машинах уже будет skydns и skydock, а локально мне хватает и того, что я описал выше.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий