Ось як ви насправді можете використовувати змінні середовища Node

Змінні середовища є фундаментальною частиною розробки Node, але з якихось причин я ніколи не заморочувався навчитися їх правильно використовувати.

Можливо, тому, що вони називаються "Змінні середовища".

Тільки слова “Змінна середовища” викликають ретроспективний зв’язок із ПТСР, в якому я намагаюся додати правильний шлях до каталогу Java Home у Windows. Це йде в PATH або JAVA_HOME або в обидва? Чи потрібно закінчувати це крапкою з комою? ЧОМУ Я ВИКОРИСТОВУЮ JAVA?

У Node змінні середовища можуть бути глобальними (як у Windows), але часто використовуються з певним процесом, який потрібно запустити. Наприклад, якщо у вас була веб-програма, у вас можуть бути змінні середовища, які визначають:

  • Порт HTTP для прослуховування
  • Рядок підключення до бази даних
  • JAVA_HOME ... почекайте ... ні - вибачте. Процес загоєння вимагає часу.

У цьому контексті змінні середовища насправді більше нагадують "Налаштування конфігурації". Подивіться, наскільки приємніше це звучить?

Якщо ви вже робили .NET, можливо, вам було знайомо щось на зразок web.configфайлу. Змінні середовища вузла працюють майже так само, як і параметри в web.config- вони дозволяють вам передавати інформацію, яку ви не хочете жорстко кодувати.

Але як ви використовуєте ці змінні у своїй програмі Node? Мені було важко знайти хороші ресурси з цього питання з необхідною кількістю жартів на Java, тому я вирішив створити такий. Ось декілька різних способів визначити, а потім прочитати змінні середовища у своїх програмах Node.

Передайте його в термінал

Ви можете передавати змінні середовища на термінал як частину вашого процесу Node. Наприклад, якщо ви запускали програму Express і хотіли пройти через порт, ви можете зробити це так ...

PORT=65534 node bin/www

Цікавий факт: порт 65535 - це найбільше значення мережі TCP / IP. Звідки я це знаю? StackOverflow, звичайно. Звідки хтось що-небудь знає? Але ви можете піднятися лише до порту 65534 для веб-програми, оскільки це найвищий порт, до якого Chrome під’єднається. Звідки я це знаю ? Тому що Ліран Тал сказала мені в коментарях. Ви повинні піти за ним. Між нами двома він знає, що робить.

Тепер, щоб використовувати змінну у коді, ви б використовували process.envоб’єкт.

var port = process.env.PORT;

Але це може стати потворним. Якщо у вас був рядок з'єднання, ви, мабуть, не хотіли б починати передавати кілька змінних на терміналі. Здавалося б, ви накопичуєте значення конфігурації, і хтось, хто вас любить, міг би здійснити втручання, і це було б незручно для всіх залучених.

PORT=65534 DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9V[email protected]react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb" SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

Це не масштабується, і всі хочуть масштабувати. За словами кожного архітектора, з яким я коли-небудь сидів на зустрічі, “масштабування” є важливішим, ніж навіть робота програми.

Тож давайте розглянемо інший спосіб: файли .env.

Використовуйте файл .env

Файли .env дозволяють розміщувати змінні середовища всередині файлу. Ви просто створюєте новий файл, що називається .envу вашому проекті, і ляпаєте там свої змінні різними рядками.

PORT=65534 DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9V[email protected]react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb" SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

Для зчитування цих значень існує кілька варіантів, але найпростіший - використовувати dotenvпакет з npm.

npm install dotenv --save

Тоді вам просто потрібен цей пакет у вашому проекті всюди, де вам потрібно використовувати змінні середовища. dotenvПакет буде забрати цей файл і завантажити ці параметри в вузол.

Use dotenv to read .env vars into Node require('dotenv').config(); var MongoClient = require('mongodb').MongoClient; // Reference .env vars off of the process.env object MongoClient.connect(process.env.DB_CONN, function(err, db) { if(!err) { console.log("We are connected"); } });

ЗАСТОСУВАННЯ: Не перевіряйте свій .envфайл у Github. У ньому є всі ваші секрети, і Github надішле вам електронного листа та скаже. Не будь схожий на мене.

Нормально Добре. Але це свого роду біль. Ви повинні помістити це у кожен окремий файл, де ви хочете використовувати змінні середовища, І ви повинні розгорнути dotenvвиробництво там, де вам насправді це не потрібно. Я не шанувальник розгортання безглуздого коду, але, мабуть, я просто описав всю свою кар'єру.

На щастя, ви використовуєте код VS (бо, звичайно, ви використовуєте ), тому у вас є деякі інші варіанти.

Робота з .env файлами у VS Code

По-перше, ви можете встановити розширення DotENV для коду, яке дасть вам гарне виділення синтаксису у ваших файлах .env.

DotENV - Ринок Visual Studio

Розширення для коду Visual Studio - Підтримка синтаксису файлу dotenv

marketplace.visualstudio.com

VS Code Debugger також пропонує кілька більш зручних варіантів завантаження значень із файлів .env, якщо ви використовуєте VS Code Debugger.

Конфігурації запуску коду VS

Налагоджувач Node для коду VS (вже є, не потрібно нічого встановлювати) підтримує завантаження у файли .env через конфігурації запуску. Детальніше про конфігурації запуску ви можете прочитати тут.

Коли ви створюєте базову конфігурацію запуску вузла (клацніть на шестерні та виберіть Вузол), ви можете зробити одну або обидві з двох речей.

Перший - ви можете просто передавати змінні в конфігурацію запуску.

This is nice, but the fact that every value has to be a string bothers me a bit. It’s a number, not a string. JavaScript only has, like, 3 types. Don’t take one of them away from me.

There is a simpler way here. We’ve already learned to love .env files, so instead of passing them, we can just give VS Code the name of the .env file.

And as long as we are starting our process from VS Code, environment variables files are loaded in. We don’t have to mutilate numbers into strings and we aren’t deploying worthless code into production. Well, at least you aren’t.

Starting with NPM instead of Node

You might have gotten this far and thought, “Burke, I never ever run node anything. It’s always an npm script like npm start”.

In this case you can still use VS Code Launch configs. Instead of using a standard Node Launch process, you add a config that is a “Launch Via NPM” task.

Now you can add back in your envFile line and tweak the runtimeArgs so that they launch the correct script. This is usually something like “start” or “debug”.

Note that you have to add the --inspect flag to your npm script so that VS Code can attach the debugger. Otherwise the task will launch, but the VS Code debugger will time out like me trying to get a date in high school.

Production environment variables

So far we’ve looked at how to define variables for development. You likely won’t use .env files in production, and VS Code Launch Configurations aren’t going to be super helpful on a server.

In production, variables will be defined however your platform of choice allows you to do so. In the case of Azure, there are 3 different ways to define and manage environment variables.

The first way is to use the Azure CLI.

az webapp config appsettings set -g MyResourceGroup -n MyApp --settings PORT=65534

Which works, but, ew.

Another way is via the Azure web portal. I don’t always use a web portal, but when I do, it’s to set environment variables.

In the case of Azure, these are called “Application Settings”.

And since you are using VS Code, you can install the App Service extension and manage all the App Settings right from the editor.

I love not having to leave VS Code to do anything. I would write emails in VS Code if I could.

WAIT A MINUTE!

markdown-mail - Visual Studio Marketplace

Extension for Visual Studio Code - Using markdown to write your email and send!

marketplace.visualstudio.com

Now you know

Тепер ви знаєте, що я знаю (чого не багато, дозвольте сказати вам), і я відчуваю, ніби я досягнув своєї мети - смачної кількості жартів на Java. На той випадок, якщо цього не зробив, я залишу вас із цим.

Java - це дуже потужний інструмент для перетворення XML у сліди стеків

- Невідомо

Застереження щодо сатири: Більшість із них - погана спроба гумору, а частина - за рахунок Java; що не приємно, але дуже легко. Ці жарти не пишуть самі.