Войти

Перевод 7

Перевод 7

перейти

  1. Configuration
    Конфигурация
  2. Applications often run in different environments. Depending on the environment, different configuration settings should be used. For example, usually the local environment relies on specific database credentials, valid only for the local DB instance. The production environment would use a separate set of DB credentials. Since configuration variables change, best practice is to store configuration variables in the environment.

    Приложения часто работают в разных средах. В зависимости от среды следует использовать разные параметры конфигурации. Например, обычно локальная среда зависит от определенных учетных данных базы данных, действительных только для локального экземпляра БД. В производственной среде будет использоваться отдельный набор учетных данных БД. Поскольку переменные конфигурации изменяются, рекомендуется хранить переменные конфигурации в среде.

  3. Externally defined environment variables are visible inside Node.js through the process.env global. We could try to solve the problem of multiple environments by setting the environment variables separately in each environment. This can quickly get unwieldy, especially in the development and testing environments where these values need to be easily mocked and/or changed.

    Внешне определенные переменные среды видны внутри Node.js через глобальный файл process.env. Мы могли бы попытаться решить проблему нескольких сред, установив переменные среды отдельно в каждой среде. Это может быстро стать громоздким, особенно в средах разработки и тестирования, где эти значения необходимо легко имитировать и/или изменять.

  4. In Node.js applications, it's common to use .env files, holding key-value pairs where each key represents a particular value, to represent each environment. Running an app in different environments is then just a matter of swapping in the correct .env file.

    В приложениях Node.js обычно используются файлы .env, содержащие пары ключ-значение, где каждый ключ представляет определенное значение, для представления каждой среды. Запуск приложения в разных средах — это просто замена правильного файла .env.

  5. A good approach for using this technique in Nest is to create a ConfigModule that exposes a ConfigService which loads the appropriate .env file. While you may choose to write such a module yourself, for convenience Nest provides the @nestjs/config package out-of-the box. We'll cover this package in the current chapter.

    Хорошим подходом к использованию этого метода в Nest является создание ConfigModule, предоставляющего ConfigService, который загружает соответствующий файл .env. Хотя вы можете написать такой модуль самостоятельно, для удобства Nest предоставляет готовый пакет @nestjs/config. Мы рассмотрим этот пакет в текущей главе.

  6. Installation

    Установка
  7. To begin using it, we first install the required dependency.

    yarn add @nestjs/config

    Чтобы начать использовать его, мы сначала устанавливаем необходимую зависимость.

    yarn add @nestjs/config

  8. Getting started

    Начало работы

  9. Once the installation process is complete, we can import the ConfigModule. Typically, we'll import it into the root AppModule and control its behavior using the .forRoot() static method. During this step, environment variable key/value pairs are parsed and resolved. Later, we'll see several options for accessing the ConfigService class of the ConfigModule in our other feature modules.

    После завершения процесса установки мы можем импортировать ConfigModule. Как правило, мы импортируем его в корневой AppModule и управляем его поведением с помощью статического метода .forRoot(). На этом этапе пары ключ/значение переменных среды анализируются и разрешаются. Позже мы увидим несколько вариантов доступа к классу ConfigService модуля ConfigModule в других наших функциональных модулях.

    @@filename(app.module)
    import { Module } from '@nestjs/common';
    import { ConfigModule } from '@nestjs/config';
    
    @Module({
      imports: [ConfigModule.forRoot()],
    })
    export class AppModule {}
  10. The above code will load and parse a .env file from the default location (the project root directory), merge key/value pairs from the .env file with environment variables assigned to process.env, and store the result in a private structure that you can access through the ConfigService. The forRoot() method registers the ConfigService provider, which provides a get() method for reading these parsed/merged configuration variables. Since @nestjs/config relies on dotenv, it uses that package's rules for resolving conflicts in environment variable names. When a key exists both in the runtime environment as an environment variable (e.g., via OS shell exports like export DATABASE_USER=test) and in a .env file, the runtime environment variable takes precedence.

    Приведенный выше код загрузит и проанализирует файл .env из расположения по умолчанию (корневой каталог проекта), объединит пары ключ/значение из файла .env с переменными среды, назначенными для process.env, и сохранит результат в частной структуре, которая вы можете получить доступ через ConfigService. Метод forRoot() регистрирует поставщика ConfigService, который предоставляет метод get() для чтения этих проанализированных/объединенных переменных конфигурации. Поскольку @nestjs/config зависит от dotenv, он использует правила этого пакета для разрешения конфликтов в именах переменных среды. Когда ключ существует как в среде выполнения как переменная среды (например, через экспорт оболочки ОС, такой как export DATABASE_USER=test), так и в файле .env, переменная среды выполнения имеет приоритет.

    Теги:
    php