Micro-updates
Micro-updates are application updates. You can update your application's code, install new packages and run bash commands before/after the update is deployed. Usually you would use a Micro-update to deploy a new release of your application or patch a bug on your entire fleet of devices.
- Before deploying a new Micro-update on the Production group, it is recommended to deploy the Micro-update on the Test group first and make sure that everything works as planned.
- When the update's status turns to Success, go back to the "Updates" category, to the recent updates table, find the relevant Micro-update row and click on Deploy to others in order to deploy the same Micro-update on the Production group.
Running commands Before and After
You can choose to run a Bash command or a Bash script before and/or after the Micro-update is deployed on the edge-device. Most bash commands will work, please note the exceptions below.
- Any command that is requiring user input. If such command is ran, the update will stuck. The solution for that can be to run the next command before your command: DEBIAN_FRONTEND=noninteractive. In any case, it is recommended to check that this solution works with your devices.
- apt upgrade - Upgrading your device kernel and core packages may result in a bricked device. We strongly not recommend running that command at all.
In case you decide to run that command, you must run it from the Remote Command using a command. The full command must be: DEBIAN_FRONTEND=noninteractive apt -y update; DEBIAN_FRONTEND=noninteractive apt -y upgrade; reboot
Using Rollback in case of a failure
When creating a new Micro-update, make sure to fill out the "Micro Update Rollback" section as desired. Those settings will be executed when a Micro-update fails for any reason.
Container Updates
Container updates are updates for containers. You can deploy a new release of your container on your entire fleet of devices. Currently, container updates are available only for Docker containers.
Requirements
- Private or Public repository at https://hub.docker.com/
- Docker engine must be installed on the Linux device.
Install docker
Upswift container update tool uses the Docker engine as the basis for the container update. Before using Upswift container update, please make sure that the docker engine is installed on the device. To install docker on any type of device architecture run the next command:
curl -fsSL https://get.docker.com | sh
Container update flow
After creating a container update, the following steps will be executed on the edge devices:
- If private repository, login to Dockerhub using your access token.
- Pull the container image.
- Stop any containers that are running using the same repository name.
- Run a container using the new pulled image.
- If succeeded running the new container, removing the old container. If an error occurred, re-running the old container(s).
- If specified, removing the image of the old container(s).
Docker Hub access token
Upswift container update tool uses the Docker Hub access token to pull images from your private repository in order to deploy the container update on your devices. Make sure to create an access token and to provide it when creating the container update at Upswift dashboard.
Follow the next steps to create an access token at the Docker Hub dashboard:
- Login to your account at https://hub.docker.com/
- Click on your username at the top right corner.
- Click on ‘Account Settings’, and move to the ‘Security’ section.
- Under the ‘Access Tokens’, click on the ‘New Access Token’ button.
- Enter the description for your access token (for example: ‘Upswift’) and click on the ‘Create’ button.
- Copy the access token (example of similar token: a0b35e8e-8ebb-49d0-8297-4fa407887e22).
- Paste the token in the relevant place when creating container update in Upswift dashboard.
Container RollBack
Upswift Agent detects errors while deploying container updates. If an error is detected during the deployment process, it will automatically bring up and re-run the previous container that was running with the same image name.
For example: Before the deployment, a container of the image: test with the tag: v1 was running. We deploy a new release of the same image test, but with a new tag: v2. If during the deployment process an error occurred, Upswift agent will re-run the container with the tag: v1. You will receive a message with the error explained.