Як пояснити простими словами, що таке Docker in Docker 😄

💥 mox – сучасний open source поштовий сервіс для пошти з власним хостингом.

Закінчуємо нашу добірку найкращих Linux дистрибутивів для новачків сьогоднішнім постом (частина 3).

👉 Rocky Linux. Дуже вдала альтернатива CentOS, яка народилася як окремий проєкт. Rocky – безкоштовний дистрибутив enterprise-рівня, готовий до продакшену. На 100% сумісний із RHEL: він ребілдить джерела напряму саме звідти. Пропонує простий сценарій міграції з інших корпоративних дистрибутивів Linux.
Системні вимоги:
- архітектура x86-64, ARM64, ppc64le, або s390x;
- 2 GB RAM;
- 40 GB вільного місця у сховищі;
- 16 GB USB диск.

👉 PepperMint_OS. Дистрибутив підійде для поціновувачів мінімалістичного стилю з можливостями персональних налаштувань. Дуже проста інсталяція тільки того, що дійсно вам потрібне. З мінусів: поставляється без firewall, браузера та медіаплеєра.
Вимоги до встановлення дистрибутиву:
- RAM: 1 ГБ;
- CPU: процесор на базі Intel x86;
- місце на жорсткому диску: мін. 4 ГБ

👉 MX Linux. Розроблений командою MEPIS Linux та antiX Linux community, цей дистрибитив базується на Debian. Легкий і з можливостями персоналізації, MX Linux використовує основні компоненти antiX з додатковим софтом від ком’юніті MX.
Для встановлення MX необхідно мати:
процессор: i686 Intel або AMD сумісний;
оперативна пам’ять: 512 MB;
диск: 5 GB вільного місця.

👉 PCLinuxOS. Дистрибутив для x86_64 десктопу або лептопу, який постачається як ISO образ LiveCD/DVD/USB. Він запускається без внесення жодних змін до комп’ютера або може бути встановлений на жорсткому диску. Простий інтерфейс підтримує 85 мов.
Вимоги для використання:
- процесор: x86_64 Intel, AMD або VIA;
- оперативна пам’ять: мін. 51 MB, рекомендовано 2GB;
- диск: мін. 12GB, рекомендовано 20GB;
- відеокарта: nVidia, ATI, Intel, SiS, Matrox, VIA.

🤩 Manage Your AWS EKS Load Balancer Like a Pro: AWS Load Balancer advanced tips & tricks.

У статті автор (Meysam, SRE) робить акцент на деяких особливостях, які часто ігноруються при роботі з AWS EKS Load Balancer, втім є важливими для успішної автоматизації всередині кластера. Ці практичні підказки побудовані за принципом DRY (“Do not repeat yourself”).

Хвала святим хлопцям із dotCloud, що свого часу започаткували нову епоху в розробці 🙏

🤓 Підхід 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 сказав автоматизувати тести. Мануальники, ви теж таке відчували, чи не так..? 😬