Съхранение на параметри на AWS срещу променливи на околната среда

В тази статия ще разгледам дали и кога магазинът за параметри на AWS трябва да се използва за замяна на променливи на околната среда в инфраструктурата на AWS. Няма да гледам какви са всяка от тях или как да ги настроя по някакъв задълбочен начин, а по-скоро сравнение между двете.

Случай за променливи в средата

Лесна за настройка

Доста проста е настройката с променливи на средата. Възелът, например, има dotenv модул, който може да бъде инсталиран през npm с една команда:

npm инсталирайте dotenv

Трябва да сме сигурни, че dotenv има входна точка някъде в нашия скрипт, обикновено чрез изявление за изискване -

изискват ( "dotenv"). довереник ()

От тук всичко, което трябва да направим, е да добавим нашите променливи от околната среда към .env файл, поставен в коренната папка на проекта.

Можете да намерите повече информация за модула dotenv тук:

Трябва да се отбележи, че магазинът с параметри първоначално не споделя същите аспекти с лекота на настройка - ако никога досега не сте работили с магазина на параметрите, процесът на настройка може да изглежда доста трудоемък с няколко неща, които трябва да имате предвид:

  • Имате нужда от достъп до AWS акаунт
  • Трябва да знаете как да навигирате в таблото за управление на AWS - по-специално в секцията SSM.
  • Чувствителните / защитени параметри трябва да бъдат криптирани с KMS - което само по себе си изисква някаква допълнителна настройка (https://aws.amazon.com/kms/)
  • В зависимост от вашите нужди може да се нуждаете от познания за конфигурация на други AWS услуги като IAM и SSM поръчка, за да накарате магазина с параметри да работи правилно.
  • Всички параметри са хоствани в облака, изискващ IAM програмен достъп, което означава, че е необходима непрекъсната връзка (трябва да се отбележи, че могат да бъдат създадени локални настройки с локални променливи, които могат да се използват на мястото на променливи в Parameter Store в зависимост от ситуацията - I всъщност би насърчил подобен подход).

Лесен за актуализиране по време на разработка, внедряване и тестване

Променливите на средата могат лесно да бъдат актуализирани чрез гореспоменатия .env файл и модул dotenv. Варианти на този файл също могат да бъдат създадени и използвани, за да отговарят на всяка съответна среда. Импортирането на нашите променливи на околната среда в тестов сценарий работи по същия начин (импортиране на env vars от съответния dotenv файл).

За разполагане на стационарен или производствен сървър, всичко, което бихме направили, е да използваме алтернативна версия на .env файла. Това лесно може да се направи чрез игнориране на съществуващия .env файл във вашата система за контрол на версиите локално (обикновено git) и създаване на ново копие на всеки етап / сървър.

Променливите на средата също се интегрират добре със системите за непрекъсната интеграция (CI). Кръгът CI например има специален раздел за управление на променливи на средата, където те могат да бъдат добавени на ниво изграждане на проект и актуализирани на едно място, когато са готови за внедряване -

От гледна точка на магазина на параметрите, той е езиков / рамков агностик, което означава, че цялата настройка или ще трябва да се извърши ръчно, като се използва AWS SDK с програмен достъп до услугата на магазина на параметрите, или по подобен начин чрез доставчик на трети страни (например npm модул) , Въпреки че AWS и неговите услуги са еталон за стандартите за сигурност в облачната компютърна област, персонализираните модули, които може да искате да разработите или използвате, може да имат уязвимости в сигурността поради злоба или надзор, като се има предвид, че за това има модули, приети в индустрията, които са поддържани и утвърдени от надеждни субекти като самите AWS.

От гледна точка на внедряване / тестване, Parameter Store също идва с уникален набор от предизвикателства, тъй като въпреки че има предложени подходи, как и кога решите да взаимодействате с магазина на параметрите зависи изцяло от вас.

Променливите на околната среда са безплатни за използване

Въпреки че AWS Parameter Store не включва допълнителни такси (https://aws.amazon.com/systems-manager/pricing), ценовата структура на Amazon за свързани услуги като KMS (https://aws.amazon.com/kms/pricing ) ще започне да прави допълнителни разходи въз основа на използване. От друга страна, използването на променливи на околната среда е безплатно.

Така че защо да заменя променливите на средата? : случай за магазина на параметрите

До този момент променливото решение на средата на ванилията сякаш огражда Parameter Store в надпреварата за доминиране в сцената / сигурната променлива арена. Въпреки че в този момент магазинът на параметрите създава повече предизвикателства, отколкото решава, има няколко неща, обаче, че магазинът с параметри безспорно се справя по-добре от променливите на средата:

Променливите в магазина на параметрите могат да се споделят в множество проекти

Най-добрата настройка, която открих за споделяне на променливи от обкръжението в проекти, е да използвам автоматизиран процес на внедряване, който извлича променливи в среда от файл, съдържащ се в споделено образувание, като например кофа S3, която се включва в конфигурацията на проекта според нуждите (обикновено се прави чрез скрипт, който се стартира от CI услуга). От предишния опит това е най-семантично жизнеспособната опция (моля, уведомете ме, ако имате опит с някакви по-добри възможности). Това за съжаление е уморително упражнение първоначално и в крайна сметка не е нещо, което бихте искали да поддържате ръчно в дългосрочен план, което се дължи главно на факта, че всякакви грешки или пропуски по пътя при настройването или поддържането му могат да доведат до проблеми.

Всичко, което можем да предадем на AWS услуга, за да автоматизираме, трябва и това е мястото, където свети Параметърът. Споделянето на KMS клавиши и променливи от магазина на параметрите в проектите излиза нестандартно.

Искам да направя крачка назад и да погледна AWS от холистична гледна точка. Amazon свърши чудесна работа по управлението на всеки аспект на облачните изчисления и разполага с множество екипи за разработки, посветени на конкретни услуги, които вие и аз никога няма да можем да копираме. Това в крайна сметка означава, че след като сте се включили в опита на Amazon, трябва да използвате всички услуги, предназначени да работят заедно под знамето на облачната инфраструктура AWS. Въпреки че има своите проблеми (като вас и аз сега, като сте напълно затворени в AWS като доставчик на услуги), в крайна сметка е по-лесно да разтоварите всичко, което можете, за тях, тъй като това е едно по-малко нещо, за което трябва да се притеснявате - дори и да струва малко повече.

Магазинът на параметрите може да използва контрол на достъпа

Наличието на специфичен контрол върху достъпа на потребителите прави услугата IAM един от най-големите атрибути на AWS, особено когато става въпрос за работа с потенциално чувствителна информация, като например ключове или пароли за API. Концепцията за контрол на достъпа до променливите на средата във ваниловия смисъл (напр. Използване на dotenv подхода) просто не е опция (освен ако не сте готови да разработите свое собствено решение - или да се преместите извън сферата на „най-добрите практики“).

Стойностите на магазина за параметри се актуализират лесно

За да актуализирате всички стойности във вашия Parameter Store, всичко, от което се нуждаете, е подходящ достъп до таблото за управление на AWS (или CLI), което означава, че дори нетехническите членове на екипа могат да актуализират стойности с малко опит на таблото за AWS.

От страна на променливата на средата на аргумента актуализирането на променливите на средата става проблематично, тъй като обикновено само квалифицирани членове на екипа, които имат достъп до разрешения за актуализиране на сървъри, ще могат да получат достъп и да ги актуализират. Освен това това отваря вашия проект до слой на уязвимост, тъй като влизането в сървър и актуализирането на основните файлове на проекта в движение (дори при автоматизирана настройка) може да доведе до проблеми.

KMS може да кодира стойностите на Parameter Store лесно

Въпреки че първоначалната настройка на криптиращите стойности в магазина на параметри може да изглежда малко обезсърчаваща, след като свикнете с нея, тя е доста проста и има много смисъл - дори от нетехническа гледна точка. Това също е страхотен слой на сигурността, който се добавя извън кутията.

Възможно е да се използва криптиране за променливи от средата, които може да не искате да съхранявате в обикновен текст, но това може да бъде трудно да се настроят и поддържат ръчно.

Параметри за съхраняване на променливи могат да бъдат организирани

Параметрите за производство и стадиране се управляват на едно място при използване на магазина с параметри, което включва сортиране и филтриране на параметри и дори добавяне на описания, за да се изясни тяхното предназначение.

От гледна точка на променлива среда, просто не можете да излезете от организация с променливи. Наличието на няколко променливи на средата може да е достатъчно лесно за управление, но това става проблематично, когато има твърде много променливи, които да се управляват ръчно. Може да е възможно да се организират променливи на околната среда в различни файлове и папки, но наистина няма надеждно решение за това, което не изглежда излишно да усложнява нещата.

В крайна сметка решението за това кое от двете решения да се използва трябва да се определя от сложността и обхвата на проекта, като се вземат предвид факторите, споменати по-горе.

заключение

Има и други фактори, които трябва да вземете предвид, когато избирате дали да използвате Параметър Магазин или променливи на обкръжението, за да управлявате вашите параметри на етап / защита, но се надяваме в тази статия да разгледаме важните.

Ако имате някакви други фактори, които смятате, си струва да се разгледат, бих искал да чуя вашите мисли.