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

Приложения — это стандартный способ упаковать программное обеспечение в 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. Хотя чтение среды приложения во время выполнения является предпочтительным подходом, в некоторых редких случаях вы можете захотеть использовать среду приложения для конфигурирования компиляции определенного проекта. Это часто делается путем вызова get_env/3 вне функции:

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

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

Этот подход имеет одно существенное ограничение: если вы измените значение среды приложения после компиляции кода, значение, используемое во время выполнения, не изменится! Например, если ваш файл config/runtime.exs содержит:

config :my_app, :db_host, "db.production"

Это значение не повлияет, так как код был скомпилирован для подключения к «db.local», что, скорее всего, недоступно в производственной среде.

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

require Application
@db_host Application.compile_env(:my_app, :db_host, "db.local")

Используя 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.