Вот эт точно не для компоуза

с нормальной системой оркестрации все получится

Нормальная система оркестрации эт точно не компоуз)

что для вас нормальная система оркестрации?

Кубер хотя б)

Ну или марафон

Кубер хотя б)

а swarm чем плох?

я не прошу названия, я прошу список критериев по которому вы так решили

У swarm нет неймспейсов, он вяло реагирует на смерть ноды

Вообще я скорее за dcos

неймспейсы - стэки? А что значит вяло реагирует? интервалы таймаутов и опроса нод настраиваются

Можно отвязаться от докера

неймспейсы - стэки? А что значит вяло реагирует? интервалы таймаутов и опроса нод настраиваются

Можно ссылку? Попробую повертеть

неймспейсы - стэки? А что значит вяло реагирует? интервалы таймаутов и опроса нод настраиваются

Наборы контейнеров, грубо новоря

Стейдж и пререлиз - там одинаковый набор сервисов, но в сварме они в куче

В кубе можно разделить по неймспейсам

Короче он более гибкий, но значительно сложнее

я не прошу названия, я прошу список критериев по которому вы так решили

В нашем случае мы выбрали dcos потому что 1. Хорошая дока (по сравнению с кубером 2. Прост в сетапе ноды 3. Можно использовать не только докер, отсюда вытекает плюс с использованием gpu 4. Из коробки есть dns, vip, и все такое.

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

Можно ссылку? Попробую повертеть

docker swarm init —dispatcher-heartbeat (default: 5s) - это про вялость реакции. Dispatcher heartbeat period (ns|us|ms|s|m|h)

Стейдж и пререлиз - там одинаковый набор сервисов, но в сварме они в куче

никто не мешает деплоить стэйджинг с оверврайтом через docker-compose под нужными именами. Особенно в связке с gitlab-ci это довольно просто и удобно

я просто еще не сталкивался с задачами, которые swarm не сможет реализовать, но у меня и опыта в этом деле не так много и проекты не "топовые" :)

никто не мешает деплоить стэйджинг с оверврайтом через docker-compose под нужными именами. Особенно в связке с gitlab-ci это довольно просто и удобно

Есть пример .gitlab-ci?

В кубе можно разделить по неймспейсам

Так в сворме так же по стакам можно все разбить.

Есть пример .gitlab-ci?

в gitlab-ci соответственно можно деплоить стэки с разными именами (по имени тэга или коммита, например): docker stack deploy —compose-file docker-stack.stage.yml mystack_staging_${CI_COMMIT_REF_NAME} а собрать stage c override можно так: docker-compose -f config1.yml -f config2.yml config > docker-stack.stage.yml но скоро этот "колхоз" запилят и можно будет прямо в stack deploy override использовать: https://github.com/docker/cli/pull/569

Мне интересно именно .gitlab-ci.yml, и используете ли volume?

и secret

@Ai_boy

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

Надо создать бота, который банит, если кто-то заходит и первым делом форвардит сообщение

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

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

Если хостовые, или с хоста не тру?

У меня как хостовые так и в ceph (доп. плагин, локально тестирую). Контейнер поднялся - волюм подтянулся. если хостовой, то ессно при его наличии на хосте (в случае биндинга директории с хоста) есть и просто именованые волюмы - создаются сами, если их нет

спс

Всё-таки, можно .gitlab-ci.yml?) Или это секрет?)

в лс кинул

Утром почитал статью https://soar.name/ru/pro/half-a-year-with-docker-swarm-mode-in-production/ и стало как-то грустно

Утром почитал статью https://soar.name/ru/pro/half-a-year-with-docker-swarm-mode-in-production/ и стало как-то грустно

Кто сталкивался с озвученными проблемами? Лично у меня похожая ситуация, первые пару багов не застал, остальные - почти все встречались. Сам теперь подумываю переводить оркестрацию на kubernates какой-нибудь

баги из коробки?)

Не, кубернетис удобоваримый

Кто сталкивался с озвученными проблемами? Лично у меня похожая ситуация, первые пару багов не застал, остальные - почти все встречались. Сам теперь подумываю переводить оркестрацию на kubernates какой-нибудь

Все баги встречал. И с автором общался. Сейчас сварм работает сносно)

Привет! Кто-то из докера подымал ejabberd ?

Привет! Кто подскажет: Все файлы которые создаются из под контейнера имеют owner`а - root. Соответственно я из хоста у меня нет прав на них без root прав

docker run —user ...

docker run —user ...

а глобально это можно установить? Запускаю контейнеры docker-compose`ом

Привет! Вопрос такой: как вы деплоите серверные приложения на ci (У нас gitlab)? У меня в голове 2 варианта: демон, дёргающийся по хуку или агент, у которого есть доступ к шеллу. 1 вариант - нельзя скрипт деплоя менять прямо в репе, 2-ой небезопасный. Так вот как это делать правильно?) Есть какие-нибудь паттерны?

Привет! Вопрос такой: как вы деплоите серверные приложения на ci (У нас gitlab)? У меня в голове 2 варианта: демон, дёргающийся по хуку или агент, у которого есть доступ к шеллу. 1 вариант - нельзя скрипт деплоя менять прямо в репе, 2-ой небезопасный. Так вот как это делать правильно?) Есть какие-нибудь паттерны?

gitlab-ci.yml + gitlab-runner

Привет! Вопрос такой: как вы деплоите серверные приложения на ci (У нас gitlab)? У меня в голове 2 варианта: демон, дёргающийся по хуку или агент, у которого есть доступ к шеллу. 1 вариант - нельзя скрипт деплоя менять прямо в репе, 2-ой небезопасный. Так вот как это делать правильно?) Есть какие-нибудь паттерны?

в gitlab-ci секция деплоя может выглядеть примерно так: deploy-to-review: stage: deploy before_script: - eval $(ssh-agent -s) - ssh-add <(echo "$SSH_PRIVATE_KEY") script: - scp $ENV_FILE $DC_STACK_FILE provisioner@staging.lc:~/docker - ssh provisioner@staging.lc VER=$CI_PIPELINE_ID 'bash -s' < ./docker/stack_deploy.sh environment: name: review/$CI_COMMIT_REF_NAME url: https://www.$CI_COMMIT_REF_SLUG-labs.cf

stack_deploy - это скрипт на сервере, получается?

Не в репе?

Не в репе?

в репе, конечно же... Это выполнение локального скрипта на удаленном компе: ssh provisioner@staging.lc VER=$CI_PIPELINE_ID 'bash -s' < ./docker/stack_deploy.sh

Не в репе?

Побольше подробностей о гитлаб CI с примерами/костылями и лично набытими шишками можно найти тут https://letsclearitup.com.ua/tag/gitlab-ci (14 статей, читайте с самых ранних) Сейчас перешли на docker swarm, поэтому будут полезны также эти две статьи: костыли с передачей переменных https://letsclearitup.com.ua/docker/docker-swarm-stack-deploy-i-env-peremennyie.html "велосипед" с томами (вместо выпиленной конструкции volumes_from) https://letsclearitup.com.ua/deploy/docker-swarm-stack-deploy-i-imenovannyie-toma-named-volumes.html

Тогда уж сделать раннер с ssh-executor, выполнит

Но тут может быть беда в том, что это небезопасно. В репе можно понаписать что угодно

Но тут может быть беда в том, что это небезопасно. В репе можно понаписать что угодно

делаете несколько веток/окружений (staging|release|prod), локальные коммиты мержатся в ветку staging, запускается CI, изменения попадают на staging окружение. В конце спринта делается ветка релиз, она попадает на соответствующее окружение, где QA проводят регрессию (тестирование). После тестирования ветка релиз мержится в ветку прод и выкатывается на прод. В своем CI настраиваете автодеплой на стейджинг окружение, а деплой на релиз/прод делаете manual (выполнится только по нажатию на кнопку), даете доступ к пайплайнам только тем, кому доверяете

делаете несколько веток/окружений (staging|release|prod), локальные коммиты мержатся в ветку staging, запускается CI, изменения попадают на staging окружение. В конце спринта делается ветка релиз, она попадает на соответствующее окружение, где QA проводят регрессию (тестирование). После тестирования ветка релиз мержится в ветку прод и выкатывается на прод. В своем CI настраиваете автодеплой на стейджинг окружение, а деплой на релиз/прод делаете manual (выполнится только по нажатию на кнопку), даете доступ к пайплайнам только тем, кому доверяете

Так и сделаю, наверное, спасибо)

А есть примеры другой реализации? Демон, который отрабатывает по хуку

Так и сделаю, наверное, спасибо)

всегда пожалуйста! Если надумаете использовать вместе с docker swarm - пишите, скину вам пример своего скрипта stack_deploy.sh

всегда пожалуйста! Если надумаете использовать вместе с docker swarm - пишите, скину вам пример своего скрипта stack_deploy.sh

Можно и сейчас скинуть) Сейчас я не готов окончательно определиться. Изучаю kubernetes, потом можно будет уже оценить плюсы и минусы swarm и kubernetes

А есть примеры другой реализации? Демон, который отрабатывает по хуку

не встречал. CI - это что-то "очень личное", каждый точит под себя... наверняка это сделать можно, но нужно ли?

Можно и сейчас скинуть) Сейчас я не готов окончательно определиться. Изучаю kubernetes, потом можно будет уже оценить плюсы и минусы swarm и kubernetes

куб мне показался сложноватым, "с наскоку" не осилил... Ну и у нас стейджинг окружение из одной ноды, поэтому docker swarm подошел идеально - чтоб потренироваться перед релизом/продом и добиться zero downtime

Да, он намного сложнее, но в некоторых кейсах удобнее и гибче

Можно и сейчас скинуть) Сейчас я не готов окончательно определиться. Изучаю kubernetes, потом можно будет уже оценить плюсы и минусы swarm и kubernetes

скрипт выглядит так: #!/bin/bash DIRECTORY=~/docker DC_FILE=docker-compose-stack-staging.yml ENV_FILE=.env.staging.lc REGISTRY=registry.gitlab.lc:5000 cd $DIRECTORY; SERVICES=$(docker service ls —filter name=ed_applications —quiet | wc -l) docker system prune -f; docker volume create —name code-$VER if [[ "$SERVICES" -gt 0 ]]; then # Update docker service update \ —detach=false \ —mount-add type=volume,source=code-$VER,target=/var/www/develop \ —constraint-add node.role==manager \ —with-registry-auth \ —image $REGISTRY/develop/ed/develop.sources:latest \ ed_applications else # Create docker service create \ —name=ed_applications \ —mount type=volume,source=code-$VER,target=/var/www/develop \ —constraint node.role==manager \ —with-registry-auth \ $REGISTRY/develop/ed/develop.sources:latest fi env $(cat $ENV_FILE | grep ^[A-Z] | xargs) docker stack deploy —with-registry-auth —compose-file $DC_FILE ed;

Да, он намного сложнее, но в некоторых кейсах удобнее и гибче

согласен на 1000%, в серьезных проектах без него никак )

Добрый день. Подскажите пожалуйста как быть в данной ситуации? Я создал докер образ в котором присутствует склонированный из гит-репозитория код (файлы исходников). Хочу чтобы файлы исходников были доступны извне. Соответственно я выполняю команду с ключём -v что-то типа такого: docker run -v /d/my-local-path/code:/code -p 8080:8080 -p 8081:8081 —name container-name —restart unless-stopped -it image-name Но проблема в том что файловая система в контейнере затирается тем что находится в /d/my-local-path/code (а там пусто) Т.е. получается что файлы копируются извне в контейнер, а мне надо наоборот - из контейнера в локальную файловую систему. Буду очень признателен если кто-то подскажет как поправить данное поведение.

Добрый день. Подскажите пожалуйста как быть в данной ситуации? Я создал докер образ в котором присутствует склонированный из гит-репозитория код (файлы исходников). Хочу чтобы файлы исходников были доступны извне. Соответственно я выполняю команду с ключём -v что-то типа такого: docker run -v /d/my-local-path/code:/code -p 8080:8080 -p 8081:8081 —name container-name —restart unless-stopped -it image-name Но проблема в том что файловая система в контейнере затирается тем что находится в /d/my-local-path/code (а там пусто) Т.е. получается что файлы копируются извне в контейнер, а мне надо наоборот - из контейнера в локальную файловую систему. Буду очень признателен если кто-то подскажет как поправить данное поведение.

это "ожидаемое поведение" докера, раньше сталкивался с таким... Запускал сервисы, правда, через docker-compose. Если каталога (или тома) нет, он создается при запуске и в него копируется содержимое из контейнера. Если каталог (том) есть, то его содержимое будет скопировано в контейнер https://letsclearitup.com.ua/deploy/docker-swarm-stack-deploy-i-imenovannyie-toma-named-volumes.html

Добрый день. Подскажите пожалуйста как быть в данной ситуации? Я создал докер образ в котором присутствует склонированный из гит-репозитория код (файлы исходников). Хочу чтобы файлы исходников были доступны извне. Соответственно я выполняю команду с ключём -v что-то типа такого: docker run -v /d/my-local-path/code:/code -p 8080:8080 -p 8081:8081 —name container-name —restart unless-stopped -it image-name Но проблема в том что файловая система в контейнере затирается тем что находится в /d/my-local-path/code (а там пусто) Т.е. получается что файлы копируются извне в контейнер, а мне надо наоборот - из контейнера в локальную файловую систему. Буду очень признателен если кто-то подскажет как поправить данное поведение.

как вариант - удаляйте каждый раз каталог при перезапуске контейнера или используйте тома (тоже каждый раз создавая новый)

как вариант - удаляйте каждый раз каталог при перезапуске контейнера или используйте тома (тоже каждый раз создавая новый)

т.е. если не будет каталога то файлы должны скопироваться из контейнера в локальную FS?

т.е. если не будет каталога то файлы должны скопироваться из контейнера в локальную FS?

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

Коллеги, кто-нибудь поднимал докер реджистри с самоподписанным сертификатом?

https://docs.docker.com/registry/insecure/#use-self-signed-certificates

http://www.itzgeek.com/how-tos/linux/centos-how-tos/how-to-setup-docker-private-registry-on-centos-7-ubuntu-16-04.html

делаю все по доке и этой статье, но не взлетело

при пуше образа пишет: certificate signed by unknown authority

как вариант - удаляйте каждый раз каталог при перезапуске контейнера или используйте тома (тоже каждый раз создавая новый)

Попробовал так сделать: - удалил локальный каталог - выполняю команду - каталог создаётся но он пустой

Попробовал так сделать: - удалил локальный каталог - выполняю команду - каталог создаётся но он пустой

случайно не докер тулбокс? =)

случайно не докер тулбокс? =)

м... наверное нет т.к. не знаю что такое докер тулбокс :)

при пуше образа пишет: certificate signed by unknown authority

да, там есть нюансы... всех не вспомню, делал давно - точно знаю что эти же сертификаты закидывал в контейнер с гитлабом и на каждой ноде, которая должна работать с реджистри закидывал ca.crt в /etc/docker/certs.d/registry.gitlab.lc:5000/ca.crt (после черо обязательно рестарт докера) https://letsclearitup.com.ua/bash/gitlab-gitlab-ci-docker-registry-s-pomoshhyu-docker-compose.html

случайно не докер тулбокс? =)

Виндовс? Линукс? можете подключиться к запущенному контейнеру и убедиться что внутри в каталоге /code действительно что-то есть?

Виндовс? Линукс? можете подключиться к запущенному контейнеру и убедиться что внутри в каталоге /code действительно что-то есть?

Виндовс. Да я подключался и проверял. Там есть то что мне нужно.