[seoyeoki]

개요

배포 워크플로(CI/CD Pipeline, deploy.yml)가 서버에서 docker compose up이 실패해도 Actions에는 성공으로 표시되고, 연달아 머지하면 배포가 동시에 실행되어 충돌하던 문제를 수정합니다. 2026-10-12에 #43, #45, #47을 머지했는데 운영에는 반영되지 않았고 Swagger 배포 일시가 바뀌지 않은 원인입니다.

Closes #48

원인

Actions 로그(7. EC2 접속 후 Docker 실행)에서 확인한 내용입니다.

배포 (머지)	로그	Actions 표시
#47	No space left on device (humix-ai-cpu 이미지 빌드 중) → failed to solve	success
#45, #43 (동시 실행)	Conflict. The container name "/0f7482c38e11_humix-backend-prod" is already in use	success

• 서버 접속 스크립트가 중간 실패에서 멈추지 않고, 마지막 명령(prune)이 항상 성공해서 단계 전체가 성공으로 끝남
• concurrency 설정이 없어 연달아 머지하면 같은 서버에 배포 두 건이 동시에 컨테이너를 교체

변경 사항 (.github/workflows/deploy.yml)

• concurrency 추가 (group: deploy-prod, cancel-in-progress: false)
  • 배포는 한 번에 하나만 실행. 진행 중인 배포는 끊지 않고, 대기 중이던 이전 실행은 최신 실행으로 대체되므로 마지막 커밋이 항상 반영됨
  • main과 develop 푸시는 둘 다 ENV_NAME=prod로 같은 서버에 배포하므로 그룹을 하나로 묶음
• 서버 쪽 docker compose up 실패가 단계 실패로 전달됨
  • 종료 코드를 저장해 두고 마지막에 exit로 반환. set -e를 추가해 cd 실패 등도 즉시 중단
  • 배포가 실패해도 prune은 그대로 실행해서 디스크를 비움 (단순히 set -e만 쓰면 실패 시 정리를 건너뛰어 다음 배포가 디스크 부족으로 막히기 쉬움)
  • prune 자체의 실패는 배포 결과에 영향을 주지 않도록 || true

영향 / 주의

• 머지하면 이 변경이 적용된 배포가 바로 실행됩니다. 서버 디스크 정리와 잔여 컨테이너 정리 전에 머지하면 그 배포는 이제 실패로 표시됩니다(의도된 동작). 서버 정리 후 머지하거나, 머지 후 정리하고 Run workflow로 다시 실행하세요.
• 이 PR은 서버 상태를 고치지 않습니다. 아래는 서버에서 직접 해야 합니다.
  • 디스크 확인·확보 (df -h /, docker system df). 도커 캐시·이미지 정리로 회수된 용량이 약 750MB뿐이라 다른 원인을 찾아야 함. DB 볼륨이 있을 수 있어 docker volume prune, docker system prune --volumes는 사용하지 않음
  • 0f7482c38e11_humix-backend-prod 컨테이너가 현재 서비스 중인지 docker ps -a로 확인한 뒤 정리
  • 정리 후 CI/CD Pipeline 수동 실행으로 [Bug] 생성·구간 재생성 요청 API가 HTTP 202로 응답하도록 수정 (#38) #43, [Bug] 구간 재생성 반복 시 곡 이름이 30자를 넘어 500이 나는 문제 수정 (#44) #45, [Feat] SSE complete 결과에 root_generation_id 추가 (#46) #47 반영

범위 외

• 매 배포마다 AI 서버 이미지(humix-ai-cpu)까지 처음부터 다시 빌드해 디스크를 크게 쓰는 문제 (서버 디스크 크기 확인 후 별도 검토)
• develop 푸시가 운영에 배포되는 점, @master로 고정된 액션 버전

테스트

• deploy.yml YAML 문법 검증 (Ruby YAML 파서), 단계 7 스크립트 sh -n 문법 검사
• 가짜 docker 명령으로 스크립트 동작 검증 (종료 코드 / prune 실행 횟수)

시나리오	종료 코드	prune 실행
배포 성공	0	2
up 실패(17)	17 (기존 스크립트는 0)	2
배포 성공 + prune 실패	0	2
docker compose 없음 → docker-compose 성공	0	2
docker-compose 실패(5)	5	2

• 실제 GitHub Actions 환경과 EC2에서 실행하는 것은 확인하지 못했습니다. concurrency의 대기·대체 동작은 GitHub 문서 기준이고, 머지 후 연달아 머지해 확인이 필요합니다.

🤖 Generated with Claude Code

[seohyun27]

develop는 사용이 없어서 CICD 범위에서 제외했습니다

[seohyun27]

서버 쪽 조치 완료했습니다.

원인

• 연속 배포 충돌로 Created 상태 컨테이너가 남아 이후 배포가 이름 충돌로 실패
• 디스크 8GB 중 여유 1.2GB로 이미지 빌드 공간 부족

조치

• 배포 충돌로 꼬인 컨테이너 정리
• DB 초기화 (PR [Feat] 음악 버전 목록 조회·되돌리기 API 추가 (#26) #40 스키마 변경 반영, 백업은 서버 ~/backup_20261014.sql)
• 디스크 부족 해결 (이미지 정리, EBS 8→20GB, 스왑 2GB 추가)
• 서버에서 docker-compose로 수동 배포

확인 결과

• 백엔드·AI 서버 컨테이너 재생성 및 Started ApiApplication 확인
• DB 테이블 4개 자동 생성 확인 (humming, melody_score, member, music_generation)
• 디스크 여유 14GB