« Rev
@symfony_ru   821
Fwd »


Юра
Вообщем ) нет никакой абсолютно разницы запустишь ты процесс в существующем контейнере или в отдельном
Юра
И там и там оверхед одинаковый
Юра
Ну там метаданные контейнера какие-то
Юра
Мелочи
Юра
И вообще это бест практис поэтому лучше сразу делать правильно
Юра
Так как обычно метрики собираются по контейнерам логи и т.д.
Юра
Можно отдельно поставить мемори лимит контейнерам чтобы если вдруг потекло что-то то ядро прибило один контейнер с одним консюмером
Михаил
по поводу оверхеда - спорно по поводу метрик и логов - всё прекрасно работает и с swool и rr и с лимитами тоже ок а вот деплой помимо приложения 10 джоб отдельными подами (и отдельными деплойментами) - полный треш
Юра
Ну ты решил что это треш, это твоя точка зрения
Юра
Лично я считаю что этоне треш. Я захожу в ранчер и нахожу контейнер с консюмером, вижу стату по нему так же как и для всех остальных типов деплойментов. Метрики и логи собираетт отдел девопсов и я тоже вижу это все так же в одном месте. Это удобно и это работает нормально
Юра
Твой подход тоже жизнеспособен
Юра
Просто нам это неудобно
Юра
Нам не нужен отдельный гипервизор или отдельный сбор логов или метрик так как это все делается автоматически инфраструктурой кубера. Как и деплои и рестарты
Юра
Твое решение имеет лишь один мифический плюс, это меньше оверхеда (что ещё нужно проверить)
Юра
Больше плюсов я не вижу
Юра
Плюс у нас есть клнсюмеры которые допустим работают с графикой, там стоят дополнительные расширения которых нет нигде больше. Так же и в других специфичных консюмерах например обработка пдф
Юра
Развивая твою мысль можно и микросервисы запускать в одном контейнере зачем им отдельный контейнер
Юра
А потом можно в принципе и удалить докер, так как все в одном контейнере и так
Михаил
Вцелом и твою мысль можно так развивать и каждый http эндпоинт в свой контейнер посадить Bg жобы - часть одного приложения и должны жить в нём
Михаил
Джобы - это просто консольные команды. Они уже есть в приложении и их код уже лежит мёртвым грузом в контейнере. Когда приходит http реквест - он дёргает контроллер. Пусть systemd дёргает консольные команды
Михаил
Я за идею упаковки. Вы или создаёте отдельную кодовую базу как отдельное приложение для бг жоб или уж будьте последовательными и упакуйте приложение в один контейнер
Михаил
Плюс вопросики по деплою вот этих отдельных контейнеров, которые на самом деле инкапсулируют одно и то же приложение, просто запускают разный код. Как там ожидание развёртывание и погашения будет работать, как организовать liveness пробы для бг жоб. Как health запросы обрабатывать?
Михаил
Я не хочу принизить твой способ. У себя на проекте мы жили и так как ты говоришь, и так как я говорю, но пришли к способу с упаковкой в один контейнер Справедливости ради там тоже есть проблемы с «умиранием» пода, но хотя бы масштаб меньше
Михаил
Кстати, а тут раскуривал тему микроконтейнеров? Как сделать так чтоб контейнер с пыхой весил чуть больше чем главный процесс. Я просто вообще не понимаю. Весит как жопа мамонта. А с нуля прыгать в эту тему дико лень сейчас.
#lest
Запускай консюмер в отдельном контейнере
У меня там di все это копировать? Так как запускать в самом докер файле прописать запуск через & (в таком случае она у меня падает, не разбирался еще почему), а запускать через php зачем, она будет это запускать при каждом запросе на нее
#lest
Мне надо чтобы при поднятии докера она запустилась и работала
Павел
Мне надо чтобы при поднятии докера она запустилась и работала
Прописываете Command /CMD в докере как запуск воркера, если хотите отдельный контейнер на каждый воркер. Или же ставите какой нить супервизорд и делаете его главным процессом контейнера и он все поднимает и скейлит.
Юра
https://youtu.be/StYhR1pWqQw?si=Uovbhe8CpI7EQy9w
Юра
Извиняюсь за видео на это реально смешно
Михаил
Ладно, раз мы кидаем сюда смешнявки не про it - то вот
#lest
Сейчас только протокол vless работает нормально
Михаил
А кто нибудь на своей галере делает мутационные тесты? Помогает? Стоит того?
Maks
галера и тесты в одним предложении, смешная шутка)))
Михаил
Ладно, ладно. В компаниях в которых вы работаете, может в пэт проектах. Просто я знаю про траблу плохих тестов, про самообман. И вот интересно, если не хочется TDD но хочется качественные тесты - решают ли мутационные тесты эту проблему.
Михаил
я на прошлой делал)
Плоды приносило? Часто находил неочевидные косяки в тестировании? Как работало с хрупкими тестами?
Aleksandr
ну если конечно у тебя не проект где все уже хорошо
Aleksandr
а таких не бывает)
Юра
А что код кавераджа недостаточно чтобы понять что тестируется все? Или мутационные тесты дают ещё какие-то преимущества?
Aleksandr
сложно, долго
Юра
Используй обычный каверадж, если этого будет недостаточно тогда уже можно думать дальше
Михаил
Используй обычный каверадж, если этого будет недостаточно тогда уже можно думать дальше
Ну вот я и пишу что tdd иногда бывает сложно ввести. Поднимал тему на прошлой работе - на минном поле и то легче
Михаил
да и то даже по тдд я напишу тест на одну строчку из многострочного метода, допустим $c = $a + $b; в качестве $a и $b задам двойки, получу свою четвёрку и мой тест позеленеет но вот беда $c = $a * $b; даст тот же результат. И вот вопрос, мутационные тесты сильны только в арифметических операциях или могут дать ещё бенефиты.
Nikolay
Ну вот я и пишу что tdd иногда бывает сложно ввести. Поднимал тему на прошлой работе - на минном поле и то легче
Не под все кейсы тдд подходит, где-то очень хорошо ложится, а где-то лучше просто обычные тесты написать
Михаил
это всё тоже понятно
Dmitriy
нам "на нашей галере" ковереджа хватает, пробовали втащить infection, посмотрели мутантов, смысла не увидели а пример с $a + $b хороший, пытаемся такие кейсы глазами высмотреть потому что такого мутанта все равно бы не нашли в общей огромной куче
Dmitriy
а коверейдж именно в МРах хорош, когда наглядно видно на ревью, какие строки кода не покрыты тестами
Maks
а что значит на ветки?
представь тело функции return $a >= $b ? "a" : "b";
Maks
строка одна и коде кавераге покажет 100%, а веток две)
Maks
метрика так и называется branch coverage
Михаил
а коверейдж именно в МРах хорош, когда наглядно видно на ревью, какие строки кода не покрыты тестами
Блин о каком кавередже вы все говорите? Вы про методологию tdd? Да она даёт 100% покрытие, но как я уже приводил пример с двойками - этого не достаточно
Юра
Твой пример с арифметикой чисто вакуумный пример
Юра
На практике будет много разных тестов которые скорее всего покроют твой пример
Юра
Но ты любитель взять какие-то крайние варианты
Юра
И развести на ровном месте холивар )
Юра
Есть проблема конкретно? Решай. Нету проблемы, не решай
Михаил
На практике будет много разных тестов которые скорее всего покроют твой пример
И будут куча других примеров которые схожи с «двойками»
Юра
Ну вот когда будут тогда можно подумать над мутационные и тестамм
Юра
Я пока один раз только встретил такое
Юра
И то оно не приводило к чему-то ужасному и было словнено когда добавился ещё один тест
Михаил
И развести на ровном месте холивар )
Простите пожалуйста, но я не разводил холивар - я искал смысл в таких тестах. Вы высказались, спасибо. Я ждал других мнений. Если кто и разводит холивары на пустом месте, так это вы. Я вам одно предложение а вы мне 10 в ответ. Сами почитайте.
Юра
А сори я тебя с муравьем спутал
Михаил
Блин о каком кавередже вы все говорите? Вы про методологию tdd? Да она даёт 100% покрытие, но как я уже приводил пример с двойками - этого не достаточно
Короче я понял. Погуглил - вы про phpunit/php-code-coverage Ок, тогда всё встаёт на свои места. Тогда это нужно идти отдельно разбираться как сделать так, что бы пайплайны падали, если тест покрыл (условно) метод, но сделал это не до конца.
Юра
У нас падает если каверадж уменьшился
Юра
Иногда бесит
Maks
Есть вот такой интересный докладит, он с примерами на жс, но база ростет из хаскелся https://www.youtube.com/watch?v=H-cBhNMxlCw
Maks
и там как раз акцент на пограничные случаи
Михаил
все эти метрики не считают "до конца", считают в лоб, был код достигнут/вызван или нет
Я просто хочу некий инструмент который даст некоторое успокоение на код ревью. Вот написан верно код. Вот есть тест, вроде и покрывает всё. Но правильно ли этот тест написан? Короче хочется пай аналогичный проверки на cs. Если он прошёл, значит тест написан условно верно.
Maks
и тут мы пришли к кононичной проблеме, нужно ли писать тесты на тесты)))
« Rev
@symfony_ru   821
Fwd »