여기어때 Secret 플랫폼 구축기 Part 3: 시크릿 저장소를 운영 가능한 서비스로 만들기 - 컨테이너화부터 CI/CD, 로그 수집까지
핵심 내용
Bun 기반 Secrethub를 단일 번들, GitLab CI, Docker 로그 수집으로 운영 가능하게 했다.
자세히 보기
Secrethub를 Bun 위에서 운영 가능한 형태로 만들기 위해 빌드, 배포, 관측을 플랫폼 레벨에서 표준화했다.
bunfig.toml에서는 linker = "isolated"를 사용해 node_modules를 심볼릭 링크 없이 구성했다. 여기에 bun build를 적용해 TypeScript와 의존성을 단일 번들(dist/index.js) 로 만들고, 실행 이미지는 소스 코드와 node_modules 없이 결과물만 담도록 정리했다.
멀티 스테이지 Dockerfile도 같은 방향으로 구성했다. 빌드 스테이지에서 의존성 설치와 번들링을 끝내고, 실행 스테이지에는 dist/만 복사해 이미지 크기를 줄이고 런타임을 단순화했다.
CI/CD는 다음 흐름으로 정리했다.
- GitLab Push
- GitLab Runner에서 Lint / Build / Test
- 컨테이너 이미지 빌드 후 ECR push
- 배포 스크립트를 S3에 업로드
- CodeDeploy 트리거
- EC2에서
docker compose pull과up으로 갱신
기존 EC2 프로젝트들이 Jenkins 중심으로 서비스별 배포 스크립트를 따로 운영하던 구조와 달리, GitLab CI 공통 템플릿을 EC2에도 적용했다. CI 로직은 DevOps팀이 관리하고, 서비스는 프로젝트명과 ECR 이미지명 같은 최소한의 설정만 선언하도록 바꿔 배포 구조를 표준화했다.
CD는 CodeDeploy + Docker Compose 조합으로 구성했다. ApplicationStop은 실행 중인 컨테이너 종료에 쓰고, BeforeInstall은 설치 전 준비 작업에만 쓰도록 정리해 훅의 책임을 분리했다. 서버가 재부팅되거나 새 EC2 인스턴스로 교체돼도 배포 스크립트만으로 끝까지 복구되도록 운영 독립성도 높였다.
관측은 애플리케이션별 로깅 라이브러리 대신 Docker log를 Loki Driver로 직접 보내는 방식으로 선택했다. 하나의 EC2에서 여러 컨테이너가 함께 도는 환경에서는 언어/프레임워크에 상관없이 컨테이너 레벨에서 일관되게 수집하는 편이 낫고, Docker Compose 템플릿으로 표준화하기도 쉽다.
현재 여기어때의 EC2 서비스는 약 **40%**가 남아 있고, 장기적으로는 EKS 전환을 진행 중이다. 그래서 먼저 CI를 표준화해 두면 EKS로 옮길 때는 CD만 바꾸면 되고, Secrethub도 안정화 이후 공통 EKS 클러스터로 전환할 계획이다.
이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.