по старой статье развернуться

а потом прочел новую и задумался

Забудьте про старую - только новый сварм.

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

root@tester3000:/docker/prometheus-data3# docker attach prom3 You cannot attach to a stopped container, start it first root@tester3000:/docker/prometheus-data3# docker start prom3 prom3 root@tester3000:/docker/prometheus-data3# docker attach prom3 You cannot attach to a stopped container, start it first

root@tester3000:/docker/prometheus-data3# docker cp prom3:/var/log /docker/prometheus-data3/log Error response from daemon: lstat /var/lib/docker/aufs/mnt/4c2c9a13626779ea44796b4203e2510d4510dc1c1c2d9a59fcc4a34c3cff9dc0/var/log: no such file or directory

ни логов ни подключиться (

подскажите пожалуйста как победить?

а что за энтрипоинт?

о сори, ентри поинт это параметры запуска?

docker run —name prom3 -d -p 9090:9090 -v /docker/prometheus-data3:/docker/prometheus-data3 prom/prometheus -config.file=/docker/prometheus-data3/prometheus.ymlr

один символ лишний в конце дело в конфиг файле prometheus.yml - если его меняю на дефолтный то все работает root@tester3000:/docker/prometheus-data3# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e39ca8397cdd prom/prometheus "/bin/prometheus -..." 9 seconds ago Up 9 seconds 0.0.0.0:9090->9090/tcp prom3 а если на свой то сразу после запуска останавливается

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

подскажите как можно подключиться к контейнеру и посмотреть что не так?

к выключенному никак

docker logs prom3 что выдает?

попробуйте через компоуз, там проще дебажить будет: https://github.com/arun-gupta/prometheus

о супер!, спасибо огромное, docker logs была ещё не знакомая мне команда )

спасибо большое!, ему в настройках имя хоста не нравилось оказывается

а ещё внутри контейнера в логах дата на -3 часа от текущей

но думаю если запущу то поправлю )

Кто какие гуи для нового сварма пробовал?

https://github.com/portainer/portainer

это у меня стоит. но оно не умеет пока docker service log

больше походу и нет ничего (

Не помню в каком чате недавно светили пачкой гуи на ноде

МБ тут? https://t.me/pogromisty

Кто какие гуи для нового сварма пробовал?

Rancher умеет уже кажется. Если нужен только гуй, то это конечно оверхед

Нужен только гуй

МБ тут? https://t.me/pogromisty

Нет, ничего такого не ищется по слову докер и docker

Наткнулся на интересную вещь

https://github.com/TomasTomecek/sen

Хочу также, только в irb как chef-shell ;)

подскажите, если у меня конейнер с systemd внутри, а на хосте openrc, то мне ничего не светит?

подскажите, если у меня конейнер с systemd внутри, а на хосте openrc, то мне ничего не светит?

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

на хостовой машине отсутствует /sys/fs/cgroup/systemd

да контейнер не мой к сожалению

на хостовой машине отсутствует /sys/fs/cgroup/systemd

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

чёрт, такой облом, на своей машине отладил конфигурацию, на проде такая засада

да контейнер не мой к сожалению

прям как шутка за 300

контейнер не мой, я лишь спросил

а вообще на чём лучше пускать многосервисные контейнеры?

видел используют supervisor, upstart

systemd какой-то геморный, слишком много хочет

а вообще на чём лучше пускать многосервисные контейнеры?

лучше не пускать :)

ну это понятно

но на каждый пук по контейнеру тоже не очень хорошо запускать

и все вопросы сразу *ПУФ* и отпали )

юзаю supervisor, вроде норм

@voskobovich Какие люди :)

но на каждый пук по контейнеру тоже не очень хорошо запускать

Вполне канонично и удобно.

@voskobovich Какие люди :)

хм...) интересные люди)

Кстати, в интернетах коливарят на тему крона в докере и все дела. Я тоже обумывал костыльность всяких кронов в докере и мне пришла идея... а что, если юзать крон хост системы? Ну то есть запускать процесс через контейнер с крона на хосте. Например как-то так: docker exec container_name php my_cron_task

Вроде это ничего не нарушает, бест практикс и прочих. Все вполне себе логично. Что скажите?

Кстати, в интернетах коливарят на тему крона в докере и все дела. Я тоже обумывал костыльность всяких кронов в докере и мне пришла идея... а что, если юзать крон хост системы? Ну то есть запускать процесс через контейнер с крона на хосте. Например как-то так: docker exec container_name php my_cron_task

а если у тебя swarm?

Кстати, в интернетах коливарят на тему крона в докере и все дела. Я тоже обумывал костыльность всяких кронов в докере и мне пришла идея... а что, если юзать крон хост системы? Ну то есть запускать процесс через контейнер с крона на хосте. Например как-то так: docker exec container_name php my_cron_task

все ничего - деплой усложняется

а если у тебя swarm?

ну у меня его пока что нету :)

мы в дженкинсе гоняем

А какие проблемы с деплоем?

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

Была у тебя одна проблема, стало две

А какие проблемы с деплоем?

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

Наиболее вменяемый вариант это наследовать контейнер с приложением и делать для него cron-like entrypoint

ERROR: S client not available

и запускать его рядом

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

это противоречит концепции

угу

инструкция должна быть внутри а не снаружи

фак :(

инструкция должна быть внутри а не снаружи

+1

ок, как решают задачи которые должны выполняться по расписанию?

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

зачем?!

как это зачем, деплоить по расписанию например

или еще чего

ок, как решают задачи которые должны выполняться по расписанию?

от крона же зависит, если это например надор тасок, связанных с базой, то удобно в дженкинсе это хоязйство держать (мы просто не держим БД в докере)

как это зачем, деплоить по расписанию например

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

плохая, но лучше чем крон на хосте)

можно это залить пачкой куда-нибудь и будет там также

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

Супервизор в отдельном контейнере лежит.

контейнер не должен ничего знать об окружении

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

но все же это надо закладывать сразу. А что если есть уже система заточеная под крон (расписанием стороняя программа занимается)?

если вам нужны какие-то фоновые задачи, сделайте свой шедулер на уровне приложения и точку входа в шедулер поставьте в entrypoint

если вы свою бизнес-логику начинаете вытаскивать куда-то наружу — вы огребёте тухлой треской по еблу

если вам нужны какие-то фоновые задачи, сделайте свой шедулер на уровне приложения и точку входа в шедулер поставьте в entrypoint

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

чёт, alpine какой-то каличный, поставил gcc, пробую собрать простейший main.c, выдает ошибки линковки с crti.o

Мало того, контейнеры с шедулерами НЕ должны дублироваться.

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

выше посмотри

Мало того, контейнеры с шедулерами НЕ должны дублироваться.

причём тут докер-то?

причём тут докер-то?

всмысле? В контейнере все окружение и все зависимости.