[도커-3] 도커 이미지 관리: 도커 허브 사용법부터 도커 파일 최적화까지

도커 허브란 도커 이미지를 저장하고 공유하는 클라우드 저장소이다.
이 글을 포스팅하는 Github랑 비슷한 서비스라고 생각하면 된다.
도커 이미지 저장소는 Public과 Private로 나누어져 있으며 여러 클라우드 서비스 업체들이 따로 운영도 하고 있지만,
여기서는 Public이자 공식 저장소인 도커 허브만 다루도록 하겠다.

도커 허브

---

도커 허브를 이용하려면 일단 회원가입부터 진행해야 한다.
하단 링크를 접속하여 우측 상단의 Sign up 버튼을 눌러 회원가입을 진행하자.

• 도커 허브 공식 사이트

다음은 무료 플랜의 경우 제공되는 기능이다.

• Public 저장소 무제한
• Private 저장소 1개
• 자동 빌드 기능

이미 nayatrei가 있어서 nayatrei3으로 가입했다…

docker login -u [username] 명령어를 입력한 후 비밀번호를 입력하면 로그인이 성공되었다는 메세지가 출력된다.
깃허브 계정으로 가입하면 비밀번호 대신 토큰을 발급받아서 사용해야 한다.

이미지 태그

도커 허브 이용시 이미지 태그의 표준 구조에 맞춰야 사용하기에 좋다.

[레지스트리]/[네임스페이스]/[레포지토리]:[태그]
예시:
docker.io/nayatrei/nayatrei-app:v1.0
│         │        │            └── 태그 (버전)
│         │        └─────────────── 레포지토리
│         └──────────────────────── 네임스페이스
└────────────────────────────────── 레지스트리

구성 요소	필수/선택	값	설명
레지스트리	선택	서버의 주소	생략 시 자동으로 docker.io로 지정됨
네임스페이스	대부분 필수	개인/조직명	공식 이미지를 pull시엔 생략 개인 이미지를 push/pull시엔 필수
레포지토리	필수	이미지명	이미지의 주요 식별자
태그	선택적이지만 권장	버전명	태그를 생략하면 latest 태그가 자동으로 부여됨 하지만 명시하는 것이 버전 관리에 용이하므로 사용이 권장됨

태그 생성 방법

docker tag 로컬이미지명 username/업로드이미지명:버전

• 예시) docker tag docker-web-server:1.0 nayatrei3/nayatrei-app:v1.0

이미지 업로드

각 구문별 해석

• docker tag docker-web-server:1.0 nayatrei3/nayatrei-app:v1.0
  • 로컬 저장소 이미지의 docker-web-server:1.0를 nayatrei3/nayatrei-app:v1.0 태그로 생성한다.
• docker push nayatrei3/nayatrei-app:v1.0
  • 나의 도커 허브 공개저장소로 이미지를 올린다.

방금 올린 이미지를 웹 도커 허브 레포지토리에서 확인할 수 있다.

이미지 다운로드

>

기존 이미지를 삭제하고 레포지토리에서 pull 후 실행한 결과. 기존과 똑같은 상태인것을 확인할 수 있다.

각 구문별 해석

• docker pull nayatrei3/nayatrei-app:v1.0
  • 도커 허브 공개 저장소 nayatrei3에서 nayatrei-app:v1.0 이미지를 다운 받는다.
• docker run -d -p 80:80 nayatrei3/nayatrei-app:v1.0
  • nayatrei3/nayatrei-app:v1.0 이미지를 백그라운드에서 실행하여 컨테이너를 만든다.
  • 호스트 컴퓨터의 80번 포트를 컨테이너 내부의 80번 포트와 연결한다.

이미지 검색 방법

이미 만들어진 이미지가 그렇게 많다는데 그 정보를 어디서 얻어야 할까?
이미지 검색 방법에는 크게 두 가지가 있다.

도커 허브 웹사이트

첫 번째는 공식 도커 허브 웹사이트를 이용하는 방법이다.

• 도커 허브 저장소

이미지의 종류가 많고 다양한데 관리 주체별로 분류해보자면 세 종류로 분류할 수 있다.

종류	관리 주체	신뢰도	확인 방법 및 특징	예시 (저장소 이름)
공식 이미지	도커 팀 또는 신뢰 파트너	최상	Official 배지 확인. 가장 안전하고 검증된 베이스 이미지.	nginx, redis, python
검증된 게시자	도커 파트너십 상업용 공급업체	높음	Verified Publisher 배지 확인. 해당 업체의 공식 지원.	mongodb/mongodb, amazon/aws-cli
일반 사용자/커뮤니티	일반 도커 사용자	사용자 판단 필요	특별한 배지 없음. 이름에 슬래시( / )와 사용자 ID가 포함됨.	myusername/mywebserver, jbookes/centos7.8

터미널 명령어 이용

두 번째는 터미널에서 명령어를 이용하는 방법이다.

공식 이미지 뿐만 아니라, 내가 올린 이미지도 검색이 된다.

• 공식/파트너십 이미지 검색 방법
  • docker search [이미지명]
  • 예시) docker search nginx
• 일반 사용자/커뮤니티 이미지 검색 방법
  • docker search [사용자ID/이미지명]
  • 예시) docker search nayatrei3/nayatrei-app

도커 파일 최적화

---

도커 파일 최적화란 이미지의 크기를 줄이고 빌드 속도를 개선하여,
컨테이너화된 애플리케이션의 배포 효율성, 안정성, 비용성, 보안을 향상시키는 일련의 작업을 말한다.
이는 도커 파일에 작성된 명령을 전략적으로 구성하고 불필요한 요소를 제거하여
최종 이미지에 꼭 필요한 실행 환경만 포함되도록 만드는 것이 핵심이다.

일단 결과부터 확인해보자.

이미지 사이즈가 539MB > 206MB로 약 62% 정도 줄었다.

상당한 차이가 나는것을 확인할 수 있다.
dockerignore와 멀티 스테이지 빌드를 적용한 뒤 결과이다.

.dockerignore

도커도 깃처럼 특정 파일을 제외시키는 ignore 파일을 만들 수 있다.
빌드 속도 향상, 이미지 크기 감소, 보안 강화 등을 목적으로
도커 데몬으로 전송하는 특정 파일이나 디렉토리를 필터링 할 수 있는 기능이다.
사용 방법은 해당 서비스가 있는 디렉토리에서 .dockerignore 파일을 생성하고 양식에 따라 작성하면 된다.

__pycache__/
*.pyc
*.pyo
.git/
.vscode/
.idea/
.env
*.md
tests/

git과 사용 방법이 상당히 비슷하다.

멀티 스테이지 빌드

하나의 도커파일 내에서 여러 개의 FROM 구문을 사용하여 빌드 환경과 최종 실행 환경을 분리하고,
최종 이미지에는 실행에 필요한 최소한의 파일만 복사하여 이미지 크기를 줄이는 도커 최적화 기법이다.

멀티 스테이지 빌드는 일반적으로 두 단계 이상으로 구성된다.

첫 번째 스테이지(빌드 스테이지)

• 역할
  • 애플리케이션을 완성하는 데 필요한 모든 무거운 작업이 이루어지는 임시 환경
  • 소스 코드 컴파일, 의존성 패키지 설치 등
• 포함 요소
  • 컴파일러(GCC), SDK, 개발 라이브러리, 테스트 파일 등 크기가 큰 불필요한 파일들이 이 스테이지에 포함됨.
• 구문
  • FROM [베이스 이미지] AS [별칭] (AS builder와 같이 별칭을 붙여 다음 스테이지에서 참조할 수 있도록 함)

두 번째 스테이지(최종 실행 스테이지)

• 역할
  • 최종 이미지를 만드는 단계로, 실제로 애플리케이션을 구동하는 데 필요한 가장 가볍고 안전한 최소 환경을 정의함.
• 핵심 명령
  • 첫 번째 스테이지에서 생성된 최종 결과물(실행 파일, 컴파일된 코드, 설정 파일)만을 선택적으로 복사함.
  • COPY –from=[별칭] [소스 경로] [목적지 경로]
• 결과
  • 빌드 도구와 임시 파일들은 두 번째 스테이지에 포함되지 않고 자동으로 버려짐.

# ============================================
# 빌드 스테이지: gcc로 패키지 컴파일
# ============================================
FROM python:3.11-slim AS builder

WORKDIR /app

# 빌드 도구만 설치
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    gcc \
    libpq-dev \
    && rm -rf /var/lib/apt/lists/*

# Python 패키지 설치
COPY requirements.txt .
RUN pip install --user --no-cache-dir -r requirements.txt


# ============================================
# 실행 스테이지: 런타임만 포함
# ============================================
FROM python:3.11-slim

WORKDIR /app

# 런타임 라이브러리만 설치 (gcc 제외!)
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    libpq5 \
    && rm -rf /var/lib/apt/lists/*

# 빌드된 패키지만 복사
COPY --from=builder /root/.local /root/.local
ENV PATH=/root/.local/bin:$PATH

# 소스 코드 복사
COPY . .

EXPOSE 5000
CMD ["python", "app.py"]

두 번째 단계에서 빌드된 패키지만 복사함으로써 gcc와 같은 불필요한 빌드 도구는 최종 이미지에서 완전히 제거된다.

멀티 스테이지 빌드를 하여 얻는 이점은 다음과 같다.

• 이미지 크기 대폭 감소
  • 불필요한 빌드 환경 파일이 제거되어 이미지 크기가 줄어들어 배포 속도가 빨라짐.
• 보안 향상
  • 이미지에 컴파일러나 개발 도구가 포함되지 않아 해킹이나 불필요한 접근의 위험이 감소함.
• 도커 파일의 간결성
  • 빌드와 실행 과정이 하나의 파일 내에서 명확하게 분리되어 관리하기 쉬움.

재빌드 및 테스트

최적화를 진행하고 테스트까지 완료하는 영상이다.

이미지 사이즈는 대폭 줄었으나, 기존과 완전히 동일한 기능(웹페이지/DB콘솔 접근)을 가지고 있다.

각 구문별 해석

• docker rmi nayatrei-docker-compose-app:latest
  • 기존 이미지 삭제
• docker compose build --no-cache
  • 재빌드(캐시 없이)
• docker images
  • 이미지 사이즈 확인
• docker compose up -d
  • 컴포즈를 백그라운드에서 실행한다.
• docker-compose exec postgres psql -U user -d myapp
  • postgres 콘솔에 접속한다.

디렉토리 구조

nayatrei-docker-compose/
├── docker-compose.yml # 컴포즈 설정 파일
├── app/
│   ├── Dockerfile # Flask 앱 도커 파일(최적화 된 파일)
│   ├── Dockerfile.backup # 기존 파일
│   ├── .dockerignore # 도커 필터 파일
│   ├── requirements.txt # Python 패키지 목록
│   └── app.py # 앱 소스 코드
└── postgres/
    └── init.sql # postgres 처음 실행시 자동으로 실행되는 SQL 스크립트

기존 Dockerfile을 backup으로 바꾸고 최적화된 신규 Dockerfile 생성, .dockerignore파일 생성

최적화된 이미지 도커 허브 업로드

최적화를 진행하고 기능 정상 테스트까지 완료했으니 마지막으로 도커 허브에 업로드까지 하면 작업은 끝이다.

v2.0 태그로 업로드된 것을 도커 허브 웹에서 확인하였다.

다음 목표

이번엔 도커 파일 최적화와 도커 허브 활용을 정리하면서 이미지 관리의 기초를 다졌다.
이제 최적화된 이미지를 수동으로 빌드하고 푸시하는 단계를 넘어,
CI/CD 파이프라인을 구축하여 빌드부터 배포까지 자동화하는 다음 단계로 넘어가보자.