💥Популярні Linux-дистрибутиви у 2023 (частина друга)💥Продовжуємо розповідати про дистрибутиви для Linux, які підійдуть для поціновувачів Windows та Mac.

👉 Deepin Linux. Раніше цей дистрибутив виходив під назвою Hiweed Linux або Linux Deepin. Це open-source проєкт, який вирізняється одним з найкрутіших середвищ: яскравий дизайн, анімація, розкладки та іконки, а ще – звукові ефекти при кліках мишею.
Вимоги до Deepin:
- Intel Pentium IV 2 ГГц або вище;
- мін. 1 ГБ оперативної пам'яті;
- мін. 20 ГБ вільного місця на диску.

👉 Manjaro Linux. Ідеальний відкритий дистрибутив для новачків, які тільки починають працювати з Linux. Manjaro розроблений на базі легкого та швидкого Arch, який, зі свого боку, створений для advanced-користувачів. Manjaro взяв від Arch найкращі фішки, втім доступний початківцям.
Для його встановлення необхідно мати:
- 4GB пам’яті;
- 30GB вільного місця на диску;
- процесор 1GHz;
- HD монітор та графічну карту.

👉 CentOS. Створена на базі RHEL (Red Hat Enterprise Linux), має відкритий код та підтримуться ком’юніті. Це класна можливість для новачків спробувати Linux на базі RPM безкоштовно, на відміну від Red Hat, який вимагає платної підписки.
Мінімальні вимоги для використання:
- відсутня підтримка 32-бітних процесорів на базі архітектури i386;
ОЗП 1 ГБ;
- 20 ГБ вільного місця на жорсткому диску або SSD;
- макс. розмір файлів файлової системи ext3 - 2 ТБ, ext4 - 16 ТБ;
- макс. розмір файлової системи ext3 - 16 ТБ, ext4 - 50 ТБ.

👉 OpenSUSE Tumbleweed. Один із найпотужніших дистросів Linux – стабільний, надійний, безпечний та простий у користуванні. Побудований на базі технологій openSUSE, як то Btfrs file system та YaST.
Системні вимоги:
- Pentium* 4 1.6 GHz або вища версія;
- 1 GB RAM;
- мін. 10 GB на диску;
- розширення екрана: 800 x 600 (1024 x 768).

💥 Kubernetes Capacity and Resource Management: It's Not What You Think It Is

Принцип роботи Kubernetes побудовано на концепції подів (pods). Pod – це сутність, притаманна саме Kubernetes, і найменша частина в кластері, яку можна деплоїти. Будь-яке робоче навантаження, що запускається в Kubernetes – це под, а не контейнер.
Про те, як управляти подами та ресурсами Kubernetes – у статті

Як пояснити простими словами, що таке 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 платформах.