도커 허브(Docker Hub) 관련 이미지 몇 장 골랐어요. 블로그에 적절히 넣으면 이해에 도움이 될 거예요.
필요하시면 각 이미지에 맞는 캡션도 같이 만들어드릴게요.
도커 이미지는 로컬에서만 사용할 수도 있지만,
결국 배포를 하려면 이미지를 저장하고 불러올 수 있는 공간이 필요합니다.
그게 바로 Docker Registry(도커 레지스트리) 입니다.
가장 대표적인 게 Docker Hub, 그리고 조직에서는 GitHub Container Registry(GHCR),
또는 자체 구축한 Private Registry를 사용합니다.
도커 이미지를 올린다는 건 무슨 의미일까

처음 도커를 배울 땐 docker build까지만 해도 충분했는데,
프로젝트를 서버에 올리려다 보니 “이미지를 서버에 어떻게 옮기지?”가 문제였습니다.
처음엔 그냥 docker save로 tar 파일을 만들어서 scp로 옮겼는데,
배포가 반복될수록 이 방식은 너무 번거로웠습니다.

그때 알게 된 게 Docker Hub였습니다.
한 번 올려두면, 서버에서 docker pull만으로 바로 이미지를 가져올 수 있었죠.
Docker Hub에 이미지 올리기

가장 기본적인 흐름은 이렇습니다.
# 1. Docker Hub 로그인
docker login
# 2. 이미지에 태그 붙이기
docker tag myapp:latest mydockerid/myapp:1.0
# 3. 업로드
docker push mydockerid/myapp:1.0
이렇게 하면 Docker Hub 계정의 저장소에 이미지가 올라갑니다.
이후 서버에서 아래 한 줄만 입력하면 바로 실행할 수 있죠.
docker pull mydockerid/myapp:1.0
이 단계를 통해서 “로컬 개발 → 원격 서버 실행”의 흐름이 완성됩니다.
태그(tag)는 버전 관리의 핵심이다
이미지 이름 뒤의 :1.0, :latest 같은 부분이 바로 태그(tag) 입니다.
이 태그가 없으면 도커는 기본적으로 latest를 사용합니다.
하지만 실무에서는 latest만 쓰는 건 위험합니다.
예전에 latest를 쓰다가 서버에서 의도치 않게 새 버전이 배포되어 장애가 났던 적이 있거든요.
태그를 명시적으로 버전처럼 관리해야 배포 안정성을 확보할 수 있습니다.
예시:
mydockerid/myapp:1.0.0
mydockerid/myapp:1.0.1
mydockerid/myapp:dev
GitHub Container Registry (GHCR)
GitHub Actions를 사용한다면,
GHCR (GitHub Container Registry) 를 쓰는 게 훨씬 자연스럽습니다.
Docker Hub와 거의 동일하지만,
GitHub의 리포지토리와 직접 연결되어 있어서
커밋/PR 단위로 이미지를 자동 빌드하고 푸시할 수 있습니다.
GitHub Actions에서 예시를 보면 이렇습니다.
- name: Build and Push Docker image
uses: docker/build-push-action@v5
with:
push: true
tags: ghcr.io/username/myapp:latest
빌드가 완료되면, GitHub의 “Packages” 탭에
도커 이미지가 자동으로 저장됩니다.
서버에서는 다음 명령으로 불러올 수 있죠.
docker pull ghcr.io/username/myapp:latest
이 과정을 자동화하면,
CI/CD 파이프라인이 “이미지 생성 → 푸시 → 배포”까지 한 번에 처리합니다.
Private Registry (사설 레지스트리)
사내 프로젝트나 보안 이슈가 있는 환경에서는
공개 레지스트리 대신 Private Registry를 구축하기도 합니다.
직접 구축하는 명령은 아주 간단합니다.
docker run -d -p 5000:5000 --name registry registry:2
이제 이 서버는 자체적인 도커 저장소가 됩니다.
이미지를 업로드하려면 다음과 같이 주소를 붙입니다.
docker tag myapp localhost:5000/myapp
docker push localhost:5000/myapp
보통은 Nginx Reverse Proxy와 SSL을 함께 설정해서
사내 전용 레지스트리로 쓰게 됩니다.
실무에서 느꼈던 자동화의 중요성
이전 프로젝트에서 수동으로 도커 이미지를 빌드하고 배포하던 시절이 있었습니다.
하루에 세 번 빌드하고, docker push, docker pull을 반복했죠.
그러다 실수로 구버전 이미지를 덮어써서 서버 장애가 났습니다.
그 이후로 CI/CD 파이프라인을 구성하면서
GitHub Actions가 자동으로 빌드 후 docker push를 하도록 바꿨습니다.
배포 로그도 남고, 버전 태그도 자동으로 관리되니
사람이 개입할 일이 거의 없어졌습니다.
지금 정리하자면
도커 이미지를 공유하고 배포하기 위해서는
Registry라는 저장소 개념을 꼭 이해해야 합니다.
Docker Hub → 가장 간단하고 공개된 방식
GHCR → 깃허브 기반의 CI/CD 연동
Private Registry → 사내 환경용 커스텀 저장소
이 세 가지 중 하나만 제대로 다뤄도
“내 로컬에서만 도는 서비스”를 “어디서든 실행 가능한 서비스”로 바꿀 수 있습니다.
'docker' 카테고리의 다른 글
| Dockerfile 이해하기 — 이미지가 만들어지는 과정 (0) | 2025.11.12 |
|---|---|
| 도커로 무중단 배포(Blue-Green Deployment) 구현하기 (0) | 2025.11.12 |
| 도커와 CI/CD — 자동으로 빌드하고 배포하기 (0) | 2025.11.12 |
| 도커 이미지와 컨테이너의 관계 — 실행 구조를 제대로 이해하기 (0) | 2025.11.12 |
| 도커란 무엇인가 — 가상머신과의 차이 이해하기 (0) | 2025.11.12 |