태그가 말해 주지 않는 베이스

런타임 이미지를 네 버전 쓰고 있었는데 그중 일부에서 패키지 갱신이 실패하기 시작했다. 같은 계열 이미지인데 어떤 버전은 되고 어떤 버전은 안 되는 상황이었다.

Open Table of contents

증상 — 네 버전의 갱신 실패

실패하는 것과 되는 것의 차이를 보려고 각 Docker 이미지 안으로 들어가서 베이스가 무엇인지 확인했다. 이미지 태그에는 런타임 버전만 적혀 있고 베이스에 대한 정보는 없었다.

확인해 보니 버전마다 베이스 배포판이 달랐다. 각 이미지의 Dockerfile 이 만들어질 당시의 안정판을 베이스로 삼았기 때문에 오래된 버전일수록 오래된 배포판을 깔고 있었다.

실패하는 두 버전의 베이스는 이미 지원이 끝난 배포판이었다. 지원이 끝나면 기본 저장소에서 패키지가 내려가므로 갱신이 실패한다.

되는 두 버전은 아직 지원 중인 배포판이라 아무 문제가 없었다. 같은 계열 이미지라는 것이 같은 베이스라는 뜻이 아니었다.

지원이 끝난 쪽은 Dockerfile 에서 저장소 주소를 아카이브로 바꿔서 해결했는데 그 과정에서 다른 것을 하나 더 발견했다. 베이스를 명시한 태그를 쓰면 되겠다고 생각해서 이름에 배포판을 붙였는데 그 이름이 내가 생각한 배포판이 아니었다.

docker build 는 정상으로 끝나므로 틀렸다는 것이 드러나지 않는다. 그래서 태그를 바꾼 뒤에도 실제로 어떤 베이스가 들어갔는지를 이미지 안에서 확인했다.

아카이브로 바꾸는 처리를 네 버전 전부에 넣지는 않았다. 지원 중인 배포판에까지 넣으면 나중에 그 주소가 바뀌었을 때 멀쩡하던 것이 깨진다.

더 오래된 배포판은 저장소 목록 파일의 형식 자체가 달라서 같은 방식이 안 먹혔다. 형식별로 나누는 대신 베이스를 명시한 태그로 맞추는 방법도 있어서 그쪽을 함께 검토했다.

이 구조는 이 런타임만의 것이 아니라 언어 런타임 공식 Docker 이미지 대부분이 같았다. 만들어진 시점의 안정판을 베이스로 삼으니 구버전은 자연히 오래된 배포판을 쓴다.

그러니 구버전을 계속 쓰면 언젠가 베이스의 지원이 끝난다는 것이 정해져 있다. 이것은 미리 알 수 있으므로 베이스 배포판의 지원 종료 일자를 확인해 두는 것을 규칙으로 넣었다.