RED HAT

Open Source

1980년대 이전

• 하드웨어 판매 중심, 소프트웨어는 사은품
• 소프트웨어가 개발자들 사이에서 자유롭게 공유되던 시절

1975년 마이크로소프트 설립

• 상용 소프트웨어 등장

자유 소프트웨어 운동( Free Software Movement )

• 리차드 스톨만
• GNU 프로젝트 (GNU's not Unix 프로그램을 만드는 프로젝트 (1984년))
• 자유 소프트웨어 재단 (FSF : Free Software Foundation) 1985년 FSF 설립
• 1989년 최초의 오픈소스 라이선스 GPL 배포

GNU GPL(GNU General Public Licence)

• GPL 라이선스 프로그램을 어떠한 목적으로든지 사용할 수 있다.
• GPL 라이선스 프로그램의 소스코드를 용도에 따라 변경할 수 있다. (개작가능)
• 변경된 컴퓨터 프로그램 역시 프로그램의 소스코드를 요청시 제공해야한다.

리눅스의 탄생

• 리누스 배네딕트 토르밸스

아파치 웹서버와 리눅스

• 1992 : Version 0.96 of Linux has 1,000 users.
• 1993 : Version 0.99 of Linux has 20,000 users.
• 1995 : Version 1.2 of Linux has 500,000 users.
• 1997 : Version 2.1 of Linux has 3.5 million users.

컨테이너 기술의 세계

소프트웨어 컨테이너(container) 는 애플리케이션과 종속성을 하나의 단위로 묶어 격리된 환경을 제공합니다. 호스트 os 커널을 공유하면서도 독립적으로 실행되어 전통적인 가상 머신(VM) 보다 훨씬 가볍습니다.

컨테이너 엔진 종류

Container Engine (Docker,Podman)

컨테이너의 동작 원리

커널 공유 방식

• 하이퍼바이저 없이 호스트 OS 커널을 공유하여 작동합니다.

네임스페이스 격리

• 리눅스 네임스페이스로 프로세스,네트워크,파일 시스템 등을 격리합니다.

자원관리

• cgroups로 CPU, 메모리, 디스크 I/O 등 자원 사용을 제한합니다.

cgroups를 통한 자원 관리

자원 할당 제어 cgroups(컨트롤 그룹)은 컨테이너별로 시스템 자원(Resource)사용량을 제한합니다.

리소스제한 CPU, 메모리, 디스크 , I/O, 네트워크 대역폭 등의 사용 한도를 설정합니다.

품질 보장 한 컨테이너가 과도한 자원을 소비하여 다른 컨테이너에 영향을 주는 것을 방지합니다.

유니온 파일 시스템

유니온 마운트 파일시스템(Union FS)이란 여러 개의 디렉토리(파일시스템)를 하나로 통합하여 볼 수 있게 하는 파일시스템 기법입니다. 즉, 한 디렉토리 위치에 다수의 다른 디렉토리를 겹쳐서 마운트하여, 겉에서 볼 때는 단일 디렉토리 트리로 보이게 합니다.

유니온 파일시스템의 작동 방식

레이어드 구조

• 도커 이미지들은 여러 읽기 전용 레이어로 구성되고, 컨테이너를 실행할 때는 그 위에 읽기/쓰기 가능한 최상위 레이어가 추가됩니다.

Copy-on-Write(CoW) 메커니즘

• 기존의 이미지 데이터는 변경되지 않은 채 공유되고, 컨테이너 내부에서 파일을 수정하거나 생성하면 그 변경분만을 최상위 레이어에 기록하는 방식입니다.

효율적인 자원 공유

• 동일한 기반 이미지를 사용하는 다수의 컨테이너가 있어도 공용 부분은 메모리와 디스크에서 중복 저장하지 않고 공유할 수 있어 자원 효율이 높습니다.

빠른 이미지 빌드

• 한 컨테이너에서 소프트웨어를 설치해도 그 변화만 레이어로 남기 때문에 새로운 이미지를 만들 때 기존 레이어 캐시를 재사용하여 빌드 속도를 크게 높일 수 있습니다.

도커 : 대표적인 컨테이너 기술

표준화된 패키징

• 애플리케이션과 종속성을 표준화된 형식으로 패키징합니다.
  계층화된 이미지
• 이미지는 읽기 전용계층으로, 컨테이너 실행 시 읽기/쓰기 계층이 추가됩니다.
  빠른배포
• Docker 엔진으로 컨테이너의 생성, 배포, 실행을 자동화합니다.
  이미지공유
• Docker Hub와 같은 저장소에 이미지를 올려 공유할 수 있습니다.

OCI 에서 컨테이너 기술 관리

Docker 엔진의 내부 구조

Docker는 컨테이너를 관리하기 위해 클라이언트-서버 아키텍쳐를 채용하고 있습니다. 이를 구성하는 주요 컴포넌트는 다음과 같습니다.

Docker 클라이언트(CLI)

docker로 대표되는 명령줄 인터페이스로, 사용자가 Docker와 상호작용하는 도구입니다.

Docker 엔진 구성요소 : 이미지와 레지스트리

이미지

Docker 에서는 컨테이너 실행에 필요한 이미지를 관리합니다. 이미지는 앞서 언급한 계층화된 파일시스템 스냅샷으로 구성된 템플릿이며, Docker Hub와 같은 이미지 레지스트리 서버에 저장되고 공유됩니다.

레지스트리(Registry)

Docker 클라이언트가 docker pull을 수행하면 Docker 데몬이 해당 레지스트리에서 이미지를 다운로드하여 로컬에 캐시합니다. Docker 레지스트리는 공개/사설로 운영될 수 있어, 기업 내부에서는 프라이빗 레지스트리를 구축해 사용하기도 합니다.

이미지 빌드

Docker 이미지는 Dockerfile로부터 docker build 명령으로 생성하며, 빌드 시 각 명령어마다 레이어가 쌓여 효율적으로 생성됩니다. docker run 으로 컨테이너를 시작할 때 요청한 이미지가 없으면 자동으로 풀(Pull)해오며, 이미 있다면 캐시된 이미지를 가져옵니다.

Docker 엔진 구성요소: 네트워크와 볼륨

Docker 네트워크

Docker는 컨테이너 간 가상 네트워크를 구성하기 위한 다양한 네트워크 드라이버를 제공합니다.

• 브리지 네트워크 : 기본 네트워크 모드로, 호스트 내 컨테이너간 통신
• 호스트 네트워크 : 컨테이너가 호스트의 네트워크 스택을 직접 사용
• 오버레이 네트워크 : 여러 Docker 호스트에 걸친 컨테이너 간 통신
• MAC LAN 네트워크 : 컨테이너에 MAC 주소를 할당하여 네트워크에 연결

Docker 볼륨

Docker는 데이터 지속성을 위한 볼륨(volume) 기능을 제공합니다.

• 볼륨:Docker가 관리하는 호스트 파일시스템의 일부
• 바인드 마운트: 호스트의 파일이나 디렉토리를 컨테이너에 마운트
• tmpfs 마운트 : 임시 파일시스템을 컨테이너 메모리에 마운트

이러한 요소들은 Docker 데몬이 컨테이너 생성 시 옵션에 따라 설정하며, 컨테이너 환경을 앱 구동에 적합하게 보완합니다.

Docker 명령 실행 흐름

사용자 명령 입력 (사용자가 터미널에서 docker run 등의 명령을 입력합니다.)
->
API 요청 전송 (Docker CLI가 명령으 Docker 데몬의 API 앤드포인트로 전송합니다.)
->
데몬 처리 (Docker 데몬이 요청을 처리하고 필요한 작업을 수행합니다.)
->
컨테이너 실행 (containerd 와 runC 를 통해 실제 컨테이너 프로세스가 생성됩니다.)

OCI ( Open Container Initiative )

OCI의 목적 : 컨테이너 기술의 표준화를 위해 2015년에 설립된 리눅스 재단 프로젝트입니다. 컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 개발하는 것이 목표입니다.

런타임 규격 : 컨테이너 런타임의 동작 방식을 정의하는 표준으로, 컨테이너 생성, 실행, 삭제 등의 작업에 대한 규격을 제공합니다. runC는 이 규격의 참조 구현체 입니다.

이미지 규격 : 컨테이너 이미지의 구조와 메타데이터를 정의하는 표준으로, 이미지의 생성, 전송, 검증 방법을 규정합니다. 이를 통해 다양한 컨테이너플랫폼 간의 호환성을 보장합니다.

컨테이너 vs 가상머신

가상머신 (VM)

하이퍼바이저 위에서 각 VH마다 게스트 OS를 포함한 전체 시스템을 실행합니다.

• 완전한 게스트 OS 구동
• 높은 격리 수준
• 다양한 OS 호환성
• 큰 용량과 느린 시작 시간

컨테이너

호스트 OS의 커널을 공유하며 각 앱을 격리 실행합니다.

• 커널 공유로 경량화
• 빠른 시작 시간(수초)
• 적은 자원 사용량
• 호스트 OS 종속성

구조적 차이점

가상머신

• 하드웨어 수준 에뮬레이션, 완전한 게스트 OS 필요

컨테이너

• 애플리케이션 수준 가상화, 호스트 OS 커널 공유

하이브리드 접근

• VM 내에 컨테이너를 실행하여 이중 격리 구현

컨테이너 활용의 주요 이점

효율성

• 빠른 시작과 적은 자원 사용으로 비용 절감
  일관성
• 개발,테스트,운영 환경의 동일한 스택 구성
  이식성
• 어디서나 동일하게 실행되는 패키징
  격리
• 애플리케이션별 독립 환경으로 사용

격리된 환경의 이점

종속성 충돌 방지

• 서로 다른 버전의 라이브러리나 언어 런타임이 필요한 애플리케이션도 각각 별도의 컨테이너에서 실행 가능합니다.
  장애 격리
• 문제 발생 시 해당 컨테이너만 재시작하거나 교체하면 되므로 전체 시스템 안전성이 향상됩니다.
  마이크로서비스 지원
• 서비스 단위를 작게 나누어 독립적으로 배포하고 확장할 수 있습니다.

이식성과 일관성

개발 환경

• 로컬 머신에서 컨테이너로 개발
  테스트 환경
• 동일한 컨테이너 이미지로 테스트
  스테이징 환경
• 프로덕션과 유사한 환경에서 검증
  프로덕션 환경
• 클라우드에 동일 이미지 배포

컨테이너 오케스트레이션

대규모 시스템에서는 수십~수백 개 이상의 컨테이너를 자동으로 관리해주는 컨테이너 오케스트레이션이 필수적입니다.

배포자동화(컨테이너 배포를 자동으로 관리) -> 스케일링(부하에 따른 컨테이너 수 조정) -> 로드밸런싱( 트래픽을 컨테이너에 균등 분배) -> 자가치유(장애 컨테이너 자동 복구) -> 배포자동화(컨테이너 배포를 자동으로 관리)

대표적 컨테이너 오케스트레이션 오픈소스 Kubernetes

쿠버네티스 : 컨테이너 오케스트레이션의 표준

클러스터 구성

• 마스터/컨트롤 플레인이 전체 시스템을 조율하고, 다수의 워커 노드가 컨테이너를 실행합니다.
  선언적 설정
• YAHL 또는 JSON 으로 원하는 배포 설정(manifest)을 작성하여 쿠버네티스 API에 전달합니다.
  자동화된 운영
  -컨테이너 생성/삭제

Podman

Podman(POD 관리자)은 컨테이너를 개발, 관리, 실행하기 위한 오픈소스 툴입니다. Red hat 엔지니어가 오픈소스 커뮤니티와 함께 개발한 Podman은 libpod 라이브러리를 사용하며 컨테이너 에코시스템 전체를 사용합니다.

포드란

포드의 정의

포드는 모두 함께 실행되며 동일한 리소스를 공유하는 컨테이너 그룹으로, 쿠버네티스 포드와 유사합니다.

Podman의 관리 방식

Podman 은 libpod 라이브러리와 간단한 커맨드라인 인터페이스(CLI)를 통해 포드를 관리합니다.

Podman의 CLI는 Open Container Initiative(active(OCI)) 컨테이너를 생성하고 지원합니다.

포드의 구성

각 포드는 하나의 인프로 컨테이너와 다수의 일반 컨테이너로 구성되어 있습니다. 인프라 컨테이너는 포드를 실행하고 사용자 네임스페이스를 유지 관리하여 컨테이너를 호스트로부터 분리합니다.

Podman 과 다른 컨테이너 엔진의 차이점

향상된 보안 : 루트리스 컨테이너로 보안 리스크 감소

데몬이 없는 구조 : 루트 권한 프로세스에 의존하지 않음

일반 사용자 권한 : 관리 권한 없이 컨테이너 관리 가능

Podman 과 Docker 비교

Podman의 특징

• 데몬이 없는 아키텍처
• 항상 루트리스 컨테이너 지원
• 특정 측면에 전문화된 모듈식 툴

Docker의 특징

• 데몬 기반 아키텍처
• 최근에야 루트리스 모드 추가
• 컨테이너 생성 및 관리를 위한 올인원툴