Вхід і реєстрація
Розробка · 9 листопада 2023, 16:00 1259
Stanislav Hordiyenko, ДевОпс Інженер

Що краще: Crossplane чи Terraform?

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

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

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

Дякую.

Теми: Crossplane, DevOps, Terraform
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Yurii Rochniak SRE в Preply 09.11.2023 17:45

Якось тикав Crossplane заради спортивного інтересу. Сподобалось те, як там можна організовувати колекції. А також те, що багато чого з інфрастурктури можна абстрагувати через Helm chart і віддати розробникам відносно простий API (через Helm Values).

Не сподобалось те, що тоді не було адекватного способу передавати назви ресурсів між конфігами. Типу як в Terraform можна робити `smth = my_resource.name.attribute`. Зараз, наче, додали таку можливість.

Для мене стопером (і великим консьорном) з приводу Crossplane є те, де зберігається стейт. Тобто ETCD. У мене, наприклад, Kubernetes кластери динамічні. Тобто зараз я досить мало парюсь стейтом. Якщо що — підніму новий кластер і Argo туди задеплоїть що треба. Що буде зі стейтом Crossplane, якщо ETCD похєриться? Ну тобто він пропаде. Але як буде реагувати на це Crossplane? Там є опція лишати ресурси в клауді як є, якщо видално маніфест, але як тоді видаляти ті ресурси (там можна докинути імперативної логіки, але то вже не Kubernetes-way).

Terraform у свою чергу дозволяє зберігати стейт багато де. Це просто великий JSON. Це просто, як тапок. Відповідно я можу просто зберігати той JSON у S3 і не паритись: довіряю інженерам Амазону більше, ніж собі, хехе.

Ще буває люди кажуть, мол, Crossplane — торт, а Terraform — ні, бо там є нативний реконсиліейшн-луп. Але ви так само можете зробити реконсіліейшн ресурсів Terraform якоюсь додатковою автоматизацію — це супер-легко зробити.

Крч, Crossplane виглядає прикольно, але поки сумнівно. Хай стейт дозволять кудись поза кластером писати і тоді можна буде ще раз дивитись туди.

Відповісти
Підтримати
Gena Kartashevskyy Platform Engineer в MyHeritage 09.11.2023 18:35
віддати розробникам відносно простий API

Так це і в ТФ можна. Ми взагалі побудували self-service платформу на CDK TF + SpaceLift, девелопер створює умовний AWS ECS кластер в 10 строчок

Відповісти
Підтримати
Yurii Rochniak
Yurii Rochniak SRE в Preply 10.11.2023 12:31

Так, звичайно. Тому ще й від контексту залежить. Якщо у вас вже є такий self-service API на одній технології, не варто все це викидати тільки тому, що десь зʼявилась новіша альтернатива.

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

Відповісти
Підтримати
Gena Kartashevskyy
Stanislav Hordiyenko ДевОпс Інженер 10.11.2023 12:04

Якщо подивитись в код Crossplane, то вони використовують Terraform.

Відповісти
Підтримати
Yurii Rochniak
Yurii Rochniak SRE в Preply 10.11.2023 12:32

у провайдерах?
В код не дивився, але не здивуюсь: Terraform — це ж теж, по суті, тонка прослойка над провайдерами

Відповісти
Підтримати
Stanislav Hordiyenko
Stanislav Hordiyenko ДевОпс Інженер 10.11.2023 12:43

Так, у GCP провайдері.

Відповісти
Підтримати
Yurii Rochniak
Oleksandr Savchenko DevOps Engineer 09.11.2023 16:39

Крім очевидних плюсів у crossplane є трохи і мінусів:
Дещо перевантажений синтаксис. Оці довгі полотна ямлів з патчами читаются важко, а пишуться ще важче.
Відсутність циклів і кондишенів намагаються продати як фічу «it’s opinionated approach», але це таки мінус
Хто зна що робити зі стейтом і міграціями з кластера в кластер.
Хто зна що робити кейсами коли треба аналоги тераформ data source, бо все таки вимагати від юзера вказати всі вхідні дані коли в тераформі треба було лише невелику частину, а все інше можна витягти з дати — це не серйозно для відносно великих речей. Скажем так, для створення якогось VPC endpoint зовсім не обовʼязково створювати новий VPC, частіше хотілось би спитати в юзера існуючий VPC-id, а все інше як то субнети, таблиці маршрутизації і тд отримати з дата сорсів.

Тому crossplane річ гарна для якихось дуже типових, дуже гарно відтестованих ephemeral envs, але з тераформом воно перетинається не дуже сильно, а скоріше доповнює.

Відповісти
Підтримати
Stanislav Hordiyenko ДевОпс Інженер 10.11.2023 12:02

Колезі подобається використовувати Helm з Crossplane, а основна мотивація, що це все можна запускати в ArgoCD.

Відповісти
Підтримати
Oleksandr Savchenko
Олексій Хількевич 09.11.2023 16:25

Можу однозначно сказати що з двох TF краще, але відповідь не така проста як здається

З TF — ти можеш створити й менеджити інфраструктуру й фіксити drift просто з файлами. Навіть стейт можна на лептопі тримати

Crossplane апріорі вимагає install and customize Crossplane in an existing Kubernetes cluster

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

Інший схожий кейс такого типу — це менеджити кластер vmware використовуючи vcenter у віртуалці, яка живе на тому самому кластері.

Ще схожий кейс такого типу — системний апргейд роутера використовуючи комп з мережі яка роутиться через той роутер

Infrastructure as a code — має бути простим як дровеняка, настільки простим, що для нього за потреби досить лептопа й ВЖЕ викачаного коду. Бо можливості викачати код після запуску може просто не бути

Crossplane — ідея мені нра, і це просто була би шикарна штука, якби всі його компоненти можна було тримати на одному лептопі без k8s. А так ним треба користуватись тільки обережно.

Всерйоз я думаю от що краще за TF — це pulumi. З певним навиком до програмування абсолютно не проблема вигрібати yaml в стилі ресурсів k8s теж

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

Відповісти
Підтримати
Stanislav Hordiyenko ДевОпс Інженер 10.11.2023 11:55

На моє питання колезі, а як ми будемо запускати цей кластер та його конфігурувати, він відповів — ТФ :-)

Відповісти
Підтримати
Олексій Хількевич
Олексій Хількевич 10.11.2023 15:11

Ну до речі гарний вихід

Не обов’язково аористуватись чимось одним можна тф для бутстрапа окремо

Але тут тре все одно бути акуратним бо це ж не тільки кластера стосується, а й всіких vnet чи vpc, роутів, і прочої лабуди

Відповісти
Підтримати
Stanislav Hordiyenko
Stanislav Hordiyenko ДевОпс Інженер 10.11.2023 11:59

Стосовно Pulumi, цікава штука, але я більше скиляюсь до ТФ, так як в ньому ну дуже складно писати поганий код. А ось дай цю можливість писати на мовах программування, то все, хана. У нас одна команда розробників вирішила піти далі, та переписала пайплайн для ГітЛабу на джаваскріпт, динамічний пайплайн, в підтримці хана, скільки зайвого. Інколи здається, що люди ускладнюють речі, щоб їх неможливо було позбутись.

Відповісти
Підтримати
Олексій Хількевич
Mykola Gatilov Senior DevOps 10.11.2023 12:21

Я не робив великі проекти на Pulumi, але ось на terraform якраз роблю модулі під великі корпоративні проекти. І можу сказати що писати поганий код на terraform аж ніяк не складніше, ніж на будь-чому. ;( Більше того, сам по собі terraform доволі «кривий» як починаєш працювати з умовним виконанням, циклами та складними даними (коли з одного yaml треба витягнути дані на кілька об’єктів).

Інколи думаю «ось на Python це було-б пара стрічок, а тут...»

Відповісти
Підтримати
Stanislav Hordiyenko
Stanislav Hordiyenko ДевОпс Інженер 10.11.2023 12:31

Ось в цих пара рядків і є проблеми, бо кожний програміст бачить код по своєму, та стандарти краси різні.
Дуже стало цікаво, що за обʼєкт ви зберігаєте у yaml? Я також інколи використовую yaml, але це більше для конфігурації, щоб не робити багато змінних у головному коді.
Єдине на данний момент, що мені не подобається в Terraform, так це коли треба створити нетворк, запустити кубернет, та задеплоїти Ingress, External DNS та CertManager. І потім, якщо наприклад щось ломається в кубернеті, то вcе виконання падає, і не можна запустити банальний plan, бо Terraform не може зчитати данніе з кубернета. Це як на мене недолік.

Відповісти
Підтримати
Mykola Gatilov
Mykola Gatilov Senior DevOps 10.11.2023 13:08

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

Наприклад, якщо робиш в терраформ цикл — уникай використання списків, використовуй map

Зазвичай в yaml зберігаються всі вхідні параметри, всі змінні. Код терраформ вже розгортає все це. Звісно, змінні можна передати і з терраформ-vars файлу, але yaml значно компактніше, коли у вас файл змінними на 1000+ строк це має значення ;)

До того-ж на одну і ту-ж структуру даних можуть посилатись кілька модулів, що прибирає дублювання даних, і сам yaml дозволяє передавати з однієї частини у іншу частину даних за допомогою & * >> - що значно спрощує сприйняття та дозволяє, знову-ж таки не дублювати дані.

Так як проекти, зазвичай, доволі великі, ми розділяємо опис структури проекту (ми також використовуємо terragrunt) як опис залежностей між модулями (структура папок з hcl файлами і залежностями між ними) від змінних проекту (наприклад розміри/тарифи для віртуальних машин, баз даних, розміри стораджей, дисків — все це, а також специфічні дані, що відрізняються в залежності від ДЦ, бо інфраструктура розгортається в декількох ДЦ). Тобто так значно простіше переносити, скажемо з dev-конфігурації у prod — можна бути впевненим, що структура проекту така сама, тарифи — менші, наприклад. При такому розділі вірогідність помилок значно менша. Та й мерджити кілька різних файлів легше, ніж один. А якщо ви відразу створюєте структуру папок згідно загального шаблону — вам не прийдеться змінювати її, якщо з’являються об’єкти у інших ДЦ... Ну і наостанок — terragrunt дозволяє деплоїти проект «частинами» — якщо вам, наприклад, треба змінити тільки одну БД у одному ДЦ...

Відповісти
Підтримати
Stanislav Hordiyenko
andriy dmytrenko IT Geek 09.11.2023 16:21

Той, хто не використовує Terraform через те, що компанія змінила ліцензцію — герой приказки «чув дзвін, та не знає, де він».

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.