개인 서버 구축 3: Docker Compose로 앱을 격리 배포하는 CLI 프롬프트

/srv/my-service/
├── compose.yml
├── .env                 # 값은 commit 금지, chmod 600
├── config/              # 비밀이 아닌 설정
├── data/                # 필요할 때만 명시적 bind mount
└── backup/              # 실제 backup은 다른 장치에도 복제

이 Linux 개인 서버에 {{REPOSITORY}}를 Docker Compose로 배포할 계획과 파일을 만들어줘.

서비스: {{SERVICES}}
port: {{PORTS}}
영속 데이터: {{DATA}}
필요한 secret 이름: {{SECRETS}}
resource budget: {{RESOURCE_BUDGET}}
health check: {{HEALTH_CHECKS}}

작업 규칙:
1. 저장소 지침과 현재 Docker 설치 여부, OS version, architecture, disk 여유, RAM을 먼저 확인해. 기존 container·network·volume은 수정하지 마.
2. Docker Engine과 Compose plugin은 해당 OS의 공식 repository 절차를 사용해 설치 계획을 보여줘. production에 convenience script를 바로 실행하지 마.
3. `docker` group이 사실상 root 권한이라는 점을 설명하고, 운영 계정을 group에 추가할지 rootless mode를 쓸지 장단점을 보고한 뒤 선택을 받아.
4. image는 검증 가능한 version 또는 digest로 고정해. `latest`만 사용하거나 source를 매 배포마다 무검증 build하지 마.
5. compose file에 restart policy, healthcheck, logging rotation, resource 보호, read-only filesystem 가능성, least privilege user를 service별로 검토해.
6. web origin만 `127.0.0.1:{{WEB_PORT}}`처럼 bind해. DB·cache·management port는 host에 publish하지 말고 Compose 내부 network에서만 연결해.
7. Docker가 publish한 port는 ufw 규칙을 우회할 수 있으므로 `docker compose config` 결과와 `ss -lntup`에서 실제 bind address를 검증해.
8. secret 값은 compose file, Dockerfile, image layer, repository, shell history, 결과 보고서에 넣지 마. `.env.example`에는 이름과 설명만 두고 실제 `.env`는 권한과 ignore 여부를 확인해.
9. DB schema migration과 application 시작을 분리하고, backup·호환성·rollback이 없는 destructive migration은 실행하지 마.
10. 첫 배포 전 image pull/build, config validation, 예상 변경, 중단 방법을 보여주고 승인을 받아. 실행 후에는 health와 log 일부만 확인하고 secret을 마스킹해.
11. rollback은 직전 image version, compose config, DB 호환 범위, data 복구 여부를 포함해. `down -v`, volume 삭제, system prune은 실행하지 마.

결과는 '현재 host 점검 / service·network·volume 설계 / 보안 결정 / 생성 파일 diff / secret 주입 절차 / dry-run / 배포 / health 검증 / rollback / 다음 단계 origin 정보' 순서로 작성해.

docker version
docker compose version
docker compose config --quiet
docker compose images
docker compose ps
sudo ss -lntup