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

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

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

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

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