AWS-parameteropslag versus omgevingsvariabelen

In dit artikel zal ik kijken of en wanneer de AWS Parameter Store moet worden gebruikt om omgevingsvariabelen binnen de AWS-infrastructuur te vervangen. Ik zal niet kijken naar wat elk van deze zijn of hoe ze op een diepgaande manier kunnen worden opgezet, maar eerder een vergelijking tussen de twee.

Een argument voor omgevingsvariabelen

Eenvoudig in te stellen

Het is vrij eenvoudig om setup met omgevingsvariabelen te krijgen. Node heeft bijvoorbeeld een dotenv-module die via npm kan worden geïnstalleerd met een enkele opdracht:

npm installeer dotenv

We moeten ervoor zorgen dat dotenv ergens in ons script een toegangspunt heeft, meestal via een vereiste -verklaring -

require ( 'dotenv'). config ()

Vanaf hier hoeven we alleen onze omgevingsvariabelen toe te voegen aan een .env-bestand in de hoofdmap van het project.

Meer informatie over de dotenv-module vindt u hier:

Opgemerkt moet worden dat de Parameter Store in eerste instantie niet dezelfde aspecten deelt in het gemak van installatie - als u nog nooit eerder met de Parameter Store hebt gewerkt, kan het installatieproces nogal omslachtig lijken met een paar dingen om te overwegen:

  • U hebt toegang nodig tot een AWS-account
  • U moet weten hoe u door het AWS-dashboard navigeert, met name het SSM-gedeelte.
  • Gevoelige / veilige parameters moeten worden gecodeerd met KMS - wat op zichzelf een aantal extra instellingen vereist (https://aws.amazon.com/kms/)
  • Afhankelijk van uw behoeften, heeft u mogelijk configuratiekennis nodig van andere AWS-services zoals IAM en SSM om de Parameter Store correct te laten werken.
  • Alle parameters worden gehost in de cloud waarvoor IAM-programmatische toegang vereist is, wat betekent dat een ononderbroken verbinding vereist is (er moet worden opgemerkt dat op maat gemaakte lokale instellingen kunnen worden gemaakt met lokale variabelen die kunnen worden gebruikt in plaats van Parameter Store-variabelen afhankelijk van de situatie— I zou in feite een dergelijke aanpak aanmoedigen).

Eenvoudig te updaten tijdens ontwikkeling, implementatie en testen

Omgevingsvariabelen kunnen eenvoudig worden bijgewerkt via het bovengenoemde .env-bestand en de dotenv-module. Variaties van dit bestand kunnen ook worden gemaakt en gebruikt voor elke relevante omgeving. Het importeren van onze omgevingsvariabelen in een testscenario werkt op vrijwel dezelfde manier (het importeren van env-bestanden uit het relevante dotenv-bestand).

Voor implementatie op een staging- of productieserver zouden we alleen een alternatieve versie van het .env-bestand gebruiken. Dit kan eenvoudig worden gedaan door het bestaande .env-bestand in je versiebeheersysteem lokaal te negeren (meestal git) en een nieuwe kopie te maken voor elke fase / serverinstantie.

Omgevingsvariabelen kunnen ook mooi worden geïntegreerd met Continuous Integration-systemen (CI). Circle CI heeft bijvoorbeeld een speciale sectie voor het beheren van omgevingsvariabelen waar ze kunnen worden toegevoegd op projectbouwniveau en op één plek kunnen worden bijgewerkt wanneer ze gereed zijn voor implementatie -

Vanuit het perspectief van de Parameter Store is het agnostisch voor taal / framework, wat betekent dat alle instellingen handmatig moeten worden uitgevoerd met behulp van een AWS SDK met programmatische toegang tot de Parameter Store-service, of op vergelijkbare wijze via een externe partij (zoals een npm-module) . Hoewel AWS en zijn services de maatstaf zijn voor beveiligingsstandaarden in het cloud computing-domein, kunnen aangepaste modules die u mogelijk wilt ontwikkelen of gebruiken beveiligingsproblemen hebben door kwaadwilligheid of toezicht - rekening houdend met het feit dat er hiervoor in de branche geaccepteerde modules zijn onderhouden en goedgekeurd door vertrouwde entiteiten zoals AWS zelf.

Vanuit het oogpunt van implementatie / testen komt de Parameter Store ook met een unieke reeks uitdagingen, want hoewel er voorgestelde benaderingen zijn, is het geheel aan u hoe en wanneer u ervoor kiest om met de Parameter Store te communiceren.

Omgevingsvariabelen zijn gratis te gebruiken

Hoewel AWS Parameter Store geen extra kosten (https://aws.amazon.com/systems-manager/pricing) bevat, is de prijsstructuur van Amazon voor gerelateerde services zoals KMS (https://aws.amazon.com/kms/pricing ) extra kosten gaan maken op basis van gebruik. Aan de andere kant is het gebruik van omgevingsvariabelen gratis.

Dus waarom omgevingsvariabelen vervangen? : een zaak voor de Parameter Store

Tot nu toe lijkt de vanille-omgeving variabele oplossing de Parameter Store te verslaan in de race om dominantie in de stage / veilige variabele arena. Hoewel de Parameter Store op dit moment meer uitdagingen lijkt te creëren dan het op dit moment oplost, zijn er echter een paar dingen die de Parameter Store onbetwist beter doen dan omgevingsvariabelen:

Parameter Store-variabelen kunnen over meerdere projecten worden gedeeld

De beste instelling die ik heb gevonden voor het delen van omgevingsvariabelen binnen projecten is het gebruik van een geautomatiseerd implementatieproces dat omgevingsvariabelen ophaalt uit een bestand in een gedeelde entiteit, zoals een S3-bucket die indien nodig op de projectconfiguratie aansluit (meestal gedaan via een script dat wordt uitgevoerd vanuit een CI-service). Uit eerdere ervaringen is dit de meest semantisch haalbare optie (laat het me weten als je ervaring hebt met betere opties). Dit is helaas in het begin een vervelende oefening en uiteindelijk niet iets dat u op de lange termijn handmatig wilt handhaven, vooral omdat eventuele fouten of vergissingen tijdens de installatie of het onderhoud tot problemen kunnen leiden.

Alles wat we aan een AWS-service kunnen overhandigen om te automatiseren, zouden we moeten doen en dit is waar de Parameter Store schittert. Het delen van KMS-sleutels en Parameter Store-variabelen binnen projecten komt direct uit de doos.

Ik wil een stap terug doen en AWS vanuit een holistisch perspectief bekijken. Amazon heeft geweldig werk verricht bij het beheren van elk aspect van cloud computing en heeft een overvloed aan ontwikkelingsteams die zijn toegewijd aan specifieke services die u en ik nooit zullen kunnen repliceren. Dit betekent uiteindelijk dat je, eenmaal je de ‘ervaring’ van Amazon hebt gekocht, gebruik moet maken van alle diensten die zijn ontworpen om samen te werken onder de vlag van de AWS-cloudinfrastructuur. Hoewel het zijn problemen heeft (zoals jij en ik nu volledig worden opgesloten in AWS als een serviceprovider), is het uiteindelijk gemakkelijker om alles wat je kunt naar hen te verplaatsen, omdat het een ding is waar je je minder zorgen over hoeft te maken - zelfs als het kost een beetje extra.

Parameter Store kan toegangscontrole gebruiken

Door specifieke controle over gebruikerstoegang is de IAM-service een van de grootste kenmerken van AWS, vooral als het gaat om het omgaan met mogelijk gevoelige informatie zoals API-sleutels of wachtwoorden. Het concept van het beheersen van de toegang tot omgevingsvariabelen in de vanille-zin (bijvoorbeeld met behulp van de dotenv-benadering) is gewoon geen optie (tenzij u bereid bent om uw eigen oplossing op maat te ontwikkelen - of buiten het bereik van ‘best practices’ te stappen).

Parameter Winkelwaarden kunnen eenvoudig worden bijgewerkt

Om waarden in uw Parameter Store bij te werken, heeft u alleen toegang tot uw AWS-dashboard (of de CLI) nodig, wat betekent dat zelfs niet-technische teamleden waarden kunnen bijwerken met een beetje AWS-dashboardervaring.

Aan de kant van de omgevingsvariabele van het argument wordt het bijwerken van omgevingsvariabelen problematisch omdat meestal alleen ervaren teamleden die toegang hebben tot serverupdatemachtigingen, deze kunnen openen en bijwerken. Bovendien opent dit uw project voor een kwetsbaarheidslaag, omdat inloggen op een server en het onmiddellijk bijwerken van kernprojectbestanden (zelfs op een geautomatiseerde installatie) tot problemen kan leiden.

KMS kan Parameter Store-waarden eenvoudig coderen

Hoewel de initiële instelling van coderingswaarden in de Parameter Store een beetje ontmoedigend lijkt, is het, zodra je eraan gewend bent, vrij eenvoudig en heel logisch - zelfs vanuit een niet-technisch perspectief. Dit is ook een geweldige beveiligingslaag die out-of-the-box wordt toegevoegd.

Het is mogelijk om codering te gebruiken voor omgevingsvariabelen die u misschien niet in platte tekst wilt opslaan, maar dit kan moeilijk zijn om handmatig in te stellen en te onderhouden.

Parameter Store-variabelen kunnen worden georganiseerd

Productie- en Staging-parameters worden op één plaats beheerd bij het gebruik van de Parameter Store, die sorteer- en filterparameters omvat en zelfs beschrijvingen toevoegt om hun doel te verduidelijken.

Vanuit het perspectief van een omgevingsvariabele krijgt u niet gewoon een kant-en-klare variabele organisatie. Het is misschien eenvoudig om enkele omgevingsvariabelen te beheren, maar dit wordt problematisch als er te veel variabelen zijn om handmatig te beheren. Het is misschien mogelijk om omgevingsvariabelen in verschillende bestanden en mappen te organiseren, maar er is echt geen bruikbare out-of-the-box oplossing die de zaken niet onnodig ingewikkeld lijkt te maken.

Uiteindelijk moet de beslissing over welke van de twee te gebruiken oplossingen worden bepaald door de complexiteit en de reikwijdte van het project, rekening houdend met de bovengenoemde factoren.

Gevolgtrekking

Er zijn andere factoren waarmee u rekening moet houden bij het kiezen of u de Parameter Store of omgevingsvariabelen wilt gebruiken om uw fase / veilige parameters te beheren, maar hopelijk hebben we in dit artikel de belangrijke behandeld.

Als u nog andere factoren hebt die u het overwegen waard vindt, hoor ik graag uw gedachten.