Kipróbáltuk az Atmost: DevOps-ból SweetOps?

A Code Factorynál már évek óta a Terragrunt-ot használjuk az Infrastructure as Code projektjeinkben. Leggyakrabban a Terraform Registryben elérhető közösségi modulokra támaszkodunk, köztük a Cloudposse csapat által fejlesztettekre is. Mivel a Gruntwork által javasolt stack-felépítés számunkra nem bizonyult elég meggyőzőnek, ezért kipróbáltuk a Cloudposse saját orchestration eszközét, az Atmos-t.

Mi az Atmos?

A terraform kód gyorsan kényelmetlenné válhat az infrastruktúránk növekedésével. Az Atmos egy robosztus CLI eszköz amely erre nyújt alternatív megoldást, segítségével képesek vagyunk kényelmesen és hatékonyan kezelni nagy infrastruktúrákat akár több accounttal és környezettel együtt.

Mit tud az Atmos?

Az Atmos a Terragrunt Stackhez hasonlóan Terraform modulokra épít, ezeket azonban komponenseknek nevezi. Ehhez tartozik egy rendkívül hasznos funkció, a vendor, amely külön konfigurációs fájlal és API-val rendelkezik. A vendor segítségével verzió alapján importálhatjuk a komponenseket a projektünkbe.

A komponenseket stackekben használjuk, amelyeket az Atmos az általunk konfigurált atmos.yaml alapján nevez el. Emellett kapunk egy modern, könnyen használható CLI-t, amely command, stack és component szinten is képes kezelni az infrastruktúrát.

Terragrunt esetében a commandok wrappelésére és a tool verziók kezelésére a mise eszközt használjuk. Az Atmosban mindez natívan elérhető: workflow-kat definiálhatunk, például egyetlen paranccsal deployolhatjuk egy EKS modul összes komponensét és függőségét. Sőt, az atmos.yaml fájlban custom commandokat is létrehozhatunk.

Mi az Atmos koncepciója?

Az Atmos alapelve a DRY (Don’t Repeat Yourself).

Ezt a filozófiát az importálások és mergelések segítségével valósítja meg. Minden YAML konfigurációs fájl importálható egy másikba, az importok sorrendje pedig meghatározza a hierarchiát. Az utoljára importált (vagy az import kulcsban utolsóként szereplő) érték kerül be a végleges stackbe. A merge-stratégiát szintén az atmos.yaml fájlban állíthatjuk be.

A bevált gyakorlat a default konfigurációk létrehozása. Ezekben definiálhatók például a stage-ek (dev, prod, stb.) közös értékei – mint a remote state vagy a catalogban található alapbeállítások. Ezután a konkrét stackek egyszerűen importálhatják a defaultot, majd szükség esetén kiegészíthetik vagy felülírhatják azt.

Az OOP-hez hasonlóan a Cloudposse is bevezetett egy öröklődési modellt, amelyet COP-nak (Component Oriented Programming) nevez. Ennek lényege, hogy a komponensek között is kialakítható leszármazási rendszer.

Egy komponenst akár absztraktnak is megjelölhetünk. Ebben az esetben közvetlenül nem hozható létre belőle példány, csak akkor, ha egy másik fájlban felülírjuk a típusát, vagy ha a YAML konfigurációban definiáljuk a leszármazást.

.
├── atmos.yaml
├── components
│   └── terraform
│       ├── account
│       │   └── *.tf
│       ├── account-map
│       │   └── *.tf
│       ├── eks
│       │   └── *.tf
│       ├── tfstate-backend
│       │   └── *.tf
│       └── vpc
│           └── *.tf
├── stacks
│   ├── catalog
│   │   ├── account
│   │   │   └── defaults.yaml
│   │   ├── account-map
│   │   │   └── defaults.yaml
│   │   ├── tfstate-backend
│   │   │   └── defaults.yaml
│   │   └── vpc
│   │       ├── defaults.yaml
│   │       ├── dev.yaml
│   │       └── prod.yaml
│   ├── mixins
│   │   ├── region
│   │   │   ├── eu-central-1.yaml
│   │   │   └── global-region.yaml
│   │   └── stage
│   │       ├── dev.yaml
│   │       ├── prod.yaml
│   │       └── root.yaml
│   └── orgs
│       └── acme
│           ├── _defaults.yaml
│           ├── core
│           │   ├── _defaults.yaml
│           │   └── root.yaml
│           └── plat
│               ├── _defaults.yaml
│               └── dev
│                   ├── _defaults.yaml
│                   └── eu-central-1.yaml
└── vendor.yaml

Hátrányok

Tapasztalataink szerint az Atmos akkor működik igazán jól, ha szorosan követjük a Cloudposse által meghatározott management konvenciókat. Ez azonban együtt jár azzal, hogy használnunk kell az Account és Account-Map komponenseket, amelyek erős függőségeket hoznak létre más modulok felé. Emiatt a megoldás nem igazán alkalmas brownfield projektekhez – én például kizárólag greenfield környezetben tudtam vele dolgozni AWS root hozzáféréssel.

A megfelelő működéshez ráadásul szükség van a teljes SweetOps ökoszisztéma használatára (Atmos, Geodesic, Cloudposse komponensek, illetve a null-label modul).

Benyomásunk az Atmosról

A Cloudposse sok szempontból logikus és előremutató ötleteket valósított meg. Az importálási és merge-mechanizmusba viszonylag gyorsan bele lehet jönni, ugyanakkor a módszertan jelenleg erősen kötődik a Cloudposse ökoszisztémához, ami jelentős függőségekkel jár.

A proof of concept kipróbálását az is nehezíti, hogy nincs nyilvánosan elérhető, teljes példa repository, a dokumentáció pedig több helyen hiányos vagy nem teljesen egyértelmű.

Köszönjük, hogy elolvastad ezt a cikket!

Érdekel a téma? Kérdés merült fel a cikkel kapcsolatosan? Foglalj egy ingyenes konzultációt és nézzük meg, hogy a Code Factory csapata miben tud segíteni neked / nektek! A szolgáltatásaink listáját itt találod meg!

Források

• Cloudposse: Production-Ready Infrastructure in 2 Weeks
• Atmos: Hello from atmos | atmos
• Geodesic: GitHub - cloudposse/geodesic: 🚀 Geodesic is a DevOps Linux Toolbox in Docker
• Null-label: GitHub - cloudposse/terraform-null-label: Terraform Module to define a consistent naming convention by (namespace, stage, name, [attributes])
• Account-map: account-map | The Cloud Posse Reference Architecture
• Account Management: Account Management | The Cloud Posse Reference Architecture
• Mise: Home | mise-en-place