Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

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

Привет!

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

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

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

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

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

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

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

Спасибо
Юрий

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

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

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

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

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

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

youtu.be/...1VKlo4uJ43EFlg0XSAyuzCEAg

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

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

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

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

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

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

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

Можен ли она выполнять события по определенным тригерам?
Да. www.zabbix.com/...onfig/triggers/expression

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

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

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

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

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

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

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