Форкнул и реанимировал одну клевую репу с кодом, который ходит в куб и проверяет поды на соотвествие праавилам, которые удобно пишутся в ямлях, если кто-то потыкает - я буду благодарен
https://github.com/count0ru/kube-lint

Годный твиттер тред про проблемы в распределенных систем: https://twitter.com/janl/status/1072442448893358081?s=20

Крутая ссылка от одного из читателей ;) https://sysadmincasts.com/ Много классных скринкастов и статей #screencast

Ещё один интересный репозиторий от ms - оператор, который позволяет писать policy для деплойментов и запрещать их запуск при несоответствии https://github.com/Azure/kubernetes-policy-controller/blob/master/README.md #policy #k8s

Вот сайт, там чуть вниз мотнешь рассказано как в 3 шага (2 из которых скачать и разъархивировать) поднять тестовый кластер all-in-one
https://www.okd.io/

https://github.com/vmware/kube-fluentd-operator
гениальное, правда немного недоделанное изобретение

Презентация от Julia Evans High Reliability Infrastructure Migrations и видео её выступления с Kubecon’18 в Сиэтле.

Бонусом: плейлист докладов c того же Kubecon

#slides #kubernetes

Как-то тихо прошли релиз и, собственно, интеграция в массы второй версии протокола Git https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html Если что, он уже доступен в Github, Gitlab и, скорее всего, других мейнстримовых git-хостилках. Для его использования нужно иметь поддержку его стороне как сервера, так и клиента (достаточно иметь свежую версию git и добавить в конфиг protocol.version 2). Как показали тесты, репочки реально клонятся быстрее

Теория шардирования⁠
🗂 Хранение данных, Высокая производительность, Анализ и проектирование систем, Блог компании Конференции Олега Бунина (Онтико)

Кажется, мы так глубоко погрузились в дебри highload-разработки, что просто не задумываемся о базовых проблемах. Взять, например, шардирование. Чего в нем разбираться, если в настройках базы данных можно написать условно shards = n, и все сделается само. Так-то, он так, но если, вернее когда, что-то пойдет не так, ресурсов начнет по-настоящему не хватать, хотелось бы понимать, в чем причина и как все починить.

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

Читать далее ➡ https://shbr.xyz/hh433370

Вот тут статья про то что nginx ingress имеет тоже свои подводные камни (а кто сомневался?) https://habr.com/company/southbridge/blog/340238/ #nginx #ingress

В блоге Lyft появилась статья о том как компания использует Apache Airflow в своей работе: https://eng.lyft.com/running-apache-airflow-at-lyft-6e53bb8fccff

KubiScan — недавно опубликованная утилита по анализу RBAC в Kubernetes http://amp.gs/EEWk Учитывая возраст репозитоия функционал пока-что ограничен, но идейно полезен для развития инструментов вэтом направлении.

В блоге компании-владельца уталиты, ееег автор также описал типовые проблемы и практики безопасной работы с RBAC http://amp.gs/EEWg

Как без даунтайма масштабировать базы данных в Яндекс.Облаке. Пример с тремя хостами
https://habr.com/company/yandex/blog/433814/

В рождественские праздники, обычно, ничего не происходит.

Однако, ловите предновогодний релиз HAProxy:

...the core improvements in 1.9, include Layer 7 retries, circuit breaking, gRPC, the new Data Plane API, and much more.

#haproxy

Очень крутую штуку ребята сделали конечно - https://github.com/spiral/roadrunner. Вдохнули в пхп проекты новую жизнь, так сказать. Больше деталей и описания здесь: https://habr.com/company/badoo/blog/434272/

​​Well, not only stuff for Kuber can shipped in fully silence

Meet Terraform Private Registry for AWS!

This Terraform module establishes a private registry for Terraform, allowing you to publish your own modules in a location you control independent of Terraform's public registry

#terraform #aws

Обрабатываем 10 000 RPS входящих сообщений на инфраструктуре за 60$ / month. Это самый желтушный заголовок, который я когда либо писал.
На самом деле в последнее время получаю много вопросов по поводу того что выбрать - kafka или rabbitmq для организации очереди сообщений. Чтобы снизить поток входящих, набросал статейку с очень простым субъективным мнением о том что и когда стоит использовать. В конце вы найдете полезные ссылки для более глубокого погружения.

Ах, да, чуть не забыл - вот ссылка на статью - https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b

В преддверии Нового года все любят загадывать на год следующий. Вот, например, DevOps Digest делится предположениями о 2019-ом в шести частях. С чем то я согласен, к чему-то есть вопросы, что-то и вовсе концептуально не совсем понятно:

Часть I. Общее:
- DevOps заходит к laggards adopters
- Это всё ещё будет считаться преимущественно Ops задачей
- Хайп вокруг NoOps сойдёт на нет
- Интеграция тулсета и появление бОльшего количества “DevOps” стартапов
- Фокус на бизнес-вэлью и сужение сфер деятельности

Часть II. Люди и культура:
- Общая ответственность и конец silos
- Фокус на разработчиках
- БОльшее проникновение DevOps as a Service
- Rise Of The Devops Engineer && Rise Of The Sre (прям название для фильма)

Часть III. Процесс разработки:
- OpenSource и коллаборация
- Стандартизация и, как следствие, уменьшение кодовой базы
- Новые фреймворки

Часть IV. Agile & CI/CD:
- Автоматизация, автоматизация, автоматизация
- Delivery станет настолько атомарным, что привычный release cycle может стать не релевантным
- Уменьшение количества разработчиков

Часть V. Тестирование:
- Автоматизация, автоматизация, автоматизация
- Смещение тестирование “влево”. Возможно даже начало написания тестов одновременно с началом дизайна фичи
- Мониторинг для тестирования

Часть VI. Аналитика и машинное обучение:
- Заход AI и ML в инфраструктурные задачи
- Уменьшения “угадывания” и улучшение прогнозов
- Измерение DevOps ROI
- DataOps