I have an apalis iMX8 board with torizoncore 4.0.0 installed. I have completed the development of my Torizon C++ project via Visual studio 2019 and now I have release built and deployed the project on the module.
Torizon C++ project properties set for release configuration:
targetfiles: COPY work/bin /bin/
targetcommands: CMD [ "/bin/MyProject.out" ]
So now I get my application running successfully in a debian container on the module, right after I deployed the project. I can also see the output logs via #docker logs CONTAINER_ID -f.
Everything looks good! Now I need to autorun my application on device startup.
I followed the following tutorial: How to Autorun Application at the Start up in Linux and wrote a systemd service to start the release built - application container as below:
ExecStart=/usr/bin/docker start <CONTAINER_ID>
This works as expected. The application starts running right on the device startup. However, as you can see in the above script, I have to hardcode the container_ID if I go this way, which I think is not a good solution. The container ID/name keeps on changing every time you deploy your solution (could be a problem when you want to update your application) a new time.
Can I get the container name a constant? If yes, how can I do that? Is there any property I need to set in Torizon C++ application properties for that?
Or is there a different way to achieve the autorun of your application (in container) on module startup?
Question about Torizon OTA update service:
I checked the website http://app.torizon.io and provisioned my Toradex device. I could not find more details or tutorials on how to deal with your application updates on your device. I understood that you can update the OS. But how do I update my own custom application using Torizon OTA services? Do I need to update my running container for this? If that’s the case how do I do that? How will it affect the autorun of my application?
I’m glad to see you were able to come up with a method for auto-starting your containerized application. However allow me to show you a more manageable alternative that should also hopefully solve the issues you have with your current method.
First of all if you’re not familiar with “Docker Compose” I’d suggest looking over the following article: https://developer.toradex.com/knowledge-base/multi-containers-torizon-core
While this article seems to be for multi-container applications, docker-compose can also be used for single container applications. With a docker-compose file you can define container parameters and constants like the name of a container for example. You can then invoke this file to start the defined containers with the parameters you set in the yml file. This will allow a more practical way for you to start your container(s), without having to rely on “docker run” commands or non-constant “ID”" numbers.
As for auto-starting a docker-compose, there’s actually already a method for this built into Torizon. By default there’s a systemd service called “docker-compose” on TorizonCore. It auto-starts any docker-compose.yml file that’s in the
/var/sota/storage/docker-compose/docker-compose.yml path. You can also look up the service file on the system to get a better idea of how it works but it works similarly to what you have now but it instead uses docker-compose.
So this actually then leads into the OTA updates for containerized applications. To be clear at the moment this particular feature isn’t publicly available yet as it’s still undergoing development and testing. However it is expected we will have container updates available soon so please keep an eye out for this. But to elaborate container updates via OTA and all of our other upcoming tooling surrounding Torizon, assume that you’re managing/starting containers via the docker-compose method I outlined above.
This is why I highly suggest you adopt this method so that you can make the most out of our tooling. We are also in the process of creating documentation for this auto-start method but it’s not ready yet. However the method itself should be ready and working so please let me know if you have any issues or further questions about it.
Thanks for the detailed answer. To start with, I edited the docker-compose.yml file in the /var/sota/storage/docker-compose path to something like this:
I deployed my solution(release built) just once on the board and have given the name of that debian image in the docker compose service. Will hardcoding the name of the image be a problem? Will it affect the OTA updates in future?
There should be no problem with the exact image name in fact that’s it is usually done. Hashes are also an option but moreso if you want to target a very specific version of a container image.