хорошая статья о том как поэксперементировать с OPA gatekeeper (политики для кубера) при помощи kind (kubernetes in docker) https://medium.com/@LachlanEvenson/verifying-container-signatures-on-kubernetes-with-gatekeeper-19a4519c3016

https://aws.amazon.com/blogs/aws/new-amazon-ec2-m6a-instances-powered-by-3rd-gen-amd-epyc-processors/

уууу, новые инстансы амазона обещают быть на 35% более производительными.

неделя AWS. Тут ещё кафка серверлесс. Я сначала обрадовался, а потом цены посмотрел и загрустил. https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-msk-serverless-public-preview/

ну штож, а вот и новый автоскейлер. https://karpenter.sh/

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

Внезапно - релиз plumber 1.0, моей любимой утилиты для работы с Кафкой и другими очередями✌️✌️

https://github.com/batchcorp/plumber

А мы тут делаем список кресел для сидения что б спина не болела. Пишите свои в комментарии или сразу делайте PR https://github.com/ukrops/newbie/blob/master/README.md

ууууууууу, то чего так ждали большевики свершилось.
Теперь теги инстанса можно забирать из амазона прямо из метадаты, не навешивая какой-либо роли.
А это значит, это значит что можно в теги складывать какую-то фигню, например пути или ещё какой-то service-discovery шлак.

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

https://aws.amazon.com/about-aws/whats-new/2022/01/instance-tags-amazon-ec2-instance-metadata-service/

Меня вообще поражает как часто люди и компании героически преодолевают проблемы которые сами себе и создают. Roblox - сервис которым пользуется 50 миллионнов человек упал на три дня.

Они выпустили неплохой постмортем, в котором рассказали о причинах и последствиях. https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/

Правда судя по выводам они не поняли, что проблема не техническая, а архитектурная.

Что случилось?

Вкратце — у них упал консул после обновления на проде. Из-за чего упал сервисдискавери, номад не смог поднимать новые поды и vault отказался работать тоже.

Почему это архитектурная проблема?

Потому что если у вас всё завязано на один сервис, то когда он упадёт, то всё перестанет работать.
Если вы используете консул и как service discovery, и как БД для номада, и как БД для vault и как просто KV store, то ну у вас всё упадёт если упадёт consul.

А если у вас много ролей для одного кластера, то упасть он может не только из-за обновления но и из-за того что

* vault начал больше писать-читать
* номад начал больше писать-читать
* сервисы начали больше писать-читать


Я иногда слышал доводы от сторонников всё писать в одно место, мол якобы так проще инфраструктура. Но простая инфраструктура ≠ меньше компонент. Было бы у них просто по одному кластеру на каждую задачу — проблема бы не затронула всю компанию. Хотя да, это было бы аж на +20 строчек кода тераформа больше и невероятно сильно усложнило бы инфраструктуру.

Вторая проблема тоже 100500 лет как известна — кешируйте сервис дискавери.

DNS не зря имеет ту архитектуру которую имеет. Там люди думали и сделали ну неплохо. Но окей, у DNS свои проблемы. Но и гугл, и нетфликс так или иначе решили сервис дискавери через локальное кеширование. Их инженеры с докладами по всему миру проехались и рассказали как они решали такие проблема. И я помню как ещё 8 лет назад уже заранее закладывал локальное кеширование в план.
Ведь пусть лучше сервис сходит на часть старых нод какое-то время, чем вообще не будет знать куда идти.

Третяя ошибка — если ваш сервис пользует несколько миллионов человек и они приносят деньги — почему бы не иметь несколько прод кластеров слабо связанных друг с другом (если это возможно — а судя по выводам которые они сделали — это возможно)
Несколько разных прод окружений удобны ещё и тем что и выкатывать обновления можно только на часть прод пользователей. И если упадёт — ну что-то работать не будет, но что-то будет. А если что-то может упасть, то оно упадёт, датацентр сгорит и так далее. Почему бы не подготовиться и не почитать Талеба.


И проблема даже не в том, что кто-то не подумал заранее. Мне не нравится что в выводах никто в Roblox не подумал — а может у нас плохая архитектура? Может надо что-то изменить на более высоком уровне?

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

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

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

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

Требовать от джуна чтоб он искал в интернете до того как прийдёт к вам с вопросом значит расходовать ресурсы в воздух (потому что джун будет искать непонятно что непонятно как) и калечить психику человека (потому что каждый джун - из тех что я нанимал - гиперответственный трудоголик, с огромным синдромом самозванца, которому только дай повод считать себя говном)

Джунов надо поддерживать, надо приучать задавать вопросы, а если вопрос не правильный (очень часто) — учить задавать вопросы. И учитывая что даже мидлы-синиоры не умеют задавать правильные вопросы — джуны не умеют этого и подавно.

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

И пока я писал этот текст, я понял что он хорошо подходит не только к джунам, но вообще к воспитанию. Чтобы человек умел учиться надо не только требовать, но и учить учиться. В первую очередь учить учиться. Учить задавать правильные вопросы, смотреть в глубь вещей и проблем, не бояться ошибаться, брать на себя ответственность (под невидимым(!) присмотром кста), учить побеждать и наслаждаться победой. Люди без опыта это люди без опыта, это чистые листы. И то чем они будут заполнены — великая ответственность заполняющего о которой нельзя забывать.

а ребята из HUG Kyiv делают Q&A с хашимото (основатель хашикорпа) прямо сейчас. Присоеденяйтесь https://www.youtube.com/watch?v=GCvhy4I2bzU

Дебаггер в IDEA — одна из главных причин почему я сижу на IDEA, а не в emacs, который и легче, и быстрее, лучше настраивается и зачастую удобнее.

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

Ещё классная штука — условия для брекпоинтов. В IDEA можно как поставить условие, мол останови если переменная в этом брекпоинте будет иметь такое-то значение. Но ещё удобнее условие - останови если какой-то из брекпоинтов был пройден.

Например, у меня есть два теста и я хочу пропускать первый и смотреть только второй. Для этого я ставлю на втором тесте брекпоинт, щелкаю на нём правой клавишей мыши и убираю “suspend” - то есть он будет проходить, но не будет останавливаться.

Теперь я могу поставить второй брекпоинт в коде, щелкнуть на нем правой клавишей, перейти в “more” и выбрать предыдущий брекпоинт в меню “disable untill hitting the folowing…”

В итоге первый тест пройдёт без остановок, а IDEA запустит окно дебаггера только на втором тесте.

В дебагере ещё много чего полезного есть. Если интересно, могу ещё какие-то полезняшки написать.

А я вот разбираюсь с terraform cloud.

Куча классных и полезных фич. Например sensetive секреты и запрет на доступ к стейту (с разрешением читать outputs). Интеграция с VCS из коробки. Быстро работает.

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

Самое странное что это базовейший сценарий, который сами терраформы рекомендуют как best practice. Я б понял если бы я там странного чего-то хотел бы. Но это ж база.

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

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

https://github.com/hashicorp/terraform-provider-tfe/issues/435

Всем привет. Делаю небольшой стрим на часик-полтора-два. Разбираюсь с Rust, буду делать лямбду пока не знаю для чего, наверное для слака. Впрочем, по опыту будем больше болтать.
Косо, криворуко, поднимет самооценку.
https://www.twitch.tv/darkctrlok

Совет дня #1:

Если у вас есть какие-то изменения в репозитории, а вам надо перейти на “чистую” ветку или какой-то коммит — используйте git stash.

Этот набор команд позволяет быстренько запаковать изменения и вернуться к ним позже без создания отдельной бранчи и коммитов.

Примеры можно посмотреть через tldr git stash

Совет дня #2:
Установите tldr или (лучше) tealdeer

P.S. как вам рубрика совет дня? Продолжать?

Совет дня — не поленитесь и освойте autojump или аналоги

Коротко — штука запоминает куда вы ходили (в смысле cd) и позволяет по части имени переходить в этот каталог.

Я пользуюсь zoxide - быстрый, написан на раст, поддерживает fuzzy search (через fzf), хорошо проставляет ранк (каталоги в которых бываете чаще — выше в выдаче)

Мой конфиг для fish:

zoxide init fish --cmd cd | source
export _ZO_FZF_OPTS="--no-sort --keep-right --info=inline --layout=reverse --height=30% --exit-0 --select-1 --preview-window=right,15% --preview='ls -p {2..}'"

для zsh надо будет заменить init fish на init zsh

И совет дня от Антона из https://news.1rj.ru/str/devops_easy

>> бесплатная альтернатива ngrok. Бывает иногда выручает в разных ситуациях https://loophole.cloud/


в кратце, эта фиготень позволяет выставлять наружу что-то локальное с ноута.
Я loophole еще не пользовался, зато ngrok много раз выручал когда надо было разрабатывать апишки для взаимодействия с внешними вебхуками.

Например, когда писал слакбот — выставил наружу апишку с локальной машины и получал запросы от слака прямо на ноут. Это НАМНОГО проще и удобнее чем куда-то деплоить что-то каждый раз.

Целый день рекрутеры не спамят в линкедин, позитив 🙂