한눈에 보는 결론

별도 업데이트 컨테이너를 추가하지 않고, 각 호스트에서 systemd 타이머로 업데이트 스크립트를 실행하는 구성이 적합하다. 새 이미지가 확인되면 다이제스트로 고정해 받아오고, 게이트웨이만 교체한 뒤 상태를 점검한다. 실패하면 미리 로컬에 보관해 둔 이전 이미지로 되돌린다.

다만 이 설계는 무중단 배포가 아니다. 현재 게이트웨이는 단일 컨테이너를 재생성하므로 전환 중 연결이 끊길 수 있고, 진행 중인 요청이 보존된다고 보장할 수 없다. 원격 레지스트리 확인도 네트워크에 의존하므로 매번 1초 안에 끝난다고 약속하기 어렵다.

이번 결과물은 설계 초안과 구현 계약에 그친다. 업데이트 스크립트나 systemd 파일을 실제로 만들거나 테스트하지 않았으며, 두 대의 VPS에 접속해 상태를 확인하지도 않았다. 따라서 아래 내용은 검증 완료된 운영 절차가 아니라, 구현과 현장 확인을 거쳐야 하는 제안이다.

왜 업데이트 범위를 좁혀야 하나

프로젝트 설정을 보면 게이트웨이는 현재 Compose에서 소스 코드로 빌드되고, 로컬 8080 포트를 사용한다. 구성 디렉터리는 읽기 전용으로 마운트되며 이메일 서비스는 메모리 저장 방식을 쓴다. 따라서 업데이트 과정에서 이메일 컨테이너를 재시작하지 않는 것이 중요한 보호 조건이다. 관련 구성은 docker-compose.yml에 있다.

배포용 이미지의 시작점은 프로젝트 루트 진입점이며, 실행에는 로컬 모델 레지스트리 설정이 필요하다. 이미지에 그 설정 디렉터리가 포함돼 있지 않으므로, 원격 서버에는 이미지를 보내는 것만으로 충분하지 않다. 설정 파일도 별도로 준비해야 한다. (프로젝트의 Dockerfile, main.go 기준)

또한 현재 루트 진입점의 모델 목록 응답은 레지스트리 스냅샷을 읽을 뿐 실제 채팅 요청을 보내지 않는다. 건강 확인 엔드포인트도 정적 생존 여부를 반환한다. 그러므로 이 두 응답만으로 상위 서비스 계정 준비 상태나 실제 채팅 기능까지 정상이라고 단정할 수 없다. (프로젝트의 internal/api/models.go, internal/api/chat.go 기준)

프로젝트의 종료 처리에는 HTTP 서버를 닫는 5초의 대기 시간이 있다. 컨테이너의 종료 유예 시간만 늘려서는 장시간 스트리밍 요청이 끝까지 보존된다고 볼 수 없다. (프로젝트의 main.go 기준)

업데이트는 ‘태그 확인’과 ‘실행 이미지 고정’을 분리

릴리스 워크플로는 예를 들어 v3.12처럼 주 버전과 부 버전 형식의 태그를 받아 latest, 3.12, v3.12, 짧은 커밋 SHA 태그를 만든다. 자동으로 유지되는 v3.x 계열 별칭은 없다. 워크플로에 여러 아키텍처가 정의돼 있어도, 특정 릴리스가 실제로 각 아키텍처에서 성공했다는 뜻은 아니다. (프로젝트의 .github/workflows/build_docker.yml 기준)

업데이트기는 새 버전을 찾을 때 추적 태그를 확인하되, 실행할 때는 레지스트리 주소와 다이제스트를 결합한 이미지 참조를 사용한다. Compose는 이미지 주소에 태그뿐 아니라 다이제스트도 지정할 수 있다. 1

상태 기록에는 다중 아키텍처 인덱스 다이제스트, 플랫폼별 매니페스트 다이제스트, Docker의 로컬 이미지 ID를 구분해 둬야 한다. 서로 다른 종류의 값을 같은 것으로 간주하면 잘못된 변경 판정이나 복구가 일어날 수 있다.

실패를 전제로 한 업데이트 순서

업데이트·복구·초기화·정리 작업은 하나의 파일 잠금으로 직렬화한다. 이미 다른 작업이 실행 중이면 새 작업은 조용히 종료한다. 실행을 시작하면 우선 미완료 트랜잭션을 복구하고, 고정된 Compose 프로젝트명과 게이트웨이 컨테이너, 설정 지문, 이메일 컨테이너가 예상과 일치하는지 확인한다. 관리자가 수동으로 바꾼 흔적이 있으면 자동으로 덮어쓰지 않고 멈춘다.

그다음 원격 매니페스트를 확인해 새 다이제스트를 계산한다. 이 단계에서 이미지 레이어를 내려받지는 않는다. 네트워크·인증·파싱에 실패하면 기존 서비스는 그대로 둔다. 결과가 비어 있거나 잘못됐다고 이를 새 버전으로 취급해서는 안 된다.

다이제스트가 이미 승인된 버전과 같다면 다운로드, 컨테이너 재생성, 업데이트 기록을 남기지 않는다. 실패 이력이 있는 다이제스트도 반복 배포하지 않고 격리한다. 새 이미지라면 먼저 다운로드하고 로컬 플랫폼에서 사용할 수 있는지, 디스크 공간이 충분한지 확인한다. 이때까지 기존 게이트웨이는 계속 실행한다.

교체 전에 현재 실행 중인 이미지 ID를 확인해 로컬 보존 태그를 붙이고, 기존 서비스가 정상인지 점검한다. 트랜잭션 상태를 디스크에 기록한 뒤 게이트웨이 서비스만 재생성한다. Compose의 --no-deps, --no-build, --pull never 옵션은 의존 서비스를 시작하지 않고, 빌드하지 않으며, 전환 중 별도의 이미지를 당겨오지 않게 하는 데 쓰인다. 2

새 컨테이너의 이미지 식별자와 실행 상태, 애플리케이션 응답을 확인한 뒤에만 새 버전을 승인한다. 실패하면 네트워크에서 다시 이미지를 받아오지 않고, 보관한 로컬 이전 이미지로 게이트웨이만 복구한다. 복구까지 실패하면 자료를 보존하고 경고와 함께 실패로 끝내야 한다. 무한 재시작을 시도해서는 안 된다.

트랜잭션 상태는 엄격하게 파싱하고 실행하지 않는 데이터 형식으로 저장한다. 임시 파일 작성 후 원자적으로 교체하되, 파일 이름을 바꾸는 것만으로 전원 차단 시 데이터가 반드시 보존된다고 가정하지 않는다. 프로세스 강제 종료나 호스트 재부팅은 종료 처리 코드에만 맡길 수 없으므로, 다음 실행 때 저장된 미완료 트랜잭션부터 복구하도록 설계해야 한다.

건강 확인은 실제 서비스 보장과 구분

초기 설정 후보로는 총 60초 확인 창, 연결 제한 1초, 요청 제한 3초, 2초 간격 확인, 연속 3회 성공을 제안할 수 있다. 이는 검증된 수치가 아니라 현장에서 조정할 시작점이다.

점검에서는 로컬 모델 목록에 HTTP 200이 오는지, 응답이 기대하는 JSON 구조인지 확인한다. 리디렉션을 따라가거나 로그인 페이지·프록시 오류 페이지를 정상 응답으로 오인하지 않도록 한다. 컨테이너가 후보 이미지로 실행 중인지와 재시작 횟수가 계속 늘지 않는지도 확인한다.

모델 목록이 비어도 정상인지 여부는 현재 레지스트리 규약에 따라 정해야 한다. 과거의 특정 개수를 고정값으로 넣어서는 안 된다. 비용이 발생할 수 있는 실제 채팅 요청은 자동 건강 점검에서 제외하고, 업무 기능 검증은 별도 절차로 다룬다.

VPS 적용과 GHCR 인증

원격 배포용 Compose에서는 게이트웨이의 build 설정을 이미지 변수로 바꾸고, 이미지가 없을 때 Compose가 임의로 가져오지 않도록 설정할 수 있다. 예를 들면 image: "${APP_IMAGE:?이미지 참조가 필요합니다}", pull_policy: never 형태다. 이는 기존 전체 구성에 적용할 수정 지점이지, 서비스 전체를 대체하는 완성 파일은 아니다. 로컬 개발용 docker-compose.yml을 덮어쓰지 말고 원격 배포본만 바꿔야 한다. Compose에서 이미지 주소와 정책을 지정하는 방식은 문서에 설명돼 있다. 1

각 VPS에서는 기존 프로젝트명, 포트, 메모리 제한, 로그, 환경 변수, 읽기 전용 설정 마운트와 이메일 구성을 보존해야 한다. Compose의 변수 치환용 환경 파일이 컨테이너 내부 환경까지 자동으로 전달되는 것은 아니다. 프로젝트 구성에는 실험 기능 스위치도 있으므로, 로컬 설정을 원격의 실제 값으로 간주하거나 이번 작업에서 임의로 바꾸지 않아야 한다.

비공개 GHCR 이미지를 가져올 때는 해당 패키지를 읽을 권한이 있는 GitHub 개인 액세스 토큰(classic)이 필요하며, 최소 권한은 read:packages다. 조직에서 요구한다면 SSO 승인도 확인해야 한다. 업데이트 서버에 CI 쓰기 토큰이나 패키지 쓰기·삭제 권한을 배포할 이유는 없다. 9

각 VPS에 별도로 취소 가능한 읽기 전용 자격 증명을 두고, Docker 인증 설정은 업데이트기 전용의 관리자만 읽을 수 있는 위치에 보관하는 편이 안전하다. 토큰을 명령행 인수나 로그에 남기지 말고, 게이트웨이나 이메일 컨테이너에 전달하지 않는다. 인증에 실패해도 현재 실행 중인 서비스에는 손대지 않아야 한다.

systemd 예약 실행과 보관 정책

예약 실행은 systemd를 우선 선택한다. 예시 구성에서는 부팅 후 1분 뒤 시작하고, 작업이 끝난 뒤 5분이 지나면 다시 확인하도록 할 수 있다. 최대 30초의 무작위 지연을 더해 두 노드가 동시에 레지스트리에 접속하거나 동시에 업데이트를 시작할 가능성을 줄인다. 이 주기는 두 서버를 원자적으로 함께 바꾸는 기능이 아니다. 한 서버가 실패해 이전 버전을 유지하는 것은 잘못된 이미지를 억지로 재시도하는 것보다 안전하다.

기본 우선순위와 디스크 I/O 우선순위를 낮춰도 Docker 데몬의 이미지 압축 해제 부하까지 제한되는 것은 아니다. 저사양 서버에서 CPU·메모리·디스크 영향을 따로 확인해야 한다. 여기서 ‘조용한 실행’은 업데이트가 없을 때 스크립트가 불필요한 출력이나 업데이트 이력을 만들지 않는다는 뜻이다. systemd 자체의 작업 기록까지 사라지는 것은 아니다.

감사 기록에는 UTC 시각, 노드와 트랜잭션 식별자, 새·이전 다이제스트, 처리 단계, 소요 시간, 건강 확인 및 롤백 결과를 남긴다. 자격 증명, 전체 환경 변수, 이메일 계정, 응답 본문은 기록하지 않는다. 로그 주간 회전, 1MB 초과 시 조기 회전, 압축 후 26개 보관은 제안된 정책이며 호스트 전체 로그 정책을 바꾸는 내용은 아니다.

이미지 정리는 전체 Docker 이미지나 볼륨을 대상으로 해서는 안 된다. 업데이트기가 소유권을 기록한 이미지 중 현재 버전, 직전 정상 버전, 미완료 트랜잭션에 필요한 이미지는 보호한다. 다른 컨테이너가 참조하거나 다른 용도로 태그된 이미지도 제외한다. 예를 들어 14일이 지난 과거 이미지는 보존 태그를 제거한 뒤 강제하지 않는 삭제를 시도하고, 실패하면 남겨 두고 기록한다. 디스크가 부족하다는 이유로 유일한 복구 이미지를 지워서는 안 된다.

실제 배포 전 확인할 것

먼저 두 VPS의 CPU 아키텍처, Docker·Compose·Skopeo 등 도구 버전, 프로젝트명, 설정 마운트, 인증 파일 권한, 현재 정상 이미지를 확인하고 복구 기준점을 만들어야 한다. 이어 격리된 환경에서 업데이트·롤백·중단 복구를 연습한 뒤, 첫 서버에서 성공과 실패 복구를 확인하고 나서 두 번째 서버에 적용하는 순서가 안전하다.

필수 검증 항목은 다이제스트가 변하지 않았을 때 다운로드·재생성이 없는지, 성공과 롤백 전후 이메일 컨테이너 ID와 시작 시각 및 준비된 메일이 유지되는지, GHCR 연결을 끊어도 로컬 이미지로 되돌아가는지다. 트랜잭션 각 단계에서 업데이트기를 중단했을 때 다음 실행이 복구를 우선하는지, 인증 정보가 노출되지 않는지, 동시 실행과 이미지 정리가 보호 규칙을 지키는지도 확인해야 한다.

결론적으로 이 방식은 짧은 게이트웨이 전환 중단을 받아들이고, 공개 레지스트리 확인 속도는 보장 대신 현장 성능 목표로 다루며, 원격 구성을 먼저 검증한다는 조건에서 현실적인 선택이다. 무중단 전환이나 실제 서비스 전체의 정상 작동까지 필요하다면 이 설계만으로는 부족하며, 별도 인스턴스와 트래픽 전환·연결 배출 방안을 추가로 설계해야 한다.

한눈에 보는 결론

별도 업데이트 컨테이너를 추가하지 않고, 각 호스트에서 systemd 타이머로 업데이트 스크립트를 실행하는 구성이 적합하다. 새 이미지가 확인되면 다이제스트로 고정해 받아오고, 게이트웨이만 교체한 뒤 상태를 점검한다. 실패하면 미리 로컬에 보관해 둔 이전 이미지로 되돌린다.

다만 이 설계는 무중단 배포가 아니다. 현재 게이트웨이는 단일 컨테이너를 재생성하므로 전환 중 연결이 끊길 수 있고, 진행 중인 요청이 보존된다고 보장할 수 없다. 원격 레지스트리 확인도 네트워크에 의존하므로 매번 1초 안에 끝난다고 약속하기 어렵다.

이번 결과물은 설계 초안과 구현 계약에 그친다. 업데이트 스크립트나 systemd 파일을 실제로 만들거나 테스트하지 않았으며, 두 대의 VPS에 접속해 상태를 확인하지도 않았다. 따라서 아래 내용은 검증 완료된 운영 절차가 아니라, 구현과 현장 확인을 거쳐야 하는 제안이다.

왜 업데이트 범위를 좁혀야 하나

프로젝트 설정을 보면 게이트웨이는 현재 Compose에서 소스 코드로 빌드되고, 로컬 8080 포트를 사용한다. 구성 디렉터리는 읽기 전용으로 마운트되며 이메일 서비스는 메모리 저장 방식을 쓴다. 따라서 업데이트 과정에서 이메일 컨테이너를 재시작하지 않는 것이 중요한 보호 조건이다. 관련 구성은 docker-compose.yml에 있다.

배포용 이미지의 시작점은 프로젝트 루트 진입점이며, 실행에는 로컬 모델 레지스트리 설정이 필요하다. 이미지에 그 설정 디렉터리가 포함돼 있지 않으므로, 원격 서버에는 이미지를 보내는 것만으로 충분하지 않다. 설정 파일도 별도로 준비해야 한다. (프로젝트의 Dockerfile, main.go 기준)

또한 현재 루트 진입점의 모델 목록 응답은 레지스트리 스냅샷을 읽을 뿐 실제 채팅 요청을 보내지 않는다. 건강 확인 엔드포인트도 정적 생존 여부를 반환한다. 그러므로 이 두 응답만으로 상위 서비스 계정 준비 상태나 실제 채팅 기능까지 정상이라고 단정할 수 없다. (프로젝트의 internal/api/models.go, internal/api/chat.go 기준)

프로젝트의 종료 처리에는 HTTP 서버를 닫는 5초의 대기 시간이 있다. 컨테이너의 종료 유예 시간만 늘려서는 장시간 스트리밍 요청이 끝까지 보존된다고 볼 수 없다. (프로젝트의 main.go 기준)

업데이트는 ‘태그 확인’과 ‘실행 이미지 고정’을 분리

릴리스 워크플로는 예를 들어 v3.12처럼 주 버전과 부 버전 형식의 태그를 받아 latest, 3.12, v3.12, 짧은 커밋 SHA 태그를 만든다. 자동으로 유지되는 v3.x 계열 별칭은 없다. 워크플로에 여러 아키텍처가 정의돼 있어도, 특정 릴리스가 실제로 각 아키텍처에서 성공했다는 뜻은 아니다. (프로젝트의 .github/workflows/build_docker.yml 기준)

업데이트기는 새 버전을 찾을 때 추적 태그를 확인하되, 실행할 때는 레지스트리 주소와 다이제스트를 결합한 이미지 참조를 사용한다. Compose는 이미지 주소에 태그뿐 아니라 다이제스트도 지정할 수 있다. 1

상태 기록에는 다중 아키텍처 인덱스 다이제스트, 플랫폼별 매니페스트 다이제스트, Docker의 로컬 이미지 ID를 구분해 둬야 한다. 서로 다른 종류의 값을 같은 것으로 간주하면 잘못된 변경 판정이나 복구가 일어날 수 있다.

실패를 전제로 한 업데이트 순서

업데이트·복구·초기화·정리 작업은 하나의 파일 잠금으로 직렬화한다. 이미 다른 작업이 실행 중이면 새 작업은 조용히 종료한다. 실행을 시작하면 우선 미완료 트랜잭션을 복구하고, 고정된 Compose 프로젝트명과 게이트웨이 컨테이너, 설정 지문, 이메일 컨테이너가 예상과 일치하는지 확인한다. 관리자가 수동으로 바꾼 흔적이 있으면 자동으로 덮어쓰지 않고 멈춘다.

그다음 원격 매니페스트를 확인해 새 다이제스트를 계산한다. 이 단계에서 이미지 레이어를 내려받지는 않는다. 네트워크·인증·파싱에 실패하면 기존 서비스는 그대로 둔다. 결과가 비어 있거나 잘못됐다고 이를 새 버전으로 취급해서는 안 된다.

다이제스트가 이미 승인된 버전과 같다면 다운로드, 컨테이너 재생성, 업데이트 기록을 남기지 않는다. 실패 이력이 있는 다이제스트도 반복 배포하지 않고 격리한다. 새 이미지라면 먼저 다운로드하고 로컬 플랫폼에서 사용할 수 있는지, 디스크 공간이 충분한지 확인한다. 이때까지 기존 게이트웨이는 계속 실행한다.

교체 전에 현재 실행 중인 이미지 ID를 확인해 로컬 보존 태그를 붙이고, 기존 서비스가 정상인지 점검한다. 트랜잭션 상태를 디스크에 기록한 뒤 게이트웨이 서비스만 재생성한다. Compose의 --no-deps, --no-build, --pull never 옵션은 의존 서비스를 시작하지 않고, 빌드하지 않으며, 전환 중 별도의 이미지를 당겨오지 않게 하는 데 쓰인다. 2

새 컨테이너의 이미지 식별자와 실행 상태, 애플리케이션 응답을 확인한 뒤에만 새 버전을 승인한다. 실패하면 네트워크에서 다시 이미지를 받아오지 않고, 보관한 로컬 이전 이미지로 게이트웨이만 복구한다. 복구까지 실패하면 자료를 보존하고 경고와 함께 실패로 끝내야 한다. 무한 재시작을 시도해서는 안 된다.

트랜잭션 상태는 엄격하게 파싱하고 실행하지 않는 데이터 형식으로 저장한다. 임시 파일 작성 후 원자적으로 교체하되, 파일 이름을 바꾸는 것만으로 전원 차단 시 데이터가 반드시 보존된다고 가정하지 않는다. 프로세스 강제 종료나 호스트 재부팅은 종료 처리 코드에만 맡길 수 없으므로, 다음 실행 때 저장된 미완료 트랜잭션부터 복구하도록 설계해야 한다.

건강 확인은 실제 서비스 보장과 구분

초기 설정 후보로는 총 60초 확인 창, 연결 제한 1초, 요청 제한 3초, 2초 간격 확인, 연속 3회 성공을 제안할 수 있다. 이는 검증된 수치가 아니라 현장에서 조정할 시작점이다.

점검에서는 로컬 모델 목록에 HTTP 200이 오는지, 응답이 기대하는 JSON 구조인지 확인한다. 리디렉션을 따라가거나 로그인 페이지·프록시 오류 페이지를 정상 응답으로 오인하지 않도록 한다. 컨테이너가 후보 이미지로 실행 중인지와 재시작 횟수가 계속 늘지 않는지도 확인한다.

모델 목록이 비어도 정상인지 여부는 현재 레지스트리 규약에 따라 정해야 한다. 과거의 특정 개수를 고정값으로 넣어서는 안 된다. 비용이 발생할 수 있는 실제 채팅 요청은 자동 건강 점검에서 제외하고, 업무 기능 검증은 별도 절차로 다룬다.

VPS 적용과 GHCR 인증

원격 배포용 Compose에서는 게이트웨이의 build 설정을 이미지 변수로 바꾸고, 이미지가 없을 때 Compose가 임의로 가져오지 않도록 설정할 수 있다. 예를 들면 image: "${APP_IMAGE:?이미지 참조가 필요합니다}", pull_policy: never 형태다. 이는 기존 전체 구성에 적용할 수정 지점이지, 서비스 전체를 대체하는 완성 파일은 아니다. 로컬 개발용 docker-compose.yml을 덮어쓰지 말고 원격 배포본만 바꿔야 한다. Compose에서 이미지 주소와 정책을 지정하는 방식은 문서에 설명돼 있다. 1

각 VPS에서는 기존 프로젝트명, 포트, 메모리 제한, 로그, 환경 변수, 읽기 전용 설정 마운트와 이메일 구성을 보존해야 한다. Compose의 변수 치환용 환경 파일이 컨테이너 내부 환경까지 자동으로 전달되는 것은 아니다. 프로젝트 구성에는 실험 기능 스위치도 있으므로, 로컬 설정을 원격의 실제 값으로 간주하거나 이번 작업에서 임의로 바꾸지 않아야 한다.

비공개 GHCR 이미지를 가져올 때는 해당 패키지를 읽을 권한이 있는 GitHub 개인 액세스 토큰(classic)이 필요하며, 최소 권한은 read:packages다. 조직에서 요구한다면 SSO 승인도 확인해야 한다. 업데이트 서버에 CI 쓰기 토큰이나 패키지 쓰기·삭제 권한을 배포할 이유는 없다. 9

각 VPS에 별도로 취소 가능한 읽기 전용 자격 증명을 두고, Docker 인증 설정은 업데이트기 전용의 관리자만 읽을 수 있는 위치에 보관하는 편이 안전하다. 토큰을 명령행 인수나 로그에 남기지 말고, 게이트웨이나 이메일 컨테이너에 전달하지 않는다. 인증에 실패해도 현재 실행 중인 서비스에는 손대지 않아야 한다.

systemd 예약 실행과 보관 정책

예약 실행은 systemd를 우선 선택한다. 예시 구성에서는 부팅 후 1분 뒤 시작하고, 작업이 끝난 뒤 5분이 지나면 다시 확인하도록 할 수 있다. 최대 30초의 무작위 지연을 더해 두 노드가 동시에 레지스트리에 접속하거나 동시에 업데이트를 시작할 가능성을 줄인다. 이 주기는 두 서버를 원자적으로 함께 바꾸는 기능이 아니다. 한 서버가 실패해 이전 버전을 유지하는 것은 잘못된 이미지를 억지로 재시도하는 것보다 안전하다.

기본 우선순위와 디스크 I/O 우선순위를 낮춰도 Docker 데몬의 이미지 압축 해제 부하까지 제한되는 것은 아니다. 저사양 서버에서 CPU·메모리·디스크 영향을 따로 확인해야 한다. 여기서 ‘조용한 실행’은 업데이트가 없을 때 스크립트가 불필요한 출력이나 업데이트 이력을 만들지 않는다는 뜻이다. systemd 자체의 작업 기록까지 사라지는 것은 아니다.

감사 기록에는 UTC 시각, 노드와 트랜잭션 식별자, 새·이전 다이제스트, 처리 단계, 소요 시간, 건강 확인 및 롤백 결과를 남긴다. 자격 증명, 전체 환경 변수, 이메일 계정, 응답 본문은 기록하지 않는다. 로그 주간 회전, 1MB 초과 시 조기 회전, 압축 후 26개 보관은 제안된 정책이며 호스트 전체 로그 정책을 바꾸는 내용은 아니다.

이미지 정리는 전체 Docker 이미지나 볼륨을 대상으로 해서는 안 된다. 업데이트기가 소유권을 기록한 이미지 중 현재 버전, 직전 정상 버전, 미완료 트랜잭션에 필요한 이미지는 보호한다. 다른 컨테이너가 참조하거나 다른 용도로 태그된 이미지도 제외한다. 예를 들어 14일이 지난 과거 이미지는 보존 태그를 제거한 뒤 강제하지 않는 삭제를 시도하고, 실패하면 남겨 두고 기록한다. 디스크가 부족하다는 이유로 유일한 복구 이미지를 지워서는 안 된다.

실제 배포 전 확인할 것

먼저 두 VPS의 CPU 아키텍처, Docker·Compose·Skopeo 등 도구 버전, 프로젝트명, 설정 마운트, 인증 파일 권한, 현재 정상 이미지를 확인하고 복구 기준점을 만들어야 한다. 이어 격리된 환경에서 업데이트·롤백·중단 복구를 연습한 뒤, 첫 서버에서 성공과 실패 복구를 확인하고 나서 두 번째 서버에 적용하는 순서가 안전하다.

필수 검증 항목은 다이제스트가 변하지 않았을 때 다운로드·재생성이 없는지, 성공과 롤백 전후 이메일 컨테이너 ID와 시작 시각 및 준비된 메일이 유지되는지, GHCR 연결을 끊어도 로컬 이미지로 되돌아가는지다. 트랜잭션 각 단계에서 업데이트기를 중단했을 때 다음 실행이 복구를 우선하는지, 인증 정보가 노출되지 않는지, 동시 실행과 이미지 정리가 보호 규칙을 지키는지도 확인해야 한다.

결론적으로 이 방식은 짧은 게이트웨이 전환 중단을 받아들이고, 공개 레지스트리 확인 속도는 보장 대신 현장 성능 목표로 다루며, 원격 구성을 먼저 검증한다는 조건에서 현실적인 선택이다. 무중단 전환이나 실제 서비스 전체의 정상 작동까지 필요하다면 이 설계만으로는 부족하며, 별도 인스턴스와 트래픽 전환·연결 배출 방안을 추가로 설계해야 한다.