Приложение поведение

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

Приложения — это стандартный способ упаковывать программное обеспечение в 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 редко используются библиотеками. Библиотеки обычно определяют свою среду в функции application/0 своего модуля 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

use Application

Когда вы use Application, модуль Application установит @behaviour Application и определит переопределяемое определение для функции stop/1, которая требуется Erlang/OTP.

Обратный вызов 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 .