컨테이너로 복구 가능한 홈 어시스턴트 배포 환경을 구축하는 방법

복구 가능한 Home Assistant 컨테이너 배포에서는 컨테이너 이미지를 언제든 폐기할 수 있는 것으로 취급합니다. 실제 시스템은 상태, 구성, 비밀 정보, 장치 매핑, 네트워크 동작 및 복구 절차로 이루어집니다.

목표는 단순히 Docker가 Home Assistant를 다시 시작하게 하는 것이 아닙니다. 업데이트 실패, 디스크 손실 또는 호스트 교체 후 깨끗한 호스트에서 서비스를 다시 구축하고, 정해진 시간 안에 동일한 사용자, 통합 구성 요소, 자동화, 무선 장치, 데이터베이스 상태 및 네트워크 ID를 복구하는 것이 목표입니다.

영구 상태를 컨테이너 이미지 외부에 보관하기

Home Assistant 구성 디렉터리 전체를 호스트의 영구 스토리지에 마운트하고 숨김 디렉터리를 포함해 그 안의 모든 항목을 백업하세요. 운영자가 눈에 보이는 YAML 파일만 복사하고 UI에서 관리되는 엔티티, 통합 구성 요소 및 기타 상태가 저장된 .storage를 빠뜨려 커뮤니티 마이그레이션이 거듭 실패하고 있습니다. 한 컨테이너 마이그레이션 실패 사례는 셸의 글로빙으로 이러한 숨김 파일이 자신도 모르게 누락될 수 있음을 보여 줍니다.

Compose 파일, 환경 변수 템플릿, 시간대, 네트워크 모드, 장치 매핑, 바인드 마운트 경로, 필요한 그룹 권한을 버전 관리되는 인프라 문서에 기록하세요. 재현 가능한 빌드와 별도의 복구용 사본도 마련해 두지 않았다면, 특정 가정의 고유한 상태를 사용자 지정 이미지에 넣지 마세요.

ZimaSpace의 완전한 Home Assistant 서버 토폴로지는 더 폭넓은 패턴을 보여 줍니다. 제어 경로를 간소하게 유지하고, 영구 상태를 대용량 스토리지와 분리하며, 서비스 종속성을 추가하기 전에 복구 수단을 활성 장애 도메인 밖에 두세요.

자주 백업하는 것만큼 일관성 있게 백업하기

백업 파일이 특정 시점의 일관된 상태를 나타내야만 유용합니다. 간단한 로컬 SQLite 배포에서는 유지보수 시간에 서비스를 중지하고 영구 구성 볼륨을 복사하는 방식이 이해하기 쉽습니다. 외부 데이터베이스를 사용하는 경우에는 데이터베이스 일관성을 보장하는 방법으로 데이터베이스를 백업하고, 해당 백업이 어떤 Home Assistant 구성 백업과 짝을 이루는지 기록하세요.

최근의 Docker 볼륨 백업 워크플로는 아카이브 명령이 성공했다고 복구 가능성을 가정하는 대신, 복사본을 실제로 복원하는 것이 중요하다고 강조합니다. SSD, 파일 시스템 또는 실수로 실행한 정리 작업으로 서비스와 백업이 모두 사라지지 않도록 최소 한 세대의 백업은 Docker 호스트 외부에 보관하세요.

백업의 생성 시점, 애플리케이션 버전, 데이터베이스 버전, 크기, 체크섬, 암호화 키 위치 및 초기화된 호스트에서 복원하는 단계를 기록하세요. 복원 메타데이터 없이 보존 정책만 적용하면 복구 시스템이 아니라 압축 파일 더미만 쌓이게 됩니다.

Compose에서 종속성 및 준비 상태 모델링

Home Assistant가 MQTT, 외부 데이터베이스, 프록시 또는 다른 로컬 서비스에 의존하는 경우, 컨테이너의 시작 순서가 서비스 준비 상태와 같은 것은 아닙니다. 프로세스가 실행 중이어도 소켓, 스키마 또는 상태 엔드포인트를 아직 사용할 수 없을 수 있습니다. Compose 준비 상태 가이드에서는 상태 점검과 종속 조건으로 시작 시 경합을 줄이는 방법을 설명합니다.

각 종속 항목에 고유한 상태 신호와 장애 동작을 설정하세요. Home Assistant는 시작 중인 데이터베이스에 재시도해야 하지만, 반복해서 비정상 상태인 데이터베이스는 무한 재시작 뒤에 숨기지 말고 장애로 표시해야 합니다. 프로세스 종료 후 복구에는 재시작 정책을 사용하고, 서비스가 실제로 준비되었는지 판단하려면 상태 점검과 모니터링을 사용하세요.

가능한 한 선택적 서비스는 핵심 시작 체인 밖에 두세요. 대시보드 렌더러, 미디어 도구 또는 메트릭 익스포터가 고장 나더라도 자동화 컨트롤러가 오프라인 상태가 되어서는 안 됩니다.

Featured

ZimaBoard 2 - 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

변경 범위를 고정하고 롤백용 한 쌍 보존

업데이트 전에 현재 Home Assistant 이미지 태그, Compose 정의, 데이터베이스 버전, 구성 백업 및 시작 과정에 관여하는 모든 보조 서비스의 버전을 기록하세요. 한 번에 한 계층씩 변경하세요. 구성 또는 데이터베이스 마이그레이션으로 영구 상태가 변경된 후에는 컨테이너 이미지만 롤백하는 것이 안전하지 않을 수 있습니다.

주요 호스트 또는 데이터베이스 마이그레이션 전에 스테이징 복원 환경이나 복제된 복구 디렉터리에서 대상 버전을 테스트하세요. 이전의 정상 작동이 확인된 이미지와 업데이트 직전에 만든 상태 스냅샷을 한 쌍으로 보존하세요. 새 버전에서 자동화, 기록, 무선 장치, 대시보드, 알림 및 재시작 테스트를 통과한 후에만 해당 쌍을 삭제하세요.

더 최근의 Home Assistant Docker Compose 설계 문서에서는 네트워킹, 영구 스토리지 및 백업을 명시적인 배포 결정으로 다룹니다. 이것이 롤백에 적합한 모델입니다. 대체 컨테이너에 필요한 상태와 배포 정의를 보존하고, 폐기 가능한 컨테이너 파일 시스템 자체는 보존하지 마세요.

배포를 복구 가능하다고 판단하기 전에 초기화된 호스트에서 재구축하세요

예비 머신, VM 또는 격리된 테스트 디렉터리를 선택하고 실행 중인 컨테이너 파일 시스템의 파일을 읽지 않은 채 복구를 수행하세요. 컨테이너 런타임을 설치하고, Compose 정의 파일을 배치하고, 영구 상태를 복원하고, 시크릿을 다시 만들고, 안정적인 기기 경로로 라디오를 연결하고, 필요한 종속성을 시작한 다음 Home Assistant를 실행하세요.

백업 불량을 의심하기 전에 파일 소유권과 권한을 확인하세요. 마이그레이션 후 권한이 달라지면 데이터가 있어도 새 온보딩 화면이 표시될 수 있습니다. Docker 마이그레이션 복구 사례에서는 권한 문제와 숨겨진 상태가 각각 복원된 설치를 표시하지 못하게 하는 방식을 보여 줍니다.

1. 기존 관리자 계정으로 로그인하세요.
2. 통합, 엔티티, 자동화, 대시보드 및 기록을 검증하세요.
3. Zigbee, Z-Wave, Thread, Bluetooth 또는 기타 라디오의 소유권을 확인하세요.
4. 인터넷 연결을 끊고 중요한 로컬 자동화를 실행하세요.
5. 호스트와 필요한 모든 종속성을 다시 시작하세요.
6. 빈 호스트에서 가정 내 제어가 작동할 때까지 걸리는 총 복원 시간을 측정하세요.

컨테이너화된 모든 종속성에 복구 계약 적용

복구 가능한 배포에는 버전이 지정된 정의, 호스트 외부에 저장된 상태, 종속성 준비 상태, 롤백용 백업 쌍, 그리고 초기화된 호스트에서 정해진 시간 내에 복원하는 절차가 있습니다. 이러한 테스트를 통과하면 컨테이너는 대체 불가능한 반려동물이 아니라, 본래 그래야 하는 대체 가능한 런타임 단위가 됩니다.