А колись це здавалося неіснуючою реальністю 🫣

🤔 Чи уявляєте ви роботу з інфраструктурою у ручному режимі? Ага, коли так береш і ручками на консолі тап-тап-тап, перевіряючи, щоб все працювало. Але завдяки такому підходу як Infrastructure as Code (IaC) наше життя стало значно легшим і приємнішим, коли справа стосується управління інфраструктурою.

Підготували для вас добірку ТОП open-source інструментів для управління інфраструктурою як кодом:

👉 TFLint. Допомагає виявляти потенційні інциденти та помилки у коді шляхом перевірки конфігураційних файлів Terraform згідно політик відповідності, стандартів написання коду та best practices. Надсилає фідбек щодо помилок у синтаксисі, конфігураціях і вразливостей відносно безпеки.

👉 Infracost. Інструмент для оцінки вартості використання хмарної інфраструктури. Інтегрується з Terraform і допомагає швидко оцінити вартість внесення змін у інфраструктуру перед деплоєм. Підтримує AWS, Azure, Google Cloud та інших провайдерів.

👉 Checkov. Аналізує код, інтегруючись із такими фреймворками як Terraform, CloudFormation, Kubernetes. Допомагає виявити й усунути помилки у конфігураціях, потенційні інциденти, а також оцінити безпекові ризики перед деплоєм.

👉 TFSec. Інструмент для сканування та виявлення потенційних безпекових загроз у коді Terraform (як у HCL, так і в JSON файлах). Під час аналізу TFSec перевіряє Terraform на відповідність правилам безпеки даних, мережевої безпеки та контролю доступів. Фідбек містить не тільки виявлені загрози, а й пропозиції щодо їх усунення.

👉 Terraform-docs. Інструмент командного рядка, який генерує документацію для модулів Terraform у різноманітних вихідних форматах (Markdown, JSON, YAML). Він парсить вхідні файли, витягує коментарі з документації (описи ресурсів, перемінні тощо) та збирає їх у структурованому форматі.

👉 Terratest. Автоматизує тестування інфраструктури, дозволяючи виявляти помилки ще на етапі розробки. За допомогою цього інструмента можна писати тести для перевірки інфраструктурного коду.

👉 Regula. Сканує файли Infrastructure as Code на предмет потенційних загроз сек’юрності, а також відповідності політикам і стандартам. Підтримує такі формати як Terraform, CloudFormation, Kubernetes YAML та Dockerfile.

Чи була корисною добірка? Поділіться у коментарях, які інструменти для управління Infrastructure as Code використовуєте ви ⬇️⬇️⬇️

Зі всіма траплялося, егеж? 🤧

💥 kubefirst – ця CLI створює GitOps платформи, які інтегрують найкращі cloud native інструменти з нуля.

Вийшов реліз KubeVirt v1.0! 🤩

Трохи історії. Проєкт KubeVirt був започаткований Red Hat ще наприкінці 2016-го. Головною ціллю команди було дати відповідь на питання: чи можуть ВМ запускатися у контейнерах і деплоїтись через Kubernetes? Справи пішли досить успішно і нове рішення виглядало правдоподібним. За цей час KubeVirt виріс у 45 активних репозиторіїв з головним репозиторієм kubevirt/kubevirt у 17k комітів та 1k форків.

Що ж містить реліз 1.0? Читаємо статтю ком’юніті та ділимося враженнями у коментарях 👇👇👇

Давненько не говорили про моніторинг і метрики 🧐

Пропонуємо статтю про Netdata. Як каже автор – швейцарський ніж для моніторингу. Що ж, будемо розбиратися.

Працювали з Netdata? Діліться в коментарях, як вам?

А у вас бувало таке? 😭

🤓 У скарбничку Command Line Interface (CLI) – Preevy. Це потужний тул для спрощення роботи з ephemeral preview середовищами. Можна використовувати для будь-якого застосунку Docker-Compose у хмарі.

🧐 Keep Linux Open and Free—We Can’t Afford Not To

Oracle заявили про готовність продовжувати підтримку сумісності з Red Hat Enterprise Linux у своєму дистрибутиві Oracle Linux. І це попри обмеження Red Hat на публічний доступ до вихідних текстів пакетів RHEL.

Більше про цю новину тут

Ви ж не пропускаєте навчальні відео від Amazon, так? 🤨

Команда ділиться якісним матеріалом, який буде корисний як новачкам, так і PRO.

У цьому відео – про основи роботи з Amazon VPC (Virtual Private Cloud). Як побудувати віртуальну приватну хмару, зокрема IP-середовище, підмережу, налаштувати маршрутизацію, безпеку тощо. А ще: підходи та кейси під’єднання VPC до фізичного дата-центру через VPN або AWS Direct Connect. Варто послухати! 🔥

Трохи про мультитаскові скіли девопсів 🤪

Порівняння продуктивності Amazon Elastic Kubernetes Service (EKS) та Google Kubernetes Engine (GKE)

⚡ Потужність платформ Kubernetes зазвичай сприймається як належне. Це ОК – ми з цим спокійно живемо і працюємо 😊 Але автор статті пішов далі і хоче розібратися, як поводять себе контейнери на двох різних Kubernetes-managed платформах.

Новенького з візуалізації підвезли 👉 Grafana Dashboards - DevOps Nirvana

Якщо ви працюєте з Nginx Ingress та Prometheus, цей дашборд перевершить ваші очікування. Обирайте зручну візуалізацію для метрик AWS і Kubernetes та насолоджуйтесь 😊

Коли DevOps сказав автоматизувати тести. Мануальники, ви теж таке відчували, чи не так..? 😬

Коли ви працюєте з кількома сутностями, load balancing – річ номер 1, про яку треба подбати. У статті на CloudWeekly досить детально розписана робота з алгоритмами load balancing. Гоу читати 👈

Маємо цікаву новину: 14-15 вересня запрошуємо на DevOpsDays Ukraine: Disaster Recovery ⚙️

Організатори конференції готують для нас Cultural Talks, Ignites & Tech Talks від світових та українських експертів: Charity Majors, Iaroslav Molochko, Manuel Pais, Adriana Villela та інші.

Головні теми заходу: Self-Service Tooling, Future of Platforms, CI/CD та IaC для GameDev, як досягати результатів в умовах війни та багато іншого.

Під час live fireside chat можна буде поставити запитання засновнику DevOpsDays, Patrick Debois, та дізнатися більше про його досвід та ідеї.

І, звісно, буде онлайн-нетворкінг на Open-Spaces з однодумцями з усього світу.

💙💛 А ще на івенті діє благодійна ініціатива — збір для фонду UA Responders. Це допоможе закупити необхідну гуманітарну допомогу для рятівників, медиків, парамедиків та інших працівників служб швидкого реагування. Долучайтесь і ви!

Коли? 14-15 вересня
Де? Онлайн

Деталі на сайті 👀 https://bit.ly/3KQ3jXS

Коли спитали, що таке DevOps 🧐

Cellular architecture останніми роками стала досить популярною серед компаній, які працюють з масштабними онлайн сервісами. Такий тип архітектури націлений суттєво зменшити радіус впливу багів на сервіс. Деякі компанії починають перехід на архітектуру сот саме з сервісів, які безпосередньо впливають на прямий контакт з кінцевим користувачем.

У статті маємо цікавий прикладний кейс переходу від моноліту на cell-based architecture від Slack. Перехід зайняв півтора року, а деталі описані у серії статей на сайті проєкту.
Гоу розбиратися!

🤩 libvirt-k8s-provisioner
Ніколи не буде зайвим покласти до робочої скарбнички ще один інструмент Kubernetes. Ділимося тулом, який за лічені хвилини допоможе побудувати робоче середовище кластеру будь-якою необхідною кількістю нод.

Якщо ви DevOps, Tools Engineer або працюєте з Platform Team, вам знайомо, що команди можуть бути різними не тільки за накопиченим досвідом, а й за рівнем «інженерної зрілости». Наприклад, у компанії Big Tech виділяють такі рівні:
🤓 The stable senior team;
🌟 The newly formed team;
👶 The junior team;
😮‍💨 The overworked team;
☠️ The toxic team;
🤯 «The manager’s about to be fired» team.

Враховуючи різні рівні зрілості, побудова платформи або інструментарію в команді може проходити за геть різними підходами. Але щоб зробити роботу ефективною в будь-якій команді, слідуйте короткому чеклісту (та не обмежуйтесь ним, бо це тільки загальні рекомендації).

👉 Ставте реальні цілі. Заплануйте реалізацію 80% кейсів, бо зазвичай 15% проходять повз, а 5-ти відсоткам взагалі не судилося втілитися в життя.

👉 Забезпечте легкий шлях. Методи й підходи мають бути простими та зрозумілими для всіх. Якщо сеньйорна команда дасть вам швидку ефективну реакцію, то «токсики» спробують знайти підводне каміння й виразити супротив. Тож ваше рішення не має залишати їм такого шансу.

👉 Запропонуйте кастомізацію. Зазвичай команди хочуть враховувати власні потреби при реалізації будь-яких нових рішень. У ролі лідера/керівника ви маєте дати їм таку можливість та не блокувати здорові побажання.

👉 Майте опції. Навіть якщо ви на 100% впевнені у дефолтних рішеннях і конфігураціях, бажано завжди мати альтернативні варіанти, думки й рекомендації.

👉 Не ускладнюйте. Якщо, наприклад, працюєте з інструментом API, працюйте з ним як з API, не вигадуючи колесо.

👉 Доводьте цінність своїх рішень. Команда має відчути, що саме ваше рішення чи інструмент суттєво перевершує альтернативні варіанти. Так ви отримаєте більше підтримки.

Підсумуємо: будуючи сервісні платформи/інструментарій у команді, робіть речі простими, доступними та зрозумілими. Мінімізуйте ієрархію узгоджень і максимально впевнено просувайте саме ваші рішення 🚀

Feeling DevOps Power ⚡️