10 інструментів DevOps, про які варто знати у 2024 році

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

Привіт! Я — Андрій Лазуркевич, DevOps Engineer у CHI Software. У цій статті хочу поділитися власними думками та рекомендаціями щодо технологій, які слід знати DevOps-спеціалісту у 2024 році.

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

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

1. Chaos Engineering Tools

Методика Chaos Engineering стала необхідною складовою для забезпечення стійкості та надійності систем. Її суть у тому, щоб перевіряти середовище шляхом контрольованих експериментів, які імітують реальні сценарії відмови системи. Таким чином можна виявити й усунути вразливості та потенційні проблеми ще до того, як вони стались, а значить — уникнути серйозних наслідків та збитків.

З власного досвіду можу зазначити, що доцільною практикою буде запровадження регулярних аудитів із застосуванням Chaos Engineering. Звісно, сьогодні вже створено досить багато інструментів для проведення таких тестів, тому кожен може обрати те, що підходить конкретно під його потреби. Я пропоную найбільш популярні, на мій погляд, приклади:

  1. ChaosIQ дозволяє інженерам здійснювати контрольовані експерименти на різноманітних платформах, включаючи найпопулярніші клауд-провайдери та K8s, щоб перевірити стійкість системи до різних видів збоїв. Також є можливість інтегрувати його в популярні CI/CD-провайдери: Jenkins, Travis, CircleCI чи GitHub Action.
  2. Gremlin також допомагає розробникам створювати та виконувати тести на стійкість у реальних умовах.

2. GitOps Tools

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

GitOps — це набір принципів та практик, які допоможуть вам вивести процес автоматичного деплою на новий рівень. Досягається це шляхом зберігання актуального стану середовища (K8s) у Git, а також безперервної синхронізації Git та робочого середовища. Найчастіше для цього використовують такі інструменти:

  1. FluxCD дозволяє описувати стан інфраструктури в Git та автоматично синхронізувати її з фактичним станом.
  2. ArgoCD надає можливості контролю версій та автоматичного розгортання додатків на інфраструктурі Kubernetes.

3. Kubernetes Security Tools

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

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

  1. Falco — система виявлення загроз, спеціально розроблена для контейнерних середовищ, яка може виявляти аномальну діяльність та безпекові інциденти в реальному часі.
  2. Aqua Security допомагає забезпечити дотримання стандартів безпеки та регуляторних вимог.

4. Serverless Monitoring and Debugging Tools

Пропоную для початку окреслити поняття serverless. Що це і навіщо його використовують?

Serverless — це функція, яку зазвичай надають клауд-провайдери. Завдяки їй вам більше не потрібно запускати власні потужності (сервери) або використовувати сервери клауд-провайдера напряму (EC2 instances). Замість цього є можливість користуватися сервісами на основі serverless.

Наприклад, використовуючи AWS Fargate замість AWS ECS, не потрібно думати про те, на яких серверах розміщувати контейнери. Цим замість вас буде займатись AWS (або інша клауд-платформа).

Тобто AWS буде розміщувати потужності на власних серверах і самостійно займатиметься їх підтримкою, що забирає у вас частину обов’язків, а також дає можливість оплачувати послуги за схемою pay-as-you-go.

З використанням serverless зросла потреба в додаткових інструментах, які дозволяють виявляти й розв’язувати проблеми продуктивності та недоліки serverless-based-застосунків:

  1. AWS X-Ray моніторить ПЗ, що працює на AWS, у тому числі serverless-додатки.
  2. Datadog Serverless надає розширені інструменти моніторингу та аналізу serverless-рішень.

5. Continuous Compliance Tools

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

Для автоматизації ми можемо використовувати інструменти, попередньо налаштовані саме під наші вимоги, а також імплементувати ці інструменти в CI/CD таким чином, що код інфраструктури (це найбільш актуально для DevOps-інженерів) буде перевірятись автоматично кожного разу після змін чи доповнень.

Тож за виявлення певних невідповідностей правилам безпеки, ми зможемо вчасно виявити проблему та не допустити її проникнення в робоче середовище.

Нижче наведу приклад кількох інструментів, які допоможуть вам у роботі з вимогами та стандартами:

  1. Terraform Compliance дозволяє вам перевіряти інфраструктурні конфігурації на відповідність внутрішнім правилам безпеки та стандартам регуляторів.
  2. Chef Compliance так само надає можливості автоматизованої перевірки відповідності вашої інфраструктури до стандартів безпеки та політик організації.

6. Observability Platforms

Моніторинг систем — тема всім відома, проте, на мою думку, її актуальність та важливість неможливо переоцінити. Моніторингові сервіси забезпечують збір, журналювання та візуалізацію метрик для всіх складових програмного забезпечення. Нижче наведу кілька прикладів популярних моніторингових рішень:

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

7. AI/ML Ops Tools

З мого досвіду, останнім часом зросла потреба в інструментах, спеціально розроблених для управління моделями машинного навчання (Machine Learning, або ML) та їх впровадження в прод-середовище. Інструменти AI/ML Ops допомагають автоматизувати процеси навчання моделі, експериментування та моніторингу. Серед найкращих такі:

  1. MLflow — опенсорс-інструмент для управління процесом розробки моделей машинного навчання від початкового етапу до впровадження в продукт.
  2. Kubeflow — це опенсорс-платформа для розробки, навчання та впровадження моделей машинного навчання на Kubernetes.

8. Infrastructure as Code Security

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

Більшість клауд-проєктів вимагають від DevOps-інженерів описувати інфраструктуру у вигляді коду. Так, я вважаю цю практику доцільною та навіть обов’язковою, але код інфраструктури важко назвати якісним, якщо він не враховує security best practices. Ось тут і знадобляться вам інструменти безпеки інфраструктури як коду.

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

Додатково ви можете використовувати, до прикладу, ПЗ для вираховування приблизної ціни інфраструктури або для перевірки щодо відповідності певним нормам, про які я вже згадував у цій статті.

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

Приклади інструментів на цей раз включають:

  1. Checkov аналізує шаблони інфраструктури (наприклад, Terraform або CloudFormation) на предмет потенційних проблем безпеки та надає рекомендації щодо їх виправлення.
  2. TerraScan — окремий інструмент безпеки для Terraform зі схожим набором функцій.

9. Service Mesh Tools

Service Mesh надає додатковий рівень управління мережевою взаємодією між сервісами в мікросервісних архітектурах, допомагаючи покращити безпеку, спостережуваність та управління трафіком між сервісами.

З популярних прикладів використання Service Mesh-систем можу зазначити реалізацію canary deployment у Kubernetes. А щодо конкретних рішень, рекомендую наступні:

  1. Istio забезпечує управління трафіком, спостережуваність, безпеку та інші функції для мікросервісних архітектур.
  2. Linkerd забезпечує низьку затримку та високу продуктивність для управління мережевою взаємодією між сервісами.

10. Automated Incident Response Tools

Автоматизовані інструменти для відповіді на інциденти допомагають командам швидко реагувати на безпекові проблеми або збої в системі.

Пропоную розібрати кейс, коли вам потрібно зреагувати на інцидент — наприклад, відмову якогось вебсайту. На реакцію у вас є до 10 хвилин, незалежно від дня та часу доби, тобто треба бути напоготові 24/7. У такому випадку вам потрібно налаштувати якусь автоматизовану систему, яка сповіщатиме певних користувачів про виникнення проблеми.

Інструменти PagerDuty та Opsgenie можуть допомогти з цілодобовим моніторингом — вони очікуватимуть на певну подію/тригер і повідомлятимуть про інцидент у зручний вам спосіб, наприклад, за допомогою SMS або повідомлення у Slack. Також, якщо вам потрібно розширити логіку таких процесів, ви можете використовувати інструменти workflow automation, наприклад, n8n.

Висновок

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

Через високу конкуренцію на ринку програмного забезпечення якість розробки стає на перший план. А разом із цим удосконалюється й DevOps-інструментарій. Я, наприклад, слідуючи цим порадам зміг «підкорити» майже всі інструменти з перелічених за короткий час та стати більш цінним співробітником.

Сподіваюся, ця стаття бодай трохи розширить ваш професійний арсенал, а ще — надихне на навчання.

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

За статтю дякую, от ще б готовий набір навчальних матеріалів по тулах цих :) Бо наприклад ArgoCD — у них я так бачу «сучансий підхід» як і у ElasticSearch де від 1 до 7 версії софт просто перетворився в якийсь дикий мультітул, перш ніж почати проацювати з ним потрібно багато шаманства дізнатись та наук. Час від часу будуть ламатись мізки коли пишеш конфіг і зтикажешся з «namesapace» і не відразу зрозуміло це про кубік неймспейс чи якийсь інший. не очевидно як запустити один Арго на 5 неймспейсів в одному калстері, розподіл прав теж чесно кажучи можна мізки зломати, оновлення версії потрібно робити обережно бо може так статись що потрібно патчити, чистити конфігмапи — бо вирішили певні розділи конфігів винести в окрмесі сервіси як то applications...

PS чи то я постарів, чи то софт реально пишуть і роблять абізяни... Раніше у мене не викликало стільки часі і болю розібратись з +1 технологією щоб вона працювала адекватно.

Може ви до ArgoCD не з тієї сторони підійшли? Як на мене досить непогана тулза. Не ідеальна, але працює. Чи може то, тому що я не намагаюся юзати її як швейцарський ніж. Кожного дня щось там правити необхідності нема, тож заморочуватися з конфігами теж. Раз на місяць відкрив веб-інтерфейс — зробив, що потрібно і закрив. А всі конфіги регулярно і автоматично бекапляться до S3. Загалом документація у них не найгірша. Погано, коли замість доків змушений читати код та коменти на гітхабі, щоб зрозуміти, як воно працює. Такі продукти краще за можливості оминати.

Може ви до ArgoCD не з тієї сторони підійшли?

Хто зна щодо сторін, документації. Все воно є — але часто густо не очевидне і витрачаєш час на тести, налагодження, знаходження рішення...
Оно по дефолту наче просто, але при підключенні типу gitlab через dex + групи + ролі для девів і тестерів — дещо нервує поки розберешся. Так само коли випиляли additionalApplications — трохи крові попили поки дотягнув до 5.0.0 весрії чарту, та об’єднання однії Арго на декілька неймспейсів — тут чесно кажучи не все ще попиляв бо багато нюансів в роботі проекту. Загалом так — норм тула якщо не дуже її кошмарити під потреби менеджменту.

Дякую за коментар. Метою статті скоріше було дати такий собі набір цікавих практик і тулів,тому в статтю не вийшло вмістити більш детального розбору цих інструментів, деякі з них це взагалі тема для окремої статті :D

деякі з них це взагалі тема для окремої статті

я б сказав окремих книжок, курсів...

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

Додайте сюди New Relic та Dynatrace

Дякую, тули в статті це просто приклади, звісно тулів на кожен пункт можна назбирати дуже багато і під різні проекти краще підійдуть різні інструменти, на жаль всіх їх не вийде додати, тому що стаття перетвориться на «кілометровий» список інструментів)

Чекаємо на другу частину :) І на третю потім...

Чи використовуєте ви snyk для аналізу вразливостей коду залежностей? Якщо — так, то чи склалось якесь враження?

На жаль, не було нагоди попрацювати з цим інструментом.

Підписатись на коментарі