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

Приложения — это стандартный способ упаковать программное обеспечение в 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. Например, пользователь вашего приложения может переопределить переменную среды :db_host следующим образом:

import Config
config :my_app, :db_host, "db.local"

Вы также можете динамически изменять среду приложения, используя функции, такие как 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

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

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

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

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

@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 будет использовать эту конфигурацию для создания файла ресурсов приложения application resource file, который называется 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 OTP Design Principles User's Guide.