▲

Docker 시스템 상태: 전체 서비스 중단

 (dockerstatus.com)
1P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • Docker의 주요 서비스에서 광범위한 장애 발생
  • 문제 원인이 클라우드 서비스 제공업체 관련 이슈로 확인됨
  • SaaS 서비스 전반에 걸쳐 오류율이 관측되었음
  • 오류 복구가 진행되어 백로그 처리 및 모니터링 단계 진입
  • 최종적으로 문제 해결 및 정상화 선언됨

Docker 시스템 장애 개요

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, Docker Hardened Images 등 Docker의 다양한 서비스에서 광범위한 접근 및 사용 문제가 발생함

2025년 10월 20일 00:16 PDT / 07:16 UTC

[조사 중]
많은 제품 서비스 전반에 걸친 접속 및 사용 이슈 발생에 따른 원인 조사 시작

2025년 10월 20일 01:22 PDT / 08:22 UTC

[문제 식별]
클라우드 서비스 제공업체의 이슈로 인해 장애 원인 파악됨
서비스 제공업체 장애가 해결될 때를 대비해 자체 시스템 준비 및 모니터링 진행

2025년 10월 20일 02:43 PDT / 09:43 UTC

[모니터링]
SaaS 서비스 전체에서 오류율이 점차 회복되는 추세 확인
백로그 처리와 함께 지속적인 상태 모니터링 진행

2025년 10월 20일 03:05 PDT / 10:05 UTC

[해결]
본 장애가 공식적으로 해결됨
서비스 전체 정상화 확인

▲
GN⁺ 22시간전  [-]
Hacker News 의견
  • 안녕하세요, Docker의 Tushar임. 현재 AWS 이슈로 인해 발생한 Docker 서비스 중단에 대해 사과드림. 저희 팀은 AWS와 협력하여 서비스를 최대한 빨리 복구하기 위해 노력 중임. dockerstatus.com에서 지속적으로 업데이트 중임. Docker Hub와 서비스가 전 세계 수백만 개발자에게 얼마나 중요한지 잘 알고 있음. 빠른 복구를 위해 최선을 다할 것임. 이번 사태가 완전히 해결된 이후, 향후 대응 방안과 함께 자세한 포스트모템을 발표할 예정임
    • 나는 이번 장애가 연쇄적으로 발생한 원인이 된 DynamoDB가 혹시 Docker 이미지 형태로 Docker Hub에 호스팅되고 있다면 참 재밌을 것 같다는 생각을 하게 됨
  • AWS 장애의 결과임 참고 링크
    • "클라우드 서비스 공급자 중 한 곳에서 근본적인 문제를 발견했다"고 하는데, 요즘은 모두 여러 클라우드 사업자를 병행해 쓰지 않나? 왜 한 공급자 장애에 이렇게 영향 받는지 궁금함
  • 우리도 여러 public Docker 이미지를 의존하는데, 기본적으로 Docker가 docker.io를 사용해서 빌드가 깨졌음. 다행히 AWS에서 docker.io 미러 서비스를 제공해서,
    FROM public.ecr.aws/docker/library/{image_name}
    로 변경했더니 모두 정상적으로 빌드됨. 에러 로그에서는 인증 엔드포인트(https://auth.docker.io)에서
    "요청을 처리할 수 있는 서버 없음" 오류가 대부분이었음. AWS 미러로 전환 후 아무 문제 없이 빌드 성공함
    • Docker가 AWS 장애로 다운됐는데, AWS mirror 저장소는 멀쩡히 돌아가는 상황이 약간 아이러니함
    • docker.io는 레이트 리밋도 걸려 있어서 조직이 어느 정도 성장하면 빌드 실패가 자주 생기기 시작함. 참고로 또 다른 이미지 호스팅 서비스 quay.io(레드햇 소유)도 오늘 하루 종일 read-only 상태였음. 컨테이너 이미지 의존성이 있다면 무작정 남의 버스에 얹혀가는 대신, 제대로 된 호스팅 솔루션을 갖추는 게 좋음
    • public.ecr.aws도 오늘 AWS 장애 때문에 5XX 에러가 떠서 나한테는 실패함 참고 링크
    • 나는 이 방법이 잘 안됐지만, Google의 미러(mirror.gcr.io)를 써서 잘 동작했음.
      FROM {image_name}
      에서
      FROM mirror.gcr.io/{image_name}
      로만 바꾸면 됨. 도움이 되길 바람. 관련 가이드
    • 나는 대규모 빌드 시스템을 관리하는데, ECR에서 이미지 pull이 하루 종일 불안정했음
  • Nexus 등 자체 레지스트리를 운영하면서, 공통 베이스 이미지로 직접 컨테이너 이미지를 빌드하는 사람들이 오늘은 확실히 선택에 안도하지 않을까 생각함. 이런 장애가 얼마나 많은 빌드나 재배포를 망칠지 궁금함. Docker나 Docker Hub에 반감은 없고, 나는 유용하게 잘 쓰고 있음
    • 도커 이미지 캐시를 중간에 두는 건 진짜 중요한 습관임. docker에서 upstream 이미지를 갑자기 내리면, K8s 노드가 교체될 때 베이스 이미지를 못 찾아서 서비스 구동이 어려워짐. 그냥 엔지니어링의 청결함이라 생각함
    • 우리도 베이스 이미지를 쓰긴 하지만, GitHub Actions이 준비 단계에서 docker 이미지를 가져가는 부분이 있어서 어플리케이션 빌드는 돼도 배포가 안 됨. CI/CD가 dockerhub에 의존하고, 어떤 이미지들은 pull-through cache로 경로를 바꿀 수가 없어 이렇게 됨
    • 우리는 Harbor를 운영하며 Proxy Cache로 모든 베이스 이미지를 미러링하고 있고, 이 구성을 몇 년째 잘 쓰고 있음. Harbor도 약간의 단점은 있지만 전체적으로 꽤 만족함
    • 컨테이너 자체를 아예 사용하지 않아서 더욱 안심되는 순간임
    • 수동 워크어라운드 없이 dev나 prod 환경에서 새로운 작업을 할 수 없는 상황임. 파급력이 꽤 크다고 생각함. 참고로 Signal도 오늘 이슈가 있는 듯함
  • AWS 장애 소식보다, 이 장애가 더 HN 메인에 떠 있는 게 꽤 흥미로움
  • 쑥스러운 광고긴 하지만, Docker Hub에 의존성이 크다면 Kubernetes 클러스터에 Spegel 설치를 추천함
    • 정말로 완전 오픈소스라면 랜딩페이지에 더 명확히 표시해줬으면 함. 바로 설치하고 실험해볼 수 있다면 엔지니어로서 진짜 큰 차이임. 구매 프로세스 거치지 않아도 되기 때문임
    • kuik와의 차이점이 궁금함. Spegel은 내 홈랩에는 다소 과하지만, 회사 환경에는 좋은 업그레이드가 될 수 있을듯함. Kuik: 참고
    • Docker Hub 외에 더 많은 저장소를 미러링하는 대안들도 있음. 대부분 엔터프라이즈급 답답함이 있지만, 명시된 기능 그대로 잘 동작함. Artifactory, Nexus Repository, Cloudsmith, ProGet 등이 있음. 이들이 덕분에 여러 번 위기에서 벗어난 경험 있음
    • Spegel이 좋아 보이지만, 우리는 GKE를 써서 현재로선 약간 꼼수로만 동작하는 상태임. GKE에서 제대로 지원될 예정이 있는지 궁금함
  • 이건 일종의 의도된 설계임.
    docker는 프라이빗 레지스트리 설정 기능을 요청받았지만, 스스로를 위해 거부했음
    관련 stackoverflow
    레드햇은 docker와 호환 가능한 podman을 만들어 이 부분을 닫을 수 있게 했음
    /etc/config/docker:
    BLOCK_REGISTRY='--block-registry=all'
    ADD_REGISTRY='--add-registry=registry.access.redhat.com'
    • 나는 이 이야기는 너무 비약이라고 봄. 기본 레지스트리를 docker.io 대신 다른 데로 바꿀 수 있다 해도, 대부분의 사람들은 귀찮아서 안 했을 거라 생각함. 사실 이미지에 태그만 잘 달아도 된다 봄. 우리 회사에선 단 하나도 docker.io에서 이미지를 pull하지 않음. 이미지명 앞에 <company-repo>/ 붙이는데 2초 걸림
    • 나는 이런 '실수유도(footgun)'를 어느 정도 용인해도 괜찮다고 생각함. domain 포함된 이미지 태그의 표현력 덕에 생기는 오해보다는 이점이 더 크다고 느낌. 예를 들어, 팀의 문서에 명령어가 써 있는데 도커 설정이 오래되면, 실수로 글로벌 퍼블릭 레지스트리에서 pull할 수도 있음. 개인적으로 글로벌 레지스트리 자체를 없애고 명확하게 어디서 가져오는지 보이게 하는 게 낫다고 생각함(하지만 docker가 이걸 진지하게 고민하지는 않을 것 같음)
    • us-east-1 리전에 ECR을 프라이빗 레지스트리로 썼던 경우엔 이 방법이 소용없었음
  • Docker가 안 떠서 O'Reilly에도 로그인 못 하는데, 그래서 "Docker 다운이면 딴 거 배워야지" 하려던 게 이런 장애 때문인가 궁금해짐
    • 최근에 썼던 모든 패키지를 저장하는 pull-through proxy를 설치하면 됨
  • 비슷한 문제를 겪는 다른 이들에게 도움이 되었던 방법은 ghcr 사용이었음. 완전히 대체되는 건 아니지만
    예: docker pull ghcr.io/linuxcontainers/debian-slim:latest
    • 이 이미지는 1년 넘게 업데이트가 없었음 관련 링크. Google Container Registry에서 pull-through 미러를 제공하니, 그냥 mirror.gcr.io를 prefix로 붙이고 Docker Official Images의 경우 library를 사용자로 써서 예를 들면 mirror.gcr.io/library/redis를 사용하면 됨 redis 공식 페이지
  • 2025년 10월 20일 09:43 UTC 기준으로 점차 복구 중임. SaaS 서비스 전반에서 에러율이 내려가는 게 관찰되고 있음. 백로그를 처리하며 상황을 계속 모니터링 중임
답변달기