AS
ну вот у тебя некий транзакшн менеджер, он пишет какую-то херню в оракл. если их поставить три одновременно писать, то все взорвется
Size: a a a
2020 September 20
ВН
ну вот у тебя некий транзакшн менеджер, он пишет какую-то херню в оракл. если их поставить три одновременно писать, то все взорвется
транзакшн для того и транзакшн вроде чтобы не взорвалось
AS
не с нуля, говорю, процессы описаны уже
ВН
ну я почитаю, но это какая-то хуета. в смысле реально - даже в systemd же cgroups - и если юнит нарожает дочерних процессов - системд их всех убьёт
ВН
не с нуля, говорю, процессы описаны уже
да какая разница. за 3 месяца современные разработчики, тем более 37 человек, разве что хеллоу ворлд говносайтик сделают
ВН
либо там что-то очень простое
AS
ну хз, это какие-то дегенераты может так и делают.
AS
мы соцсеточки в два гисе за неделю делали целые на похапе, пьяные по вечерам )
AS
типа flamp.ru
AS
а мы даже и не программисты даже
AS
хуле там делать, фреймворки, только логику надо туда придумать и запихать, остальное все либами придумано до тебя
ВН
так это речь о том, что если условно вебсервер будет запускать другие процессы в контейнере - он должен их правильно подбирать
ВН
хуле там делать, фреймворки, только логику надо туда придумать и запихать, остальное все либами придумано до тебя
да ебать в рот либы. причём тут либы
k
@vitalif, в общем я бы рассматривал куб не как замену LXC, а как замену systemd.
Один контейнер = один процесс is the true way, остальное костыли.
Логи в stdout, собирать единым логгером, тогда и exit-коды нормально отрабатывать будут.
Один под = один микросервис, он в свою очередь может состоять из нескольких контейнеров, как например nginx и php-fpm.
Один контейнер = один процесс is the true way, остальное костыли.
Логи в stdout, собирать единым логгером, тогда и exit-коды нормально отрабатывать будут.
Один под = один микросервис, он в свою очередь может состоять из нескольких контейнеров, как например nginx и php-fpm.
ВН
просто бизнес-логика занимает время
AS
а в чем трабл написать приложение ?
ВН
@vitalif, в общем я бы рассматривал куб не как замену LXC, а как замену systemd.
Один контейнер = один процесс is the true way, остальное костыли.
Логи в stdout, собирать единым логгером, тогда и exit-коды нормально отрабатывать будут.
Один под = один микросервис, он в свою очередь может состоять из нескольких контейнеров, как например nginx и php-fpm.
Один контейнер = один процесс is the true way, остальное костыли.
Логи в stdout, собирать единым логгером, тогда и exit-коды нормально отрабатывать будут.
Один под = один микросервис, он в свою очередь может состоять из нескольких контейнеров, как например nginx и php-fpm.
ну вот а мне это не нравится
AS
если в ТЗ все написано что и как должно работать
k
Контейнеры вообще могут содержать один гошный бинарник без какой либо ОСи
ВН
@vitalif, в общем я бы рассматривал куб не как замену LXC, а как замену systemd.
Один контейнер = один процесс is the true way, остальное костыли.
Логи в stdout, собирать единым логгером, тогда и exit-коды нормально отрабатывать будут.
Один под = один микросервис, он в свою очередь может состоять из нескольких контейнеров, как например nginx и php-fpm.
Один контейнер = один процесс is the true way, остальное костыли.
Логи в stdout, собирать единым логгером, тогда и exit-коды нормально отрабатывать будут.
Один под = один микросервис, он в свою очередь может состоять из нескольких контейнеров, как например nginx и php-fpm.
мне нравится докер тем, что я могу целиком ПРИЛОЖЕНИЕ в нём описать