Skip to content

You are viewing documentation for Instruqt 2.0 Labs. For Tracks documentation, please visit docs.instruqt.com.

A Container resource lets you create and configure Docker containers that make up your lab environment. Containers provide the compute layer of your sandbox, allowing you to run applications, services, and tools that participants will use during hands-on exercises.

Through the UI, you can define container settings such as the image, startup commands, exposed ports, and environment variables, all without needing to write configuration files. You can also connect containers to networks, manage how they interact within the lab, and make them accessible through terminal tabs for users to interact with directly.

Containers make it easy to design flexible, interactive environments that replicate real-world systems and support a wide range of lab scenarios.

Container resources can be created in the Sandbox tab. To create a new Container resource, navigate to the Sandbox tab and click the + button. Select Container from the dropdown menu.

Start by naming the container. Note that this is an internal name. You can assign a variety of settings to your container, but you also have the option to use a preset. Presets are pre-configured images for common container setups that can help you get started quickly. You can choose a preset from the Select preset dropdown menu:

Alternatively, you can select your own public or private image. By selecting “Add a new public or private image on GCP” you can add a custom image in the input.

To edit a container resource, you can select it from the list of existing sandboxes in the Sandbox tab. Click on the container you want to edit, make your changes in the configuration panel, and then click Add changes to save your updates. See Editing & Publishing for how changes are reviewed and published.

The container form is organized into collapsible sections. The Image and Resources sections are expanded by default. All other sections are collapsed and can be expanded by clicking on them.

FieldRequired?DefaultDescription
Image✓Docker image for the container

Selecting a custom image, rather than a preset, also reveals Username and Password fields for pulling from a private registry.

You can attach a container to one or more networks. Each attachment has its own set of fields:

FieldRequired?DefaultDescription
ID✓Select the network to attach the container to
IP AddressStatic IP address for the container on that network
AliasesAlternate names for the container on that network
FieldRequired?DefaultDescription
CPU Limit1000CPU limit for the container
Memory Limit256Memory limit in MB
Disk LimitDisk space limit in MB
CPU PinningPin the container to one or more CPU cores
GPU DriverGPU driver for the container
GPU Device IDsGPU device IDs for the container
Max Restart CountMaximum restart attempts (-1 for unlimited, 0 to disable restarts)
FieldRequired?DefaultDescription
EntrypointOverride the default entrypoint
CommandCommand to run in the container

This section also includes a Run As group to override the user and group the container runs as:

FieldRequired?DefaultDescription
UserUsername or user ID to run the container as
GroupGroup name or group ID to run the container as

Leave both fields empty to use the default user defined in the container image.

FieldRequired?DefaultDescription
Environment VariablesKey-value pairs for environment variables
FieldRequired?DefaultDescription
LabelsKey-value pairs set on the container
FieldRequired?DefaultDescription
DNS ServersCustom DNS servers for the container

Each port entry supports the following fields:

FieldRequired?DefaultDescription
Local Port✓Port the app listens on inside the container
Host PortOptional host port to bind
ProtocoltcpProtocol type: tcp or udp
FieldRequired?DefaultDescription
Range✓Consecutive port range to expose (e.g. 8080-8090)
Enable HostfalseExpose the port range on the host
ProtocoltcpProtocol type: tcp or udp
FieldRequired?DefaultDescription
Source✓Source path on the host machine
Destination✓Destination path inside the container
TypeMount type: bind, volume, or tmpfs
Read OnlyfalseMount the volume as read-only
Bind PropagationPropagation mode for bind mounts: shared, private, slave, rslave, or rprivate
SELinux RelabelSELinux relabeling mode: shared or private
FieldRequired?DefaultDescription
Timeout30sHealth check timeout

You can add any number of HTTP, TCP, and Exec health checks. Each type is its own list, so a container can have several checks of the same type at once.

HTTP

FieldRequired?DefaultDescription
Address✓Healthcheck URL
MethodGETHTTP method
BodyRequest body
HeadersHTTP headers
Success Codes200Expected success codes

TCP

FieldRequired?DefaultDescription
Address✓Healthcheck address

Exec

FieldRequired?DefaultDescription
CommandHealthcheck command
ScriptHealthcheck script
Exit Code0Expected exit code

The health check script is a probe that decides whether the container is healthy - it is not for setup or lifecycle scripting. To run setup scripts against a container, create an Exec resource targeting it.

FieldRequired?DefaultDescription
PrivilegedRun the container in privileged mode
AddAdd Linux capabilities to the container
DropDrop Linux capabilities from the container

The Container resource serves as the core compute component of your sandbox, enabling you to run the applications, services, and tools used in hands-on labs. You can easily create and configure containers through the UI by choosing a preset image or defining your own, setting startup commands, ports, and environment variables, all without writing configuration files.

For more granular control, containers can also be fine-tuned using advanced configuration options such as volumes, health checks, networks, and resource limits.

Overall, container resources make it simple to build flexible, interactive environments that closely replicate real-world systems and provide an engaging learning experience.