Когда надо запустить и забыть

Но обновляться все таки должно

Очень специфический случай, у нас так geoip работает, например

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

а статика генерируется в контейнере?

Не в контейнере во время билде, это точно

Пришел засвидетельствовать нам существование Rkt?

Если воспринимать статику как один из артефактов приложения, то и деплой артефактов вероятно должен происходить во время деплоя приложения.

ну я имею ввиду. а надо ли вообще эти два процесса связывать?

Миша ! Спасибо за билет ! Привет )

привет ) Пожалуйста )

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

Ииии ?

Представь что у тебя пакет с 10 зависимостями. Ты спрашиваешь ставить тебе их как то в момент инсталляции системы, или когда ты пакет собираешься ставить ?

Миша ! Спасибо за билет ! Привет )

кстати там у вас в московии намечается еще что то инетересное? я б скатался

Хайлоад.

Но дорого и я не пойду

в ноябре же?

Саша Титов утром рассылку делал, что в феврале они devopsdays Moscow хотят делать

в ноябре же?

Да

Ты опять плоско мыслишь. Зависимости высокоуровневые у тебя в композе. А докерфайл он про сборку конкретного артефакта

Не нужно выдумывать боль аналогичную генерации конфигов из постинсталов

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

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

а никакого демона не придумали для автостарта контейнеров после ребута, только systemd?

Compose в продакшене все равно никто не использует.

эээ —restart-policy always?

или как то так

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

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

гайз, извините за нубский вопрос, но как православнее пару сайтов завернуть в докер? каждому сайту по отдельному контейнеру с nginx, php и mysql, или все сайты просто 3мя контейнерами обслуживать, добавляя vhost'ы в nginx?

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

cмотря какая цель

я бы выбрал епервый вариант

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

гайз, извините за нубский вопрос, но как православнее пару сайтов завернуть в докер? каждому сайту по отдельному контейнеру с nginx, php и mysql, или все сайты просто 3мя контейнерами обслуживать, добавляя vhost'ы в nginx?

А зачем каждому контейнеру nginx?

первый вариант норм

А зачем каждому контейнеру nginx?

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

А зачем каждому контейнеру nginx?

да и речь не про каждый контейнер шла, а про каждый сайт.

Присоединюсь к обсуждению(похожая задача), есть VPS, и на нем сейчас несколько сайтов( что-то самопись(html+css+js) , что то CMS( WP /joomla) что-то и использованием фреймворка (nodejs+angularjs) , как правильно, и стабильнее реализовать, и плюс, хотелось бы мониторить все это, я так понимаю в каждый контейнер по агенту заббикса надо будет добавить потом. Вариант : в каждый контейнер по сайту, с его зависимостями, плюс mysql ,(и отдельно NGINX контейнер, и туда все хосты прописать) или есть другие альтернативные методы?

агенты заббикса не нужны в контейнерах. тот же nginx и php мониторится забиксом путем парсинга внешних страниц со статой. mysql путем парсинга ответа от запроса

По mysql вопрос, надо ли его в каждый контейнер пилить, или же в один лучше и несколько баз там организовать ?

тут правильно заметили - смотря как использовать планируется.

Имхо, можно удариться в крайность вообще 1 процесс - 1 контейнер

Имхо, можно удариться в крайность вообще 1 процесс - 1 контейнер

не крайность а бест практис ! )

оно бест практис только для проектов которым scaleout нужен ДЕЙСТВИТЕЛЬНО... а для "несколько сайтов разбросать по окружениям", оно не бест практис от слова вообще

IMHO ;)

ну и я вот правильно понимаю... что ноги у логики "1 процесс= 1 контейнер" торчат непосредственно из cgroup, поскольку городить свой init докеру ну вообще не с руки, потому что глюков будет больше со start\stop контейнера..

let the срач begin

ну и я вот правильно понимаю... что ноги у логики "1 процесс= 1 контейнер" торчат непосредственно из cgroup, поскольку городить свой init докеру ну вообще не с руки, потому что глюков будет больше со start\stop контейнера..

хммм. а мне показалось что у них свой "супервизор".

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

на внезамно прометоусовской конфе :)

Порасказывал сегодня в Питере https://youtu.be/5PNyRdIXP90?t=1h22m2s

Чё там, огонь?

ну чувак запилил супервизора для докера

ща может сам явится

Имхо, можно удариться в крайность вообще 1 процесс - 1 контейнер

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

кстати вот эту штука может быть полезна @alloprm

я вчера пока смотрел думал как раз про ваш кейс с пуппетом и раскладкой файлов.

@prepor а чего в релизач какая то старая версия. вчера на телике было 10-чото там

а в релизах гитхаба 9

ну и я вот правильно понимаю... что ноги у логики "1 процесс= 1 контейнер" торчат непосредственно из cgroup, поскольку городить свой init докеру ну вообще не с руки, потому что глюков будет больше со start\stop контейнера..

хочу заметить, что правильный init нужен и без нескольких отдельных процессов, а 1. в кейсай one-shot форков, типа "запустить imagemagick" или там ffmpeg какой нить для конвертинга. 2. мастер-воркер инфраструктуре процессов типа nginx, unicorn, uwsgi etc

кроме того, текущий докер _форсит_ неправильную обработку сигналов в старт/стоп запуская ДВА процесса, а не один при указании CMD в виде my_service start 8000, запуская его внутри sh -c

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

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

@prepor а чего в релизач какая то старая версия. вчера на телике было 10-чото там

а я забил релизы делать, основной способ распространения — докер

кому нужны эти бинарнички

я думаю что лучше сделать так контейнер nginx + mysql + для логов + и по контейнеру для CMS отдельно + контейнер для zabbix , есть еще вариант удобней?

какой смысл собирать такую схему ?

какой смысл в заббиксе в контейнере ?

какой смысл в заббиксе в контейнере ?

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

заббикс не нужен ни в докере ни без него.

но в докере особенно бесполезен

может еще и докер не нужен?:)

какой смысл собирать такую схему ?

к примеру смена VPS, контейнер взял и перенос, потратив некоторое время, а так с нуля, был опыт( когда еще выбирал VPS, и неудачный был выбор когда то давно)сидишь сетапишь все самого начала, настраиваешь, полюбому какой то бекап не заводится, зависимости, или правило какое то в конфиге, или еще что то .

может еще и докер не нужен?:)

к сожалению нужен

но заббикс точно не нужен

к примеру смена VPS, контейнер взял и перенос, потратив некоторое время, а так с нуля, был опыт( когда еще выбирал VPS, и неудачный был выбор когда то давно)сидишь сетапишь все самого начала, настраиваешь, полюбому какой то бекап не заводится, зависимости, или правило какое то в конфиге, или еще что то .

докеркомпоуз решает вопрос переноса

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

и локальные тома для проброса