Introduction

Pour build des images conteneur en 2026, vous avez le choix :

• docker build : classique, depend du daemon Docker
• Buildah : build sans daemon, scriptable en bash, integre a Podman
• Buildkit : moteur de build avance, utilise par defaut dans Docker recent et integre a docker buildx

Ce tuto couvre les deux outils.

Prerequis

• VPS Linux Debian / Ubuntu / Rocky
• Acces root pour installer
• User non-root pour rootless

Partie 1 : Buildah

Etape 1 : Installation Buildah

sudo apt update
sudo apt install -y buildah
buildah --version

Etape 2 : Build a partir d'un Containerfile

Containerfile :

FROM alpine:3.18
RUN apk add --no-cache nginx
COPY index.html /var/www/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

buildah bud -t monsite:1.0 .

bud = "build using dockerfile". Pas de daemon. Pas de root. Genere une image OCI valide.

Etape 3 : Lister les images

buildah images

Ou avec podman :

podman images

Buildah et Podman partagent le storage backend.

Etape 4 : Build mode imperatif (scriptable)

Le vrai pouvoir de Buildah : construire des images en bash :

#!/bin/bash
ctr=$(buildah from alpine:3.18)
buildah run $ctr apk add --no-cache nginx
buildah copy $ctr ./index.html /var/www/html/
buildah config --port 80 --cmd '["nginx", "-g", "daemon off;"]' $ctr
buildah commit $ctr monsite:1.0
buildah rm $ctr

Beaucoup plus flexible qu'un Dockerfile : vous pouvez injecter de la logique conditionnelle, des boucles, lire des fichiers externes, etc.

Etape 5 : Push vers une registry

buildah login registry.votre-domaine.fr
buildah push monsite:1.0 registry.votre-domaine.fr/monequipe/monsite:1.0

Etape 6 : Multi-arch (ARM + x86)

buildah bud --platform=linux/amd64,linux/arm64 -t monsite:1.0 .

Buildah utilise QEMU pour emuler les architectures non-natives. Installez d'abord :

sudo apt install -y qemu-user-static

Partie 2 : Buildkit

Etape 1 : Installation Buildkit

Buildkit est integre a Docker recent. Verifiez :

docker buildx version

Si manquant :

sudo apt install -y docker-buildx-plugin

Etape 2 : Creer un builder

docker buildx create --name monbuilder --driver docker-container --use
docker buildx inspect --bootstrap

Etape 3 : Build basique

docker buildx build -t monsite:1.0 --load .

--load charge l'image dans le daemon local. Sans, l'image reste dans le cache buildx.

Etape 4 : Multi-arch avec Buildkit

docker buildx build \
    --platform linux/amd64,linux/arm64,linux/arm/v7 \
    -t registry.votre-domaine.fr/monequipe/monsite:1.0 \
    --push .

Push direct vers la registry, sans charger les images localement. Tres rapide.

Etape 5 : Cache distribue

Le gros avantage de Buildkit : cache partage entre builds.

docker buildx build \
    --cache-from type=registry,ref=registry.votre-domaine.fr/cache/monsite:cache \
    --cache-to type=registry,ref=registry.votre-domaine.fr/cache/monsite:cache,mode=max \
    -t monsite:1.0 \
    --push .

Le cache est stocke dans la registry. Le prochain build sur une autre machine reutilise ce cache. Indispensable pour les CI/CD.

Etape 6 : Secrets au build time

Pour ne pas baker un secret dans l'image :

Dockerfile :

FROM alpine
RUN --mount=type=secret,id=apikey \
    cat /run/secrets/apikey > /tmp/key && \
    do-something-with-key && \
    rm /tmp/key

docker buildx build --secret id=apikey,src=./apikey.txt -t monsite:1.0 .

Le secret n'apparait nulle part dans l'image finale ni dans les layers.

Etape 7 : SSH agent forwarding

Pour cloner un repo prive pendant le build :

FROM alpine
RUN apk add --no-cache git openssh
RUN --mount=type=ssh git clone [email protected]:monorga/private-repo.git

eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519
docker buildx build --ssh default -t monsite:1.0 .

Etape 8 : Bake (orchestration de plusieurs builds)

docker-bake.hcl :

group "default" {
  targets = ["api", "frontend", "worker"]
}

target "api" {
  context = "./api"
  dockerfile = "Dockerfile"
  tags = ["registry.votre-domaine.fr/monequipe/api:latest"]
  platforms = ["linux/amd64", "linux/arm64"]
}

target "frontend" {
  context = "./frontend"
  tags = ["registry.votre-domaine.fr/monequipe/frontend:latest"]
}

target "worker" {
  context = "./worker"
  tags = ["registry.votre-domaine.fr/monequipe/worker:latest"]
}

docker buildx bake --push

Build et push 3 images en parallele.

Partie 3 : Build dans Kubernetes (Kaniko)

Pour build dans un Pod K8s, utilisez Kaniko (Google) :

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args:
    - "--dockerfile=/workspace/Dockerfile"
    - "--context=git://github.com/monorga/monrepo.git"
    - "--destination=registry.votre-domaine.fr/monequipe/monsite:1.0"

Pas de daemon Docker dans le Pod, pas de privileges root. Securise et adapte aux clusters multi-tenants.

Comparatif rapide

Depannage

Buildah : "newuidmap: write to uid_map failed"

Meme probleme que Podman rootless. Configurez les subuid/subgid :

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 votreuser

Buildkit : "no builder found"

docker buildx create --use
docker buildx inspect --bootstrap

Build tres lent

Activez le cache :

docker buildx build --cache-from ... --cache-to ...

Ou ordonnez vos COPY/RUN du moins volatil au plus volatil pour maximiser le cache layer.

"no space left on device" pendant un build

Nettoyer le cache builder :

docker buildx prune
buildah rmi -a

Multi-arch builds qui timeout

QEMU emulation est lent. Considerez :

• Builders natifs ARM (Raspberry Pi, ARM instances cloud)
• Build remote sur builders dedies par arch

Commandes utiles

Buildah

buildah bud -t image:tag .
buildah from image-base
buildah images
buildah containers
buildah commit ctr-id image:tag
buildah push image:tag registry/image:tag
buildah login registry
buildah rm --all
buildah rmi --prune

Buildkit / buildx

docker buildx ls
docker buildx create --use
docker buildx build -t image:tag .
docker buildx build --platform linux/amd64,linux/arm64 -t image:tag --push .
docker buildx bake
docker buildx prune
docker buildx imagetools inspect image:tag    # voir les variantes arch

Conclusion

Pour 2026 :

• Buildah : si vous etes dans l'ecosysteme Red Hat / Podman, ou voulez du scripting bash
• Buildkit (buildx) : si Docker, et pour des builds rapides avec cache distribue
• Kaniko : pour builds dans K8s

Tous produisent des images OCI 100% compatibles entre eux.

Pour aller plus loin :

• Combinez avec Cosign pour signer vos images
• Activez SBOM generation pour la traceabilite supply chain
• Pour des builds reproductibles, regardez Nix ou Bazel

Ressources

• Buildah : https://buildah.io
• Buildkit : https://github.com/moby/buildkit
• Docker buildx : https://docs.docker.com/build/buildx/
• Kaniko : https://github.com/GoogleContainerTools/kaniko