Warning: Permanently added ‘’ (ED25519) to the list of known hosts.
time=“2024-06-17T14:35:32Z” level=warning msg=“The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string.”
no such service: -debug
The terminal process “sshpass ‘-p’, ‘torizon’, ‘ssh’, ‘-p’, ‘22’, ‘-o’, ‘UserKnownHostsFile=/dev/null’, ‘-o’, ‘StrictHostKeyChecking=no’, ‘torizon@’, ‘LOCAL_REGISTRY= TAG=arm64 docker compose pull -debug’” terminated with exit code: 1.
`
I’ve noticed that this is due to the compose file on the board not being correct.
Each of the sub-projects override each others compose files, since the “copy-docker-compose” task puts it in the home directory.
At that point it’s basically a free for all, as to when which task actually starts, and which crash.
Is there an easy way to create a subdirectory for each sub-project, so they don’t collide?
Or is there another solution for this?
Any help is appreciated,
Regards
HTKMBU
P.S.
I know that the Multi-Container Project stuff is experimental, so if it does not work this way then that’s fine.
In that case however I would be glad for some pointers in the direction of how to set up a debug configuration with multiple containers in the docker-compose.yml (in a single project), since the ones generated by default only run the specific service (debug or release), and none of the other services specified in the compose file.
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?
Hello,
Addressing the issue you’re encountering with the “pull-container-torizon-debug-arm64” task and the subsequent challenges with Docker Compose in a multi-container project setup, there are a couple of strategies you might consider to resolve the conflicts and streamline your debugging process.
Subdirectory for Each Sub-Project: Creating a subdirectory for each sub-project’s Docker Compose file is a practical approach to prevent them from overriding each other. You can modify the “copy-docker-compose” task in your automation (e.g., Makefile, script) to copy each project’s Docker Compose file into its designated subdirectory on the board. This ensures that each project’s containers are managed independently. When running Docker Compose commands, you’ll need to specify the path to the relevant compose file using the -f or --file option, e.g., docker-compose -f path/to/specific/docker-compose.yml up.
Custom Docker Compose Files for Debugging: For a setup that involves multiple containers across sub-projects, consider creating a custom Docker Compose file for debugging purposes. This file would include definitions for all the services involved in your project, with adjustments made for debugging configurations as needed. This approach allows you to launch and manage all related services with a single command, facilitating a more integrated debugging environment. You can specify service dependencies using the depends_on attribute to control the startup order and ensure that services are launched in the correct sequence.
Environment-Specific Compose Files: Docker Compose supports extending base compose files with additional environment-specific configurations using multiple compose files. This feature can be used to overlay a debug-specific compose file on top of your base compose file, allowing you to define or override configurations for debugging without affecting the base setup. The command to use multiple compose files looks like this: docker-compose -f docker-compose.yml -f docker-compose.debug.yml up. This method provides flexibility in managing different configurations for development, testing, and production environments.
Service-Specific Debugging: If integrating all services in a single Docker Compose file for debugging is not feasible, consider launching only the specific service you need to debug along with its dependencies. This can be achieved by specifying the service name with the docker-compose up command. For a more integrated debugging experience across multiple services, you might need to explore more advanced orchestration or debugging tools that can handle complex multi-service scenarios.
Remember, when working with Docker and Docker Compose on Torizon,
Please, also check if these links can help you solve your problem:
I checked with our team and it seems this is a known issue/limitation with multi-container project configuration. This is on our radar to be addressed in the future.
If you’re curious to try, they did say that removing the "torizon_workspace": "${workspaceFolder}" setting from .vscode/settings.json could resolve this particular issue. It’d be appreciated if you could give this a try and let me know if that worked or not.
Just to add to this, you have to only remove the entry in the .vscode/settings.json file, but not the one from the *.code-workspace file.
It seems that this one takes precedence over the one in the workspace file.
(Specifically, the entry in the workspace file has the double-dot, which causes it to always deploy the compose file from the parent directory.)
From that point it mostly works.
I tend to get an error stating that the torizon_default network is “ambiguous”, but just performing a “docker compose down” on the board causes it to clean everything.
(This may also be resolved by specifying a custom network in the compose file, but I haven’t seen the error enough to bother checking)
Running a single part of the application also works as expected.
Glad that information was able to help you a bit. Thank you also for the feedback it’s very helpful for our development team.
I tend to get an error stating that the torizon_default network is “ambiguous”, but just performing a “docker compose down” on the board causes it to clean everything.
By the way our team was wondering. Do you get this error if you try to run any of your projects separately, like a single container project? Or is it only in this multi-project configuration?
