„AWS“ parametrų saugykla ir aplinkos kintamieji

Šiame straipsnyje apžvelgsiu, ar reikia naudoti AWS parametrų saugyklą, norint pakeisti aplinkos kintamuosius AWS infrastruktūroje. Aš nežvelgsiu į tai, kas iš jų yra, ar kaip juos išsamiai išdėstyti, o aš palyginsiu juos.

Aplinkos kintamųjų atvejis

Lengva nustatyti

Nustatyti aplinkos kintamuosius yra gana paprasta. Pvz., Mazgas turi „dotenv“ modulį, kurį galima įdiegti per npm naudojant vieną komandą:

npm įdiegti dotenv

Turime įsitikinti, kad „dotenv“ kažkur mūsų scenarijuje turi įėjimo tašką, paprastai per reikalavimo pareiškimą -

reikalauti ('dotenv'). config ()

Čia viskas, ką mums reikia padaryti, tai pridėti savo aplinkos kintamuosius į .env failą, esantį pagrindiniame projekto aplanke.

Daugiau informacijos apie „dotenv“ modulį rasite čia:

Reikėtų pažymėti, kad „Parameter Store“ iš pradžių nesiskiria tais pačiais aspektais, kad būtų lengva juos nustatyti - jei jūs niekada anksčiau nebendravote su „Parameter Store“, sąrankos procesas gali atrodyti gana daug darbo reikalaujantis, atsižvelgiant į keletą dalykų:

  • Jums reikia prieigos prie AWS paskyros
  • Turite žinoti, kaip naršyti AWS prietaisų skydelyje, ypač SSM skyriuje.
  • Jautrūs / saugūs parametrai turėtų būti užšifruoti naudojant KMS - tam jau reikia šiek tiek papildomų sąrankų (https://aws.amazon.com/kms/).
  • Atsižvelgiant į jūsų poreikius, jums gali prireikti kitų AWS paslaugų, tokių kaip IAM ir SSM, konfigūravimo žinių, kad „Parameter Store“ veiktų tinkamai.
  • Visi parametrai yra talpinami debesyje, kuriai reikalinga IAM programinė prieiga, o tai reiškia, kad reikalingas nenutrūkstamas ryšys (reikėtų pažymėti, kad vietinius kintamuosius galima sukurti naudojant vietinius kintamuosius, kurie gali būti naudojami vietoje „Parameter Store“ kintamųjų, atsižvelgiant į situaciją - aš iš tikrųjų skatintų tokį požiūrį).

Lengva atnaujinti kuriant, diegiant ir testuojant

Aplinkos kintamuosius galima lengvai atnaujinti naudojantis minėtu .env failu ir dotenv moduliu. Šio failo variantus taip pat galima sukurti ir panaudoti atsižvelgiant į kiekvieną aplinką. Aplinkos kintamųjų importavimas į bandymo scenarijų veikia panašiai (ENV variklius importuoja iš atitinkamo dotenv failo).

Diegdami į etapų arba gamybos serverį, mes tik pasinaudosime alternatyvia .env failo versija. Tai lengvai galima padaryti ignoruojant esamą .env failą jūsų versijų valdymo sistemoje vietoje (paprastai git) ir sukuriant naują kopiją kiekviename etape / serverio egzemplioriuje.

Aplinkos kintamieji taip pat gražiai integruojasi į nuolatinės integracijos sistemas (CI). Pvz., „Circle CI“ turi skyrių, skirtą aplinkos kintamiesiems valdyti, kur juos galima pridėti projekto kūrimo lygiu ir atnaujinti vienoje vietoje, kai jie paruošti diegimui -

Žvelgiant iš „Parameter Store“ perspektyvos, tai yra kalbos / struktūros agnostika, tai reiškia, kad visą sąranką reikės atlikti rankiniu būdu, naudojant AWS SDK su programine prieiga prie „Parameter Store“ paslaugos, arba panašiai per trečiosios šalies teikėją (pvz., Npm modulį). . Nors AWS ir jos paslaugos yra debesų kompiuterijos srities saugos standartų etalonas, pasirinktiniai moduliai, kuriuos galbūt norėsite sukurti ar panaudoti, gali turėti saugumo pažeidžiamumų dėl piktnaudžiavimo ar priežiūros - turint omenyje, kad yra tam pramonėje priimtų modulių, kurie yra prižiūrimi ir patvirtinami patikimų subjektų, tokių kaip patys AWS.

Diegimo / bandymo požiūriu „Parameter Store“ taip pat susiduria su unikaliu iššūkių rinkiniu, nes, nors ir yra siūlomi metodai, vis tiek jūs galite nuspręsti, kaip ir kada norite bendrauti su „Parameter Store“.

Aplinkos kintamieji yra laisvai naudojami

Nors „AWS Parameter Store“ neapima papildomų mokesčių (https://aws.amazon.com/systems-manager/pricing), „Amazon“ kainų struktūra susijusioms paslaugoms, tokioms kaip KMS (https://aws.amazon.com/kms/pricing) ) pradės patirti papildomų išlaidų, susijusių su naudojimu. Kita vertus, naudoti aplinkos kintamuosius yra nemokama.

Taigi kodėl pakeisti aplinkos kintamuosius? : „Parametrų parduotuvės“ dėklas

Iki šiol atrodo, kad vanilės aplinkos kintamasis sprendimas aplenkia „Parametrų parduotuvę“, siekdamas dominavimo scenoje / saugioje kintamojoje arenoje. Nors atrodo, kad parametrų parduotuvė sukuria daugiau iššūkių, nei ji išsprendžia šiuo metu, vis dėlto yra keletas dalykų, kurie, be abejo, daro parametrų parduotuvę geriau nei aplinkos kintamieji:

Parametrų saugyklos kintamuosius galima bendrinti keliuose projektuose

Geriausias būdas, kurį radau keisdamas aplinkos kintamuosius visuose projektuose, yra naudoti automatinį diegimo procesą, iš kurio aplinkos kintamieji yra gaunami iš failo, esančio bendro naudojimo objekte, pvz., S3 segmento, kuris prireikus įtraukiamas į projekto konfigūraciją (paprastai tai daroma naudojant scenarijus, kuris vykdomas iš CI paslaugos). Remiantis ankstesne patirtimi, tai yra semantiškai perspektyviausias pasirinkimas (praneškite, jei turite kokių nors geresnių variantų). Deja, iš pradžių tai yra varginantis pratimas ir galiausiai tai nėra dalykas, kurį norėtumėte išlaikyti rankiniu būdu ilgainiui. Daugiausia dėl to, kad nustatant ar prižiūrint bet kokias klaidas ar peržiūras, gali kilti problemų.

Viskas, ką galime perduoti AWS tarnybai automatizuoti, turėtume ir būtent čia šviečia „Parametrų parduotuvė“. Dalijimasis KMS klavišais ir „Parameter Store“ kintamaisiais visuose projektuose yra neįmanomas.

Noriu atsitraukti ir pažvelgti į AWS iš holistinės perspektyvos. „Amazon“ atliko puikų darbą tvarkydama kiekvieną debesų kompiuterijos aspektą ir turi daugybę kūrimo komandų, skirtų konkrečioms paslaugoms, kurių jūs ir aš niekada negalėsime atkartoti. Tai galiausiai reiškia, kad įsigiję „Amazon“ patirtį, turėtumėte naudotis visomis paslaugomis, skirtomis dirbti kartu, naudojant AWS debesų infrastruktūros reklamjuostę. Nors ji turi problemų (pvz., Jūs ir aš, kaip paslaugų teikėjas, dabar esame visiškai prisijungę prie AWS), galų gale lengviau atsikratyti visko, ką galite, nes tai yra dar vienas dalykas, dėl kurio turite jaudintis, net jei tai kainuoja šiek tiek papildomai.

Parametrų parduotuvėje galima naudoti prieigos valdymą

Konkrečiai kontroliuodami vartotojo prieigą, IAM paslauga tampa vienu iš didžiausių AWS atributų, ypač kai kalbama apie galimai neskelbtiną informaciją, tokią kaip API raktai ar slaptažodžiai. Prieigos prie aplinkos kintamųjų kontrolės vanilės prasme koncepcija (pvz., Naudojant dotenv metodą) tiesiog nėra išeitis (nebent esate pasirengęs sukurti savo individualų sprendimą - arba išeiti už „geriausios praktikos“ ribų).

„Parameter Store“ vertės lengvai atnaujinamos

Norint atnaujinti bet kokias „Parameter Store“ vertes, jums reikia tinkamos prieigos prie jūsų AWS prietaisų skydelio (arba CLI), tai reiškia, kad net ne techninės komandos nariai gali atnaujinti vertes naudodamiesi šiek tiek „AWS“ prietaisų skydo patirties.

Aplinkos kintamojoje argumento pusėje aplinkos kintamųjų atnaujinimas tampa problematiškas, nes paprastai prieiti ir atnaujinti galės tik kvalifikuoti komandos nariai, turintys prieigą prie serverio atnaujinimo leidimų. Be to, tai atveria jūsų projekto pažeidžiamumo lygmenį, nes prisijungus prie serverio ir atnaujinant pagrindinius projekto failus skrydžio metu (net naudojant automatinę sąranką) gali kilti problemų.

KMS gali lengvai užšifruoti „Parameter Store“ reikšmes

Nors pradinis parametrų parduotuvėje esančių reikšmių šifravimo nustatymas gali atrodyti šiek tiek bauginantis, kai jau pripratai, jis yra gana paprastas ir turi daug prasmės - net ir ne techniniu požiūriu. Tai taip pat yra puikus saugumo sluoksnis, kuris pridedamas, nepaisant jo.

Galima naudoti šifravimą aplinkos kintamiesiems, kurių galbūt nenorite laikyti paprastame tekste, tačiau tai gali būti sunku nustatyti ir prižiūrėti rankiniu būdu.

Gali būti organizuojami parametrų saugyklos kintamieji

Gamybos ir sustojimo parametrai yra valdomi vienoje vietoje naudojant „Parametrų parduotuvę“, kuri apima parametrų rūšiavimą ir filtravimą ir netgi prideda aprašymus, kad paaiškintų jų paskirtį.

Aplinkos kintamojo požiūriu, jūs tiesiog nesuprantate kintamojo organizavimo. Turėti keletą aplinkos kintamųjų gali būti pakankamai lengva valdyti, tačiau tai tampa problematiška, kai yra per daug kintamųjų, kad juos būtų galima valdyti rankiniu būdu. Gali būti įmanoma suskirstyti aplinkos kintamuosius į skirtingus failus ir aplankus, tačiau tikrai nėra perspektyvaus sprendimo, kuris neatrodo be reikalo apsunkinantis.

Galiausiai sprendimas, kurį iš dviejų sprendimų naudoti, turėtų būti nustatomas atsižvelgiant į projekto sudėtingumą ir apimtį, atsižvelgiant į pirmiau minėtus veiksnius.

Išvada

Yra ir kitų faktorių, į kuriuos reikia atsižvelgti renkantis, ar valdyti parametrų saugyklą, ar aplinkos kintamuosius savo scenos / saugiems parametrams valdyti, tačiau tikimės, kad šiame straipsnyje apžvelgsime svarbius.

Jei turite kokių nors kitų veiksnių, kurie, jūsų manymu, yra verti dėmesio, norėčiau išgirsti jūsų mintis.