Зачем?

Я нужен здесь

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

>Это может подпадать под какие-нибудь конвенции о запрете пыток и тп

нет, пытка - это читать на перле

писать-то норм

хотя второе означает и первое..

ребята, а как бы вы поступили? У меня есть сервис на фласке, крутиться будет под uWSGI, сервис будет работать на нескольких убунтовых серверах (14.04) Видимо, буду делать setup.py, т.к. сервис отдается админам. Дальше вопрос: как сделать так, что бы сервис писал логи в /var/log/"что-то там"? Ведь он будет запускаться от непривелегированного пользователя

запускать всё дело будет supervisor, видимо

вопрос с логированием. Вариантов ведь несколько, можно в конфиге супервизора прописать куда логировать, можно использовать лог uWSGI, видимо, а можно свой лог писать

ребята, а как бы вы поступили? У меня есть сервис на фласке, крутиться будет под uWSGI, сервис будет работать на нескольких убунтовых серверах (14.04) Видимо, буду делать setup.py, т.к. сервис отдается админам. Дальше вопрос: как сделать так, что бы сервис писал логи в /var/log/"что-то там"? Ведь он будет запускаться от непривелегированного пользователя

syslog?

SysLogHandler?

зачем сервису самому писать логи?

необязательно )) по-этому и возник вопрос "как бы поступили"

необязательно )) по-этому и возник вопрос "как бы поступили"

syslog

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

напомните, ансибл это в какой чат лучше?

https://telegram.me/pro_ansible

вопрос с логированием. Вариантов ведь несколько, можно в конфиге супервизора прописать куда логировать, можно использовать лог uWSGI, видимо, а можно свой лог писать

docker, syslog, elk, kubernetes, rancher, fluentd... там много всего... но первое слово - это решатель основных проблем на слове "видимо буду делать setup.py", пораждает пару неприятностей с логгированием в syslog, но в целом - не критично ни разу.

тут уже пару месяцев назад проскакивала идея, что docker хорош уже даже в режиме замены supervisor-а. Особенно, вместе с docker-compose, кстати.

У меня был один из вариантов - в консоль, а запускающий сам пусть решает (в том же конфиге supervisor)

тут уже пару месяцев назад проскакивала идея, что docker хорош уже даже в режиме замены supervisor-а. Особенно, вместе с docker-compose, кстати.

я уже много раз говорил: докер писали хипстеры. криворукие хипстеры.

вон оно уже всё умеет:) https://docs.docker.com/engine/admin/logging/overview/

я уже много раз говорил: докер писали хипстеры. криворукие хипстеры.

ну возьми rkt :)

вон оно уже всё умеет:) https://docs.docker.com/engine/admin/logging/overview/

нет

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

нет

ну я помню твою боль, но я именно про нее написал, что это не существенно

ну я помню твою боль, но я именно про нее написал, что это не существенно

а куда логгировать приложению? )

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

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

ну вот я знаю про https://github.com/docker/docker/issues/25019

но если ты готов мириться с текстовым логом не разделенным по severity, то всё вполне норм

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

ну вот я знаю про https://github.com/docker/docker/issues/25019

вот про этот костылизм я и говорю

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

с другой стороны, можно, наверное, замапить сокет journald внутрь контейнера и писать в хостовый journald прямо из контейнера. ну а как еще?

У меня был один из вариантов - в консоль, а запускающий сам пусть решает (в том же конфиге supervisor)

ну вот это как делается с докером без отдельных плясок

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

дело не в этом. а в том, что дофига чего хочет писать в /dev/log

что мешало слушать самим этот /dev/log и форвардить в соответствующий log driver.

вместе с stderr/stdout.

с другой стороны, можно, наверное, замапить сокет journald внутрь контейнера и писать в хостовый journald прямо из контейнера. ну а как еще?

я с syslog там делал. но там надо именно каталог пробрасывать.

ну и чо бы нет

дело не в этом. а в том, что дофига чего хочет писать в /dev/log

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

:)

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

больше 1.

больше 1.

ну сам себе буратино, тогда:)

ну сам себе буратино, тогда:)

а что, nginx только с 1 воркером запускать предлагаешь?

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

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

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

ну ты сказал "1 процесс".

приложение одно, процессов много.

ну ты сказал "1 процесс".

ну, ок. одно приложение с его тредами.

ну, ок. одно приложение с его тредами.

процессами )

процессами )

в линухе это будут системные треды же

или он там прямо отдельные процессы запускает и сам их по pid-у мониторит?

Вот, кстати, если у меня есть приложение на django, которое работает из под nginx, gunicorn, а также использует redis, memcashed, solr и ещё чёрта в ступе, не помню уже что именно, как всё это в одном контейнере запустить? Я ни разу не админ, но надо поддерживать такую вот штуку с приоритетом "не бей лежачего". Хочется всё это как-то упростить.

тебе НЕ нужно запускать это всё в одном контейнере

that's the idea

именно

Алилуя, аж отлегло

docker-compose берёшь и оно поднимает пачку контейнеров

Вот, кстати, если у меня есть приложение на django, которое работает из под nginx, gunicorn, а также использует redis, memcashed, solr и ещё чёрта в ступе, не помню уже что именно, как всё это в одном контейнере запустить? Я ни разу не админ, но надо поддерживать такую вот штуку с приоритетом "не бей лежачего". Хочется всё это как-то упростить.

docker-compose тебе помочь должен в задаче этой, джедай

Спасибо! Буду значит ковырять

ну и гуникорн я бы на uwsgi уж сразу заменил;)

Последний раз, когда смотрел в логи, там было что-то про это и deprecated.

и тут уже попробовал и пока вроде норм. пихаю любой фронтенд сервер перед контейнером с uwsgi и ключом --http

типа получается, что оно сразу отдает из себя http, но фасадик ему, конечно, не помешает, но это может быть уже и haproxy и AWS ELB

ERROR: S client not available

или он там прямо отдельные процессы запускает и сам их по pid-у мониторит?

nginx - процессы. ну и у него теперь пул тредов для io. у меня тоже где-то так же. несколько процессов и пул тредов.

и тут уже попробовал и пока вроде норм. пихаю любой фронтенд сервер перед контейнером с uwsgi и ключом --http

как-то http в uwsgi меня не впечатлил =(

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

как-то http в uwsgi меня не впечатлил =(

ты мерял?

ты мерял?

конечно.

я чо-то теже rps намерял танком

я чо-то теже rps намерял танком

смотря во что ты уперся )

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

хочется разделять info/debug/warn

ну и error ессно )

но оно за ELB было в обоих случаях. в одном ELB->uwsgi, в другом - ELB->nginx+wsgi->uwsgi

ну и error ессно )

ну, по кругу ушло обсуждение. это можно, но немного гемор.

а по haproxy vs nginx можно комментарий?

вообще, если только linux не надо shared state между воркерами - лучше просто плодить процессы по числу ядер.

а по haproxy vs nginx можно комментарий?

я не мерял:)

я не про rpc, а вообще

но говорят ELB и есть haproxy

ну, по кругу ушло обсуждение. это можно, но немного гемор.

угу. и крайне не хочется велосипедить.

а по haproxy vs nginx можно комментарий?

смотря для чего. haproxy быстрее на больших объемах и там есть Health checking. в nginx надо будет как-то со стороны это прикручивать.

а haproxy же не умеет ничего кроме http, да?

а haproxy же не умеет ничего кроме http, да?

https://www.haproxy.com/doc/aloha/7.0/haproxy/healthchecks.html

https://speakerdeck.com/mitsuhiko/binary-python

Презенташка Армина с PyCon Belarus 2017

Привет!

Я так и не понял, что же мы будем делать https://www.meetup.com/spbpython/events/236816033/

@annastasy вы не надумали прислать нам кого-нибудь что-нибудь рассказать?:)

Привет, я сегодня спрашивала как раз. Возможно Мехти)

А вы когда к нам?) Следующий митап?

йеей :)

А вы когда к нам?) Следующий митап?

Надо обсудить и подумать. Точно не в марте.

conda/anaconda в linux ведь не популярно?

Почему? Если не хочется заморачиваться с настройкой окружения для data science, то почему бы не использовать такой репозиторий с кучей уже настроенных пакетов?

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