Procesul Zento de deployment Magento 2

Soluția Zento are 2 componente principale: un frontend headless PWA care rulează pe AWS Lambda și un backend Magento 2 care rulează pe Kubernetes folosind AWS EKS (Elastic Kubernetes Service).

Am descris cum găzduim backend-ul Magento 2 pe Kubernetes în articolul anterior, iar în acest articol ne vom concentra pe modul în care procesul de Continuous Deployment funcționează.

Cum sunt modulele configurate

Unul dintre avantajele principale ale Magento îl reprezintă extensibilitatea. Așadar, urmarind bunele practici din domeniu, atât funcțiile globale cât și cele specifice anumitor proiecte au un modul Magento dedicat într-un repository propriu.

Toate modulele folosesc Composer.

Github & Versionarea

Una dintre nevoile noastre încă din primul moment a fost să avem versionare pentru module, astfel încât modulele configurate pe proiecte să poată avea versiuni precise și documentație de release.

Când echipa de dezvoltatori trimite cod în GitHub, CI Actions pornește automat un proces de code review pentru verificarea calității codului. Pentru a putea lansa codul pe un proiect însă, este necesară o acțiune de Release în GitHub.

Odată un Release creat, un proces Github Action automat împachetează codul într-un pachet Composer și îl încarcă într-un repository S3 privat, de unde va fi descărcat ulterior în procesele de deploy.

Deploy-ul

Deployment-urile Zento sunt automatizate prin AWS Step Functions: când se dorește lansarea unui nou proiect sau actualizarea unui proiect existent, se pornește un proces Step Function care actualizează frontend-ul PWA, backend-ul Magento 2 sau oricare alt micro-serviciu utilizat.

Pentru partea Magento 2, Step Function primește ca parametru versiunea Magento 2 utilizată și lista de module utilizate pe proiect, cu versiunea explicită pentru fiecare modul. Funcția apoi realizează următoarele operațiuni:

Compilează o imagine Docker cu tot codul Magento 2 și modulele proiectului
Încarcă imaginea Docker în Kubernetes
Execută acțiunea de Install sau Upgrade

Cunoscând versiunea de Magento și versiunea tuturor modulelor utilizate este pornită o funcție de AWS CodeBuild. Procesul utilizează codul Magento 2 de bază, apoi instalează fiecare modul din S3 folosind Composer.

Rezultatul este un director care conține tot codul de backend al proiectului, iar un build Docker împachetează tot acest cod într-o imagine Docker pentru proiectul curent.

CodeBuild încarcă imaginea Docker rezultată în AWS ECR (Elastic Container Registry), finalizând astfel build-ul.

Deploy pe Kubernetes

Odată ce avem imaginea Docker din CodeBuild, Step Function-ul începe deployment-ul în EKS:

crează Namespace dacă este nevoie
crează/actualizează Pod Access
crează/actualizează ConfigMap
crează/actualizează serviciul și pod-urile M2-HTTP
crează/actualizează serviciul și pod-urile M2-Cron
crează/actualizează serviciul și pod-urile M2-Consumer
crează/actualizează serviciul și pod-urile Varnish

Pod Access Role gestionează accesul pod-urilor din namespace-ul proiectului la celelalte servicii AWS: S3 pentru stocare, SES pentru trimiterea de mail-uri, SQS pentru diferite queue-uri, CloudFront pentru invalidări de CDN, etc.

Serviciile M2-HTTP, M2-Cron și M2-Consumer sunt actualizate să utilizeze noua imagine de Docker, iar Varnish este actualizat să utilizeze cele mai noi servicii.

Unul dintre avantajele acestei strategii de deploy este că toate procesele consumatoare de timp sunt realizate în etapa de CodeBuild, astfel încât lansarea unui nou Pod Kubernetes să fie rapidă (2-3s). Acest lucru garantează scalarea orizontală rapidă în cazul unui trafic crescut.

Executarea operațiunilor de Install sau Upgrade

Odată ce codul nou este împachetat într-o imagine Docker și lansat pe Kubernetes, este momentul să executăm operațiunea de upgrade sau install de care Magento are nevoie pentru configurarea bazei de date.

Operațiunea de install rulează un install de Magento nativ și un set de comenzi care configurează un magazin nou de Magento.

Operațiunea de upgrade execută comanda Magento de setup upgrade și apoi actualizează cache-ul și indecșii.

Concluzii

Obiectivul nostru cu acest proces de deployment este ca el să fie complet automatizat, fault-tolerant, rapid la scalarea Kubernetes și să poată fi rulat cu downtime zero.

Procesul nostru este: automatizat (se introduc modulele și versiunile, iar restul operațiunilor sunt automate), fault-tolerant (în cazul oricărei erori, procesul este oprit fără a afecta magazinul online), rapid la scalare (toate operațiunile consumatoare de timp sunt realizate în build și nu în deploy). Rezultatul este un proces robust cu downtime zero.