Модуль для работы с приложениями и определения обратных вызовов приложений.

Приложения — это стандартный способ упаковки программного обеспечения в Erlang/OTP. По сути, они похожи на концепцию «библиотеки», распространённую в других языках программирования, но с некоторыми дополнительными характеристиками.

Приложение — это компонент, реализующий определённую функциональность со стандартной структурой каталогов, конфигурацией и жизненным циклом. Приложения загружаются, запускаются и останавливаются. Каждое приложение также имеет собственную среду, которая предоставляет унифицированный API для конфигурации каждого приложения.

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

Среда приложения

Каждое приложение имеет свою собственную среду. Среда — это список ключевых слов, сопоставляющих атомы с терминами. Обратите внимание, что эта среда не связана со средой операционной системы.

По умолчанию среда приложения — это пустой список. В файле mix.exs проекта Mix вы можете установить ключ :env в application/0.

def application do
  [env: [db_host: "localhost"]]
end

Теперь в вашем приложении вы можете прочитать эту среду, используя функции, такие как fetch_env!/2 и аналогичные:

defmodule MyApp.DBClient do
  def start_link() do
    SomeLib.DBClient.start_link(host: db_host())
  end

  defp db_host do
    Application.fetch_env!(:my_app, :db_host)
  end
end

В проектах Mix среда приложения и его зависимостей может быть переопределена через файлы config/config.exs и config/runtime.exs. Первый загружается на этапе компиляции, до компиляции вашего кода, а второй — во время выполнения, непосредственно перед запуском вашего приложения. Например, кто-то, использующий ваше приложение, может переопределить переменную среды :db_host следующим образом:

import Config
config :my_app, :db_host, "db.local"

Дополнительную информацию см. в разделе «Конфигурация» в модуле Mix. Вы также можете динамически изменять среду приложения, используя функции, такие как put_env/3 и delete_env/2.

Примечание: файлы конфигурации config/config.exs и config/runtime.exs редко используются библиотеками. Библиотеки обычно определяют свою среду в функции def application своего модуля mix.exs. Файлы конфигурации чаще используются приложениями для конфигурации своих библиотек.

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

Среда времени компиляции

В предыдущем примере мы читали среду приложения во время выполнения:

defmodule MyApp.DBClient do
  def start_link() do
    SomeLib.DBClient.start_link(host: db_host())
  end

  defp db_host do
    Application.fetch_env!(:my_app, :db_host)
  end
end

Другими словами, ключ среды :db_host для приложения :my_app будет прочитан только тогда, когда приложение MyApp.DBClient фактически запустится. Хотя чтение среды приложения во время выполнения предпочтительнее, в некоторых редких случаях вы можете захотеть использовать среду приложения для конфигурации компиляции определённого проекта. Однако если вы попытаетесь получить доступ к Application.fetch_env!/2 вне функции:

defmodule MyApp.DBClient do
  @db_host Application.fetch_env!(:my_app, :db_host)

  def start_link() do
    SomeLib.DBClient.start_link(host: @db_host)
  end
end

Вы можете увидеть предупреждения и ошибки:

warning: Application.fetch_env!/2 is discouraged in the module body,
use Application.compile_env/3 instead
  iex:3: MyApp.DBClient

** (ArgumentError) could not fetch application environment :db_host
for application :my_app because the application was not loaded nor
configured

Это происходит потому, что при определении модулей среда приложения ещё недоступна. К счастью, предупреждение показывает, как решить эту проблему, используя Application.compile_env/3 вместо этого:

defmodule MyApp.DBClient do
  @db_host Application.compile_env(:my_app, :db_host, "db.local")

  def start_link() do
    SomeLib.DBClient.start_link(host: @db_host)
  end
end

Разница в том, что compile_env ожидает, что значение по умолчанию будет передано в качестве аргумента, а не используя функцию def application вашего модуля mix.exs. Кроме того, используя compile_env/3, инструменты, такие как Mix, будут сохранять значения, используемые во время компиляции, и сравнивать значения компиляции со значениями во время выполнения при запуске вашей системы, вызывая ошибку в случае их различия.

В любом случае, следует избегать сред времени компиляции. В случае возможности чтение среды приложения во время выполнения должно быть первоочередным.

Модуль обратных вызовов приложения

Приложения могут загружаться, запускаться и останавливаться. Обычно инструменты сборки, такие как Mix, позаботятся о запуске приложения и всех его зависимостей, но вы также можете сделать это вручную, вызвав:

{:ok, _} = Application.ensure_all_started(:some_app)

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

Первый шаг — добавить ключ :mod к определению application/0 в вашем файле mix.exs. Он ожидает кортеж, содержащий модуль обратного вызова приложения и аргумент запуска (обычно пустой список):

def application do
  [mod: {MyApp, []}]
end

Модуль MyApp , переданный в :mod , должен реализовывать поведение Application. Это можно сделать, поместив use Application в этот модуль и реализовав обратный вызов start/2, например:

defmodule MyApp do
  use Application

  def start(_type, _args) do
    children = []
    Supervisor.start_link(children, strategy: :one_for_one)
  end
end

Обратный вызов start/2 должен создать и связать диспетчер и вернуть {:ok, pid} или {:ok, pid, state}, где pid — PID диспетчера, а state — необязательное состояние приложения. args — второй элемент кортежа, переданного в опцию :mod.

Аргумент type , переданный в start/2 , обычно является :normal, за исключением распределённых установок, где настроены передача и восстановление приложений. Распределённые приложения выходят за рамки этой документации.

При завершении приложения вызывается обратный вызов stop/1 после остановки дерева надзора системой выполнения. Этот обратный вызов позволяет приложению выполнить окончательную очистку. Аргумент — состояние, возвращённое start/2, если оно было, или [] в противном случае. Возвращаемое значение stop/1 игнорируется.

Используя Application, модули получают реализацию по умолчанию для stop/1, которая игнорирует свой аргумент и возвращает :ok, но её можно переопределить.

Модули обратных вызовов приложений также могут реализовать необязательный обратный вызов prep_stop/1. Если он присутствует, prep_stop/1 вызывается перед завершением дерева надзора. Его аргументом является состояние, возвращённое start/2, если оно было, или [] в противном случае, а его возвращаемое значение передаётся в stop/1.

Файл ресурсов приложения

В предыдущих разделах мы настроили приложение в разделе application/0 файла mix.exs. В конечном итоге Mix использует эту конфигурацию для создания файла файла ресурсов приложения, который называется APP_NAME.app. Например, файл ресурсов приложения приложения OTP ex_unit называется ex_unit.app.

Дополнительную информацию о генерации файлов ресурсов приложений вы можете найти в документации Mix.Tasks.Compile.App, доступной также посредством выполнения mix help compile.app.

Жизненный цикл приложения

Загрузка приложений

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

Application.load(:ex_unit)
#=> :ok

При загрузке приложения среда, указанная в его файле ресурсов, объединяется с любыми переопределениями из файлов конфигурации.

Загрузка приложения не загружает его модули.

На практике вы редко загружаете приложения вручную, так как это часть процесса запуска, описанного ниже.

Запуск приложений

Приложения также запускаются:

Application.start(:ex_unit)
#=> :ok

После компиляции вашего приложения запуск вашей системы сводится к запуску текущего приложения и его зависимостей. В отличие от других языков, в Elixir нет процедуры main, которая отвечает за запуск вашей системы. Вместо этого вы запускаете одно или несколько приложений, каждое со своей логикой инициализации и завершения.

При запуске приложения функция Application.load/1 автоматически вызывается, если она ещё не была выполнена. Затем она проверяет, являются ли зависимости, перечисленные в ключе applications файла ресурсов, уже запущенными. Наличие хотя бы одной не запущенной зависимости — это условие ошибки. Функции, такие как ensure_all_started/1 , позаботятся о запуске приложения и всех его зависимостей.

Если для приложения не настроен модуль обратных вызовов, запуск выполняется на этом этапе. В противном случае вызывается обратный вызов start/2. PID верхнего уровня, возвращённый этой функцией, сохраняется системой выполнения для последующего использования, а возвращённое состояние приложения также сохраняется, если оно имеется.

Остановка приложений

Запущенные приложения, наконец, останавливаются:

Application.stop(:ex_unit)
#=> :ok

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

Остановка приложения с модулем обратного вызова имеет три шага:

1. Если присутствует, вызывается необязательный обратный вызов prep_stop/1.
2. Завершается верхний диспетчер.
3. Вызывается обязательный обратный вызов stop/1.

Передаваемые аргументы обратным вызовам связаны с состоянием, которое необязательно возвращается start/2, и подробно описаны в разделе о модуле обратных вызовов выше.

Важно отметить, что шаг 2 является блокирующим. Остановка надзирателя вызывает рекурсивную цепочку остановок дочерних элементов, поэтому происходит упорядоченная остановка всех дочерних процессов. Обратный вызов stop/1 вызывается только после завершения всей иерархии управления.

Чистую остановку действующей системы можно выполнить, вызвав System.stop/1. Она остановит каждое приложение в обратном порядке их запуска.

По умолчанию, SIGTERM из операционной системы автоматически переводится в System.stop/0. Вы также можете получить больший контроль над сигналами операционной системы с помощью функции :os.set_signal/2.

Инструменты

Инструмент сборки Mix автоматизирует большинство задач управления приложениями. Например, mix test автоматически запускает зависимости вашего приложения и само приложение перед выполнением тестов. mix run --no-halt запускает текущий проект и может использоваться для запуска долгоживущей системы. См. mix help run.

Разработчики также могут использовать mix release для создания релизов. Релизы способны упаковать весь исходный код, а также виртуальную машину Erlang в один каталог. Релизы также предоставляют явный контроль над тем, как и в каком порядке запускается каждое приложение. Они также обеспечивают более удобный механизм запуска и остановки систем, отладки, ведения журналов, а также мониторинга системы.

Наконец, Elixir предоставляет инструменты, такие как escripts и архивы, которые являются различными механизмами для упаковки приложения. Они обычно используются, когда инструменты должны быть общими для разработчиков, а не в качестве вариантов развертывания. См. mix help archive.build и mix help escript.build для получения более подробной информации.

Дополнительная информация

Для получения дополнительной информации об приложениях, пожалуйста, обратитесь к документации модуля :application Erlang и разделу Приложения в руководстве по принципам проектирования OTP .