Тренди DevOps — що треба знати і вміти інженеру в 2022 році

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Ігор Канівець. Я працюю на позиції Advanced DevOps в Innovecs. Хочу поділитися своїм досвідом і розповісти про роль DevOps-інженерів, їхні обов’язки, можливості росту, набір важливих soft & hard skills, а також найголовніше — тренди DevOps у 2022 році. Статтю почав писати ще до війни, а у воєнний час актуалізував.

Як тоді, так і зараз потреба в DevOps-інженерах зростає, і фахових спеціалістів не так легко знайти. Щоб освоїти цю сферу, треба постійно вчитися. Сьогодні поділюся своїми знаннями, які, сподіваюся, будуть корисними і потрібними для тих, хто працює або прагне розвиватися у цьому напрямку.

Основне завдання DevOps — максимально збільшити передбачуваність, ефективність і безпеку розробки програмного забезпечення. Методологія (development + operations) зародилася ще 2009 року задля налагодження взаємодії між програмістами й системними адміністраторами, щоб збільшити частоту випуску релізів. По суті, DevOps engineer працює на перетині цих двох професій і займається автоматизацією. Він залучений на етапі розробки, тестування та випуску релізу.

До його основних обов’язків входить розгортання релізу в продакшн, інтеграція й заглиблення процесів розробки і постачання, стандартизація процесів розробки, налаштування інфраструктури відповідно до вимог програмного забезпечення, автоматизація процесів. Звичайно, найбільше навантаження лягає на плечі DevOps-інженера під час підготовки інфраструктури для аплікації, а також налаштування CI/CD процесу, який потім працює в автоматичному режимі. У роботі DevOps використовує різні засоби управління конфігураціями, віртуалізації та автоматизації операційних процесів, використання хмарних технологій. Щоб встигати за стрімким розвитком технологій, йому треба постійно вчитися, бути цілеспрямованим і посидючим.

Тож розкрию кілька важливих трендів, якими однозначно повинен володіти DevOps у 2022 році.

Terraform

Terraform — це інструмент від компанії Hashicorp, який допомагає декларативно керувати інфраструктурою. Завдяки цій технології не доводиться вручну створювати інстанси, мережі тощо в консолі хмарного провайдера, а достатньо написати конфігурацію, у якій буде викладено, як ви бачите майбутню інфраструктуру. Така конфігурація створюється у текстовому форматі. Якщо ви хочете змінити інфраструктуру, тоді редагуєте конфігурацію і запускаєте terraform apply. Terraform спрямує запити API до вашого хмарного провайдера згідно з конфігурацією, яка вказана у файлі.

Уявімо, що у нас є інфраструктура з 1000 комп’ютерів у cloud. Комп’ютери з’єднані за допомогою певного мережевого обладнання. Ці 1000 штук комп’ютерів можна розвернути за допомогою однієї команди terraform apply, попередньо переглянувши план (terraform plan). Приблизно 10 хвилин від старту до фінішу, й інфраструктура підніметься.

Припустимо, що ми хочемо створити вебсервер, який при запиті www.arizon.page повинен видати нам стартову сторінку. Процес створення інфраструктури (розгорнути інстанс, встановити вебсервер, налаштувати вебсервер) може зайняти до 3-5 хвилин, і ми отримаємо вже готову інфраструктуру з усім функціоналом і двигунами.

З Terraform може працювати як одна людина, так і декілька. Як правило, розробка ведеться групою людей. Один працює над однією фічею, інший — над іншою і так далі. Коли надходить час деплоїти, ми користуємося командою terraform apply.

Завдяки lock механізму у той час, коли один з тіммейтів розгортає свою частину інфраструктури, ніхто інший цього зробити не може. Lock механізм працює з tf.state файлом, який зберігається віддалено (aws s3 bucket чи щось подібне). Якщо не використовувати віддалений tf.state файл і все робити локально, то ваші тіммейти не будуть знати про зміни, які ви зробили в хмарі і можуть просто видалити/ змінити їх. Коли ж усі працюють з одним і тим же tf.state файлом, то у всієї команди буде актуальний стан інфраструктури. Коли хтось із команди деплоїть, усім іншим висвітлюється індикатор, що деплоїти не можна, оскільки з цим працює інша людина. Коли процес деплойменту завершився, Terraform автоматично налаштовує unlock й інші вже можуть працювати.

Технологія постійно розвивається, доповнюється фічами й модулями, стає цікавішою та складнішою у плані архітектури. Terraform в інструментарії DevOps engineer — це must have.

На жаль, не всі покривають інфраструктуру кодом і цим самим наражають себе на небезпеку. Так, у ситуації фейлу системи саме DevOps опиняється в «центрі пожежі». Усе переходить у статус downtime — зупиняється нетворкінг, інстанси, на яких раняться вебсервери, і, як результат, втрачаються гроші. Тоді й усвідомлюєш, наскільки важливим є покриття інфраструктури кодом.

За допомогою двох команд terraform plan/ terraform apply, інфраструктура буде повернута до початкового робочого стану за лічені хвилини, в той час, коли дебаггінг може тривати години. Перша команда (terraform plan) покаже зміни, які були зроблені в інфраструктурі, друга ж (terraform apply) зробить ті зміни, які видала перша команда. У цьому вся сила Terraform (Infrastructure as code). Є й інші технології, які покривають інфраструктуру кодом такі, як: Cloud Formation в AWS, Pullumi у роботі з Python та інші. Основне правило — інфраструктура має бути покрита кодом. На випадок мануальних змін Terraform покаже, до якого стану треба повернути код. Але мануальних змін треба уникати та правити все безпосередньо в Terraform, тому що для цього він і розроблений.

Cloud Technologies

Ще одна трендова технологія в інструментарії DevOps — це Cloud Technologies, яка забезпечує швидкий доступ через мережу до системи комп’ютерних ресурсів, зокрема cloud storage, database в тому обсязі та на той проміжок часу, який потрібен саме для ваших потреб.

Частина компаній не довіряє свою конфіденційну інформацію AWS, Google Cloud чи Azure. Вони все зберігають локально і самостійно обслуговують свої сервери. Але якщо в силу неприємних обставин у них вилучать hardware, на якому енвайронмент, який раниться і приносить гроші, вони опиняються у статусі downtime, і це треба мати на увазі. Можливо, деякі компанії не мають права використовувати хмарні технології, до прикладу, державні компанії, але це вже інша історія.

Хмарні технології вигідні і з точки зору заощадження коштів за оренду приміщення, у якому довелося б зберігати комп’ютери, кошти на електроенергію і заробітну плату персоналу та інше. При використанні хмарних ресурсів ми платимо тільки за те, чим користуємося. Якщо вам потрібен інстанс певної потужності на тривалий проміжок часу (пів року, рік, два тощо), ви також можете зекономити кошти. Що більш тривалий проміжок часу — то більша знижка.

AWS і різні хмарні сховища дуже ефективні з точки зору гнучкості. Вони можуть автоматично додати потужності у момент пікових навантажень.

Так, змоделюємо ситуацію, коли під час Black Friday відбувається пікове навантаження на сервер. Вночі може працювати 15-20 серверів, а зранку коли трафік зменшується, кількість серверів скорочується до 4-х.

Таким чином завдяки хмарним сховищам не доведеться переплачувати за додаткові потужності, коли пікове навантаження завершується. Оплачується робота оптимальної кількості серверів, які обслуговують usual traffic.

Docker

Docker — один з найбільш відомих інструментів у роботі з контейнерами. Ця технологія дозволяє за лічені хвилини підняти робочий застосунок. І нам більше не потрібно створювати віртуальну машину, встановлювати на неї операційну систему, а на операційну систему встановлювати необхідні компоненти для роботи застосунку. На цей час усе, що нам потрібно, — це Dockerfile (інструкція для запуску застосунку всередині контейнера), у якому ми вказуємо, який образ (docker image) нам треба використовувати, які додаткові компоненти для застосунку необхідні тощо.

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

За допомогою Docker-контейнера, як розробник, так і тестувальник може швидко протестувати код локально. Оскільки Docker у всіх однаковий, ми можемо бути впевнені у тому, що застосунок працюватиме однаково, як на стороні розробника і тестувальника, так і на стороні клієнта.

Часто буває так, що на стороні розробника все працює, але коли застосунок потрапляє до тестувальників — працює вже не зовсім коректно, оскільки середовища відрізняються (різні версії встановлених пакетів тощо). Щоб зберегти цінний час і уникнути перекидання тікетів між розробниками та тестувальниками — Docker незамінний.

Kubernetes

Kubernetes — це адміністратор Docker-контейнерів, або довершена система оркестрації контейнерів. Це розробка Google, створена як рішення з відкритим вихідним кодом для автоматичного розгортання, масштабування й управління контейнеризованими застосунками. Останнім часом більшість додатків розробляються як мікросервіси, які функціонують на рівні контейнера.

Контейнерні технології допомагають у щоденному оновленні додатків для підтримки безперебійної роботи сервісу 24/7. Kubernetes є рішенням, яке дозволяє застосункам оновлюватися і працювати у будь-який час і в будь-якому місці завдяки оркестрації контейнерів.

Уявімо, що вебсайт розміщений на одному контейнері. Kubernetes стежить за тим, щоб контейнер ранився. Якщо Docker-контейнер з якоїсь причини «впаде», Kubernetes створить такий же новий робочий контейнер за певним шаблоном, але в такому випадку буде певний downtime статус. Тому рекомендовано одночасно ранити щонайменше два контейнери, які виконують ідентичні функції. У такому випадку, якщо один контейнер впаде, то буде доступний інший, доки буде розгортатися другий — так ми уникаємо статусу downtime. Таким чином Kubernetes може стежити за сотнями сервісів, які раняться одночасно. Kubernetes як восьминіг — з одним центром і багатьма щупальцями-сервісами.

Підсумовуючи, можна виділити кілька переваг Kubernetes: 1) легке масштабування контейнерних застосунків; 2) легка міграція — дуже легко перенести контейнерні застосунки з локальних машин у хмарне сховище для подальшого розгортання; 3) самоуправління — контейнери перезавантажуються, змінюються чи знищуються автоматично; 4) безпечне розгортання — Kubernetes автоматично оновлює додатки, аналізуючи їхній стан.

Знання GoLang або Python

Не існує стандартного набору технологій, якими повинен володіти DevOps інженер, але одну із мов програмування він таки повинен знати. Поставлену задачу можна вирішити кількома способами — C++, Python, Java. Знання хоча б однієї мови програмування є умовою виконання поставленої задачі. У 2022 році особливої популярності у роботі DevOps інженера набирає мова програмування GoLang.

GoLang — мова програмування, яку розробив Google і яка стає популярною технологією. У 2019 році вона потрапила до списку мов, які найшвидше розвиваються. Згідно з даними StackOverflow у 2022, Go на 14-му місці у світовому рейтингу популярних мов і на 10-му місці серед українських програмістів згідно з опитуванням DOU.

Go має багато бібліотек, які працюють з певним застосунком. До прикладу, можна викликати бібліотеку, яка буде працювати з Amazon. З допомогою написаної на GoLang програми можна вимкнути усі сервіси на Amazon аккаунті, які не відповідають поточному стану (звичайно, якщо у вас достатньо прав на це). Як ми вже говорили раніше, це можна зробити також за допомогою іншої мови програмування, наприклад, Python.

Освоївши одну з технологій, можна переходити до вивчення іншої. Важливо розуміти логіку технології, а синтаксис вивчати поступово.

Jenkins / GithubActions

Jenkins — це дуже гнучка система, написана на Java і дозволяє реалізувати процес безперервної інтеграції та розгортання будь-якого рівня складності. З його допомогою можна протестувати код і виявити можливі помилки.

Пайплайн налаштовується у декларативному або скриптовому стилі на мові Groovy, а файл конфігурації (Jenkinsfile) знаходиться у системі контролю версій разом з вихідним кодом.

Jenkins налаштовується на задачі, які потрібні розробникам й тестувальникам. Для цього треба відкрити UI Jenkins — там є список job. Ми обираємо потрібне завдання, виставляємо параметри та натискаємо run. Після цього Jenkins скеровується у Github (сховище, у яке розробник запушив свій код), стягує код і починає білдити. Якщо у процесі Jenkins виявляє помилку в синтаксисі, розробник може подивитись Jenkins Console чи отримати повідомлення у месенджер, що щось пішло не так, виправити помилку, запушити новий код, натиснути build та перевірити результат роботи Jenkins. Є багато різних плагінів для Jenkins, які допомагають з тим чи іншим функціоналом. Один з них — GitHub plugin за допомогою якого Jenkins Job може бути запущена після того, як код потрапив до тієї чи іншої GitHub бранчі.

Підсумовуючи, можна виділити кілька важливих характеристик Jenkins.

• Безперервна інтеграція та безперервна доставка. Jenkins можна використовувати як простий сервер CI або перетворити на центр безперервної доставки для будь-якого проєкту.
• Легка інсталяція. Jenkins — це автономна програма на основі Java, готова до запуску «з коробки» з пакетами для Linux, macOS та інших Unix-подібних операційних систем. Також Jenkins може бути запущений у Docker-контейнерi.
• Плагіни. Завдяки сотням плагінів Jenkins інтегрується практично з кожним інструментом у ланцюзі інструментів безперервної інтеграції та доставки.
• Простота дистрибуції. Jenkins може легко розподіляти роботу між кількома машинами, допомагаючи швидше створювати, тестувати та розгортати на кількох платформах.
• Фінансова сторона. Jenkins — це безплатне програмне забезпечення, але недоліком є відсутність техпідтримки.

Аналогом Jenkins є GithubActions, яка є продуктом GitHub і розроблена лише рік-два тому. З допомогою GitHub actions можна стартувати білди відразу в ґіті. Перевага і зручність у тому, що вам не потрібне обладнання і його обслуговування, щоб запускати білди. Ви можете налаштувати запуск білда за тригером (git tag, create pull request, push у визначену гілку і так далі). Інструкції для GitHub пишуться у форматі .yml.

Terminal

Сучасному DevOps, як і системному адміністратору необхідно знати командний рядок, тому що основна частина систем — це Linux.

Усі команди запам’ятати неможливо, але важливо знати певний алгоритм дій. Припустимо, у файлі треба змінити firewall rule. При відкритті документа з’явиться полотно різних rules в IP table. Якщо їх кількість налічує до 500, продивлятися вручну незручно, треба створити пайплайн з команд, котрі зроблять необхідні зміни.

Навіть якщо ви працюєте в системі Windows, там також може статися збій і перед очима з’явиться чорний екран з текстом. Щоб пофіксити ситуацію, треба переглянути логи, а це можна зробити, скориставшись визначеними командами або текстовим редактором у Terminal.

Linux-based

DevOps інженер повинен орієнтуватися в Linux-системах, як риба у воді.

Linux-based зручні тим, що для їхньої роботи не потрібна графічна оболонка, яка забирає ресурси. Для роботи у Linux-based системі достатньо командного рядка, за допомогою якого виконуються всі маніпуляції у системі.

Рано чи пізно доводиться з’ясовувати, чому не працює та чи інша служба. Для цього треба вибудовувати чіткий ланцюг дебагінг-процесу. Якщо не стартує служба — треба переглянути логи, і якщо в логах ви бачите помилки, які потребують певних дій — виконати їх, і так далі. Щоб виконувати поставлені задачі, треба визначений багаж знань і досвід, який напрацьовується на практиці. Якщо ви сьогодні зіткнулися з певною проблемою, на вирішення можете витратити 2 години — це нормально, але завтра ви вже справитеся за 2 хвилини. З таким підходом і напрацьовуються навички. І так не лише з Linux-системами, так виглядає процес будь-якої практики.

Bash Scripting

Одна з ролей DevOps-інженера — це автоматизація. Якщо якусь дію потрібно робити кілька разів, значить, процес потребує автоматизації.

Bash scripting — це сценарій командного рядка, написаний для оболонки bash, потужний спосіб автоматизації дій, які часто виконуються.

Сценарії командного рядка — це набори тих же команд, які можна вводити з клавіатури, зібрані у файли й об’єднані спільною ціллю. Результати роботи команд можуть служити вхідними даними для інших команд.

Наприклад, якщо доводиться кілька разів у різних місцях створювати теку з файлом і поточною датою, можна написати скрипт у текстовому редакторі, котрий це зробить автоматично. Спочатку прописуються дії в певному порядку, які б виконувалися в Terminal, після чого файл зберігається з розширенням sh. Для запуску скрипта необхідно виконати команду sh script.sh

Скриптинг — це дуже зручно, але все ж треба пам’ятати, що це машина, яка може як створювати, так і редагувати й видаляти. Тому якщо використовуєте скрипти для видалення, то краще витратити час на тестування і бути впевненим, що буде видалена лише та інформація, яку і планували видалити, а не інша. Таким чином уникнути небажаної втрати важливої інформації, що призведе до неприємних наслідків.

BackUps

Як відомо, якщо ви володієте інформацією, значить, володієте грошима. Якщо інформація буде втрачена — гроші також. Виходячи з цього, дуже важливим фактором доступу й цілісності інформації є бекапи.

Оскільки з даними працюють люди, то діє людський фактор. Інколи непорозуміння між людьми чи недостатньо протестований код може з легкістю стерти інформацію. На випадок таких ситуацій треба мати бекапи. Так, можливо, у вас не буде найсвіжішої інформації, але краще мати інформацію до вчорашнього дня і не мати за останній день, ніж не мати даних взагалі.

Monitoring

Моніторинг — це гарантія того, що ваша система працює, як належить, і всі операції виконуються коректно. Якщо раптом щось йде не так — моніторинг знатиме про це першим і сповістить у зручний для вас спосіб. Відтак, можна бути впевненим, що все гаразд до того моменту, поки немає відповідних сповіщень. Завдяки моніторингу downtime статус можна скоротити в рази, оскільки сповіщення надходить за лічені секунди після того, як це стається.

Вимоги до soft & hard skills DevОps-інженера

Оскільки DevОps-інженер працює на перетині між розробниками, тестувальниками й операційною командою, йому варто розвивати як hard skills, так і soft skills. Є кілька важливих порад, які можна взяти до уваги.

• Розвивати гнучкість у роботі з командою. Серед важливих soft skills — ефективна комунікація, терпіння, гнучкість, відповідальність, стресостійкість і вміння знайти підхід до різного спеціаліста. Саме гнучкість є однією із найбільш важливих якостей. Не завжди програмісти відповідають на запит, і часто доводиться чекати або нагадувати по кілька разів. Важливо не панікувати, а підлаштовуватися до команди.

• Уважність на етапі продакшну. DevOps-інженеру варто багато вчитися, а під час навчання ніхто не застрахований від помилок. Недопустимо помилятися на етапі продакшну. Якщо немає можливості протестувати продукт локально, то можна на платній основі створити свій AWS-акаунт, де ви можете робити все, що заманеться. На dev можна експериментувати й тестувати, а на продакшені — ні в якому випадку.

• На перших етапах важливо багато практикуватися. Молодому DevOps-інженеру важлива не лише теорія, але і практика. Перед деплойментом коду варто перевірити кілька разів і впевнитися, що після натискання enter все піде за планом. Без перевірки можна допуститися фатальних помилок, які потім негативно відбиваються на кар’єрі DevOps-спеціаліста.

• Перш ніж видаляти щось — перепитай. DevOps-інженер має широкий спектр повноважень. Він має права, яких не мають розробники. До прикладу, видалити цілу базу. Перш ніж щось видаляти, варто уточнювати та перепитувати в колег, щоб не зробити фатальний delete. У цій роботі важливо мати аналітичний склад розуму і розвивати стресостійкість. Ніколи не здаватися навіть, якщо все йде не так, як запланував.

• Важливо мати хорошого ментора і багато вчитися. Найкраще, коли є можливість вчитися у більш досвідченого DevOps-інженера. Свого часу я працював з хорошим ментором, який ставив переді мною задачі, допоміг засвоїти певні технології, перевіряв виконані завдання і давав поради щодо росту. Окрім ментора, можна також проходити навчальні курси. Важливо постійно освоювати нові технології, багато вчитися і стежити за трендами. Свого часу мені «давали вудочку, а не рибу». Зіткнувшись з певною задачею, я спочатку гуглив документацію, шукав відповіді, а якщо таки не вдавалося зробити щось самостійно — звертався до ментора, який завжди міг спрямувати.

• Можливі шляхи розвитку DevОps-інженера. Більшість DevOps-інженерів — це у минулому системні адміністратори, які вивчили інструменти програмування, або ж розробники, які більш глибоко вдалися в операційні процеси. У будь-якому випадку треба мати базову технічну освіту і розумітися у питаннях, пов’язаних із системним адмініструванням і автоматизацією різних задач. У кар’єрному розвитку, як і будь-який інженер, DevOps проходить рівні — junior, middle, senior, lead.

Незалежно від обраного вектора розвитку, кожному DevOps-інженеру у 2022 році треба освоїти важливе правило Life-Long Learning. Що більше технологій знаєш — тим більш популярним фахівцем на ринку стаєш.