Ну ладно. Есть же MVP, есть болезни роста и технический долг.
Если есть точная оценка, что вот эта часть функционала нам полезна, но существущий стек поддерживать дороже чем написать заново, то переписывание имеет место быть.
Иначе — планомерный плановый рефакторинг.
Все остальное — беды плохой оценки и планирования. Ну или по деньгам получается что и так сойдёт.
Лолчто?
Реляционная бд это не просто табличная система хранения данных, это ещё и, блин, реляции, связи между таблицами.
SQL это вообще не база данных, тем более не имеет никакого отношения к непосредственно реляциям.
Ну и все в этом духе.
Пожалуйста, изучите материал прежде чем учить других. Вы больше навредите.
Да я, в целом-то, неплохо понимаю, зачем нужен envoy, что такое service mesh, сайдкар и все такое.
Просто из статьи не очень понятно. Просто вот: логика nginx, вот так её можно реализовать в envoy. А зачем — неясно ))
Господи, сколько копий поломано.
Какая нафиг разница кто в каком праве.
Давайте проще.
Вас никто никогда не заставит что-то делать.
Не хочется — шлите нефиг такого работодателя с его заданиями.
И наоборот, интересно — делайте.
Ну никто никому ничего вообще в этом мире не должен. Ну что серьезно, получив на собесе задание и сказав, что вы не будете его делать потому что закон, вы рассчитываете, что компания скажет — ну да, так нельзя и возьмёт вас.
Или наоборот подаст на вас в суд, что вы недовыполнили задание собеседования?
Нет контракта — нет отношений. И ваша обоюдная, повторю обоюдная задача — друг другу понравиться.
И все.
Помните просто, что не только вас выбирают, но и вы выбираете.
Это очень частный случай получится, если весь наш паппет выложить)))
Может есть смысл просто рассказать чуть подоробнее про настройку взаимодействия хиеры и паппета, но мне кажется такие статьи тут уже были.
Вы сравниваете системы с абсолютно разным подходом.
В одних случаях хорош паппет, в других ансибл. И говорить что одно есть жалкое подобие другого по меньшей мере некорректно.
Я бы сказал, что обе системы не лишены недостатков, но и серебряной пули тоже нет.
В последнее время, ребята, кто на собеседование приходят, почему-то вообще уверены, что devops это программист, который умеет CI делать. Так что черт его знает на что сейчас тренд ;-)
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.
Да просто бывают админы, которые живут в каком-то своем идеальном мире. И любое начинание разработичка для них как штык к горлу (или другая крайность — пусть творят что хотят, мое дело апач передернуть).
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
Так может стоит быть более последовательным?
Во первых, снимать статистику по LA и IOwait.
Во вторых, снимать статистику по дискам из /proc/diskstats и/или iostat
В третьих, мониторить dmesg на ошибки.
И уже при возникновении проблем по этим метрикам проводить какие-то тесты, которые могут повлиять на измеряемые параметры и работу приложений.
Иначе можено дойти до того, что у вас вечь сервер будет покрыт тестами, но работать на нем будет невозможно.
И, кстати, никогда не забивайте разделы диска, сетевые интерфейсы и т.п. в мониторинг руками, пользуйтесь низкоуровневым обнаружением.
iowait может быть по множеству причин. Не факт, что винт там будет на первом месте. И не факт, что для всех 20% это правильный порог.
Вопрос в том, что синтетический тест чтения с диска — это для сферических коней в сжиженном вакууме может пригодится. Но автору виднее, может для него это важная метрика ))
Никто не мешает сделать так, например…
В конфиге заббикс агента: Include=/etc/zabbix/zabbix_agentd.conf.d/
Потом прописываете в puppet, например, в манифесте, который ставит nginx, чтоб он
положил в этот каталог файлик с необходимыми пользовательскими параметрами
в sites-enabled nginx положил конфиг сервера, который будет отдавать nginx_stats на 127.0.0.1
запустил скрипт, который через zabbix API добавит необходимый шаблон к вашему хосту
при необходимости — положил нужные скрипты, добавил в крон
перезапустил заббикс агент
После этого вся установка nginx вместе с мониторингом будет занимать ровно одну строчку в описании ноды.
21 век, какой пгпул...
Жыза.
Ну ладно. Есть же MVP, есть болезни роста и технический долг.
Если есть точная оценка, что вот эта часть функционала нам полезна, но существущий стек поддерживать дороже чем написать заново, то переписывание имеет место быть.
Иначе — планомерный плановый рефакторинг.
Все остальное — беды плохой оценки и планирования. Ну или по деньгам получается что и так сойдёт.
Лолчто?
Реляционная бд это не просто табличная система хранения данных, это ещё и, блин, реляции, связи между таблицами.
SQL это вообще не база данных, тем более не имеет никакого отношения к непосредственно реляциям.
Ну и все в этом духе.
Пожалуйста, изучите материал прежде чем учить других. Вы больше навредите.
Просто из статьи не очень понятно. Просто вот: логика nginx, вот так её можно реализовать в envoy. А зачем — неясно ))
Тут невзирая на средний перевод, неплохо раскрыт вопрос "как?"
Но, я вообще не понимаю пока "зачем?"
Господи, сколько копий поломано.
Какая нафиг разница кто в каком праве.
Давайте проще.
Вас никто никогда не заставит что-то делать.
Не хочется — шлите нефиг такого работодателя с его заданиями.
И наоборот, интересно — делайте.
Ну никто никому ничего вообще в этом мире не должен. Ну что серьезно, получив на собесе задание и сказав, что вы не будете его делать потому что закон, вы рассчитываете, что компания скажет — ну да, так нельзя и возьмёт вас.
Или наоборот подаст на вас в суд, что вы недовыполнили задание собеседования?
Нет контракта — нет отношений. И ваша обоюдная, повторю обоюдная задача — друг другу понравиться.
И все.
Помните просто, что не только вас выбирают, но и вы выбираете.
Спасибо, вот только послезавтра вылетаем туда.
Было полезно )
Это очень частный случай получится, если весь наш паппет выложить)))
Может есть смысл просто рассказать чуть подоробнее про настройку взаимодействия хиеры и паппета, но мне кажется такие статьи тут уже были.
Вы сравниваете системы с абсолютно разным подходом.
В одних случаях хорош паппет, в других ансибл. И говорить что одно есть жалкое подобие другого по меньшей мере некорректно.
Я бы сказал, что обе системы не лишены недостатков, но и серебряной пули тоже нет.
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
Во первых, снимать статистику по LA и IOwait.
Во вторых, снимать статистику по дискам из /proc/diskstats и/или iostat
В третьих, мониторить dmesg на ошибки.
И уже при возникновении проблем по этим метрикам проводить какие-то тесты, которые могут повлиять на измеряемые параметры и работу приложений.
Иначе можено дойти до того, что у вас вечь сервер будет покрыт тестами, но работать на нем будет невозможно.
И, кстати, никогда не забивайте разделы диска, сетевые интерфейсы и т.п. в мониторинг руками, пользуйтесь низкоуровневым обнаружением.
Вопрос в том, что синтетический тест чтения с диска — это для сферических коней в сжиженном вакууме может пригодится. Но автору виднее, может для него это важная метрика ))
В конфиге заббикс агента:
Include=/etc/zabbix/zabbix_agentd.conf.d/Потом прописываете в puppet, например, в манифесте, который ставит
nginx, чтоб онzabbix APIдобавит необходимый шаблон к вашему хостуПосле этого вся установка nginx вместе с мониторингом будет занимать ровно одну строчку в описании ноды.