Microsoft — це не лише компанія Windows. Тепер вона підтримує кілька дистрибутивів Linux поряд із власними операційними системами. Важливо пам’ятати, що це не Linux загального призначення, як-от Ubuntu чи Red Hat.
Натомість вони орієнтовані на конкретні сценарії використання:
- SoNIC для хмарного мережевого обладнання,
- SphereOS для захищеного промислового обладнання Інтернету речей
- CBL-Mariner як хост для своїх граничних систем Azure Stack і частини підсистеми Windows для Linux.
Рік тому Microsoft придбала німецького постачальника Linux Kinvolk, щоб підтримати використання контейнерів в Azure, особливо на хмарних платформах, таких як Kubernetes. Kinvolk є домом для популярної платформи Linux Flatcar, оптимізованої для контейнерів, а також захищеної платформи Kubernetes на базі Linux Lokomotive. Kinvolk перебрав естафету випуску версії Linux для контейнерів після того, як Red Hat придбала CoreOS і об’єднала її стек із Fedora, що знизило його ефективність для таких платформ, як Kubernetes.
Додавання Kinvolk до Microsoft і Azure
Придбавши Kinvolk, Microsoft відзначила його важливість для Azure і взяла на себе зобов’язання підтримувати проєкт розвитку спільноти Flatcar, маючи намір вивчити, як працює команда Kinvolk. Цікаво чути, як Microsoft каже, що хоче навчитися добре працювати з відкритим кодом, адже очевидно, що компанія робить великий перехід до методів відкритого коду. Можливо, вона ніколи не відкриє вихідний код Windows чи Office, але використовує відкритий код як спосіб створювати нові інструменти й платформи та керувати ними.
Зрозуміло, що спочатку Microsoft розглядала Flatcar як заміну CoreOS в Azure. За рік до придбання компанія рекомендувала клієнтам перейти на Flatcar до завершення підтримки CoreOS у травні 2020 року. Міграція полягала в зміні образів розгортання Azure у репозиторії Kubernetes або контейнера. Крім того, системи CoreOS можна перемкнути на Flatcar за допомогою простого скрипту для завантаження й запуску інструментів оновлення. Це дасть змогу наявним вузлам продовжити роботу без повного повторного розгортання.
Після запуску нової ОС ви можете витратити час на створення й тестування нових образів перед повторним розгортанням контейнерного середовища.
Що таке Flatcar Container Linux?
Якщо ви ще не бачили Flatcar, це мінімальний дистрибутив Linux, призначений лише для запуску контейнерів. Flatcar спирається на багато базових концепцій розробки хмарних застосунків і надає незмінну інфраструктуру, яка повторно розгортається з кожною новою збіркою вашого коду.
Ви ж не хочете, щоб ОС змінювалася під вашим застосунком, навіть якщо вона розміщує лише контейнери вашого застосунку, тож Flatcar налаштовують перед розгортанням із системним розділом лише для читання. Його можна налаштувати на автоматичне встановлення виправлень безпеки, хоча ви можете віддати перевагу тому, щоб зробити оновлення частиною процесу збірки й розгортання.
Kinvolk надає інструменти для керування процесом оновлення: визначення, які екземпляри можна оновити, коли можна запускати оновлення та як часто їх слід застосовувати. Мінімальна система Linux із заблокованою файловою системою, що працює в хмарі, має цілком очевидний сенс. Azure забезпечує ізоляцію між орендарями, які працюють на одному й тому самому обладнанні, але незмінний контейнерний вузол значно знижує ризики безпеки, зберігаючи невелику поверхню атаки й гарантуючи, що багато класів атак не зможуть виконуватися на контейнерному вузлі. Flatcar можна знайти в Azure Marketplace у версіях для трьох різних каналів оновлення: стабільного, бета-версії та альфа-версії.
Більшість виробничих систем мають використовувати стабільний канал, а для тестування й розробки рекомендовано бета-версію та альфа-версію. Ви можете віддати перевагу запуску бета- й альфа-версій у своїх внутрішніх системах безпосередньо від Kinvolk, а не з Azure Marketplace.
Початок роботи з Flatcar в Azure
Kinvolk надає сценарії Azure CLI для встановлення Flatcar. Ви можете вибрати версію, вказавши SKU і версію перед створенням URN для образу, який установлюєте. Він має такий формат
Kinvolk підтримує образи гіпервізорів як 1-го, так і 2-го покоління, причому за замовчуванням використовується образ 1-го покоління. Якщо ви хочете використовувати gen 2, додайте -gen2 до назви каналу в розділах SKU і URN сценаріїв встановлення. Крім того, ви можете завантажити вибраний образ Flatcar, готовий для Azure, безпосередньо, помістивши його в обліковий запис сховища Azure. Kinvolk надає сценарій, для якого потрібні назва групи ресурсів і обліковий запис сховища.
Однак на практиці Azure Marketplace — найкращий варіант, оскільки образ Flatcar уже є в Azure, і вам не доведеться платити за його зберігання. Хоча AKS (служба Azure Kubernetes) використовує Ubuntu як базову ОС, ви все одно можете скористатися перевагами Flatcar в Azure, використовуючи власне встановлення Kubernetes або версію постачальника API кластера для Azure, щоб запустити власний керований екземпляр Kubernetes.
На сайті Kinvolk є інструкції з використання AKS Engine, і хоча можна використовувати автономну версію AKS, вона застаріла й більше не оновлюється. Налаштування та запуск Flatcar Після встановлення образу Flatcar вам потрібно налаштувати його за допомогою інструмента під назвою Ignition, який вводить файл конфігурації JSON у середовище користувача Flatcar перед першим завантаженням. Після завантаження файлова система Flatcar, призначена лише для читання, означає, що ви не можете вносити зміни.
Файли конфігурації записуються у форматі YAML, утворюючи Container Linux Config. Це задає базову конфігурацію контейнерного хоста, визначаючи, які службові контейнери він завантажує, як вони запускаються і як хост реагує на збій контейнера. Наприклад, можна перезавантажувати найновіші образи контейнерів під час запуску, видаляти старі версії, коректно завершувати роботу під час вимкнення та перезапускати контейнери, що вийшли з ладу, після заданого проміжку часу.
Kinvolk надає інструмент для перетворення CLC YAML на JSON, який використовується з Ignition. Створивши JSON, його можна передати Flatcar за допомогою Azure CLI як користувацькі дані під час налаштування контейнера. Azure CLI може додавати користувачів і ключі SSH до образів, якщо вам потрібно входити в них для розробки й налагодження. Виробничим екземплярам це не знадобиться, оскільки це збільшує ризики безпеки. Команда рекомендує протестувати віртуальну машину Flatcar на машині для розробки, перш ніж переходити до виробничого середовища. Хоча можна використовувати Hyper-V, у більшості документації використовується QEMU з відкритим кодом, тож ви можете віддати перевагу тестуванню в системі Linux.
Такий підхід дає змогу використовувати власні тестові образи Kinvolk, установлюючи файл JSON Ignition під час першого завантаження. Якщо ви експериментуєте з різними контейнерами й конфігураціями, просто видаляйте віртуальну машину щоразу, коли вносите зміни, та використовуйте іншу копію образу Flatcar.
Flatcar призначений не лише для Azure. Він працює в усіх основних загальнодоступних хмарах, а також у граничних і приватних хмарах. Оскільки ті самі файли конфігурації працюють у всіх системах, Flatcar — цікавий варіант для гібридних хмарних і граничних розгортань, де ви можете розробити робочі навантаження один раз і доставити їх до кількох цілей із мінімальними змінами.
Також є підтримка таких інструментів, як Terraform, тож ви можете зробити Flatcar частиною платформи «інфраструктура як код», відокремивши керування контейнерними вузлами від застосунків. За останні кілька років Microsoft багато чого навчилася в керуванні придбаннями проєктів із відкритим кодом. Як і Deis Labs, Kinvolk залишається майже незалежною організацією. Це дає змогу йому й надалі підтримувати свою спільноту з відкритим кодом, а також створювати й проводити власні експерименти.
Тим часом Microsoft може багато чого навчитися у Flatcar, розширюючи власні пропозиції Linux і додаючи до свого портфеля більше проєктів із відкритим кодом.
