Fluentd

т.е. хост фасилитис

Гоебаный айфон дал написать с 3 попытки

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

Кого рестартануть? Флюента такой же контейнер рядышком

ок

Который шлёт вот это все в спланк, Клауд, и т.д.

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

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

нормализация процессов, тобишь попытка разбить приложение на несколько контейнеров обернулась долгиму и мучительными размышлениями, 1. должны ли кроны выполняться в своих собственных контейнерах или нет? 2. должен ли в каждом контейнере быть свой сислог? 3. есть ли nginx отдельная часть или его можно запускать вместе с основным приложением внутри какие мысли у вас, коллеги

2 нет 3 что такое "отдельная часть"?!

1 сам задаю себе такой вопрос

ну к примеру есть приложение на python + uwsgi, нужно ли контейнер запускать с uwsgi only процессом или же сразу с запущенным перед ним nginx

все внутри одного контейнера

Два коньейнера nginx и wsgi

Я правда не знаю что делать если через сокет. Вроде можно через общий диск, но я не пробовал.

ну то можно порт открыть

что за кроны что скажет?

А что в кронах то?

Наши кроны дёрнуть урл

ну к примеру есть приложение на python + uwsgi, нужно ли контейнер запускать с uwsgi only процессом или же сразу с запущенным перед ним nginx

как сделали мы: джанга+ гуникорн в одном контейнере, nginx во втором рядом. никаких сислогов, никаких кронов! зачем крон? celerybeat вам в помощь

Наши кроны дёрнуть урл

т.е. по крону дергаете урл на запущенном контейнере?

как сделали мы: джанга+ гуникорн в одном контейнере, nginx во втором рядом. никаких сислогов, никаких кронов! зачем крон? celerybeat вам в помощь

да, но крон иногда все-таки нужен

Пока да, но не очень нравится. Вариант с очередью ближе как-то

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

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

да, но крон иногда все-таки нужен

например?

сихронизироваться с источником данных, скажем обновиться из api

стоп. стейтлесс приложение обновляется?

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

запустили контейнер, он запроси API , получил данные для работы, через 5 минут синхронизировался снова

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

сельдерей-бит мы для этого готовим

а что делать, если клиент отвалился от очереди?

как обеспечить безусловную синхронизацию

а вообще, как говорит Чистяков, я мало знаю, если честно

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

когда говорят про мониторинг докера, почему-то всегда тишина про cadvisor

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

дивный узкий мир

а что делать, если клиент отвалился от очереди?

В SOA времена за такое возвращали в очередь, насколько я помню

?

файловую систему я мониторю, и диски тоже

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

Сервис контейнера кто мешает чекать? Да и агент какой-либо может отчитываться.

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

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

Дискаверить, не? Вы же наверняка знаете, куда именно блуждает контейнер.

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

Что такое "здоровье контейнера"?

Что именно становится проблематично?

И почему это контейнер блуждает? У меня ничто никуда не блуждает

А будет блуждать - будет регаться в Consul

Я вообще тут никакой проблемы не наблюдаю

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

Что такое "здоровье контейнера"?

здоровье это состояние процессов внутри

здоровье это состояние процессов внутри

повеяло badoo

чую подвох вопроса в том, что нехдоровый должен был упасть

здоровье это состояние процессов внутри

Ну - вот и ответ на вопрос

Мы состояние процессов и мониторим

Обычным образом

нездоровый может медленно умирать

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

Руками? O_O

скриптом самописным ака руками

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

Так consul templates же

rancher, cadvisor… хм

cadvisor… да .. я вчера с шипиярдом зачем то его спутал... каюсь

кстати,шипярд выглядит интересным. Я его еще не трогал за разное, и дискуссию видел, но не прочитал за рулем. К чему пришли?

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

comstatbot.xyz/chat/-1001030317489

какой пиздатый бот

он самописный?

или что-то более-менее распространенное

какой пиздатый бот

хочешь в сетевой чятег его?

нет

!!

не надо в сетевой ничего со статистикой

и логированием

хехе

а вот как вы мониторите pid процесса который в pid файле записан? неужели все делают свой велоспид на shell + awk? неужели нет какого-то стандартного плагина для заббикс-агента или icinga?

Что значит "стандартный плагин заббикс-агента"? И что значит "мониторите pid процесса"? Живость? Память? CPU? Память в байтах?

живость, память, CPU, state

А в чём проблема сделать ps и указать тот пид из файла?

/me улыбает что живость процесса проверяется по pid файлу ;)

/me

/me улыбает что живость процесса проверяется по pid файлу ;)

Рассказывайте, как проверяете живость процесса?

zookeeper + инфернальная нода на нем - самый простой случай

redis + протухающий ключ + подписка на событие изменение ключа

/me улыбает что живость процесса проверяется по pid файлу ;)

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

ну к примеру есть приложение на python + uwsgi, нужно ли контейнер запускать с uwsgi only процессом или же сразу с запущенным перед ним nginx

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

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

imho эта пардигма себя уже изжила и в контейнере должен жить не процесс а бизнес юнит