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

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

у каждого образа контейнера приложения есть код билда, который формируется на основе времени (ну, как-нибудь так: gdate -d "Aug 21 1987" +%s | xargs ./bashids -e ), он используется как часть имени файлов (папка) при закачке в хранилище (потому что там адский кеш для снижения затрат), то есть у каждого образа будет персональная версия статики в хранилище

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

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

Хайлоад.

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

в ноябре же?

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

в ноябре же?

Да

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

у меня все python-зависимости ставятся при билде образа через RUN

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

а чем это плохо? вот ptchol, похоже, считает наоборот

у меня все python-зависимости ставятся при билде образа через RUN

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

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

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

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

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

у меня нет compose'а) у меня есть пачка systemd-сервисов) но это не важно тут) я могу тестировать или во время сборки (внутри docker build или снаружи) до попадания образа в хранилище или на CI после скачивания из хранилища для тестирования

а плоско мыслить - это когда есть 1 вариант и не сомневаешься)

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

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

ну, а systemd работает же) systemctl enable ... .service

эээ —restart-policy always?

или как то так

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

эээ —restart-policy always?

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

поэтому у меня systemd

но в данном случае вопрос про другое

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

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

на продакшене у меня systemd + Rkt

кстати, я обратил внимание, что Scaleway образы виртуалок докером собирает)

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

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

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

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

можно все сайты на разные VPS'ки, на каждой будет по 3 контейнера, запускать через rkt fly (то есть оставляем все плюсы от докера, собираем докером, доставляем докером, а на самом сервере двойную виртуализацию не делаем), если все VPS'ки на разных серверах - так безгеморнее всего) а если по условию 1 сервер - тогда 1 вариант мне кажется более правильным) 3 на каждый проект + 1 балансировщик на nginx/HAProxy

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

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

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

ERROR: S client not available

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Окей,спасибо. подскажи как схему правильно изначально собрать?

пернесишь все это дело через scp

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

вот task

В докере только разбираюсь, поэтому и совета прошу у вас)

эм.

заббикс агент ортогонален докеру

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

мониторить контейнеры придется по другому

другими инструментами

другими инструментами

можно написать обертку?

можно написать всё что угодно.

были бы руки...

но есть ли в этом смысл ?

контейнеры живут по 5 минут.

какой тут забикс агент

эм... а зачем в них агент?

он там не нужен