홈 서버에서 PHP 기반 Docker 앱을 안전하게 업데이트하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Update PHP-Based Docker Apps on Your Home Server Safely - Zima Store Online

컨테이너 내부의 PHP 보안 패치는 보통 새로 빌드된 이미지를 통해 적용됩니다. 이미지를 다운로드하는 것과 실제 서비스에 적용하는 것은 별개의 단계입니다. 업데이트 계획에는 컨테이너가 종료된 뒤에도 남아 있는 데이터베이스와 영구 파일을 보호하는 방법도 포함해야 합니다.

이미지를 변경하기 전에 애플리케이션 데이터와 해당되는 경우 데이터베이스, 구성을 백업하세요. 지원되는 패치 버전을 가져와 서비스를 다시 만들고, 교체된 컨테이너를 검증한 다음 중요한 사용자 작업이 정상적으로 수행되는지 확인한 뒤 업데이트를 완료된 것으로 기록하세요.

1. 현재 배포 상태 기록하기

docker compose ps로 프로젝트 디렉터리와 서비스 이름을 확인하세요. docker compose images로 현재 이미지 태그와 이미지 ID를 기록하고, 영구 볼륨과 데이터베이스 상태가 저장된 위치도 확인하세요. 공유 로그에 비밀 정보가 노출되지 않도록 Compose 구성의 보호된 사본을 보관하세요.

대상 이미지의 릴리스 노트에서 PHP 수정 사항을 확인하세요. latest라는 태그는 특정 패치가 적용되었다는 증거가 아닙니다. 다이제스트를 고정해 사용한다면, 검증된 대체 다이제스트로 변경해야 합니다.

2. 일관성 있는 백업 만들기

애플리케이션에 문서화된 백업 방법을 사용하세요. 일관된 복구 시점의 구성, 파일, 데이터베이스 백업을 보존하세요. 애플리케이션에서 필요로 하는 경우 쓰기 작업을 중단하거나 유지보수 모드로 전환하세요. 실행 중인 데이터베이스 디렉터리를 파일 시스템에서 복사하는 것은 유효한 데이터베이스 백업을 대신할 수 있는 보편적인 방법이 아닙니다.

복구 사본은 애플리케이션이 쓰기 권한으로 접근할 수 없는 곳에 보관하고, 복원 방법을 숙지하세요. 이전 구성과 이미지 참조를 보존하되, 취약한 이전 이미지를 복원한 뒤 곧바로 공개 인터넷에 노출해서는 안 됩니다.

이미지 롤백으로 애플리케이션을 복원하지 못할 수 있는 이유는 무엇인가요?

컨테이너 이미지는 보통 실행 코드를 포함하고, 데이터베이스와 업로드된 파일은 영구 저장소에 보관됩니다. 업그레이드로 데이터베이스 스키마가 바뀌거나 애플리케이션 상태가 다시 작성될 수 있습니다. 이때 이전 이미지로 되돌리면 새 데이터에 이전 코드가 적용되어, 이미지가 시작되더라도 호환되지 않을 수 있습니다.

상태를 저장하는 앱이라면 지원되는 데이터베이스 내보내기 파일, 구성, 관련 애플리케이션 파일, 이전 아티팩트 참조를 함께 보관해 복구 세트를 갖추세요. Nextcloud의 백업 안내에는 해당 애플리케이션에 필요한 상태가 설명되어 있습니다. 다른 앱은 각기 다른 규칙을 따릅니다. 이미지 캐시만으로는 누락되거나 마이그레이션된 데이터를 복구할 수 없습니다.

3. 의도한 서비스를 가져와 재생성하기

관리자가 게시한 이미지를 사용하는 경우 서비스의 이미지 참조를 호환되는 고정 릴리스로 업데이트한 다음, 올바른 프로젝트 디렉터리에서 이 예제를 실행하세요. app을 PHP 애플리케이션 서비스 이름으로 바꾸세요.

docker compose pull app
docker compose up -d --no-deps app
docker compose ps
docker compose exec -T app php -v

Docker 문서에 따르면 pull은 이미지를 다운로드하지만 컨테이너를 시작하지 않으며, up은 이미지 또는 구성 변경 사항을 적용하기 위해 컨테이너를 재생성합니다. 여기서 --no-deps는 변경 범위를 선택한 서비스로 제한합니다. 종속 서비스가 이미 정상 작동하고 호환되는 경우에만 사용하세요.

직접 빌드하는 경우 관련 PHP 베이스 이미지나 패키지를 업데이트하고, 일반적인 빌드 파이프라인을 통해 다시 빌드한 뒤 결과 이미지를 배포하세요. 해당 런타임을 사용하는 워커에도 이 과정을 반복하세요. 임시 컨테이너 셸에서 패치하고 재생성 후에도 수정 사항이 유지될 것이라고 가정하지 마세요.

4. 접근을 다시 허용하기 전에 애플리케이션 검증하기

토큰이나 비공개 경로를 공유하지 말고 로컬에서 로그를 확인해 시작 오류를 살펴보세요. 웹 런타임을 확인한 다음 로그인, 파일 탐색, 소규모 업로드, 백그라운드 작업을 테스트하세요. 볼륨 경로와 소유권이 의도한 구성과 일치하는지 확인하세요.

외부 접근을 제한했다면 버전 및 기능 확인을 통과한 후에만 접근을 복구하세요. 컨테이너 상태가 정상이라고 해서 업로드나 백그라운드 작업이 작동한다고 단정할 수는 없습니다.

서버 전체를 테스트하지 않고 새 컨테이너를 어떻게 확인하나요?

교체, 런타임, 사용자 동작을 각각 별도로 확인하세요. 재생성 후 컨테이너 이미지 식별자를 기록하고, 올바른 서비스에서 런타임을 확인한 다음, 대표적인 핵심 작업을 하나 수행하세요. 파일 앱이라면 알려진 테스트 파일을 읽고, 업로드가 필수라면 삭제해도 되는 작은 파일을 업로드하세요. 데이터베이스 관련 오류는 간단한 랜딩 페이지에서는 나타나지 않을 수 있습니다.

실패	다음으로 확인할 사항
이전 이미지가 계속 실행 중	Compose 프로젝트, 서비스 선택 및 재생성
실행 환경이 변경된 뒤 앱에서 오류가 발생함	확장 기능, 호환성, 구성 및 마이그레이션
로그인은 되지만 업로드가 실패함	영구 마운트 권한, 저장 공간 및 업로드 설정
롤백이 시작되지만 데이터 오류가 계속 발생함	앱 안내에 따라 업그레이드 전 상태를 맞춰 복원

이미지 가져오기와 컨테이너 생성 또는 교체의 차이는 Docker 문서에 설명되어 있습니다. 결과를 실행 환경 식별 및 복구 가능한 사본 계획과 연계해 업데이트 기록이 셸 명령의 성공 여부만 보여 주는 데 그치지 않게 하세요.

5. 검증에 실패하면 신중하게 복구

조사하는 동안 서비스를 격리 상태로 유지하세요. 앱의 마이그레이션 규칙에 따라 필요한 경우 애플리케이션 파일과 데이터베이스 상태를 함께 복원하세요. 스키마를 업그레이드한 뒤 이미지만 변경하면 안전하지 않을 수 있습니다. 문제 해결을 위한 지름길로 docker compose down -v를 사용하지 마세요. 명명된 볼륨이 제거될 수 있습니다.

ZimaCube 2 사용자는 업데이트 기록을 대용량 파일과 분리하고 별도의 백업을 유지하세요. 업데이트가 성공적으로 완료되려면 실행 환경이 무엇인지 확인할 수 있고, 애플리케이션 기능이 작동하며, 여전히 설명할 수 있는 복구 경로가 있어야 합니다.

개인 저장 공간과 자체 호스팅 애플리케이션 환경을 위해 ZimaCube 2 개인용 클라우드 홈 NAS를 살펴보세요. 소프트웨어 보안은 설치된 서비스, 해당 서비스의 구성, 확인된 업데이트에 따라 달라집니다.