[에스넷시스템 부트캠프] TIL Day 27 - Docker

1. Docker

• 컨테이너 기반의 오픈소스 가상화 플랫폼 
• 가상머신처럼 독립적으로 실행되지만 가상머신보다 빠르고 쉬우며 효율적
• 컨테이너라는 격리된 환경에서 작동하는 프로세스 단위로 실행

1) VM vs Docker

https://www.docker.com/blog/containers-and-vms-together/

항목	Virtual Machine	Docker
실행 구조	Hypervisor + Guest OS	Docker Engine
운영체제	Guest OS 필요	Host OS 공유
성능	하드웨어를 깊게 활용 가능	가볍고 빠름
사용 목적	강한 격리, 복잡한 OS 환경	빠른 배포, 일관된 환경 제공

 

2) 도커의 특징

• 확장성/이식성 : 도커가 설치되어 있다면 어디서든 컨테이너 실행이 가능
• 표준성 : 컨테이너라는 표준으로 서버를 배포하므로 모든 서비스들의 배포 과정이 동일
• 이미지 : 빌드 서버에서 Dockerfile로 이미지를 만들어 이미지 저장소에 저장하고 운영서버에서 이미지를 불러옴
• 설정 관리 : 컨테이너를 띄울 때 환경 변수를 같이 지정
• 자원 관리 : 컨테이너 삭제 후 새로 만들면 모든 데이터가 초기화돼 세션이나 캐시를 외부로 분리해야 함
• 빌드 기록 : 이미지 빌드 기록이 남아서 버전 관리가 편함
• 성능 저하 없음 : 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능저하가 거의 없음
• 오픈소스 : 특정 회사 기술에 종속적이지 않음
• 러닝 커브 낮음 : 복잡한 기술을 몰라도 사용 가능

 

💡 Docker는 소프트웨어 패키징과 배포 방식의 혁신을 가져왔지만,
서버 운영이나 클러스터링 자체의 혁신은 Kubernetes 영역에 가깝다. 

 

 

3) Kubernetes

• 여러 개의 컨테이너와 서버를 클러스터 단위로 자동 관리하는 플랫폼
• 주요 기능
  • 오케스트레이션: 여러 개별 작업들을 구성 요소를 자동으로 연결하고 조정하며 전체 시스템이 사용자가 원하는대로 작동하도록 만드는 작업
  • 스케줄링: 컨테이너를 적절한 서버에 배치
  • 클러스터링: 여러 서버를 하나처럼 묶어 관리
  • 서비스 디스커버리: 컨테이너 간 네트워크 탐색 지원

 

2. 컨테이너 실행 명령어

🔁 RHEL 8 이후 기본 컨테이너 런타임은 Docker에서 Podman으로 변경
→ Podman은 데몬리스 구조로 동작하며 OCI 표준을 따름

docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

• -d : 백그라운드로 실행
• -p : 호스트와 컨테이너의 포트를 연결
• -v : 호스트와 컨테이너의 디렉토리를 연결
• Z : SELinux가 활성화된 시스템에서 컨텍스트 설정 (보안 격리용)
• -e : 컨테이너 내에서 사용할 환경변수 설정
• --name : 컨테이너 이름 설정
• --rm : 프로세스 종료시 컨테이너 자동 제거
• -it : -i와 -t, 터미널 입력을 위한 옵션
• --network : 네트워크 연결 

 

3. 도커 이미지

• 컨테이너 실행을 위한 레이어 기반 파일 시스템
• 읽기 전용 + 레이어 캐싱 구조 → 빌드 최적화
• 기본 스토리지 드라이버: AUFS, OverlayFS, Btrfs

 

 

1) Dockerfile 주요 명령어

• FROM : 기본 이미지
• RUN : 쉘 명령어 실행
• CMD : 컨테이너 기본 실행 명령어
• EXPOSE : 오픈되는 포트 정보
• ENV :  환경 변수 설정
• ADD :  파일 또는 디렉토리 추가. URL/ZIP 사용 가능
• COPY :  파일 또는 디렉토리 추가
• ENTRYPOINT :  컨테이너 기본 실행 명령어

 

2) 이미지 빌드

docker build -t [이름공간]/[이미지이름]:[태그] .

 

. 은 현재 디렉토리를 빌드 컨텍스트로 사용

 

4. 컨테이너

1) 컨테이너 런타임이란?

• 컨테이너를 구성, 실행 및 관리할 수 있도록 해주는 핵심 소프트웨어
• 하이퍼바이저처럼 컨테이너 자원을 생성 및 구성 그리고 관리하는 것이 주요 목적
• 하이퍼바이저와는 달리 커널을 공유하며 동작

 

2) 런타임 소프트웨어

런타임 특징 Kubernetes 지원

런타임	특징	Kubernetes 지원
Docker	가장 대중적, 도구 생태계 풍부	✅
Podman	데몬리스, Docker 대체 가능, pod 기능 기본 내장	✅ (간접적으로 CRI-O와 호환)
CRI-O	Kubernetes CRI 전용, 가볍고 빠름, Podman과 유사	✅
Containerd	Docker에서 분리된 런타임, 복잡하지만 강력	✅
LXC/LXD	Ubuntu 계열, VM처럼 부팅, 쿠버네티스 미지원	❌

 

 

3) 컨테이너 기술의 역사와 발전 과정 시작

• 초기 시도
  • IBM System Z, AIX, BSD의 Jail, 리눅스의 VServer
  • 목적: 사용자 공간 단위의 격리
• Linux 커널 기반 발전
  • cgroups: CPU, 메모리 등 자원 제한
  • namespaces: PID, 네트워크, 파일시스템 등 격리
  • LXC(Linux Container): 최초의 완전한 리눅스 컨테이너 구현
  • → 그러나 보안/유연성에 한계
• 보안 강화
  • SELinux: 강제 접근 제어(MAC)
  • Seccomp: 시스템 콜 제한
• 기업 및 커뮤니티 동향
  • Google → Borg → Kubernetes
  • RedHat → Kubernetes 기반 OpenShift
  • Docker 등장으로 대중화 시작
  • RHEL에서는 Docker를 대체하기 위해 Podman, CRI-O 중심의 Atomic 프로젝트 전개

 

 

4) 컨테이너 격리를 위한 커널 기술 (RHEL 7 기준)

• mnt : 마운트 연결 지점
• pid : 독립적인 프로세스 테이블
• net : 네트워크 리소스, 라우팅 및 아이피 정보
• ipc : 프로세스간 서로 메모리 공유 방지
• uts : 호스트 및 도메인 이름
• usr : 컨테이너 및 호스트간 uid 매핑
• cgrp : 시스템의 cgroup을 컨테이너에게 숨김

 

5. [실습] podman 설치해보기

1) 도커 데스크탑

컨테이너화된 애플리케이션 및 마이크로서비스를 구축하고 공유할 수 있는 Mac, Linux, Windows 환경용 원클릭 설치 애플리케이션이다. 

 

1-1) 도커 데스크탑에 포함된 서비스 

• 도커 엔진
• 도커 CLI 클라이언트
• 도커 빌드X
• 확장 프로그램
• 도커 컴포즈
• 도커 콘텐츠 신뢰
• 쿠버네티스
• 자격 증명 도우미

 

1-2) 주요 기능

• 여러 언어 및 프레임워크로 모든 클라우드 플랫폼에서 모든 애플리케이션을 컨테이너화하고 공유할 수 있는 기능
• 완전한 Docker 개발 환경의 빠른 설치 및 설정
• 최신 버전의 Kubernetes 포함
• 기본 Windows Hyper-V 가상화를 통한 빠르고 안정적인 성능
• Windows 컴퓨터에서 WSL 2를 통해 Linux에서 기본적으로 작업 

 

2) podman 설치

 

 

6. 컨테이너 런타임 구조와 탈 Docker 흐름 정리

1) 저 수준 컨테이너 런타임

• 컨테이너는 linux namespace + cgroup으로 구성
  • namespace : 각 컨테이너의 파일 시스템, 네트워크 등 시스템 리소스 가상화로 격리된 공간 제공
  • cgroup : 각 컨테이너의 CPU 및 MEM 리소스 사용량 제한

 

2) 고 수준 컨테이너 런타임

저수준 런타임 위에서 동작하며, 컨테이너를 논리적으로 관리하고 API, 데몬 등을 제공하는 계층이다. 

ex) Docker, Containerd, CRI-O, Podman 

 

3) CRI (Container Runtime Interface)

• Kubernetes 개발진들이 만든 컨테이너 런타임 표준 인터페이스
• 목적: Kubernetes가 다양한 런타임과 독립적으로 동작하도록 설계
• Docker 엔진의 종속성을 줄이기 위한 목적으로 개발됨
• CRI를 만족하는 런타임 예: CRI-O, Containerd

 

 

4) 왜 탈 Docker인가?

• 엔진 자체가 매우 무거움
• 단일 실패점으로 장애 발생시 모든 자식 프로세스에 영향을 줌
• auditd 등 리눅스 보안 기능과의 충돌
• 모든 도커 명령은 루트 권한을 가진 사용자에 의해서만 실행할 수 있음
• 최근엔 기존 도커의 Server-Client Model 대신 fork-exec 방식으로 전환하여 개발하는 추세 -> 데몬을 각자 분기하여 동작

 

5) 탈 Docker 대안

도구	역할	특징
Buildah	컨테이너 이미지 빌드 도구	Dockerfile 없이 이미지 생성, 데몬 불필요
Podman	컨테이너 실행 및 관리	Docker CLI 완전 대체 가능, pod 지원
Skopeo	이미지 복사/조회	docker pull/tag/push 대신 skopeo copy 한 줄로 처리
CRI-O	Kubernetes 최적화 런타임	경량, 빠른 실행, 보안 중심 설계

 

6) 컨테이너 서비스 구분

플랫폼	런타임	오케스트레이션
Docker	Docker Engine	Docker Swarm
Podman	Podman	OpenShift (RedHat)
Containerd	Containerd	Kubernetes

 

7) 그럼에도 불구하고...

• Docker는 여전히 가장 사용하기 쉬운 런타임
• RHEL에서는 기본 런타임으로 Podman을 제공하지만, 학습 난이도와 구조가 복잡
• 개인 프로젝트나 실습 환경에서는 여전히 Docker가 널리 사용되고 있음

 

 

7. [실습] Podman, Skopeo, Docker 이미지 업로드 정리

1) Podman은 데몬리스

• Podman은 Docker와 달리 백그라운드 데몬이 필요 없음
• 단순히 podman 명령어만 실행하면 즉시 컨테이너 동작 가능
• 시스템 자원을 더 안전하게 사용할 수 있음

 

podman run을 해도 ps를 찍어보면 안나옴

 

2) skopeo로 이미지 태그 검색

Skopeo는 컨테이너 이미지 저장소에서 이미지 정보를 조회하거나 직접 복사할 수 있는 도구이다. 

skopeo list-tags 명령어로 이미지 태그 목록을 확인할 수 있다.

 

 

3) Docker 이미지의 명명 규칙

[레지스트리]/[사용자명]/[이미지명]:[태그]

• 사용자명이 없는 경우 → Docker 공식 이미지
• 예시:
  • nginx:latest → 공식 nginx 이미지
  • myrepo/myapp:1.0 → 사용자 정의 이미지

 

4) Red Hat UBI 이미지 다운로드

podman pull 명령어로 registry.access.redhat.com/ubi9/httpd-24 해당 이미지를 다운로드한다. 

 

5) 이미지 태그 이름 변경

podman tag 명령어로 로컬에서 쉽게 사용가능하도록 httpd로 변경한다. 

 

 

6) Dockerhub에서 리포지토리 생성

 

7) docker cli에서 이미지 push 

1. CLI에서 로그인
[root@server1 ~]# podman login docker.io
Username: 
Password: 
Login Succeeded!

[root@server1 ~]# podman images
REPOSITORY                                TAG         IMAGE ID      CREATED        SIZE
localhost/httpd                           latest      2df46c86953  2 weeks ago    312 MB
registry.access.redhat.com/ubi9/httpd-24  latest      2df46c69953  2 weeks ago    312 MB
localhost/rocky                           latest      da830f52510  19 months ago  181 MB
quay.io/rockylinux/rockylinux             9.3         da830f5e251  19 months ago  181 MB

2. 태그 재설정
[root@server1 ~]# podman tag localhost/rocky docker.io/yulee0461/new1

[root@server1 ~]# podman tag localhost/httpd docker.io/yulee0461/new2:1

3. 이미지 push 
[root@server1 ~]# podman push docker.io/yulee0461/new1
Getting image source signatures
Copying blob 446f83f14b23 skipped: already exists  
Copying config da830f5e25 done   | 
Writing manifest to image destination

8) docker cli에서 이미지 pull

--- 이미지 모두 삭제 후 이미지 pull  ----

[root@server1 ~]# podman pull docker.io/studylab/new2:latest
Trying to pull docker.io/studylab/new2:latest...
Getting image source signatures
Copying blob 97971704aef2 done   | 
Copying blob 7d13becb8940 done   | 
Copying blob ce1770dcb97c done   | 
Copying config 2df46c8699 done   | 
Writing manifest to image destination
2df46c869953fe49208e34f2c5426748d85a20c5d822c5

[root@server1 ~]# podman images
REPOSITORY               TAG         IMAGE ID      CREATED      SIZE
docker.io/studylab/new2  latest      2df46c86995  2 weeks ago  312 MB

 

✍️ 하루 회고

오늘은 Docker에 대해 다시 정리하고, Podman과 같은 대체 런타임에 대해서도 학습해보았다.
그동안 도커만 사용해왔는데, 보안성과 유연성 면에서 Podman이 더 적합할 수 있다는 사실을 처음 알게 되었다.

다만, Podman은 데몬리스 구조이고, Skopeo나 Buildah처럼 함께 알아야 할 툴들이 많아 처음에는 다소 어렵게 느껴졌다.

 

그래도 기존에 Docker를 사용해본 경험 덕분에, Podman 명령어 자체는 거의 동일하게 사용할 수 있어 진입 장벽은 낮았다.

컨테이너 생태계가 빠르게 발전하고 있는 만큼, Docker 외에도 다양한 도구들을 실제로 써보면서 익숙해져야겠다는 생각이 들었다.