Manage sub-containers with DockerBoard

Enable multi-container isolation when creating an instance

1. Log on to the PAI console, go to the DSW page, and click Create Instance.

2. In the instance settings, find the Enable Multi-Container Isolation (DinD) toggle and turn it on.

3. After you enable DinD, the following configuration options appear:

   • Restrict roles that can access the main container: select the workspace roles that you want to restrict from the drop-down list. Users with restricted roles cannot directly open or operate the DSW primary container and can only develop by connecting to sub-containers over SSH.

     For example, if you select Algorithm Development, users with the Algorithm Developer role cannot access the primary container, but can still create and use their own sub-containers from the Sub-container Management tab on the instance details page.

     If no role is selected, all authorized users can access the primary container as usual, which is consistent with the existing behavior.

   • Maximum Number of Sub-containers: set the maximum number of sub-containers allowed for this instance. You can specify an integer from 1 to 16. The default value is 10.

   • Data Catalog Fencing Configuration: specify the path to the data directory isolation configuration file inside the primary container. The default path is /etc/docker/dockerboard/mount_access.json. This configuration file controls which data directories users can mount when creating sub-containers. You can click Configuration Template Download to download the configuration file template first. For the subsequent configuration steps, see Configure data directory isolation.

4. Complete the remaining instance settings and click Create to create the instance.

Configure data directory isolation

Data directory isolation controls which data directories each developer can mount when creating sub-containers, preventing developers from accessing data stored by other users.

Configuration steps:

1. On the instance creation or editing page, click the Configuration Template Download link below Data Catalog Fencing Configuration to download the JSON template file.

2. Edit the downloaded template to define the allowed directories for each RAM user UID.

3. Place the completed mount_access.json file at the path specified in the DSW primary container configuration (the default is /etc/docker/dockerboard/mount_access.json).

Configuration file format:

The configuration file is in JSON format. Each key is a RAM user's UID, and each user entry can include an Allow field (list of directories the user can mount) and a Deny field (list of directories the user cannot mount). Example:

{
  "123124432xxx": {
    "Allow": [
      "/mnt/workspace",
      "/mnt/data1"
    ],
    "Deny": [
      "/mnt/data2"
    ]
  },
  "224321234xxx": {
    "Allow": [
      "*"
    ]
  }
}

Field descriptions:

Configuration behavior:

• If the configuration file exists and has a valid format, the system validates whether the current user has permission to mount the selected directories when a sub-container is created.

• If the current user's UID is not found in the configuration file, the user cannot mount any data directories when creating a sub-container. The following message appears: "Your account does not have any available DSW paths. If you need to mount directories, contact the instance owner to add your configuration."

• If the configuration file path is empty or the file does not exist, the system does not enforce directory isolation and all users can mount any directory in the primary container.

Open the sub-container management page

1. Log on to the PAI console and go to the DSW page.

2. In the instance list, click the name of the target instance that has DinD enabled to go to the instance details page.

3. On the instance details page, click the Sub-container Management tab to open the management page.

Create a sub-container

On the sub-container management page, click the Create Sub-container button and complete the following settings in the creation form.

Basic information

Environment settings

Resource settings

After you complete the settings, click Confirm to create the sub-container. You can click Child Container Creation Progress on the sub-container management page to track the creation progress.

Manage sub-containers

In the sub-container list, the following actions are available for each sub-container:

You can only manage sub-containers that you created.

• Start: restart a stopped sub-container.

• Stop: stop a running sub-container. After the container is stopped, all processes inside are terminated, but the container configuration and mounted storage data are preserved.

• Restart: restart a running sub-container. This stops and then starts the container in a single operation.

• Logs: view the runtime logs of the sub-container for troubleshooting.

• SSH connection details: view the SSH connection information for the sub-container, including the connection username and connection command.

• Delete: delete the sub-container. After deletion, any data that was not persisted through mounted storage is permanently lost and cannot be recovered. Proceed with caution.

View the sub-container list

The sub-container management page displays a list of all sub-containers on the current instance. The list includes the following information:

All users with read access to DSW can view the full sub-container list, but can only manage (start, stop, or delete) sub-containers they created.

View the creation task list

Sub-container creation can take a while, especially when pulling large images. The system provides creation task tracking to help you monitor progress.

In the upper-right corner of the sub-container management page, click Child Container Creation Progress to view the status and logs of all container creation tasks. For tasks that are still in the Creating state, you can manually abort them. Task records are kept for 3 days and then automatically deleted.

Access a sub-container over SSH

After a sub-container is successfully created and enters the Running state, you can connect to it over SSH.

Steps:

1. In the sub-container list, find the target sub-container and click SSH connection details in the Actions column. The dialog shows the connection username and the full connection command.

2. Run the connection command in your local terminal to connect to the sub-container. The command format is:

ssh <connection_username>@<instance_public_IP> -p 22 -i <local_private_key_path>

Parameter descriptions:

After a successful SSH login, you are placed directly in the command-line environment of the corresponding sub-container. All sub-containers share port 22 of the DSW primary container. Each sub-container is isolated through its own unique SSH key and a dedicated connection username.

Q: Why can't I see the sub-container management tab on the instance details page?

Check the following:

1. The DSW instance was created with the Enable Multi-Container Isolation (DinD) feature enabled.

2. The DSW primary container is currently in the Running state. When the primary container is not running, the sub-container management tab is not displayed.

Q: Why can't I mount data directories when creating a sub-container?

This is likely because the instance owner has configured a data directory isolation policy, and your RAM user account has not been assigned any available directories in the configuration file. Contact the instance owner to add your configuration in mount_access.json.

Q: Why does my SSH connection to a sub-container fail?

Check the following in order:

1. Is the sub-container in the Running state?

2. Does the local private key match the public key provided when the sub-container was created?

3. Is SSH enabled on the DSW instance?

4. Can your network reach the instance's public IP address on port 22?

Q: Why does sub-container creation take so long?

Sub-container creation time depends mainly on the image pull speed. The first pull of a large image may take a considerable amount of time. You can monitor the progress and logs in the creation task list. When you create subsequent containers with the same image, the process is much faster because the image is already cached locally.

Q: Can I manage sub-containers created by other users?

By default, each user can only manage their own sub-containers, but can view basic information about all sub-containers. To manage another user's sub-containers, the instance owner must grant the appropriate permissions through a RAM policy.