Forwarded from Geeks (Shpak A.)
Распробовал на днях утилиту sq. Если jq - это инструмент для выборки и красивой визуализации данных из джейсонок, то sq - это все тоже самое (и даже чуть больше), но для баз данных. Выглядит прикольно, использовать (после jq) достаточно интуитивно, есть прикольные плюшки (например, просмотр диффа двух таблиц), умеет импортировать/экспортивароть данные. И, естественно, это опенсорсный проект. В общем, мне понравлось настолько, что не стыдно и вам показать https://sq.io/
sq
sq data wrangler
Forwarded from k8s (in)security (r0binak)
На просторах
Когда мы имеем дело с уязвимым
Примеры того как можно классифицировать такие инъекции и реальные примеры таких уязвимостей можно в репозитории.
Github
мы наткнулись на репозиторий KubernetesCRInjection. Он определенно будет полезен, если вы пишите свой Kubernetes controller
и хотите избежать возможных уязвимостей еще на стадии его проектирования.Когда мы имеем дело с уязвимым
Kubernetes controller
нужно понимать что, злоумышленники могут контролировать определенные пользовательские ресурсы и внедрять вредоносные полезные нагрузки, которые могут вызвать вредоносное поведение, когда контроллер анализирует, обрабатывает, хранит кастомные ресурсы или генерирует другие связанные ресурсы.Примеры того как можно классифицировать такие инъекции и реальные примеры таких уязвимостей можно в репозитории.
GitHub
GitHub - Esonhugh/KubernetesCRInjection: Here is a common vulnerability when Kubernetes Controller designed.
Here is a common vulnerability when Kubernetes Controller designed. - Esonhugh/KubernetesCRInjection
Forwarded from DOFH - DevOps from hell
Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза для k8s
https://habr.com/ru/articles/852536/
Спойлер:
https://habr.com/ru/articles/852536/
Спойлер:
iommu.strict=0
Хабр
Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза
Предыстория Недавно я начал готовить очередной Kubernetes кластер на Bare Metal серверах для одного из наших проектов дабы съехать с Google Cloud и снизить расходы на инфраструктуру примерно в 4 раза,...
Forwarded from Мемный Болт Генона
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from linkmeup
This media is not supported in your browser
VIEW IN TELEGRAM
Шикарный пример пряморукой визуализации. Товарищ наглядно изобразил, как устроены задержки при межсерверной коммуникации внутри и между зонами доступности на примере амазоновского us-east-2 датика.
Цель проекта? Да пёс его знает. Красиво и наглядно показывает, что коммуникация внутри AZ всегда быстрее, даже если все машины физически в одном месте.
https://benjdd.com/az/
Циферки брал вот так: https://www.bitsand.cloud/posts/cross-az-latencies
Цель проекта? Да пёс его знает. Красиво и наглядно показывает, что коммуникация внутри AZ всегда быстрее, даже если все машины физически в одном месте.
https://benjdd.com/az/
Циферки брал вот так: https://www.bitsand.cloud/posts/cross-az-latencies
Forwarded from commit -m "better"
Я вот как-то писал про свою личную 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://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
Telegram
commit -m "better"
https://keunwoo.com/notes/rebooting/ #reboot
Хороший, только очень длинный текст, в котором написаны 2 простых мысли:
* В любой системе нарастает энтропия. По другому - в системе есть https://ru.wikipedia.org/wiki/Гейзенбаг.
* Перезагрузка(VM, хоста, программы)…
Хороший, только очень длинный текст, в котором написаны 2 простых мысли:
* В любой системе нарастает энтропия. По другому - в системе есть https://ru.wikipedia.org/wiki/Гейзенбаг.
* Перезагрузка(VM, хоста, программы)…
Forwarded from commit -m "better"
rxd_txd
Я вот как-то писал про свою личную OPS практику - периодический рестарт программ в проде (https://tttttt.me/itpgchannel/370) Вот, хороший текст, подтверждающий эффективность такого подхода: https://pushtoprod.substack.com/p/netflix-terrifying-concurrency-bug…
https://matt.blwt.io/post/regular-restarts-are-good-actually/
TL;DR - еще один взгляд на тему "почему регулярные рестарты - хорошо".
TL;DR - еще один взгляд на тему "почему регулярные рестарты - хорошо".
Matt Blewitt
Regular Restarts Are Good, Actually
A much maligned feature has hidden benefits.
Forwarded from Гепардово гнездо
Я написал очень длинный и очень интересный текст про Юникод. Поскольку в Telegram пост такого размера не помещается, выложил на сайт:
https://blo.gepar.do/v0/unicode.html
Все бегом читать :)
https://blo.gepar.do/v0/unicode.html
Все бегом читать :)
Forwarded from Кубернетичек
Я думаю, многие слышали кучу наставлений, что CPU limits в kubernetes не нужны. Началось это все со знаменитого поста Tim Hockin.
Но вот нюанс, с похожей ситуацией и я столкнулся, если ваше приложение ориентируется на cpuset cgroup, то придется делать под Guaranteed (нет, это нужно не только для static полиси).
Мораль такова: что не все, что большие мужи говорят - стоит принимать за истину.
Но вот нюанс, с похожей ситуацией и я столкнулся, если ваше приложение ориентируется на cpuset cgroup, то придется делать под Guaranteed (нет, это нужно не только для static полиси).
Мораль такова: что не все, что большие мужи говорят - стоит принимать за истину.
GitHub
processes from /system.slice using cores assigned to guaranteed Pods when --cpu-manager-policy=static is set · Issue #85764 · …
What happened: Following is the configuration for kubelet to enable the --cpu-manager-policy=static feature. --cpu-manager-policy=static --system-reserved=cpu=10,memory=10Gi --system-reserved-cgrou...
Forwarded from Кадровый Болт Генона
Мой хороший знакомый Лев Гончаров (@ultralisc) недавно выложил у себя в блоге Devops Roadmap
https://www.goncharov.xyz/it/devops-roadmap.html
Там есть информация о том, что почитать, что посмотреть, с каких курсов начать. Так же есть разбивка материалов по направлениям в виде операционных систем, сетей, docker, CI/CD и т.д.
У Льва много статей и докладов, как на английском языке
https://github.com/ultral/ultral.github.io
так и на русском языке
https://github.com/ultral/ultral.github.io/blob/master/README-ru.md
Собственно, пост Devops Roadmap родился как раз из одного внутреннего доклада в T-Systems.
Всем интересующимся рекомендую ознакомиться.
https://www.goncharov.xyz/it/devops-roadmap.html
Там есть информация о том, что почитать, что посмотреть, с каких курсов начать. Так же есть разбивка материалов по направлениям в виде операционных систем, сетей, docker, CI/CD и т.д.
У Льва много статей и докладов, как на английском языке
https://github.com/ultral/ultral.github.io
так и на русском языке
https://github.com/ultral/ultral.github.io/blob/master/README-ru.md
Собственно, пост Devops Roadmap родился как раз из одного внутреннего доклада в T-Systems.
Всем интересующимся рекомендую ознакомиться.