În calitate de echipă de platformă la Trendyol Tech, unul dintre obiectivele noastre a fost de a face ca gestionarea configurației aplicațiilor și a secretelor să fie dinamică, fiabilă, sigură și să fie abstractizată de aplicații. Folosim de mult timp Kubernetes ConfigMaps și Secrets și acestea nu ne satisfac complet cerințele. De exemplu; atunci când modificăm o configurație pe un ConfigMap, trebuie să repornim podurile noastre de aplicații pentru ca această modificare să intre în vigoare. Uneori este nevoie de câteva minute pentru ca modificarea să se reflecte în toate instanțele aplicației. O altă problemă este că secretele Kubernetes nu sunt suficient de sigure. Avem nevoie ca secretele noastre să fie sigure și auditabile.
Principalele noastre cerințe au fost;
- Ar trebui să putem schimba configurațiile aplicațiilor în mod dinamic fără a reporni procesele aplicațiilor. Când schimbăm o configurație, aceasta ar trebui să afecteze instantaneu toate instanțele aplicației.
- Secretele aplicațiilor noastre trebuie să fie sigure și auditabile. De asemenea, dorim să oferim un control al accesului la secrete bazat pe roluri.
- Trebuie să facem abstracție de gestionarea configurației din aplicații. Cu alte cuvinte, aplicațiile nu ar trebui să știe unde și cum sunt păstrate și furnizate secretele și configurațiile pentru ele.
- Sistemul nostru de gestionare a configurației și secretelor trebuie să fie foarte disponibil și scalabil.
După unele cercetări, am ajuns la 2 aplicații; envconsul și consul-template.
Știam deja că Vault este instrumentul standard al industriei pentru stocarea secretelor. Acesta satisface toate cerințele noastre și are caracteristici precum secretele dinamice, care ar putea fi utile pentru noi în viitor. De asemenea, puteți utiliza Consul ca backend de stocare pentru Vault.
Consul este un instrument distribuit, foarte disponibil și scalabil pentru descoperirea și configurarea serviciilor. În cazul nostru, vom folosi doar caracteristica de stocare cheie-valoare a Consul pentru a păstra configurațiile nesecrete.
Am putea folosi envconsul sau consul-template în principal pentru cea de-a treia cerință: abstractizarea gestionării configurației de la aplicații.
Envconsul oferă o modalitate de a lansa un subproces cu variabilele de mediu populate din Consul și Vault.
Consul-template populează valorile din Consul și Vault în sistemul de fișiere și păstrează valorile sincronizate în timp ce lucrează în modul daemon.
O regulă a aplicației cu doisprezece factori este: stocați configurațiile în mediu. Dar problema cu Envconsul (sau variabilele de mediu) este că nu puteți modifica variabilele de mediu ale unui proces fără a-l reporni. Acest lucru este în contradicție cu prima noastră cerință. Vrem să putem modifica configurațiile fără a reporni procesele aplicației. Acesta este motivul pentru care am decis să optăm pentru consul-template.
În consul-template, puteți utiliza un fișier șablon pentru redarea fișierelor de configurare. Acest lucru ne oferă o mare flexibilitate. Iată un exemplu de fișier șablon;
Consul-template citește acest șablon, înlocuiește caracterele de poziție cu valori din Consul dacă folosiți cuvântul cheie „key” și din Vault dacă folosiți cuvântul cheie „with secret”. Puteți afla mai multe despre limbajul de modelare aici. Fișierul de ieșire redat ar arăta astfel;
server:
port: "8080"
toggles:
fooEnabled: true
database:
username: "username"
password: "password"
.