Skip to content

redhat-et/triton-dev-containers

Repository files navigation

Triton Dev Containers

TL;DR

  • 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.

Details

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.

Available Containers

This repository offers two types of development containers:

  1. Vanilla Containers – Containers where a development directory can be mounted.
  2. VSCode DevContainers – Configured for use with Visual Studio Code via the Dev Containers Extension.

Prerequisites

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.

Supported Hardware

  • NVIDIA GPUs
  • AMD GPUs
  • CPUs

Using Vanilla Containers

Building the Triton NVIDIA Vanilla Container

make triton-image

Running the triton NVIDIA vanilla container

 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 and git submodule update on the mounted repo if you haven't already run these commands.

Building the triton-cpu vanilla container

 make triton-cpu-image

Running the triton-cpu vanilla container

 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 and git submodule update on the mounted repo if you haven't already run these commands.

Building the triton-amd vanilla container

 make triton-amd-image

Running the triton-amd vanilla container

 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 and git submodule update on the mounted repo if you haven't already run these commands.

Using .devcontainers with VSCODE

Please see the .devcontainer user guide

Demos

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

Why Container-First Development Matters?

Please checkout why container-first development matters here.

More about the containers

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.

Adding packages as a non-root user inside the development containers

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

Why do the containers install some dependencies at startup time?

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.

About

Development containers for triton and triton-cpu

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 3

  •  
  •  
  •