OCP 학습 1일차 · 컨테이너란 무엇인가?

학습 기준: OpenShift Container Platform(OCP) 4.20 · 참고 문서: Red Hat Enterprise Linux(RHEL) 9 · 실습 환경: Rocky Linux 9.8 / Podman 5.8.2 / ARM64 / root · 학습 시간: 20~30분

OCP를 배우기에 앞서 Podman으로 컨테이너 기초를 익힙니다. 오늘은 이미지와 컨테이너의 차이를 기존 WAS 설치 경험에 연결해 이해합니다.

오늘의 학습 목표

  • 이미지와 컨테이너의 차이를 설명합니다.
  • Red Hat Universal Base Image(UBI) 이미지로 컨테이너 내부 파일을 읽습니다.
  • 명령 종료 후 컨테이너가 목록에 보이지 않는 이유를 설명합니다.

1. 이미지와 컨테이너

JDK와 Tomcat을 설치하고 애플리케이션 파일을 준비해도 Tomcat 프로세스가 바로 실행되는 것은 아닙니다. 실행 명령이 필요합니다.

  • 이미지: 실행에 필요한 파일과 설정을 담은 준비물입니다. JDK, Tomcat, 애플리케이션을 함께 담도록 구성할 수 있습니다. 이는 구성 예시이며 모든 이미지가 같은 내용을 포함하지는 않습니다.
  • 컨테이너: 이미지에서 만들어지는 격리된 실행 환경과 프로세스를 다루는 단위입니다. 프로그램이 끝나면 컨테이너도 종료될 수 있습니다.
실행에 필요한 파일과 설정을 담은 이미지 하나에서 각각의 실행 프로세스와 쓰기 가능 계층을 가진 컨테이너 A와 B가 만들어지는 구조
이미지는 실행 준비물이며, 같은 이미지로 여러 컨테이너를 만들 수 있습니다.

2. 파일 하나 읽어 보기

Podman이 이미 설치된 개인 학습용 Linux에서만 따라 하세요. 환경이 없다면 예시를 읽으며 진행해도 됩니다.

podman run --rm registry.access.redhat.com/ubi9/ubi cat /etc/os-release
  • podman run: 새 컨테이너를 만들고 명령을 실행합니다.
  • --rm: 종료 후 이번 컨테이너를 삭제합니다.
  • registry.access.redhat.com/ubi9/ubi: 사용할 Red Hat UBI 9 이미지입니다.
  • cat /etc/os-release: 컨테이너 내부의 OS 식별 파일을 읽습니다.

로컬에 이미지가 없으면 다운로드될 수 있습니다. 컨테이너가 삭제되어도 로컬 이미지는 남을 수 있습니다.

실제 검증 결과 — 2026-11-01

맥미니의 VMware Fusion에서 실행한 학습용 Podman VM에서 위 명령을 검증했습니다. 이미지 다운로드와 컨테이너 실행은 종료 코드 0으로 성공했습니다.

준비 기록: 이번 VM에서는 Rocky 기본 저장소를 이용한 Podman 설치가 성공했습니다. 아래 실습은 Podman이 설치된 상태를 전제로 합니다.

아래는 실제 출력 중 주요 항목입니다. 전체 출력은 아니며, 이미지가 갱신되면 버전과 출력이 달라질 수 있습니다.

NAME="Red Hat Enterprise Linux"
VERSION="9.8 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.8"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.8 (Plow)"

이것은 컨테이너 내부 파일의 OS 식별 정보이며 호스트 운영체제가 변경된다는 뜻이 아닙니다. 이번에는 컨테이너를 실행한 VM의 게스트 OS는 Rocky Linux이고, 컨테이너 내부 사용자 공간(userland)은 RHEL로 식별됐습니다.

3. 종료와 삭제 확인하기

실행 중인 컨테이너만 확인하려면 다음 명령을 사용합니다.

podman ps

정지된 컨테이너까지 포함해 확인하려면 다음 명령을 사용합니다.

podman ps -a

앞의 cat 명령이 끝나면 컨테이너도 종료되고 --rm에 의해 삭제됩니다. 따라서 이번 컨테이너는 두 목록에 남지 않습니다. 다른 컨테이너가 있다면 해당 목록에 보일 수 있습니다.

실제 확인: 이번 VM에서는 실행 후 podman ps와 podman ps -a가 모두 헤더만 표시했고, 이미지 자체는 로컬에 남았습니다. 파일 출력과 종료 코드 0으로 실행 성공을 확인했으며, --rm 옵션과 두 목록의 결과를 함께 확인해 이번 컨테이너가 삭제됐음을 확인했습니다.

podman ps의 빈 목록만으로 실행 성공이나 삭제를 확정할 수는 없습니다. 정지된 컨테이너는 podman ps에 표시되지 않으므로 podman ps -a도 함께 확인합니다.

실패했을 때 확인할 것

  • command not found: Podman이 설치되어 있고 현재 셸에서 실행할 수 있는지 확인합니다.
  • 이미지 다운로드 실패: 표시된 실제 오류 메시지를 읽고 DNS 이름 해석과 인터넷 연결을 확인합니다.
  • 실행 성공 확인: 파일 출력과 확인 대상 명령의 종료 상태를 함께 확인합니다. 아래 명령은 위의 podman run 명령 직후, 다른 명령을 실행하기 전에 사용합니다. 0은 성공을 뜻합니다.
echo $?

환경 없이 학습했다면 이미지 이름, 내부 명령, 종료 후 목록에 보이지 않는 이유를 자신의 말로 설명해 보세요.

4. 확인 퀴즈

  1. 이미지만 준비하면 Tomcat이 실행 중일까요? 아닙니다. Tomcat을 시작하도록 구성된 컨테이너를 실행해야 합니다.
  2. podman ps에 없으면 장애일까요? 아닙니다. 정상 종료와 --rm의 결과일 수 있습니다.

한 줄 요약: 이미지는 준비물, 컨테이너는 실행 단위입니다.

다음 2일차에는 이미지 이름과 태그를 읽는 방법을 학습합니다.

공식 참고 문서

Read more

OCP 학습 5일차 · 노드와 역할: Control Plane·Worker

학습 기준: OpenShift Container Platform(OCP) 4.20 · 학습 시간: 20~30분 4일차에서는 OCP가 Kubernetes를 기반으로 한다는 관계를 확인했습니다. 오늘은 클러스터를 이루는 컴퓨터인 노드(node)를 역할별로 구분합니다. 오늘의 학습 목표 * Control Plane과 Worker의 역할을 구분합니다. * 노드 목록의 NAME·STATUS·ROLES를 읽습니다. * 노드가 Ready라는 사실과 애플리케이션 정상 동작을 구분합니다. 1.

By andre

OCP 학습 4일차 · Kubernetes와 OCP의 관계

학습 기준: OpenShift Container Platform(OCP) 4.20 · 학습 시간: 20~30분 3일차에서는 실제 Podman 환경에서 이미지를 가져오고, 같은 latest 태그가 다른 이미지 ID를 가리키는 변화를 확인했습니다. 오늘은 한 컴퓨터에서 이미지를 다루는 단계에서 여러 컴퓨터의 애플리케이션을 운영하는 단계로 시야를 넓힙니다. 오늘의 학습 목표 * Kubernetes와 OCP의 관계를 한 문장으로 설명합니다. * 이미지

By andre

OCP 학습 2일차 · 이미지 이름과 태그 읽기

오늘의 학습 목표 * 이미지 주소를 레지스트리·네임스페이스·저장소·태그로 나눠 읽습니다. * 같은 로컬 이미지에 이름을 추가하고 IMAGE ID를 비교합니다. * 태그와 digest의 차이를 설명합니다. 1. 이미지 주소 읽기 1일차에서는 이미지와 컨테이너를 구분했습니다. 오늘은 OpenShift Container Platform(OCP)을 배우기에 앞서 Podman으로 이미지 이름을 읽어 봅니다. registry.access.redhat.com/ubi9/ubi:

By andre