JFrog Artifactory : votre registre Docker privé en production

Docker Hub est pratique pour commencer, mais ses limites (rate limiting, confidentialité, traçabilité) finissent par poser problème en production. Artifactory résout ces problèmes en centralisant la gestion de toutes vos images Docker.

Trois types de dépôts Docker dans Artifactory

Artifactory distingue trois types de dépôts, qui correspondent à trois usages différents :

Local — stocke vos propres images. C’est votre registre privé interne.

artifactory.example.com/docker-local/myapp:1.0.0

Remote — proxy vers un registre externe (Docker Hub, GHCR, ECR…). Les images téléchargées sont mises en cache localement.

artifactory.example.com/docker-hub/library/nginx:latest
# → Artifactory interroge Docker Hub et met en cache

Virtual — point d’entrée unique qui agrège local + remote. Vos équipes n’ont qu’une seule URL à configurer.

artifactory.example.com/docker-virtual/
# → résout depuis docker-local d'abord, puis docker-hub

Proxyfier Docker Hub : résoudre le rate limiting

Docker Hub limite les pulls anonymes à 100 pulls/6h par IP. Pour une infrastructure avec des dizaines de jobs CI/CD, c’est insuffisant. Un dépôt Remote Artifactory résout le problème :

# Configurer le daemon Docker pour passer par Artifactory
cat /etc/docker/daemon.json
{
  "registry-mirrors": ["https://artifactory.example.com/docker-hub"]
}

# ou dans vos Dockerfiles
FROM artifactory.example.com/docker-hub/python:3.12-slim

L’image est téléchargée une fois depuis Docker Hub, mise en cache dans Artifactory, et servie localement pour tous les builds suivants.

Intégrer dans un pipeline Jenkins

pipeline {
  environment {
    REGISTRY = 'artifactory.example.com'
    REPO     = 'docker-local'
    IMAGE    = "${REGISTRY}/${REPO}/myapp"
  }
  stages {
    stage('Build & Push') {
      steps {
        withCredentials([usernamePassword(
          credentialsId: 'artifactory-creds',
          usernameVariable: 'ART_USER',
          passwordVariable: 'ART_PASS'
        )]) {
          sh """
            docker login ${REGISTRY} -u $ART_USER -p $ART_PASS
            docker build -t ${IMAGE}:${BUILD_NUMBER} .
            docker tag ${IMAGE}:${BUILD_NUMBER} ${IMAGE}:latest
            docker push ${IMAGE}:${BUILD_NUMBER}
            docker push ${IMAGE}:latest
          """
        }
      }
    }
    stage('Scan Xray') {
      steps {
        // JFrog CLI scanner Xray
        sh "jfrog rt build-collect-env"
        sh "jfrog rt build-publish"
        sh "jfrog rt build-scan --fail=true"
      }
    }
  }
}

Build Info : la traçabilité complète

Artifactory peut enregistrer des Build Info — des métadonnées associant un artefact à son build CI : numéro de build, commit Git, résultats de tests, dépendances utilisées. Cette traçabilité est précieuse pour les audits.

# Via JFrog CLI
jfrog rt build-collect-env myapp 42
jfrog rt docker-push artifactory.example.com/docker-local/myapp:42 docker-local \
  --build-name=myapp --build-number=42
jfrog rt build-publish myapp 42

Depuis Artifactory, vous pouvez voir exactement quel commit a produit quelle image et quels artefacts ont été utilisés.

Promotion de builds : staging → production

La promotion est le workflow recommandé pour valider un artefact avant production :

# Promouvoir du repo staging vers prod
jfrog rt build-promote myapp 42 \
  --source-repo=docker-staging \
  --target-repo=docker-prod \
  --status=Released \
  --comment="Validé en staging le 30/04/2026"

L’image est copiée (pas re-buildée) dans le repo de production. La promotion est traçée dans Artifactory avec la date, l’auteur et le commentaire.

Notre formation Artifactory couvre l’ensemble du cycle — dépôts, Build Info, promotion et scanning Xray — sur des environnements réels.