Да, certbot renew в теории должен обновлять их, но сайты живые, постоянно разрабатываются, причем разными людьми и с ними иногда происходят разные чудеса. То поменяется DocumentRoot, то появятся правила rewrite/redirect, которые блокируют проверку, то доменное имя куда-то уедет... В общем, обновления иногда фейлятся и сертификаты протухают. А когда сайтов много, что-то проблемное случается регулярно.
Ааа. Вот в чем проблема. Ну pip install в вашей жизни ничего не решит толком. Надо исправлять саму возможность возникновения подобных проблем, а не отказываться от certbot renew.
Просто добавить в bashrc. Если уж написали эту строчку, то сделать ее переиспользуемой не сложно.
Атеперь, представьте, что мы хотим не просто увидеть дату, а еще и как-то что-то сделать, если до истечения останется меньше 20 дней... как будет выглядеть команда?
Зачем это делать через какие-либо скрипты? Если вы используете LE, то у вас должна в кроне стоять задача на замену сертификата, как это рекомендуется создателями этой системы. И там все за вас уже сделано.
Ну и должен быть мониторинг, а любой мониторинг умеет в проверку сертификатов.
Т.е. showcert без сомнения хорошая, удобная вещица для ad-hoc проверок. Но при чем здесь shell, флот и триггер скриптов мне не понятно.
У нас компания в джунах и стажерах обычно заинтересована. Я лично нанял или собеседовал с успехом 4 стажеров, два по-прежнему с нами, два в хороших компаниях заграницей. Найм же джунов и около джунов с прицелом на рост для меня обычная история. Плюс служба саппорта, которая студентов коллекционирует (удобный, хотя иногда тупиковый вариант для начала карьеры).
Обычно обращаю внимание на системное мышление, интерес к IT и интерес к вакансии. А вопросы задаю по резюме, не ожидая, что человек знает сходу то, что мне нужно, но подразумевая, что он готов отвечать за знания, которые заявил.
Но вот еще не разу я не взял "вайтишника". Выдел у людей курсы в резюме, но все они отзывались о них плохо, говоря, что просто делая что-то на коленке для себя или универа или в open source они получали больше знаний.
Имхо грейды имеют смысл только в большой и очень богатой компании, когда они привязаны как к существенным материальным ценностям, так и к положению в сложной, большой иерархии.
Для компании меньше 500 человек, да еще и склонной кроить каждую копейку это не имеет смысла.
Монолит также может быть горизонтально отмасштабирован с load balancer-ом и high availability.
Обычно это сложнее. Когда говорят, что микросервисы могут легко масштабироваться, разумеется имеют ввиду, что хорошо масштабируются сервисы без состояния. Все, что имеет состояние вызывает проблемы. Ну и монолит этой проблеме подвержен также.
Вторая проблема это неравномерное масштабирование. В больших комплексах часто надо масштабировать конкретную функцию, а не весь объем кода. Размножать весь монолит, ради одной функции нелепо. И тут мы приходим к давней идее аппликейшен серверов, RPC, DI, resource pooling и прочего. Называется по-другому, но в общем-то это тоже микросервисы и контейнеры, только без k8s и https everywhere.
ИМХО, Java хорошо переживает тысячи разрабов в одной репе благодаря всей этой сложившейся культуре с иерархией архитектор-->team lead --> senior --> middle --> junior.
Плюс там паттерны заточены под переиспользование кода с минимальными последствиями.
У кого сотня микросервисов, как вы живете, страдаете?
Микросервисы это не столько архитектурная, сколько организационная проблема.
Нужна команда SRE. Программистам хода на продакшен нет. Никогда.
Нужен хороший CI/CD
Нужна строгость в сборке и деплойменте: -snapshot.jar недопустим (он так-то никогда недопустим, но кого это останавливает)
Как можно больше статических проверок контрактов. Как раз в Java c этим прекрасно (хотя я не Java прогер, могу ошибаться)
Как можно больше асинхрона для уменьшения связности.
SDET и QA Automation.
При выполнении этих и еще ряда условий (в том числе архитектурных) масштабируемость резко возрастает и увеличивается независимость команд. Хотя и не ясно нужно ли это конкретно вам.
Есть мифы, частично упомянутые в статье:
Сервис дискавери это сложнА! - Нет, не сложно, поскольку там очень шаблонированный код, особенно в наше время. Да и в большинстве случаев все ограничивается k8s и terraform и не доходит до Consul и Zookeeper
Мониторинг сложнее чем в монолите - Нет, не сложнее. Если не делать архитектурных глупостей, то мониторинг можно шаблонировать и выйдет примерно как с монолитом. А еще раскурить ELK и OpenTelementry. Ну и главная проблема мониторинга едина для всех подходов: необходимо каждый параметр описать и определить диапазоны, а на это уходит дикое количество времени.
Деплоймент это сложнА! - Для программистов да, хотя не то чтобы сложно, а непривычно и ненужно. Но для этого есть отдельные специалисты: SRE, DevOPS, QA
Имхо, с микросервисами есть одна ловушка: когда компания готова к микросервисам, разработка монолита для нее бессмысленна, но вы можете ошибаться, думая, что вы к этому готовы.
Все дело в том как конкретно применяют Swagger. В библиотеках на Python принята идеология "code first", когда схема генерируется по уже готовому API (например Django DRF) и тогда возникает куча проблем с несовместимой схемой, на это забивают и в конечном счете от сваггера не остается ничего.
Если же использовать логику "schema first", то выясняется, что прям хороших генераторов сервера для Python нет. А то что есть не дотягивает до уровня Fast API, например.
В других языках schema first может лучше работать, а может и хуже.
Что меня радует в MS, так это традиции: каждая вторая версия должна быть неудачной. Тут похоже та же история. И дело не в том, что чего-то там еще не сделано, а просто в дикой популярности предыдущей версии (10ой), которая не позволит взлететь сырым инновациям 11ой.
Да, про эту штуку я уже читал, но меня она немного подбешивает. Мне не нравится, что в python втащили синтаксис bash, перегрузив привычные операторы (если я правильно понял как оно устроено).
Т.е. синтаксис как бы разваливается на две части: обычный питон, и питон с магией.
Я бы предпочел более привычную для python историю. Что-то типа
Ну в мире много интересных систем, которые не стали распространнеными. И не смотря на то, что TCL хорош, но по распространенности до bash и python ему невероятно далеко.
В целом согласен, но это скорее потому, что юникс сделан под плеин текст. Если бы это было не так, то баш был бы другим. Думаю он был бы похож на powershell.
К слову, в aix был бинарный реестр, древовидный. Но к нему шли довольно развитые консольные утилиты, что позволяло оперировать значениями и ветками из шела.
Ааа. Вот в чем проблема. Ну pip install в вашей жизни ничего не решит толком. Надо исправлять саму возможность возникновения подобных проблем, а не отказываться от certbot renew.
Просто добавить в bashrc. Если уж написали эту строчку, то сделать ее переиспользуемой не сложно.
Зачем это делать через какие-либо скрипты? Если вы используете LE, то у вас должна в кроне стоять задача на замену сертификата, как это рекомендуется создателями этой системы. И там все за вас уже сделано.
Ну и должен быть мониторинг, а любой мониторинг умеет в проверку сертификатов.
Т.е. showcert без сомнения хорошая, удобная вещица для ad-hoc проверок. Но при чем здесь shell, флот и триггер скриптов мне не понятно.
У нас компания в джунах и стажерах обычно заинтересована. Я лично нанял или собеседовал с успехом 4 стажеров, два по-прежнему с нами, два в хороших компаниях заграницей. Найм же джунов и около джунов с прицелом на рост для меня обычная история. Плюс служба саппорта, которая студентов коллекционирует (удобный, хотя иногда тупиковый вариант для начала карьеры).
Обычно обращаю внимание на системное мышление, интерес к IT и интерес к вакансии. А вопросы задаю по резюме, не ожидая, что человек знает сходу то, что мне нужно, но подразумевая, что он готов отвечать за знания, которые заявил.
Но вот еще не разу я не взял "вайтишника". Выдел у людей курсы в резюме, но все они отзывались о них плохо, говоря, что просто делая что-то на коленке для себя или универа или в open source они получали больше знаний.
Имхо грейды имеют смысл только в большой и очень богатой компании, когда они привязаны как к существенным материальным ценностям, так и к положению в сложной, большой иерархии.
Для компании меньше 500 человек, да еще и склонной кроить каждую копейку это не имеет смысла.
Обычно это сложнее. Когда говорят, что микросервисы могут легко масштабироваться, разумеется имеют ввиду, что хорошо масштабируются сервисы без состояния. Все, что имеет состояние вызывает проблемы. Ну и монолит этой проблеме подвержен также.
Вторая проблема это неравномерное масштабирование. В больших комплексах часто надо масштабировать конкретную функцию, а не весь объем кода. Размножать весь монолит, ради одной функции нелепо. И тут мы приходим к давней идее аппликейшен серверов, RPC, DI, resource pooling и прочего. Называется по-другому, но в общем-то это тоже микросервисы и контейнеры, только без k8s и https everywhere.
Можно эти свойства переложить на отдельные сервисы, например добавив MQ, или сделав связку MQ+ServerLess.
ИМХО, Java хорошо переживает тысячи разрабов в одной репе благодаря всей этой сложившейся культуре с иерархией архитектор-->team lead --> senior --> middle --> junior.
Плюс там паттерны заточены под переиспользование кода с минимальными последствиями.
Хотя усилий требуется не мало, конечно.
Микросервисы это не столько архитектурная, сколько организационная проблема.
Нужна команда SRE. Программистам хода на продакшен нет. Никогда.
Нужен хороший CI/CD
Нужна строгость в сборке и деплойменте: -snapshot.jar недопустим (он так-то никогда недопустим, но кого это останавливает)
Как можно больше статических проверок контрактов. Как раз в Java c этим прекрасно (хотя я не Java прогер, могу ошибаться)
Как можно больше асинхрона для уменьшения связности.
SDET и QA Automation.
При выполнении этих и еще ряда условий (в том числе архитектурных) масштабируемость резко возрастает и увеличивается независимость команд. Хотя и не ясно нужно ли это конкретно вам.
Есть мифы, частично упомянутые в статье:
Сервис дискавери это сложнА! - Нет, не сложно, поскольку там очень шаблонированный код, особенно в наше время. Да и в большинстве случаев все ограничивается k8s и terraform и не доходит до Consul и Zookeeper
Мониторинг сложнее чем в монолите - Нет, не сложнее. Если не делать архитектурных глупостей, то мониторинг можно шаблонировать и выйдет примерно как с монолитом. А еще раскурить ELK и OpenTelementry. Ну и главная проблема мониторинга едина для всех подходов: необходимо каждый параметр описать и определить диапазоны, а на это уходит дикое количество времени.
Деплоймент это сложнА! - Для программистов да, хотя не то чтобы сложно, а непривычно и ненужно. Но для этого есть отдельные специалисты: SRE, DevOPS, QA
Имхо, с микросервисами есть одна ловушка: когда компания готова к микросервисам, разработка монолита для нее бессмысленна, но вы можете ошибаться, думая, что вы к этому готовы.
Все дело в том как конкретно применяют Swagger. В библиотеках на Python принята идеология "code first", когда схема генерируется по уже готовому API (например Django DRF) и тогда возникает куча проблем с несовместимой схемой, на это забивают и в конечном счете от сваггера не остается ничего.
Если же использовать логику "schema first", то выясняется, что прям хороших генераторов сервера для Python нет. А то что есть не дотягивает до уровня Fast API, например.
В других языках schema first может лучше работать, а может и хуже.
А что это за "профильный" чат. Он тайный, или туда можно попасть?
По моим ощущениям этой истории уже много лет (10-15) и это банальная калька с английского, где слово expertise может использоваться в этом значении.
https://dictionary.cambridge.org/dictionary/english/expertise
Что меня радует в MS, так это традиции: каждая вторая версия должна быть неудачной. Тут похоже та же история. И дело не в том, что чего-то там еще не сделано, а просто в дикой популярности предыдущей версии (10ой), которая не позволит взлететь сырым инновациям 11ой.
Ждем 12ю?
Как бы потом, смотря на скрипт в 10к строк не пришлось за стаканы браться.
Да, про эту штуку я уже читал, но меня она немного подбешивает. Мне не нравится, что в python втащили синтаксис bash, перегрузив привычные операторы (если я правильно понял как оно устроено).
Т.е. синтаксис как бы разваливается на две части: обычный питон, и питон с магией.
Я бы предпочел более привычную для python историю. Что-то типа
И да, такое можно сделать и даже вроде как не сложно, но сила привычки велика.
Ну в мире много интересных систем, которые не стали распространнеными. И не смотря на то, что TCL хорош, но по распространенности до bash и python ему невероятно далеко.
В целом согласен, но это скорее потому, что юникс сделан под плеин текст. Если бы это было не так, то баш был бы другим. Думаю он был бы похож на powershell.
К слову, в aix был бинарный реестр, древовидный. Но к нему шли довольно развитые консольные утилиты, что позволяло оперировать значениями и ветками из шела.
По сравнению с sh, python слишком низкоуровневый. Т.е. код, эквивалентный вот такому:
Займет довольно много строчек, даже применяя все батарейки.
Другой вопрос, что именно бизнеслогику выражать на sh это немного кощунство из-за примитивных структур данных и плохого переиспользования кода.
Надеюсь вы вкурсе, что if/then/else и a && b || c не эквивалентны?
Высыпаешь. т9 подвёл
Ну это же не кубик Рубика. Тупо высылаешь фишки, мешаешь и по одной кладешь, а дальше 50/50.