Trgovina parametrov AWS proti spremenljivkam okolja

V tem članku bom preučil, ali in kdaj naj se trgovina s parametri AWS uporablja za zamenjavo spremenljivk okolja znotraj infrastrukture AWS. Ne bom gledal, kaj je vsako od teh, ali kako jih postaviti na kakšen poglobljen način, temveč primerjavo med njimi.

Primer za spremenljivke okolja

Enostaven za namestitev

Namestitev s spremenljivkami okolja je precej preprosta. Vozlišče ima na primer modul dotenv, ki ga je mogoče namestiti prek npm z enim ukazom:

npm namestite dotenv

Poskrbeti moramo, da ima dotenv vhodno točko nekje v našem scenariju, ponavadi preko zahtevane izjave -

zahtevati ('dotenv'). config ()

Od tu naprej moramo vse spremenljivke okolja dodati v datoteko .env, ki je nameščena v korenski mapi projekta.

Več informacij o modulu dotenv najdete tukaj:

Upoštevati je treba, da trgovina parametrov na začetku nima enakih vidikov pri enostavni namestitvi - če še nikoli niste delali s Trgovino parametrov, se vam postopek nastavitve lahko zdi precej naporen z nekaj stvarmi:

  • Potrebujete dostop do računa AWS
  • Če želite krmariti po armaturni plošči AWS - še posebej v razdelku SSM, morate vedeti.
  • Občutljivi / varni parametri morajo biti šifrirani s KMS - kar samo po sebi zahteva nekaj dodatnih nastavitev (https://aws.amazon.com/kms/)
  • Za pravilno delovanje trgovine s parametri boste morda potrebovali znanje o konfiguraciji drugih storitev AWS, kot sta IAM in SSM.
  • Vsi parametri so gosti v oblaku, ki zahteva programski dostop IAM, kar pomeni, da je potrebna neprekinjena povezava (upoštevati je treba, da se lahko po lokalnih nastavitvah ustvarijo lokalne spremenljivke, ki se lahko uporabljajo namesto spremenljivk shrambe parametrov, odvisno od situacije - I bi dejansko spodbudil takšen pristop).

Enostaven za posodobitev med razvojem, uvajanjem in testiranjem

Spremenljivke okolja je mogoče enostavno posodobiti s pomočjo zgoraj omenjene datoteke .env in modula dotenv. Različice te datoteke lahko tudi ustvarite in uporabite tako, da ustrezajo vsakemu ustreznemu okolju. Uvoz naših spremenljivk v okolju v testnem scenariju deluje na skoraj enak način (uvoz okolice iz ustrezne datoteke dotenv).

Za uvajanje na strežnik za prikazovanje ali produkcijo bi morali uporabiti le nadomestno različico datoteke .env. To lahko preprosto storite tako, da lokalno (ponavadi git) v vašem sistemu za nadzor različic ignorirate obstoječo datoteko .env in ustvarite novo kopijo na vsakem primerku stopnje / strežnika.

Tudi spremenljivke okolja se lepo integrirajo s sistemi neprekinjene integracije (CI). Na primer, krog CI ima poseben razdelek za upravljanje spremenljivk okolja, kjer jih je mogoče dodati na ravni gradnje projekta in posodobiti na enem mestu, ko so pripravljeni za uvajanje -

Z vidika trgovine Parameter gre za jezikovni / okvirni agnostik, kar pomeni, da bo treba vse nastavitve opraviti ročno z uporabo AWS SDK s programskim dostopom do storitve Parameter Store ali podobno prek ponudnika neodvisnih ponudnikov (na primer npm modul) . Medtem ko so AWS in njegove storitve merilo za varnostne standarde v domeni računalništva v oblaku, pa lahko po meri moduli, ki jih morda želite razviti ali uporabiti, imajo varnostne ranljivosti zaradi zlobe ali nadzora - glede na to, da za to obstajajo moduli, ki so sprejeti v industriji, ki so vzdržuje in potrjuje zaupanja vredna podjetja, kot je AWS.

Z vidika uvajanja / testiranja ima trgovina Parameter tudi edinstven nabor izzivov, saj čeprav obstajajo predlagani pristopi, odvisno od tega, kako in kdaj se boste odločili za interakcijo s Trgovino parametrov.

Spremenljivke okolja so brezplačne za uporabo

Čeprav trgovina s parametri AWS ne vključuje dodatnih stroškov (https://aws.amazon.com/systems-manager/pricing), Amazonova struktura cen za povezane storitve, kot je KMS (https://aws.amazon.com/kms/pricing) ) bodo začeli nastajati dodatni stroški zaradi uporabe. Po drugi strani je uporaba spremenljivk okolja brezplačna.

Zakaj torej zamenjati spremenljivke okolja? : primer za trgovino s parametri

Do zdaj se zdi, da rešitev za vanilijevo okolje spreminja Parameter Store v tekmi za prevlado v areni / varni spremenljivki. Čeprav se zdi, da trgovina parametrov ustvarja več izzivov, kot jih rešuje na tej točki, vendar je nekaj stvari, ki jih trgovina parametrov nedvomno deluje bolje kot spremenljivke okolja:

Spremenljivke trgovin s parametri lahko delite v več projektov

Najboljša nastavitev, ki sem jo našel za skupno rabo spremenljivk okolja med projekti, je uporaba samodejnega postopka uvajanja, ki pridobi datoteke spremenljivke iz datoteke, ki se nahaja v skupni enoti, na primer vedro S3, ki se po potrebi priklopi v konfiguracijo projekta (običajno se izvede prek skript, ki se izvaja iz storitve CI). Iz prejšnjih izkušenj je to najbolj pomensko izvedljiva možnost (sporočite mi, če imate izkušnje z boljšimi možnostmi). To je na žalost dolgočasna vaja in na koncu ni nekaj, kar bi želeli dolgoročno vzdrževati ročno, predvsem zato, ker bi kakršne koli napake ali previdi na poti pri njeni postavitvi ali vzdrževanju lahko povzročile težave.

Vse, kar lahko predamo storitvi AWS za avtomatizacijo, bi morali in to je mesto, kjer sije trgovina s parametri. Skupna raba tipk KMS in spremenljivk shrambe parametrov med projekti je povsem na voljo.

Želim narediti korak nazaj in pogledati AWS iz celostne perspektive. Amazon je odlično opravil z upravljanjem vseh vidikov računalništva v oblaku in ima množico razvojnih skupin, ki so namenjene določenim storitvam, ki jih ti in jaz ne bomo mogli nikoli ponoviti. To končno pomeni, da morate po nakupu v Amazonovo izkušnjo uporabiti vse storitve, ki so zasnovane za skupno delo pod zastavo infrastrukture v oblaku AWS. Čeprav ima svoje težave (kot sta ti in jaz zdaj popolnoma zaklenjen v AWS kot ponudnik storitev), je na koncu lažje naložiti vse, kar lahko, saj je to ena stvar, za katero moraš skrbeti - tudi če stane malo več.

Trgovina parametrov lahko uporablja nadzor dostopa

Zaradi specifičnega nadzora nad dostopom uporabnikov storitev IAM sodi med največje atribute AWS, zlasti ko gre za obravnavo potencialno občutljivih informacij, kot so ključi API ali gesla. Koncept nadzorovanja dostopa do spremenljivk okolja v smislu vanilije (npr. Z uporabo dotenv pristopa) preprosto ni možnost (razen če niste pripravljeni razviti svoje lastne rešitve - ali se premakniti izven področja "najboljših praks").

Vrednosti shranjevanja parametrov se enostavno posodobijo

Če želite posodobiti vse vrednosti v trgovini Parameter, potrebujete ustrezen dostop do svoje nadzorne plošče AWS (ali CLI), kar pomeni, da lahko tudi netehniški člani ekipe posodobijo vrednosti z malo izkušnje na nadzorni plošči AWS.

Na strani spremenljivke okolja postane posodabljanje spremenljivk okolja problematično, saj lahko običajno dostopajo do njih in jih posodobijo le usposobljeni člani skupine, ki imajo dostop do dovoljenj za posodobitev strežnika. Poleg tega to odpira vaš projekt do ranljivosti, saj lahko prijava v strežnik in posodabljanje jedrnih projektnih datotek na poti (tudi ob samodejni namestitvi) povzroči težave.

KMS lahko šifrira vrednosti Parameter Store z lahkoto

Čeprav se začetna nastavitev šifriranja vrednosti v trgovini s parametri morda zdi nekoliko zastrašujoča, je, ko se tega navadiš, povsem preprosta in ima veliko smisla - tudi z netehničnega vidika. To je tudi odlična plast varnosti, ki je dodana zunaj okvira.

Mogoče je uporabiti šifriranje za spremenljivke okolja, ki jih morda ne želite hraniti v navadnem besedilu, vendar je to lahko težko ročno nastaviti in vzdrževati.

Parameter Store spremenljivke je mogoče organizirati

Parametri proizvodnje in uprizarjanja se upravljajo na enem mestu, kadar uporabljate shrambo parametrov, kar vključuje razvrščanje in filtriranje parametrov ter celo dodajanje opisov za razjasnitev njihovega namena.

Z vidika spremenljivke okolja preprosto ne morete izhajati iz spremenljive organizacije. Nekaj ​​spremenljivk okolja je lahko dovolj enostavno za upravljanje, vendar to postane problematično, če je preveč spremenljivk za ročno upravljanje. Morda je mogoče organizirati spremenljivke okolja v različne datoteke in mape, vendar resnično ni primerne rešitve, ki je zunaj okvira, za katero se zdi, da stvari ne bi po nepotrebnem zapletle.

Na koncu je treba odločitev, katero od dveh rešitev uporabiti, določiti glede na kompleksnost in obseg projekta, ob upoštevanju zgoraj omenjenih dejavnikov.

Sklep

Pri izbiri, ali želite uporabljati shrambo parametrov ali spremenljivke okolja za upravljanje s svojimi faznimi / varnimi parametri, morate upoštevati še druge dejavnike, vendar upamo, da smo v tem članku zajeli pomembne.

Če imate še kakšne dejavnike, za katere menite, da so vredni premisleka, bi rad slišal vaše misli.