Day-23 🐳 3계층 MERN 앱 Dockerizing 및 ITSM 도구 탐구

Source: Dev.to

오늘은 내 DevOps 여정에서 큰 도약을 이룬 날이었다. 컨테이너를 개별적으로 실행하던 방식을 버리고, 전체 3‑계층 MERN 애플리케이션( MongoDB, Express/Node, React )을 Docker화하는 작업에 도전했다.

🏗️ 프로젝트: 3‑계층 아키텍처

npm start 를 세 개의 터미널에서 각각 실행하는 대신, 전체 스택을 컨테이너화하고 싶었다.

• 프론트엔드: 컨테이너에서 실행되는 React
• 백엔드: Node.js/Express (API 레이어)
• 데이터베이스: MongoDB (영구 저장소)

🐙 Docker Compose 로 오케스트레이션

오늘의 진짜 게임 체인저는 Docker Compose 사용이었다. docker‑compose.yml 파일을 작성함으로써 세 개 컨테이너의 라이프사이클을 하나의 파일에 정의할 수 있었다.

• 클라이언트, 서버, 데이터베이스 각각에 대한 서비스 정의
• 서비스 이름을 호스트명으로 사용해 서로 통신할 수 있도록 네트워킹 설정
• 데이터 영속성을 위한 볼륨 구성

이제 전체 환경을 올리는 명령은 단 한 줄:

docker-compose up --build

🐛 “Gotcha” 순간

코딩 없는 하루는 없겠지. 로컬 환경에서는 모든 것이 완벽히 동작했지만, 컨테이너를 올리자마자 바이너리 호환성 오류가 발생했다.

문제는 COPY . . 명령이 로컬 Windows 기반 node_modules 를 Linux 컨테이너 안으로 복사해버린 것이었다. esbuild 등 일부 바이너리는 OS에 종속적이기 때문에, Linux 컨테이너는 Windows 바이너리를 실행할 수 없었다.

해결 방법

1. node_modules 와 .git 을 명시적으로 제외하도록 .dockerignore 파일을 생성
2. 손상된 이미지를 삭제
3. --no-cache 플래그를 사용해 완전히 새로운 이미지로 재빌드

구성을 업데이트한 뒤, 컨테이너 간 통신이 정상적으로 이루어졌다.

🏢 코드 외: ITSM 도구

빌드가 진행되는 동안 DevOps의 “프로세스” 측면을 배우기 위해 시간을 투자했다. 다음 도구들을 살펴보았다:

• Jira & Confluence: 작업 추적 및 문서화
• ServiceNow: 인시던트 관리(장애 대응)와 변경 관리(안전한 업데이트 배포)

이 도구들이 CI/CD 파이프라인에 어떻게 녹아드는지 이해하는 것은 기업 환경에서 일할 때 필수적이다.

🚀 다음은?

Docker Compose 를 정복했다. 이제 자연스러운 다음 단계는? 규모에 맞는 오케스트레이션이다. 내일부터 Kubernetes(K8s)를 파고들 예정이다. 오늘 배운 팟과 서비스가 어떻게 다른지 기대된다.

LinkedIn: