а там где нужно кластеризация и масштабирование на несколько хостов да обслужвать это все и держать на плаву... "все в одном" не пойдет. Хотя... тут уже будет поздно.

Это я все в теории пока знаю :)

а там где нужно кластеризация и масштабирование на несколько хостов да обслужвать это все и держать на плаву... "все в одном" не пойдет. Хотя... тут уже будет поздно.

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

представляю :) но мы же в группе по докеру

даже на докере можно придумать много вариантов больишх продакшенов, но как вияснилось... одни потом превращаются в боль, а другие нет. В этом и разница :)

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

это я понимаю :)

дальше надо взвешивать

мне товарищи говорили что супервизор в контейнере на котором fpm + nginx + ... это круто тем, что если что-то одно падает то весь контейнер не падает и супервизор потом все поднимет сам.

То есть даже в этом варианте в некоторых ституациях есть свои плюсы :)

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

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

Это кажется одна из основных идей именно докера?

Это кажется одна из основных идей именно докера?

who cares? если удобнее жить в парадигме "5 процессов на контейнер" - нужно плюнуть на это потому что Docker Inc. завещала так не делать?

кстати интересно посмотреть, где именно это записано как заповедь :)

если удобно - живи :)

но не зря же епридумали и написали Best Practices https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/

да и хвала небесам что они есть :)

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

In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers.

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

it depends

best practices это правила готорые подходят для 90% типичных проектов, а 10% не подходят

если у меня один процесс прилаги не имеет смысла в отрыве от другого процесса

best practices это правила готорые подходят для 90% типичных проектов, а 10% не подходят

вот, тоже верно :)

Скалировать горизонтально можно как контейнер с 1 процессом так и контейнер с 2 процессами, ровно ничего не случится.

Ну оверхед будет побольше, зато единица вычисления атомарная.

ну, смотря что за процессы :) опять же... все индивидуально

Например php-fpm и кеш запросов redis

да, если ты сем себе можешь по чесноку обьяснить зачем ты сунул два или более процессов в один контейнер. Норм по моему.

нее fpm и кэш.. не поверю что нужно в один

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

я, как человек учащийся, сперва сделаю по best practices. А кгда я пойму почему они написанны именно так, то уже можно и свои BP писать :)

вот мой кейс. Пришел запрос в API. API поставила задачу в кролика на обработку, количий эксчейндж рассувал задачу во все очереди которые подвязаны. И вот все воркеры которые слушают эти очереди они делают по факту одну и туже бизенсс-задачу. Я по быстрому засунул все в один контейнер, до сих пор не разнес. Работают хорошо.

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

кстати интересно посмотреть, где именно это записано как заповедь :)

Нигде. Это просто бестпрактис

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

rpc ?

rpc ?

ну т.е какой-нибудь https://leonid.shevtsov.me/post/messagepack-rpc/, да? А вот тогда вопрос как им друг другу дискавери сделать самым простым образом. В сворме есть?

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

ты-то сам что используешь? :)

у нас своя поделка в стиле json-rpc

Я бы не использовал rpc, предпочитаю очередь

+1

+1 ну не 90'е же за окном

и на минуточку, Докер же тут не причем. Ты просто строишь распределенную систему

ну вопрос был про SD

Я бы не использовал rpc, предпочитаю очередь

Это разные механизмы и не всегда заменимые

Добре.

Возвращаясь к вечному - nginx+fpm. Если с докером на одной машине все относительно ясно - можно папку монтировать с машины (ИМХО, ни есть гуд), можно отдельный data container сделать.... и прочее.

То в swarm mode не все так радужно.

Есть какие-то костыли для распределенного хранения данных, но все как-то...

Нормальный драйвер для ceph так и не запилили, а то, что было, вроде забросили.

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

Вижу на данный момент оптимальным вариантом - упаковка nginx+fpm+код в один контейнер.

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

Будет. А нужно, как обычно, вчера. :)

Будет. А нужно, как обычно, вчера. :)

это был сарказм. ничего у них не будет

Вижу на данный момент оптимальным вариантом - упаковка nginx+fpm+код в один контейнер.

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

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

Сейчас на проде код подсасывается на все бэкенды через рсинк

но в данный момент пока не о проде

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

ох. рсинк как доставка кода.

ох. рсинк как доставка кода.

о да

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

фб сказал что так только лохи делают

ERROR: S client not available

у нормальных пацанов все юзеры тестируют

идея - упаковался nginx+fpm+код, запустился где-то там в сварме, отработал свое, уничтожился

лол

не ну ок идея.

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

и что именно под этим вы понимаете

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

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

Вижу на данный момент оптимальным вариантом - упаковка nginx+fpm+код в один контейнер.

Я же эту тему месяц мусолил в чатике. Решено было что docker-way это каждый контейнер снабдить нужным кодом.

Если два контейнера с nginx и php-fpm то в каждом должен быть код приложения. Где-то полный, а где то только статика. Но никаких общих шардов с кодом не должно быть. Тому есть ряд причин: отказоустойчивость, обслуживание, масштабирование и прочее вытекающее.

Стройте контейнеры в CI (там же тесты) и доставляйте на продакшен автоматически.

И будет счастье:)

Помнишь я спрашивал про пыхеров и их любовь к странному? Ну так вот пока только они были в этом замечены

Если два контейнера с nginx и php-fpm то в каждом должен быть код приложения. Где-то полный, а где то только статика. Но никаких общих шардов с кодом не должно быть. Тому есть ряд причин: отказоустойчивость, обслуживание, масштабирование и прочее вытекающее.

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

Так будет и докер вэй и масштабируемо

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

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

Коллеги, подскажите правильный путь деплоя имаджей на продакшен после релиза их через Gitlab CI? Какие есть варианты?

У меня был вариант через раннер запущенный на продакшене. Но тогда получается, что часть сценария .gitlab-ci.yml нужно выполнить в раннере с докером на дев сервере, а часть в совсем другом shell раннере на продакшене.

На продакшене все равно запущен докер-демон (сервер), который может получать команды. Может можно как-то его дернуть удаленно и попросить его подтянуть новые образы и запустить контейнеры? Слышал про Swarm и docker-machine... но вот сел читать про это. Подскажите куда читать более правильно :)

https://docs.docker.com/engine/reference/api/docker_remote_api/

https://docs.docker.com/engine/reference/api/docker_remote_api/

Спасибо!

Я хоть в правильном направлении двигаюсь?

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

кстати, а вот и не всегда подходит ваш вариант (когда nginx контейнеру не нужны файлы проекта). Например в корне рядом с index.php лежит robots.txt. Кто же будет его отдавать? ))

robots.txt это статика

та же фавиконка тоже рядом часто лежит.

да, ее должен отдавать nginx но в то же время robots.txt это часть проекта (лежит в одном репо с кодом)

это тоже статика

это понятно что статика. Выше звучало следующее "В нжинксе код приложения не нужен. Всякие скрипты и стили генерить тоже отдельно от приложения"

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

То что это все лежит в одном репо - это просто так получилось. Можно разложить их в 2 репо.

ну, тоже верно :) Ок, Павел, есть мысли по поводу деплоя на прод контейнеров после билда в CI?