Упаковка приложения
Чтобы упаковать приложение, используйте команду pack:
cartridge pack TYPE [PATH] [параметры]
Передаваемые аргументы:
TYPE(обязательно) — тип дистрибутива. Поддерживаемые типы:PATH(необязательно) — путь к директории приложения. Значение по умолчанию:.(текущая директория).
Перед упаковкой cartridge pack собирает приложение. Это процесс схож с тем, что происходит во время cartridge build. Итоговый артефакт сборки включает модули .rocks и исполняемые файлы, специфичные для системы, на которой вы собираете пакет приложения. Именно поэтому дистрибутив, собранный на одной ОС, невозможно использовать на другой: например, RPM-пакет, собранный на MacOS, не может быть установлен на машине с CentOS. Обойти это ограничение можно, выбрав сборку приложения внутри Docker-контейнера с помощью параметра --use-docker.
Примечание
Если вы используете версию Tarantool с открытым исходным кодом, tarantool будет среди зависимостей вашего артефакта. Версия Tarantool при этом будет совпадать с указанной в переменной PATH в вашей системе. Если же вы используете Tarantool Enterprise, ваш артефакт будет включать бинарные файлы tarantool и tarantoolctl из вашего SDK.
Следующие параметры управляют локальной упаковкой приложения в RPM- или DEB-дистрибутив, TGZ-архив или Docker-образ.
--name |
Имя приложения. Оно будет присвоено и пакету, и соответствующему сервису systemd. По умолчанию имя берется из поля package в файле .rockspec. |
--version |
Application package version.
By default, the version string is the output of git describe --tags --long,
normalized to major.minor.patch.count.
If the application is not a git repository,
you have to set the --version flag explicitly.
If you set --version flag, it will be used as provided. |
--suffix |
Суффикс итогового имени файла или образа. Например, дистрибутив tar.gz именуется по следующему шаблону: <имя>-<версия>[.<суффикс>].<архитектура>.tar.gz. |
--filename |
Явно задать полное имя пакета. Например, пакет, собранный с --filename bundle_name.tar.gz , имеет имя bundle_name.tar.gz. |
--use-docker |
Принудительная сборка приложения на Cartridge в Docker. Параметр обязателен, если вы собираете Docker-образ. |
--no-cache |
Отключение кэширования по путям. При использовании вместе с cartridge pack docker автоматически устанавливает параметр --no-cache для команды docker. |
Ознакомьтесь с документацией по упаковке приложений на Cartridge в RPM/DEB-дистрибутивы и Docker-образы, чтобы узнать больше о параметрах, специфичных для этих способов упаковки.
По умолчанию пакет собирается внутри временной директории в ~/.cartridge/tmp/. Таким образом, процесс упаковки не влияет на содержимое директории вашего приложения.
Копируя файлы приложения, Cartridge игнорирует директорию .rocks.
В итоговом пакете сохраняются все права доступа к файлам, а в качестве владельца файлов кода устанавливается root:root.
Убедитесь, что для всех файлов приложения установлены права доступа не ниже a+r (a+rx для директорий). В противном случае cartridge pack выдаст ошибку.
Указать пользовательскую директорию для сборки приложения можно с помощью переменной окружения CARTRIDGE_TEMPDIR. Если такой директории не существует, она будет создана, использована для упаковки приложения, а затем удалена.
Если в переменной окружения CARTRIDGE_TEMPDIR указать существующую директорию, то приложение будет упаковано в директории CARTRIDGE_TEMPDIR/cartridge.tmp, которая затем будет удалена. Перед началом сборки пакета эта вложенная директория будет очищена.
Примечание
Это может быть актуально при сборке Docker-образов с помощью GitLab CI, так как в этом случае Docker-тома (Docker volumes) не работают должным образом с директорией tmp по умолчанию. Используйте для таких случаев CARTRIDGE_TEMPDIR=. cartridge pack ....
Этот раздел посвящен локальной сборке приложений на Cartridge. Чтобы узнать о сборке в Docker, ознакомьтесь с соответствующим разделом документации.
Независимо от того, собираете ли вы TGZ-архив, дистрибутив RPM/DEB или Docker-образ, сборка включает три этапа.
На этом этапе из директории приложения удаляется часть файлов.
- В первую очередь с помощью
git clean -X -d -fудаляются все неотслеживаемые и игнорируемые файлы, в том числе относящиеся к вложенным модулям. - После этого удаляется директория
.git.
На этом этапе cartridge выполняет следующее:
- Скрипт
./cartridge.pre-build, если он есть в корневой директории приложения. Узнайте больше о скриптах pre-build и post-build. Вместо того, чтобы использовать этот скрипт, вы можете определить правила сборки, включив в файл.rockspecкомандыcmake, как это сделано в Cartridge. tarantoolctl rocks make. Чтобы выполнить эту команду, потребуется файл.rockspecв корневой директории приложения. Если вы создали приложение по шаблону, этот файл уже находится там.cartridgeустановит все зависимости, указанные в этом файле.
По завершении сборки приложение появится в директории .rocks. Его можно запустить локально из его корневой директории.
На этом этапе cartridge запускает cartridge.post-build, если такой скрипт существует. Скрипт post-build удаляет ненужные файлы, созданные во время сборки приложения — например, node_modules.
Подробную информацию вы найдете в описании скриптов pre-build и post-build.
При сборке будет автоматически создан файл VERSION.lua, в котором хранится текущая версия приложения. При подключении к экземпляру с помощью cartridge connect вы сможете проверить версию проекта, получив информацию из этого файла следующим образом:
require('VERSION')
VERSION.lua также используется при вызове cartridge.reload_roles():
-- Получение версии проекта
require('VERSION')
-- Перезапуск экземпляров после изменения файла VERSION.lua
require('cartridge').reload_roles()
-- Получение обновленной версии проекта
require('VERSION')
Примечание
Если в директории приложения уже есть файл VERSION.lua, при сборке пакета он будет перезаписан.
Вы можете кэшировать директории для упаковки приложений на Cartridge. Если вы собираете пакет для приложения несколько раз, одни и те же модули .rocks устанавливаются каждый раз заново. Чтобы ускорить процесс переупаковки, укажите пути для кэширования в файле pack-cache-config.yml, расположенном в корневой директории приложения.
Директория .rocks кэшируется по умолчанию. Путь к ней указан в стандартной конфигурации pack-cache-config.yml:
- path: '.rocks':
key-path: 'myapp-scm-1.rockspec'
- path: 'node_modules':
always-cache: true
- path: 'third_party/custom_module':
key: 'simple-hash-key'
Убедитесь, что вы указали путь к директории .rocks из корневой директории приложения и предоставили ключ для кэширования. В примере выше:
- директория
<путь_к_myapp>/.rocksбудет кэширована в зависимости от содержанияmyapp-scm-1.rockspec; - директория
<path-to-myapp>/node_modulesвсегда будет добавляться в кэш. - директория
<путь_к_myapp>/third_party/custom_moduleбудет кэширована в зависимости от значенияsimple-hash-key;
Эти параметры нельзя комбинировать: вы не можете одновременно указать и always-cache, и key-path.
У каждого пути в проекте может быть только один ключ кэширования. Предположим, вы кэшировали .rocks, указав файл .rockspec в качестве key-path. Затем вы изменили содержимое файла .rockspec и запустили cartridge pack. В этом случае старый кэш директории .rocks, связанный со старым ключом, будет удален. Новый кэш для .rocks будет сохранен с новым ключом после упаковки.
В кэше можно хранить не более 5 проектов с путями для кэширования. При добавлении шестого самый старый проект будет удален из директории кэша. Для каждого проекта при этом можно добавлять сколько угодно путей для кэширования.
Чтобы отключить кэширование, используйте параметр --no-cache или удалите пути из pack-cache-config.yml. Полностью сбросить кэш можно, удалив директорию ~/.cartridge/tmp/cache.