у меня просто похожая схема с Ceph вместо infinit.sh вполне работает.

А ломает потому что либо abandonware либо infinit

А ломает потому что либо abandonware либо infinit

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

есть, правда, серьезное подозрение, что infinit.sh до взрослого стораджа еще лет пять развиваться. ceph все-таки не идиоты пишут и он не зря непростой получается.

есть, правда, серьезное подозрение, что infinit.sh до взрослого стораджа еще лет пять развиваться. ceph все-таки не идиоты пишут и он не зря непростой получается.

а сколько ceph пишут и когда он наконец заработает кстати?

а сколько ceph пишут и когда он наконец заработает кстати?

ceph работает уже года три точно, с пробуждением. пишут 9 лет.

ceph работает уже года три точно, с пробуждением. пишут 9 лет.

странно, а мне казалось дримхост тут неделю изза цефа лежал буквально осенью

странно, а мне казалось дримхост тут неделю изза цефа лежал буквально осенью

сдуру можно и хрен сломать.

где-то есть постмортем, чтобы увидеть, где именно было их "сдуру"?

я хз. но я не слышал, чтобы цеф ктото в здравом уме рекомендовал в прод

я хз. но я не слышал, чтобы цеф ктото в здравом уме рекомендовал в прод

репрезентативно (на самом деле нет).

https://cds.cern.ch/record/2015206/files/CephScaleTestMarch2015.pdf например, полтора года назад.

journalctl

Хочу деплоить каждый бранч на отдельный сабдомен. Сейчас есть мультиконтейнерное приложение, все это деплоится на aws Elastic Beanstalk. Можно конечно создавать Elastic Beanstalk enviroment на каждый бранч, но это ОЧЕНЬ долго. Может кто делал подобное?

берешь Jenkins, берешь docker compose, готово

jenkins + registry это все есть. Как разворачивать то?

у вас docker-compose.yml тоже в репозитории?

или вы как-то иначе все деплоите?

лучше деплоить так же, как вы это делаете на прод, чтобы флоу сам тестить заодно

Elastic Beanstalk во первых не работает с docker-compose, ему нужен свой конфинг. Но суть в том, что на один энваремент задеплоить можно только одно мультиконтейнерное приложение, и на каждый бранч разворачивать энваремент совсем дело. Вот и ищу другие способы

хм, понятно. Не знал про Beanstalk. У нас для разработки у нас выделенный сервак, мы там просто Jenkins подняли и в Job'е на баше просто прописали все необходимое для поднятия

без docker-compose, но с ним вышло бы так же (разве что префикс потребовался бы для веток)

получается, на каждую ветку свой docker-compose, потом все дело деплоится на сервере и подставляется домен, грубо говоря на одном сервере много версий приложения крутится, правильно понимаю?

примерно так, да. В docker-compose можно переменные окружения передавать, которые можно заюзать в самом docker-compose.yml ( https://docs.docker.com/compose/environment-variables/ ). Возможно, с ними получится 1 docker-compose.yml иметь на все ветки. Но имхо лучше этот файл закинуть в какой-нибудь репозиторий, чтобы разработчики могли для своей ветки изолированно добавлять/удалять сервисы

тут еще есть такая проблема. К примеру, у нас 3 образа. У них дофига версий. Как понять, какие версии для этих образов поднимать. Мы у себя такой вопрос конвенциями решили. Конкретно в этом случае можно: 1. теги именовать так же как ветки 2. решить, какой тег будет по умолчанию 3. когда деплоим ветку XXX, поднимаем контейнеры с тегом XXX, либо дефолтные Как сделать 3 пункт в docker-compose.yml я хз. Возможно, перед всей этой петрушкой проверять, есть ли контейнер A с тегом XXX. Если нет - то тегировать дефолтный. Тогда 2 пункт не нужен. Получается несколько кустарно, но должно работать :) Возможно, кто-то из присутствующих по-лучше способ придумал

А как порты выдаете приложениям?

вручную не задаем. Но при поднятии контейнера указываем —label hostname=${SUBDOMAIN}.xxx.yyy как там внутри разруливается, я хз. Настраивал кто-то другой

Хочу деплоить каждый бранч на отдельный сабдомен. Сейчас есть мультиконтейнерное приложение, все это деплоится на aws Elastic Beanstalk. Можно конечно создавать Elastic Beanstalk enviroment на каждый бранч, но это ОЧЕНЬ долго. Может кто делал подобное?

Не знаю как с бинстолком, с консулом в качестве сервис дискавери получается все просто - регистрируете сервис с тегов векти и он автоматически доступен чере tag.name.service.conul

делаем именно так для прогонов стейджинг

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

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

deregister service же никто не отменял

в консуле, кстати, можно и конфиги хранить. Очень удобно получается в связке с consul-template :) Но это уже другая тема

у меня такая была проблема - делал REST запрос по их API, чтобы дерегистрировать сервис, так вот выяснилось, что нужно знать, к какому агенту обращаться

Спасибо за информацию, посмотрю на consul

кажется, вспомнил ту проблему. Там были: docker-swarm + несколько тачек + docker-compose. При обновлении через docker-compose контейнер поднимался на другой тачке, а со старой не дерегистрировался. Сейчас мб пофиксили

docker-swarm в связке с consul получается?

ну это чтобы на нескольких тачках работало )

если машина одна - то docker-compose + consul должно подойти

кажется, вспомнил ту проблему. Там были: docker-swarm + несколько тачек + docker-compose. При обновлении через docker-compose контейнер поднимался на другой тачке, а со старой не дерегистрировался. Сейчас мб пофиксили

да - проверил - есть такое дело, дерегистер надо делать, обращаясь к тому же серверу консул

у них issue было в гитхабе, которое закрывалось и открывалось несколько раз :D там еще чел свою утилиту на go написал. Но если надо будет кому - могу поискать, как мы это у себя делали

чтобы запустил команду и вжух

чтобы запустил команду и вжух

Я недавно поднимал вопрос "как контейнеры деплоить на прод?" Мне дали вариант только по ssh, хотел бы ещё варианты услышать. Читал про swarm + consul и там какой-то ппц был (сложно). Как вы делаете?

локально как запускаете?

Я недавно поднимал вопрос "как контейнеры деплоить на прод?" Мне дали вариант только по ssh, хотел бы ещё варианты услышать. Читал про swarm + consul и там какой-то ппц был (сложно). Как вы делаете?

можно указать docker -H hostname

но нужно будет настроить сертификаты

локально как запускаете?

Пока у меня мультконтейнерное приложение живущее на одном хосте и запускаемое через docker-compose.

-H

Options: -f, --file FILE Specify an alternate compose file (default: docker-compose.yml) -p, --project-name NAME Specify an alternate project name (default: directory name) --verbose Show more output -v, --version Print version and exit -H, --host HOST Daemon socket to connect to

можно указать docker -H hostname

И тогда смогу обращаться к docker-machine по апи?

И тогда смогу обращаться к docker-machine по апи?

докер машин не юзаю

это хел для докер компоуза

И тогда смогу обращаться к docker-machine по апи?

но проще поднять ранеер на хосте ходит в это раннер дженкинсом или гитлабом и запускать

прямо шелом в джобе дженкинса того же

Ок. Тогда подробнее как схема работает и что откуда и куда?:) У меня gitlab ci. Через раннер не вариант или я не знаю как:) Но вот допустим есть сервер ci и сервер прода с запущенной службой docker. Можно ли с сервера ci попросит службу docker на хосте прода подтянуть и перезапустить контейнеры нужные?

Через какие-то внутренные при докера...

за гитлаб не скажу, но логика любого ci раннера - у него есть шел на каком либо серевре, коль так, юзеру у которого есть шел можно дать права управлять докером

в дженкинсе это просто шел команды, у гитлаба так понимаю свой подход через yml

Ок. Тогда подробнее как схема работает и что откуда и куда?:) У меня gitlab ci. Через раннер не вариант или я не знаю как:) Но вот допустим есть сервер ci и сервер прода с запущенной службой docker. Можно ли с сервера ci попросит службу docker на хосте прода подтянуть и перезапустить контейнеры нужные?

https://medium.com/@PS_/a-guide-to-automated-docker-deployments-w-gitlab-ci-510966dd6022#.g5jvy0lnu подойдет?

за гитлаб не скажу, но логика любого ci раннера - у него есть шел на каком либо серевре, коль так, юзеру у которого есть шел можно дать права управлять докером

да, вы правы - суть одна везде. Но у гитлаба раннер сам работает в докер контейнере не засирая при этом хост машину и сам докер тестовыми контейнерами, очень удобно для поддержания чистоты системы. Так что из гитлабовского раннера не получится сразу деплоить. Пока что мне вариант с SSH нравиться все больше и больше. Он достаточно гибкий, чтобы реализовать любые операции по копированию файлов на прод, перезапуск и управление контейнерами. Да и плюс ssh достаточно надежный канал.

ERROR: S client not available

https://medium.com/@PS_/a-guide-to-automated-docker-deployments-w-gitlab-ci-510966dd6022#.g5jvy0lnu подойдет?

за ссылочку спасибо, почитаю. Годных гайдов найти не так просто.

во, в статье используется stackahoy для Deployment

Я недавно поднимал вопрос "как контейнеры деплоить на прод?" Мне дали вариант только по ssh, хотел бы ещё варианты услышать. Читал про swarm + consul и там какой-то ппц был (сложно). Как вы делаете?

ну на самом деле не так сложно. Через docker-machine можно поднять docker swarm (прям 1 командой, хоть на aws, хоть на своей тачке). Сертификаты там сами настроятся, причем, если мне не изменяет память, они автоматически обновляются. После настройки docker swarm пишешь что-то вроде eval $(docker-machine env наименование_машины) и работаешь с docker swarm будто с локальным докером. Мы поднимали все через ансибл, но я думаю, сейчас нет смысла этого делать :) Если только устанавливать отдельные утилиты на серваке, которые могут быть полезны при заходе на сервак

у консула есть хелс-чеки, главное, чтобы приложение их поддерживало. ХЧ можно самому написать на чем угодно. Например, можно написать ХЧ на работу БД - типа коннектимся к БД и пытаемся выполнить SHOW TABLES или что-то в этом духе.

ну а дальше через консул и консул-теплейт можно удобно сделать blue-green deployment

типа - поднимаем копию сервисов, пишем в консул наименование цвета, по консул темплейт переключаем прокси

перед тем как этим пользоваться (ансибл, докер сварм, докер машина) надо понять как оно все работает и взаимодействует :)

но я узнал что есть такой путь

спасибо :)

на первом заходе можно думать как о черной коробке: 1. ansible - настройка машин (так же можно и деплой через него сделать) 2. docker-machine - установка докера и докер-сварма на тачках (можно сделать ансиблом, но docker-machine в разы проще) 3. docker-swarm - объединение нескольких docker server'ов в 1 4. docker-compose - поднятие приложения, состоящего из нескольких сервисов

а если будут какие-то специфичные требования/проблемы - копать уже в конкретную сторону

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

Мне пока подойдет как замена SSH https://stackahoy.io/ но не уверен буду ли я переходить на него.

Мне пока подойдет как замена SSH https://stackahoy.io/ но не уверен буду ли я переходить на него.

А зачем SSH на что-то менять?

"работает - не трогай" :D

хорошее правило, кстати

ну вот и я о том же. Возможно этот сервис что-то упростит. Если нет, тогда нет :)

хорошее правило, кстати

плохое

ну, так как пока не работает в продакшене то можно и потыкать палкой :)

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

тратить время на исходники левого проекта как-то не очень

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

И что? Но если его не нарушать, то нет движения. А ты или активный, или мертвый

плохое

надо золотую середину находить и взвешивать риски и профит

SSH это базовейший инструмент вообще, странно что ты о нем говоришь как о какой-то "подходящей тулзе для деплоя"

надо золотую середину находить и взвешивать риски и профит

Тип того. Т,е. этого правила нет

ну у меня есть другое направление, в котором я копаю. Я не docker-сварщик :D

а тут уж пришлось разобраться )

SSH это базовейший инструмент вообще, странно что ты о нем говоришь как о какой-то "подходящей тулзе для деплоя"

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