이미지 업데이트 후에만 컨테이너화된 앱의 시간대가 UTC로 되돌아가는 이유는 무엇인가요?
컨테이너화된 애플리케이션은 업데이트 후 새 이미지에서 시간대 데이터가 제거되거나, TZ를 무시하거나, 더 이상 호스트 시간대 마운트를 사용하지 않으면 UTC로 되돌아갈 수 있습니다.
호스트 시계가 올바르게 유지되더라도 애플리케이션이 UTC로 날짜를 표시할 수 있습니다. 컨테이너는 일반적으로 호스트 커널 시계를 공유하지만 자체 시간대 파일, 환경 및 언어 런타임 데이터를 갖기 때문입니다. 이미지 업데이트로 베이스 배포판이 변경되거나, tzdata애플리케이션 사용자를 변경하거나, 진입점을 교체하거나, 공급업체별 TZ 변수입니다. 호스트 시간대를 변경하기 전에 이전 이미지와 새 이미지를 비교하세요.
시스템 시계 시간과 시간대 형식 분리
이전 컨테이너와 새 컨테이너에서 UTC 시간, 현지 형식 시간, 시간대 이름, 숫자 오프셋, 애플리케이션 자체에 표시되는 시간을 기록하세요.
GNU C 라이브러리는 TZ 변수가 현지 시간 변환을 제어한다고 설명하며, 기본 시스템 시계는 절대 시간의 원천으로 유지됩니다.
에포크 시간이 일치하지만 형식이 지정된 시간대가 변경된다면, 문제는 시계 오차나 NTP가 아니라 시간대 설정입니다.
새 이미지에 여전히 tzdata가 포함되어 있는지 확인
설치된 패키지 비교 /usr/share/zoneinfo, /etc/localtime및 /etc/timezone 이전 이미지 태그와 현재 이미지 태그 사이
Debian의 tzdata 패키지는 애플리케이션이 UTC를 지역 현지 시간으로 변환할 때 사용하는 시간대 정의를 제공합니다.
최소 교체 이미지는 의도적으로 이 패키지를 제외할 수 있습니다. 파생 이미지에 설치하거나, 실행 중인 컨테이너를 수동으로 수정하는 대신 애플리케이션에서 지원하는 시간대 설정 방식을 사용하세요.
베이스 배포판이 TZ를 적용하는 방식 확인
이미지가 Debian, Ubuntu, Alpine, distroless 또는 다른 베이스인지 확인하세요. 이를 가정하지 마세요. TZ 모든 이미지에서 동일한 효과가 있습니다.
Alpine Linux는 tzdata 및 zoneinfo를 통한 시간대 설정을 문서화하고 있습니다.
업데이트로 기본 이미지가 변경되었다면 해당 배포판에서 지원하는 방법으로 시간대 설정을 다시 구성하세요. 이전 컨테이너에서 파일 하나만 복사하면 일광 절약 시간제 규칙이 오래된 상태로 남을 수 있습니다.
호스트 localtime 바인드 마운트 검사
재생성 전후에 실행 중인 컨테이너의 마운트를 비교하세요. 다음을 확인하세요. /etc/localtime 또는 zoneinfo 파일이 여전히 읽기 전용으로 마운트되어 있는지 확인하세요.
Docker 바인드 마운트는 호스트의 특정 파일 또는 디렉터리를 컨테이너에 매핑합니다. 공식 바인드 마운트 안내에서는 삭제된 Compose 마운트 또는 변경된 소스 경로로 인해 새 컨테이너가 이미지 기본값으로 돌아가는 이유를 설명합니다.
호스트 전체를 마운트하지 마세요 /etc 디렉터리. 애플리케이션에 필요한, 지원되는 범위가 좁은 파일 또는 명시적인 시간대 구성을 사용하세요.
애플리케이션 런타임 자체의 시간대 데이터베이스 확인
애플리케이션이 운영 체제의 zoneinfo 데이터베이스를 사용하는지, 아니면 Python, Java, PHP, Node.js 또는 다른 런타임 내부에 시간대 데이터를 포함하는지 확인하세요.
Python의 zoneinfo 모듈은 시스템 데이터 또는 tzdata 패키지를 검색합니다.
따라서 셸 명령에서 올바른 시간대가 표시되더라도 애플리케이션에는 UTC가 표시될 수 있습니다. 애플리케이션 런타임 동작은 컨테이너 셸과 별도로 비교하세요.
재생성 후 Compose 환경 변수 우선순위 확인
재생성된 컨테이너의 최종 환경을 검사하고 Compose 보간 결과와 비교하세요. 환경, env_file및 이미지 기본값
Red Hat의 컨테이너 문서에서는 런타임 구성이 이미지 환경을 재정의할 수 있다고 설명합니다. 따라서 업데이트된 이미지와 오래된 배포 파일을 함께 사용하면 예상과 다른 최종 값이 생성될 수 있습니다.
Compose 파일만 확인하지 말고 실제 컨테이너 환경을 읽어 보세요. 오래된 스택 UI나 다른 env 파일로 인해 의도한 시간대 변수를 적용하지 않은 상태에서 서비스가 재생성되었을 수 있습니다.
구성을 고정하고 다른 업데이트에서도 테스트하기
지원되는 시간대 방법 하나를 선택하고, 버전 관리되는 배포 구성에 고정한 다음 컨테이너를 재생성하고 해당되는 경우 겨울철 및 일광 절약 시간 날짜를 확인하세요.
컨테이너 작업 시간 및 환경에 관한 ZimaSpace 문서는 컨테이너 시간 설정을 변경할 때 일정이 바뀌는 경우에 대한 인접 진단 범위를 제공합니다.
재시작 후 애플리케이션, 셸, 로그 및 예약 작업이 의도한 시간대를 사용하고, 제어된 이미지 재생성 작업을 한 번 더 수행했을 때 문제가 해결됩니다.
자주 묻는 질문
컨테이너에 자체 하드웨어 시계가 있나요?
아니요. 일반적으로 호스트 커널 시계를 공유하지만, 서로 다른 시간대 데이터와 환경 설정을 사용해 해당 시간을 표시할 수 있습니다.
TZ를 설정하는 것만으로 항상 충분한가요?
아니요. 이미지와 애플리케이션이 해당 변수를 지원하고 시간대 규칙에 액세스할 수 있어야 합니다. 일부 런타임은 별도로 포함된 데이터베이스를 사용합니다.
컨테이너 하나를 수정하려고 NAS 호스트의 시간대를 변경해야 하나요?
아니요. 먼저 컨테이너 또는 애플리케이션 구성을 수정하세요. 호스트를 변경하면 로그, 일정 및 다른 모든 서비스에 영향을 줄 수 있습니다.
추천 제품
지원 및 팁
더 읽어보기
Docker 볼륨을 복원하면 파일 내용은 복원되지만 확장 속성은 사라지는 이유는 무엇인가요?
xattr 인벤토리, tar 및 Rsync 옵션, 네임스페이스, 대상 지원, 권한, 레이블, 앱 메타데이터와 테스트를 다루는 볼륨 복원 진단.
Compose 파일을 변경한 후에도 실행 중인 컨테이너의 메모리 제한이 기존 값으로 유지되는 이유는 무엇인가?
실행 중인 cgroup, 재시작과 재생성, Compose 필드, 하드 및 소프트 제한, 상위 범위, 스왑, 런타임 힙을 다루는 메모리 제한 진단입니다.
리버스 프록시를 재시작하면 셀프 호스팅 앱 하나의 모든 세션이 무효화되는 이유는 무엇인가요?
재시작 범위, 쿠키 소유권, 비밀 키 순환, 캐시 기반 세션, 스티키 라우팅, 인증 게이트웨이 및 복구를 다루는 세션 손실 진단.
