feat(dev): add Dockerfile for container deployment

[gaujain-nv]

Summary

This PR adds Docker container support for Slurm-web, enabling deployment via containers and Kubernetes.

Changes

• Added Dockerfile with multi-stage build:
  • Stage 1: Build frontend with Node.js
  • Stage 2: Build Python wheel
  • Stage 3: Runtime image with all dependencies
• Added docker-compose.yml for local development

Usage

# Build
docker build -t slurm-web:6.0.0 .

# Run gateway
docker run -e SLURM_WEB_MODE=gateway -p 5011:5011 slurm-web:6.0.0

# Run agent
docker run -e SLURM_WEB_MODE=agent -p 5012:5012 slurm-web:6.0.0

Testing

Tested on:

• ✅ Docker Desktop (macOS with ARM64 → AMD64)
• ✅ AWS EKS (Kubernetes 1.34)
• ✅ Slurm 25.11.0 via Slinky operator

Motivation

Currently Slurm-web is distributed via deb/rpm packages. Container support enables:

• Kubernetes deployment
• CI/CD pipelines
• Cloud-native environments (EKS, GKE, AKS)

Checklist

• Code follows project conventions
• Tested locally

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[gaujain-nv]

I have read the CLA Document and I hereby sign the CLA

[rezib]

Hello @gaujain-nv,

First, thank you very much for this contribution, this is really appreciated.

For the sake of clarity, do you work with @faganihajizada? He mentioned such contribution in #683 (comment).

I'd like to contribute a Dockerfile that:

• […]
• Supports both gateway and agent via SLURM_WEB_MODE env var

TBH, I'm not familiar with Docker and containers best practices. Is this the standard way to instantiate an application with different arguments in Docker world?

Describe alternatives you've considered

• Using package installation in a container (messy, large image)

Can you elaborate on why it would be messy to install Slurm-web packages in container images?

I see several advantages with this packages approach:

1. It simplifies the Dockerfile with less instructions, there is factorization with existing well tested packaging code. This would be less new code to maintain and support.
2. I have great tooling to maintain packages that allow me, for instance, to distribute bug fixed packages with patches without requiring to go through whole Slurm-web release process.

I'm willing to submit a PR with:

• […]
• docker-compose.yml (optional)

Yes please! I think it is expected by users.

• Documentation updates (optional)

Yes please, at least docs/modules/install/pages/install/containers/docker.adoc must be updated to explain how to start Slurm-web with docker-compose with the way to provide necessary files (eg. JWK) and configuration.

Questions:

1. Is this contribution welcome?

Of course!

2. Any preferences for base image or structure?

I think Debian stable is a good choice, well maintained by a great community.

3. Would you like container images published to GHCR?

Yes indeed, that's my intent.

[faganihajizada]

For the sake of clarity, do you work with @faganihajizada? He mentioned such contribution in #683 (comment).

@rezib we are going to meet and discuss this internally and we will get back to you on this. Thank you!

[rezib]

@rezib we are going to meet and discuss this internally and we will get back to you on this. Thank you!

Heh I guess the perspective has changed a bit considering the recent announcement 😅

[gaujain-nv]

Hi @rezib
Thank you for the detailed and thoughtful review! I really appreciate you taking the time to explain your preferences.

**Re: @faganihajizada ** - Yes! Fagani and I work together at NVIDIA. He raised the idea in #683, and I'm implementing it. We're coordinating on this effort.

Re: SLURM_WEB_MODE env var - This is a common Docker pattern for multi-mode containers (similar to how many apps use env vars to configure behavior at runtime). That said, if you prefer separate images for gateway and agent, I'm happy to restructure it that way. Please let me know your preference!

Re: Debian packages - You're absolutely right, and I apologize for the "messy" wording. I wasn't aware your packages were available for container use. Using your Debian packages is clearly the better approach:

• ✅ Simpler Dockerfile
• ✅ Leverages your well-tested packaging
• ✅ Easier for you to maintain and patch

I'll update the Dockerfile to use debian:bookworm-slim and install via apt.

Question: Could you share the exact repository URL and package name(s)? I tried:

[rezib]

Re: SLURM_WEB_MODE env var - This is a common Docker pattern for multi-mode containers (similar to how many apps use env vars to configure behavior at runtime). That said, if you prefer separate images for gateway and agent, I'm happy to restructure it that way. Please let me know your preference!

Well, I really don't know what's the best pattern for Slurm-web… so follow your own intuition for now!

I'll update the Dockerfile to use debian:bookworm-slim and install via apt.

Debian stable is trixie these days, bookworm is the oldstable with less maintenance workforce. Debian project publishes the debian:stable-slim symbolic tag name on Docker hub, I think this one should be preferred.

Question: Could you share the exact repository URL and package name(s)? I tried:

You can refer to: https://docs.rackslab.io/slurm-web/install/install/distribs/debian.html

It gives the URL of the keyring, the repository and package names.