Devops

개요 Dockerizing은 Docker 컨테이너를 사용해 애플리케이션을 패키징하고 배포하고 실행하는 일련의 과정 코드와 런타임, 의존성, 설정을 이미지로 고정하여 환경 차이와 배포 리스크를 낮추는 것이 목적 핵심 개념 Image: 애플리케이션과 런타임, 의존성, 설정을 포함한 불변 아티팩트 Container: 이미지를 실행한 격리된 프로세스 단위 Dockerfile: 이미지를 만들기 위한 선언형 스펙 Registry: 이미지를 저장하고 배포하는 원격 저장소 동작 흐름 빌드 단계 Dockerfile 작성 후 docker build 실행해 이미지 생성 태그 전략 수립 필요 ex) app:1.2.3, app:stable, app:commit-hash 배포 단계 레지스트리에 docker push 환경별 레지스트리 또는 네임스페이스 구분으로 충돌 방지 실행 단계 docker run으로 컨테이너 기동, 포트 매핑과 환경 변수 주입 로그는 표준 출력으로 수집, 상태 점검을 위해 헬스체크 설정 권장 업데이트와 롤백 불변 이미지와 태그 기반 배포로 롤백 단순화 레지스트리 보존 정책으로 이력 관리 간단 예시 최소 Dockerfile 스니펫 FROM alpine:3.19 WORKDIR /app COPY . . CMD ["sh", "-c", "echo hello"] 로컬 빌드와 실행 docker build -t app:local . docker run --rm -p 8080:8080 app:local주의와 베스트프랙티스 최소 베이스 이미지 선택으로 공격면과 이미지 크기 축소 레이어 캐시 고려해 변경 빈도 낮은 명령을 상단에 배치 멀티스테이지 빌드로 빌드 타임 도구를 런타임 이미지에서 제거 비밀정보는 이미지에 포함하지 않고 시크릿 관리 도구 또는 런타임 주입 사용 컨테이너 리소스 제한 설정으로 노이즈 네이버 이슈 완화 개발과 운영 환경 간 설정 차이는 환경 변수와 명시적 구성으로 관리 보안 스캔과 베이스 이미지 업데이트 자동화로 취약점 대응 마무리 Dockerizing은 애플리케이션을 이미지로 표준화해 이식성과 재현성을 확보하고 배포 파이프라인 단순화에 기여함 핵심은 선언적 스펙으로 빌드하고 불변 이미지를 레지스트리로 배포한 뒤 태그와 자동화를 통해 일관되게 실행하는 것 작게 빠르게 안전하게의 원칙을 적용하면 운영 효율과 신뢰도 상승 ...

개요 DNS TTL은 레코드가 캐시로 유지되는 시간의 기준값으로 초 단위 설정값임. 권한 네임서버가 응답에 TTL을 포함하고, 재귀 리졸버와 클라이언트가 이 시간 동안 결과를 기억함. TTL이 만료되면 다시 질의가 발생함 핵심 개념 TTL Time To Live DNS 응답을 브라우저나 재귀 DNS 서버가 얼마 동안 캐시할지 정하는 값 예 TTL이 300이면 해당 레코드는 5분간 캐시 유지, 이후 재질의 발생 부존재 응답 NXDOMAIN 역시 SOA 설정에 따라 일정 시간 캐시됨 왜 중요한가 TTL이 짧으면 변경 사항이 빠르게 반영됨 트래픽 변화 대응 용이 대신 DNS 요청 수 증가로 지연과 비용 증가 가능 TTL이 길면 질의 수가 줄어 효율적이고 안정적임 캐시 적중률 상승 대신 변경 반영이 느림 권장 TTL 값 가이드 일반 웹사이트 300600 510분 트래픽 변화가 잦은 API 60~300 안정적이고 변경이 드문 서비스 360086400 1시간하루 레코드 변경 직전 예 이관 60 이하로 낮춰 사전 준비 참고 사항 ...

개념과 배경 마이크로서비스로 분산이 심화되면 로깅, 모니터링, 보안, 네트워킹 같은 공통 기능을 어디에 둘지 결정이 어려워짐 애플리케이션 코드에 공통 기능을 계속 끼워 넣으면 침투와 중복 증가, 배포와 버전 관리 복잡도 상승 사이드카 패턴은 공통 기능을 별도 컨테이너로 분리해 메인 서비스는 비즈니스 로직에 집중하게 하는 접근법 컨테이너 오케스트레이션 환경에서 일관된 운영 모델을 제공한다는 점이 실무적 장점 핵심 개념 사이드카 패턴의 구성 요소 메인 컨테이너: 비즈니스 로직 담당, 웹 서비스나 API 서버 등 사이드카 컨테이너: 횡단 관심사 처리, 로그 수집, 모니터링 에이전트, 프록시, 보안 검사 등 같은 파드 내 배치로 네트워크 네임스페이스와 볼륨 공유 가능, 표준 출력/공유 볼륨 등을 통해 데이터 연계 업데이트와 배포를 컨테이너 단위로 분리해 독립적 버전 관리 가능 동작 원리 하나의 파드에 메인 컨테이너와 사이드카 컨테이너를 함께 배치 ...

개요 Kubernetes 환경에서 Liveness Probe와 Readiness Probe는 애플리케이션 상태를 주기적으로 점검해 자동 복구와 트래픽 차단을 수행하는 안전 장치 역할 수행 Node.js는 싱글 스레드 기반으로 이벤트 루프 차단이나 메모리 누수 상황이 치명적이라 두 프로브의 설계가 안정성에 직접적인 영향 미침 핵심 차이 Liveness Probe의 질문은 너 살아있니, 실패 시 컨테이너 재시작 수행 Readiness Probe의 질문은 일할 준비 됐니, 실패 시 서비스 엔드포인트에서 제외해 트래픽 차단 수행 본질적 차이는 실패 시 K8s가 취하는 액션이며 재시작과 트래픽 제어로 구분됨 Node.js 맥락 Liveness Probe 대상 상황 이벤트 루프 블로킹으로 요청 처리 불가 상태 무한 루프 또는 데드락과 유사한 좀비 상태로 PID는 있으나 응답 불능 메모리 누수로 OOM 임박하여 응답 지연 또는 멈춤에 가까운 상태 Readiness Probe 대상 상황 프로세스는 떠 있으나 초기화 작업 진행 중인 상태 DB 연결 수립 중, 대용량 설정 로딩, 캐시 워밍업 등으로 실제 서비스 처리 불가 상태 유의점 Liveness는 가벼운 체크로 한정, 외부 의존성까지 포함 시 불필요한 재시작 유발 위험 Readiness는 실제 트래픽 처리 가능 여부를 반영해야 하며 의존성 준비 상태를 포함하는 편이 안전함 구현 스니펫 Node.js에서 Liveness는 최소한의 핑 수준으로, Readiness는 의존성 준비 여부를 반영하는 형태 권장 ...

컨트롤 플레인은 쿠버네티스 클러스터의 두뇌이자 의사결정 계층으로, 워커 노드가 실제 워크로드를 돌리는 동안 전체 상태를 정의하고 조율하는 역할을 맡음 조직 비유로 보면 컨트롤 플레인은 본사와 경영진, 워커 노드는 지점과 현장 직원에 해당함 개념과 정의 컨트롤 플레인은 Desired State를 선언적으로 저장하고, Observed State와 비교해 일치하도록 끊임없이 조정하는 계층 사용자는 API를 통해 상태를 선언하고, 컨트롤 플레인은 스케줄링과 컨트롤 루프로 이를 만족하도록 시스템을 수렴시킴 핵심 구성요소 API 서버 kube-apiserver — 모든 요청의 진입점, 인증·인가·어드미션 수행 후 상태 변경을 etcd에 반영 ...