Spec-Zone.ru › Elixir 1.15

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, может быть записано в текстовые файлы конфигурации, оно должно быть ограничено только простыми типами данных, такими как целые числа, строки, атомы, кортежи, карты и списки. Такие элементы, как идентификаторы процессов, ссылки и функции, сериализоваться не могут.

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.15.4/Config.Provider.html

Spec-Zone.ru

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