- What this repo provides: Preconfigured development containers for building and running Triton and Triton-cpu.
- Who it's for: Developers working on Triton.
- Why use it: Provides isolated, reproducible environments for development.
- How to use it: Mount your Triton directory into the available containers and start working.
This repository provides development containers preconfigured with all the necessary tools to build and run Triton and Triton-cpu. By mounting your Triton directory from the host into the container, you can continue working with your preferred IDE while keeping build and runtime tasks isolated within the container environment. This repo also provides the .devcontainer files that can be used with the VSCode development container extension. The goal of this repo is to provide consistent and reproducible development environments for Triton.
This repository offers two types of development containers:
- Vanilla Containers – Containers where a development directory can be mounted.
- VSCode DevContainers – Configured for use with Visual Studio Code via the Dev Containers Extension.
Before using these containers, ensure you have the following installed:
- Docker or Podman
- NVIDIA Container Toolkit (Required for GPU usage with NVIDIA hardware)
- AMD ROCm (Required for GPU usage with AMD hardware)
- VSCode Dev Container Extension (Only needed for VSCode dev containers)
Note: If using an NVIDIA GPU, install the NVIDIA Container Toolkit.
Note: The NVIDIA Container Toolkit is not required for
triton-cpu
.
Note: If using an AMD GPU, install the ROCm Docker Prerequisites.
- NVIDIA GPUs
- AMD GPUs
- CPUs
make triton-image
make triton-run [triton_path=<path-to-triton-on-host>]
NOTE: if you do not provide
triton_path
the triton repo will be cloned at container startup time.
NOTE: if you do provide a triton_path you should run
git submodule init
andgit submodule update
on the mounted repo if you haven't already run these commands.
make triton-cpu-image
make triton-cpu-run [triton_path=<path-to-triton-on-host>]
NOTE: if you do not provide
triton_path
the triton-cpu repo will be cloned at container startup time.
NOTE: if you do provide a triton_path you should run
git submodule init
andgit submodule update
on the mounted repo if you haven't already run these commands.
make triton-amd-image
make triton-amd-run [triton_path=<path-to-triton-on-host>]
NOTE: if you do not provide
triton_path
the triton-cpu repo will be cloned at container startup time.
NOTE: it's also advised that you commit the image after it's completed initialization
[podman|docker] commit <container_id> quay.io/triton-dev-containers/amd:latest
NOTE: if you do provide a triton_path you should run
git submodule init
andgit submodule update
on the mounted repo if you haven't already run these commands.
Please see the .devcontainer user guide
To see the VSCODE devcontainers in action please check out the Triton devcontainer vscode demo
To see the vanilla development containers in action please checkout the Triton devcontainer demo
Please checkout why container-first development matters here.
The container images provided by this repo are based on RHEL UBI images. They support both root and non-root users. For non-root user support, the user is created at runtime via the container entrypoint script entrypoint.sh.
To add extra packages to the non-root user container, create a Dockerfile that extends one of the provided base/vanilla images:
- quay.io/triton-dev-containers/nvidia
- quay.io/triton-dev-containers/cpu
- quay.io/triton-dev-containers/amd
FROM quay.io/triton-dev-containers/nvidia:latest
USER 0
RUN dnf update -y && \
dnf -y install <PACKAGES> && \ #### <==== modify this line to add your packages.
dnf clean all
Some dependencies are installed at runtime to optimize image size of the development containers. This allows the images to remain lightweight while still providing all necessary functionality. The packages installed at startup time can be found in entrypoint.sh.