который запускает контейнер с субд (тот еще моветон) и потом контейнер с докером

https://github.com/docker/compose/issues/374

там есть depend_on который не полагается на хелсчеки

но они это исправят

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

через systemd это всё организуется более красиво, чем через .sh

нет

и запускать только когда действительно база стартовала

сейчас через системд нельзя сказать работает ли база или нет

в докере можно выделить ресурсы на пачку контейнеров сразу? нет

да можно

без systemd?

причем тут вообще системд то ?

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

Евгений писал

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

я не уверен до конца, но думаю, что без systemd тут не обойтись

cgroup-parent

при чем тут систем д ? будт бы он вообще какое то отношение имеет к ограничению ресусов

ну, через него удобнее

а тут как? через cgmanager ?

сравнится по удобству пользования с compose файлом будет действительно сложно

как ты создашь группу пофиг. хоть файлами. хоть командами.

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

и тут в целом, наверное, не так важно, что это будет - пачка .service/.target/.slice или compose

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

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

если бы sendmail конфигурировался ямлом до сих пор жил бы.

суть в том, что если меняются лишь версии - можно сделать 1 версию и тащить всегда только её

и 2 репозитория

Но тогда бы пропал целый пласт исскуства

в 1 пушится все версии вообще, в другой только та, которую надо отправить на продакшен

таким образом, при обновлении не меняем эти конфиги на сервере

вы вообще какой вариант используете?

вы поняли, о чём я спросил? ?

вариант 1: у вас на сервере есть конфиг (compose , .service или что угодно), где указаны версии образа контейнера, обновилась версия - вы меняете этот конфиг вариант 2: у вас на сервере есть конфиг, где указана всегда одна и та же версия образа контейнера, обновилась версия - вы меняете её в репозитории (например, копируете из другого репозитория)

1

1.

ибо 2 глупо и не идемпотентно

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

2 вариант не запрещает версионировать

то есть у вас 2 репозитория, в одном разные версии, в другом лишь 1 версия, именно она и идёт на сервер

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

при этом конфиги на сервере остаются такие же

ну а перекинуть из 1 репозитория во второй проще, чем закинуть конфиги на сервер

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

мой вариант деплоя, по-простому, схематически: у вас 2 репозитории, в первой что-нибудь типа: project/app:1.0 project/app:1.1 project/app:1.2 project/app:1.3 project/app:1.3.1 во второй просто 1 образ всегда project/app:na-berlin релиз-менеджер делает pull из первой репозитории, меняет тег на na-berlin и отправляет образ во вторую репозиторию если что-то не пошло и надо откатиться - аналогично, берём другую версию из первой репозитории, меняем тег, отправляем во вторую, тег во второй всегда будет na-berlin , конфиги на сервере всегда будут стягивать с тегом na-berlin

как узнать какая версия была задеплоена вчера ?

у меня это в админке

ну, то есть через docker exec cat ... можно вытащить (если лень открывать браузер и админку)

как узнать какая версия была задеплоена вчера ?

About -> Version? :D

в билд всегда надо версию вкладывать

вот этот вариант позволяет меньше трогать production-серверы

хрена вы нафлудили

например, можно не изучать ansible/salt stack))

мой вариант деплоя, по-простому, схематически: у вас 2 репозитории, в первой что-нибудь типа: project/app:1.0 project/app:1.1 project/app:1.2 project/app:1.3 project/app:1.3.1 во второй просто 1 образ всегда project/app:na-berlin релиз-менеджер делает pull из первой репозитории, меняет тег на na-berlin и отправляет образ во вторую репозиторию если что-то не пошло и надо откатиться - аналогично, берём другую версию из первой репозитории, меняем тег, отправляем во вторую, тег во второй всегда будет na-berlin , конфиги на сервере всегда будут стягивать с тегом na-berlin

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

latest например да ?

>echo $PWD $PWD

echo %CD%

latest например да ?

как latest, но другой по смыслу

latest означает последнюю версию

может, production

latest плоховато, лучше версии биндить

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

поэтому лучше production или как-то так

поэтому лучше версии

и не долбать себе мозг

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

ERROR: S client not available

с версиями надо обновлять конфиги на серверах

а тут можно просто те же самые конфиги юзать

не надо

а как деплоить?

а как щас ?

ну, допустим, сейчас есть nginx.service и там запускается Docker , где указана версия team/repository:project1-nginx-production

если вместо слова production указать версию, то нужно будет обновлять nginx.service на новый nginx.service

с новой версией

слабый какой то пойнт

ты же ходишь на сервера перезапускать

когда ты идешь знаешь что новая версия

и знаешь какую хочешь выкатить

можно передат ьи она стартанет

было 1.1, будет 1.2 и вот ради этого надо будет закачивать новый project-nginx.service на каждый сервер, где этот проект запущен

а юниты это хвост по хорошему

ну кто-то через compose запускает - аналогично же

я про то и говорю, что выгодно иметь 1 версию для продакшена

да да да

а не гонять конфиги с циферками

но мне кажется в будущем с докером должен быть шедулер

и ты не паришься на тему юнитов

он сам смотрит чтобы все это дерьмо работало

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

ну вот этот вариант с production требует лишь пульнуть нужную версию, переименовать в production и пушнуть снова

это можно сделать с обычного рабочего ноута

а перекидывать конфиги - это уже доступ на сервер нужен

так а перезапускается то он сам как ?

ты же все равно доступаешься и рестартишь

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

ужс какой

если в репозитории новые версии - он рестартит .target

билды отдельно деплои отдельно