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

Приложения — это стандартный способ упаковать программное обеспечение в 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 предоставляет инструменты, такие как скрипты и архивы, которые являются различными механизмами для упаковки вашего приложения. Они обычно используются, когда инструменты должны быть общими между разработчиками, а не в качестве вариантов развертывания. См. mix help archive.build и mix help escript.build для получения более подробной информации.

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

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