ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 125
Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 85
Abonament PDF

Administrarea unui sistem serverless cu Terraform în AWS

Vlad Cenan
DevOps Engineer @ Endava
PROGRAMARE

Construirea și administrarea unei infrastructuri serverless cu terraform în Amazon Cloud a presupus întâlnirea cu o serie de obstacole, precum comiterea unor erori. Acest articol își propune să ofere o serie de recomandări, care odată puse în aplicare, vor reduce riscul apariției de erori.

Terraform este instrumentul perfect pentru Infrastructure as Code, folosit atunci când este necesar de furnizat și administrat un serverless stack în Amazon Cloud.

Ce înseamnă Serverless?

Serverless computing este un model de calcul în care un furnizor de servicii cloud gestionează automat furnizarea și alocarea resurselor.

Această implementare a arhitecturii serverless este numită Functions as a Service (FaaS).

De ce Serverless?

Utilizarea serviciilor serverless a avut o mulțime de avantaje și beneficii datorită faptului că se plătește numai pentru execuție și durată, nu s-a investit timp pentru administrarea de servere, sisteme de operare sau alte aplicații ca dependințe. De asemenea, serviciile serverless oferă o autonomie ridicată, care reduce timpul de lucru pe arhitectură și configurează aceste elemente în mediul AWS.

Un dezavantaj a fost faptul că ne-am confruntat cu unele blocaje de I/O care nu s-au putut replica și cu lipsa de vizibilitate în depanarea fluxurilor aplicației.

Recomandări

Securitate

Parolele hardcoded nu sunt periculoase doar din cauza hackerilor și a atacurilor de tip DDoS și malware, ci și pentru că îngreunează refolosirea codului sursă.

AWS Secret Manager este un serviciu pentru administrarea credențialelor, stocarea, extragerea și rotarea cheilor de acces între resurse.

Asigurați-vă că stocați credențialele și cheile de access într-un secret manager tool, nu pe laptopul propriu sau hardcoded în codul sursă găzduit în git.

Versionare

Funcția lambda conține codul sursă și dependințele în format zip, iar arhiva este încărcată într-un S3 bucket pe baza unui indicator de timp.

În cazul de față, indicatorul de timp dă numele versiunii funcției lambda și cheii folosite de terraform pentru a găsi arhiva funcției lambda în bucket:

Pentru o bună gestionare a aplicației, a fost adăugat un fișier de manifest, actualizat automat la fiecare build, cu rolul de a stoca versiunile funcțiilor lambda aferente fiecărui release. Pe baza acestui fișier, aplicația poate fi lansată în mediul de lucru și se poate reveni cu ușurință la o versiune anterioară în caz de nevoie.

Resurse

Este mai bine să împărțim dependințele pentru o resursă în mai multe părți componente, decât să avem un singur fișier mare de configurare.

În exemplul de mai jos, resursa funcției lambda va lua rolul ce îi dă dreptul de a accesa resurse AWS dintr-un alt fișier de configurare iam.tf (fișier responsabil pentru crearea tuturor rolurilor și permisiunilor pentru resursele AWS) și va prelua definiția de rol dintr-un fișier extern:

Astfel, veți ușura procesul de debugging, iar componentele vor putea fi refolosite și în alte module. Toate acestea vor duce la o vizibilitate sporită asupra funcționalității codului de infrastructură.

Variabile

După divizarea codului de infrastructură pe componente, e necesar să se folosească terraform remote state pentru a utiliza variabile între module.

În cazul de față, după implementarea unui flux lambda, se vrea atașarea unei notificări pe baza unui eveniment pentru o funcție lambda. Pentru aceasta, luăm din remote state (data store care deține resursele și metadata pentru infrastructura creată) numele resursei create și o atașăm în fluxul curent care va implementa notificările.

Environment

Pentru a evita duplicarea codului, utilizați terraform workspace pentru separarea mediilor de lucru.

Toate mediile sunt gestionate ca o bază de cod și sunt găzduite într-un git repo. Există mai multe abordări de împărțire a configurării între mediile de lucru. Se pot utiliza subfoldere, o soluție care îngreunează întreținerea codului din cauza fișierelor duplicate. Începând cu Terraform, versiunea 0.10 se poate utiliza comanda workspace pentru organizarea infrastructurii.

Ambele abordări au compromisuri, dar terraform workspace este o funcție excelentă care poate fi utilizată pentru a separa mediul actual cu scopul de a testa o nouă funcționalitate.

Logare

În mod implicit, toate logurile sunt monitorizate cu AWS CloudWatch. Pentru o vizualizare mai bună, se pot crea dashboarduri personalizate cu acest serviciu, dar chiar și așa, există nevoia de a naviga prin mai multe ecrane pentru a obține logurile și valorile dorite, ceea ce creează un dezavantaj în depanarea fluxurilor aplicației. Pentru a evita acest inconvenient, se recomandă serviciul AWS Elasticsearch.

Deoarece grupurile de loguri pentru funcțiile lambda din AWS CloudWatch nu au putut fi manipulate sau îmbinate, s-a folosit CloudWatch ca serviciu de agregare a logurilor, de unde o funcție lambda creată special pentru streaming va prelua logurile și le va transfera în API-ul de import Elasticsearch prin protocolul HTTPS.

Imaginea alăturată arată cum putem căuta eroarea "accessdenied" și numele unei funcții lambda și astfel să descoperim cu ușurință greșeala. În cazul de față, rolul funcției lambda nu are acces la anumite acțiuni în servicul AWS CloudWatch.

Teste Unitare

O necesitate este testarea infrastructurii. Aceasta poate fi făcută prin utilizarea unei librării scrisă în limbajul ruby, care va testa resursele din AWS pe baza unor specificații. În exemplul de mai jos, testele unitare sunt rulate cu succes pentru o tabelă din baza de date AWS DynamoDB a aplicației.

Un dezavantaj este faptul că nu toate resursele din AWS sunt acoperite de această librărie. Menționăm în acest sens servicii precum cum ar fi AthenaDB sau StepFunctions. Din moment ce librăria e doar cod ruby , se poate scrie propriul cod pentru a testa resursele neacoperite sau alte funcționalități specifice aplicației cum ar fi verificarea unui query în baza de date DynamoDB.

În concluzie, testează totul!

Bibliografie

  1. https://www.hashicorp.com/blog
  2. https://www.terraform-best-practices.com/code-structure
  3. https://www.terraform.io/docs/index.html
  4. https://upcloud.com/community/tutorials/terraform-variables/
  5. https://github.com/shuaibiyy/awesome-terraform
  6. https://aws.amazon.com/serverless/
  7. https://github.com/k1LoW/awspec

VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA