Stručné shrnutí stavu DevOps v Ackee na konci roku 2020

Na rok 2020 asi nikdo z nás nebude chtít vzpomínat. Náš DevOps tým sice neměl moc příležitostí pracovat společně v kanceláři, ale i tak jsme odvedli spoustu skvělé práce. O jaký tým vlastně jde?

Jsme zhruba tři DevOps inženýři se čtvrtým čestným členem, naším team leaderem. Všichni členové jsou kromě team leadera součástí rotace na podpoře. Takže jeden týden v měsíci musí být každý z nás k dispozici vývojářům, když mají nějaké potíže. U jednoho projektu máme navíc pohotovostní službu 24/7. Zní to jako něco, co je víceméně odpovědností týmu Site Reliability Engineering (SRE) a za normálních okolností ve větší firmě byste měli pravdu. Nějak jsme ale museli najít způsob, jak zajistit, aby vše fungovalo v rámci našich DevOps povinností.

A tím to nekončí! Náš tech-stack sahá od Node.js až po Android aplikace. Přesvědčte se samina https://stackshare.io/ackee_2/ackee (správně, je to ackee_2, někdo totiž ztratil přihlašovací údaje k ackee). V Ackee nás je přes sedmdesát, čtyři vývojové týmy, každý pro jinou platformu. Naše práce by byla mnohem náročnější, kdybychom neměli tak skvělé vývojáře

Standardizovaný stack aneb méně času na podpoře

Někdy na podpoře prosedíme hodně času. Ale naštěstí jsou takové situace vzácné. Za to vděčíme především našemu sjednocenému a standardizovanému stacku, který našim vývojářům poskytujeme. Jestli byste si měli něco z tohoto článku odnést, tak je to právě tohle: Pokud pracujete v DevOps a poskytujete podporu pro hodně vývojářů a projektů – standardizujte si váš stack. 

To ale často znamená, že musíte zničit sny projekťákům. Protože jakmile se necháte unést a slíbíte jim mnoho nových fancy funkcí, musíte myslet na to, že váš tým má omezené množství času nazbyt. Zejména novými věcmi téměř vždy rozšiřujete budoucí čas strávený na podpoře. Pamatujte na bibli SRE, kterou jsme dostali od samotného Googlu. Jako DevOps inženýr máte maximálně 50 % času, který můžete věnovat podpoře.

Atomické deploymenty

V některých případech se nám stává, že potřebujeme atomický deployment. Tj. aby se veškerý provoz v jednu chvíli přepnul bez výpadku na novou verzi backendu. Překvapilo nás, jak náročné tohle bylo pro náš GKE cluster. Rolling updates nám nepomohly, protože v jednu chvíli byl uživatelům nabízen nový i starý obsah. Kubernetes strategie v podobě Recreate updates také samozřejmě způsobila výpadek. Stejně tak přepínání labelů v rámci servicy. A změna backend service v GKE Ingress? Správně, výpadek. Svým způsobem měl být náš deployment bez jakýchkoli viditelných problémů a na novou sadu podů měl přepnout co nejlépe atomicky. Zdálo se, že Service mesh je pro nás jediné řešení. 

Service mesh je fantastická věc, ALE… Vždycky je tu nějaké ale, kterému musíte čelit:

• Náš stack funguje na Helm chart deployments. Helm ale není zrovna kamarád se Service mesh, kde přepínáte virtuální váhy servicy. 
• GKE podporuje ISTIO, ale samotná podpora je stále v beta verzi a vytváří hodně problémů. Jen se podívejte na všechny ty reference na  ISTIO v Release notes.
• Jakýkoliv jiný Service mesh by musel být pod správou našeho DevOps týmu. Jak už jsem ale zmiňoval v úvodu, máte maximálně  50 % svého času na podporu.
• Integrace s GKE aplikačním load balancerem není tak přímočará, jak bychom si přáli.
• Mnoho známých nástrojů v GKE ISTIO funguje velice záhadným způsobem. V našem případě se nezdařilo nastavit Kiali, Po vyřešení několika upstream problémů díky Kiali vývojářům fungoval, ale pak zase fungovat přestal.

Těšíme se tedy na stabilnější prostředí ISTIO v GKE a do té doby raději počkáme. Potom se rádi podělíme.

Terraform, terraform a zase terraform

Terraform učinil v roce 2020 velký skok dopředu: Nejprve představil verzi 0.13 v srpnu a potom 0.14 v prosinci. Obě verze byly velmi slibné. Ale přiznejme si, že od té doby, co Terraform přestal stát za nic (s příchodem verze 0.12 v květnu 2019), potřeba častých updatů nebyla tak nutná. Proč? Už verze 0.12 nabízela funkce, které lidé potřebovali nejvíce: např. for_each, odpovídající syntaxe interpolace, apod. Také kvůli tomu jsme začali migrovat na 0.13 až v posledním kvartálu roku 2020. Nejvýznamnějším zlepšením pro nás bylo jednotné místo v konfiguraci pro verze providerů.

Samozřejmě nám udělalo radost zavedení count do modulů ve verzi 0.13. Ale v té době už všechny naše moduly využívaly mapy, které nám umožňovaly vytvářet více resources ještě před zavedením keywordu count. Protože jsme používali příkazy for_each, odkazování na vytvořené resources bylo jen otázkou použití správných klíčů mapy. Nejvýznamnějším zlepšením pro nás byla čitelnost, kterou může count přinést do konfigurace.

Také jsme čelili spoustě problémů týkajících se týmové práce v Terraform projektech. State rostl, protože rostly naše projekty. Dříve nebo později (nebo příští úterý) jsme se vždy dostali do chvíle, kdy byl state management nemožný. Zkoumali jsme Terragrunt, ale nenašli jsme žádný best practice, který by byl vhodný pro náš use-case.

Potom, co jsem v uplynulém roce úspěšně složil zkoušku z Terraform, jsem se těšil na Terraform Cloud. Sedí hned na několik našich use-casů. Sice by nepomohl zmenšit náš state, ale umožnil by nám konfiguraci bez konfliktů. Se state managementem navíc pomohlo použití remote backendu pro Terraform. Už jsme nebyli zodpovědní za úložiště, kde se state nachází.

Vždycky je tu ale nějaký háček. Naše workflow spočívá ve vyvinutí appky a pak se jede dál. V některých případech jsme potřebovali přidat klienty do našeho GitLabu, abychom s nimi sdíleli Terraform konfigurační soubory. V tuhle chvíli (3. 1. 2021) Terraform cloud nabízí ve své free verzi přístup 5 uživatelům a Team plan za 20 USD měsíčně na uživatele. Protože jsme v našem týmu jen tři, nebyl by to problém. Ale kdybychom přidali více uživatelů, fakturace by pak byla překážkou. Místo toho jsme se tedy rozhodli vylepšit náš CI/CD system a Terraform Cloud si nechat na rok 2021.

Gitlab CI a loučení s Jenkinsem

Následující část blogu bude pravděpodobně trochu kontroverzní. Já osobně znám dost lidí, kteří by přísahali, že Jenkins je jediný CI/CD systém: vyspělý, robustní, stabilní. Mám pocit, že jakmile vám jednou pipeline selže s NullPointerException kvůli kódu pipeliny, ne kvůli kódu aplikace, nepoužíváte to nejlepší možné řešení pro vytváření pipelines. Takové situace se vám v Jenkinsovi mohou stát častěji než v GitLab CI. Když vaše codebase zestárne a ti, kdo ji napsali, už odešli, vsaďte se, že takové problémy budete mít velmi často. O naší cestě za GitLab CI jsem mluvil na DevOpsCon minulý rok. Dost jsem bojoval s tím, abych nevinil Jenkinse za problémy, které jsme měli. Vím, že psát si pipelinu v YAML má spousty vlastních problémů, ale pro náš use-case to stačilo. 

Některé pipeliny se trochu zpomalily. To se stalo hlavně kvůli neexistujícímu workspace directory v Jenkinsovi. Kvůli tomu, že GitLab CI Runners jsou založeny na souběžném nezávislém runtimu, může být sdílení dat problematické. A to třeba kvůli velkým node_modules složkám, které sdílíme mezi úlohami přes keše. Každá výzva je příležitost – s touto jsme se rozhodli vypořádat následujícími kroky:

• Kešujte všechno. Kešujte node packages na lokální síti, používejte Minio pro GitLab CI kešování a ukládejte balíčky na runnery v lokálních adresářích namountovaných do Docker kontejneru.
• Nebojte se Docker BuildKit. Náš senior DevOps inženýr Tomáš Hejátko BuildKit  otestoval, deploynul ho do našich GitLab CI Runners. Zatím jsme s BuildKitem neměli žádné potíže. 
• Myslete na keš key. Například my kešujeme node_modules pomocí `CI_PROJECT_ID` variable (ID projektu). Předtím jsme používali `CI_COMMIT_REF_SLUG`. To vedlo k vytvoření nových node_modules pro každou branch nebo tag. Ukázalo se, že to nebylo potřeba.

Díky těmto zlepšením jsme byli schopni mít stejnou dobu běhu pipeliny jako jsme měli s Jenkinsem. To nám samozřejmě nemohlo stačit. Přínosů GitLab CI bylo více:

• Teď můžeme škálovat runnery, s Jenkinsem to nebylo tak jednoduché.
• Ovládáme pipeliny přímo v GitLab UI.
• Už nebojujeme s merge request buildery.
• Vylepšili jsme naši codebase pro pipeliny.
• Trávíme méně času na podpoře.

Jestli se ocitnete ve stejné situaci, jako jsme byli my, silně doporučuji implementaci pipeline do GitLab CI místo Jenkinse.

Hosting React aplikace v GCS vs. Firebase hosting

Hostovat React aplikace by mělo být jednoduché. Většinou se to dá shrnout do následujících kroků:

• naprogramujete aplikaci,
• synchronizujete aplikaci do bucketu,
• nastavíte správná práva
• a to je vše!

Dobrá, ale co když chcete nastavit TLS? Následováním guidelines od Google byste ideálně měli vytvořit aplikační load balancer a pro něj získat Managed certificate. Už to není tak snadné, jak byste chtěli.

Navíc, mít bucket pojmenovaný stejně jako doménu znamená, že autentizaci musíte udělat ručně vy. Jasně, není to tak těžké, stačí pár kliknutí. Mohlo by to ale být ještě jednodušší? Mohl by to udělat jakýkoliv vývojář místo vás? Pamatujte, na podporu máte maximálně 50 % vašeho času.

Pro nás byla odpověď Firebase hosting. V téhle době ho spíše testujeme, abychom viděli, jestli naplní všechny naše požadavky. Firebase SDK je velmi přátelská vůči vývojářům. Ti dnes ovládají věci, které jsme dříve měli na starosti my z DevOps (TLS, caching, apod.), a to pomocí jednoho konfiguračního souboru.

Nicméně i tento způsob může být zrádný. To, že keše měli na starost lidé z DevOps, mělo svůj důvod. Někdy mají vývojáři tendenci zapomínat, že keše mohou trochu bolet. Například nastavování TTL pro 404 na déle než 5 minut může vést ke katastrofám. Nám se omylem podařilo nastavit TTL pro 404 na půl roku (to byl můj nápad). To je fajn, pokud používáte hashe pro nově nasazené soubory přímo v jejich názvech. Problém ale nastane, když deploynete novou verzi. Pár klientů mělo tu smůlu, že zavolaly nový index, který odkazuje na obsah, který ještě není uploadovaný. Z těchto důvodů si dáváme pozor na naše experimenty s Firebase Hosting a doufáme, že se nám podaří vychytat všechny mouchy.

2021, tady nás máš

Nebyl by to pořádný shrnující blog post, kdybych nepoděkoval svému týmu. Všechny výše zmíněné body byly možné jen proto, že jsme se naplno mohli soustředit na naši práci a s nasazením ji vykonávat, díky!

Nejlepší zpětnou vazbu na svou práci jsem obdržel v podobě kudos během našich udržitelných Vánoc. Dříve nebo později se ocitnete v pozici člověka, který musí umět říkat ne (především pokud pracujete na podpoře). Stopnete ne jeden sen projektových manažerů, někdy zase zklamete vývojáře. Váš čas je prostě omezený. Nakonec ale zjistíte, že tato pozice není tak moc obtížná pro ostatní – je těžká pro vás. Právě vy limitujete sny, abyste poskytli spolehlivost. Zmíněný feedback mi pomohl pochopit, že i ostatní jsou si vědomi toho, v jakých situacích se DevOpsáci nacházejí a že tu nejsou žádné “hard feelings”. Takže alespoň pro rok 2020 se nám vedlo dobře. 

Těšíme se na mnoho dalších úkolů, které se chystáme podniknout:

• Nemůžeme se dočkat, až se pořádně ponoříme do Service mesh. Pokud je tu nějaký zainteresovaný čtenář, neváhejte se nám ozvat, rádi se přiučíme.
• Taky se nemůžeme dočkat, až ještě více zlepšíme náš Terraform. Samotná migrace na novou verzi není to stejné jako plné využívání všech nových funkcí.
• Jsme připraveni se poprat se všemi problémy na podpoře, kterým budeme muset čelit!

A jedna poslední věc. Doufám, že se brzy budeme moct vrátit do kanclu.