관리용 컨테이너에 특정 버전의 데이터베이스 클라이언트를 넣어야 했다. 기반 이미지는 ubuntu:22.04 인데 그 버전은 벤더의 apt 저장소에서 가져와야 하는 상황이었다.
Table of contents
Open Table of contents
배경 — 없는 계열과 안 맞는 라이브러리
벤더 저장소의 dists/ 를 확인하니 jammy 가 아예 없었다. 바로 이전 안정 계열도 요청하면 응답이 없었다. 그보다 더 옛날 focal 에는 원하는 최신 패치 버전이 있어서 설치를 시도했다.
그런데 그 계열 패키지는 libssl1.1 에 의존하고 기반 이미지에는 libssl3 만 있어서 설치가 깨졌다. 결국 남은 것이 unstable 계열이었다. 버전은 조금 낮지만 libssl3 로 빌드돼 있어 호환됐다.
검증 — 실측을 붙인 답변
불안정 계열을 쓴다고 했더니 왜 그것을 쓰느냐와 바로 이전 안정 계열을 찾아보라는 지적이 왔다. 이름 그대로 불안정하므로 맞는 지적이었다.
찾아봤다고 말로 답하는 대신 docker run --rm 일회용 컨테이너로 각 계열을 실제로 시도해 apt-get install 출력을 붙였다. 한쪽은 저장소 자체가 없고 다른 쪽은 저장소는 있으나 설치 시 라이브러리가 안 맞았다. 실측 결과로 보이고 나서야 배제가 근거를 가졌다.
조치 — 출처로 건 핀
불안정 계열을 쓰되 그것이 시스템 전체로 번지면 안 됐다. 핀은 두 가지 방법이 있었는데 Pin: release a=unstable 로 계열에 거는 것과 Pin: origin 으로 벤더 호스트에 거는 것이다. 뒤쪽을 골랐다. 이유는 apt_preferences 매뉴얼대로 origin 핀은 그 호스트에서 오는 버전에만 우선순위를 줘서다. release a= 핀은 그 아카이브의 모든 패키지에 걸린다. 대신 벤더 호스트 이름이 바뀌면 /etc/apt/preferences.d/ 도 같이 고쳐야 하는 것을 감수했다.
계열로 걸면 그 계열의 모든 패키지가 우선돼 시스템 라이브러리까지 불안정 계열 것이 온다. 출처로 걸면 그 저장소에서 오는 패키지만 우선되므로 데이터베이스 클라이언트만 그쪽에서 오고 나머지는 기반 저장소 것을 쓴다.
주의 — 영향 범위로 버린 대안
기반 이미지를 ubuntu:20.04 로 내리는 대안도 있었고 그러면 focal 계열의 최신 버전을 그대로 쓸 수 있었다. 그렇게 하지 않았다.
이 컨테이너에는 다른 도구들도 들어 있어서 기반을 내리면 그것들이 전부 영향을 받는다. 하나를 위해 전부를 희생하는 것이므로 영향 범위가 큰 쪽은 안 건드리기로 했다.
원인 — 문서에 남긴 교환
최종 결정을 채택한 것과 그 이유와 비용과 배제한 것과 그 이유로 나눠 DECISIONS.md 에 기록했다. 불안정 계열에 출처 한정 핀을 건 것을 채택하고 기반 이미지 교체는 영향 범위 때문에 배제했다.
버전이 조금 낮다는 비용도 함께 적었다. 왜 불안정 계열을 썼느냐는 질문에 대한 답이 문서에 있으므로 같은 지적이 다시 와도 그 문서를 보면 된다.
정리
- 벤더 저장소에 최신 배포판 계열이 없을 수 있다
- 옛 계열은 있어도 라이브러리 계열이 안 맞아 설치가 깨진다
- 불안정 계열이 유일한 경로면 출처 한정 핀으로 번짐을 막는다
- 핀을 계열이 아니라 출처로 걸어 대상을 좁게 잡는다
- 대안이 영향 범위가 크면 쓰지 않는다
- 찾아봤는데 없다가 아니라 실측 결과를 붙여 답한다
- 교환과 배제 이유를 문서에 남긴다
- 같은 지적이 다시 왔을 때 그 문서를 가리키면 된다