Urmând modelul european, tot mai multe țări cer stocarea datelor personale, guvernamentale și esențiale în spațiul geografic al țării, chiar și în cazul soluțiilor cloud.
În cazul de față, soluțiile aeroportuare au fost implementate inițial în AWS în spațiul european, dar la solicitarea din partea guvernului, a fost nevoie de migrarea în data centere din Orientul Mijlociu. Problema era chiar mai complexă pentru că singurul furnizor de servicii cloud disponibil la momentul respectiv era Azure.
Este foarte important ca toate rolurile din companie (inclusiv DevOps) să înțeleagă valoarea de business a soluțiilor aeroportuare și impactul lor asupra utilizatorilor și a pasagerilor.
În cazul de față avem:
Este un sistem de afișare a informațiilor de zbor pentru pasageri dar și pentru stafful din aeroporturi. O întrerupere a sistemului ar duce la oprirea majorității operațiunilor din aeroport pentru că pasagerii nu ar găsi birourile de check-in, porțile de îmbarcare sau benzile de bagaje corecte. VisionAir găzduiește mai bine de 5000 de clienți (ecrane) în aeroportul pentru care facem migrarea.
Este un sistem pentru vizualizarea și controlul operațiunilor aeroportuare, un digital twin al aeroportului. Totul, de la mișcarea avioanelor până la cozile formate de pasageri, este vizibil în timp real. O întrerupere a acestui sistem ar lăsa centrele de comandă și control cu zero vizibilitate asupra a ceea ce se întâmplă în aeroport. Soluția este folosită în cel puțin 12 centre de comandă și control (în aeroport și pentru liniile aeriene) cât și de utilizatori individuali la stațiile personale de lucru.
Este o aplicație mobilă destinată personalului din aeroporturi, folosită pentru comunicarea de informații importante și coordonarea operațiunilor din aeroporturi. O întrerupere a sistemului ar reduce drastic eficiența de operare în aeroport. Aplicația are aproximativ 60.000 utilizatori care pot fi afectați de migrare.
Toate sistemele sunt bazate pe tehnologii web și construite după o arhitectură de nivel înalt comună, redundantă:
Dacă VisionAir și RealTime au o infrastructură specializată (per client = single tenant), Community App are în schimb o infrastructură unică (multi tenant), partajată între mai mult de 30 de aeroporturi internaționale. Având o infrastructură multi tenant, migrarea datelor a implicat modificări și la nivel de cod în backendul aplicației pentru a îndeplini cerințele legale.
Este un software open-source pe care l-am folosit pentru a crea Infrastructure as Code. Terraform codifică API-urile Cloud providerilor în fișiere de configurare declarative într-un limbaj simplu numit HCL (HashiCorp Configuration Language).
De ce am ales Terraform?
pentru minimizarea erorilor umane și creșterea automatizării prin păstrarea infrastructurii sub formă de cod;
pentru furnizarea unei infrastructuri în peste 300 cloud providers în doar câteva minute;
Alternative IaC în funcție de cloudul destinație: Azure Resource Manager, AWS CloudFormation și Google Cloud Deployment Manager, iar printre cele cloud agnostic: Ansible, Chef etc.
Este un software open-source care funcționează prin SSH și pe care l-am folosit pentru a instala software-ul și a modifica setările sistemului, având un rol extrem de important în automatizare.
De ce am ales Ansible?
Din experiența noastră, există cel puțin două avantaje care fac din Ansible instrumentul nostru preferat de automatizare:
Este fără agent, ceea ce înseamnă că nu necesită instalarea de software suplimentar pe mașinile pe care le controlăm. Acest lucru ajută la menținerea curată a instalării, asigurându-ne în același timp că nu există conflicte cu software-ul nostru.
Alternative: Puppet, Chef sau configurarea manuală.
Face parte din GitLab și este un tool folosit pentru toate metodele continue (integrare continuă, livrare și implementare). GitLabCI rulează scripturi automate (secvențial sau în paralel) pentru a construi și testa aplicația.
De ce am ales GitLabCI?
Principalul motiv a fost "totul într-un singur loc", GitlabCI fiind deja încorporat în locul în care ne ținem codul sursă (GitLab), iar cel de-al doilea motiv este legat de compatibilitățile cloud native pe care le oferă (Kubernetes, Terraform etc.).
Alternative: Jenkins, TravisCI, CircleCI, Azure Pipelines etc.
Planul de migrare a constat în câțiva pași:
Construirea unei infrastructuri în Azure;
Pregătirea infrastructurii;
Deploymentul serviciilor;
Testarea serviciilor;
Construirea infrastructurii este etapa în care am pregătit fișierele de configurare folosind Terraform. Fișierele de configurare sunt stocate într-un repository, în cazul nostru Gitlab. Structura proiectului a constat în două directoare, unul în care am păstrat modulele și altul în care am păstrat configurațiile cu datele de intrare pentru fiecare sistem.
Configurarea fișierelor a constat în primul rând în definirea modulelor pentru fiecare resursă pe care ne-am dorit să o construim. Modulele sunt configurații Terraform, care permit abstractizarea unei părți comune a infrastructurii și reutilizarea ulterioară cu diferite intrări.
Modulele se definesc în funcție de providerul în care dorim să creăm infrastructura, în cazul nostru Azure și sunt folosite ulterior de către fiecare aplicație/sistem. În directorul destinat aplicațiilor definim datele de intrare specifice fiecărui sistem.
După definirea datelor de intrare am folosit Terraform CLI (Command Line Interface) pentru aplicarea configurațiilor și crearea infrastructurii. Aceleași fișiere de configurare pot fi folosite și în situații de disaster recovery, permițând refacerea întregii infrastructuri în câteva minute.
Folosindu-ne de Ansible playbooks am instalat și configurat procesele de care avem nevoie pe fiecare sistem și am modificat setările actuale a sistemelor după politica de standardizare internă. Standardizarea constă într-o colecție de roluri (playbook) care ajută la aplicarea unui setup inițial pentru fiecare mașină nouă achiziționată. Câteva exemple de roluri: set_language, set_ntp, set_timezone, set_color_prompt, set_logrotate, set_iptables_rules, set_authorized_keys, set_server_name care presupun modificarea setărilor actuale a mașinilor.
După setupul inițial folosim playbooks pentru instalarea de software precum Docker - cu rolul de container runtime, Netdata - colectarea metricilor de pe host în timp real etc.
În acest moment avem o infrastructură configurată cu toate dependințele instalate și configurate, necesare sistemelor pentru a funcționa în parametri.
Întreaga parte de CI/CD este configurată în GitLabCI, soluția folosită pentru Continuous Integration/Continuous Deployment.
Definim foarte pe scurt ce înseamnă conceptele CI/CD:
CI (Continuous Integration) - presupune ca fiecare modificare transmisă unei aplicații stocate într-un repository de Git in Gitlab este construită și testată automat și continuu folosind un set de scripturi.
Merită menționat faptul că toate aplicațiile în discuție sunt containerizate folosind Docker în calitate de Container Runtime și sunt orchestrate utilizate Docker Swarm.
Structura pipeline-ului va fi una generică deoarece singura diferență o face codul sursă și testele aferente. Pipeline-ul se configurează pe fiecare proiect în parte, fiind responsabil de întregul proces CI/CD care presupune: build, test, staging, production.
Rolul fiecărui stage din pipeline:
build: construirea imaginilor de docker pe baza Dockerfiles;
test: aplicarea diferitelor teste la nivel de cod;
staging: deploymentul aplicației într-un mediu de staging;
Am adăugat încă un pas în stage-ul de Production configurat să redirecționeze către nouă infrastructură (Azure) care să facă deployment cu aplicația echivalentă pentru producție. Practic, am avut același setup în doi cloud provider diferiți, însă mai lipseau datele.
Migrarea datelor în cazul sistemelor single tenant (VisionAir și RealTime) a fost relativ simplă, printr-un dump și un restore la baza de date am reușit să migrăm toate datele de care aveau nevoie cele două sisteme.
Community App a fost un caz particular doar prin simplu motiv că are o infrastructură multi tenant, partajată cu alte peste 30 de aeroporturi. Migrarea în cazul acestui sistem a fost făcută cu ajutorul unui serviciu configurat să replice doar colecțiile din baza de date specifice aeroportului pentru care s-a făcut migrarea.
Serviciul a fost implementat ca serviciu de Docker pe infrastructura din Azure, iar scopul particular al acestui serviciu a fost replicarea anumitor colecții (folosim baze de date non-relaționale) din baza de date actuală de producție în cea migrată. Precum am ilustrat în figura de mai sus, de fiecare dată când colecțiile specifice se populează cu date, acest serviciu va replica instant datele și în baza de date din Azure.
Aplicațiile fiind extrem de complexe, testarea lor este un pas esențial pentru a asigura succesul migrării. Toate aplicațiile se bazează pe date care sunt integrate de la alte sisteme aeroportuare (cum ar fi RADAR). Pentru a putea testa aplicațiile am abordat două strategii:
Implementarea unui sistem double drop (în care datele primite de la alte sisteme sunt replicate atât către stackul "vechi" cât și către stackul nou);
Din fericire ambele metode sunt suportate de ADR ("AirportLabs Data Router"), soluția de integrarea de date a firmei.
Redirecționarea URL-urilor spre noul stack s-a realizat din DNS, prima dată reducând TTL(Time To Live) la valoarea minimă, iar apoi modificând astfel încât să indice către stackul nou. Această abordare are avantajul că nu necesită nicio modificare pentru clienți, iar în caz de probleme, schimbarea poate fi făcută către vechiul stack de servicii, cu un timp de refacere maxim egal cu TTL-ul configurat. Pe intervalul de migrare avem opțiunea de a sincroniza între stackul nou și stackul vechi orice informații specifice conexiunii unui client anume ("state") pentru a asigura o trecere fără întreruperi.
În general se recomandă start-upurilor să accelereze dezvoltarea de produse folosind componente preconstruite oferite de furnizorii de servicii cloud.
Când am început dezvoltarea soluțiilor noastre am luat în considerare efortul de dezvoltare versus lipsa de portabilitate între furnizori. Prin urmare, am decis să construim totul intern, alegând să folosim exclusiv puterea de procesare, stocare și conexiune la rețea de la furnizorii de cloud. În cazul acestei migrări alegerea s-a dovedit corectă, având în vedere că nu a existat nicio dependință de un anumit furnizor.
În procesul de migrare au fost implicate mai multe echipe din cadrul companiei: DevOps, Development, Project Management și Quality Assurance. Colaborarea între aceste echipe e ceea ce a dus la succesul migrării.
de Ovidiu Mățan
de Ovidiu Mățan
