Signing and Pushing TorizonCore Packages to Torizon Platform Services
The Torizon Platform Services allows customers to push their own customized versions of TorizonCore (OS updates) and Docker Compose (application updates) to our hosted service. It means that, after customizing an image or creating your application, you must sign and push it to Torizon Platform Services.
In this article, you will learn how to use the TorizonCore Builder Tool for signing and pushing packages to the Torizon Platform Services.
| This is a feature available on prime-tiers of the Torizon Platform Services. If you want to learn more about the Torizon Platform Services pricing and plans, please contact us.|
Request access to evaluate the Torizon Platform Services premium features
This article complies to the Typographic Conventions for Torizon Documentation.
The prerequisites to complete these instructions are:
- A host machine with TorizonCore Builder installed.
.tarfile containing the TorizonCore Image with no-container pre-provisioned for offline installation.
credentials.zipfile downloaded from your account on the Torizon Platform Services dashboard.
- A docker-compose file of your appplication container if you want to update your application.
Make sure your working directory has the following structure, including
docker-compose.yml, and the TorizonCore installation image
Also make sure you can run TorizonCore Builder:
$ torizoncore-builder --help
Generating a TorizonCore image
Our TorizonCore Builder tool is the recommended way to customize a TorizonCore OS image to suit your product requirements. This tool allows easy customization of nearly all aspects of the OS, and for a more detailed evaluation at its features please take a look at TorizonCore Builder Tool - Customizing TorizonCore Images.
With TorizonCore Builder, you will always generate OS images that are suitable to be pushed to our Torizon Platform Services for updates.
The output of this process is either an OSTree reference or a Toradex Easy Installer compatible image - ready to be installed with Toradex Easy Installer (TEZI), usually during production programming.
- Using standalone commands:
deploy commandgenerates a TEZI format image, while the
union commandgenerates an OStree branch.
- Using the
build command, you can set the
output sectionof the configuration file for either options.
If you want to deploy simultaneously the OS and application with Torizon Platform Services, you should use the synchronous update feature of our Torizon Platform, instead of customizing your image to bundle containers to a TorizonCore image, since its bundled containers are not capable of being deployed without Toradex Easy Installer.
Signing and pushing the image to Torizon Platform Services
The TorizonCore Builder tool will also be used to push your OS image and your application to the server.
platform push from TorizonCore Builder can be used to push a new TorizonCore image to Torizon Platform Services.
torizoncore-builder platform push --credentials <credentials file> <ostree reference>
The command requires the
credentials.zip file from Torizon Platform Services and a reference to the OSTree repository that should be pushed to the Platform Services server.
If you are pushing Toradex Easy Installer compatible images, first you should run the
images unpack command
to generate a base OStree reference.
$ torizoncore-builder images unpack <base Toradex Easy Installer image of Torizon>
After running the
images unpack command, you should use
base as the
ostree reference. If your customization process output was an OStree branch, you can use its name or hash as the
As an example, using the OSTree reference is called
my-custom-image, the command below will push the customized image to Torizon Platform Services:
torizoncore-builder platform push --credentials credentials.zip my-custom-image
Now, if you log in to Torizon Platform Services and initiate an update, you should see the customized image, ready to be used to update a device:
And, if everything went fine with the update, you shall see your board rebooting when the process is completed, and the splash screen shown in the device initialization will be the one defined in the new image.
There are also some additional arguments that can be passed to further customize this image update package.
torizoncore-builder platform push --credentials <credentials file> --package-name <name for this image update> --package-version <version for this image update> <ostree reference> --hardwareid <supported hardware for this image update>
--package-name argument will apply whatever is passed as the name for this image update package. Simply put, this is the name that your update will appear under in our Torizon Platform Services web UI. However, this argument is optional and, if not used, will default to the
--package-version argument is the version that this image update package will show up as in the web UI. This doesn't have to be a numerical version and can be any legitimate string. This argument is optional, and if not used, the version will default to the
--hardwareid argument defines which hardware IDs the image to be uploaded will be compatible with. This argument can be repeated multiple times, adding extra supported hardware IDs to the image. It's important to notice this argument will override the default image's hardware ID. Under the
Supported Hardware tab at the Torizon Platform Services web UI, you can confirm the changes. This argument is optional, and if not used, the supported hardware ID will default to the original image's hardware ID.
Signing and pushing the docker-compose file to Torizon Platform Services
platform push can also be used to push docker-compose files to Torizon Platform Services.
credentials.zip is also required along with the path to the docker-compose file. Your compose file can have any name, as long as it ends in
.yaml. If it does not have either of these file endings then the command will assume you passed an OSTree reference instead.
torizoncore-builder platform push --credentials <credentials file> <path to docker-compose file>
There are also some additional arguments that can be passed to further customize this update package
torizoncore-builder platform push --credentials <credentials file> --package-name <name for this update> --package-version <version for this update> --canonicalize <path to docker-compose file>
--package-name argument will apply whatever is passed as the name for this updated package. Simply put, this is the name that your update will appear under in our Torizon Platform Services web UI. However, this argument is optional and, if not used, will default to the pushed file's name.
--package-version argument is the version that this package will show up as in the web UI. This doesn't have to be a numerical version and can be any legitimate string. This argument is also optional and, if not used, will default to the date of upload at UTC time in the format of
--canonicalize argument generates a canonicalized version of the docker-compose file, changing its extension to '.lock.yml' or '.lock.yaml' before pushing it to Torizon Platform Services. If no other package name is provided, using the
--package-name argument, the default package name will be the generated file's name when using the canonicalize argument.
For a docker-compose file to be suitable for use with offline-updates it must be in canonical form.
For example running the following command:
torizoncore-builder platform push --credentials credentials.zip --package-name tcb-test --package-version 1.1 docker-compose.yml
Will result in the following appearing in your account's web UI:
Lockfiles and Canonical Docker Compose Files
When pushing a docker-compose file to Torizon Platform Services, TorizonCore Builder will:
- Canonicalize the docker-compose file
- Save a copy of the canonicalized docker-compose file with
.lock.yamlextension (depending on how you named your docker-compose file)
- If the
--canonicalizeoption was provided, send the canonicalized docker-compose file to Torizon Platform Services.
Canonicalizing a docker-compose file basically means putting it into a specific YAML format, removing comments (lines starting with a
# or any word included after a
# character), and associating HASH values to Docker images.
This way, it would be easier to track changes to this docker-compose file and also make your deployment more secure since we are pulling down images based on HASHES instead of tags.