여기어때, 컨테이너 기반 CI/CD 및 Observability 구축으로 플랫폼 관리 효율 UP!
Bun 런타임 기반의 Secrethub를 컨테이너화하여 배포하기 위해 Docker 멀티 스테이지 빌드(Multi-stage Build)를 적용, 이미지 크기를 최소화함
기존 Jenkins 기반 EC2 CI/CD의 확장성 한계를 극복하고자 GitLab CI 기반 중앙 관리 구조를 도입, EC2와 EKS 환경에서 동일한 CI 흐름을 유지함
CodeDeploy를 활용하여 EC2에 배포 스크립트를 전달하고, Docker Compose를 통해 컨테이너를 갱신하는 CD 파이프라인을 구축함
Docker 레벨 로그 수집 방식을 선택하여 애플리케이션 코드 변경 없이 Loki Driver Client를 통해 로그를 수집, 언어/프레임워크 독립성을 확보함
EC2 환경에서 EKS 전환을 위한 CI 표준화를 진행하며, 플랫폼 레벨 관리 구조를 구축하여 운영 확장성을 확보함
Bun 런타임(Runtime) 기반 컨테이너 이미지 빌드 전략
본문에서는 Bun 런타임(Runtime)을 사용하여 Secrethub를 컨테이너화하는 과정을 설명하며, Bun의 빌드 방식과 의존성 관리 전략에 주목한다.
`isolated` 링커: `node_modules`를 심볼릭 링크(Symbolic Link) 없이 독립적인 디렉토리에 복사하여 파일 시스템 예측 가능성(File System Predictability)을 확보
멀티 스테이지 빌드(Multi-stage Build): 빌드 스테이지(Build Stage)와 실행 스테이지(Run Stage)를 분리하여 최종 이미지 크기를 최소화(Minimize)
결과: 최종 이미지에 소스 코드, `node_modules`를 포함하지 않아 이미지 크기 감소(Image Size Reduction) 및 보안성 향상
이러한 전략은 컨테이너 환경에서 불필요한 파일(Unnecessary Files) 제거를 통해 이미지 빌드 속도를 높이고, 배포 효율성을 증대시킨다.
GitLab CI 기반 중앙 관리형 CI/CD 파이프라인 구축
여기어때는 기존 Jenkins 기반 EC2 CI/CD 구조의 확장성 한계를 인지하고, GitLab CI 기반 중앙 관리 구조를 도입했다.
DevOps팀 주도 CI 로직 관리: 서비스 설정만 선언적으로 정의하여 CI/CD 관리 효율성(CI/CD Management Efficiency)을 높임
EC2 및 EKS 환경 통합: 배포 대상에 관계없이 동일한 CI 흐름을 유지하여 일관된 배포 프로세스(Consistent Deployment Process)를 구축
CodeDeploy + Docker Compose: CodeDeploy를 통해 EC2에 배포 스크립트를 전달하고, Docker Compose를 활용하여 컨테이너를 갱신
이러한 접근 방식은 CI/CD 파이프라인의 유지보수성(Maintainability)을 향상시키고, DevOps팀의 중앙 집중식 관리(Centralized Management)를 가능하게 한다.
CodeDeploy를 활용한 CD 파이프라인 설계
본문에서는 CodeDeploy를 활용한 CD(Continuous Delivery) 파이프라인 설계를 상세히 설명하며, 배포 자동화(Deployment Automation)를 위한 핵심 요소들을 제시한다.
훅(Hooks) 활용: `ApplicationStop`, `BeforeInstall`, `AfterInstall`, `ApplicationStart` 훅을 활용하여 배포 단계별 스크립트 실행
운영 환경 독립성 확보: 서버 재부팅 또는 EC2 인스턴스 교체 상황에서도 자동 배포(Automated Deployment)가 가능하도록 설계
BeforeInstall 훅 수정: 기존 컨테이너 중지 로직을 `ApplicationStop` 훅으로 이동하여 훅 실행 순서(Hook Execution Order) 준수
이러한 설계를 통해 배포 과정의 안정성(Stability)을 높이고, 운영 효율성을 극대화한다.
Docker 레벨 로그 수집을 통한 Observability 확보
여기어때는 Docker 레벨 로그 수집 방식을 선택하여 Observability를 확보하고, 애플리케이션 코드 변경 없이 로그 수집을 구현했다.
Loki Driver Client 활용: 컨테이너의 `stdout/stderr` 로그를 Loki로 직접 전송하여 로그 수집 간소화(Simplified Log Collection)
언어/프레임워크 독립성: Node.js, Java, Python 등 어떤 스택(Stack)이든 동일한 방식으로 로그 수집 가능
Docker Compose 템플릿: 로그 수집 설정을 재사용 가능한 구조로 만들어 설정 표준화(Configuration Standardization)
이러한 접근 방식은 로그 관리(Log Management)의 효율성을 높이고, 다양한 환경에서 일관된 로그 수집(Consistent Log Collection)을 가능하게 한다.
EC2에서 EKS로의 전환 전략
여기어때는 EC2 환경에서 EKS로의 전환을 장기적으로 추진하며, CI 표준화를 통해 전환 범위를 최소화하는 전략을 채택했다.
CI 표준화: EKS 전환 시 CD(Continuous Delivery) 부분만 변경하면 되도록 CI 파이프라인을 통일
GitLab CI 활용: 전사 배포 현황을 일관된 방식으로 파악하여 배포 관리 효율성(Deployment Management Efficiency)을 향상
플랫폼 레벨 관리 구조: 로그 수집, CI/CD 구조, 빌드 방식 등을 플랫폼 레벨에서 관리하여 운영 확장성(Operational Scalability) 확보
이러한 전략은 EKS 전환의 성공 가능성(Success Probability)을 높이고, 클라우드 네이티브(Cloud Native) 환경으로의 원활한 이행(Smooth Transition)을 지원한다.
