Pull to refresh
3
0
Антон Чевычалов @acmnu

Пользователь

Send message

$ echo | openssl s_client -connect mx.yandex.ru:25 -starttls smtp 2>&1 | openssl x509 -noout -dates

function showcert(){
    echo | openssl s_client -connect ${1} -starttls smtp 2>&1 | openssl x509 -noout -dates
}

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

Атеперь, представьте, что мы хотим не просто увидеть дату, а еще и как-то что-то сделать, если до истечения останется меньше 20 дней... как будет выглядеть команда?

Зачем это делать через какие-либо скрипты? Если вы используете LE, то у вас должна в кроне стоять задача на замену сертификата, как это рекомендуется создателями этой системы. И там все за вас уже сделано.

Ну и должен быть мониторинг, а любой мониторинг умеет в проверку сертификатов.

Т.е. showcert без сомнения хорошая, удобная вещица для ad-hoc проверок. Но при чем здесь shell, флот и триггер скриптов мне не понятно.

У нас компания в джунах и стажерах обычно заинтересована. Я лично нанял или собеседовал с успехом 4 стажеров, два по-прежнему с нами, два в хороших компаниях заграницей. Найм же джунов и около джунов с прицелом на рост для меня обычная история. Плюс служба саппорта, которая студентов коллекционирует (удобный, хотя иногда тупиковый вариант для начала карьеры).

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

Но вот еще не разу я не взял "вайтишника". Выдел у людей курсы в резюме, но все они отзывались о них плохо, говоря, что просто делая что-то на коленке для себя или универа или в open source они получали больше знаний.

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

Для компании меньше 500 человек, да еще и склонной кроить каждую копейку это не имеет смысла.

Монолит также может быть горизонтально отмасштабирован с load balancer-ом и high availability.

Обычно это сложнее. Когда говорят, что микросервисы могут легко масштабироваться, разумеется имеют ввиду, что хорошо масштабируются сервисы без состояния. Все, что имеет состояние вызывает проблемы. Ну и монолит этой проблеме подвержен также.

Вторая проблема это неравномерное масштабирование. В больших комплексах часто надо масштабировать конкретную функцию, а не весь объем кода. Размножать весь монолит, ради одной функции нелепо. И тут мы приходим к давней идее аппликейшен серверов, 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 может использоваться в этом значении.

I've been in this job for 30 years, and I've picked up a good deal of expertise along the way.

https://dictionary.cambridge.org/dictionary/english/expertise

Что меня радует в MS, так это традиции: каждая вторая версия должна быть неудачной. Тут похоже та же история. И дело не в том, что чего-то там еще не сделано, а просто в дикой популярности предыдущей версии (10ой), которая не позволит взлететь сырым инновациям 11ой.

Ждем 12ю?

Как бы потом, смотря на скрипт в 10к строк не пришлось за стаканы браться.

Да, про эту штуку я уже читал, но меня она немного подбешивает. Мне не нравится, что в python втащили синтаксис bash, перегрузив привычные операторы (если я правильно понял как оно устроено).

Т.е. синтаксис как бы разваливается на две части: обычный питон, и питон с магией.

Я бы предпочел более привычную для python историю. Что-то типа

zcat("access.log.2.gz").awk('$6 == "\"GET" {print $1}').sort(uniq=true, number=true)

И да, такое можно сделать и даже вроде как не сложно, но сила привычки велика.

Ну в мире много интересных систем, которые не стали распространнеными. И не смотря на то, что TCL хорош, но по распространенности до bash и python ему невероятно далеко.

В целом согласен, но это скорее потому, что юникс сделан под плеин текст. Если бы это было не так, то баш был бы другим. Думаю он был бы похож на powershell.

К слову, в aix был бинарный реестр, древовидный. Но к нему шли довольно развитые консольные утилиты, что позволяло оперировать значениями и ветками из шела.

По сравнению с sh, python слишком низкоуровневый. Т.е. код, эквивалентный вот такому:

 zcat /var/log/nginx/access.log.2.gz | awk '$6 == "\"GET" {print $1}' | sort -un

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

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

shortcircuting - вместо кучи if/else использовать || или && и сразу выходить с сообщением.

Надеюсь вы вкурсе, что if/then/else и a && b || c не эквивалентны?

Высыпаешь. т9 подвёл

Ну это же не кубик Рубика. Тупо высылаешь фишки, мешаешь и по одной кладешь, а дальше 50/50.

Хм. Нет. Это же известная история. Автор головоломки даже обещал большие деньги тому, кто найдет алгоритм.

Information

Rating
Does not participate
Registered
Activity

Specialization

DevOps, Chief information officer (CIO)
Lead