Видите, и без дженериков можно кодогенерацией заниматься

спалить еретика!!!!!1111

подскажите как запустить go как демон?

./myapp &

& отвяжет процесс от текущей консоли

Работает в macOS и Linux

а есть полноценный вариант , чтоб старт стоп?

systemd юнит сваяй

или пиши fork-вариант

Можно извьебнутся с форком, можно использовать внешние утилиты

Я за стандартные штуки- лучше systemd

лучше http://supervisord.org/

а systemd - да, отличная операционка

ну это лучше там, где нет systemd, в остальном systemd ничуть не хуже справляется

не холивару ради, но порог входа сильно разный, вот прям СИЛЬНО

нельзя нормально работать в docker

systemd + , делаешь описание, и выполняемый файл лёгким движением руки превращается в сервис

Это к чему?

Про докер

нельзя нормально работать в docker

Ещё как можно.

можно, но не нужно )

наверное в тему про SELinux

и про logind

причем тут сель, вообще? О_о

и про tty которые как бэ есть но их как бэ и нет

o_O-0 причём докер?

проблем с systemd + docker не испытовал

А зачем в докере systemd?

внутри или снаружи конейнера?

А зачем в докере systemd?

Золотые слова!

/me олдфаг, systemd генетически отвергается - все остальное тема для холивара

если нужно внутри контейнера запускать несколько процессов и контролирвать их - хорошо подходит supervisord

подскажите как запустить go как демон?

или https://www.digitalocean.com/community/tutorials/how-to-install-and-use-screen-on-an-ubuntu-cloud-server

можно и systemd, если оплата почасовая

не, systemd очень прост, с учётом что это init процесс - целесообразно в новых дистрах его использовать

не, systemd очень прост, с учётом что это init процесс - целесообразно в новых дистрах его использовать

а без него - не продают, последним вроде Debian сдался (слабаки!)

слака еще держится ??

и кто-то ей пользуется?

Это очень хороший академический дистрибутив

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

ясно понятно для консервов хорошо

Gentoo и Slackware - обрети мудрость, через боль и страдания ))

+1 за systemd unit

(если ты не systemd-хейтер ?)

глупо быть systemd-хейтером в 2017 году, хейть не хейть, реальность упряма

если нужно внутри контейнера запускать несколько процессов и контролирвать их - хорошо подходит supervisord

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

там вчера в systemd уязвимость нашли, кстати

во.. просрали все полимеры

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

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

Именно поэтому официальный обаз registry от Docker запускает несколько процессов внутри контейнера https://hub.docker.com/_/registry/ https://github.com/docker/distribution-library-image/blob/576b139d6eac5b35c9b3e9fe6c2e5132b0c7e03b/docker-entrypoint.sh

Перед "каноном" все равны, но некоторые - ровнее ))

Именно поэтому официальный обаз registry от Docker запускает несколько процессов внутри контейнера https://hub.docker.com/_/registry/ https://github.com/docker/distribution-library-image/blob/576b139d6eac5b35c9b3e9fe6c2e5132b0c7e03b/docker-entrypoint.sh

эм, ненашёл там нескольких процессов

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

Нет таких канонов

эм, ненашёл там нескольких процессов

вероятно стоит подтянуть shell скриптинг

по меньшей мере, одному из нас...

Зачем так издеваться ? С одним процессом ? А если надо будеть читать из сокета ? Маунтить его что-ли ?

Само собой! Прокидывать в volume и читать из другого контейнера!

Кстати shared volume появился относительно недавно

Само собой! Прокидывать в volume и читать из другого контейнера!

так себе решение

так себе решение

Зато целиком каноническое!

Именно поэтому официальный обаз registry от Docker запускает несколько процессов внутри контейнера https://hub.docker.com/_/registry/ https://github.com/docker/distribution-library-image/blob/576b139d6eac5b35c9b3e9fe6c2e5132b0c7e03b/docker-entrypoint.sh

это точка входа, запускающая нужную утилиту в зависимости от параметром запуска контейнера

Нет таких канонов

это официальный best practice

это официальный best practice

ложь

"Each container should have only one concern" != "Each container should host only one process"

https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#avoid-installing-unnecessary-packages

RTFM

ERROR: S client not available

Ну ладно, там написано, что "судите сами, как вам надо"

останемся на том, что все зависит от ситуации

there should be only one operating system process per container

Именно это все и имеют в виду

"Все", лол. Все ты и два твоих друга ламера.

Какой смысл ссылаться на бестпрактис, что бы потом аппелировать к мифическим "всем"?

Либо трусы надень, либо крестик сними (с)

"Все", лол. Все ты и два твоих друга ламера.

Ооо, д'Артаньян в белом

there should be only one operating system process per container

Ага, а если у тебя в докере вебсервер, ему, очевидно, лучше тоже один процессор дать, он же так больше коннектов обслужит!

Ага, а если у тебя в докере вебсервер, ему, очевидно, лучше тоже один процессор дать, он же так больше коннектов обслужит!

процессор?

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

А, чет я невнимательно вас читал, хуйню вякнул, сорь

Не переживай, если в бочку хуйни от Александра добавить еще ложку хуйни от тебя, хуже уже не будет и бочка хуйни от Александа останется ею

Не переживай, если в бочку хуйни от Александра добавить еще ложку хуйни от тебя, хуже уже не будет и бочка хуйни от Александа останется ею

а ты токсичен. тем не менее best practice остается best practice, к тому же доминирующей в докеростроении - в контейнерах используется один системный процесс в 99% случаев.

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

"You may have heard that there should be “one process per container”. While this mantra has good intentions, it is not necessarily true"

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

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

И как это коррелирует с парадигмой "1 процесс на 1 контейнер"?

"You may have heard that there should be “one process per container”. While this mantra has good intentions, it is not necessarily true"

я же выше дал цитату, там же пояснящую что это значит: there should be only one operating system process per container. О чем ты споришь? concern практически всегда сводится к одному системному процессу.

лол

"практически всегда" ПОСОНЫ ИКСПЕРТ В ЧЯТИ

Практически никогда, я бы сказал

Щас бы не приводить примеров и просто так сраться в телеграмме в 2017 :(

Я думаю правильный ответ такой- в идеальном случае лучше запускать 1 процесс на контейнер, но если ваше приложение требует еще каких то сервисных утилит, то их тоже можно запускать, ничего страшного

В целом 1 процесс на контейнер упрощает управление, поскольку когда падает процесс- падает контейнер, который может быть перезапущен чем-то из хостовой машины

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

Я думаю правильный ответ такой- в идеальном случае лучше запускать 1 процесс на контейнер, но если ваше приложение требует еще каких то сервисных утилит, то их тоже можно запускать, ничего страшного

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

Несколько демонов не укладываются в "one concern", чаще всего там бежит разный обслуживающий стафф.

Не переживай, если в бочку хуйни от Александра добавить еще ложку хуйни от тебя, хуже уже не будет и бочка хуйни от Александа останется ею

это будет бестпрактис?

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