Automatizace – všechno nebo nic
Jak už jsem zmiňoval ve svém článku o tom, proč milujeme Terraform, v Ackee spravujeme infrastrukturu deklarativním způsobem neboli jako IaC (Infrastructure as Code). Srdcem stroje zvaného Ackee DevOps je tedy Terraform a Kubernetes. Pojďme se podívat, jak tyhle nástroje využíváme v praxi agenturního vývoje aplikací.
Terraform
Při psaní deklarativních .tf souborů musí člověk vždy myslet na zmíněný princip “všechno nebo nic” a vyhnout se zkratkovitostem. Co to znamená?
V dnešní době, kdy naše aplikace běží v public cloudech (u nás konkrétně GCP – Google Cloud Platform), lze většinu infrastruktury lidově řečeno “naklikat”. Tento přístup je určitě výhodný pro malé projekty nebo na testování, ale zkázou daného principu “všechno nebo nic”, protože IaaC, potažmo Terraform implementují volání API metod. Kdežto, jak jsme se již několikrát přesvědčili, webové rozhraní (v GCP mu říkají konkrétně Google Cloud Console) volá někdy několik API metod a ty někdy vyžadují i určitou posloupnost. Snažíme se tedy pracovat s Terraformu už ve vývojovém prostředí.
Dev vs. Ops
Domluva s vývojáři je tedy následující: Pokud potřebujete část infrastruktury, která se opakuje, standardně například GCS (Google Cloud Storage) pro ukládání perzistentních dat, tak běžte rovnou do Terraformu, podívejte se na již zajetý projekt a definujte nový bucket s úpravou parametrů (zpravidla název). Pokud potřebujete část infrastruktury, se kterou jste nikdy nepracovali, pokuste se ji vydefinovat v Terraformu (za předpokladu, že na této práci strávíte triviální čas). Pokud by vám to trvalo déle, stačí “naklikat” a replikaci v Terraformu zadat DevOps týmu. V dev prostředí mají vývojáři “vysoká oprávnění”, aby nebyly brzděni často zaneprázděným DevOps týmem.
Infrastructure staging
Ve stage prostředí mají vývojáři oprávnění pouze pro čtení, nasazování infrastruktury probíhá vždy pouze za použití Terraformu. Tento mezikrok nám dává určitou pojistku, že nepřehlédneme nic, co “nečekaně vytvořilo” webové rozhraní cloud providera. Často se totiž stává, že i když se ve vývojovém prostředí tváří vše v pořádku, na stage prostředí se může projevit, že nám v Terraform definicích něco chybí. Zde se tedy zajistí, že je tedy git “jedním zdrojem pravdy”.
“Ostrá verze” infrastruktury
V produkčním prostředí nás již nemůže nic zaskočit a nasazujeme vždy ověřené Terraform setupy.
(Almost) Everything as a code
S používáním Terraformu tedy největší problém nastává, pokud se nepoužívá. Jediné problémy, na které jsme jinak narazili, byly při zpětném importu již vytvořených věcí – někdy to může být komplexnější a časově náročnější, než dané věci vytvořit rovnou v Terraformu.
Výjimkou potvrzující pravidlo zde budiž Firebase, které hojně používáme, ale dlouho nešlo vytvořit přes API (a tudíž ani přes Terraform). I tato výjimka ale už byla vyřešena: https://github.com/terraform-providers/terraform-provider-google/issues/2973#issuecomment-606156150
Kubernetes
I když je Kubernetes využíván primárně pro aplikace samotné, nasazujeme do něj zpravidla i dva typy infrastrukturních objektů:
Infrastruktura firemní
Jako kontejnery nám běží všechny naše oblíbené služby: Jenkins, Gitlab, Vault, Redmine atd.
Infrastruktura aplikační
Ačkoli se snažíme co nejvíce utilizovat služby nabízené veřejnými cloudy (CloudSQL pro MySQL/Postgres, MemoryStore pro Redis atd.), někdy je třeba si deploynout i nějakou podpůrnou infrastrukturu do clusteru. Pro tyto potřeby hojně využíváme Terraform Helm provider. S věcmi, které nemají Helm chart, pomůže vlastní Jenkins pipeline, která umí deployovat Kubernetes manifesty.
S dotáhnutím k dokonalosti a tedy k vysněnému “všechno nebo nic” nám hodně pomohly sealed secrets, které tvoří “poslední kus skládačky”. Tedy, v Kubernetes se dají definovat kompletní aplikace a s pomocí Jenkins pipeline nasazovat vše automatizovaně z repozitáře rovnou do clusteru – tomuto postupu se říká GitOps. Jediné, co tento postup rozbíjelo, byla právě hesla (nebo API klíče či jiné credentials), které člověk na jednu stranu potřebuje mít někde vydefinované, protože bez nich nelze aplikaci provozovat, ale na stranu druhou není zpravidla dobrý nápad je mít nešifrované uložené do repozitáře, přestože je přístup do něj omezen.
Sealed secret tento nedostatek řeší a díky nim lze mít opravdu vše “as a code”.
Závěr
Osvědčilo se nám tedy udělat udělat vývojový cyklus infrastruktury s postupně “zpřísňovaným” důrazem na kompletnost kódu, kdy ve vývojovém prostředí dáváme velký prostor agilnímu vývoji společně s našimi backend vývojáři, ve stage si funkčnost společně ověříme a v produkčním prostředí již sebevědomě nasazujeme funkční infrastrukturu.
Chcete vytvářet infrastrukturu a škálovat aplikace pro miliony uživatelů? Přidejte se k našemu DevOps týmu!
