Прокси, который умеет тушить и поднимать докер окружения

Привет!

Строю Continuous Integration сервер для веб разработки.

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

Каждое такое окружение будет тянуть под пол гига оперативки а удерживать активными таких билдов хочется много.

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

Потом когда приходит запрос проверяем если окружение активное — передаем запрос по адресу. Если же нет — поднимаем контейнеры а пока пользователю показываем html страничку с джаваскриптом, который каждые 5 секунд просто перезагружает страничку. Лоадер вообщем какой-то.

Вопрос — встречали ли вы подобные прокси (принимать запрос и проверять активно ли окружение)?

На чем бы его было логичнее написать?

Спасибо
Юрий

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: Continuous Integration, Docker, проксі

Ctrl + Enter

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 17.03.2019 15:36

В действительности это очень плохая практика сама по себе — держать кучу билдов из боковых веток гита (разработчики будут против, но набитые шишки и боль показывают, что придется их переубедить рано или поздно).
1. Эти билды используются для тестеров, но как только они начинают параллелиться, тут же начинают влиять друг на друга и тестеры тестируют уже непонятно что, ибо после мержа придется тестировать все сначала (причем любого мержа любой боковой ветки).
2. Мерж конфликты становятся просто обыденностью и качество становится полностью зависимым от того, кто резольвил конкретный мерж.
3. Нагрузка на инфраструктуру (собственно описанная проблема). Причем просто гашением контейнеров ее не решить, т.к. у них еще имиджи есть и они тоже жрут ресурсы.
4. На практике половина этих веток вообще забывается на каком-то этапе и через пару спринтов с основных веток уже вообще не имеет шанса на мерж, т.к. сильно отстает.

Приучайте своих работать строго в цепочках (local)-dev-(test)-stage-prod для каждой мажорной версии, вкупе с автоматическим CI это дает самый вменяемый результат по моему опыту.

Відповісти

Підтримати

Misha Kron 17.03.2019 00:46

У вас получилось сделать то что вы планировали? Если да то скажите на каком прокси вы остановились. Мне заказали похожий проект как у вас, и я сейчас оцениваю можно ли для него на proxystore купить прокси, или нужно что-то другое использовать. Ну и вообще братся ли за проект, так как он мне кажется довольно таки запутанным (особенно часть с тугением не нужный контейнеров)

Yuriy Gerasimov Lead Developer в ImageX 17.03.2019 06:18

я нашел решение в docksal.io

Misha Kron

Егор Добровольский 02.10.2016 19:29

rancher.com

Егор Добровольский 02.10.2016 19:35

детальнее: сетапите сервер ранчера (не самой rancherOS), добавляете туда хосты (можно в т. ч. и тот, где сам основной сервер ранчера), деплоите туда обычным docker-compose’ом. есть замечательное REST API, есть встроенный load balanced (haproxy с API), есть сбор статистики и тд.

Егор Добровольский

Yuriy Gerasimov Lead Developer в ImageX 02.10.2016 22:57

ого-го! Звучит! Обязательно потестирую. Огромное спасибо за наводку!

Vasyl Lytovchenko бомж в отключке 01.10.2016 16:33

В формулировке: «принимать запрос и отправлять его туда где активно» — это вообще любой load balancer делает. То есть можно представить себе схему, когда то что отдает HTML страничку с reload’ом доступно всегда(с низким приоритетом, или как fallback), а когда есть более другие инстансы — то нагрузка идет на них. Ну и плюс сервис который будет тушить/поднимать. Хотя это из пушки по воробьям в вашем случае(если конечно load balancer’а нет на горизонте).

Тоже самое можно сделать с Apache или nginx, и там и там есть proxy, и там и там можно сделать что-то типа «если heartbeat отвечает — тогда проксируй туда, если нет — то сюда». Ну и плюс тот же самый маленький сервис который будет тушить и поднимать инстансы.

Конь в Пальто 01.10.2016 12:07

Мы такое делали.
С кучей регионов.
Но кодебейз кроме сворма и докера весь свой.
Вот краткое описание

youtu.be/...1VKlo4uJ43EFlg0XSAyuzCEAg

Vanya Yani Web Developer в Capgemini Engineering 30.09.2016 22:37

Можно посмотреть в сторону serverless apps blog.docker.com/...verless-apps-with-docker

Vanya Yani Web Developer в Capgemini Engineering 30.09.2016 22:33

Так Continuous Integration или множество деплойментов? По описанию не похоже на Continuous Integration.

Eugene Nuribekov SSE 30.09.2016 19:14

Если я правильно понял, что мониторить виртуальные хосты и делать что-то по результатам то может Zabbix и его агенты?

Yuriy Gerasimov Lead Developer в ImageX 30.09.2016 19:32

Евгений, спасибо за ответ.

Я с Zabbix не сталкивался.

Насколько я понял с сайта продукта это система мониторинга.

Можен ли она выполнять события по определенным тригерам? Например проверять подняты ли докер контейнеры для определенного http запроса и поднимать их.

И как в этом случае если они не подняты, отдавать заглушку html страницу?

Eugene Nuribekov

Eugene Nuribekov SSE 30.09.2016 21:32

Можен ли она выполнять события по определенным тригерам?

Да. www.zabbix.com/...onfig/triggers/expression

Yuriy Gerasimov

Eugene Nuribekov SSE 30.09.2016 21:33

Агентом можно поставить любой bash-скрипт отдающий данные в определенном формате.

Andrii Bublyk DevOps Expert в Ciklum 30.09.2016 19:08

а не выйдет ли заюзать inetd / xinetd для того что вам нужно?

Yuriy Gerasimov Lead Developer в ImageX 30.09.2016 19:35

Андрей, очень интересное предложение с xinetd.

Может ли он понимать что не только пришел запрос на порт 80 а и на какой хост пришел этот запрос?

И может ли xinetd что-то отдавать клиенты пока поднимаются контейнеры?

Andrii Bublyk

Andrii Bublyk DevOps Expert в Ciklum 30.09.2016 19:49

Хост это уже сущность из http-протокола.
Если речь о заголовке http Host.
Это можно решить nginx-ом, который будет понимать хост и проксировать запросы на нужные tcp-порты, слушающиеся локально. А дальше “маленьке звірятко загортає шоколад у фольгу”, тоесть inetd получает tcp-пакет на порт, подымает докер, ...

Andrii Bublyk DevOps Expert в Ciklum 30.09.2016 19:51

developer.atlassian.com/...ystemd-socket-activation
вот вариант через systemd.

Прокси, который умеет тушить и поднимать докер окружения

18 коментарів

Підписатись на коментарі