Dockerfile 완벽 가이드: 구조와 모범 사례

Dockerfile 기본 구조 Dockerfile은 Docker 이미지를 생성하기 위한 스크립트입니다. 각 명령어는 새로운 레이어를 생성하며, 이미지의 최종 상태를 결정합니다. 1. 기본 설정 명령어 FROM FROM node:18-alpine 베이스 이미지 지정 모든 Dockerfile은 FROM으로 시작 가능한 경우 공식 이미지 사용 권장 Alpine 기반 이미지로 크기 최소화 가능 ARG ARG VERSION=latest ARG BUILD_ENV=production 빌드 시점 변수 정의 docker build --build-arg 로 외부 주입 가능 ENV와의 주요 차이점: 빌드 시에만 사용 가능 이미지에 저장되지 않음 컨테이너 실행 시 접근 불가 2. 파일 시스템 설정 WORKDIR WORKDIR /app 작업 디렉토리 설정 절대 경로 사용 권장 존재하지 않는 경우 자동 생성 이후 명령어의 기준 경로가 됨 COPY # 단일 파일 복사 COPY package.json . # 여러 파일 복사 COPY ["file1", "file2", "./"] # .dockerignore 적용 COPY . . 호스트에서 이미지로 파일 복사 상대 경로는 WORKDIR 기준 .dockerignore로 제외 파일 설정 가능 3. 빌드 및 실행 설정 RUN # 쉘 형식 RUN npm install # 실행 형식 RUN ["npm", "install"] # 레이어 최소화를 위한 체이닝 RUN apt-get update && \ apt-get install -y \ package1 \ package2 && \ rm -rf /var/lib/apt/lists/* 새 레이어에서 명령어 실행 이미지 빌드 중 실행 레이어 수 최소화를 위해 명령어 체이닝 권장 ENV ENV NODE_ENV=production ENV PATH=$PATH:/usr/local/bin 환경 변수 설정 빌드 시점 및 런타임에서 사용 가능 컨테이너 실행 시에도 유지됨 CMD와 ENTRYPOINT # CMD 예시 CMD ["npm", "start"] # ENTRYPOINT 예시 ENTRYPOINT ["nginx"] CMD ["-g", "daemon off;"] CMD: 기본 실행 명령어 (오버라이드 가능) ENTRYPOINT: 고정 실행 명령어 보통 둘 중 하나만 사용 ENTRYPOINT + CMD 조합도 가능 Docker Build 명령어 상세 가이드 기본 빌드 명령어 docker build -t my-app:1.0 . 주요 빌드 옵션 옵션 설명 예시 -t, --tag 이미지 태그 지정 docker build -t app:1.0 . -f, --file 도커파일 경로 지정 docker build -f prod.Dockerfile . --build-arg 빌드 인자 전달 docker build --build-arg ENV=prod . -q, --quiet 진행 상황 출력 생략 docker build -q . 빌드 컨텍스트 최적화 .dockerignore 활용 # 빌드에서 제외할 파일 node_modules *.log .git .env* 레이어 캐시 활용 # 효율적인 캐시 활용 COPY package*.json ./ RUN npm install COPY . . 멀티 스테이지 빌드 예시 # 빌드 스테이지 FROM node:18 AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build # 실행 스테이지 FROM node:18-alpine WORKDIR /app COPY --from=builder /app/dist ./dist COPY package*.json ./ RUN npm install --production CMD ["npm", "start"] 모범 사례 및 팁 1. 이미지 크기 최적화 Alpine 기반 이미지 사용 불필요한 패키지 제거 멀티 스테이지 빌드 활용 2. 보안 강화 루트가 아닌 사용자로 실행 최소 권한 원칙 적용 보안 스캔 도구 활용 3. 캐시 최적화 자주 변경되는 레이어는 나중에 배치 의존성 설치는 별도 레이어로 분리 .dockerignore 적극 활용 참고 문헌 Docker 공식 문서: Dockerfile 모범 사례 Docker 빌드 최적화 가이드 컨테이너 보안 가이드라인

Infra · 2025-08-26

Introduction

컴퓨터 네트워크 컴퓨터와 프린터, 스마트폰과 같은 기타 장치들이 서로 통신할 수 있도록 연결한 집합이다. 통신을 위해 컴퓨터와 장치는 정보 전송을 지원하는 물리적 매체로 연결되어야한다. 구리 케이블 및 광섬유와 같은 유선 매체와 무선 주파수 매체를 포함하여 물리적 매체에 대한 다양한 기술이 개발되었다. 컴퓨터는 다양한 네트워크 토폴로지로 매체에 연결될 수 있다. 네트워크를 통신하기 위해 컴퓨터는 사용되는 매체와 상관없이 통신 프로토콜이라는 합의된 규칙을 사용한다. 컴퓨터 네트워크에는 개인용 컴퓨터, 서버, 네트워킹 하드웨어 또는 기타 특수 목적 또는 일반 목적을 호스트가 포함될 수 있다. 이들은 네트워크 주소로 식별되며 호스트명을 가질 수 있다. 호스트명은 노드에 대한 기억하기 쉬운 레이블 역할을 하며 초기 할당 후에는 거의 변경되지 않는다. 네트워크 주소는 인터넷 프로토콜과 같은 통신 프로토콜에 의해 노드를 찾고 식별하는 데 사용된다. 네트워크 패킷 대부분의 최신 컴퓨터 네트워크는 패킷 모드 전송을 기반으로 하는 프로토콜을 사용한다. 네트워크 패킷은 교환 네트워크에서 전송되는 형식화된 데이터 단위이다. 패킷은 제어 정보와 사용자 데이터(Payload)의 두 가지 유형의 데이터로 구성된다. 제어 정보는 네트워크가 사용자 데이터를 전달하는 데 필요한 데이터를 제공한다. 예를 들어, 소스 및 대상 네트워크 주소, 오류 감지 코드 및 시퀀싱 정보 등이 있다. 일반적으로 패킷 헤더 및 트레일러에 있으며, 사용자 데이터(Payload)는 그 사이에 있다. 패킷을 사용하면 네트워크가 회선 교환되는 경우보다 전송 매체의 대역폭을 사용자 간에 더 잘 공유할 수 있다. OSI 7 Layer Layer Protocol Data Unit(PDU) e.g. Function Host Layer 7 Application Layer Data HTTP, SMTP, SNMP, FTP, TELNET, NFS, NTP 리소스 공유나 원격 파일 접근을 위한 고급 프로토콜 Host Layer 6 Presentation Layer Data ASCII, MIDI, MPEG 네트워킹 서비스와 애플리케이션 간 데이터 변환 (문자 인코딩, 데이터 압축, 암호화/복호화) Host Layer 5 Session Layer Data FIFO, NetBIOS, SSL, TLS 통신 세션 관리, 즉 두 노드 간의 여러 번의 왕복 전송 형태로 정보를 지속적으로 교환하는 것 Host Layer 4 Transport Layer Segment TCP, UDP, RTP, SCTP 패킷 분할, ACK 및 멀티플렉싱를 포함하여 네트워크의 지점 간 데이터 세그먼트의 안정적인 전송 Media Layer 3 Network Layer Packet, Datagram IP, ICMP, IPsec Addressing, Routing, Traffic Control을 포함한 다중 노드 네트워크 구조화 및 관리 Media Layer 2 Data Link Layer Frame Ethernet 물리적 계층으로 연결된 두 노드 간 데이터 프레임 전송 Media Layer 1 Physical Layer Bit, Symbol X.25, RS-232 물리적 매체를 통한 원시 비트 스트림의 전송 및 수신 브리지 및 스위치 브리지와 스위치는 통신에 관련된 포트로만 프레임을 전달한다. 브리지는 두 개의 포트만 있지만, 스위치는 일반적으로 수많은 포트를 가지고 있어 장치에 대한 스타 토폴로지를 용이하게 하고 추가 스위치를 계단식으로 연결할 수 있다. 브리지와 스위치는 OSI 모형의 데이터 링크 계층(2 Layer)에서 작동하며 두 개 이상의 네트워크 세그먼트 간의 트래픽을 브리지하여 단일 로컬 네트워크를 형성한다. 브리지와 스위치는 네트워크의 충돌 도메인을 분할하지만 단일 브로드캐스트 도메인을 유지한다. 브리징 및 스위칭을 통한 네트워크 세분화는 크고 혼잡한 네트워크를 더 작고 효율적인 네트워크의 집합으로 분해하는 데 도움이 된다. 라우터 라우터는 패킷에 포함된 주소 지정 또는 라우팅 정보를 처리하여 네트워크 간에 패킷을 전달하는 인터네트워킹 장치이다. 라우팅 정보는 종종 라우팅 테이블과 함께 처리된다. 라우터는 라우팅 테이블을 사용하여 전달할 위치를 결정한다. 방화벽 방화벽은 네트워크 보안 및 엑세스 규칙을 제어하는 네트워크 장치 또는 소프트웨어이다. 방화벽은 내부 네트워크와 인터넷과 같은 잠재적으로 안전하지 않은 외부 네트워크 간의 연결에 삽입된다. 방화벽은 일반적으로 인식되지 않는 소스에서의 엑세스 요청을 거부하고 인식된 소스에서의 작업을 허용하도록 구성된다. 점점 증가하는 사이버 공격 관련 이슈가 발생하는 현 시대에서 방화벽은 네트워크 보안에서 중요한 역할로 여겨지고 있다. SSL(Secure Socket Layer)/TLS(Transport Layer Security) SSL은 인증서가 있는 서버를 필요로 한다. 클라이언트가 SSL 보안 서버에 대한 엑세스를 요청하면 서버는 인증서 사본을 클라이언트에 보낸다. SSL 클라이언트는 전달받은 인증서를 확인 후 검증되면 서버가 인증된다. 클라이언트는 세션에서 사용할 대칭 키 암호를 협상한다. 세션은 SSL 서버와 SSL 클라이언트 간의 매우 안전한 암호화된 터널에서 통신할 수 있게된다. References https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0_%EB%A7%9D https://ko.wikipedia.org/wiki/OSI_%EB%AA%A8%ED%98%95

Infra · 2025-09-16

Kubernetes Helm 차트 분석

Helm 개요 Helm은 Kubernetes의 패키지 매니저로서, charts라는 패키지 포맷을 통해 애플리케이션을 관리합니다. Helm Charts의 이해 기본 개념 Charts: Kubernetes 리소스를 설명하는 파일들의 집합 Release: Kubernetes 클러스터에 배포된 Chart의 인스턴스 Repository: Charts를 저장하고 공유하는 저장소 Charts의 활용 사례 단순 배포: 단일 서비스(예: Memcached) 배포 독립적인 마이크로서비스 구성 복잡한 애플리케이션: 웹 애플리케이션 전체 스택 데이터베이스 + 캐시 + 서버 조합 마이크로서비스 아키텍처 Chart 구조와 기본 명령어 myapp/ Chart.yaml # 메타데이터 파일 values.yaml # 기본 설정값 templates/ # 템플릿 디렉토리 deployment.yaml # 배포 설정 service.yaml # 서비스 설정 ingress.yaml # 인그레스 설정 charts/ # 종속성 차트들 주요 명령어 # Chart 다운로드 helm pull chartrepo/chartname # Chart 설치 helm install release-name chartrepo/chartname # 릴리스 목록 조회 helm list # Chart 업그레이드 helm upgrade release-name chartrepo/chartname <https://helm.sh/ko/docs/topics/charts/> ## Helm 템플릿 시스템 ### 템플릿 기본 사항 Helm의 템플릿 시스템은 Go 템플릿을 기반으로 하며, 강력한 변수 치환과 조건부 로직을 제공합니다. #### 템플릿 문법 예시 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-config data: # 단순 값 참조 database: {{ .Values.database.name }} # 조건문 사용 {{- if .Values.enableFeature }} feature.enabled: "true" {{- end }} # 반복문 사용 ports: | {{- range .Values.service.ports }} - {{ . }} {{- end }} 로컬 템플릿 테스트 템플릿을 실제 클러스터에 적용하기 전에 로컬에서 테스트할 수 있습니다. # 기본 템플릿 렌더링 helm template . # 특정 값 파일 사용 helm template . -f values.dev.yaml # 특정 템플릿만 렌더링 후 적용 helm template . -s templates/config.yaml --values=dev.yaml | kubectl apply -f - 주의사항 클러스터 상태 의존적인 값들은 로컬에서 테스트할 때 가상(faked) 값으로 대체됩니다 서버 측 유효성 검사는 수행되지 않으므로, 실제 적용 전 주의가 필요합니다 Helm Values 시스템 Values 파일 구조화 values.yaml 파일은 Helm 차트의 기본 설정값을 정의합니다. 환경별로 다른 설정이 필요한 경우 values-{env}.yaml 파일을 사용할 수 있습니다. # values.yaml 예시 global: environment: production application: name: myapp replicas: 3 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 80 HPA (Horizontal Pod Autoscaling) 설정 HorizontalPodAutoscaler는 워크로드의 자동 스케일링을 담당하는 Kubernetes 리소스입니다. # HPA 템플릿 예시 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: {{ .Release.Name }}-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: {{ .Release.Name }} minReplicas: {{ .Values.autoscaling.minReplicas }} maxReplicas: {{ .Values.autoscaling.maxReplicas }} metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }} Ingress 설정 Ingress는 클러스터 외부에서 내부 서비스로의 HTTP/HTTPS 라우팅을 관리합니다. # Ingress 템플릿 예시 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ .Release.Name }}-ingress annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/ssl-redirect: "true" spec: rules: - host: {{ .Values.ingress.host }} http: paths: - path: / pathType: Prefix backend: service: name: {{ .Release.Name }}-service port: number: 80 Kubernetes 리소스 관리 ReplicaSet 관리 ReplicaSet은 지정된 수의 파드 복제본이 항상 실행되도록 보장하는 Kubernetes 리소스입니다. ReplicaSet 주요 구성 요소 # ReplicaSet 템플릿 예시 apiVersion: apps/v1 kind: ReplicaSet metadata: name: {{ .Release.Name }}-replicaset spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ .Release.Name }} template: metadata: labels: app: {{ .Release.Name }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" resources: requests: cpu: {{ .Values.resources.requests.cpu }} memory: {{ .Values.resources.requests.memory }} limits: cpu: {{ .Values.resources.limits.cpu }} memory: {{ .Values.resources.limits.memory }} ReplicaSet 설정 가이드 셀렉터 설정 파드 식별을 위한 레이블 매칭 규칙 정의 적절한 레이블링 전략 수립 필요 레플리카 수 관리 초기 레플리카 수 설정 HPA와 연동 시 고려사항 검토 파드 템플릿 설계 컨테이너 스펙 정의 리소스 요청/제한 설정 헬스 체크 구성 DaemonSet 데몬셋은 모든 노드 또는 일부 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. 데몬셋의 일부 대표적인 용도 모든 노드에서 클러스터 스토리지 데몬 실행 모든 노드에서 로그 수집 데몬 실행 모든 노드에서 노드 모니터링 데몬 실행 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. 컨테이너 리소스 관리 Kubernetes에서 효율적인 리소스 관리는 안정적인 애플리케이션 운영의 핵심입니다. 리소스 요청과 제한 # 리소스 설정 예시 resources: requests: memory: "128Mi" cpu: "250m" limits: memory: "256Mi" cpu: "500m" 리소스 요청 (Requests) 컨테이너가 필요로 하는 최소 리소스 양 스케줄링 결정에 사용 노드의 리소스 예약에 활용 리소스 제한 (Limits) 컨테이너가 사용할 수 있는 최대 리소스 양 초과 시 컨테이너 제한 또는 재시작 OOM Killer 동작 기준 CPU 리소스 단위 이해 단위 설명 예시 코어 1.0 = 1개 CPU 코어 cpu: "1.0" 밀리코어 1000m = 1개 CPU 코어 cpu: "500m" 백분율 CPU 코어의 백분율 cpu: "0.5" (50%) CPU 리소스 특징 절대값 기준: 노드 스펙과 무관하게 동일한 컴퓨팅 파워 최소 단위: 1m (0.001) CPU 일반적인 설정: 가벼운 서비스: 100m-250m 중간 규모: 500m-1000m 리소스 집약적: 1000m 이상 메모리 리소스 관리 spec: containers: - name: app resources: requests: memory: "128Mi" limits: memory: "256Mi" 메모리 단위 체계 단위 설명 사용 예 Ki 킬로바이트 (1024) memory: "64Ki" Mi 메가바이트 (1024^2) memory: "128Mi" Gi 기가바이트 (1024^3) memory: "2Gi" 참고: 쿠버네티스에서 CPU 리소스를 1m보다 더 정밀한 단위로 표기할 수 없다. 이 때문에, CPU 단위를 1.0 또는 1000m보다 작은 밀리CPU 형태로 표기하는 것이 유용하다. 예를 들어, 0.005 보다는 5m으로 표기하는 것이 좋다. 메모리 리소스 단위 memory 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, k 와 같은 수량 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. 128974848, 129e6, 129M, 128974848000m, 123Mi 접미사의 대소문자에 유의한다. 400m의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다. 이 사람은 아마도 400 메비바이트(mebibytes) (400Mi) 또는 400 메가바이트 (400M) 를 요청하고 싶었을 것이다. https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/

Infra · 2025-08-26

가비아

가비아 대한민국의 클라우드 및 그룹웨어 솔루션 기업이다. 주요 사업 IaaS 클라우드 인프라 서비스 (g클라우드) 클라우드 기반 그룹 웨어 (hiworks) 클라우드 매니지드 서비스 도메인 호스팅 주요 서비스 클라우드 g클라우드는 가비아의 자체 기술 스택으로 개발한 IaaS형 클라우드이다. 모든 내부 시스템의 고가용성(HA: High Availability)구성으로 안정성을 극대화했다. 현재 KT, NBP와 나란히 공공 클라우드 시장에 진출해 있다. 도메인 국내 도메인 등록 점유율 1위로, 85만 개 이상의 도메인을 보유하고 있다. 기업 도메인의 등록/연장과 브랜드 보호를 위한 서비스를 일반 도메인과 별도로 운영하고 있다. 호스팅/IDC 개인/기업, OS, 업종에 따른 호스팅 서비스를 운영한다. 웹호스팅 외에도 웹에이전시 호스팅/워드프레스 호스팅/이미지 호스팅/동영상 호스팅 등을 서비스하고 있다. 서버호스팅, 코로케이션, 위탁운영 등 물리 서버 및 하이브리드 서버의 임대/구매 및 운영을 맡고 있다. IDC는 서초, 가산, 강남, 분당에 위치해있다. 보안 자체 보안 브랜드인 가비아 시큐리티를 론칭하고 보안관제와 보안 컨설팅을 비롯한 기업 대상의 보안 서비스를 제공하고 있다. Reference https://ko.wikipedia.org/wiki/%EA%B0%80%EB%B9%84%EC%95%84

Infra · 2025-09-11

네트워크 인프라 구성도 그리기

구성 요소별 핵심 역할 👨‍💻 사용자 (Client) 웹 브라우저를 통해 서비스에 접속하는 최종 사용자입니다. 🌐 도메인 등록 및 DNS 서버 사용자가 도메인 주소(예: www.your-service.com)를 입력하면, 해당 주소를 클라우드 플랫폼의 서버 IP 주소로 변환하여 연결해주는 역할을 합니다. ☁️ 클라우드 플랫폼 VPC (Virtual Private Cloud): 클라우드 플랫폼 내에 생성된 논리적으로 분리된 가상의 네트워크 공간입니다. 외부로부터 격리되어 있어 보안이 강화됩니다. 로드 밸런서 (Load Balancer): 사용자의 요청(트래픽)을 여러 대의 웹 서버로 자동 분산하여 특정 서버에 과부하가 걸리는 것을 방지합니다. 이를 통해 서비스의 안정성을 높이고, SSL 인증서를 적용하여 HTTPS 통신을 처리합니다. Public Subnet (외부망): 인터넷과 직접 통신이 가능한 영역입니다. 웹 서버 (Nginx): 프론트엔드 애플리케이션을 사용자에게 제공합니다. 정적 파일을 서빙하고, 사용자의 동적 요청을 내부망에 있는 WAS로 전달하는 리버스 프록시(Reverse Proxy)의 핵심 역할을 수행합니다. Docker 컨테이너로 배포됩니다. Private Subnet (내부망): 인터넷에서 직접 접근할 수 없는 내부 네트워크 영역으로, 중요한 자원을 배치하여 보안을 강화합니다. WAS: 백엔드 애플리케이션으로, 실제 비즈니스 로직을 처리하고 데이터베이스와 통신합니다. 웹 서버를 통해서만 요청을 받기 때문에 외부에 직접 노출되지 않아 안전합니다. 마찬가지로 Docker 컨테이너로 배포됩니다. DB 서버: 서비스의 모든 데이터를 저장하고 관리하는 데이터베이스입니다. 클라우드 플랫폼의 관리형 서비스를 사용하거나, 서버에 Docker 컨테이너로 직접 구축할 수 있습니다. 가장 안쪽의 격리된 네트워크에 위치하며 오직 WAS의 요청에만 응답합니다. 데이터 흐름 DNS 조회: 사용자가 브라우저에 도메인 주소를 입력하면, DNS가 클라우드 플랫폼 로드 밸런서의 IP 주소를 알려줍니다. 요청 전달: 사용자의 요청은 클라우드 플랫폼의 로드 밸런서로 전달됩니다. 트래픽 분산: 로드 밸런서는 받은 요청을 Public Subnet에 있는 여러 웹 서버 중 하나로 전달합니다. 프론트엔드 서빙 및 API 요청: 웹 서버는 프론트 엔드 코드로 만들어진 화면을 사용자에게 보여줍니다. 만약 데이터 처리가 필요하면(예: 로그인, 게시글 조회), 웹 서버는 해당 요청을 Private Subnet에 있는 WAS로 전달합니다. 비즈니스 로직 처리: WAS는 요청을 받아 비즈니스 로직을 수행하고, 필요시 DB 서버에 데이터 조회를 요청합니다. 데이터 응답: DB 서버는 WAS의 요청을 처리한 후 결과를 반환합니다. API 응답: WAS는 DB에서 받은 데이터를 가공하여 웹 서버로 최종 결과를 전달합니다. 최종 렌더링: 웹 서버는 WAS로부터 받은 데이터를 포함하여 사용자에게 최종 화면을 보여줍니다. 보안/네트워킹 권장 설정 VPC 분리: 퍼블릭 서브넷, 프라이빗 서브넷 SG(Security Group): 최소 포트만 허용 LB→Web Server: 443/80(내부) Web Server→WAS: 8080(내부) WAS→DB: 3306(내부) HTTPS 강제 및 HSTS, 보안 헤더(Content-Security-Policy 등) 적용 DB 프라이빗 접속만 허용, 백업/복제/모니터링 배포 파이프라인(예시) CI: 테스트 → Docker 이미지 빌드 → 취약점 스캔 → 레지스트리에 push CD: 서버/쿠버네티스에 배포, 헬스체크 후 트래픽 전환(블루/그린 또는 롤링) 포트/엔드포인트 요약 외부: 443(HTTPS) → LB → Web Server 내부: 8080(WAS), 3306(DB) 관리: SSH는 Bastion Host 또는 SSM 계열 툴로 제한적 허용 운영 모니터링 애플리케이션: Prometheus + Grafana, Spring Actuator 인프라: Cloud Platform Monitoring, 로드밸런서/네트워크 지표, 로그 수집(ELK/EFK)

Infra · 2025-09-23

메시지 교환 방식

Infra · 2025-09-22

클라우드 컴퓨팅

Infra · 2025-09-11

ahngbeom

Contact

Infra