Magento 2 pe Kubernetes (EKS)

Ca și companie, rulăm în producție Magento pe Kubernetes încă din 2017 pe produsul nostru Magento 1. La acel moment AWS nu avea EKS (Elastic Kubernetes Service), deci am fost nevoiți să ne construim propriul cluster; a fost o sarcină interesantă, dar provocatoare.

Azi, rulăm clustere Zento pe EKS, unde deși AWS gestionează partea de Kubernetes, a fost necesar un efort considerabil pentru a face Magento 2 să ruleze pe Kubernetes.

În acest articol, vom acoperi următoarele:

• setup-ul nostru pentru routing
• stocare de fișiere
• securitate
• scalare
• monitorizare

Setup-ul nostru special

Pentru a routa request-urile care ajung la CDN-ul CloudFront, utilizăm AWS Application Load Balancer (ALB), care direcționează traficul de la CloudFront la Namespace-ul și serviciul EKS relevant.

Zento este o soluție SaaS, deci deployment-ul nostru Kubernetes este multi-proiect. Pentru a nu fi necesar câte un ALB pentru fiecare magazin Zento, folosim target group-uri ALB care să identifice Namespace-ul destinație al fiecărei vizite și să o direcționeze către Service-ul corect.

Stocare

Prima provocare pe care am avut-o a fost legată de fișierele pe care Magento în mod normal le stochează pe disc: media și log-uri.

O soluție este utilizarea EFS (Elastic File System), ceea ce am făcut pe soluția veche Magento 1, însă această soluție are mai multe dezavantaje:

• poate fi lent (IOPS burstable disponibile se pot consuma foarte rapid)
• este foarte consumator de CPU la lansarea unui pod (Linux care multă indexare când se face mount la o partiție mare)
• este relativ scump

O soluție mai bună este utilizarea S3 pentru stocarea de fișiere, însă asta necesită modificarea modului în care Magento 2 stochează fișiere. Echipa Magento lucrează la suport nativ pentru S3, însă până acest suport este disponibil, extinderea Magento este necesară.

Pentru rezolvarea stocării log-urilor de pe disc am construit un agent bazat pe fluentd care ia logurile Magento 2 și le transmite printr-un stream către CloudWatch Logs. În acest fel, programatorii au tot timpul acces la log-urile de pe toate Pod-urile unui proiect, indiferent ce Pod a generat acele log-uri sau dacă Pod-ul mai rulează.

Securitate

Toate credențialele sunt stocate în serviciul Parameter Store din AWS SSM și sunt salvate în namespace-ul Kubernetes într-un configmap.

Accesul la celelalte servicii AWS, cum ar fi S3 sau SES, este realizat printr-un Pod Role IAM. Este un mod securizat și elegant de permisiuni care nu necesită gestionarea unor chei de acces.

Tot clusterul rulează într-un VPC privat astfel încât accesul să se poată face doar prin canalele stabilite. Se asigură astfel și accesul securizat între EKS și baza de date MySQL care rulează pe AWS RDS.

Scalare

Una dintre principalele promisiuni Kubernetes este scalarea, deci configurarea unei auto-scalări este importantă.

La Zento avem 2 seturi de Node-uri:

• on-demand care găzduiesc Pod-uri ce servesc request-uri GraphQL și accesul în panoul de administrare
• Spot pentru Pod-uri de Consumer

Ambele seturi scalează în sus și în jos în funcție de Pod-urile care rulează pe ele. Pod-urile într-un Namespace scalează în sus sau în jos în funcție de volumul de trafic sau job-uri care rulează la orice moment.

Monitorizare

Un aspect critic în orice activitate DevOps este monitorizarea, deci monitorizăm tot. Pe lângă log-ul de vizite primit din CloudFront, toate log-urile generate de Magento 2 și PHP sunt stocate în CloudWatch Logs prin fluentd.

Pentru monitorizarea consumului de resurse din EKS, serviciul de Container Insights oferit de AWS este o soluție excelentă. Însă prețul este bazat pe numărul de metrici generate de Namespace-uri și Pod-uri, ceea ce era prea scump în setup-ul nostru. Drept urmare, am decis să utilizăm Prometheus pe care AWS îl oferă ca și serviciu.

Un agent Blackfire este prezent în fiecare namespace pentru a permite întregii echipe să aibă acces la informații legate de consumul de resurse a fiecărui proces și pentru a permite astfel optimizarea lor.

Concluzii

Un deployment Magento 2 pe Kubernetes este recomandat pentru setup-uri mari:

• oferă cea mai scalabilă arhitectură
• forțează respectarea bunelor practici
• permite o întreținere ușoară

Pentru deployment-ul de cod avem o soluție bazată pe GitHub Actions, Step Functions și CodeBuild. Vom povesti mai multe despre această arhitectură într-un viitor articol.