Infrastructure as Code és GitOps szolgáltatás

Amit kódból építünk fel

A szervereket, a hálózatot és az alapkonfigurációt Terraformmal vagy OpenTofuval írjuk le, Ansible-lel visszük fel rájuk a szoftvereket és a beállításokat, a Kubernetes-erőforrásokat pedig ArgoCD-vel vagy Fluxszal léptetjük GitOps-elven: a gitben lévő állapot a forrás, a klaszter automatikusan ehhez igazodik. Minden módosítás pull requesten és review-n megy keresztül, mielőtt élesbe kerül, így nyomon követhető, ki és miért változtatott bármit. Ezt a folyamatot az első átadáskor együtt állítjuk be veled. Ezt a fegyelmet a legkisebb konfigurációs módosításnál is tartjuk, nem csak a nagyobb infrastruktúra-változtatásoknál.

• Terraform vagy OpenTofu a szerverekhez és a hálózathoz
• Ansible a konfigurációhoz és a szoftvertelepítéshez
• ArgoCD vagy Flux a Kubernetes-erőforrások GitOps-léptetéséhez
• Minden változtatás pull requesten és review-n keresztül

Bevált gyakorlatok, amelyeket alkalmazunk

A kód alapú infrastruktúra csak akkor ér valamit, ha nincs mellette kézi kiskapu. Ezt a listát minden bevezetésnél alkalmazzuk, és a te dokumentációdban is rögzítjük, a katasztrófa utáni helyreállítási gyakorlat eredményeivel együtt. Egy egyetlen kézzel módosított szerver elég ahhoz, hogy a kódból leírt állapot és a valóság szétváljon, és egy újraépítés eltérő eredményt adjon, mint amit vártál. Ezért a drift-ellenőrzést rendszeresen megismételjük. Ezért a kézi kiskaput minden bevezetésnél tudatosan bezárjuk, nem csak elméletben tiltjuk.

• Minden a gitben, review-val, kivétel nélkül
• Immutábilis infrastruktúra: csere, nem foltozás
• Semmilyen kézi módosítás nincs az éles környezetben
• Rendszeres katasztrófa utáni helyreállítási gyakorlat
• Környezeti paritás: teszt és éles ugyanazon kódból épül

Konfiguráció-eltolódás és állapotzárolás

Az idő múlásával a legfegyelmezettebb csapatnál is előfordul, hogy valaki kézzel javít egy szervert egy sürgős hiba miatt. Ezt a konfiguráció-eltolódást (drift) rendszeresen ellenőrizzük, és jelentjük, mielőtt a következő kódból történő futtatás felülírná vagy ütközne vele. A Terraform állapotát zároljuk, hogy két párhuzamos futtatás ne írja felül egymást, a titkokat pedig SOPS-szal vagy Vault-tal kezeljük, sosem sima szövegben a gitben.

• Rendszeres drift-ellenőrzés, jelentéssel eltérés esetén
• Állapotzárolás, hogy párhuzamos futtatások ne ütközzenek
• Titkok SOPS-szal vagy Vault-tal, sosem sima szövegben

A beleértett órák és a bevezetés

A Terraform- és Ansible-alapok felépítése, a GitOps-léptetés bevezetése és az első katasztrófa utáni helyreállítási gyakorlat a havi órák terhére történik: 1–8 óra a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken. Az ügyfélpanel DevOps szolgáltatások menüpontjából kéred, javasolt határidővel. A meglévő, kézzel kezelt infrastruktúra kódba öntése jellemzően több hónapot vesz igénybe, ezért szakaszoljuk. A kereten felüli munkát külön számlázzuk, a munka megkezdése előtt egyeztetett becsléssel.

Hogyan dolgozunk

1. Igényled a panelből

   Elmondod, milyen infrastruktúrád van jelenleg, és mennyire kézzel kezelt, majd javasolsz egy határidőt a DevOps szolgáltatások menüpontban.

2. Egyeztetjük a kereteket

   Felmérjük a jelenlegi állapotot, kiválasztjuk az eszközöket, és meghatározzuk, mely komponenseket öntjük kódba elsőként, a havi óraszám alapján.

3. Megvalósítjuk és teszteljük az újraépítést

   Megírjuk a Terraform- és Ansible-kódot, beállítjuk a GitOps-léptetést, majd egy környezetet teljes egészében kódból építünk fel, hogy igazoljuk a reprodukálhatóságot.

4. Dokumentálva átadjuk

   Megkapod a kódot a tárolódban, a drift-ellenőrzés eredményeit, a katasztrófa utáni helyreállítási eljárást és a review-folyamat leírását.

Felhasználási esetek

Technológiák

• Terraform
• OpenTofu
• Ansible
• ArgoCD
• Flux
• SOPS
• HashiCorp Vault
• Atlantis

Gyakori kérdések

• Mi az az Infrastructure as Code, és miért jobb, mint a kézi beállítás?

  Az Infrastructure as Code azt jelenti, hogy a szerverek és a hálózat állapotát kódban írod le, nem kézzel állítod be egyenként. Előnye, hogy a változás review-n megy át, a teljes környezet reprodukálható, és egy incidens után nem kell találgatni, mi volt pontosan beállítva.

• Mi az a GitOps, és miben más, mint a hagyományos CI/CD?

  A GitOps-ban a kívánt állapot a gitben van, és egy operátor folyamatosan ehhez igazítja a klasztert, nem egy pipeline futtat kézi lépéseket. Ez azt jelenti, hogy a git-előzmény pontosan tükrözi az éles állapotot, és egy visszaállítás annyi, hogy visszaállítod a régi commitot.

• Terraform vagy Ansible: melyiket mire használjátok?

  A Terraform a szerverek, a hálózat és az alapinfrastruktúra létrehozására és leírására való. Az Ansible a már létező szervereken végzi el a konfigurációt és a szoftvertelepítést. A kettőt együtt használjuk: Terraform hozza létre a gépet, Ansible állítja be rajta a szoftvert.

• Mi történik, ha valaki kézzel módosít egy szervert a kódon kívül?

  Ezt konfiguráció-eltolódásnak hívjuk, és rendszeresen ellenőrizzük. A drift-ellenőrzés jelenti az eltérést, mielőtt a következő kódfuttatás felülírná vagy ütközne vele. A cél, hogy a kézi módosítás kivétel maradjon, ne a norma.

• Hogyan segít az Infrastructure as Code egy katasztrófa utáni helyreállításban?

  Ha minden kódban van leírva, egy teljesen elveszett környezet újraépíthető a gitből, gép- és hálózatkonfigurációval együtt, kézi rekonstrukció nélkül. Rendszeres gyakorlattal ellenőrizzük is, hogy ez ténylegesen működik, nem csak elméletben igaz.

• Mennyi idő alatt térül meg az Infrastructure as Code bevezetése?

  A pontos idő a jelenlegi infrastruktúra méretétől függ, de a legtöbb csapat már az első néhány új környezet létrehozásánál érzi a különbséget: percek, nem napok. A nagyobb nyereség az auditálhatóságban és a katasztrófa utáni helyreállítás megbízhatóságában jelentkezik.