вручную не задаем. Но при поднятии контейнера указываем —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 достаточно надежный канал.

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 для автоматизации чего либо. Уж так вышло :) для меня это был путь войти на удаленный сервер и работать там, но в скриптах не юзал.

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

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

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

если с такой стороны посмотреть - то да

работает - не трогает - это адское наследие предыдущего поколения. Сейчас все стремятся к повторяемости - не знаешь как повторить - не трогай :)

работает - повтори и не трогай

а сам ssh может быть вреден, точнее не сам ssh, а например sftp - нарывался на ситуации, когда канал забит в полочку - sftp просто перестает работать

работает - повтори и не трогай

ну если так разве что

а сам ssh может быть вреден, точнее не сам ssh, а например sftp - нарывался на ситуации, когда канал забит в полочку - sftp просто перестает работать

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

это да

никаких ssh на сервер! :))

так что blue/green и вперед

угу - самое верное

во

blue\green это из какой оперы?

хорошо что вы сказали про проблемы деплоя по ssh.

https://habrahabr.ru/post/309832/

шикарно! Спасибо

А что там на картинке? 2 разные базы?

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