В блоге 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

15 Useful Helm Charts Tools

15 полезных утилит для работы с Helm.

https://caylent.com/15-useful-helm-charts-tools

В ВК зарегистрировано полмиллиарда пользователей, а среднесуточная аудитория около 100 млн. Чтобы держать такую нагрузку нужна крепкая архитектура и десятки тысяч серверов. Как организовано взаимодействие между ними, как происходит мониторинг и как решают проблему постоянно ломающихся серверов рассказал Алексей Акулович на HighLoad++ в докладе FAQ по архитектуре и работе ВКонтакте, а Ник Волынкин аккуратно записал в конспект.

https://github.com/NickVolynkin/highload-2018/blob/master/2.1-vk-architecture.md

Считанные часы остались до Нового года, настало время поговорить об итогах и планах.

Важный итог - мы с Ontico (Конференции Олега Бунина, организаторы знаменитой конференции Highload++) запустили работу над первой в России конференции про управление знаниями в IT компаниях и командах KnowledgeConf 2019. Она пройдет в Москве в апреле 2019 года. Этот пост - неофициальный старт подачи заявок, этакий тизер, детали и подробности будут впереди.

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

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

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

Создали уникальную и крутую на ваш взгляд систему адаптации новичков в компании? А может придумали свой подход к хранению и индексации информации в базе знаний? Изучили современные подходы к обучению и полностью пересмотрели систему передачи знаний в компании? Отказались от документации совсем? Расскажите об этом!

Захотелось выступить? Ссылка на подачу заявки тут.

У нас следующие секции:

- Вовлечение сотрудников в процесс knowledge sharing, создание культуры непрерывного обмена знаниями и опытом в IT-командах и компаниях.
- Оценка эффективности управления знаниями и бизнес-результат.
- Современные технологии и методы обучения.
- Практические кейсы и результаты организации управления знаниями в компаниях: онбординг новичков, организация базы знаний, внутренний университет, обучение на практике.
- Софт и платформы управления знаниями, автоматизация процессов управления знаниями: преимущества, недостатки и проблемы, которые они решают (Wiki-системы, системы онлайн-обучения и т.д.).
- Откуда взять специалиста по КМ? Проблемы подготовки и найма

Если вам кажется, что у вас интересная тема, идея, но она не укладывается в рамки конференции - напишите мне @Lananovikova, вместе придумаем формат.

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

С наступающим вас Новым годом! Настало время делиться знаниями.

Брендан Грегг опубликовал туториал по eBPF Tracing (extended Berkeley Packet Filter). В туториале рассматривается несколько тулзовин для трейсинга (bcc, bpftrace) для разных уровней сложности (от Beginner до Advanced).
http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-tracing.html

Новый опенсорсный нат от scaleway. Говорят, может до ста гигабит пропускать. https://github.com/scaleway/natasha

Envoy proxy: отличная тема, даже без кубера 🔥

Envoy - это L4/L7 proxy, раньше был в Lyft, а теперь - CNCF.
https://github.com/envoyproxy/envoy

Он позволяет легко и быстро построить service-to-service, front proxy или double proxy (или даже все в месте). Вот, например, так:
https://www.envoyproxy.io/docs/envoy/latest/intro/deployment_types/double_proxy

Конфигурация кажется немного запутанной, но через пару часов все ясно и понятно - намного проще и быстрее чем HAproxy/nginx, etc.

Пример double proxy конфигурации:
https://github.com/envoyproxy/envoy/blob/master/configs/envoy_double_proxy_v2.template.yaml

Он очень классно интегрируется с Consul (в том числе как communication bus для Consul Connect), и может динамически слушать порты, строить роуты, делать всякую магию, которую в случае с HAproxy/nginx нужно было решать всякими ужасными темплейтами и генерацией конфигурации.

Все вы знаете реализацию Envoy внутри Istio, но кто хочет попроще или не в k8s - можно брать просто Envoy.

Из сомнительных моментов могу упомянуть:
▶️ Если хотите запустить несколько Envoy контейнеров на одной ноде, нужно передавать дополнительный параметр - иначе не будет работать:
https://www.envoyproxy.io/docs/envoy/latest/operations/cli#cmdoption-base-id
▶️ Prometheus exporter встроен прямо в Envoy, но с оговорками. Путь - /stats/prometheus (what?, почему не /metrics, или почему даже редиректа нету?), и второй момент - метрики отдаются через админский интерфейс, а он не защищен. Вот issue:
https://github.com/envoyproxy/envoy/issues/2763 - должны сделать.

Мы сейчас как раз в процессе внедрения, пока что впечатления крайне положительные, могу рекомендовать 🙂

И еще расшарю для вас gist с relabel_configs для prometheus, который берет таргеты из Consul:
https://gist.github.com/Mykolaichenko/9ab505876237999466a6e3b506ef598a

Top 7 Ansible articles from 2018

1. How to use Ansible to patch systems and install applications
Learn how to save time doing updates with the #Ansible IT automation engine.

2. A sysadmin's guide to Ansible: How to simplify tasks
There are many ways to automate common sysadmin tasks with Ansible. Here are several of them.

3. How to manage your workstation configuration with Ansible
Learn how to automate your workstation setup via Ansible, which will allow you to easily restore...

4. How to use Ansible to set up system monitoring with Prometheus
In the third part of this Ansible how-to series, learn how to automate system monitoring.

5. An introduction to Ansible Operators in Kubernetes
The new Operator SDK makes it easy to create a Kubernetes controller to deploy and manage a service or application in a cluster.

6. 4 Ansible playbooks you should try
Streamline and tighten automation processes in complex IT environments with these Ansible playbooks.

7. Manage your workstation with Ansible: Automating

VPN не нужен (в некоторых частых случаях). Написал об этом небольшую статью. https://dvps.blog/p/93ec1ff3-b02b-439e-8336-77fc89dd5d7c/

Why SRE Documents Matter

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

https://cacm.acm.org/magazines/2018/12/232897-why-sre-documents-matter/fulltext

Неплохая коллекция постмортемов

https://github.com/danluu/post-mortems

Тулза — открытие дня (вчерашнего)

truffleHog — инструмент для поиска секретов в git репозитории.

Поиск осуществляется по истории. При чём по-умолчанию тулза ориентируется по энтропии строк (так что в вывод будут залетать всякие package-lock.json). Однако, можно включить поиск на основании регулярных выражений для уменьшения числа ложных срабатываний (есть готовые, плюс можно скармливать свои).

Поскольку поиск происходит по истории (можно задавать глубину), находятся в том числе те ключи, которые были “закоммичены, но оперативно потёрты”

Пока из минусов увидел только два:
- нельзя эксклудить файлы (соответствующий пул реквест висит)
- нельзя отключить подсветку вывода (потом не так удобно парсить вывод дальше)

#toolz #security

22 SSH examples, practical tips and tunnels.

#tutorial #coding #ssh
@thedevs

https://kutt.it/Xw7141