Оригинал этой статьи находится по адресу Releases

Эту главу следует читать вместе с документацией по rel(4), systools(3) и script(4).

Концепция релизов

Когда мы написали одно или несколько приложений, у нас может возникнуть желание создать систему, состоящую из этих приложений и некоторого подмножества приложений Erlang/OTP. Это называется релизом.

Для того чтобы сделать это, мы создаем файл ресурсов релиза, который определяет, какие приложения будут включены в релиз.

Файл ресурсов релиза необходим для генерации загрузочных скрипов и пакетов релиза. Система, которая передается и устанавливается в другом месте, называется целевой системой (target system). Как использовать пакеты для создания целевой системы, описано в разделе документации «Системные принципы».

Файл ресурсов релиза

Для описания релиза мы создаем файл ресурсов релиза (release resource file), или, более коротко, .rel файл, в котором мы задаем имя и версию релиза, на какой версии ERTS он создан и из каких приложений состоит:

{release, {Name,Vsn}, {erts, EVsn},
 [{Application1, AppVsn1},
   ...
  {ApplicationN, AppVsnN}]}.

Файл должен называться Rel.rel, где Rel – уникальное имя.

Name, Vsn и Evsn – строки.

Каждое приложение Application (атом) и AppVsn (строка) – это имя и версия приложения, включенного в релиз. Необходимо заметить, что минимальный релиз, созданный на основе Erlang/OTP, состоит из приложений kernel и stdlib, так что эти приложения обязательно должны быть включены в список.

Пример: Мы хотим создать релиз приложения ch_app из главы Приложения. Это приложение имеет следующий .app файл:

{application, ch_app,
 [{description, "Channel allocator"},
  {vsn, "1"},
  {modules, [ch_app, ch_sup, ch3]},
  {registered, [ch3]},
  {applications, [kernel, stdlib, sasl]},
  {mod, {ch_app,[]}}
 ]}.

Файл .rel также должен содержать kernel, stdlib и sasl, поскольку эти приложения используются ch_app. Назовем файл ch_rel-1.rel:

{release,
 {"ch_rel", "A"},
 {erts, "5.3"},
 [{kernel, "2.9"},
  {stdlib, "1.12"},
  {sasl, "1.10"},
  {ch_app, "1"}]
}.

Генерация загрузочных скриптов

В SASL модуле systools есть утилиты, позволяющие создавать и проверять релизы. Функции читают файлы .rel и .app и производят проверку синтаксиса и зависимостей. Функция systools:make_script/1,2 используется для генерации загрузочного скрипта (см. Системные принципы).

1> systools:make_script("ch_rel-1", [local]).
ok

Эта функция создаст загрузочный скрипт в пригодном для чтения виде (в файле ch_rel-1.script) и в бинарном виде, используемом системой выполнения (в файле ch_rel-1.boot). "ch_rel-1" – это имя .rel файла, за исключением расширения. local – это опция, обозначающая, что директории, в которых находятся приложения, будут использованы в загрузочном скрипте вместо $ROOT/lib. ($ROOT – это корневая директория установленного релиза.) Это полезный способ проверить сгенерированный загрузочный скрипт локально.

При запуске Erlang/OTP с использованием загрузочного скрипта все приложения из .rel файла будут автоматически загружены и запущены:

% erl -boot ch_rel-1
Erlang (BEAM) emulator version 5.3

Eshell V5.3  (abort with ^G)
1> 
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
         supervisor: {local,sasl_safe_sup}
            started: [{pid,<0.33.0>},
                      {name,alarm_handler},
                      {mfa,{alarm_handler,start_link,[]}},
                      {restart_type,permanent},
                      {shutdown,2000},
                      {child_type,worker}]

...

=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
        application: sasl
         started_at: nonode@nohost

...
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
        application: ch_app
         started_at: nonode@nohost

Создание пакета релиза

Существует функция systools:make_tar/1,2, которая принимает .rel файл в качестве параметра и создает сжатый zip-ом tar-файл с кодом для указанных приложений – пакет релиза(release package).

1> systools:make_script("ch_rel-1").
ok
2> systools:make_tar("ch_rel-1").
ok

Пакет релиза по умолчанию состоит из .app файлов и объектного кода для всех приложений, находящихся в местах, определенных структурой директорий приложения, загрузочного скрипта в бинарном виде, переименованном в start.boot, и .rel файла.

% tar tf ch_rel-1.tar
lib/kernel-2.9/ebin/kernel.app
lib/kernel-2.9/ebin/application.beam
...
lib/stdlib-1.12/ebin/stdlib.app
lib/stdlib-1.12/ebin/beam_lib.beam
...
lib/sasl-1.10/ebin/sasl.app
lib/sasl-1.10/ebin/sasl.beam
...
lib/ch_app-1/ebin/ch_app.app
lib/ch_app-1/ebin/ch_app.beam
lib/ch_app-1/ebin/ch_sup.beam
lib/ch_app-1/ebin/ch3.beam
releases/A/start.boot
releases/ch_rel-1.rel

Необходимо заметить, что новый загрузочный скрипт был сгенерирован без опции local, перед созданием пакета релиза. В пакете релиза все директории приложения расположены в директории lib. Мы также не знаем, где будет установлен пакет релиза, поэтому мы не должны жестко задавать абсолютные пути в загрузочном скрипте.

Если файл relup и/или системный конфигурационный файл sys.config найдены, эти файлы также включаются в пакет релиза. Смотрите раздел Управление релизами.

Также можно установить опции для включения в пакет релиза исходных кодов и бинарников ERTS.

Для установки новой системы, используя пакет релиза, обратитесь к разделу Системные Принципы(System Principles), а для получения информации об установке нового пакета релиза на существующую систему – к разделу Управление релизами.

Структура директорий

Структура директорий для кода, установленного менеджером релизов из пакета релиза:

$ROOT/lib/App1-AVsn1/ebin
                    /priv
         /App2-AVsn2/ebin
                    /priv
         ...
         /AppN-AVsnN/ebin
                    /priv
     /erts-EVsn/bin
     /releases/Vsn
     /bin

• lib – директории приложений.
• erts-EVsn/bin – исполняемые файлы системы Erlang.
• releases/Vsn – .rel файл и загрузочный скрипт start.boot, при наличии в пакете релиза relup и/или sys.config.
• bin – Высокоуровневые исполняемые файлы системы Erlang.

Приложения не обязательно должны находиться в директории $ROOT/lib. Соответственно, может существовать несколько установочных директорий, каждая из которых может содержать различные части системы. Например, предыдущий пример может быть расширен следующим образом:

$SECOND_ROOT/.../SApp1-SAVsn1/ebin
                             /priv
                /SApp2-SAVsn2/ebin
                             /priv
                ...
                /SAppN-SAVsnN/ebin
                             /priv

$THIRD_ROOT/TApp1-TAVsn1/ebin
                        /priv
           /TApp2-TAVsn2/ebin
                        /priv
           ...
           /TAppN-TAVsnN/ebin
                        /priv

$SECOND_ROOT и $THIRD_ROOT представлены как variables при вызове функции systools:make_script/2.

Бездисковые клиенты или клиенты в режиме «только чтение»

Если вся система состоит из нескольких бездисковых клиентов или клиентов в режиме «только чтение», директория clients должна быть добавлена в директорию $ROOT. Под узлом в режиме «только чтение» мы подразумеваем узел с файловой системой, доступной только для чтения.

Директория clients должна содержать по одной поддиректории на каждый поддерживаемый клиентский узел. Имя каждой клиентской директории должно совпадать с именем соответствующего клиентского узла. Как минимум, каждая клиентская директория должна содержать поддиректории bin и releases. Эти директории используются для сохранения информации об установленных релизах и для указания текущего релиза клиенту. Соответственно, директория $ROOT содержит следующие директории:

$ROOT/...
    /clients/ClientName1/bin
                        /releases/Vsn
            /ClientName2/bin
                        /releases/Vsn
            ...
            /ClientNameN/bin
                        /releases/Vsn

Эта структура должна использоваться, если все клиенты запускаются на Erlang-машине одного и того же типа. Если есть клиенты, работающие на других типах Erlang-машин или на других операционных системах, директория clients должна быть разделена на несколько поддиректорий, по одной на каждый тип Erlang-машины. Также можно установить отдельную директорию $ROOT для каждого типа машины. Для каждого типа должны быть включены некоторые из директорий из $ROOT:

$ROOT/...
    /clients/Type1/lib
                  /erts-EVsn
                  /bin
                  /ClientName1/bin
                              /releases/Vsn
                  /ClientName2/bin
                              /releases/Vsn
                  ...
                  /ClientNameN/bin
                              /releases/Vsn
            ...
            /TypeN/lib
                  /erts-EVsn
                  /bin
                  ...

В этой структуре корневая директория для клиентов типа Type1 будет $ROOT/clients/Type1.