Docker hub pull limit이 발생했다면?
Docker Hub 에서 신나게 pull 받다가 limit 때문에 문제가 발생한 경우와, 이를 회피하는 방법에 대해서 작성해봤습니다.
Docker Hub Pull Limit
Docker를 사용하는 여러 이유가 있겠지만, 무엇보다도 Docker Hub에 있는 이미지들을 자유롭게 받아서 사용할 수 있다는 점이 큰 매력 중에 하나라고 생각합니다. 그래서 저도 public 이미지들을 자유롭게 받아서 사용하고 이를 운영하는 서버에도 적용해서 배포를 하고 있었습니다. 그러던 와중에 청천벽력같은 소식이 전해집니다.
Hello:
You are receiving this email because of a policy change to Docker products and services you use. On Monday, November 2, 2020 at 9am Pacific Standard Time, Docker will begin enforcing rate limits on container pulls for Anonymous and Free users. Anonymous (unauthenticated) users will be limited to 100 container image pulls every six hours, and Free (authenticated) users will be limited to 200 container image pulls every six hours, when enforcement is fully implemented. Docker Pro and Team subscribers can pull container images from Docker Hub without restriction, as long as the quantities are not excessive or abusive.
In addition, we are pausing enforcement of the changes to our image-retention policies until mid-2021, when we anticipate incorporating them into usage-based pricing. Two months ago, we announced an update to Docker image-retention policies. As originally stated, this change, which was set to take effect on November 1, 2020, would result in the deletion of images for free Docker account users after six months of inactivity. Today’s announcement means Docker will not enforce image expiration on November 1, 2020.
이메일을 통해서 받았었는데, 당시에는 사실 바빠서 그냥 읽지도 않고 넘겼었습니다. 그때는 도커도 자주 사용하지 않았기 때문에 별로 신경을 쓰지 않았던 것입니다. Docker Hub Pull Limit에 대해서는 여기서 자세히 알아볼 수 있습니다.
요약하자면, 정책이 변경되었고, 맘껏 쓰고 싶으면 돈내고 써라 입니다.
그리고 시간이 지나, 이 이메일을 메일함에 방치하고 있던 와중에, ECS와 Code Build를 통해서 배포를 하던 와중에 일이 발생하고야 말았습니다.
배포의 실패
저희 팀에서는 Airflow를 통해 특정 추천 서비스의 전처리와 학습을 진행하고, 이 내용을 바탕으로 개발서버에 먼저 배포를 한 뒤에 결과를 일부 확인하고 운영서버에 배포하는 작업을 수행하고 있습니다. 어느때와 같이 새로운 고객사에 대해 추천 서비스 DAG를 생성하고 DAG를 켜줬습니다. 별 다른 이상이 없어서 시계를 확인하고 마침 퇴근 시간이 되었길래 칼퇴!를 했습니다. 지하철을 타는 순간에 핸드폰에서 불안한 알람이 온 것을 느꼈고, 그 내용은 DAG가 실패했다는 것이었습니다.
그런데 이 DAG의 태스크는 왠만해서는 실패가 되지 않는 부분이었습니다. 학습된 내용을 도커 이미지에 작성하고 작성된 이미지를 그냥 빌드하는 것이었기 때문입니다. 찜찜해서 가는 내내 고민하다가, 다른 동료가 보내준 코드 빌드에서 에러 로그를 보자마자 스치듯 지나갔던 그 메일이 생각났습니다.
에러의 내용은 다음과 같았습니다. toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
돈을 내라는 것이었습니다.
하지만 저는 돈을 내기는 싫었고, 6시간을 기다려서 초기화 될때까지 기다려서 배포를 해볼까 했습니다. 하지만 고객사 추가가 잦아지거나 다른 이미지들을 pull해올 때 또 다시 문제가 발생할 수 있기에, 이를 한번 회피해야 겠다는 생각을 했습니다. 회피하는 방법은 생각보다 간단했습니다.
🤫 pull limit 제한 없이 쓰기
많은 회사들에서는 클라우드 기반에서 서비스를 운영하실 것이라고 생각합니다. 온프레미스에서 운영하실 수도 있으나, 저희는 클라우드 기반에서 운영하기에, 또 AWS를 사용하기에 이 환경에 국한한 문제 해결 방법을 소개해 드리겠습니다.
AWS에는 이미지를 관리할 수 있는 저장소가 따로 있습니다. ECR 이라고 불립니다. 이 ECR에 다양한 이미지들을 빌드해서 올려놓고, ECS에 있는 TASK들의 컨테이너가 띄워질 때, 이 이미지를 사용해서 올라오게 됩니다. ECS말고도 인스턴스에서 이미지들을 갖고와서 사용할 수도 있고, 또 다르게 다양하게 사용할 수 있을 것입니다.
그래서 다양하게 한 번 사용을 해봤습니다. 필요한 이미지를 받아서 빌드하고 이 이미지를 ECR에 올려놓고, 이 이미지를 받아서 한번 사용해보는 겁니다. 그렇게 되면 이 이미지 자체는 ECR에 존재하게 되어서, ECS에서 태스크를 띄우든, 다른 곳에서 사용하든 무제한으로 이 이미지를 사용할 수 있게 될 것입니다.
저희 쪽에서 특히 자주 사용하는 이미지는 바로, python 이미지였습니다. python:3.7-slim-buster 를 특히 자주 썼었던 것 같은데, 이 이미지를 구글에서 검색해서 원본 이미지를 pull 해왔습니다. 이미지는 이 곳에서 찾았습니다.
나와있는 대로
1 | $ docker pull python@sha256:88e9ed044abd15c15069477046e8c65fb7e97cebd7cf140e901ae35440bfc073 |
docker 명령어를 통해 필요한 이미지를 받아줍니다. 그리고 docker image ls를 하면?
amd64/python 3.7 7cb3330faa6c 8 days ago 903MB
이렇게 잘 있는 것을 확인했습니다.
그 다음 이미지 이름에 태그를 달아주고 어디로 보내줄 것인지를 정의해줬습니다.
1 | docker tag amd64/python:3.7 xxxxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/python37_slim_buster |
그런데 이때 중요한 것은, ECR의 레포지토리를 미리 만들어줘야 한다는 것입니다. 미리 만들어두지 않으면, 알아서 레포지토리를 만들지 못하기 때문에 에러가 나서 실망하게 됩니다. 한 번에 딲! 끝내고 싶다면 미리 만들어 두십시오.
태그를 해 준 다음에는 push를 해줍니다.
1 | docker push amd64/python:3.7 xxxxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/python37_slim_buster |
이렇게 Push까지 하게되면? 원하는 이미지를 ECR 레포지토리에서 확인할 수 있습니다.
이제 이렇게 만들어진 이미지의 URI를 복사해서 Dockerfile의 FROM에 집어넣어 주면? 이제 제한없이 배포를 마음껏 할 수 있게 됩니다!
Reference
Docker hub pull limit이 발생했다면?