🤓 Підхід Infrastructure as Code (IaC) приніс революційні зміни у cloud computing, зробивши управління ресурсами швидшим, ефективнішим і сконцентрованим в одному місці завдяки роботі з кодом. Ба більше, це додатковий крок у боротьбі з помилками через людський фактор та розширення можливостей масштабування. Але є ряд факторів, які підлягають регулярному аналізу, щоб пайплайн працював як треба. На які аспекти треба звернути увагу, працюючи з Infrastructure as Code та CI/CD pipeline:

👉 Сек’юрність. Сканування пайплайну має бути невіднятною частиною роботи. Перевіряйте інфраструктуру на предмет вразливостей, відповідностей стандартам та правилам безпеки.

👉 Вартість. Перед тим, як застосовувати зміни в Terraform, перевіряйте їхню ціну ще в процесі, щоб запобігти неочікуваним витратам після деплоя.

👉 Лінтинг. Інструменти для лінтингу допомагають виявляти потенційні проблеми та помилки у коді Terraform (синтаксис, сек’юрність тощо).

👉 Відповідність. Перевіряйте, чи відповідає ваш код корпоративним вимогам, встановленим стандартам і правилам.

👉 Документація. Не нехтуйте створенням документації на ваш Terraform CI/CD pipeline. Це допоможе зробити інфраструктуру документованою, зрозумілою та доступною для всіх зацікавлених осіб.

👉 Забирайте цікавий матеріал «на почитати»: Canary deployment using Argo Rollouts and Nginx

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

🤔 Чи уявляєте ви роботу з інфраструктурою у ручному режимі? Ага, коли так береш і ручками на консолі тап-тап-тап, перевіряючи, щоб все працювало. Але завдяки такому підходу як 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. Ділимося тулом, який за лічені хвилини допоможе побудувати робоче середовище кластеру будь-якою необхідною кількістю нод.