Containerization#
This guide covers building and managing SmartEM Decisions container images.
Docker/Podman Operations#
Basic Build (Default Configuration)#
Build the container with default settings (runs as root):
# Docker
docker build -t smartem-decisions .
# Podman
podman build --format docker -t smartem-decisions .
Build with Custom User (DLS Deployment)#
For production deployment at Diamond Light Source, build with custom UID/GID to enable /dls
filesystem access:
# Docker
docker build \
--build-arg groupid=1000 \
--build-arg userid=1000 \
--build-arg groupname=smartem \
-t smartem-decisions:dls .
# Podman
podman build --format docker \
--build-arg groupid=1000 \
--build-arg userid=1000 \
--build-arg groupname=smartem \
-t smartem-decisions:dls .
See Container User Configuration for detailed information about build arguments and deployment scenarios.
Running Containers#
# Docker - run API service
docker run -p 8000:8000 -e ROLE=api smartem-decisions
# Podman - run API service
podman run -p 8000:8000 -e ROLE=api localhost/smartem-decisions
Cleanup#
# Docker
docker image rm smartem-decisions -f
# Podman
podman image rm localhost/smartem-decisions -f
Tagging and Pushing Images#
GitHub Container Registry (Current)#
# Tag the image
docker tag smartem-decisions ghcr.io/diamondlightsource/smartem-decisions:latest
# Login to GitHub Container Registry
echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin
# Push the image
docker push ghcr.io/diamondlightsource/smartem-decisions:latest
Tagging Strategies#
# Development/staging build
docker tag smartem-decisions ghcr.io/diamondlightsource/smartem-decisions:dev
docker tag smartem-decisions ghcr.io/diamondlightsource/smartem-decisions:staging
# Production build with version
docker tag smartem-decisions ghcr.io/diamondlightsource/smartem-decisions:1.0.0
docker tag smartem-decisions ghcr.io/diamondlightsource/smartem-decisions:latest
# Production build with custom user
docker tag smartem-decisions:dls ghcr.io/diamondlightsource/smartem-decisions:production
Multi-Stage Build Architecture#
The Dockerfile uses a multi-stage build process:
developer stage: Base Python image with system dependencies
build stage: Installs Python packages and application code
runtime stage: Slim image with only runtime dependencies and built application
This approach:
Minimizes final image size
Separates build tools from runtime environment
Enables efficient layer caching
Build Arguments Reference#
Argument |
Default |
Purpose |
---|---|---|
|
|
Python version for base images |
|
|
Group ID for container user (0 = root) |
|
|
User ID for container user (0 = root) |
|
|
Name for group and user |