OCP 학습 3일차 · 이미지 레지스트리의 역할

학습 기준: OpenShift Container Platform(OCP) 4.20 · 참고 문서: Red Hat Enterprise Linux(RHEL) 9 · 학습 시간: 20~30분

공식 문서로 설명한 내용을 실제 VM에서 검증해 보완했습니다. 실습의 실제 실행 일시는 2026-11-02 19:25:41~19:26:43 KST이며, 아래에는 해당 실행 기록을 정리했습니다.

오늘의 학습 목표

• 레지스트리, 이미지 저장소, 로컬 이미지의 차이를 설명합니다.
• 이미지 주소를 보고 다운로드 출발지를 찾습니다.
• pull과 컨테이너 실행의 차이를 구분합니다.

1. 이미지는 어디에서 가져올까?

2일차에서는 이미지 이름과 태그를 읽었습니다. 오늘은 그 이미지가 어디에 보관되고 어떻게 내 컴퓨터로 오는지 살펴봅니다.

레지스트리(registry)는 컨테이너 이미지를 저장하고 배포하는 서비스입니다. 기술적으로는 이미지 레지스트리 API를 제공하는 서버입니다. 그 안의 이미지 저장소(repository)는 관련 이미지와 이를 식별하는 태그의 모음입니다. 다운로드한 이미지는 내 컴퓨터의 로컬 이미지 저장소에 보관됩니다.

레지스트리 → pull → 로컬 이미지 저장소
로컬 이미지 → 실행 → 컨테이너

기존 WAS 설치에 비유하면, 배포 파일을 받는 곳과 내려받은 파일, 실행 중인 프로그램을 구분하는 것과 비슷합니다.

registry.access.redhat.com/ubi9/ubi:latest

• 레지스트리: registry.access.redhat.com
• 저장소 경로: ubi9/ubi
• 태그: latest

UBI는 Red Hat Universal Base Image입니다. 이 예시의 레지스트리는 인증 없이 이미지를 받을 수 있습니다. 다른 레지스트리는 로그인과 접근 권한을 요구할 수 있습니다.

pull은 원격 이미지를 로컬로 가져오는 작업이고, push는 로컬 이미지를 레지스트리에 올리는 작업입니다. 오늘 실습은 가져오기만 다룹니다.

OCP는 외부 레지스트리의 이미지를 사용할 수 있고, Operator가 관리하는 내장 이미지 레지스트리도 제공합니다. 오늘은 OCP 설정에 들어가기 전에 개인 Podman 환경에서 이미지 가져오기 개념을 익힙니다.

2. 미니 실습: 가져오기와 실행 구분하기

실습 환경: Rocky Linux 9.8 (Blue Onyx) · aarch64(ARM64) · Podman 5.8.2 · rootful

다운로드는 로컬 디스크를 사용하고 이미지를 남깁니다. 업무 서버 대신 개인 학습 환경에서 진행하세요. 이번 검증에서는 이미지 가져오기와 목록 조회를 수행했으며, 컨테이너 실행·push·삭제·설정 변경은 하지 않았습니다.

먼저 로컬 이미지 확인하기

목적은 이미 내려받은 이미지를 살펴보는 것입니다.

podman images

이 목록은 원격 레지스트리 전체가 아니라 현재 로컬 저장소를 보여 줍니다. 기존 이미지가 있으면 목록에 나타나며, 없으면 헤더만 보일 수 있습니다.

실제 실행 결과 — pull 전 목록을 표로 재구성했습니다. 당시 두 항목의 CREATED는 5 days ago, SIZE는 236 MB였습니다.

두 태그가 같은 로컬 이미지 ID를 가리키는 상태에서 시작했습니다.

레지스트리에서 이미지 가져오기

podman pull \
  registry.access.redhat.com/ubi9/ubi:latest
echo $?

podman pull 뒤의 이미지 주소가 가져올 대상입니다. 줄 끝의 역슬래시(\)는 다음 줄까지 하나의 명령으로 이어 줍니다. 실제 검증에서는 pull을 한 줄로 실행했으며, 위 명령은 읽기 쉽게 줄만 나눈 것입니다.

echo $?는 바로 앞 pull 명령 직후 실행하여 종료 상태를 확인합니다. 이번 검증에서도 사이에 다른 명령을 실행하지 않았습니다. 중간에 다른 명령을 실행하면 그 명령의 상태가 표시됩니다.

실제 실행 결과 — pull 출력 중 주요 행입니다. 서명 처리 메시지 일부와 긴 이미지 ID의 뒷부분은 생략했습니다.

Trying to pull registry.access.redhat.com/ubi9/ubi:latest...
Copying blob e84ca6eccdfe done
Copying config abaa0dfc3a done
Writing manifest to image destination
Storing signatures
abaa0dfc3a2e…

바로 이어 실행한 echo $?의 실제 출력:

0

종료 상태 0으로 pull 성공을 확인했습니다. 마지막 이미지 ID는 로컬 이미지의 식별값이며 레지스트리 manifest digest와 같은 개념으로 해석하지 않습니다. 로그에서 blob과 config 복사 완료는 확인했지만, 이 기록만으로 네트워크 전송량이나 레이어별 캐시 사용 여부를 단정할 수는 없습니다.

이 명령은 이미지를 가져옵니다. 컨테이너나 애플리케이션을 실행하지는 않습니다.

로컬 저장 여부 확인하기

podman images

실제 실행 결과 — pull 후 목록입니다. 조회 명령도 종료 상태 0으로 완료됐으며, 원출력을 표로 재구성했습니다.

당시 latest 항목의 CREATED는 10 hours ago, day2는 5 days ago였고 SIZE는 둘 다 236 MB였습니다. CREATED는 로컬 다운로드 시각이 아니라 이미지 생성 시점에 관한 값입니다.

이번에는 latest가 가리키는 로컬 이미지 ID가 4df3d65a2ea5 → abaa0dfc3a2e로 바뀌었습니다. 반면 day2는 이전 이미지 ID를 유지했습니다. 같은 태그 이름으로 다시 pull해도 이미지 내용이 달라질 수 있다는 점을 실제로 관측한 사례입니다.

목록에서 REPOSITORY가 registry.access.redhat.com/ubi9/ubi, TAG가 latest인 항목을 찾습니다. ID, 생성 시각, 크기는 받은 이미지에 따라 달라집니다.

목록에 원래 있던 이미지만으로 이번 다운로드 성공을 단정하지 마세요. pull의 오류 여부와 직후 종료 상태, 로컬 목록을 함께 확인합니다. latest는 변경 가능한 태그이므로 다른 날 같은 내용을 보장하지 않습니다.

3. 실패하면 무엇을 확인할까?

• command not found: Podman 설치 여부를 확인합니다.
• 주소 해석 실패나 연결 시간 초과: 이미지 주소, DNS, 인터넷 연결을 확인합니다.
• 인증 또는 접근 거부: 지정한 레지스트리와 저장소의 접근 조건을 확인합니다.
• 이미지나 태그를 찾지 못함: 저장소 경로와 태그 철자를 공식 안내와 대조합니다.

인증서 오류를 해결하려고 TLS 검증을 끄지 마세요. 실제 오류 문구를 바탕으로 원인을 확인합니다.

4. 실습 환경이 없다면

위 이미지 주소에서 레지스트리·저장소·태그를 직접 표시해 보세요. 이어서 “원격 이미지 → 로컬 이미지 → 컨테이너”를 종이에 쓰고, 어느 화살표가 pull인지 설명해 봅니다.

5. 확인 문제

문제 1. podman images는 레지스트리에 있는 모든 이미지를 보여 줄까요?

아닙니다. 현재 로컬 저장소에 있는 이미지를 보여 줍니다.

문제 2. podman pull이 성공하면 애플리케이션도 실행 중일까요?

아닙니다. 이미지를 가져온 것이며, 컨테이너 실행은 별도 작업입니다.

문제 3. 같은 latest를 내일 받으면 오늘과 같은 이미지일까요?

보장되지 않습니다. 태그가 가리키는 이미지가 변경될 수 있습니다.

오늘의 세 줄 정리

• 레지스트리는 이미지를 저장하고 배포하는 서비스입니다.
• pull은 이미지를 로컬 저장소로 가져옵니다.
• 이미지를 받는 일과 컨테이너를 실행하는 일은 다릅니다.

다음 4일차에서는 Kubernetes와 OCP의 관계를 알아봅니다.

공식 참고 자료

• OCP 4.20: Registry — 용어와 내장 레지스트리
• RHEL 9: Working with container registries
• Podman: pull
• Podman: images