если запустить внутри пачку демонов тупо баш-скриптом, то остановить контейнер можно будет только по kill, что не есть хорошо — баш не сможет отправить сигналы демонам, которые от него отвязались.
Т.е. требуется что-то вроде supervisord для рулёжки процессами в контейнере.
Ну и неудобства в виде одного единственного stdout/stderr на весь контейнер, например.
Т.е. нужно лишний раз включать голову и решать вопросы, которых бы и не возникло, не пользуйся мы докером.
Важно, что костылей понадобилось немного — всё украдено за нас.
Докер даёт очень хорошую гарантию — в прод едут ровно те бинари и те npm-пакеты. которые проверялись на тестинге.
Плюс при грамотной упаковке элементов в контейнеры становится плевать, на какой физической машинке они бегут и сколько экземпляров одинакового сервиса поднято — и это тоже удобно.
Наши приложения в большинстве своём stateless, поэтому docker или аналоги напрашивались. Опять же на решение влияет хайп, количество готовых костылей и подпорок^W^W^W инструментов, чтоб это работало.
Это можно решать через зипованные образы lxc / openvz, но количество готовых костылей и подпорок для них меньше, чем для докера.
Оукееей. Допустим, это не моё приложение со специфичным конфигом. Например, rabbitmq или nginx, или тот же consul.
Т.е. любое стороннее приложение, разработчиков которого более чем устраивают простые текстовые файлы (иногда длинные).
consul-template пусть и неизящно, но позволяет подрихтовать конфиг на лету (без рестарта контейнера, что важно).
Или приложение уже давным-давно написано и не хочется лезть и менять в его код — мы просто пакуем его в контейнер, подкладываем рядом consul-template и небольшой entrypoint, который позаботится, чтоб всё хорошо стартовало-умирало.
Так мы относительно дёшево получаем неизменный артефакт для деплоя (здесь я мысленно проклял npm и миллиарды зависимостей).
А обучение приложения работать напрямую с consul по api — уже отдельная задача, которую можно спокойно выкинуть в беклог с невысоким приоритетом.
у меня конфигурация — это потенциально жирный json с метадатой, который нужно иногда менять быстро по желанию левой пятки заказчика.
Но при этом, ему не место в БД с обычными данными.
Прокидывать его через переменные окружения — чудовищная идея, которая ещё и принуждает меня контейнер рестартовать, когда можно дать команду на перечитывание конфига.
по факту значимые значения конфигурации хранятся в консуле и их можно прямо оттуда поменять на лету — consul-template сам перегенерит конфиг и передёрнет приложение.
А если ломается структура конфига — это так и так новый релиз => пересборка нового образа.
Легковесные виртуалки (джейлы фряхи, openvz линукса, зоны в солярке) существуют и применяются значительно дольше, чем существует Docker.
Тем не менее контейнеры почему-то полетели.
Меня в докере подкупила идея разделения понятия образа и контейнера, а также иммутабельных слоёв ФС — это по-своему правильно и хорошо.
Стало на порядок проще воспроизводить тот бардак зависимостей (npm-пакетов), с которыми у меня сейчас сервис в проде работает — взял ворох докер-образов таких же, как на проде — и ковыряешь.
И докер не опоздал лет на 10, а пришёлся как раз вовремя — много компаний доросли до кластеров и начали задумываться над вопросом, а что делать, если нужно будет валить с одного облачного провайдера в другой.
наши крон-джобы — это наоборот, всякая периферия.
Досылка данных в очередь, если мгновенная отправка не прошла по какой-то причине (все сервисы должны уметь в семантику one or more), файлообмен с внешними системами итд.
Каждый адаптер для внешней системы — это отдельный сервис и нелогично отделять его работу по расписанию от него самого.
1) генерация конфига для работоспособности содержимого — имхо вполне специфичная задача, которая имеет непосредственную связь 1 к 1 с сервисом.
2) а можно меня носом в мануал ткнуть, пожалуйста? я поизучаю на досуге.
3) это неудобно только тем, что неправильный шаблон может обнаружиться только после сборки тестинга (имеем поломанный билд). зато это очень удобно, что ты можешь выкинуть контейнер на любую машинку в и он сам себя правильно сконфигурит. Среда корректно определяется тем, какой консул-кластер — test / stage / prod.
Ну мне подумалось, что это может быть аналогом kubernetes для бедных — дёргаем скриптами alive-чеки, смотрим где плохо или наоборот лишнее и в автоматическом режиме дёргаем ручки для масштабирования.
Это может быть вполне нормальным решением для портирования старой системы масштабирования вместо переезда на kubernetes / nomad / etc.
P.S. у нас джобы по расписанию запускаются контейнеров, только они сделаны велосипедными библиотеками для nodejs.
мне в этом решении резко не понравилось, что
1) в этом случае контейнер перестаёт быть самодостаточной сущностью.
2) конфиг консул-темплейта на хосте становится сложным и зависит от состава запущенных контейнеров.
3) нужно монтировать внутрь ещё и конфиги.
т.е. выходит циклическая зависимость хост <-> контейнер, которую хотелось бы избежать.
а если этот контейнер с cron сам дёргает по расписанию другие ручки в кластере? и совсем не хотелось бы, чтоб он умер вместе с машиной.
этакий кластер-менеджмент для бедных.
Раньше это работало.
Теперь после всё равно режут заблоченные IP для https, или для http присылают редирект на заглушку, даже если идёшь на правильный IP + режут http-траффик до заблоченного IP. так что только VPN / SOCKS-прокси.
0.000000 94.181.74.158 -> 8.8.4.4 DNS 75 Standard query 0x1f70 A rutracker.org
0.000344 8.8.4.4 -> 94.181.74.158 DNS 91 Standard query response 0x1f70 A 92.255.241.100
0.030720 8.8.4.4 -> 94.181.74.158 DNS 91 Standard query response 0x1f70 A 195.82.146.214
Прилетает 2 ответа — один от Эр-телекома, а другой от нормального DNS-сервера.
Возможно от региона зависит, а может они эту глубоко порочную схему всё-таки убрали.
05 Dec 2014 Ижевск, гитхаб резолвился в IP, принадлежащий Эр-Телекому.
Траффик до яндексовых dns-серверов идет через провайдера.
root@eeerouter:/etc/openvpn# dig @77.88.8.8 github.com
;; ANSWER SECTION:
github.com. 600 IN A 92.255.241.100
Траффик до восьмерок идет через VPN в европе.
root@eeerouter:/etc/openvpn# dig @8.8.8.8 github.com
;; ANSWER SECTION:
github.com. 7 IN A 192.30.252.128
Т.е. требуется что-то вроде supervisord для рулёжки процессами в контейнере.
Ну и неудобства в виде одного единственного stdout/stderr на весь контейнер, например.
Т.е. нужно лишний раз включать голову и решать вопросы, которых бы и не возникло, не пользуйся мы докером.
Докер даёт очень хорошую гарантию — в прод едут ровно те бинари и те npm-пакеты. которые проверялись на тестинге.
Плюс при грамотной упаковке элементов в контейнеры становится плевать, на какой физической машинке они бегут и сколько экземпляров одинакового сервиса поднято — и это тоже удобно.
Наши приложения в большинстве своём stateless, поэтому docker или аналоги напрашивались. Опять же на решение влияет хайп, количество готовых костылей и подпорок^W^W^W инструментов, чтоб это работало.
Это можно решать через зипованные образы lxc / openvz, но количество готовых костылей и подпорок для них меньше, чем для докера.
Т.е. любое стороннее приложение, разработчиков которого более чем устраивают простые текстовые файлы (иногда длинные).
consul-template пусть и неизящно, но позволяет подрихтовать конфиг на лету (без рестарта контейнера, что важно).
Или приложение уже давным-давно написано и не хочется лезть и менять в его код — мы просто пакуем его в контейнер, подкладываем рядом consul-template и небольшой entrypoint, который позаботится, чтоб всё хорошо стартовало-умирало.
Так мы относительно дёшево получаем неизменный артефакт для деплоя (здесь я мысленно проклял npm и миллиарды зависимостей).
А обучение приложения работать напрямую с consul по api — уже отдельная задача, которую можно спокойно выкинуть в беклог с невысоким приоритетом.
Но при этом, ему не место в БД с обычными данными.
Прокидывать его через переменные окружения — чудовищная идея, которая ещё и принуждает меня контейнер рестартовать, когда можно дать команду на перечитывание конфига.
А если ломается структура конфига — это так и так новый релиз => пересборка нового образа.
Тем не менее контейнеры почему-то полетели.
Меня в докере подкупила идея разделения понятия образа и контейнера, а также иммутабельных слоёв ФС — это по-своему правильно и хорошо.
Стало на порядок проще воспроизводить тот бардак зависимостей (npm-пакетов), с которыми у меня сейчас сервис в проде работает — взял ворох докер-образов таких же, как на проде — и ковыряешь.
И докер не опоздал лет на 10, а пришёлся как раз вовремя — много компаний доросли до кластеров и начали задумываться над вопросом, а что делать, если нужно будет валить с одного облачного провайдера в другой.
Досылка данных в очередь, если мгновенная отправка не прошла по какой-то причине (все сервисы должны уметь в семантику one or more), файлообмен с внешними системами итд.
Каждый адаптер для внешней системы — это отдельный сервис и нелогично отделять его работу по расписанию от него самого.
2) а можно меня носом в мануал ткнуть, пожалуйста? я поизучаю на досуге.
3) это неудобно только тем, что неправильный шаблон может обнаружиться только после сборки тестинга (имеем поломанный билд). зато это очень удобно, что ты можешь выкинуть контейнер на любую машинку в и он сам себя правильно сконфигурит. Среда корректно определяется тем, какой консул-кластер — test / stage / prod.
Это может быть вполне нормальным решением для портирования старой системы масштабирования вместо переезда на kubernetes / nomad / etc.
P.S. у нас джобы по расписанию запускаются контейнеров, только они сделаны велосипедными библиотеками для nodejs.
1) в этом случае контейнер перестаёт быть самодостаточной сущностью.
2) конфиг консул-темплейта на хосте становится сложным и зависит от состава запущенных контейнеров.
3) нужно монтировать внутрь ещё и конфиги.
т.е. выходит циклическая зависимость хост <-> контейнер, которую хотелось бы избежать.
этакий кластер-менеджмент для бедных.
USERS_ARE_LISTENERS — Users with a USER role will be unable to post messages.
Полный мануал:
support.skype.com/en/faq/FA10042/what-are-chat-commands-and-roles
Теперь после всё равно режут заблоченные IP для https, или для http присылают редирект на заглушку, даже если идёшь на правильный IP + режут http-траффик до заблоченного IP. так что только VPN / SOCKS-прокси.
https://habrahabr.ru/post/303850#comment_9671330
0.000000 94.181.74.158 -> 8.8.4.4 DNS 75 Standard query 0x1f70 A rutracker.org
0.000344 8.8.4.4 -> 94.181.74.158 DNS 91 Standard query response 0x1f70 A 92.255.241.100
0.030720 8.8.4.4 -> 94.181.74.158 DNS 91 Standard query response 0x1f70 A 195.82.146.214
Прилетает 2 ответа — один от Эр-телекома, а другой от нормального DNS-сервера.
05 Dec 2014 Ижевск, гитхаб резолвился в IP, принадлежащий Эр-Телекому.
Траффик до яндексовых dns-серверов идет через провайдера.
root@eeerouter:/etc/openvpn# dig @77.88.8.8 github.com
;; ANSWER SECTION:
github.com. 600 IN A 92.255.241.100
;; Query time: 1 msec
;; SERVER: 77.88.8.8#53(77.88.8.8)
;; WHEN: Thu Dec 4 22:46:54 2014
;; MSG SIZE rcvd: 44
Резолвится в эр-телекомовский IP.
Траффик до восьмерок идет через VPN в европе.
root@eeerouter:/etc/openvpn# dig @8.8.8.8 github.com
;; ANSWER SECTION:
github.com. 7 IN A 192.30.252.128
;; Query time: 142 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec 4 22:47:42 2014
;; MSG SIZE rcvd: 44
Резолвится, как положено.
Сейчас ещё попрошу человека свежих данных по тому, как DNS-запросы работают у них.