Category
Preparing references and filters for this topic. 이 주제의 레퍼런스와 필터를 준비하고 있습니다.
Category Reference
컨테이너 개념, 이미지 빌드, buildx, 실행 흐름, 네트워크, Compose, secret과 운영 정책까지 Docker의 핵심 흐름을 카드형 레퍼런스로 정리합니다.
Search titles, summaries, tags, and subcategories.
Showing 27 cards.
Subcategory
3 cards
컨테이너가 무엇이고 Docker가 무엇을 자동화하는지, 개발 환경 일관성과 배포 재현성 관점에서 정리하는 입문 카드입니다.
# 이미지를 내려받아 컨테이너로 실행
docker run -d -p 8080:80 nginx:alpine
# 실행 중인 컨테이너 확인
docker ps
# 로그 확인
docker logs <container-id>Docker 입문에서 가장 자주 헷갈리는 이미지와 컨테이너의 차이를 정적 청사진과 실행 인스턴스 관점에서 정리합니다.
# 이미지 하나로 컨테이너 여러 개 실행
docker pull nginx:alpine
docker run -d --name web1 nginx:alpine
docker run -d --name web2 nginx:alpine
docker run -d --name web3 nginx:alpineDocker CLI가 데몬과 통신해 이미지, 컨테이너, 네트워크, 볼륨 같은 객체를 관리하는 구조를 정리합니다.
# CLI(클라이언트)가 데몬으로 명령을 전달하는 흐름
docker info # 데몬 상태 확인
docker ps # 컨테이너 객체 목록
docker images # 이미지 객체 목록
docker network ls # 네트워크 객체 목록
docker volume ls # 볼륨 객체 목록3 cards
이미지를 처음 실행할 때 가장 자주 쓰는 docker run 옵션을 중심으로 이름, 포트, 환경 변수, 삭제 흐름을 정리합니다.
docker run \
--name web \
-d \
-p 8080:80 \
-e NGINX_HOST=example.com \
--rm \
nginx:alpine컨테이너를 생성한 뒤 상태를 확인하고 시작, 중지, 삭제하는 기본 생명주기 명령을 정리합니다.
docker run --name web -d nginx:alpine # created → running
docker ps # 실행 중 확인
docker stop web # running → stopped
docker start web # stopped → running
docker rm web # 컨테이너 삭제컨테이너 실행 시 환경 변수를 넘기는 기본 방법과 `--env-file`의 역할을 정리합니다.
# .env 파일 예시
# DB_HOST=db
# DB_PORT=5432
# APP_ENV=production
docker run --env-file .env -e PORT=4000 my-app8 cards
FROM, WORKDIR, COPY, RUN, CMD 같은 핵심 지시어를 기준으로 Dockerfile이 이미지를 만드는 방식을 정리합니다.
FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
CMD ["npm", "start"]Docker 빌드 속도와 이미지 효율을 좌우하는 build context와 레이어 캐시의 동작 원리를 정리합니다.
FROM node:22-alpine
WORKDIR /app
# 의존성 파일만 먼저 복사 — 소스 변경이 캐시에 영향 없음
COPY package.json package-lock.json ./
RUN npm ci
# 소스 코드는 나중에 — 자주 바뀌는 파일을 뒤에 둔다
COPY . .
RUN npm run build이미지 이름과 태그가 버전 식별과 배포 경로를 결정한다는 점을 중심으로 build, tag, push 흐름을 정리합니다.
docker build -t myname/my-app:1.2.3 .
docker push myname/my-app:1.2.3빌드 도구와 런타임 이미지를 분리하는 multi-stage build의 핵심 목적과 패턴을 정리합니다.
FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html컨테이너 시작 명령을 구성할 때 `ENTRYPOINT`와 `CMD`가 각각 어떤 역할을 맡는지 정리합니다.
FROM python:3.12-slim
WORKDIR /app
COPY . .
ENTRYPOINT ["python", "-m", "http.server"]
CMD ["8000"]빌드 시점 변수 ARG와 런타임 환경 변수 ENV를 어떻게 구분해야 하는지 정리합니다.
ARG NODE_VERSION=22
FROM node:${NODE_VERSION}-alpine
ENV NODE_ENV=production
ENV PORT=3000이미지 빌드가 느리고 예상보다 무거워질 때 자주 원인이 되는 build context와 .dockerignore의 역할을 정리합니다.
# .dockerignore
node_modules
.git
dist
.env
*.log
coverage
.DS_Store한 아키텍처만이 아니라 amd64와 arm64 같은 여러 플랫폼용 이미지를 함께 빌드하고 배포할 때 쓰는 buildx의 기본 흐름을 정리합니다.
# buildx 빌더 생성 (처음 한 번)
docker buildx create --name mybuilder --use
# amd64와 arm64를 동시에 빌드해 레지스트리에 푸시
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t myorg/myapp:1.0.0 \
--push .3 cards
개발 편의성과 데이터 영속성 요구에 따라 bind mount와 volume 중 무엇을 고를지 판단하는 카드입니다.
# bind mount — 호스트 경로를 그대로 마운트
docker run -v "$(pwd)/src":/app/src node:22-alpine
# named volume — Docker가 관리하는 전용 저장소
docker run -v pgdata:/var/lib/postgresql/data postgres:16
# tmpfs — 메모리 기반 임시 저장소
docker run --tmpfs /tmp:rw,size=64m my-app호스트와 컨테이너 사이의 포트 연결, 그리고 컨테이너끼리의 통신에서 bridge 네트워크가 어떤 역할을 하는지 정리합니다.
docker run --name web -d -p 8080:80 nginx:alpine컨테이너끼리 이름으로 통신하려면 named network와 Docker의 서비스 발견 방식을 함께 이해해야 합니다.
docker network create appnet
docker run -d --name db --network appnet postgres:17
docker run -d --name api --network appnet my-api
# api 컨테이너 안에서 db라는 이름으로 postgres에 접근 가능4 cards
여러 docker run 명령을 흩어 놓는 대신 compose.yaml 하나로 앱, DB, 볼륨, 네트워크를 선언하는 기본 흐름을 정리합니다.
services:
app:
build: .
ports:
- "3000:3000"
depends_on:
- db
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: secret
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:Compose에서 서비스 시작 순서를 제어하되, 실행 순서와 준비 완료 상태는 다르다는 점을 healthcheck와 함께 정리합니다.
services:
web:
build: .
depends_on:
db:
condition: service_healthy
db:
image: postgres:16
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5환경별 차이를 Compose 파일 분리로 관리하는 기본 패턴을 정리합니다.
# -f로 파일을 명시하면 뒤에 오는 파일이 앞 설정을 덮어씀
docker compose -f compose.yaml -f compose.dev.yaml up -d
# 운영 환경
docker compose -f compose.yaml -f compose.prod.yaml up -d선택적 서비스 기동을 위한 Compose profiles 기능의 기본 목적과 사용 흐름을 정리합니다.
services:
app:
build: . # profile 없음 → 항상 실행
adminer:
image: adminer
profiles:
- debug # --profile debug 할 때만 실행
prometheus:
image: prom/prometheus
profiles:
- monitoring # --profile monitoring 할 때만 실행6 cards
실행 중인 컨테이너 내부를 확인하고, 셸에 들어가고, 설정과 포트 매핑을 읽는 기본 디버깅 흐름을 정리합니다.
docker logs --follow app
docker exec -it app sh
docker inspect app실험 후 남은 중지 컨테이너, dangling 이미지, 미사용 네트워크와 볼륨을 안전하게 정리하는 기본 카드를 정리합니다.
# 디스크 사용량 확인 후 정리
docker system df
docker system prune컨테이너가 호스트 자원을 무제한 쓰지 않도록 docker run 단계에서 메모리와 CPU 제한을 거는 기본 패턴을 정리합니다.
docker run --memory=512m --cpus=1.5 my-app:latest컨테이너 재시작 정책을 통해 장애 후 동작을 어느 수준까지 자동화할 수 있는지 정리합니다.
docker run -d --restart unless-stopped my-app컨테이너가 단순히 떠 있는 상태와 실제로 요청을 받을 준비가 된 상태가 왜 다른지, healthcheck를 어떤 기준으로 설계하는지 정리합니다.
HEALTHCHECK --interval=30s --timeout=3s --retries=3 --start-period=10s \
CMD curl -f http://localhost:3000/health || exit 1비밀번호와 API 키 같은 민감한 값을 이미지에 굳히지 않고 안전하게 전달하는 기본 원칙을 정리합니다.
# docker-compose.yml
services:
app:
image: my-app
secrets:
- db_password
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
file: ./secrets/db_password.txt