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

Приложения — это стандартный способ упаковки программного обеспечения в 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.

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

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

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 и к разделу Applications руководства по принципам проектирования OTP .