Lex
Пиздец, ебанный пиздец
Lex
Я бы еще по почкам настрелял, но думаю уже поздно
Sergey
Делай PR и впили им туда json.dumps
В питон-то? Нееееее, там цельная философия вокруг этого. Import this, вот это вот всё.
А разрабы и так переделают постепенно, главное донёс.
Lex
Еще небось в syslog логи пишут?
Александр
Eventlog
Sergey
Еще небось в syslog логи пишут?
эммммммммммм
Ты так написал, как будто это что-то плохое. Что с ним не так? O_o
rsyslog шикарно их разрывает-парсит-подписывает и заливает в Graylog.
Sergey
Самое забавное и приятное, что это всё дело практически не жрёт проц.
Lex
Ну тут большой холивар, есть адепты сислога, записи в файл и записи в stdout
Lex
Периодически случаются баталии по этому поводу
Sergey
А, вон чего. Смотри.... Питонячьи приложния часто пускаются из супервизора, а у него с прокидыванием stdout/stderr возникают иногда затыки (этакий блуждающий баг, который всё никак не починят - периодически всплывает под разными номерами issues).
Поэтом проверку жёстким продакшном прошёл только UDP на 514, то есть локальная доставка в слушающий порт rsyslog.
Разумеется, не факт, что подобная схема заработает без изменений в случае доскера и его друзей - там свои приседания.
Sergey
Поэтому правильный ответ определяется только особенностями окружения и способностями человека/команды, которым это всё достаётся на поддержку.
Lex
Проблема с сислогом в том, что может проебывать логи, если это не критично, то все ок
Sergey
Проблема с сислогом в том, что может проебывать логи, если это не критично, то все ок
rsyslog? ссылку на issue бы хоть одним глазком.....
Lex
UDP
Sergey
А! Дык на 127.0.0.1 UDP просрать - это ещё надо постараться.
Vladimir
Lex
И да, есть же /dev/log
Sergey
Есть. Но UDP надёжнее с точки зрения работоспособности приложения. Сервис первичен, логи вторичны. Ну в смысле - понятное дело, что rsyslog мониторится, все дела, но деньги мы зарабатываем сервисами, а не логами.
Roman
Mikhail
В связи с разрастанием количества проектов на докере возник такой вопрос:
есть разные окружения (dev, stage, prod)
контейнеры под них должны немного различаться, эти различия делаю через указание build-arg при билде и в основном это все сводится к копированию разных конфигов в докерфайле
Т.е. есть пачка скажем конфигов nginx: nginx.conf-dev, nginx.conf-prod, ... которые незначительно друг от друга отличаются
Суть: при внесении изменений я задолбался вносить их во все версии и прихожу к свежей мысле, что версии конфигов должны генериться из одного шаблона.
Шаблон должен быть читаемым и похожим на сами конфиги.
Подскажете что-нибудь такое?
Lex
ансебль?
Viktor
хоть ansible, хоть puppet
Bsod
Mikhail
вообще я про питон думал, просто подозреваю что кто-то это уже сделал и прошел путь до конечного варианта
Mentat
Andrew
+
Даня
Andrew
salt/ansible - шаблоны, переменные, таргетинг и вперед.
Lotus
оронул
Lotus
и у него получился ансибл
Lex
В связи с разрастанием количества проектов на докере возник такой вопрос:
есть разные окружения (dev, stage, prod)
контейнеры под них должны немного различаться, эти различия делаю через указание build-arg при билде и в основном это все сводится к копированию разных конфигов в докерфайле
Т.е. есть пачка скажем конфигов nginx: nginx.conf-dev, nginx.conf-prod, ... которые незначительно друг от друга отличаются
Суть: при внесении изменений я задолбался вносить их во все версии и прихожу к свежей мысле, что версии конфигов должны генериться из одного шаблона.
Шаблон должен быть читаемым и похожим на сами конфиги.
Подскажете что-нибудь такое?
различие контейнеров для разных енвов это антипаттерн, так делать нельзя от слова совсем
Mentat
оронул
Я тут просто недавно смотрел на одну нашу внутренную схемку таскраннера в виде конечного автомата и подумал что я же где-то все это уже видел
Mikhail
ну да, я тоже думал про антипаттерн и т.п., а потом когда устал от выкрутасов что б все работало и на локалхосте и в проде и еще и одинаково понял что два простых конфига проще чем один, но мутный. А если эти два будут генериться, то и проблема имхо уходит
Lex
который ECS?
Mikhail
угу
Eugeny
ну да, я тоже думал про антипаттерн и т.п., а потом когда устал от выкрутасов что б все работало и на локалхосте и в проде и еще и одинаково понял что два простых конфига проще чем один, но мутный. А если эти два будут генериться, то и проблема имхо уходит
так проблема в том что у вас много немного разных конфигов?
Andrew
» понял что два простых конфига проще чем один, но мутный.
Вот это кстати очень правильный вывод.
Lex
ну да, два конфига и ранскрипт который выбирает нужный в зависимости от переменной окружения
Lex
но опять-же будете страдать, так как тестирование контейнера не даст ответ о его поведении в проде
Mentat
да и их надо делать чем-то
я для какой-то башевой тулзы на узкую задачу брал просто саму jinja2 - шаблонизатор который пользуется ансибл - и пускал ее стандалон
Leonid
А! Дык на 127.0.0.1 UDP просрать - это ещё надо постараться.
И я! И я тоже умею!
(правда же тут перипись тех, кто умеет на localhost буфер сокета забить?)
Mentat
И я! И я тоже умею!
(правда же тут перипись тех, кто умеет на localhost буфер сокета забить?)
и забывает подкрутить ядро еще, ага)
Lex
:)
Mikhail
ну да, два конфига и ранскрипт который выбирает нужный в зависимости от переменной окружения
тоже похожий вариант
в принципе, кто мешает тестировать все версии и разными тестами?
Lex
тоже похожий вариант
в принципе, кто мешает тестировать все версии и разными тестами?
а зачем вам разные конфиги?
Sergey
Lex
в плане в чем там различие?
Lex
просто интересно
Eugeny
коллеги решили похожую проблему примерно так: конфиг внутри сервиса, когда сервис стартует он идет регистрироваться и отдает свой профиль: dev например, в ответ ему отдают настройки - url db 0.0.0.0 и тд.
Lex
переизобрели service discovery?
Lex
нуну
Lex
ааа, тогда хорошо, а то Я такие велосипеды видел, плакать хотелось
Lex
да хоть разные роботс.тхт, разные конфиги нжинкса
оу, у вас еще и контент статический отличается?
Eugeny
хотя судя по контексту тут не в этом беда
Mikhail
я как раз и пытаюсь упростить ситуацию и не залезть в новые горизонты
Lex
ну тогда, одинаковый артифакт для всех окружений, (докер образ), окружение определяется через переменные окружения/сервис дискавери
Mikhail
оу, у вас еще и контент статический отличается?
например на проде добавляется локейшн для хелс-чеков, что-то можно спрятать под авторизацию, какие-то такие различия
Lex
по хорошему k8s и configmap решают эту проблему
Lex
так как конфиги nginx будут определятся окружением
Lex
и их можно запихнуть в helm тот-же
Lex
ну или consui-template
Mikhail
да, надеюсь до к8 руки дойдут, спасибо
Lex
а вот как это на AWS ECS сделать Я хз, тут надо ребят с опытом кастовать
Mikhail
ну тогда, одинаковый артифакт для всех окружений, (докер образ), окружение определяется через переменные окружения/сервис дискавери
интересно, там удастся обойтись без развесистого стартап скрипта, подсовывающего нужное?
Lex
а вот с разной статикой (минимизация/обфускация js) и т.д. тут конечно вопрос, у нас просто то, что собирается из master ветки по умолчанию минимизированно/обфусцированно, то, что собирается из фичабранчей не проходит этот этап — упрощается дебаг там, где это критично
Lex
интересно, там удастся обойтись без развесистого стартап скрипта, подсовывающего нужное?
RUN ["nginx", "-c", "/nginx.${ENV}.conf", "-g", "daemon off;"]
Lex
путь к robot.txt в том же конфиге nginx можно менять
Mikhail
в exec режиме же енвы не должны раскрываться?
Lex
а вот не помню, но, эту строку можно запихнуть в
/run.bash
и получать удовольствие
Mikhail
ну удовольствие все ж немного подпортит процесс шелла поверх всего остального, не то что бы так делать нельзя, но это мне тоже не совсем нравится