Я вот как-то писал про свою личную OPS практику - периодический рестарт программ в проде (https://tttttt.me/itpgchannel/370)

Вот, хороший текст, подтверждающий эффективность такого подхода:

https://pushtoprod.substack.com/p/netflix-terrifying-concurrency-bug

"We created a rule in our central monitoring and alerting system to randomly kill a few instances every 15 minutes. Every killed instance would be replaced with a healthy, fresh one"

И я, кстати, совершенно не кривил душой, говоря про это.

Вот, например, я периодически рестартую свои haproxy и ssh туннели для обхода блокировок (https://tttttt.me/itpgchannel/2262) в своей #lab #home_lab - https://github.com/pg83/lab/blob/master/lab/cg.py#L455-L457

https://matt.blwt.io/post/regular-restarts-are-good-actually/

TL;DR - еще один взгляд на тему "почему регулярные рестарты - хорошо".

Я написал очень длинный и очень интересный текст про Юникод. Поскольку в Telegram пост такого размера не помещается, выложил на сайт:

https://blo.gepar.do/v0/unicode.html

Все бегом читать :)

Я думаю, многие слышали кучу наставлений, что CPU limits в kubernetes не нужны. Началось это все со знаменитого поста Tim Hockin.
Но вот нюанс, с похожей ситуацией и я столкнулся, если ваше приложение ориентируется на cpuset cgroup, то придется делать под Guaranteed (нет, это нужно не только для static полиси).
Мораль такова: что не все, что большие мужи говорят - стоит принимать за истину.

Про переписывание истории

В баше (а точнее, в GNU Readline, который используется башом), есть довольно странная фича: историю команд можно редактировать!

Делается это так:
* нажимаем клавишу ↑, доматываем до команды, которую хотим отредактировать
* редактируем команду
* нажимаем клавишу ↓, доматываем до конца
* готово :)

Наглядную демонстрацию можно видеть на видео выше.

Я на эту «фичу» неумышленно натыкался много раз, и, сам того не зная, редактировал историю. А потом недоумевал, почему у меня при вызове history часть строк оказывались пустыми.

Как это отключить? Можно почитать, например, здесь. Если коротко, то надо в домашней папке создать файл с названием .inputrc и поместить в него такие строчки:

$include /etc/inputrc
set revert-all-at-newline on

https://abenezer.org/blog/hyrum-law-in-golang

"law" is simple:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

🔎 Смотрите какую красоту показали. Анализатор трафика, использующий под капотом eBPF - kyanos...

- Сайт: https://kyanos.pages.dev/
- Github: https://github.com/hengyoush/kyanos

Позволяет получить данные о сетевом взаимодействии конкретного процесса для http трафика, redis запросов и трафика сервера БД mysql.

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

#tui #kyanos #фидбечат

Еще про проклятые фичи баша

https://yossarian.net/til/post/some-surprising-code-execution-sources-in-bash

tl;dr: вот эта функция на баше при передаче «правильного» аргумента может привести к выполнению произвольного кода:

function guess() {
  num="${1}"
  if [[ "${num}" -eq 42 ]]
  then
    echo "Correct"
  else
    echo "Wrong"
  fi
}

Мораль проста: не пишите на баше не передавайте в bash-скрипты недоверенные данные

​Кажется в одном из выпусков про DWDM упоминалосья что не надо смотреть на оптические панели, не зная мощности сигналов в оптике, а то панель может посмотреть обратно на тебя.

Я в целом согласен с основной мыслью поста, за исключением слов должны. Это open source, тут никто никому ничего в общем случае не должен 🌝

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

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

Рынок должен начать смотреть на Kubernetes как на Linux Kernel. Что я имею в виду? В трезвом уме сисадмин маленькой или средней компании вряд ли станет говорить на работе, что не нужно использовать дистрибутив Linux — мол, сейчас он возьмет ядро и соберет свой дистрибутив. Так просто не принято: все понимают, что надо выбирать готовый дистрибутив, подходящий под конкретный набор задач. Да, есть и универсальные дистрибутивы, которые более-менее успешно могут использоваться под разные задачи, однако помимо дистрибутивов общего пользования (generic purpose), есть и куча специфических дистрибутивов вроде того же Talos Linux, Kali Linux, VyOS, DSL, SLAX, которые заточены под конкретные виды задач.
. . .
Многие ли инженеры четко и полноценно понимают, что там скрыто в недрах Linux Kernel, какие крутилки ядра применены в том или ином дистрибутиве Linux? А все потому, что рынок принял дистрибутив как некий эталон юнита с минимальной единицей бизнес-ценности, дробить эту абстракцию до уровня ядра или отдельных компонентов ядра просто нет смысла. Конечно, крупные компании собирают свои дистрибутивы — например, тот же Microsoft уже в новой технологической истории сделал Azure Linux. Однако большинству компаний это не нужно.

Тут возникает вопрос: а как поменять это мышление? Что для этого должно произойти? На мой взгляд, для полноценного запуска этого тектонического сдвига необходимы следующие процессы:

- Рабочие группы CNCF (TAG App Delivery, Technical Oversight Committee, а также мейнтейнеры и главные спонсоры Kubernetes) должны запустить дискуссии по этой теме. Обсудить перспективы и угрозы, в итоге выработав некую продуктовую стратегию. Потому что в итоге Kubernetes как продукт должен претерпеть достаточно серьезные изменения — одно дело, когда разрабатывается полноценное ПО и совсем другое, когда разрабатывается компонент, пусть и центральный. 

- TAG App Delivery, Technical Oversight Committee должны начать говорить с рынком и транслировать в него послание о том, что необходимо много платформ, чтобы были альтернативы. А также создать документы и технические условия (или инициировать формирование новой рабочей группы), позволяющие максимально упростить процесс создания платформы (собственно, Kubernetes как продукт должен сфокусироваться именно на том, что он становится центральным компонентом сторонней платформы).

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

- Крупные игроки различных рынков должны начать объединяться вокруг различных платформ или создавать новые, которые максимально соответствуют требованиям конкретного рынка и заточены под него.

- CNCF и другие open source-организации должны брать такие проекты под свое крыло и помогать им развиваться, а также выделять под продвижение такого подхода временные слоты на ключевых конференциях, которые они организуют (речь, например, о Kubecon).

Неизбежное будущее Kubernetes: почему оркестратор должен пойти по пути Linux Kernel
https://habr.com/ru/companies/aenix/articles/865238/

Канал автора @glina_nauchit

9 декабря 2024 года вышло расширение GitHub Skyline CLI для визуализации в ASCII достижений на платформе для разработки, а также экспорта этих данных для 3D-печати. Исходный код проекта GitHub Skyline (gh-skyline) написан на Go и опубликован под лицензией MIT.

#разработка

Мне это было сложно осознать, но Microsoft выпустили библиотеку для конвертации офисных файлов в маркдаун. То есть да, можно брать вордовый поток сознания и переводить в чистый, понятный, структурированный и внятный маркдаун без всех этих скачков форматирования и прочей чуши.
А можно не вордовский, а прям презентаху, и её тоже разложит в красивый вид. И прям парси её, анализируй её и вообще кайф.
https://github.com/microsoft/markitdown