LabHub

패키지 관리 · apt 실전 · 이론

apt 는 무엇을 보고 판단하나

LabHub 에서 이어서 보기

한 줄 요약

apt 의 모든 판단은 로컬에 캐시된 저장소 색인에서 나온다. 색인이 낡으면 apt 는 낡은 세계를 본다.

왜 이게 필요했나

apt-get install nginx 를 쳤는데 "패키지를 찾을 수 없습니다" 가 나온다. 저장소에는 분명히 있다. 이때 십중팔구 원인은 apt-get update 를 안 한 것이다.

apt 는 설치할 때 저장소에 물어보지 않는다. /var/lib/apt/lists/ 에 받아 둔 색인 파일만 보고 의존성을 계산한 다음, 계산이 끝난 뒤에야 실제 .deb 를 내려받는다. 이 분리가 apt 를 빠르게 만들지만, 동시에 "저장소에는 있는데 안 보인다" 의 원인이 된다.

어떻게 동작하나

한 번의 설치는 네 단계다.

1. 색인 읽기/etc/apt/sources.listsources.list.d/*.list 에 적힌 저장소의 Packages 파일을 읽는다.
2. 후보 선정 — 같은 패키지가 여러 저장소에 있으면 핀 우선순위(priority) 로 고른다. apt-cache policy <패키지> 가 이 판단 결과를 그대로 보여 준다.
3. 의존성 해결 — Depends 와 Recommends 를 따라가며 설치 집합을 만든다.
4. 내려받기와 unpack/configure — dpkg 에게 넘긴다.

apt-cache policy 출력을 읽는 법이 핵심이다.

nginx:  Installed: (none)  Candidate: 1.24.0-2ubuntu7  Version table:     1.24.0-2ubuntu7 500        500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages

왼쪽 숫자가 버전, 오른쪽 숫자가 우선순위다. 기본값은 500 이고, 여기에 손을 대는 방법이 두 가지 있다.

둘은 목적이 다르다. hold 는 "지금 이 버전에서 멈춰" 이고, pin 은 "여러 저장소 중 이쪽을 봐" 다. 사내 미러와 공식 저장소를 함께 쓰는 환경에서는 pin 이 필수다.

현장에서 만나는 모습

쿠버네티스 노드의 kubelet. 클러스터 버전을 통제해야 하므로 apt-mark hold kubelet kubeadm kubectl 은 사실상 표준 절차다. 이걸 안 걸어 두면 어느 날 무심코 실행한 apt-get upgrade 가 노드 하나만 마이너 버전을 올려 버리고, 그 노드에서만 파드가 안 뜬다.

사내 미러의 배신. 사내 미러를 sources.list 에 추가했는데 여전히 공식 저장소에서 받아 온다. 우선순위가 같으면 apt 는 버전이 높은 쪽을 고르기 때문이다. 미러를 강제하려면 pin 을 걸어야 한다.

다음 실습에서 할 것

/opt/localrepo 오프라인 저장소를 상대로 검색·설치·제거를 하고, hold 와 pin 을 직접 걸어 apt-cache policy 출력이 어떻게 바뀌는지 확인한다.