Docker
작은 서비스 자동 시작을 Compose와 systemd 중에서 고른 기준
컨테이너와 호스트의 재시작 책임을 나눈 비교 메모입니다.
선택 기준을 먼저 적었다
작은 VPS에서 컨테이너 자동 시작을 설정할 때 두 계층에 같은 책임을 주어 장애 원인이 흐려졌다. 내가 필요한 것은 재부팅 뒤 HTTP가 살아나는지와 로그를 어디서 볼지였다.
| 기준 | 컨테이너 재시작 정책 | systemd |
|---|---|---|
| 내부 프로세스 장애 | 간단하다 | 직접 설계한다 |
| 부팅 순서 | 제한적이다 | 명시하기 쉽다 |
| 로그 | 컨테이너 로그 | journal 로그 |
최종 구조
컨테이너의 생명주기는 Compose에, 부팅 시 실행은 systemd에 맡겼다. 유닛에는 작업 경로를 반드시 적었다.
[Service]
Type=oneshot
WorkingDirectory=/srv/blog
ExecStart=/usr/bin/docker compose up -d
RemainAfterExit=yes
적용 뒤에는 현재 SSH 세션을 닫기 전에 상태와 실제 응답을 확인했다.
sudo systemctl daemon-reload
sudo systemctl enable --now blog-compose.service
sudo systemctl status blog-compose.service
WorkingDirectory를 빼먹으면 수동 실행은 되는데 부팅 후 env 파일을 못 찾을 수 있다.
결정 전에 묻는 질문
- 재시작 책임이 두 곳에 겹치지 않는가
- 부팅 순서가 중요한가
- 장애 로그의 위치를 팀원이 아는가
- 재부팅 후 200 응답까지 확인했는가
설정이 짧은 것보다 책임 경계가 한 문장으로 설명되는 것이 더 오래 갔다.