Trouble getting my application onto custom image with TorizonCore Builder

AM62 Q 1GB WB IT V1.0A
Mallow Board V1.1A
TorizonCore 6.6.1 Build 14

After a few days of struggling with switching to TorizonOS and TorizonCore Builder I was able to successfully push my image to DockerHub, pull it using the bundle command, and then build the image with the build command. I have confirmed my Python application runs successfully when debugging it on the board through the IDE. I have confirmed that the new image was successfully deployed to my board, however I’m not certain my application is on the board, or if it is on the board, how to confirm its status and make it autorun.

The build says it successfully combined my image and docker container bundle.

Updating TorizonCore image in place.
Updating TorizonCore image in place.
Combining TorizonCore image with Docker Container bundle.

=>> Build command successfully executed!

Prior to switching to Torizon we utilized our own custom Yocto build with a service to autorun our application on start up. This made everything pretty straight forward, I could use systemctl to watch the status of it as well as our built in log files that are generated. With Torizon I’m still trying to understand the file structure of the OS and where I should be looking when troubleshooting and debugging. I am new to Docker all together so the containers are another layer of complexity here for me.

When I do ‘docker images’ on my board I do not see my container image that I would expect, so I don’t think its being bundled properly or maybe its just not running it.

How can I confirm that my image was or was not bundled properly?

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

To confirm whether your Docker container image was successfully bundled with your TorizonCore image using the TorizonCore Builder, and to ensure it’s set to autorun on startup, you can follow these steps:

  1. Verify the Bundle Process: First, ensure that the bundle command was executed correctly and that it pointed to the correct Docker container images or Docker Compose file. The command should reference the directory containing your Docker images or the Docker Compose file that defines your application stack. If this step was successful, the TorizonCore Builder would have integrated your Docker container image into the custom TorizonCore image.

  2. Inspect the Custom Image: After flashing the custom TorizonCore image to your board, you can inspect the image to see if it contains your Docker container. Connect to your board and use the command docker images to list all Docker images present on the system. If the process was successful, you should see your application’s Docker image listed.

  3. Check for Autorun Configuration: If your Docker container is meant to autorun on startup, ensure that you have configured it accordingly. This typically involves creating a Docker Compose file that includes the necessary settings to start your container automatically. For Torizon, this can be done by specifying restart policies in your Docker Compose file. A common policy for autorun scenarios is restart: always, which ensures that your container starts automatically upon system startup.

  4. Debugging and Logs: If your container is supposed to be running but isn’t, you can check Docker’s logs to troubleshoot. Use docker ps -a to see all containers, including those that have exited. For a container that has stopped or failed to start, use docker logs <container_name_or_id> to view its logs. This can provide insights into why the container didn’t start as expected.

  5. Systemd Integration for Docker Containers: Since you mentioned transitioning from a Yocto build with a systemd service for autorun, note that for Docker containers on Torizon, you might need to create a systemd service that starts your Docker container or Docker Compose project. This service file would call docker run or docker-compose up for your container or project, respectively. This approach allows you to use systemctl to start, stop, and check the status of your application as a service.

  6. Documentation and Examples: While direct links to documentation are not provided here, Toradex has extensive documentation on using Docker and Docker

Please, also check if these links can help you solve your problem:

Pre-provisioning Docker Containers onto a Torizon OS image | Toradex Developer Center.

After deleting all of my debugging images that were on my board and redeploying with the ‘restart: always’ as suggested, it appears as though my application is being deployed and running on boot as intended when I put the new OS Image on the board.

However, I seem to have a misconception about how the docker system works. I was under the impression that a docker container image is required to start an instance of the container.

When using ‘docker images’ I do not see my particular container image as I was expecting, but I do see my container instance running with ‘docker ps’.

torizon@verdin-am62-15036754:~$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
registry     2         27031dfcd859   8 months ago   24.9MB
torizon@verdin-am62-15036754:~$ docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                                                 NAMES
12d1c8de1c35   c3183b14987b   "/bin/sh -c '. ${APP…"   19 minutes ago   Up 23 seconds   0.0.0.0:5000->5000/tcp, :::5000->5000/tcp             torizon-remotemonitor-1
d4423346ae4e   registry:2     "/entrypoint.sh /etc…"   4 hours ago      Up 23 seconds   5000/tcp, 0.0.0.0:5002->5002/tcp, :::5002->5002/tcp   registry
torizon@verdin-am62-15036754:~$

Greetings @dleberfinger,

Your latest post leaves me quite confused. As far as I know you need to have a corresponding container image for each running container. For example if I try to remove a container image from my system that has a running container related to it I get something like this:

docker rmi c
Error response from daemon: conflict: unable to delete c69ac6bed067 (cannot be forced) - image is being used by running container 306918f17f5b

I’m not entirely sure how you managed this result on your system as you showed.

What was your exact process here?

So it looks like you ran torizoncore-builder build to produce your custom image with your bundled containers and docker-compose.yml file. Correct? After this did you then deploy your custom OS image using Toradex Easy Installer?

Best Regards,
Jeremias

@jeremias.tx

I built my Torizon OS image with torizoncore-builder build command and my docker-compose.prod.yml that was produced by the Torizon IDE create-production-image task runner. Once my new image is made, I deploy it to my board using the TorizonCore Builder tcb-deploy task runner. I have not installed the image through the Toradex Easy Installer yet.

I’m guessing something about the tcb-deploy is the problem?

I’m guessing something about the tcb-deploy is the problem?

I see you’re running torizoncore-builder via VSCode. When you deploy in this manner it deploys your changes over network using OSTree as the medium to push the changes. OSTree does not track changes related to containers. If you want your pre-bundled containers, and compose file to be present you need to flash your custom image using Toradex Easy Installer. It’s documented as such in this article here: Pre-provisioning Docker Containers onto a Torizon OS image | Toradex Developer Center

Best Regards,
Jeremias