Spec-Zone.ru › Elixir 1.13

Config.Provider поведение

Определяет API провайдера, загружающего конфигурацию во время запуска.

Провайдеры конфигурации обычно используются во время релизов для загрузки внешней конфигурации во время запуска системы. Это делается путем запуска виртуальной машины с минимальным количеством запущенных приложений, затем вызова всех провайдеров и перезапуска системы. Это требует изменяемого конфигурационного файла на диске, так как результаты провайдеров записываются в файловую систему. Для получения дополнительной информации о конфигурации во время выполнения см. mix release.

Множественные конфигурационные файлы

Одно из распространенных применений провайдеров конфигурации — указание нескольких конфигурационных файлов в релизе. Elixir поставляется с одним провайдером, называемым Config.Reader, который умеет обрабатывать встроенные конфигурационные файлы Elixir.

Например, представьте, что вы хотите перечислить некоторую основную конфигурацию в встроенном файле config/runtime.exs Mix, но также хотите поддерживать дополнительные конфигурационные файлы. Для этого вы можете добавить это в часть def project вашего mix.exs.

releases: [
  demo: [
    config_providers: [
      {Config.Reader, {:system, "RELEASE_ROOT", "/extra_config.exs"}}
    ]
  ]
]

Вы можете разместить этот extra_config.exs файл в вашем релизе несколькими способами:

  1. Если он доступен на хосте при сборке релиза, вы можете поместить его в "rel/overlays/extra_config.exs", и он будет автоматически скопирован в корень релиза

  2. Если он доступен на целевой машине во время развертывания, вы можете просто скопировать его в корень релиза как шаг в вашем развертывании

Теперь, после запуска системы, она загрузит как config/runtime.exs, так и extra_config.exs на раннем этапе процесса загрузки. Вы можете узнать больше о других опциях на Config.Reader.

Пользовательский провайдер конфигурации

Вы также можете реализовать пользовательские провайдеры конфигурации, аналогично тому, как работает Config.Reader. Например, представьте, что вам нужно загрузить некоторые параметры конфигурации из JSON-файла и загрузить их в систему. Данный провайдер конфигурации будет выглядеть следующим образом:

defmodule JSONConfigProvider do
  @behaviour Config.Provider

  # Let's pass the path to the JSON file as config
  @impl true
  def init(path) when is_binary(path), do: path

  @impl true
  def load(config, path) do
    # We need to start any app we may depend on.
    {:ok, _} = Application.ensure_all_started(:jason)

    json = path |> File.read!() |> Jason.decode!()

    Config.Reader.merge(
      config,
      my_app: [
        some_value: json["my_app_some_value"],
        another_value: json["my_app_another_value"],
      ]
    )
  end
end

Затем, при указании вашего релиза, вы можете указать провайдер в конфигурации релиза:

releases: [
  demo: [
    config_providers: [
      {JSONConfigProvider, "/etc/config.json"}
    ]
  ]
]

Краткое описание

Типы

config()
config_path()

Путь к конфигурационному файлу.

state()

Обработчики событий

init(term)

Вызывается при инициализации провайдера конфигурации.

load(config, state)

Загружает конфигурацию (обычно при запуске системы).

Функции

resolve_config_path!(path)

Разрешает config_path/0 до фактического пути.

validate_config_path!(path)

Проверяет config_path/0.

Типы

config()Исходный код

@type config() :: keyword()

config_path()Исходный код

@type config_path() :: {:system, binary(), binary()} | binary()

Путь к конфигурационному файлу.

Поскольку к конфигурационным файлам часто обращаются на целевых машинах, их можно выразить как:

  • бинарное значение, представляющее абсолютный путь

  • кортеж {:system, system_var, path}, где конфигурация — это конкатенация переменной окружения system_var и заданного path

state()Исходный код

@type state() :: term()

Обработчики событий

init(term)Исходный код

@callback init(term()) :: state()

Вызывается при инициализации провайдера конфигурации.

Провайдер конфигурации обычно инициализируется на машине, где система собирается, а не на целевой машине. Обработчик событий init/1 полезен для проверки аргументов, переданных провайдеру, и подготовки состояния, которое будет передано в load/2.

Кроме того, поскольку состояние, возвращаемое обработчиком событий init/1, может быть записано в текстовые конфигурационные файлы, оно должно быть ограничено только простыми типами данных, такими как целые числа, строки, атомы, кортежи, карты и списки. Элементы, такие как PID, ссылки и функции, сериализовать нельзя.

load(config, state)Исходный код

@callback load(config(), state()) :: config()

Загружает конфигурацию (обычно при запуске системы).

Он получает текущую config и state, возвращенные обработчиком событий init/1. Затем вы обычно читаете дополнительную конфигурацию из внешнего источника и объединяете ее в полученную config. Объединение должно выполняться с помощью Config.Reader.merge/2, так как он выполняет глубокое объединение. Он должен вернуть обновленную конфигурацию.

Обратите внимание, что load/2 обычно вызывается очень рано в процессе загрузки, поэтому если вам нужно использовать приложение в провайдере, вы несете ответственность за его запуск.

Функции

resolve_config_path!(path)Исходный код

@spec resolve_config_path!(config_path()) :: binary()

Разрешает config_path/0 до фактического пути.

validate_config_path!(path)Исходный код

@spec validate_config_path!(config_path()) :: :ok

Проверяет config_path/0.

© 2012 Plataformatec
Licensed under the Apache License, Version 2.0.
https://hexdocs.pm/elixir/1.13.4/Config.Provider.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API