État de Docker : interruption de l’ensemble des services

 (dockerstatus.com)
2 points par GN⁺ 2025-10-22 | 1 commentaires | Partager sur WhatsApp
  • Les principaux services Docker ont connu une panne généralisée
  • La cause a été confirmée comme un problème lié au fournisseur de services cloud
  • Le taux d’erreur a été observé sur l’ensemble des services SaaS
  • La restauration a progressé avec l’entrée dans la phase de traitement du backlog et de surveillance
  • La résolution a finalement été annoncée et la normalisation confirmée

Vue d’ensemble de l’incident Docker

Des problèmes importants d’accès et d’utilisation ont été observés sur divers services de Docker, notamment Docker Hub Registry, Docker Authentication, Docker Hub Web Services, Docker Billing, Docker Hub Automated Builds, Docker Hub Security Scanning, Docker Scout, Docker Build Cloud, Testcontainers Cloud, Docker Cloud et Docker Hardened Images.

20 octobre 2025 00:16 PDT / 07:16 UTC

[En cours d'enquête]
Début de l'enquête sur la cause d'après les problèmes d'accès et d'utilisation survenant sur de nombreux services.

20 octobre 2025 01:22 PDT / 08:22 UTC

[Problème identifié]
La cause de l'incident a été identifiée comme un problème lié au fournisseur de services cloud.
La préparation des systèmes internes et la surveillance ont été lancées en attendant la résolution du problème côté fournisseur.

20 octobre 2025 02:43 PDT / 09:43 UTC

[Surveillance]
Une tendance de réduction progressive du taux d'erreur a été observée sur l'ensemble des services SaaS.
Le traitement du backlog et une surveillance continue de l'état ont été poursuivis.

20 octobre 2025 03:05 PDT / 10:05 UTC

[Résolu]
Cet incident a été officiellement résolu.
La normalisation de l'ensemble des services a été confirmée

À lire aussi

1 commentaires

 
GN⁺ 2025-10-22
Avis de Hacker News
  • Bonjour, je suis Tushar chez Docker. Je m’excuse pour l’interruption de service Docker provoquée par un incident AWS. Notre équipe travaille avec AWS pour rétablir le service aussi vite que possible, et nous faisons des mises à jour en continu sur dockerstatus.com. Nous savons à quel point Docker Hub et le service sont importants pour des millions de développeurs dans le monde entier. Nous ferons de notre mieux pour un rétablissement rapide. Une fois cette panne entièrement résolue, nous publierons un postmortem détaillé avec nos prochaines étapes.
    • Je me suis dit que ça serait intéressant si DynamoDB, qui semble être à l’origine de cette chaîne d’incidents, était hébergé sur Docker Hub sous forme d’image Docker.
  • Cet incident est la conséquence d’un incident AWS Lien de référence
    • On dit avoir découvert « un problème fondamental chez un fournisseur de services cloud », mais de nos jours la plupart utilisent plusieurs fournisseurs cloud, non ? Je me demande comment une panne d’un seul fournisseur peut avoir autant d’impact.
  • Nous dépendons aussi de plusieurs images Docker publiques. Par défaut, les builds cassaient parce que Docker utilisait docker.io. Heureusement, AWS propose un miroir docker.io ; en remplaçant par
    FROM public.ecr.aws/docker/library/{image_name}
    les builds sont tous passés correctement. Dans les logs d’erreur, la plupart provenaient de l’endpoint d’authentification (https://auth.docker.io) avec l’erreur « aucun serveur pour traiter la demande ». Après bascule vers le miroir AWS, les builds sont passés sans problème.
    • Docker étant down à cause de la panne AWS, il est un peu ironique que le dépôt miroir AWS soit resté opérationnel.
    • docker.io applique aussi un rate limit ; quand une organisation atteint une certaine taille, les builds commencent à échouer de plus en plus souvent. À noter qu’un autre service d’hébergement d’images, quay.io (propriété de Red Hat), est resté en lecture seule toute la journée. Si vous dépendez d’images conteneur, mieux vaut avoir une vraie solution d’hébergement plutôt que de monter simplement dans le bus des autres.
    • public.ecr.aws a aussi affiché des erreurs 5XX aujourd’hui à cause de la panne AWS, donc ça a échoué pour moi Lien de référence
    • Cette approche n’a pas bien fonctionné pour moi, mais le miroir de Google (mirror.gcr.io) a bien marché. Il suffit de remplacer
      FROM {image_name}
      par
      FROM mirror.gcr.io/{image_name}. J’espère que ça aide. Guide associé
    • Je gère un système de builds à grande échelle et le pull d’images depuis ECR a été instable toute la journée.
  • Nous exploitons un registre interne comme Nexus et construisons nos images de base conteneur en direct pour les images de base communes ; aujourd’hui, les personnes qui font ça doivent certainement se sentir plutôt rassurées. Je me demande combien de builds et de redeploiements cette panne a pu casser. Je n’ai rien contre Docker ou Docker Hub, je les utilise encore à mon avantage.
    • Mettre un cache d’images Docker en amont est une habitude vraiment importante. Si Docker retire une image upstream, lors du remplacement d’un nœud K8s, la base peut ne plus être trouvée, ce qui empêche le service de démarrer. C’est simplement une question de propreté d’ingénierie.
    • Nous utilisons des images de base, mais dans la phase de préparation de GitHub Actions on récupère les images Docker, donc même si le build d’application passe, le déploiement ne se fait pas. Le CI/CD dépend de dockerhub, et pour certaines images, on ne peut pas changer le chemin via un pull-through cache, ce qui explique ça.
    • Nous opérons Harbor et mirroirons toutes les images de base avec un Proxy Cache, et cette configuration fonctionne bien depuis plusieurs années. Harbor a quelques limites, mais globalement c’est plutôt satisfaisant.
    • C’est plutôt rassurant de ne pas utiliser de conteneur du tout.
    • Impossible de faire de nouveaux travaux en dev ou prod sans contournement manuel. Je pense que l’impact est assez important. Au passage, Signal semble aussi être concerné aujourd’hui.
  • C’est assez intéressant de voir cette panne sur la page principale de HN plus que la panne AWS.
  • Petite pub un peu gênante, mais si vous dépendez fortement de Docker Hub, je recommande d’installer Spegel sur votre cluster Kubernetes.
    • Si c’était vraiment open source, ce serait bien précisé clairement sur la landing page. Pouvoir installer et tester immédiatement fait une vraie différence pour un ingénieur, puisqu’on n’a pas à passer par un processus d’achat.
    • Je suis curieux de la différence avec kuik. Spegel est un peu trop pour mon homelab, mais pourrait être une bonne upgrade en entreprise. Kuik : Voir la ref
    • Il existe aussi des alternatives qui répliquent plus de dépôts que Docker Hub. La plupart ont un peu trop de contraintes enterprise, mais fonctionnent bien selon leurs fonctions annoncées. Artifactory, Nexus Repository, Cloudsmith, ProGet, etc. Ces outils nous ont aidés à sortir de plusieurs crises.
    • Spegel a l’air bien, mais nous utilisons GKE et, pour l’instant, il ne fonctionne que de façon un peu bricolée. Je me demande si un support nativement prévu sur GKE est prévu.
  • C’est une forme de conception intentionnelle.
    docker a reçu des demandes pour implémenter une configuration de registre privé, mais a refusé pour se protéger lui-même
    Référence stackoverflow
    Red Hat a créé podman, compatible avec docker, pour fermer ce cas de figure
    /etc/config/docker:
    BLOCK_REGISTRY='--block-registry=all'
    ADD_REGISTRY='--add-registry=registry.access.redhat.com'
    • Je pense que c’est une extrapolation trop large. Même si on peut changer le registre par défaut de docker.io pour un autre, la plupart des gens ne le feront pas, trop paresseux. En pratique, bien taguer les images suffit. Dans mon entreprise, on ne pull jamais d’image depuis docker.io. Ajouter <company-repo>/ devant le nom de l’image prend 2 secondes.
    • Je pense qu’on peut tolérer ce genre de « footgun ». Les avantages de la sémantique des tags incluant un domaine me semblent supérieurs aux ambiguïtés qu’ils peuvent créer. Par exemple, si une commande écrite dans un doc d’équipe est utilisée avec une vieille config Docker, il peut arriver de puller par erreur depuis un registre public global. Personnellement, je préfère supprimer complètement le registre global et rendre visible l’origine précise des images (mais je doute que Docker se penche sérieusement sur ce sujet).
    • Quand ECR était utilisé comme registre privé dans la région us-east-1, cette méthode n’était d’aucune utilité.
  • Docker ne marche pas, donc je n’arrive pas non plus à me connecter à O’Reilly, et je me suis dit : « si Docker tombe, autant apprendre autre chose » ; je me demande si cette panne est la cause.
    • Installer un proxy pull-through qui met en cache tous les paquets utilisés récemment.
  • La méthode qui a aidé d’autres personnes rencontrant des problèmes similaires a été d’utiliser ghcr. Ce n’est pas un remplacement complet, mais
    par exemple : docker pull ghcr.io/linuxcontainers/debian-slim:latest
    • Cette image n’a pas été mise à jour depuis plus d’un an Lien associé. Google Container Registry fournit un miroir pull-through, donc ajoutez simplement le préfixe mirror.gcr.io, et pour les Docker Official Images utilisez library comme nom d’utilisateur ; par exemple mirror.gcr.io/library/redis page officielle redis
    • Au 20 octobre 2025, 09:43 UTC, la restauration est en cours progressivement. On observe une baisse du taux d’erreur sur les services SaaS en général. Nous traitons le backlog et continuons à surveiller la situation.