Це перша публікація у серії матеріалів, присвячених змінам, покращенням та доповненням у майбутньому оновленні платформи Red Hat OpenShift до 4.0, які допоможуть підготуватися до переходу на нову версію.
З того самого моменту, як представники спільноти Kubernetes, що тільки формувалося, вперше зібралися восени 2014 року в офісі Google в Сіетлі, вже можна було сказати, що проекту Kubernetes судилося докорінно змінити сучасні підходи до розробки та впровадження програмного забезпечення. У той же час публічні постачальники хмарних послуг продовжували активно інвестувати у розвиток інфраструктури та сервісів, що значно полегшило та спростило роботу з ІТ та створення софту, і зробило їх неймовірно доступними, що мало хто міг уявити собі ще на початку десятиліття.
Зрозуміло, анонс кожного нового хмарного сервісу супроводжувався численними обговореннями експертів у Твіттері, причому суперечки велися на різні теми – у тому числі про кінець епохи відкритих вихідних кодів, про захід ІТ на стороні клієнтів (on-premises IT), про неминучість нової софтової монополії у хмарі, і про те, як нова парадигма X прийде на зміну решті всіх парадигм.
Чи варто говорити, що всі ці суперечки були дуже дурними
Реальність така, що ніщо нікуди не пропаде, і сьогодні можна спостерігати експоненційне зростання кінцевих продуктів та способів їх розробки, що пов'язано з постійною появою нового програмного забезпечення у нашому житті. І незважаючи на те, що все навколо змінюватиметься, водночас за своєю суттю все залишатиметься незмінним. Розробники софту будуть як і раніше писати код з помилками, інженери-експлуатаційники і фахівці з надійності ходитимуть з пейджерами і отримуватимуть автоматичні оповіщення в Slack, менеджери будуть так само оперувати поняттями OpEx і CapEx, і щоразу при виникненні збою старший розробник сумно зітхатиме зі словами: «Я ж говорив»…
Що дійсно слід би обговоритиТак це те, які інструменти ми можемо отримати в своє розпорядження, щоб створювати більш якісні програмні продукти, і як вони дозволяють підвищити безпеку і зробити розробку простіше і надійніше. Зі збільшенням складності проектів з'являються і нові ризики, і сьогодні життя людей настільки залежать від програмного забезпечення, що розробники просто зобов'язані намагатися робити свою роботу краще.
Kubernetes є одним із таких інструментів. Ведеться робота над тим, щоб у рамках Red Hat OpenShift об'єднати його з іншими інструментами та сервісами в єдину платформу, яка дозволяла б зробити програмне забезпечення більш надійним, зручним в керуванні та безпечним для користувачів.
З урахуванням сказаного команда OpenShift задається одним простим питанням:
Як можна зробити роботу з Kubernetes простіше та зручніше?
Відповідь на подив очевидна:
- автоматизувати складні моменти у розгортанні на хмарі або поза хмарою;
- зосередитися на надійності, ховаючи при цьому складність;
- продовжувати постійну роботу з випуску простих та безпечних оновлень;
- домагатися контрольованості та можливості аудиту;
- прагнути спочатку забезпечувати високу безпеку, але не на шкоду юзабіліті.
Наступний реліз OpenShift повинен враховувати як досвід творців, так і досвід інших розробників, які у великих масштабах впроваджують програмне забезпечення у найбільших компаніях світу. Крім того, в ньому необхідно враховувати весь накопичений досвід відкритих екосистем, які сьогодні лежать в основі сучасного світу. При цьому необхідно відмовитися від колишнього менталітету розробника-любителя та перейти до нової філософії автоматизованого майбутнього. Це має бути «міст» між колишніми та новими способами розгортання софту та повністю використовувати всю доступну інфраструктуру – не важливо, чи обслуговується вона найбільшим хмарним постачальником чи запущена на крихітних системах на периферії.
Як досягти такого результату?
У Red Hat прийнято довго виконувати нудну і невдячну роботу, щоб зберегти спільноту, що сформувалася, і не допустити закриття проектів, в яких компанія бере участь. У open-source співтоваристві складається величезна кількість талановитих розробників, які створюють найнезвичайніші речі – розважальні, навчальні, що відкривають нові можливості і просто красиві, але, зрозуміло, ніхто не чекає, що всі учасники рухатимуться в одному напрямку або переслідуватимуть спільні цілі. Використання цієї енергії, перенаправлення її в потрібне русло, часом необхідне для розвитку напрямів, які були б корисні нашим користувачам, але в той же час ми повинні стежити за розвитком наших співтовариств та навчатися у них.
На початку 2018 року Red Hat придбала проект CoreOS, який мав схожі погляди на майбутнє – безпечніше та надійніше, що створюється на принципах open-source. Компанія працювала над подальшим розвитком цих ідей та їх реалізацією, втілюючи в життя нашу філософію – намагаючись досягти безпечної роботи всього програмного забезпечення. Вся ця робота будується на Kubernetes, Linux, публічних хмарах, приватних хмарах та тисячах інших проектів, що лежать в основі нашої сучасної цифрової екосистеми.
Новий реліз OpenShift 4 буде зрозумілим, автоматизованим і природнішим
Платформа OpenShift працюватиме з найкращими та надійними операційними системами Linux, з bare-metal апаратною підтримкою, зручною віртуалізацією, автоматичним програмуванням інфраструктури та, зрозуміло, контейнерами (які по суті є просто образами Linux).
Платформа повинна бути безпечною з самого початку, але при цьому забезпечувати можливість зручних ітерацій для розробників - тобто мати достатню гнучкість і надійність, при цьому, як і раніше, дозволяти адміністраторам здійснювати аудит і забезпечувати зручність управління.
Вона повинна дозволяти запускати програмне забезпечення «у вигляді сервісу» і не призводити до некерованого розростання інфраструктури для операторів.
Вона дозволить розробникам зосередитись на створенні реальних продуктів для користувачів та клієнтів. Не доведеться продиратися крізь нетрі налаштувань обладнання та програмного забезпечення, а всі випадкові ускладнення залишаться у минулому.
OpenShift 4: NoOps платформа, яка не потребує супроводу
В описувалися ті завдання, які допомогли сформувати бачення компанії щодо OpenShift 4. У команди стоїть завдання максимально спростити повсякденні завдання з експлуатації та супроводу софту, зробити ці процеси легкими та невимушеними – як для фахівців, які займаються впровадженням, так і для розробників. Але як можна наблизитися до цієї мети? Як створити платформу для запуску софту, яка потребує мінімального втручання? Що взагалі означає NoOps у цьому контексті?
Якщо постаратися абстрагуватися, то для розробників поняття "serverless" або "NoOps" означають інструменти та сервіси, що дозволяють сховати "експлуатаційну" складову або мінімізувати цей тягар для розробника.
- Працюйте не із системами, а з прикладними інтерфейсами (API).
- Не займайтеся використанням софту – нехай замість вас цим займається провайдер.
- Не слід братися відразу за створення великого фреймворку – почніть з написання невеликих фрагментів, які виступатимуть у ролі «будівельних блоків», намагайтеся, щоб цей код працював із даними та подіями, а не з дисками та базами даних.
Завдання, як і раніше, полягає в тому, щоб прискорити ітерації при розробці софту, забезпечити можливість створення більш якісних продуктів, і щоб при цьому розробник міг не переживати про системи, на яких запускається його софт. Досвідчений розробник чудово розуміє, що якщо зосередитися на користувачах, то картина може швидко змінитися, тому не слід вкладати надто багато зусиль у написання софту, якщо у вас немає абсолютної впевненості у його необхідності.
Для фахівців, зайнятих супроводом та експлуатацією, слово «NoOps» може звучати дещо страшно. Але під час спілкування з інженерами з експлуатації стає очевидним, що використовувані ними патерни та методики, спрямовані на забезпечення надійності безвідмовності (Site Reliability Engineering, SRE), багато в чому перегукуються з описаними вище патернами:
- Не керуйте системами – автоматизуйте процеси керування ними.
- Не займайтеся використанням програмного забезпечення – створюйте пайплайн для його розгортання.
- Намагайтеся не об'єднувати всі ваші сервіси разом і не допускати, щоб відмова одного з них призводила до відмови всієї системи – розосередьте їх по всій інфраструктурі, використовуючи засоби автоматизації, та з'єднуйте їх, передбачивши можливість контролю та спостереження.
Фахівці з SRE знають, що щось може піти не так, і їм доведеться відслідковувати та усувати проблему – тому вони автоматизують рутинну роботу та заздалегідь визначаються з допустимими відхиленнями (error budgets), щоб бути готовими до розміщення пріоритетів та прийняття рішень у разі виникнення проблеми. .
Kubernetes у OpenShift – це платформа, покликана вирішити дві основні завдання: замість того, щоб змушувати вас розбиратися з віртуальними машинами або API-інтерфейсами балансувальників навантаження, ведеться робота з абстракціями вищого порядку – з процесами розгортання та сервісами. Замість встановлення софтверних агентів можна запустити контейнери, а замість написання власного стека моніторингу використовувати вже доступні у платформі інструменти. Таким чином, секретний інгредієнт OpenShift 4 насправді не представляє жодної таємниці – потрібно просто взяти за основу принципи SRE та безсерверні концепції, та довести їх до логічного завершення, на допомогу розробникам та інженерам з експлуатації:
- Автоматизувати та стандартизувати інфраструктуру, яка використовується додатками
- Поєднати разом процеси розгортання та розробки, не обмежуючи при цьому самих розробників
- Досягти того, щоб запуск, аудит і забезпечення безпеки сотого сервісу, функції, програми або цілого стека були не складнішими, ніж першого.
Але в чому полягає відмінність платформи OpenShift 4 від її попередниць і від «стандартного» підходу до вирішення подібних проблем? За рахунок чого досягається масштабування для команд, які займаються використанням та експлуатацією? За рахунок того, що король у цій ситуації кластер. Отже,
- Робимо так, щоб призначення кластерів було зрозумілим (Дорога хмара, цей кластер я підняв тому, що зміг)
- Машини та операційні системи існують для того, щоб обслуговувати кластер (Ваша Величність)
- Керуйте станом хостів із кластера, мінімізуйте їх перебудову (drift).
- Для кожного важливого елемента системи необхідна нянька (механізм), яка відстежуватиме та усуватиме проблеми
- Збій кожного аспекту або елемента системи відповідні механізми відновлення - це звичайна частина життя
- Вся інфраструктура має конфігуруватися за допомогою API.
- Використовуйте Kubernetes для запуску Kubernetes. (Так-так, це не друкарська помилка)
- Оновлення повинні встановлюватися легко та невимушено. Якщо для встановлення оновлення потрібно більше одного кліка миші, то, очевидно, вими робимо щось не так.
- Моніторинг та налагодження будь-якого компонента не повинно складати проблеми, і, відповідно, відстеження та складання звіту по всій інфраструктурі також має бути простим та зручним.
Бажаєте побачити можливості платформи у справі?
Попередня версія OpenShift 4 стала доступною для розробників. За допомогою простого у використанні інсталятора можна запустити кластер на AWS поверх Red Had CoreOS. Щоб скористатися попередньою версією, потрібний лише обліковий запис AWS для надання інфраструктури та набір облікових записів для доступу до образів попередньої версії.
- Щоб розпочати роботу, перейдіть на та натисніть “Get Started”.
- Увійдіть у свій обліковий запис Red Hat (або створіть новий) і дотримуйтесь інструкцій, щоб налаштувати ваш перший кластер.
Після успішної установки, ознайомтеся з нашими навчальними матеріалами , щоб отримати більш детальне уявлення про системи та концепції, які роблять платформу OpenShift 4 настільки простим та зручним інструментом для запуску Kubernetes.
Спробуйте новий реліз OpenShift та поділіться своєю думкою. Ми прагнемо зробити роботу з Kumbernetes максимально доступною і не вимагає зусиль – майбутнє NoOps починається вже сьогодні.
А тепер увага!
На конференції 20 квітня один із розробників OpenShift, Вадим Рутковський проведе майстер клас — зламає десять кластерів і змусить лагодити. Конфа платна, але за промокодом #RedHat знижка 37%
Майстер клас о 17:15 – 18:15, а стенд працює весь день. Футболки, капелюхи, наклейки - як завжди!
Зал #2
«Тут всю систему міняти треба: лагодимо зламані k8s кластери разом із сертифікованими слюсарями».
Джерело: habr.com