[Troubleshooting Report] Harbor 서비스 관리 체계 개선

1. 개요 (Background)

프로젝트를 진행하면서 Harbor 서비스의 자동 재실행 문제를 해결하기 위해 초기 검토 했던 Systemd(OS 레벨 데몬) 등록 방식에 대해 기술적 한계 부분을 인식하였고, 왜 이 방식이 컨테이너 컨셉에 부적합한지 분석해보았다.

---

2. 왜 Systemd 방식은 비추천인가?

컨테이너 환경에서 Systemd를 통해 컨테이너를 관리하는 것은 다음과 같은 이유로 권장되지않는다.

① Coupling 문제

• 문제: Systemd에 등록하는 순간, 서비스는 특정 호스트 OS의 설정에 종속됨.
• 결과: 서버를 이전하거나 클라우드 환경으로 확장할 때 docker-compose.yml 파일 외에 OS의 /etc/systemd/system/ 설정까지 매번 수동으로 옮겨야 함. 이는 컨테이너의 핵심 가치인 어디서나 실행 가능(Run Anywhere)을 훼손함.

② 책임 소재의 역전: 관리는 Docker 엔진이

• 문제: 컨테이너의 생명 주기(시작, 정지, 재시작)는 Docker 엔진이 전담하도록 설계됨.
• 결과: Systemd와 Docker가 동시에 컨테이너 상태를 관리하려고 하면, 엔진 업데이트나 충돌 상황에서 누가 주도권을 가질지 모호해지며 시스템 복잡도만 상승함.

③ 컨테이너 철학 위배 : Self-healing

• 문제: Systemd 방식은 외부(OS)에서 강제로 살려주는 방식이다.
• 결과: 서비스 내부의 의존성(예: DB가 준비되지 않았는데 App이 뜨는 문제)을 해결하지 못한 채 억지로 프로세스만 띄우게 되어, 근본적인 서비스 무결성을 보장할 수 없다.

---

3. 기술적 비교 분석

비교 항목	Systemd 등록 (비추천)	Docker Native (권장)
관리 계층	L1: OS 레벨 (Infrastructure-centric)	L2: Container 레벨 (Service-centric)
의존성 관리	불가능 (단순 프로세스 실행)	가능 (Healthcheck 기반 순서 제어)
복구 방식	외부 강제 재시작 (Reactive)	내부 상태 감지 및 복구 (Proactive)
확장성	서버마다 개별 설정 필요	파일 하나로 무한 확장 가능

---

4. 대안

OS 데몬에 의존하지 않고, Docker의 고유 기능을 활용하여 서비스 스스로 생존하도록 구조를 개선하고자 한다.

1. Healthcheck 활용: 컨테이너 내부에 pg_isready 등 상태 확인 로직을 심어 Docker 엔진이 서비스의 "진짜 준비 상태"를 알게 함.
2. 의존성 제어(depends_on): 서비스 간 실행 순서를 OS가 아닌 Docker Compose 파일 내부에서 명시하여 자생적 복구 시나리오 완성.
3. Restart Policy: Docker 엔진의 restart: always 정책을 활용하여 엔진 재시작 시 자동으로 컨테이너가 복구되도록 설정.

---

5. 결론 

컨테이너 환경에서 발생하는 문제는 컨테이너 내부의 설정으로 해결해보기

이번 프로젝트를 통해 Harbor의 재실행 문제를 OS 데몬이 아닌 Docker Native 방식(Healthcheck + Depends_on)으로 해결함으로써, 인프라 환경 변화에 유연하게 대응할 수 있는 표준화된 운영 모델이 무엇일지 생각해보는 시간을 가질 수 있었다.