잡학다식 개발일지

Container 가상화

1. Container 기술이란?

컨테이너란?

• 컨테이너는 앱을 실행하는 데 필요한 모든 것을 포함한 경량 가상화 환경.
  • 애플리케이션 코드, 라이브러리, 종속성 등을 포함.
  • 운영체제(OS) 커널을 공유하여 가볍고 빠르게 동작.
• Docker에서는 Dockerfile을 기반으로 컨테이너를 생성.

2. 컨테이너의 이점

3. 컨테이너의 주요 용도

4. 컨테이너 기술과 Docker의 관계

5. 부가적으로 알아야 할 정보

1. 컨테이너 vs 가상 머신(VM):
   • 컨테이너는 운영체제를 공유하며 경량화.
   • VM은 각기 다른 운영체제를 포함, 무겁고 시작 시간이 길음.
2. 컨테이너와 마이크로서비스:
   • 컨테이너는 마이크로서비스 아키텍처를 구현하기에 이상적.
   • 각 마이크로서비스를 독립적인 컨테이너로 관리 가능.
3. 컨테이너 오케스트레이션:
   • Kubernetes와 Docker Swarm 같은 도구를 사용해 다중 컨테이너를 관리.
   • 확장, 부하 분산, 장애 복구 등 자동화 가능.

6. 장단점

1. Docker Hub에 이미지 Push

Docker Registry 개념

• Registry: Docker 이미지 파일을 저장하고 관리하는 공간.
• Public Registry: 누구나 접근 가능 (예: Docker Hub).
• Private Registry: 특정 사용자나 그룹만 접근 가능.
• Docker Hub: Docker의 공식 Registry 플랫폼(hub.docker.com).

이미지 Push 작업 순서

1. Docker Hub 로그인
2. docker logout docker login
3. 이미지 태깅(Tagging)
   • Docker Hub 계정 이름을 이미지 이름 앞에 붙여 태그 생성:

     docker image tag <이미지>:<태그> <계정>/<이미지>:<태그>
     

     예:

     docker image tag nginx:latest nbcdocker0000/nginx-test:1.0
     

4. 이미지 Push예:
5. docker push nbcdocker0000/nginx-test:1.0
6. docker push <계정>/<이미지>:<태그>
7. Push된 이미지 Pull 및 실행
8. docker pull nbcdocker0000/nginx-test:1.0 docker run -d -p 8001:80 --name=nginx-test nbcdocker0000/nginx-test:1.0

2. Dockerfile 최적화

최적화 이유

• 빠른 빌드 속도: 빌드 시간을 줄여 작업 효율성 증가.
• 이미지 크기 감소: 작고 경량화된 이미지는 저장 공간 절약 및 빠른 전송 가능.
• 보안 강화: 불필요한 패키지 제거로 공격 표면 감소.
• 유지보수 용이: 잘 정리된 Dockerfile은 수정이 쉽고 오류 발생 가능성 감소.

3. Java 환경 Dockerfile 예제

Dockerfile (Multi-stage Build 사용)

# Build 단계
FROM gradle:8.5-jdk21-alpine AS builder
WORKDIR /app
COPY ./ ./  # 소스 복사
RUN gradle clean bootJar  # Gradle로 Spring Boot 애플리케이션 빌드

# Application 실행 단계
FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY --from=builder /app/build/libs/spring-boot-0.0.1-SNAPSHOT.jar .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "spring-boot-0.0.1-SNAPSHOT.jar"]

최적화 포인트

1. Alpine 이미지 사용:
   • 최소한의 라이브러리만 포함된 경량 이미지.
   • 보안 강화 및 이미지 크기 최소화.
2. Multi-stage Build:
   • 빌드와 실행 환경을 분리.
   • 최종 실행 컨테이너에는 불필요한 빌드 도구(예: Gradle)가 포함되지 않음.

4. Docker Image Push 및 최적화 요약

5. 부가적으로 알아야 할 정보

1. Docker Hub 사용 팁:
   • Public Repository는 무료, Private Repository는 제한 있음.
   • 팀 협업을 위해 Docker Organization 기능 활용 가능.
2. Multi-stage Build 장점:
   • 빌드 환경에서만 필요한 파일은 제외.
   • 실행 이미지를 작고 빠르게 유지.
3. 이미지 최적화 도구:
   • docker-slim: Docker 이미지를 자동으로 최적화.
   • Dive: 이미지 내부 구조를 분석하여 최적화 가능한 부분 확인.
4. 이미지 관리:
   • 필요하지 않은 이미지는 삭제하여 디스크 공간 확보:

     docker image prune
     

6. Docker Image Push 및 최적화의 장단점

Docker Network

• Docker 네트워크는 컨테이너 간 통신과 보안을 관리하는 도구입니다.
• 컨테이너가 서로 데이터를 주고받을 수 있도록 경로를 제공하며, 네트워크 격리를 통해 보안을 강화합니다.

실제 비즈니스 애플리케이션을 컨테이너화할 때, 여러 개의 컨테이너가 서로 협력해야 목표를 달성할 수 있어요. 그래서 각각의 컨테이너가 서로 소통할 수 있는 방법이 필요하죠. 이를 위해 컨테이너들 사이에서 데이터 패킷을 주고받을 수 있는 경로, 즉 네트워크를 설정해야 해요. 도커에서는 이런 네트워크를 쉽고 효율적으로 구축할 수 있도록 도와주는 간단한 네트워크 모델을 만들었어요. 이 모델을 컨테이너 네트워크 모델(CNM)이라고 부른답니다. 이 모델은 컨테이너 네트워크를 구현할 때 필요한 기본 요건들을 정해줘요.

2. Docker Network 개념

• 하나의 네트워크 샌드박스 안에는 여러 개의 엔드포인트가 있을 수 있어요. 즉, 하나의 샌드박스 안에 있는 컨테이너는 네트워크에 전혀 연결되지 않거나, 여러 네트워크에 동시에 연결될 수 있어요. 가령, 세 개의 샌드박스 중 하나는 엔드포인트를 통해 두 개의 네트워크에 동시에 연결된 상태일 수 있죠.

• 이 네트워크 모델은 꽤 범용적이에요. 개별 컨테이너가 네트워크에서 어디에서 작동하는지는 정하지 않아요. 모든 컨테이너가 한 호스트에서 실행될 수도 있고(로컬), 여러 호스트에 걸쳐 있을 수도 있어요(글로벌).

• 물론 CNM은 그냥 네트워크가 어떻게 작동하는지 설명하는 모델일 뿐이에요. 실제로 네트워크를 사용하려면 CNM을 구현해야 해요. 로컬이든 글로벌이든, CNM을 구현하는 여러 방법이 있답니다.

• 각 네트워크는 외부에서 오는 권한 없는 접근으로부터 리소스를 보호해서 더 많은 보안을 제공해요. 그래서 애플리케이션을 만들고 운영할 때 여러 네트워크를 사용하는 게 좋아요. 그리고 서로 꼭 통신해야 하는 서비스들만 같은 네트워크에 두는 거죠. 방금 본 예제에서는 웹 API가 데이터베이스와 직접 통신할 필요가 없으니까, 이 둘을 다른 네트워크에 두었어요. 이렇게 하면 만약 해커가 웹 API를 해킹해도, 제품 카탈로그 서비스를 먼저 해킹하지 않고서는 데이터베이스에 접근하기 어렵게 됩니다.

3. Docker Network 종류

4. 실제와 유사한 사례

예제: API, 카탈로그, 데이터베이스 서비스 네트워크

• 목표:
  • API는 카탈로그와 통신하지만, 데이터베이스와는 통신하지 않음.
  • 카탈로그는 두 네트워크 모두 연결.

구현 코드

# 네트워크 생성
docker network create --driver=bridge back
docker network create --driver=bridge front

# 컨테이너 생성 및 실행
docker run --name=webapi -itd --net=front ubuntu:14.04
docker run --name=catalog -itd --net=back ubuntu:14.04
docker run --name=database -itd --net=back ubuntu:14.04

# catalog 컨테이너를 front 네트워크에 추가 연결
docker network connect front catalog

# 각 컨테이너에서 네트워크 상태 확인
docker exec webapi route
docker exec catalog route
docker exec database route

# 네트워크 정보 확인
docker network inspect front
docker network inspect back

# 네트워크 통신 테스트
docker exec -it webapi bash
ping -c 1 catalog
ping -c 1 database  # 불가능
exit

docker exec -it catalog bash
ping -c 1 webapi
ping -c 1 database
exit

# 네트워크 및 컨테이너 정리
docker network disconnect front catalog
docker stop webapi catalog database
docker rm webapi catalog database
docker network rm back front

5. Docker Network 명령어

6. Docker Network 사용 이유

7. Docker Network의 장단점

8. 부가적으로 알아야 할 정보

1. Bridge와 Host 네트워크 차이:
   • 브리지 네트워크는 컨테이너 간 독립적 IP와 네트워크 격리 제공.
   • 호스트 네트워크는 컨테이너가 호스트의 네트워크를 직접 사용해 높은 성능 제공.
2. 오버레이 네트워크:
   • Swarm 클러스터에서 여러 호스트를 연결할 때 사용.
   • 분산 애플리케이션과 마이크로서비스 환경에서 필수적.
3. macvlan 네트워크:
   • 고유 IP 주소를 컨테이너에 직접 제공해 외부 네트워크와의 원활한 통신 가능.

# back, front 네트워크 생성
docker network create --driver=bridge back
docker network create --driver=bridge front

# 각 서비스를 생성 및 실행
docker run --name=webapi -itd --net=front ubuntu:14.04
docker run --name=catalog -itd --net=back ubuntu:14.04
docker run --name=database -itd --net=back ubuntu:14.04

# catalog 서비스는 기본 back 네트워크 뿐만 아니라 front 네트워크에도 연결
docker network connect front catalog

# webapi 의 라우팅 테이블
docker exec webapi route

# catalog 의 라우팅 테이블
docker exec catalog route

# database 의 라우팅 테이블
docker exec database route

docker network inspect front # webapi / catalog
docker network inspect back # catalog / database


docker exec -it webapi bash
# 머신 안에서
ping -c 1 catalog # 가능
ping -c 1 database # 연결 불가능
exit

# 
docker exec -it catalog bash
# 머신 안에서
ping -c 1 webapi
ping -c 1 database

# 리소스 정리
docker network disconnect front catalog

docker stop webapi catalog database

docker rm webapi catalog database

docker network rm back

docker network rm front

Docker Volume

• Docker Volume은 데이터를 저장하고 관리하는 Docker의 기본 메커니즘 중 하나입니다.
• 컨테이너와 독립적으로 데이터를 보존하며, 컨테이너 삭제 시에도 데이터가 유지됩니다.
• 여러 컨테이너에서 데이터를 안전하게 공유하거나 관리할 때 사용됩니다.

Volume 사용 이유

Docker Volume 유형

Docker Volume의 장단점

Docker Volume 명령어

Docker Compose에서 볼륨 설정

• Compose 파일에서 서비스별로 볼륨을 설정할 수 있습니다.

version: "3.8"
services:
  app:
    image: myapp:latest
    volumes:
      - my-volume:/data
volumes:
  my-volume:

부가적으로 알아야 할 정보

1. 볼륨 드라이버:
   • 기본적으로 Docker의 local 드라이버 사용.
   • NFS, AWS EBS 등 외부 저장소와 통합하려면 특정 볼륨 드라이버 설정 필요.
2. Bind Mount와 비교:
   • Bind Mount는 호스트 경로를 직접 사용하므로 관리가 어렵지만, 특정 파일을 사용할 때 유용.
   • Volume은 Docker에서 관리하며, 안정성과 유연성이 뛰어남.
3. 볼륨 보안:
   • 기본적으로 볼륨 데이터는 암호화되지 않음. 민감한 데이터는 추가적인 보안 설정 필요.
4. 성능 최적화:
   • 데이터가 많거나 빈번히 접근하는 경우, 볼륨을 사용하는 것이 더 효율적.

8. 사용 사례

• 데이터베이스 컨테이너:
  • 데이터를 영구적으로 저장하기 위해 볼륨 사용.
• 여러 컨테이너가 동일한 데이터 공유:
  • 웹 서버와 애플리케이션 컨테이너가 동일한 볼륨 사용.
• 백업 및 복구:
  • 중요한 데이터를 볼륨에 저장하여 백업 및 복구 작업 간소화.

Docker Volume 실습

1. 데이터 영속성 실습

예제 코드

# 1. 볼륨 생성
docker volume create datavol

# 2. 볼륨 리스트 확인
docker volume ls

# 3. Alpine 컨테이너에서 볼륨 사용
docker container run -ti --rm -v datavol:/data alpine

# 4. 컨테이너 내부에서 파일 생성
echo "볼륨 데모" > /data/demo.txt
exit

# 5. 볼륨 데이터 확인
docker container run --rm -v datavol:/data ubuntu cat /data/demo.txt

# 6. 호스트 머신에서 디렉토리 구조 확인
sudo apt update; sudo apt install -y tree
sudo tree -a /var/lib/docker/volumes/datavol

볼륨 정보 확인

docker volume inspect datavol

2. 암시적 볼륨 마운트 실습

예제 코드

# 1. MySQL 컨테이너 실행
docker run -d --name mysqltest -v /var/lib/mysql mysql:latest

# 2. 컨테이너 정보 확인
docker inspect mysqltest | jq .[].Mounts

# 3. 볼륨 리스트 확인
docker volume ls

3. Bind Mount 실습

디렉토리 마운트

# 1. 호스트 머신에서 디렉토리 생성
cd ~
mkdir test-app
cd test-app
touch run.sh
chmod +x ./run.sh

# 2. Bind Mount 컨테이너 실행
docker run -ti --rm -v .:/app alpine

# 3. 컨테이너 내부에서 파일 확인
cd /app
ls -ahlvF

Read-Only 및 Read-Write 마운트

# 1. Read-Only 및 Read-Write 디렉토리 생성
mkdir ~/readonly
mkdir ~/readwrite

# 2. 컨테이너 실행
docker run -ti \
-v ~/readonly:/readonly:ro \
-v ~/readwrite:/readwrite:rw \
ubuntu

# 3. 컨테이너 내부에서 파일 쓰기 테스트
echo "test" > /readonly/readonly.txt  # 파일 쓰기 불가
echo "test" > /readwrite/readwrite.txt  # 파일 쓰기 가능
exit

# 4. 호스트 머신에서 파일 확인
cat ~/readwrite/readwrite.txt

4. MySQL 데이터 보존 실습

MySQL 컨테이너 실행

docker run -ti --rm -d \
--name mysqltest \
-e MYSQL_ROOT_PASSWORD=123! \
-e MYSQL_DATABASE=mysqltest \
-v ~/mysqldata:/var/lib/mysql \
mysql:latest

MySQL 서버 접속 및 데이터 입력

# 1. 컨테이너 내부에서 MySQL 접속
docker exec -ti mysqltest /bin/bash
mysql -h localhost -u root -p

# 2. MySQL 명령 실행
show databases;
use mysqltest;
create table mysqltest(id int, name varchar(50));
insert into mysqltest values(1, 'testname');
select * from mysqltest;

# 3. 데이터 확인 후 종료
exit

데이터 파일 확인

# 1. 컨테이너 내부 데이터 확인
ls -ahlvF /var/lib/mysql/mysqltest

# 2. 호스트 머신에서 데이터 확인
ls -ahlvF ~/mysqldata/mysqltest

다른 컨테이너에서 동일 데이터 사용

# 1. 기존 컨테이너 중지
docker stop mysqltest

# 2. 새 컨테이너 실행
docker run -ti --rm -d \
--name mysqltest2 \
-e MYSQL_ROOT_PASSWORD=123! \
-e MYSQL_DATABASE=mysqltest \
-v ~/mysqldata:/var/lib/mysql \
mysql:latest

# 3. 새 컨테이너에서 데이터 확인
docker exec -ti mysqltest2 /bin/sh
mysql -h localhost -u root -p
use mysqltest;
select * from mysqltest;

환경 변수 확인

• MySQL 이미지 관련 환경 변수는 MySQL Docker Hub 페이지에서 확인 가능.

5. 실습 요약

부가적으로 알아야 할 정보

1. docker volume 명령어:
   • docker volume create <이름>: 새 볼륨 생성.
   • docker volume ls: 볼륨 목록 표시.
   • docker volume inspect <이름>: 볼륨 세부 정보 확인.
   • docker volume rm <이름>: 특정 볼륨 삭제.
2. MySQL 환경 변수:
   • MySQL 컨테이너 실행 시 사용할 수 있는 환경 변수는 Docker Hub의 공식 문서를 참고.
3. Bind Mount와 Volume 차이:
   • Bind Mount는 호스트 경로를 직접 연결, 파일 동기화에 적합.
   • Volume은 Docker에서 관리, 데이터 영속성 및 백업에 적합.

Docker 모니터링

📌  컨테이너 모니터링은 실행 중인 컨테이너의 성능, 자원 사용량(CPU, 메모리, 네트워크 등)을 실시간으로 관찰하고 관리하는 과정입니다. 이를 통해 컨테이너의 상태를 확인하고, 문제가 발생했을 때 신속히 대응할 수 있습니다.

Docker 모니터링을 사용하는 이유

주요 Docker 모니터링 도구 및 명령어

Docker 기본 모니터링 명령어

1. docker stats

• 기능: 실행 중인 모든 컨테이너의 자원 사용량을 실시간으로 표시.
• 주요 정보:
  • CPU 사용량(%)
  • 메모리 사용량(MB, %)
  • 네트워크 I/O
  • 블록 I/O
• 사용법:

  docker stats
  

  특정 컨테이너를 모니터링하려면 이름 또는 ID 추가:

  docker stats [컨테이너 이름 또는 ID]
  

2. htop

• 기능: 리눅스 시스템 전체 자원 및 프로세스를 실시간으로 모니터링.
• 설치 및 실행:

  docker run --name test-tools -ti -d ubuntu:22.04
  docker exec -ti test-tools /bin/bash
  apt update && apt install htop -y
  htop
  

• 특징:
  • CPU, 메모리, 스왑 사용량 그래픽 표시.
  • 실행 중인 프로세스 관리(종료, 우선순위 변경 등).
  • 실시간 모니터

외부 모니터링 도구 (추천)

Docker 로깅

📌 로깅(Loggin)은 컨테이너 실행 과정에서 발생하는 이벤트나 메시지를 기록하는 것.

• Docker는 모든 컨테이너 로그의 표준 출력(stdout) 또는 표준 에러(stderr)를 캡처하여 json-file 로깅 드라이버를 사용하여 json 형식으로 파일에 기록합니다

• 목적:
  • 에러 및 문제 원인을 파악.
  • 컨테이너의 상태 및 동작을 추적.

Docker 로깅 명령어

• 로그 확인:

  docker logs [컨테이너 이름 또는 ID]
  

• 실시간 로그 확인:

  docker logs -f [컨테이너 이름 또는 ID]
  

  • -f: 실시간 로그 스트림.

Docker 모니터링과 로깅의 장단점

추가 팁 및 알아야 할 정보

1. 모니터링과 로깅은 함께 사용:
   • 모니터링은 현재 상태를 추적, 로깅은 과거 기록을 분석.
   • 둘을 함께 사용하면 문제 원인 파악과 예방이 더욱 효과적.
2. 외부 도구 도입:
   • Docker 기본 도구로는 대규모 환경에서 한계가 있음.
   • Prometheus + Grafana 같은 툴로 시각화와 자동 알림 설정.
3. 자원 제한 설정:
   • 컨테이너가 과도한 자원을 사용하는 것을 방지하려면 자원 제한 설정을 활용: 
   • docker run --memory="512m" --cpus="1.0" [이미지 이름]

Docker 로깅 실

로그 파일의 기본 위치

• 로그 파일은 컨테이너별로 저장되며, 기본적으로 다음 위치에 저장됩니다:

  /var/lib/docker/containers/<컨테이너_ID>/<컨테이너_ID>-json.log
  

Docker 로깅 명령어

1. 특정 컨테이너의 로그 보기

# 컨테이너 실행 (로그 생성)
docker run --name logs-test --rm -d ubuntu:22.04 /bin/bash -c 'while true; do date; sleep 1; done'

# 전체 로그 출력
docker logs logs-test

# 실시간 로그 보기
docker logs -f logs-test

# 마지막 10줄부터 로그 보기
docker logs -f --tail 10 logs-test

2. 로그 파일 경로 확인

docker inspect logs-test --format "{{.LogPath}}"

• 위 명령어는 컨테이너의 로그 파일 경로를 출력합니다.

로그 파일 로테이션 설정

운영 환경에서는 로그 파일 크기를 제한하고, 오래된 로그를 제거하거나 순환(로테이션)하도록 설정해야 합니다.

1. 컨테이너별 로깅 드라이버 구성

• 로그 파일의 최대 크기와 파일 개수 지정.

docker run -d \
--log-driver json-file \
--log-opt max-size=10m \  # 로그 파일 최대 크기 (10MB)
--log-opt max-file=10 \   # 최대 로그 파일 개수
--name nginxtest \
--restart always \
-p 80:80 \
-p 443:443 \
nginx:latest

2. nginx 컨테이너로 로깅 실습

1. 컨테이너 실행:
2. docker run -d \ --log-driver json-file \ --log-opt max-size=1m \ # 로그 파일 크기 제한 (1MB) --log-opt max-file=5 \ # 최대 파일 개수 (5개) --name nginxtest \ --restart always \ -p 80:80 \ -p 443:443 \ nginx:latest
3. 실시간 로그 확인:
4. docker logs -f nginxtest
5. 로그 파일 크기와 개수 제한 확인:
   • 제한된 크기의 로그 파일이 최대 5개까지 생성되고, 오래된 파일은 순환 방식으로 삭제.
6. 임의로 많은 로그 생성:
7. sudo apt update && sudo apt install -y wrk wrk -t10 -c100 -d30s http://localhost:80/

Docker Compose에서 로깅 설정

Docker Compose 파일에서 서비스별로 로깅 설정을 추가할 수 있습니다.

예제: Compose 파일에서 로그 파일 제한

services:
  app:
    image: myapp:latest
    ports:
      - "8080:8080"
    logging:
      driver: 'json-file'
      options:
        max-size: '10m'   # 로그 파일 최대 크기 10MB
        max-file: '10'    # 최대 10개의 로그 파일 유지

Docker 로깅 요약

로깅의 장단점

부가적으로 알아야 할 정보

1. 외부 로깅 도구 연동:
   • Docker는 Fluentd, syslog, Logstash와 같은 외부 로깅 도구를 지원.
   • 대규모 환경에서는 중앙 집중식 로그 관리가 필요.
2. 로깅 드라이버 변경:
   • 컨테이너 실행 시 --log-driver 옵션으로 다른 로깅 드라이버 설정 가능.
3. 기본 로그 관리 정책:
   • 컨테이너별로 설정이 가능하며, 환경에 따라 적절히 조정 필요.

Docker Compose란?

📌  Docker Compose는 여러 개의 Docker 컨테이너를 정의하고 관리하기 위한 도구입니다. 각 컨테이너를 하나의 설정 파일(docker-compose.yaml)에 정의하여, 개발, 테스트, 배포 환경에서 쉽게 관리할 수 있습니다.

Docker Compose를 사용하는 이유

1. 편리한 설정 관리:
   • 여러 컨테이너를 한 파일에 정의해 관리. 각 컨테이너의 이미지, 포트, 환경 변수 등을 설정.
2. 자동화된 배포:
   • 설정 파일 기반으로 docker compose up 명령만으로 여러 컨테이너를 자동으로 생성 및 실행.
3. 의존성 관리:
   • 컨테이너 간의 의존성을 정의하고, 필요한 순서에 따라 실행.
4. 유지보수 간편화:
   • 설정 파일 하나로 컨테이너를 관리, 수정 시 파일만 업데이트하면 반영.
5. 일관성 있는 환경 제공:
   • 개발, 테스트, 운영 환경에서 동일한 설정 파일을 사용하여 환경 차이 제거.
6. 보안 강화:
   • 네트워크를 격리하여 컨테이너 간 통신을 외부로부터 차단 가능.

Docker Compose 사용 환경

1. 개발 환경:
   • 애플리케이션과 의존 서비스(DB, Redis 등)를 쉽게 설정하고 실행.
   • 팀원이 동일한 환경에서 작업 가능.
2. 테스트 환경:
   • 자동화된 테스트 환경을 빠르게 생성 및 제거.
   • 예제:

     docker compose up -d
     ./run_tests
     docker compose down
     

3. 단일 호스트 배포:
   • 단일 서버에서 여러 컨테이너를 관리하고 실행.
   • 운영 환경에서도 간단한 애플리케이션 배포 가능.

Docker Compose의 특장점

Docker Compose 실행 방법

1. 각 애플리케이션의 Dockerfile 작성:
   • 애플리케이션 실행에 필요한 Dockerfile 작성.
   • 예: 웹 서버용 Dockerfile, 데이터베이스 컨테이너는 기본 이미지를 사용.
2. docker-compose.yaml 파일 작성:
   • 여러 컨테이너와 네트워크, 볼륨, 환경 변수를 정의.
   • 예:

     version: "3.8"
     services:
       web:
         build: .
         ports:
           - "5000:5000"
         volumes:
           - .:/code
       db:
         image: postgres
         environment:
           POSTGRES_USER: user
           POSTGRES_PASSWORD: password
     

3. Compose 명령 실행:
   • docker compose up: 컨테이너 실행.
   • docker compose down: 실행 중인 컨테이너 종료 및 네트워크 제거.

Docker Compose 명령어 요약

Docker Compose의 장단점

부가적으로 알아야 할 정보

1. YAML 파일 형식:
   • Docker Compose 설정은 YAML 형식으로 작성되며, 들여쓰기가 중요.
   • 버전에 따라 일부 기능의 지원 여부가 달라질 수 있음.
2. Compose 파일 버전:
   • version은 Compose 파일 형식의 버전을 지정.
   • 일반적으로 최신 버전(3.8)을 사용하는 것이 좋음.
3. Docker Compose와 Kubernetes:
   • Docker Compose는 단일 호스트에서 관리하기 적합.
   • Kubernetes는 다중 호스트와 복잡한 배포 환경에 적합.
4. 네트워크와 볼륨:
   • Compose 파일에서 네트워크와 볼륨을 정의해 데이터와 통신을 효율적으로 관리.

Docker Compose 파일 실전 예제

• ▶️ 실전에서 쓰이는 예제
  • ▶️ fastapi app
    • Dockrfile

FROM python:3.10

RUN pip install pipenv

WORKDIR /app

ADD . /app/

RUN pipenv --python 3.10
RUN pipenv run pip install poetry
RUN pipenv sync
RUN pipenv run pip install certifi


ARG STAGE

RUN sh -c 'echo "STAGE=$STAGE" > .env'
RUN sh -c 'echo "PYTHONPATH=." >> .env'
# ENV PYTHONPATH=/app
RUN chmod +x ./scripts/run.sh
RUN chmod +x ./scripts/run-worker.sh

# ENV PYTHONPATH=/app
CMD ["./scripts/run.sh"]

• docker-compoe.yaml

version: "3"
services:
  channel-api:
    image: xxxx.dkr.ecr.ap-northeast-2.amazonaws.com/reaction-channel:${AWS_ENV_STAGE:-dev}-${TAG:-latest}
    build:
      context: .
      dockerfile: dockerfile
      args:
        STAGE: ${STAGE:-develop}
    ports:
      - "8000:8000"
    environment:
      - NEW_RELIC_CONFIG_FILE=newrelic.ini
      - NEW_RELIC_ENVIRONMENT=ecs-${STAGE:-develop}
    logging:
      driver: awslogs
      options:
        awslogs-stream-prefix: channel
        awslogs-group: /ecs/reaction/${AWS_ENV_STAGE:-dev}/channel-api
        awslogs-region: ap-northeast-2

  reverseproxy:
    image: xxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/reverseproxy:prod-channel-latest
    ports:
    - "80:80"
    - "81:81"
    logging:
      driver: awslogs
      options:
        awslogs-stream-prefix: reverseproxy
        awslogs-group: /ecs/reaction/${AWS_ENV_STAGE:-dev}/reverseproxy
        awslogs-region: ap-northeast-2

• 실습: 개발환경에서 Docker Compose 사용하기
  • https://github.com/nbcdocker/spring-boot-sample
  • 해당 코드를 clone

cd ~
git clone https://github.com/nbcdocker/spring-boot-sample.git

• docker-compose 로 실행

cd ~/spring-boot-sample
docker-compose up -d
docker-compose logs -f

• mysql, redis 를 Docker Compose로 실행하여 코드에서 사용
  • redis: 26379
  • mysql: 23306
• redis 연결 테스트
  • http://localhost:8080/test-cache 에 redis 를 사용한 5초 단위 캐시 적용 확인

YAML file

📌YAML 파일은 컴퓨터가 읽을 수 있는 설정 파일이에요. 사람이 읽기에도 쉬운 텍스트 형식으로 되어 있죠. 'YAML Ain't Markup Language'의 줄임말이에요, 즉 'YAML은 마크업 언어가 아니다'라는 뜻이죠.

• 어떻게 생겼나요?
  • YAML 파일은 일반 텍스트로 쓰여 있어요. 설정이나 데이터를 쉽게 알아볼 수 있는 형식으로 나열해요. 예를 들어, 목록이나 키-값 쌍 같은 것들이죠.
• 왜 쓰나요?
  • YAML 파일은 설정을 정리하고 관리하기에 아주 좋아요. 예를 들어, Docker Compose에서는 YAML 파일을 사용해서 여러 컨테이너의 설정을 한 곳에 쉽게 정리할 수 있어요.
  • YAML은 읽기 쉽고, 쓰기도 간단해서 많은 프로그램과 도구에서 선호하는 설정 파일 형식이에요.
• 특징은?
  • YAML 파일은 구조가 명확하고 간단해서, 사람이 보기에도 이해하기 쉬워요. 들여쓰기를 사용해서 각 설정의 관계를 나타내죠.

YAML은 다음과 같은 문법을 사용해요

• 키-값 쌍: 키와 값으로 이루어진 쌍으로 구성됩니다. 키와 값은 콜론(:)으로 구분됩니다.
• 리스트: 쉼표(,)로 구분된 값들의 리스트로 구성됩니다.
• 딕셔너리: 중괄호({})로 둘러싸인 키-값 쌍의 리스트로 구성됩니다.
• 불린 값: true, false, yes, no 등의 값으로 표현됩니다.
• 문자열: 큰 따옴표("")나 작은 따옴표('')로 둘러싸인 문자열로 표현됩니다.

Dockerfile

📌 Dockerfile은 컴퓨터에서 돌아가는 앱을 만들기 위한 레시피라고 보면 된다. 이 레시피대로 하면 Docker 이미지라는 걸 만들 수 있다. Docker 이미지는 앱을 실행하는 데 필요한 모든 것을 담고 있다.

Dockerfile을 사용하는 이유

1. 환경 일관성

• 문제: 애플리케이션은 다양한 환경(OS, 라이브러리 버전, 설정)에 따라 다르게 동작할 수 있습니다.
• Dockerfile의 역할:
  • Dockerfile을 통해 운영체제, 소프트웨어 버전, 라이브러리 등을 명시적으로 정의.
  • 개발, 테스트, 운영 환경에서 동일한 컨테이너 이미지를 사용하므로 환경 차이로 인한 문제를 방지.
  • "개발 환경에서 잘 동작하는데 프로덕션에서는 오류가 발생하는 문제"를 해소.

2. 자동화된 이미지 생성

• 문제: 매번 애플리케이션을 설치하거나 빌드하는 과정을 수동으로 처리하면 시간이 낭비되고 오류가 발생할 수 있습니다.
• Dockerfile의 역할:
  • Dockerfile은 애플리케이션 빌드 및 설치 과정을 자동화.
  • docker build 명령어로 간단히 이미지를 생성할 수 있음.
  • 변경 사항이 생길 경우 Dockerfile만 업데이트하여 쉽게 새로운 이미지를 생성 가능.

3. 이식성(Portability)

• 문제: 다른 플랫폼(OS)에서 애플리케이션을 배포하려면 추가 설정과 조정이 필요할 수 있습니다.
• Dockerfile의 역할:
  • Docker 이미지는 한 번 생성하면 어떤 환경에서든 동일하게 동작.
  • 컨테이너를 실행할 수 있는 곳이라면(로컬, 클라우드, 서버 등) 어디서나 배포 가능.
  • 운영 환경에 상관없이 안정적인 배포 보장.

4. 확장성과 모듈화

• 문제: 복잡한 시스템은 여러 애플리케이션이나 서비스가 상호작용하며 구성됩니다.
• Dockerfile의 역할:
  • Dockerfile을 사용해 애플리케이션별 컨테이너를 생성하고, 이를 조합하여 마이크로서비스 아키텍처를 구현.
  • 각 서비스는 독립적으로 배포, 확장 가능.

5. 버전 관리 및 재현성

• 문제: 애플리케이션 업데이트나 변경이 과거 버전과 충돌하거나 재현이 어려울 수 있음.
• Dockerfile의 역할:
  • Dockerfile 자체를 소스 코드와 함께 버전 관리(Git 등)할 수 있음.
  • 특정 시점의 Dockerfile로 언제든지 동일한 이미지를 재생성 가능.

6. 배포 자동화(CI/CD와 통합)

• 문제: 애플리케이션 배포 과정을 수동으로 처리하면 효율성이 떨어지고 오류가 발생할 수 있음.
• Dockerfile의 역할:
  • CI/CD 파이프라인에서 Dockerfile을 사용해 자동으로 이미지를 생성하고 테스트, 배포 가능.
  • GitHub Actions, Jenkins, GitLab CI/CD 등과 쉽게 통합 가능.

7. 리소스 격리

• 문제: 하나의 서버에서 여러 애플리케이션을 실행하면 서로 충돌할 가능성이 있음.
• Dockerfile의 역할:
  • 컨테이너화된 애플리케이션은 호스트와 격리된 상태로 실행.
  • 리소스(CPU, 메모리, 네트워크)를 독립적으로 관리 가능.

8. 경량성

• 문제: VM(가상 머신)은 운영체제와 함께 많은 리소스를 소모.
• Dockerfile의 역할:
  • 컨테이너는 운영체제를 포함하지 않으므로 VM에 비해 가볍고 빠름.
  • Dockerfile로 필요한 최소 구성만 정의해 경량화된 이미지를 생성.

요약: Dockerfile 사용하는 이유

Dockerfile 사용법

Dockerfile 예제

# Dockerfile
FROM ubuntu:latest  # 베이스 이미지를 Ubuntu 최신 버전으로 설정
MAINTAINER Your Name <your-email@example.com>  # 이미지 제작자 정보

# 필요한 패키지 업데이트 및 Nginx 설치
RUN apt-get update && apt-get install -y nginx  

# index.html 파일을 Nginx의 기본 HTML 디렉토리로 복사
COPY index.html /usr/share/nginx/html  

# 컨테이너가 노출할 포트를 설정
EXPOSE 80  

# 컨테이너 실행 시 Nginx를 실행하고 데몬 모드를 비활성화
CMD ["nginx", "-g", "daemon off;"]  

Dockerfile 명령어 설명

Docker 이미지 생성 명령어

1. Docker 이미지를 생성하는 명령:

   docker buildx build -t my-nginx:latest .
   

   • -t: 이미지에 태그를 설정 (예: my-nginx:latest).
   • .: 현재 디렉토리에서 Dockerfile을 찾음.
   • buildx: 빌드 실행 도구. 일반적인 빌드 명령은 docker build를 사용.

Docker 컨테이너 실행 명령어

1. 컨테이너 실행 명령:

   docker run -d -p 80:80 my-nginx:latest
   

   • -d: 컨테이너를 백그라운드에서 실행.
   • -p 80:80: 호스트의 80번 포트를 컨테이너의 80번 포트에 매핑.
   • my-nginx:latest: 생성한 Docker 이미지를 기반으로 컨테이너 실행.

Docker 컨테이너 관리

1. 컨테이너 종료:
   • my-nginx: 실행 중인 컨테이너 이름 또는 ID.
2. docker stop my-nginx
3. 컨테이너 재시작:
4. docker start my-nginx
5. 실행 중인 컨테이너 확인:
6. docker ps
7. 중지된 컨테이너 포함 확인:
8. docker ps -a

Docker 이미지 공유

1. Docker 레지스트리:
   • Docker 이미지를 공유하고 저장하는 서비스.
   • 예: Docker Hub, AWS ECR, Google Container Registry 등.
2. 이미지 업로드 명령:
   • username/my-nginx:latest: Docker Hub에 업로드할 이미지 이름.
   • Docker Hub에 업로드하려면 먼저 docker login으로 인증 필요.
3. docker push username/my-nginx:latest
4. 이미지 다운로드 명령:
   • 공유된 이미지를 다른 사용자나 서버에서 다운로드하여 사용.
5. docker pull username/my-nginx:latest

정리된 작업 흐름

1. Dockerfile 작성:
   • 애플리케이션과 설정을 정의.
2. 이미지 생성:
   • docker build 명령으로 이미지를 생성.
3. 컨테이너 실행:
   • docker run 명령으로 컨테이너 실행.
4. 컨테이너 관리:
   • 컨테이너를 start, stop, restart 명령으로 제어.
5. 이미지 공유:
   • Docker Hub 등 레지스트리에 이미지를 업로드하여 협업 또는 배포.

Dockerfile 명령어

Dockerfile 예제 1: FastAPI 앱 실행

# Python 3.11 베이스 이미지 사용
FROM python:3.11

# pipenv 설치
RUN pip install pipenv

# 작업 디렉토리 설정
WORKDIR /app

# 로컬 파일을 컨테이너로 복사
ADD . /app/

# pipenv 환경 설정
RUN pipenv --python 3.11
RUN pipenv run pip install poetry
RUN pipenv sync
RUN pipenv run pip install certifi

# 빌드 시 입력 가능한 변수 설정
ARG STAGE
RUN sh -c 'echo "STAGE=$STAGE" > .env'
RUN sh -c 'echo "PYTHONPATH=." >> .env'

# 실행 스크립트에 실행 권한 부여
RUN chmod +x ./scripts/run.sh
RUN chmod +x ./scripts/run-worker.sh

# 컨테이너 시작 시 실행할 명령어 설정
CMD ["./scripts/run.sh"]

Dockerfile 예제 2: Nginx 웹 서버

Dockerfile

# Ubuntu 22.04 베이스 이미지 사용
FROM ubuntu:22.04

# 작성자 정보
MAINTAINER your-name <your-email@example.com>

# 이미지 메타데이터 추가
LABEL purpose=Web Server

# Nginx 설치
RUN apt-get update && apt-get install -y nginx

# Nginx 설정 파일 복사
COPY nginx.conf /etc/nginx/nginx.conf

# 컨테이너 실행 시 Nginx 시작
CMD ["nginx", "-g", "daemon off;"]

Nginx 설정 파일 (nginx.conf):

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  65;

    gzip  on;
    gzip_disable "msie6";

    include /etc/nginx/conf.d/*.conf;
}

GitHub Actions

📌 GitHub Actions는 GitHub에 내장된 CI/CD 도구로, 소스 코드 저장소 내에서 코드 테스트, 빌드, 배포 등의 작업을 자동화합니다. GitHub Actions는 별도의 CI/CD 서버 구축 없이 GitHub와 쉽게 통합되며, 사용자가 YAML 형식의 워크플로 파일을 통해 간단하게 자동화 작업을 설정할 수 있습니다.

주요 특징

1. GitHub 통합: GitHub와 완벽히 통합되어, 저장소 내 이벤트(push, pull request 등)를 기반으로 자동화 실행.
2. 서버리스: CI/CD 서버를 별도로 운영할 필요 없이 GitHub에서 바로 실행.
3. 무료 제공 범위:
   • 스토리지: 500MB
   • 실행 시간: 월 2,000분 (무료 사용자 기준)
4. YAML 기반 설정:
   • 워크플로는 반드시 .github/workflows 디렉토리에 저장.
   • YAML 파일을 작성해 자동화 작업 정의.

GitHub Actions의 CI (Continuous Integration)

개념

• CI in GitHub Actions:
  • 코드 병합 시 자동 테스트 및 빌드를 실행.
  • 테스트 통과된 코드만 develop, main 브랜치로 병합되도록 설정.
  • 코드 품질 유지 및 안정적인 배포 보장.

활용 예시

1. develop 브랜치에 병합 시:
   • gradle test 실행.
2. feature/* 브랜치에 push 시:
   • 테스트 실행 후 알림(Slack, 이메일 등) 전송.

샘플 CI 워크플로

# 워크플로 이름을 설정 (GitHub Actions UI에서 표시됨)
name: CI

# 워크플로가 트리거되는 조건 정의
on:
  push: # push 이벤트 발생 시 실행
    branches: 
      - develop # develop 브랜치에 push되었을 때 실행
      - feature/** # feature 하위 브랜치에 push되었을 때 실행

# 작업(Job) 정의 시작
jobs:
  ci: # Job의 이름 정의
    runs-on: ubuntu-latest # 실행 환경으로 최신 버전의 Ubuntu를 사용

    # Job에서 실행할 작업 단계 정의
    steps:
      # 1. 리포지토리 코드를 체크아웃 (clone)
      - name: Checkout repository # 단계 이름
        uses: actions/checkout@v4 # GitHub Actions의 공식 체크아웃 액션 사용

      # 2. Java 환경 설정
      - name: Setup Java # 단계 이름
        uses: actions/setup-java@v3 # Java 설정을 위한 액션 사용
        with:
          java-version: '17' # Java의 버전을 17로 설정

      # 3. Gradle을 사용해 테스트 실행
      - name: Run Gradle tests # 단계 이름
        run: ./gradlew clean test # Gradle 명령어를 실행하여 테스트 수행

GitHub Actions의 CD (Continuous Deployment)

개념

• CD in GitHub Actions:
  • main 브랜치에 병합된 코드를 자동으로 배포.
  • 배포 작업에 필요한 빌드, 테스트, 배포 프로세스를 YAML로 정의.

활용 예시

1. main 브랜치에 병합 시:
   • 테스트 실행 후 JAR 파일 생성.
   • 생성된 JAR 파일을 AWS, GCP, Heroku 등으로 배포.

샘플 CD 워크플로

# 워크플로 이름을 설정
name: CD

# 워크플로 트리거 조건 설정
on:
  push: # push 이벤트 발생 시 실행
    branches: [ main ] # main 브랜치에 push되었을 때만 실행

# 작업(Job) 정의 시작
jobs:
  cd: # Job의 이름 정의
    runs-on: ubuntu-latest # 실행 환경으로 최신 버전의 Ubuntu를 사용

    # Job에서 실행할 작업 단계 정의
    steps:
      # 1. 리포지토리 코드 체크아웃
      - name: Checkout repository # 단계 이름
        uses: actions/checkout@v4 # GitHub Actions의 공식 체크아웃 액션 사용

      # 2. Java 환경 설정
      - name: Setup Java # 단계 이름
        uses: actions/setup-java@v3 # Java 설정을 위한 액션 사용
        with:
          java-version: '17' # Java의 버전을 17로 설정

      # 3. Gradle 테스트 실행
      - name: Run Gradle tests # 단계 이름
        run: ./gradlew clean test # Gradle 명령어를 실행하여 테스트 수행

      # 4. Heroku에 배포
      - name: Deploy to Heroku # 단계 이름
        uses: akhileshns/heroku-deploy@v3.12.12 # Heroku 배포를 위한 액션 사용
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}} # Heroku API 키를 GitHub Secrets에서 가져옴
          heroku_app_name: "sampleapp-github-actions" # Heroku 앱 이름 (고유해야 함)
          heroku_email: "user@example.com" # Heroku 계정 이메일

GitHub Actions의 장단점

GitHub Actions의 사용 이유

1. 빠르고 간단한 설정: .github/workflows에 YAML 파일을 작성해 바로 사용 가능.
2. GitHub와의 높은 호환성: Pull request, Push 등 GitHub 이벤트와 밀접하게 연동.
3. 비용 절감: 무료 플랜으로 소규모 프로젝트에서 부담 없이 사용 가능.
4. 강력한 커뮤니티와 확장성:
   • GitHub Marketplace에서 다양한 Actions 활용 가능.
   • DevOps 문화에 적합한 자동화 도구 제공.

정리

부가적으로 알아야 할 정보

1. GitHub Secrets:
   • API 키, 데이터베이스 비밀번호 등 민감한 정보를 안전하게 관리.
   • secrets.변수명으로 워크플로에서 참조 가능.
2. GitHub Marketplace:
   • 다양한 오픈소스 액션 제공(테스트, 배포, 코드 분석 등).
   • 사용자가 만든 커스텀 액션을 공유하거나 활용 가능.
3. 모니터링 및 디버깅:
   • GitHub Actions에서 제공하는 로그를 통해 워크플로 실행 과정을 모니터링 및 디버깅.

Github Actions 뜯어보기

• Workflow
  • 최상위 개념
  • 여러 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스
  • Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장됨
• event
  • Github Repository에서 발생하는 push, pull request open, issue open, 특정 시간대 반복(cron) 등의 특정한 규칙
  • workflow 를 실행(trigger)함
• runner
  • Github Action Runner app이 설치된 VM
  • Workflow가 실행될 instance로, 각각의 Job 들은 개별적인 runner에서 실행
• job
  • 하나의 runner에서 실행될 여러 step의 모음을 의미
• step
  • 실행 가능한 하나의 shell script 또는 action
• Actions
  • Workflow의 가장 작은 단위로 재사용이 가능
  • Job을 만들기 위해 Step들을 연결
• workflow 뜯어보기
  • name
    • github actions의 이름을 정하는 부분
  • on
    • 이 action이 언제 실행되는지에 대한 부분
  • jobs
    • 실제 실행할 내용에 대한 부분
      • runs-on: 어떤 환경에서 실행하는지 기술
        • https://docs.github.com/ko/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners
      • steps: 실제 실행할 단계들을 기술
        • name: 실행에 표시될 이름
        • uses: 여러 가지 plugin 사용
          • 다양한 action들을 사용 - https://github.com/marketplace?type=actions

• with: plugin 에서 사용할 파라미터들
• run: 실제로 실행할 스크립트

Github Actions 을 활용한 CI/CD 파이프라인 배포

• 전체 흐름
  • 개발자는 feature/ 로 시작하는 브랜치를 만들어서 test코드를 포함한 수정 작업을 완료한 뒤 Pull Request 생성
  • (자동화) Pull Request를 만들면 해당 브랜치에 대해 gradle test를 수행
  • Pull Request 코드의 test가 실패한 경우, Pull Request 를 생성한 개발자는 test 코드를 수정하여 Pull Request를 변경
  • Pull Request 코드의 test가 성공한 경우, 다른 개발자들의 승인을 기다림
  • 다른 개발자들은 Pull Request의 코드를 승인하거나 댓글로 소통
  • (자동화) main 브랜치에 merge 되면 해당 브랜치를 cloudtype 서버에 배포

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

🧩 부모 타입 변수 = 자식 타입 객체; 는 자동으로 부모 타입으로 변환이 일어납니다.

소제목 

🎵 클래스가 설계도라면 추상 클래스는 미완성된 설계도입니다.

CI/CD

CI (Continuous Integration, 지속적 통합)

• 개발자가 코드 변경 사항을 공유 저장소에 자주 병합하며, 이를 통해 변경 사항이 팀 내에서 빠르게 통합될 수 있도록 지원.
• 핵심 구성 요소:
  • 자동화 빌드: 코드가 병합될 때마다 프로젝트가 자동으로 빌드됨.
  • 자동화 테스트: 빌드된 프로젝트에 대해 자동으로 테스트가 실행되어 오류나 결함을 조기에 발견.
  • 소스 코드 관리: GitHub, GitLab, Bitbucket 등의 저장소를 사용하여 팀원이 동일한 코드 베이스를 관리.

CD (Continuous Delivery/Deployment, 지속적 제공/배포)

• Continuous Delivery (지속적 제공):
  • 모든 코드 변경 사항이 프로덕션 환경에 배포 가능한 상태로 자동 준비.
  • 배포 전, 수동 승인 과정을 포함하여 프로덕션 환경에서의 안전성을 보장.
• Continuous Deployment (지속적 배포):
  • 코드 변경 사항이 자동으로 프로덕션 환경에 배포되며, 별도의 수동 승인 없이 진행.
  • 완전히 자동화된 배포 파이프라인을 통해 운영 비용을 절감.

CI/CD 주요 구성 요소

1. 소스 코드 관리(SCM): Git을 사용하여 코드 버전을 관리하고 팀 협업을 지원.
2. 빌드 자동화 도구: Jenkins, GitLab CI/CD, CircleCI, TravisCI 등.
3. 테스트 자동화: 다양한 테스트(단위 테스트, 통합 테스트, E2E 테스트)를 자동 실행.
4. 배포 자동화: Docker, Kubernetes와 같은 컨테이너 및 오케스트레이션 툴을 활용한 배포 관리.
5. 모니터링 및 피드백: Prometheus, Grafana, ELK 스택 등을 사용하여 문제를 조기에 탐지.

CI/CD의 상세 장단점

CI/CD 사용 이유

1. 품질 개선:
   • 코드 병합 시 자동으로 테스트를 수행해 결함을 사전에 발견.
   • 코드 리뷰 프로세스와 통합하여 개발 표준을 준수.
2. 효율성 증가:
   • 반복적이고 수동적인 작업을 자동화하여 개발자 생산성 향상.
   • 릴리스 주기를 단축해 시간 및 인력 비용 절감.
3. 리스크 감소:
   • 변경 사항이 점진적으로 배포되므로 대규모 릴리스로 인한 문제 발생 가능성 감소.
   • 롤백 자동화로 문제 발생 시 신속한 복구 가능.
4. 팀 협업 강화:
   • 병합 시 충돌을 최소화하고, 투명한 코드 공유를 통해 팀 간 협력 향상.
   • DevOps 문화를 활성화하여 개발과 운영의 경계를 허물음.

CI/CD 프로세스 상세 표

Docker+CI/CD

Docker와 CI/CD를 결합하면 개발, 테스트, 배포 프로세스를 표준화하고, 애플리케이션의 이식성과 안정성을 크게 향상할 수 있습니다. 

Docker와 CI/CD의 결합 개념

• Docker: 컨테이너화를 통해 애플리케이션과 모든 종속성을 하나의 이미지로 패키징. 어떤 환경에서도 동일하게 동작하도록 보장.
• CI/CD:
  • CI: Docker 이미지를 생성하고 테스트를 자동화.
  • CD: Docker 이미지를 사용해 스테이징 또는 프로덕션 환경에 배포.

Docker+CI/CD의 주요 장점

Docker와 CI/CD를 활용한 워크플로우

1. 코드 작성 및 변경: 개발자가 소스 코드를 작성하고 Git 저장소에 커밋.
2. Docker 이미지 생성:
   • CI 파이프라인에서 Dockerfile을 기반으로 이미지를 빌드.
   • 이미지에 필요한 애플리케이션 코드와 종속성을 포함.
3. 자동화 테스트:
   • Docker 컨테이너에서 테스트 스크립트를 실행하여 애플리케이션의 동작 검증.
4. 이미지 저장소 푸시:
   • 테스트를 통과한 Docker 이미지를 Docker Hub, AWS ECR, Azure ACR 등에 푸시.
5. 배포 자동화:
   • CD 파이프라인에서 저장소에 있는 이미지를 스테이징 또는 프로덕션 환경에 배포.
   • Kubernetes 등 오케스트레이션 도구를 활용해 배포 관리.
6. 모니터링 및 피드백:
   • 배포된 애플리케이션의 성능과 로그를 모니터링하고, 피드백 루프를 구축.

CI/CD 파이프라인에서 Docker 사용 사례

Docker와 CI/CD를 구현하는 도구

간단한 예: GitLab CI/CD + Docker

1. Dockerfile 작성

# 베이스 이미지 설정
FROM node:14

# 작업 디렉토리 설정
WORKDIR /app

# 패키지 파일 복사 및 설치
COPY package*.json ./
RUN npm install

# 애플리케이션 코드 복사
COPY . .

# 애플리케이션 실행
CMD ["npm", "start"]

2. GitLab CI/CD 설정 (.gitlab-ci.yml)

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t my-app .

test:
  stage: test
  image: docker:latest
  script:
    - docker run my-app npm test

deploy:
  stage: deploy
  image: docker:latest
  script:
    - docker tag my-app my-dockerhub-repo/my-app:latest
    - docker push my-dockerhub-repo/my-app:latest