Kubefire (http://e42.link/3RYWoO5) — Инструмент для автоматической установки K8s, K3s, etc. Использет разработку от Amazon для AWS Lambda — Firecracker(http://e42.link/3J8l8iG). Интересная альтернатива ручной установке или использованию K3s, minikube, etc. для малых инсталляций.

Через пару минут начнется вебинар о безопасном найме от «Экспресс 42». Присоединяйтесь: 👉http://e42.link/3zCUVFQ

DevOops от JUG Ru Group возвращается!

Конференция, посвященная инженерным DevOps‑решениям, пройдет уже в октябре.

Вы можете стать ее спикером. Если у вас есть интересные кейсы или вы хотите поделиться опытом решения нетривиальных задач — подавайте заявку на участие.

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

На сайте (http://e42.link/3zKhVD2) вы найдёте список тем, с которыми можно выступить. Если хотите выступить с другой темой, присылайте свои предложения — их обязательно рассмотрят.

А если хотите просто поучаствовать в DevOops 2022 — билеты уже на сайте по ссылке — http://e42.link/3JnbsAU

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

Чтобы решить эту проблему приходится писать несколько команд terraform state mv, чтобы имеющиеся облачные ресурсы находились по новому пути.
В Terraform 1.1 (который вышел в конце 2021) появился новый синтаксис языка: блок moved, который помогает в таком рефакторинге.
Но если в процессе рефакторинга переезжает особенно много ресурсов, то даже писать блоки moved {} становится проблематично.
Для решения этой проблемы есть утилита tfautomv (http://e42.link/3EpnLfC), которая анализирует вывод terraform plan и сама подставляет набор таких блоков.
Надеемся рефакторить ваш код на терраформе теперь станет проще.

На конференции ObservabilityCON Grafana анонсировала два новых инструмента:
Phlare(http://e42.link/3fx2OFy) — БД для непрерывного профайлинга;
Faro (http://e42.link/3sVyO9B) — JS-библиотека для observability frontend-приложений

Несколько ссылок для тех, кто строит практики DevSecOps у себя в компании:
Minimum Viable Secure Product (http://e42.link/3UtFBDc) — минимальный чеклист безопасности для любых интернет-сервисов.

Модель зрелости DevSecOps (http://e42.link/3hdWbZg) — около 20 практик DevSecOps с рекомендуемым порядком применения от базовых к продвинутым.

DevSecOps Playbook (http://e42.link/3hnUXei) — всеохватное описание практик DevSecOps для всего цикла разработки, для компаний любого размера. Указан рекомендуемый приоритет и сложность применения, также показана взаимосвязь с мировыми стандартами безопасности.

Вышел очередной технический радар от ThoughtWorks.
Много новых рекомендаций по построению инфраструктурных платформ и по безопасности. Ссылка на PDF http://e42.link/3TgaoCx

Ниже небольшой разбор отчета.

Техники:
Path-to-production mapping (вариант Value stream mapping) появился на радаре только-только и сразу в квадранте Adopt.
Продолжается использование концептов из Team Topologies. В этот раз говорится про:
Team cognitive load — при проектировании структуры команд ориентируемся на снижение когнитивной нагрузки для команд
Incremental developer platform — строим платформу по кусочкам, слой за слоем, а не пытаемся сразу построить гигантское здание
Активны темы про безопасность:
Обновили описание про Threat modelling (модель угроз)
SLSA и SBOM переехали из Assess в Trial (это соответственно рекомендации по безопасному управлению опенсорсными зависимостями, и формат описания таких зависимостей)
Github push protection — быстрое сканирование кода при пуше и блокировка, если он не проходит проверки (например, содержит секреты в открытом виде). Классически сканирование проводилось уже после того как такой код попадает в репозиторий, а т.е. секреты в открытом виде становятся доступны атакующим в будущем.
Появилась тема «Observability for CI/CD pipelines» — мониторинг пайплайнов команд для того, чтобы помочь им разобраться с возможными проблемами процесса
Принципы SOLID предлагают заменить на характеристики CUPID, которыми должно обладать современные приложения
SLI/SLO as code уже появился на радаре, хотя спецификация OpenSLO появилась всего лишь год назад. Идея в том, чтобы описывать SLI/SLO прямо в коде (например в YAML), и из этого описания инструменты мониторинга будут сами собой строить алерты и графики с ключевыми метриками.
Поднимается тема «облачных монолитов» (мы бы добавили сюда и «инфраструктурные монолиты») — приложений, которые по-модному запущены на облаках, но в которых невозможно изменить небольшой кусок, чтобы не пришлось переделывать все приложение целиком. Естественно, про это говорится в квадранте Hold, т.е. это предостережение о такой опасности.

Платформы:
Backstage наконец дошел до состояния Adopt, т.е. он однозначно рекомендуется к использованию.
Colima в качестве альтернативы для Docker Desktop
Несколько интересных платформ в области Data/ML
На радаре появились VictoriaMetrics в качестве бакенда к Prometheus (но сами Thoughtworks рекомендуют также присмотреться к Cortex и Thanos)
Keptn — платформа для SRE, первая(?) в своем роде. Идея в том, что при движении по пайплайну в сторону продакшна становятся необходимыми совсем другие способы движения по пайплайну — мы это знаем в контексте, например Canary Deployment или Rolling Deploy. При помощи Keptn можно строить сложные оркестрации деплоя, которые будут учитывать, например SLO в качестве Quality Gate, или делать подобные же сложные многоступенчатые раскатки по нескольким окружения. Естественно, с дашбордами и всем что нужно, чтобы этим удобно было пользоваться для SRE

Инструменты:
k6 перешел в Adopt, это инструмент для нагрузочного тестирования
Cruft — инструмент для упрощения обновления шаблонов-генераторов и прочего бойлерплейта (например, helm-чартов, которые обычно копипастятся в каждый сервис, и которые потом больно обновлять), работает на базе Cookiecutter
Hadolint для линтинга докерфайлов
Наконец, на радаре появился Kaniko для сборки контейнеров
Для тестирования OpenAPI/ AsyncAPI контрактов появился Spectral
Styra для отладки политик Open Policy Agent
Пара инструментов для управления затратами на облако: Infracost и Harness Cloud Cost Management
Karpenter как интеллектуальная на замену Cluster Autoscaler
Mizu для отладки сетевой связности Kubernetes
Teller для управления секретами на рабочем компьютере для различных окружений — этот инструмент автоматически вытаскивает и подставляет секреты из большого количества разных бакендов, и за счет его настроек можно однообразно запускать приложения на рабочем компьютере, в CI и на продакшне

SheetOps (не путать!) Интерфейс с kubernetes в google spreadsheets 😀
http://e42.link/3XIXfFc

Github выпустил The state of open source software — http://e42.link/3VI47RU

Основные тезисы:
* IaC растёт, язык года HCL
* Компания крутая, если запустила OSPO (open source program offices)
* 50% свежих контрибьюторов предпочитают коммерчески-поддерживаемые проекты.
* Разработчики предпочитают приватные репозитория (чуть более 20% паблик)
* Уязвимости стали устранять чаще благодаря dependabot и т.д.
* В Антарктике не хватает новых разработчиков
* На графике роста количества разработчиков Россия входит в двадцатку, и авторы явно это подчеркнули. Через пару абзацев история про разблокировку в Иране.
* Статистика (http://e42.link/3BjeCTP) по языкам и статистика (http://e42.link/3BiiggH) по самым-самым проектам.
* Go наступает на пятки Python в направлениях скриптовой и облачной разработки
* В коммерческих проектах разрабы со стороны чаще пишут комменты или issue, а мейнтейнеры проектов занимаются кодом (маркетинговая жилка возможно в этом есть, упоминание microsoft-реп стало более заметным). Также пишут, что коммерчески-поддерживаемые проекты самые популярные.

Прогнозы(http://e42.link/3Bjz8Dx) экспертов
* Трое говорят про OSPO: разработчики недооценены, вкладываться в OSS круто.
* Open source приносит социальную пользу: углеродный след, COVID-19, ВОЗ,
* В этом году увеличилось внимание правительства
* Большая вовлеченность в «supply chain security» (не знаем, как лучше перевести: поставка безопасности/DevSecOps)

В завершении (http://e42.link/3h3OEwF) цитата:
At the end of the day, open source is and will continue to be a global team sport. Over the past year governments and policymakers have increasingly identified themselves as players, and we’re excited for what’s to come.
Пора вводить хакатоны в Олимпиаду!

Flux стал graduated по версии CNCF
https://www.weave.works/press/releases/weaveworks-gitops-project-flux-graduates-in-the-cncf/

OWASP ТОП 10 рисков безопасности в CI/CD средах https://e42.link/3hDtJ3I

Grafana Labs в своем блоге опубликовали статью – A complete guide to managing Grafana as code: tools, tips, and tricks.

Рассмотрели имеющиеся на текущий момент способы конфигурации Grafana as Code - Grafana Terraform provider, Grafana Ansible collection, Grafonnet for dashboards, Grizzly, Grafana APIs with GitHub Actions, and Crossplane. Также, предложили рекомендации для выбора какого то из этих способов. https://e42.link/3FG8PJi

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

Отметим из плюсов фреймворка, что это еще и хороший перевод Team Topologies, Модифицирующая команда для Enabling Team хоть немного и не точно, так нет ориентации на outcome, но отлично показывает, что это команда делает в других командах.

Рекомендуем к изучению и переиспользованию.
Ссылка на сайт https://e42.link/3BSrxMs
Ссылка на tg для обсуждения https://e42.link/3joUr0v

Еженедельный список рассылки про экосистему Terraform https://e42.link/3XquImV

Хороший обзор монорепо как практики — ключевые требования к тому, чтобы монорепо работало хорошо (у него есть как несомненные преимущества по отношению к множеству репозиториев, так и минусы), и для чего это нужно. Когда лучше держать монорепу, а когда лучше держать код по отдельным репозиториям. Некоторые инструменты на текущий момент работают только с JS репозиториями. Тем не менее, обзор будет полезен для построения работы с монорепо для любых языков программирования.
https://e42.link/3kiMiv9

Еще одно средство автоматизации CI/CD пайплайнов.

https://e42.link/3RIr4Dq

Каждый stage можно описать с помощью API (на любом ЯП), который будет выполняться в контейнере. И каждый такой stage выстраивается в цепочку (пайплайн) в виде графа.

Легковесный фреймворк для написания несложных операторов для Kubernetes https://e42.link/3RL2uC1

Буквально в десяток строчек операторы пишутся на питоне.

Каждый, кто когда-либо отлаживал CI/CD пайплайны при отладке сталкивался с тем, что фактически нет возможности протестировать свой пайплайн локально до того как сделать push.
От этого страдает надежность пайплайнов, качество и увеличивается цикл разработки (поправить пайплайн ➡️ сделать пуш ➡️ подождать результатов на CI-сервере).

Как минимум для Github Actions и Gitlab есть способ запускать и отлаживать пайплайны локально:
https://e42.link/3Y4dD2f — для Github Actions
https://e42.link/3ky8v8I — для Gitlab-CI

Если у вас был опыт работы с ними - напишите о нем в комментах к посту.

Kubernetes-кластер без kubelet:
https://e42.link/3J1Ziin

Можно локально поднять Kubernetes-кластер без необходимости разворачивать все компоненты. При этом эмулируется наличие нескольких нод, т.е. можно использовать для тестирования многонодовых инсталляций.

Интересная статья, про тренды и будущее devops-практики Observability.

https://e42.link/3KToOaZ

Что можно отметить:

1. Технологический стек для создания цифровых продуктов меняется и это приводит к изменению и инструментов для Observability. Вместо монолитных архитектур сейчас используют микросервисы, Kubernetes и распределенную архитектуру, cloud native.

2. Если раньше инструменты шли под определенное направление Observability: логирование, мониторинг, трейсинг, то теперь есть тренд на создание платформенных решений для объединения в одном окне/интерфейсе возможности работы с логами, метриками, трейсами и так далее.

3. Связь Observability с процессами вокруг бизнес-данных, например, сбор логов ETL или бизнес-процессов и визуализация шагов бизнес-процессов.

4. Отсутствие зависимости от одного вендора.

5. Интеграция инструментов машинного обучения для решения задач предиктивного мониторинга.

6. Более тесная интеграция собираемых данных/телеметрии с решением задач по security + тут тоже интеграция с инструментами машинного обучения.

7. Оптимизация затрат на хранение и обработку собираемых метрик. В статье не указывается про Yandex Cloud Remote Storage, но, вероятно, это про решение вышеуказанной задачи. В контексте - зачем внутри компании разворачивать свою хранилку для метрик, когда с помощью API метрики в нужном формате можно складывать и хранить в облаке и потом там же визуализировать c помощью DataLens и других инструментов.

8. Мониторинг CI/CD-пайплайнов.

9. Автоматизация процесса алертинга на основе машинного обучения, а не выставленных в ручную пороговых значений.