Debug Torizon Project with VS Code, leaving all the other containers

Technical Support
, ,
1

I have my Verdin iMX8M-Plus SoM running Torizon OS with some containers.
Now I need to develop another part of my application, and so I created a new Torizon Project using Torizon IDE Extension (Python 3 Console Application).
I can debug it from VS Code using the Torizon IDE Extension.
This is ok.
But I see that all the other containers are stopped and removed.
I need that they’re not touched on the module.
I don’t need to attach a debugger to them.

How can I get this result?

2

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:

Hand-shake,

To debug your Torizon project in Visual Studio Code using the Torizon IDE Extension without stopping or removing other running containers, you should adjust the debug configuration to ensure it doesn’t interfere with the existing containers. By default, the Torizon IDE Extension might be configured to clean the environment to ensure a fresh start for the application being debugged, which can lead to stopping and removing other containers.

To achieve your goal, follow these steps:

  1. Modify the Docker Compose File: The Torizon IDE Extension uses Docker Compose files to manage container configurations. Locate the docker-compose.yml file in your project directory. This file defines how your application is run, including any dependencies on other containers. Ensure that your service definition does not conflict with the existing containers. You might need to specify non-conflicting ports and network settings.

  2. Adjust the VS Code Debug Configuration: In your project’s .vscode folder, there’s a launch.json file that contains configurations for debugging. Look for any settings that might instruct the IDE to stop or remove other containers and adjust accordingly. Unfortunately, if the Torizon IDE Extension automatically stops other containers as part of its debug routine, you might have limited control over this behavior directly from the debug configuration.

  3. Use Docker Compose Overrides: Docker Compose supports override files that allow you to modify your application’s configuration without altering the base docker-compose.yml file. You can create a docker-compose.override.yml file for your debug environment that specifically ensures it does not interfere with other containers. This might involve setting up dedicated networks or volumes that do not conflict with those used by your other containers.

  4. Manual Container Management: As a last resort, if the IDE Extension does not support the desired behavior through configuration, you may need to manually manage your containers for debugging. This involves using Docker commands to start your debug container without stopping the others. While this approach offers more control, it bypasses the convenience of the IDE Extension for debugging.

Please note, these steps provide a general direction. The specific implementation might vary based on your project’s configuration and the current behavior of the Torizon IDE Extension. If the extension does not currently support non-disruptive debugging in a way that meets your needs, consider reaching out to the community or forums for more targeted advice or to request this feature in future updates.

Best regards,
Toradex AI Assistant

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

Deploying Container Images to Torizon OS | Toradex Developer Center.

3

I verified that the pre-cleanup task (defined in tasks.json) is responsible to stop all the running containers, and to remove them.
Removing this task from wait-debugpy-start-arm64 task dependencies did the trick.

But looking deeper, I see that

"args": [
  "[",
  "${command:cleanLock}",
  "==",
  "false",
  "];",
  "then",
  "DOCKER_HOST=${config:torizon_ip}:2375",
  "docker",
  "compose",
  "-p",
  "torizon",
  "down",
  "--remove-orphans",
  ";",
  "fi"
],

And so the question is:
is ${command:cleanLock} a parameter than can be used to execute or not the docker compose down?

I thought that the best option would be leaving the task pre-cleanup, removing --remove-orphans so that everything described in docker-compose.yml is stopped, but in this way all the containers are stopped.
Even if the documentation of docker compose down says

Stops containers and removes containers, networks, volumes, and images created by up

It’s true that all the containers running in the SoM have been started by their docker-compose.yml, but…

4

Hello @vix,

This is correct, however the command cleanLock returns an internal flag from the extension that is used to check if the pre-cleanup task already ran. This is used to fix race conditions on the multi-container projects.

Considering your use case, you may want to change the task to only bring down a specific service, for example:

      {
          "label": "pre-cleanup",
          "detail": "",
          "hide": true,
          "command": "if",
          "type": "shell",
          "args": [
              "[",
              "${command:cleanLock}",
              "==",
              "false",
              "];",
              "then",
              "DOCKER_HOST=${config:torizon_ip}:2375",
              "docker",
              "compose",
              "-p",
              "torizon",
              "down",
              "testcconsole-debug",
              ";",
              "fi"
          ],
          "dependsOrder": "sequence",
          "dependsOn": [
              "remove-dangling-images",
              "wait-a-bit"
          ],
          "problemMatcher": "$msCompile",
          "icon": {
              "id": "flame",
              "color": "terminal.ansiYellow"
          }
      },

Please note that this may cause issues when not debugging.

Best Regards,
Bruno