딩코딩

단위 테스트와 통합 테스트, 언제 어떤 걸 써야 할까?

딩코딩 — Mon, 7 Apr 2025 14:45:03 +0900

단위 테스트와 통합 테스트, 언제 어떤 걸 써야 할까?

개발을 하다 보면 "테스트를 왜 해야 하지?", "어떤 테스트가 더 중요한가?" 같은 고민이 생긴다.
이번에 직접 테스트를 작성하면서, 단위 테스트와 통합 테스트에 대해 정리해봤다.

✅ 단위 테스트(Unit Test)란?

실제 데이터 없이, 로직 자체의 흐름과 메서드 호출 여부를 검증하는 테스트
주로 mock 객체를 사용하여 의존성 분리
빠르고, 내부 구현이 바뀌면 바로 확인 가능

예를 들어

특정 메서드가 호출되었는지
if/else 조건 분기가 잘 작동하는지
특정 입력에 대해 정확한 출력을 내는지

✅ 통합 테스트(Integration Test)란?

실제 데이터(DB 등)를 사용하여 기능이 전반적으로 잘 동작하는지를 검증
사람이 수동으로 하던 QA를 자동화한 느낌
예: 회원가입 → 로그인 → 글 작성 → 글 조회 흐름을 자동으로 테스트

✅ 두 테스트의 차이점

항목	단위 테스트	통합 테스트
속도	빠름	느림
데이터	mock (가짜)	실제 DB 사용
목적	로직 흐름 검증	전체 흐름 검증
디버깅	쉬움	어려움
테스트 대상	개별 클래스/함수	여러 컴포넌트 간 상호작용

이렇게 이해했다

단위 테스트는 로직을 안전하게 보호하는 테스트
통합 테스트는 사람이 직접 해보는 QA를 자동화
TDD는 핵심 로직이 바뀌지 않도록 테스트 먼저 작성 후 기능 구현
초기 개발 단계나 작은 프로젝트에서는 통합 테스트만으로도 현실적으로 충분할 수 있다

언제 어떤 테스트를?

상황	추천 테스트
복잡한 로직, 조건 분기 많음	단위 테스트
API 전체 흐름을 점검하고 싶음	통합 테스트
빠르게 MVP 개발 중	통합 테스트 중심
코드 리팩터링 전	단위 테스트 선 작성

✅ 결론

테스트는 모든 걸 다 해야 하는 게 아니라,
상황에 따라 전략적으로 선택하는 것이 중요하다.

작은 프로젝트는 통합 테스트 위주,
중대형 서비스에서는 단위 + 통합 + E2E까지 조화롭게 구성하는 게 이상적이다.

내 생각

단위 테스트는 내부 흐름과 조건 분기를 검증하고,
통합 테스트는 실제 데이터를 기반으로 한 자동화 QA이다.
결국 테스트는 신뢰성 + 유지보수성 + 개발 효율을 위한 투자다.

Kubernetes에서 MySQL과 연동하여 볼륨(Persistent Volume) 사용하기

딩코딩 — Thu, 6 Feb 2025 22:34:11 +0900

쿠버네티스(Kubernetes)에서 MySQL을 배포할 때, 데이터를 지속적으로 유지하려면 Persistent Volume (PV) 및 **Persistent Volume Claim (PVC)**를 활용해야 합니다. 이 글에서는 MySQL을 쿠버네티스에서 운영하면서 볼륨을 연동하는 방법을 설명합니다.

1. Persistent Volume (PV) 생성

PV는 클러스터 내에서 사용할 수 있는 스토리지 자원을 정의하는 객체입니다. MySQL 데이터를 유지하기 위해 PV를 생성합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: mysql-storage
  hostPath:
    path: "/mnt/data"

storage: 10Gi (10GB 크기의 볼륨)
accessModes: ReadWriteOnce (하나의 노드에서 읽기/쓰기 가능)
persistentVolumeReclaimPolicy: Retain (삭제 후에도 데이터 유지)
hostPath: "/mnt/data" (노드의 경로에 데이터를 저장)

2. Persistent Volume Claim (PVC) 생성

PVC는 애플리케이션이 PV를 요청하는 객체입니다. PVC를 생성하여 MySQL Pod에서 사용할 수 있도록 설정합니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: mysql-storage

storageClassName: mysql-storage (PV와 매칭되는 Storage Class 지정)
accessModes: ReadWriteOnce (하나의 노드에서 접근 가능)
requests.storage: 10Gi (요청하는 스토리지 크기)

3. MySQL Deployment 및 Service 생성

PVC를 MySQL Pod에서 사용할 수 있도록 Deployment와 Service를 생성합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.7
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "rootpassword"
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-storage
        persistentVolumeClaim:
          claimName: mysql-pvc

image: mysql:5.7 (MySQL 5.7 이미지 사용)
MYSQL_ROOT_PASSWORD: "rootpassword" (루트 비밀번호 설정)
volumeMounts: /var/lib/mysql에 PVC를 마운트하여 데이터 보존
volumes: mysql-pvc와 연결

MySQL Service 생성

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  type: ClusterIP
  ports:
    - port: 3306
      targetPort: 3306
  selector:
    app: mysql

ClusterIP 서비스로 설정하여 외부에서 직접 접근할 수 없도록 제한합니다.
내부에서 MySQL에 접근하려면 kubectl port-forward를 활용해야 합니다.

kubectl port-forward svc/mysql 3306:3306

이제 로컬 머신에서 다음 명령으로 MySQL에 접근할 수 있습니다.

mysql -h 127.0.0.1 -P 3306 -u root -p

또한 원격 클러스터에서 접근하려면 SSH 터널링을 사용할 수 있습니다.

ssh -L 3306:localhost:3306 user@your-remote-cluster

이렇게 하면 로컬에서 원격 클러스터의 MySQL에 접속할 수 있습니다.

4. 배포 및 확인

이제 위의 YAML 파일들을 적용하여 MySQL을 쿠버네티스 클러스터에 배포합니다.

kubectl apply -f mysql-pv.yaml
kubectl apply -f mysql-pvc.yaml
kubectl apply -f mysql-deployment.yaml
kubectl apply -f mysql-service.yaml

배포된 MySQL Pod 확인:

kubectl get pods

MySQL 볼륨 상태 확인:

kubectl get pv
kubectl get pvc

MySQL 컨테이너에 접속하여 데이터가 유지되는지 확인:

kubectl exec -it <mysql-pod-name> -- mysql -u root -p

비밀번호를 입력하고 MySQL이 정상적으로 동작하는지 확인하면 됩니다.

5. 결론

쿠버네티스에서 MySQL과 볼륨(PV & PVC)을 연동하면, Pod가 재시작되어도 데이터를 유지할 수 있습니다.

MSA 도커 localhost 안될때 호스트머신 주소 접근방법, host.docker.internal

딩코딩 — Wed, 5 Feb 2025 20:51:09 +0900

Docker 컨테이너 간 통신 및 localhost 사용 문제 해결

문제 상황

Docker 컨테이너에서 localhost 또는 **127.0.0.1**을 사용할 경우, 이는 컨테이너 내부를 참조합니다.

따라서 다른 컨테이너나 호스트 머신에 접근하려고 할 때 연결되지 않는 문제가 발생할 수 있습니다.

해결 방법

방법 1. 컨테이너 이름으로 접근

Docker는 같은 네트워크에 있는 컨테이너 간에 컨테이너 이름을 도메인 이름처럼 사용할 수 있도록 지원합니다.

예를 들어, **post-service**라는 이름의 컨테이너에 접근하려면 **http://post-service:포트번호**로 요청할 수 있습니다.

1. 컨테이너를 같은 네트워크로 설정

기본적으로 Docker 컨테이너는 서로 다른 네트워크로 분리되어 있습니다. 따라서 같은 네트워크로 연결해야 합니

2. 네트워크 생성 실행 중인 컨테이너가 없다면 새 네트워크를 생성한 뒤 컨테이너를 실행합니다.

docker network create backend-network

3. 컨테이너 실행 시 네트워크 연결 컨테이너 실행 시 -network 옵션을 사용해 네트워크를 연결합니다:

docker run --name post-service --network backend-network -p 9000:9000 post-service-image
docker run --name another-service --network backend-network -p 8080:8080 another-service-image

4. 실행 중인 컨테이너에 네트워크 연결 이미 실행 중인 컨테이너가 있다면 docker network connect 명령으로 연결합니다:

docker network connect backend-network post-service docker network connect backend-network another-service

5. 컨테이너 이름으로 접근

예: post-service 컨테이너에 접근하려면:
<http://post-service:9000>

장점

호스트나 별도의 설정 없이 Docker 환경 내에서 자체적으로 동작.
표준화된 네트워크 관리 가능.

방법 2. host.docker.internal 사용

**host.docker.internal**은 Docker 컨테이너 내부에서 호스트 머신을 참조하기 위한 예약 도메인입니다.

이를 사용하면 컨테이너에서 호스트 머신에 있는 서비스에 쉽게 접근할 수 있습니다.

1. host.docker.internal로 변경 기존의 localhost 대신 **host.docker.internal**을 사용합니다:

spring.datasource.url=jdbc:mariadb://host.docker.internal:3307/lulla_volume?serverTimezone=UTC&characterEncoding=UTF-8

2. 리눅스에서 설정 추가 Linux에서는 **host.docker.internal**이 기본적으로 동작하지 않습니다. 이 경우 컨테이너 실행 시 -add-host 옵션을 추가합니다:

docker run --name my-service \
  --add-host host.docker.internal:host-gateway \
  -p 8080:8080 my-service-image

장점

네트워크 설정 없이 호스트 머신과 직접 통신 가능.
호스트에서 실행 중인 데이터베이스, 서버 등에 접근할 때 간편.

정리

방법	설명	장점	단점
방법 1. 컨테이너 이름 사용	컨테이너 이름으로 다른 컨테이너 접근 (http://post-service:9000)	컨테이너 간 통신에 표준화된 접근 방식 제공. 네트워크 분리 가능.	같은 네트워크 설정 필요. Docker 환경 외부와의 통신은 어려움.
방법 2. host.docker.internal	localhost 대신 host.docker.internal 사용해 호스트 머신에 접근	호스트 머신의 서비스에 간편하게 접근 가능. 네트워크 설정 불필요.	리눅스에서는 기본적으로 동작하지 않아 추가 설정 필요. 보안 관리 주의 필요.

쿠버네티스 ConfigMap과 Secret 완벽 정리

딩코딩 — Wed, 5 Feb 2025 01:33:42 +0900

쿠버네티스에서 애플리케이션의 설정을 분리하여 관리하는 두 가지 주요 리소스가 ConfigMap과 Secret입니다. 이 두 가지는 환경 설정 값을 Pod에 주입하는 데 사용되지만, 중요한 차이점이 있습니다. 이번 포스팅에서는 ConfigMap과 Secret의 차이점, 사용 방법, 주의할 점 등을 정리해 보겠습니다.

1. ConfigMap이란?

ConfigMap은 애플리케이션에서 사용하는 설정 데이터를 저장하는 쿠버네티스 리소스입니다. 일반적으로 환경 변수, 설정 파일, 커맨드라인 인자 등을 저장하는 용도로 사용됩니다.

✅ 특징

비밀 데이터가 아닌 일반적인 설정 값을 저장함 (예: 데이터베이스 URL, 서비스 포트)
Key-Value 형태로 데이터를 저장
Pod 내에서 환경 변수, 파일, 커맨드라인 인자로 주입 가능

ConfigMap 생성 방법

1️⃣ YAML 파일을 이용한 생성

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  APP_ENV: "production"
  DATABASE_URL: "mysql://user:password@db:3306/mydb"

ConfigMap을 Pod에 적용하는 방법

1️⃣ 환경 변수로 주입

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: APP_ENV

2. Secret이란?

Secret은 민감한 데이터를 저장하는 쿠버네티스 리소스입니다. ConfigMap과 유사하지만, 비밀번호, API 키, 인증 토큰 등 보안이 필요한 데이터를 저장하는 용도로 사용됩니다.

✅ 특징

ConfigMap과 유사하지만, Base64 인코딩을 사용하여 데이터를 저장함
민감한 정보를 보호하기 위해 Pod에 주입될 때 특정한 보안 메커니즘이 적용됨
Pod 내에서 환경 변수, 파일, 커맨드라인 인자로 주입 가능
kubectl get secret을 사용하면 값이 ***로 표시되어 직접 볼 수 없음

Secret 생성 방법

1️⃣ YAML 파일을 이용한 생성

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  DB_PASSWORD: bXlwYXNzd29yZA==  # "mypassword"를 Base64 인코딩한 값
  API_KEY: dG9wLXNlY3JldC1rZXk=

Secret을 Pod에 적용하는 방법

1️⃣ 환경 변수로 주입

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: DB_PASSWORD

3. ConfigMap과 Secret의 차이점 비교

비교 항목	ConfigMap	Secret
목적	환경 설정값 저장	비밀번호, API 키 등 보안 정보 저장
데이터 저장 방식	일반 텍스트	Base64 인코딩
데이터 보안	보안 없음	보안 강화 (Base64 인코딩 + RBAC 적용)
사용 방법	환경 변수, 볼륨 마운트	환경 변수, 볼륨 마운트
kubectl get 출력	평문 표시	값이 ***로 숨겨짐

4. ConfigMap과 Secret 사용 시 주의할 점

✅ ConfigMap

어플리케이션 설정을 코드에서 분리하여 관리할 수 있음.
보안이 필요한 정보는 ConfigMap이 아닌 Secret을 사용할 것.
Pod가 실행 중일 때 ConfigMap이 변경되면, 즉시 반영되지 않을 수도 있음.

✅ Secret

Base64는 암호화가 아님! Base64 인코딩된 값은 쉽게 디코딩할 수 있음. (echo "bXlwYXNzd29yZA==" | base64 --decode)
보안이 필요한 경우 Kubernetes RBAC(Role-Based Access Control)를 활용하여 접근을 제한할 것.
파일 시스템 볼륨 마운트를 이용하면 Secret이 자동으로 업데이트됨 (환경 변수 주입 방식은 Pod 재시작 필요).

결론

ConfigMap은 일반적인 설정 정보, Secret은 보안이 필요한 정보를 저장하는 용도!
ConfigMap과 Secret을 활용하면 코드와 설정을 분리하여 관리할 수 있음.
Secret은 Base64로 인코딩되지만, 보안 강화를 위해 RBAC 및 암호화 솔루션(KMS 등)과 함께 사용하는 것이 중요!

Kubernetes에서 Service란?

딩코딩 — Tue, 4 Feb 2025 22:58:57 +0900

서비스(Service) : 외부로부터 요청을 받는 역할 / 외부로부터 들어오는 트래픽을 받아, 파드에 균등하게 분배해주는 로드밸런서 역할을 하는 기능

spring-service.yaml

apiVersion: v1
kind: Service

# Service 기본 정보
metadata:
  name: spring-service # Service 이름
  
# Service 세부 정보
spec:
  type: NodePort # Service의 종류
  selector:
    app: backend-app # 실행되고 있는 파드 중 'app: backend-app'이라는 값을 가진 파드와 서비스를 연결
  ports:
    - protocol: TCP # 서비스에 접속하기 위한 프로토콜
      port: 8080 # 쿠버네티스 내부에서 Service에 접속하기 위한 포트 번호
      targetPort: 8080 # 매핑하기 위한 파드의 포트 번호
      nodePort: 30000 # 외부에서 사용자들이 접근하게 될 포트 번호

Kubernetes Service의 주요 개념

1. Selector와 Label

Service는 특정 Pod을 대상으로 트래픽을 전달해야 한다. 이때 Selector를 사용하여 특정 Label을 가진 Pod을 찾아 연결한다.

2. ClusterIP (기본값)

Service는 기본적으로 ClusterIP를 제공하여 내부 네트워크에서 Pod을 접근할 수 있도록 한다.

3. NodePort

클러스터 외부에서도 접근할 수 있도록 NodePort를 설정하면, 각 노드의 특정 포트를 통해 Service에 접근할 수 있다.

4. LoadBalancer

클라우드 환경에서 외부 로드 밸런서를 생성하여 Service에 접근할 수 있도록 한다.

5. ExternalName

DNS 이름을 반환하여 외부 서비스로 연결할 수 있도록 한다.

서비스 실행하기

kubectl apply -f spring-service.yaml

서비스 확인하기

kubectl get service

Docker + GitHub Actions 배포 vs 쿠버네티스 배포 비교

딩코딩 — Tue, 4 Feb 2025 10:02:23 +0900

쿠버네티스를 이용한 배포 방식으로 변경하면 기존 Docker + GitHub Actions 기반 배포와 비교해서 차이가 많습니다.

특히, 온프레미스(개발 서버 직접 운영) 환경이라면, 쿠버네티스를 적용하는 방식이 다소 달라질 수 있습니다.

배포 방식기존 Docker + GitHub Actions쿠버네티스 (K8s)

배포 대상	EC2 또는 직접 구축한 서버에서 실행	쿠버네티스 클러스터 (온프레미스 or 클라우드)
실행 방식	서버에서 Docker 컨테이너 직접 실행	K8s의 Pod 단위로 컨테이너 관리
배포 방식	GitHub Actions에서 docker build → docker run	GitHub Actions에서 kubectl apply
확장 방식	서버의 스펙을 높이거나, 새로운 서버 추가 후 수동 배포	HPA(Pod 자동 확장), Node 추가 가능
장애 대응	컨테이너가 죽으면 수동으로 재시작 필요	쿠버네티스가 자동으로 복구 (Self-healing)
네트워크 관리	Docker 컨테이너별 포트 설정	K8s Service & Ingress 컨트롤 가능
로드 밸런싱	Nginx 또는 AWS ELB 사용	쿠버네티스 자체 로드 밸런싱 지원

결론: 기존 Docker 배포보다 확장성, 장애 대응, 자동 복구, 트래픽 관리 측면에서 쿠버네티스가 훨씬 유리함. 하지만 운영이 더 복잡할 수 있음.

기존 Docker + GitHub Actions 배포 방식

기존 배포 과정 (Docker 방식)

1️⃣ GitHub Actions 실행 → 서버에서 Docker 이미지 빌드

- name: Build Docker Image
  run: docker build -t my-app .

2️⃣ Docker Hub or ECR에 푸시

- name: Push to Docker Hub
  run: docker push my-app

3️⃣ 서버에 SSH 접속 후 실행

- name: Deploy to Server
  run: |
    ssh user@server "docker stop my-app && docker rm my-app"
    ssh user@server "docker run -d -p 8080:8080 my-app"

✔️ 문제점:

서버에 직접 Docker 컨테이너를 실행하는 방식이라 서버 장애 발생 시 자동 복구 안됨
스케일링(트래픽 증가 시 확장)이 어렵고, 컨테이너 개수를 늘리면 수동으로 관리해야 함

쿠버네티스 기반 배포 방식

쿠버네티스로 전환하면 기존 Docker 배포보다 더 유연하고 자동화된 방식으로 운영 가능.

쿠버네티스 배포 과정 (K8s 방식)

1️⃣ GitHub Actions 실행 → Docker 이미지 빌드

- name: Build Docker Image
  run: docker build -t my-app .

2️⃣ 이미지를 컨테이너 레지스트리(Docker Hub, ECR, Private Registry)에 푸시

- name: Push to Docker Hub
  run: docker push my-app

3️⃣ 서버의 쿠버네티스 클러스터에 kubectl apply

- name: Deploy to Kubernetes
  run: kubectl apply -f deployment.yaml

✔️ 차이점:

GitHub Actions에서 docker run으로 직접 실행하는 것이 아니라, 쿠버네티스 클러스터에 배포
서버 장애 발생 시 쿠버네티스가 자동 복구
HPA (Horizontal Pod Autoscaler)로 트래픽 증가 시 자동 확장 가능

쿠버네티스 배포 시 필요한 구성 요소

쿠버네티스로 배포하려면 기존과 다른 몇 가지 추가 설정이 필요.

✅ 1) Deployment 설정 (deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        ports:
        - containerPort: 8080

✔️ Pod 개수(replica)를 설정하여 스케일링 가능

✅ 2) Service 설정 (service.yaml)

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

✔️ 쿠버네티스 내부에서 Pod 간 트래픽을 관리
✔️ LoadBalancer 타입을 사용하여 외부에서 접근 가능

✅ 3) Ingress 설정 (ingress.yaml, 선택)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

✔️ 도메인을 통해 접근하도록 설정 (Nginx Ingress 사용 가능)

쿠버네티스로 바뀌면 무엇이 편리해질까?

기능기존 Docker 배포쿠버네티스 배포

자동 복구	컨테이너 죽으면 직접 재시작 필요	Pod가 죽으면 K8s가 자동으로 재시작
트래픽 증가 대응	서버 수동 추가 필요	HPA(Pod 자동 확장) 사용 가능
로드 밸런싱	Nginx 등 직접 설정	K8s Service & Ingress로 자동 관리
Zero-Downtime 배포	기존 컨테이너 중지 후 배포	Rolling Update로 무중단 배포 가능
다중 서버 관리	수동으로 서버 추가	K8s 노드 추가로 자동 확장

쿠버네티스로 전환하면 이런 점이 좋아짐

1️⃣ 트래픽 증가 시, 자동으로 Pod 개수를 늘릴 수 있음 (HPA 사용)
2️⃣ 서버 장애 발생 시, 자동으로 복구됨 (Self-Healing)
3️⃣ CI/CD 연동하여 무중단 배포(Rolling Update) 가능
4️⃣ 서비스 간 통신(Networking)이 자동 관리됨 (Service & Ingress 활용)
5️⃣ 운영이 안정적이고, 확장성이 좋아짐 (스케일아웃이 유리함)

결론: 쿠버네티스로 전환하는 게 좋은 경우

✅ 개발 서버가 여러 개 있고, 트래픽 증가 시 자동 확장이 필요할 때
✅ 서버 장애가 나도 자동 복구되도록 운영하고 싶을 때
✅ Zero-Downtime 배포(무중단 배포)를 적용하고 싶을 때
✅ CI/CD 파이프라인을 K8s 기반으로 개선하고 싶을 때

Kubernetes Deployment를 사용하여 여러 개의 Pod 실행하기

딩코딩 — Tue, 4 Feb 2025 01:25:54 +0900

Kubernetes에서 동일한 Pod을 여러 개 실행하려면 Deployment를 활용하면 된다. Deployment는 여러 개의 Pod을 관리하고, 업데이트 및 롤백을 손쉽게 수행할 수 있도록 도와준다.

Deployment 작성 방법

apiVersion: apps/v1  # Deployment의 API 버전
kind: Deployment  # Deployment 리소스를 생성한다.

metadata:
  name: spring-deployment  # Deployment의 이름

spec:
  replicas: 3  # 동일한 Pod을 3개 실행한다.
  selector:
    matchLabels:
      app: backend-app  # backend-app 레이블을 가진 Pod을 관리한다.

  template:  # 새로운 Pod을 생성하는 템플릿
    metadata:
      labels:
        app: backend-app
    spec:
      containers:
        - name: spring-container
          image: spring-server  # 사용할 컨테이너 이미지
          imagePullPolicy: IfNotPresent  # 로컬에 이미지가 없으면 풀받아온다.
          ports:
            - containerPort: 8080  # 컨테이너가 사용할 포트

Deployment 생성 및 확인 방법

1. Deployment 생성

아래 명령어를 실행하여 Deployment를 생성한다.

kubectl apply -f deployment.yaml

2. Deployment 확인

Deployment가 정상적으로 생성되었는지 확인하려면 다음 명령어를 사용한다.

kubectl get deployment

3. ReplicaSet 확인

Deployment는 ReplicaSet을 통해 Pod을 관리하므로, ReplicaSet이 정상적으로 생성되었는지 확인한다.

kubectl get replicaset

4. Pod 확인

실제로 실행 중인 Pod이 정상적으로 배포되었는지 확인하려면 아래 명령어를 입력한다.

kubectl get pod

위와 같이 Deployment를 사용하면 동일한 Pod을 여러 개 띄울 수 있으며, 관리도 편리해진다. kubectl get 명령어를 활용하여 Deployment, ReplicaSet, Pod이 정상적으로 배포되었는지 확인하는 것이 중요하다.

Dockerfile에서 WORKDIR과 COPY . .의 역할과 필요성

딩코딩 — Tue, 4 Feb 2025 00:00:20 +0900

Dockerfile을 작성할 때 `WORKDIR`과 `COPY . .`을 자주 사용하지만, **정말 필요할까? 없이도 실행이 가능할까? 이 글에서는 `WORKDIR`과 `COPY . .`의 필요성과 역할을 명확하게 정리해보겠습니다.

## ✅ WORKDIR과 COPY . . 없이도 실행이 가능할까?

### 1️⃣ `WORKDIR` 없이 `COPY . .`만 사용하는 경우

FROM node:18
COPY . .
RUN npm install
CMD ["node", "index.js"]

✅ 실행 가능하지만 모든 파일이 루트(/) 디렉터리에 복사됩니다.
❌ 루트 디렉터리는 시스템 파일과 섞일 위험이 있어 관리하기 어렵습니다.

2️⃣ COPY . . 없이 WORKDIR만 설정한 경우

FROM node:18
WORKDIR /app
RUN npm install
CMD ["node", "index.js"]

❌ 컨테이너 내부에 실행할 코드가 존재하지 않아, 실행 시 파일을 찾을 수 없다는 오류가 발생합니다.

3️⃣ WORKDIR과 COPY . . 둘 다 없는 경우

FROM node:18
CMD ["node", "index.js"]

❌ 애플리케이션 코드가 컨테이너 내부에 존재하지 않기 때문에 실행이 불가능합니다.

✅ WORKDIR과 COPY . .을 사용하는 이유

WORKDIR과 COPY . .를 함께 사용하면 파일을 정리하여 관리하기 쉽고, 실행 환경을 명확하게 설정할 수 있습니다.

올바른 Dockerfile 예시

FROM node:18

# 작업 디렉터리를 /app으로 설정
WORKDIR /app

# 현재 디렉터리의 모든 파일을 컨테이너의 /app 폴더로 복사
COPY . .

# npm 패키지 설치
RUN npm install

# 앱 실행
CMD ["node", "index.js"]

사용의 장점

✅ 파일이 특정 폴더(/app)에 정리되어 관리가 용이
✅ 컨테이너 실행 시 자동으로 /app에서 실행되므로 실행 명령어가 단순해짐
✅ 루트(/) 디렉터리에 파일이 흩어지는 것을 방지하여 보안성이 증가

✅ WORKDIR과 COPY . . 비교 정리

방법	실행 여부	추천 여부	설명
WORKDIR 없이 COPY . . 사용	가능	❌	파일이 루트(/)에 복사되어 관리가 어려움
COPY . . 없이 WORKDIR만 설정	불가능	❌	컨테이너 내부에 실행할 파일이 없음
둘 다 없음	불가능	❌	컨테이너 내부에서 실행할 코드가 없어서 실행 자체가 안 됨
둘 다 사용 (권장 방식)	가능	✅	애플리케이션을 /app 등 특정 폴더에 정리하여 관리

✅ 결론

Docker에서 WORKDIR과 COPY . .는 필수는 아니지만, 일반적으로 권장되는 설정입니다.
이를 통해 파일을 체계적으로 관리하고 실행 환경을 명확하게 설정할 수 있습니다.

특히, 실무에서는 여러 컨테이너를 운영하기 때문에 특정 폴더(/app 등)에 파일을 모아두는 것이 관리 및 유지보수 측면에서 매우 중요합니다.

이상 gpt를 통해 궁금해서 찾아본 내용을 정리해 보았습니다.

쿠버네티스 기초 명령어

딩코딩 — Wed, 22 Jan 2025 00:44:01 +0900

1. 매니페스트 생성 (nginx-pod.yaml)

apiVersion: v1
kind: Pod #Pod를 만들때는 apiVersion을 V1을 써야하는데 공식문서에서 이렇게 안내한다. 따로 이유를 알 필요는 없음

metadata:
  name: nginx-pod

spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
        - containerPort: 80
      imagePullPolicy: IfNotPresent

2. pod 시작

kubectl apply -f nginx-pod.yaml

3. 실행중인 pod 확인

kubectl get pods

4. pod 내부로 진입

kubectl exec -it nginx-pod -- bash

5. pod 포트 포워딩

kubectl port-forward pod/nginx-pod 80:80

6. pod 삭제

kubectl delete pod nginx-pod

7. pod 디버깅 할때

kubectl describe pod <pod-name>                          # Pod 상태 및 이슈 확인
kubectl logs <pod-name> -f                      # 실시간 로그 확인 (follow mode)
kubectl exec -it <pod-name> -- /bin/sh          # Pod 내부 접근 (sh shell)
kubectl exec -it <pod-name> -- /bin/bash        # Pod 내부 접근 (bash shell)

플러터 상중하 AppBar 기본 init

딩코딩 — Mon, 15 Jul 2024 23:50:38 +0900

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}): super(key: key);
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(),
        body: Container(),
        bottomNavigationBar: BottomAppBar(),
      ),
    );
  }
}