클라우드정리

열공하는웅2·2025년 11월 3일

클라우드

목록 보기

3/13

🐳 Docker와 Kubernetes

이제 가상 컨테이너에서 실행되는 Docker(API, OS 이미지)와 이를 운영‧관리해주는 Docker Orchestration, 즉 Kubernetes(Kube, K8s) 를 알아본다.

🔧 사용 및 활용 현황

현재 삼성전자, 삼성 SDS, 현대 기아 자동차 AI Labs 등에서 사용 중인 도구로,

VMware 서버 설치 후 OpenStack(가상 컨테이너가 하나의 파일로써 소프트웨어이므로, 이를 연결하기 위해 물리적 장치가 아니라 소프트웨어적인 장치(스위치와 라우터)를 구축해주는 오픈소스 프로그램)을 활용해 사내 클라우드를 구축 및 운영하고 있다.
여기서 OpenStack은 SDN(Software Defined Network) 에 해당한다.

⚙️ 관련 도구 및 구성요소

Docker / Kubernetes : 환경 구성과 서비스 지원
Helm : Kubernetes 패키지 매니저로 서비스 설정과 관리 지원
Prometheus : Helm에서 수집된 정보를 Grafana로 전달
Grafana : 오픈소스 메트릭/로그 시각화 대시보드 제공 → 클라우드 모니터링
Terraform : 오픈소스 클라우드 인프라스트럭처 자동화 도구로, 인프라 자동화 구축 및 운영

🐋 Docker

Docker는 VMware, Virtual PC, Virtual Box(Oracle) 등과 같이 2013년에 등장한 컨테이너 기반 가상화 도구이다.
Go 언어(Go-lang) 로 작성되었으며, API는 리눅스 상의 계층화된 파일 시스템을 기반으로 한다.

⚙️ 동작 원리

외부 호스트의 CPU 프로세스를 각각 격리한 뒤, 각 프로세스에서 도커 이미지를 컨테이너 방식으로 실행 및 관리한다.
수많은 도커 이미지는 외부 리눅스 호스트의 각 CPU 프로세스 상에서 수행된다.
도커는 전용 이미지를 읽어 실행하기도 하지만, 외부에서 환경 변수 값을 입력받아 이미지 생성 및 실행 시 반영할 수도 있다.
→ 즉, 외부 입력값을 컨테이너 내부에서 즉시 적용하여 API가 실행되도록 한다.

🧱 구조적 특징

도커 이미지는 외부 리눅스 CPU 프로세스 상에서 동작하며, 휘발성 특성을 지닌다.
(→ 컨테이너 종료 시 데이터 저장 불가)
컨테이너의 상태를 다시 이미지로 만들어 재사용(CI/CD) 가능하다.

💻 개발 활용

일반적으로 Python, PHP, Ruby, Java 등의 언어로 개발된 애플리케이션을
다양한 라이브러리나 프레임워크와 함께 오픈소스로 공개하여 개발한다.
하지만 이러한 개발은 버전 관리, 보안 패치, 버그 수정 등의 문제로 어려움을 겪을 수 있다.
개발에 필요한 애플리케이션 라이브러리를 관리하여 환경 간 일관성 유지에 유리하다.

🐋 Docker (Kubernetes 필요성)

일반적으로 Python, PHP, Ruby, Java 등의 언어로 개발된 애플리케이션은
다양한 라이브러리나 프레임워크를 사용하며,
버전 관리·보안 패치·함수 의존성 등의 문제로 인해 개발에 어려움을 겪을 수 있다.
Docker는 이러한 문제를 해결하기 위해 등장한 기술로,
컨테이너를 통해 어플리케이션을 안정적으로 운영·통제할 수 있도록 해준다.
즉, Kubernetes는 Docker를 기반으로 동작하며 일부 모듈이 컨테이너로 되어 있다.

📦 컨테이너 이미지와 실행 방식

API를 포함한 Docker 이미지는 파일로 보관하거나 GitHub 같은 원격 저장소에서 공유 가능하다.
필요 시 언제 어디서나 업데이트/업그레이드된 API를 새로운 컨테이너로 실행할 수 있다.
도커 이미지는 격리된 CPU 프로세스에서 실행되므로,
여러 컨테이너 간 변경이 서로에게 영향을 주지 않는다.
나아가 외부 호스트(리눅스) 에도 영향을 미치지 않는다.
이러한 구조 덕분에 MS Word, Excel, Access API 등을 각각 독립된 Docker 이미지로 만들어
컨테이너 안에서 실행할 수도 있다.
(예: MS Office 365가 대표적인 Docker 클라우드 API 형태)

💰 Docker 버전 종류

Docker EE (Enterprise Edition) : 유료 버전
Docker CE (Community Edition) : 무료 버전
→ 일반적으로 Docker CE stable 버전을 사용해도 도커 활용에 무리가 없다.

🧩 Docker의 컨테이너 기반 가상화

⚙️ 개념 비교

가상머신(VM) : 하드웨어를 소프트웨어로 구현한 형태 (예: VMware, VirtualBox, VirtualPC)
컨테이너(Docker) : 호스트의 CPU 프로세스를 격리하여 각 컨테이너가 독립적으로 실행되는 구조

🧠 동작 구조

외부 호스트(Linux) 입장에서 보면 컨테이너는 단순히 CPU의 각 프로세스에 불과하지만,
사용자(컨테이너 내부) 입장에서는 자신만의 독립된 가상머신처럼 인식된다.
즉, 컨테이너는 외부 호스트와 무관하게 동작하면서 하나의 독립된 프로세스로 존재한다.
이러한 이유로 도커를 “컨테이너형 가상화(Container-based Virtualization)” 라고 부른다.
도커는 이러한 컨테이너형 가상화를 지원하는 대표 도구 중 하나이다.

🐋 Docker의 구조 및 환경

도커 이미지를 실행하는 컨테이너는 Linux 커널 기반에서 동작한다.
Docker나 Kubernetes를 포함한 컨테이너 관리 도구들은 CentOS 7, Ubuntu 18 이상의 리눅스 환경에서 주로 운용된다.
S/W 앱 실행에 필요한 요소들을 패키지화하여 하나의 이미지로 구성하고, 이를 독립된 컨테이너에서 실행한다.

🧱 Container vs VM

구분	Container	Virtual Machine (VM)
실행 환경	호스트 OS 위에서 실행	하이퍼바이저(Hyper-V, VMware 등) 위에서 실행
구성 요소	커널 공유 + 독립된 실행 파일(binary)/라이브러리(library)	OS 전체 포함
오버헤드	매우 낮음 → 클라우드에 최적	높음 (OS 중복 실행)

💡 오버헤드 비교: HyperVisor > VM > Container 순으로 크다.

📦 파일 및 라이브러리 관리

컨테이너는 프로그램을 실행할 때 필요한 라이브러리나 실행파일(binary) 만 포함한다.
예: import graphic, #include stdio
전체 OS를 설치하지 않기 때문에 가볍고 빠르며, 클라우드 환경에 최적화되어 있다.

🧱 컨테이너의 독립적 실행과 구조적 특징

단일 Linux 머신에서 컨테이너 독립적인 플랫폼을 실행하기 위해
OS 가상화(Linux 커널의 cgroups, namespace 공유, 파일 실행 등) 을 기반으로 한다.
컨테이너는 호스트 머신에서 직접 실행되므로 VM보다 훨씬 빠르게 동작한다.
(VM은 HyperVisor를 거쳐야 하므로 속도가 느림)

⚙️ 성능 및 구조 비교

구분	VM (가상머신)	Container
실행 방식	HyperVisor 위에서 동작	호스트 OS 위에서 직접 동작
구성 요소	독립적 CPU, RAM, HDD 포함 → 이미지 크기 큼	라이브러리와 실행 파일만 포함 → 이미지 크기 작음
실행 속도	느림	빠름

🧩 소프트웨어 구성 방식

Monolithic 방식
: 대입해야 하는 값을 일괄적으로 불러들이는 전통적 방식
MicroService 방식
: 필요한 기능 단위(모듈)를 개별적으로 실행하는 방식으로,
일종의 Modular 구조와 유사하다.
→ 특정 언어에 종속되지 않으며, 모듈 관리가 쉽고 유지보수도 간편하다.

💡 예시

Nginx App만을 컨테이너에서 실행할 수 있으며,
OS 없이도 동작 가능해 부하가 적고 유지보수가 쉬움.

🐋 Docker 이미지와 컨테이너의 동작 원리

Docker 이미지(Container) 는 각각 격리된 CPU 프로세스 환경에서 실행되는 애플리케이션(APP) 으로,
VM 가상머신과 유사하지만 훨씬 경량화된 구조를 가진다.
컨테이너는 클라우드 환경에서 소프트웨어 개발, 배포, 테스트 자동화를 위해 만들어졌으며,
이는 CI/CD (Continuous Integration / Continuous Development & Deployment) 개념과 맞닿아 있다.

⚙️ 실행 구조 비교

구분	Container	Virtual Machine (VM)
OS 커널	외부 호스트의 커널을 공유	각자 독립적인 OS 커널 보유
실행 환경	격리된 CPU 프로세스에서 실행	독립적인 OS 상에서 실행
자원 사용량	매우 적음 (디스크·메모리 효율적)	비교적 많음
부팅 속도	수 초 내 실행 가능	수 분 이상 소요

🧠 특징 요약

컨테이너는 실행 코드와 그에 종속된 요소를 묶어 응용층에 위치한 가벼운 실행 단위이다.
각 컨테이너는 외부 호스트 머신의 커널을 공유하면서도 격리된 CPU 프로세스에서 독립적으로 작동한다.
VM 가상머신은 각자 OS 커널을 가지므로 컨테이너보다 무겁고 느리다.
반면 Docker는 OS가 필요 없으며, 빠른 CPU 처리로 수 초 만에 여러 APPs를 실행할 수 있다.
따라서 다수의 Docker 컨테이너를 동시에 실행해도 시스템에 큰 부하가 없다.

🧱 컨테이너의 네트워크 OSI 상 계층 구조

계층 (Layer)	주요 내용	해당 Apps / 예시	대응되는 OSI 계층
Layer 6	Development Workflow, Opinionated Containers	Docker Cloud, OpenShift, Cloud Foundry, Deis, Flynn 등	표현층
Layer 5	Orchestration / Scheduling Service Model	Kubernetes, Docker Swarm, Marathon/Mesos, Nomad, Diego 등	세션층
Layer 4	Container Engine	Docker, Rocket, RunC(OCI), OSv, LSC, LXD 등	전송층
Layer 3	Operating System	Ubuntu, RHEL, CentOS, Unikernels 등	네트워크층
Layer 2	Virtual Infrastructure	OpenStack, vSphere, EC2, GCP, AWS, Azure 등	데이터링크층
Layer 1	Physical Infrastructure	Raw Computer, Network, Storage 등	물리층

요약하자면,

컨테이너 환경은 OSI 7계층 구조를 응용해, 하드웨어(물리 인프라)부터 컨테이너 엔진과 오케스트레이션 계층까지 단계적으로 구성되어 있다.

⚙️ CI/CD (Continuous Integration / Continuous Delivery / Continuous Deployment)

📘 개념 정의

CI/CD란 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법이다.
기본 개념은 다음 세 가지를 포함한다.
1. 지속적인 통합 (CI)
2. 지속적인 서비스 제공 (CD - Continuous Delivery)
3. 지속적인 서비스 배포 (CD - Continuous Deployment)

🔄 CI (Continuous Integration)

의미: 개발자들이 작성한 코드를 자동화된 프로세스를 통해 지속적으로 통합하는 과정
목표: 여러 개발자가 동시에 작업할 때 발생하는 코드 충돌 및 “통합 지옥(integration hell)” 문제 해결
방법:
- 새로운 변경사항을 주기적으로 빌드(build) 및 테스트(test) 후 공유 저장소에 병합
- 이를 통해 항상 최신 상태의 애플리케이션 코드를 유지

🚀 CD (Continuous Delivery / Deployment)

Continuous Delivery
- 지속적인 서비스 제공 단계로, 테스트를 통과한 코드를 자동으로 배포 가능한 상태까지 유지
Continuous Deployment
- 실제 운영환경(Production)까지 자동 배포가 이루어지는 단계
- 두 용어는 종종 혼용되지만, 자동화 수준의 차이에 따라 구분된다.

💡 핵심 포인트

CI/CD는 통합 → 테스트 → 배포의 모든 과정을 자동화하여
개발 효율성과 서비스 품질을 동시에 향상시키는 DevOps 핵심 요소이다.
자동화 파이프라인을 통해 코드 변경 시마다 신속하게 테스트 및 배포가 이루어진다.

⚙️ CI/CD의 Workflow와 DevOps 연계

🔄 CI/CD 파이프라인의 개념

CI/CD 파이프라인(Workflow Pipeline) 이란
애플리케이션의 개발 → 통합 → 테스트 → 배포 단계 전체를 자동화하고
지속적인 모니터링과 서비스 제공이 가능하도록 구축된 시스템을 말한다.
즉, 애플리케이션의 라이프사이클 전체를 자동화한 개발 환경이다.

🚀 Agile & DevOps

Agile(애자일)
: 신속한 반복 작업을 통해 실제 동작 가능한 소프트웨어를 지속적으로 제공하는 개발 방식.
DevOps(데브옵스)
: 개발(Development)과 운영(Operations)의 협업을 강조한 개념으로,
개발자와 정보기술 전문가 간의 소통·협업·자동화를 중심으로 한다.
→ 소프트웨어 개발과 배포 효율을 높이는 핵심 문화이자 방법론이다.

🧠 SRE (Site Reliability Engineering)

SRE는 IT 운영에 대한 소프트웨어 엔지니어링 기반 접근법이다.
DevOps의 철학을 기반으로, 시스템을 프로그래밍적으로 관리하고
문제 해결 및 운영 자동화를 통해 안정적인 서비스 제공을 목표로 한다.

🧩 주요 CI/CD 도구

대표적인 자동화 도구로는 다음이 있다.
Jenkins, CircleCI, TeamCity, Bamboo, GitLab CI/CD 등

요약하자면,

CI/CD는 Agile과 DevOps 문화를 기반으로 하여,
개발–테스트–배포 전 과정을 자동화하고
SRE 방식으로 시스템 안정성을 확보하는 현대적 소프트웨어 개발 패러다임이다.

🧩 컨테이너를 사용하는 이유

컨테이너는 다음과 같은 특징 덕분에 가상 서버보다 우수한 애플리케이션 실행 환경을 제공한다.

⚙️ 1. 인프라 사용률 향상

하나의 물리 서버(또는 가상 서버, 노드) 위에서 여러 개의 컨테이너(파드) 를 동시에 실행할 수 있다.
CPU와 RAM 사용 효율이 높아져 하드웨어 자원을 극대화할 수 있다.

⚡ 2. 빠른 실행 시간

컨테이너의 실행 속도는 가상 서버(VM)나 물리 서버보다 훨씬 빠르다.
운영체제나 미들웨어 설치 없이 이미지 기반으로 즉시 실행 가능하다.
이미지에 필요한 설정이 포함되어 있기 때문에 설치 및 환경 설정 시간이 단축된다.
네트워크나 볼륨 등의 소프트웨어 정의 자원도 즉시 자동으로 구성 가능하다.

🧱 3. 유연한 실행 환경

애플리케이션 실행에 필요한 모든 소프트웨어를 이미지로 패키징할 수 있다.
여러 컨테이너를 조합하여 시스템을 모듈화할 수 있으며,
특정 서버에 종속되지 않기 때문에 개발 환경과 운영 환경 간 차이를 최소화할 수 있다.

요약하자면,

컨테이너는 효율성(자원 활용) + 속도(즉시 실행) + 유연성(환경 분리) 을 동시에 만족시키는
현대적 애플리케이션 실행 플랫폼이다.

🧩 컨테이너 실행 환경과 Docker 구성 요소

⚙️ 1. 컨테이너 실행을 위한 커널 및 가상화 환경

컨테이너를 실행하기 위해서는 리눅스 커널 기반의 가상 서버가 필요하다.
Docker CE를 Mac이나 Windows에 설치할 경우,
- Mac에서는 HyperKit,
- Windows에서는 Hyper-V,
- Linux에서는 Containerd 런타임 위에서 동작한다.
이 구조는 하이퍼바이저 위에 Linux를 올리고, 그 위에서 컨테이너를 실행하는 형태다.
LinuxKit은 컨테이너 실행을 위한 경량 리눅스 서브시스템으로, Docker, IBM, ARM, MS, Intel 등이 공동 개발하였다.

☁️ 2. 클라우드 및 오픈소스 환경

컨테이너는 하이퍼바이저 기반 가상머신뿐 아니라
퍼블릭/프라이빗 클라우드 환경에서도 널리 사용된다.
대표적으로 OpenStack 위에서 구동되는 사례가 많다.
리눅스 커널이 제공하는 기능을 직접 활용해 도커가 없어도 컨테이너 생성은 가능하지만,
재활용 및 관리가 어려워 일반적으로 hub.docker.com 같은 커뮤니티 저장소에서
이미지를 내려받아 사용하는 것이 효율적이다.

🐳 3. Docker의 기본 구조

구성 요소	설명
Docker 데몬(Daemon)	서버 단에서 도커 명령을 받아 컨테이너 및 이미지를 관리하는 핵심 엔진
Docker 클라이언트(Client)	사용자가 명령어를 입력하거나 외부 네트워크 요청을 통해 도커 데몬에 접근
Docker 이미지(Image)	컨테이너를 생성하기 위한 템플릿으로, 실행 환경과 애플리케이션을 포함
Docker 레지스트리(Registry)	이미지 저장소로, hub.docker.com과 같은 원격 저장소를 포함

🧱 4. 주요 기능 요약

컨테이너 생성, 실행, 중지, 삭제 등의 파드 단위 제어
컨테이너의 로그, 자원 사용량, 네트워크 연결 상태 관리
외부 리소스 제어 및 보안 설정 관리

요약하자면,

Docker는 리눅스 커널 기반의 경량 가상화 기술로,
클라이언트–데몬–이미지–레지스트리 구조를 통해
컨테이너 생성, 배포, 관리를 일원화한 오픈소스 플랫폼이다.

🐳 Docker의 명령어 기반 제어 구조

⚙️ 1. Docker의 기본 구성

Docker는 서버 단의 도커 데몬(Daemon) 과 명령어로 제어되는 클라이언트(Client),
그리고 도커 이미지(Image) 및 레지스트리(Registry) 로 구성된다.

도커 데몬(Daemon)
- 클라이언트로부터 명령을 받아 도커 객체(이미지, 컨테이너, 볼륨, 네트워크 등)를 관리한다.
- 외부 네트워크의 원격 클라이언트 요청도 API를 통해 수신할 수 있다.
- 마스터 노드에서는 쿠버네티스(Kubernetes)의 API 서버처럼 클라이언트 요청을 받아
  컨테이너를 실행하거나, 노드를 지정해 스케줄링 및 삭제 등을 수행한다.
- 또한 파드 제어, 외부 리소스 관리, 컨트롤러 기능까지 담당한다.

💻 2. 도커 클라이언트(Docker Client)

CLI(Command Line Interface) 환경에서 도커 데몬과 통신하며 명령을 전달한다.
사용자는 도커 API를 통해 도커 데몬에게 요청을 보내며, 이 과정을 통해
컨테이너 생성, 이미지 관리, 리소스 조회 등의 작업을 수행할 수 있다.

🧱 3. 주요 Docker 명령어 정리

명령어	설명
docker build	베이스 이미지에 기능을 추가하여 새로운 이미지를 생성
docker pull	원격 레지스트리(Docker Hub 등)에서 이미지를 다운로드
docker run	이미지를 기반으로 새로운 컨테이너를 생성 및 실행
docker ps / docker container ls	실행 중인 컨테이너 목록 확인

요약하자면,

Docker는 명령어 기반 제어 구조(CLI + API) 를 통해
클라이언트–데몬 간의 요청과 응답으로 컨테이너를 생성·배포·관리하는 체계적인 플랫폼이다.

🐋 Docker 이미지 실행 및 컨테이너 관리

⚙️ 1. 이미지 실행 기본 구조

로컬 호스트에 이미지가 없을 경우, 도커는 원격 레지스트리에서 자동으로 이미지를 다운로드(pull) 한 뒤 실행(run)한다.

docker pull jenkins   # 원격 레지스트리에서 Jenkins 이미지 다운로드
docker run jenkins    # 다운로드된 이미지로 컨테이너 실행

예: Nginx, CentOS 등의 이미지도 동일한 방식으로 실행된다.

🧱 2. 이미지 생성과 Dockerfile

대부분의 이미지는 기존 이미지 기반으로 파생되어 생성된다.
예: Nginx 컨테이너는 Debian을 기반으로 생성됨.
새로운 이미지를 만들 때는 기본 이미지(Nginx) 와 설치 스크립트 등을
Dockerfile에 명시(Manifest) 한 뒤, 이를 빌드(build) 하여 생성한다.

예시:

Dockerfile 명령어를 읽음
필요한 기본 이미지 다운로드
설정 및 패키지 추가
새로운 이미지(Nginx 등)를 로컬 레지스트리에 저장

이 과정은 모두 자동화되어 수행된다.

💻 3. 컨테이너의 실행 및 구조

각 컨테이너는 하나의 CPU 프로세스와 동일하게 동작한다.
리눅스의 네임스페이스(namespace)와 cgroups 기술을 통해
독립된 프로세스로 분리되어 실행된다.
컨테이너 실행 시 자동으로 고유한 IP 주소가 할당되며,
외부와의 연결을 위해 내부 프로세스를 연결할 수 있다.

🔧 4. 주요 실행·관리 명령어

명령어	설명
docker run	컨테이너를 실행한다.
docker stop	실행 중인 컨테이너를 중지한다.
docker kill	강제 종료한다.
docker rm	컨테이너를 삭제한다.

요약하자면,

Docker는 Dockerfile 기반으로 이미지를 자동 생성하고,
run → stop → remove 순서로 컨테이너의 전체 라이프사이클을 제어할 수 있다.

🐳 Docker 컨테이너 재실행 및 레지스트리 구조

🔁 1. 컨테이너 재실행과 IP 주소 주의점

docker start 명령으로 중지된 컨테이너를 다시 실행할 수 있다.
단, 정지 전 사용하던 IP 주소는 유지되지 않으며,
재실행 시 새로운 IP 주소가 자동 할당된다.
도커 이미지는 가상머신의 프로세스 단위로 작동하므로,
컨테이너가 삭제되면 모든 데이터와 설정 정보도 함께 사라진다.

⚙️ 2. 리눅스 기반 커널 차이

Docker 컨테이너는 리눅스 커널 기반으로 실행되며,
사용되는 OS 버전에 따라 커널 버전이 다르다.
- 예: CentOS 7 → 3.10 / Debian 9 → 4.9 / Ubuntu 18.0 → 5.4
Docker CE 버전 16.04.0-ce 이상에서는 리눅스 커널 4.9.93-linuixkit-aufs를 사용한다.
리눅스 배포판마다 커널 버전이 달라도 실행 가능한 이유는,
도커가 ISO 표준화된 규격에 따라 호환성을 유지하기 때문이다.

📦 3. Docker 레지스트리(Registry)와 리포지토리(Repository)

구분	설명
Docker Registry (도커 레지스트리)	컨테이너 이미지가 저장되는 공간으로, 대표적으로 Docker Hub (hub.docker.com) 이 있다.
Docker Repository (도커 리포지토리)	여러 도커 이미지를 모아둔 공간으로, 하나의 레지스트리 안에 여러 개의 리포지토리가 존재한다.

예시:

docker run hello-world

→ Docker Hub의 공개 레지스트리에 등록된 hello-world 이미지를 다운로드하여
로컬에서 컨테이너로 실행한다.

☁️ 4. Docker 이미지 레지스트리의 유형

유형	설명	대표 서비스
a) 퍼블릭 레지스트리	누구나 자유롭게 접근 가능한 공개 저장소	Docker Hub, Quay.io
b) 클라우드 레지스트리	퍼블릭 클라우드에서 제공하는 상용 저장소, 계정 인증 필요	AWS ECR, Azure Container Registry, Google GCR, IBM Cloud Registry
c) 프라이빗 레지스트리	특정 조직이나 개인이 자체적으로 운영하는 폐쇄형 저장소	Harbor, GitLab Container Registry, Docker Private Registry

요약하자면,

Docker는 리눅스 기반의 표준화된 커널 위에서 작동하며,
이미지는 Registry → Repository → Container 순서로 관리되고 실행된다.
퍼블릭·클라우드·프라이빗 세 유형으로 구분되며, Docker Hub가 대표적이다.

☸️ Kubernetes와 Docker의 관계 및 동작 구조

⚙️ 1. Kubernetes의 이미지 실행 과정

Kubernetes도 Docker처럼 레지스트리(Registry) 에서 이미지를 다운로드받아 컨테이너를 실행한다.
이 과정은 다음과 같다:

Dockerfile로 이미지에 대한 명세(Manifest)를 작성
docker build 명령으로 이미지 빌드
docker push 명령으로 이미지를 레지스트리에 등록
kubectl 명령으로 매니페스트(Manifest)에 기재된 오브젝트(Object) 생성 요청
매니페스트에 지정된 레포지토리에서 컨테이너 이미지를 다운로드
컨테이너 내부(Pod)에서 실행

즉, Kubernetes는 Docker 이미지를 활용해 컨테이너를 관리한다.

🧱 2. Kubernetes와 Docker 런타임의 변화

Kubernetes는 도커 컨테이너 런타임 환경을 사용하지만,
최근에는 Containerd 프로세스를 통해 Docker 데몬(dockerd) 없이도 작동 가능하다.
원래 Docker를 만든 회사가 컨테이너 런타임 표준(Container Runtime Interface, CRI) 을
기반으로 만들었기 때문에 오랫동안 Docker가 기본 런타임으로 사용되었다.
그러나 이후 Kubernetes는 점진적으로 Docker 종속성 제거 방향으로 발전하고 있다.
→ 즉, Kubernetes 1.11 이후 버전부터는 Docker 대신 Containerd, CRI-O 등을 사용한다.

☁️ 3. 클라우드 및 런타임 확장

퍼블릭 클라우드 환경에서도 Kubernetes 관리 서비스(예: IBM Cloud Kubernetes Service 등)가
Containerd 기반으로 전환되는 추세이다.
이는 성능 향상과 경량화를 목표로 하는 방향이다.

요약하자면,

Kubernetes는 Docker 이미지를 기반으로 컨테이너를 실행하지만,
Containerd 중심의 경량 런타임 환경으로 전환 중이다.
이는 Kubernetes의 독립성과 효율성 향상을 위한 진화 과정이다.

☁️ 네임스페이스, 파일 시스템, 그리고 클라우드 기반 Kubernetes 활용

⚙️ 1. 네임스페이스(namespace)

네임스페이스는 클라우드 안에서의 로컬 LAN 같은 작업 영역으로 볼 수 있다.
리눅스 커널은 특정 프로세스를 다른 프로세스와 분리하여
컨테이너가 속한 네임스페이스 내부에서만 접근 가능하도록 한다.
Subnet이나 VLAN 개념과 유사하다.

📁 2. 파일 시스템 – UnionFS

Docker는 UnionFS 계열의 파일 시스템을 사용한다.
→ 서로 다른 파일 시스템의 디렉터리를 하나의 통합된 파일 시스템처럼 사용하는 기술.
주요 유형: aufs, btrfs, overlay2
- 과거에는 aufs가 기본이었으나,
- Docker CE 17.12 이후에는 overlay2 가 표준으로 채택되었다.
overlay2는 속도가 빠르고 구조가 단순하다는 장점이 있다.

🧠 3. cgroups (Control Groups)

리눅스 커널의 cgroup 기능을 통해
도커 프로세스별 CPU·RAM 사용량을 감시하고 제한할 수 있다.
이를 통해 컨테이너 간 자원 격리가 가능하며,
여러 컨테이너가 동시에 실행되어도 자원 관리 효율성이 유지된다.

☸️ 4. 클라우드 환경에서의 Kubernetes 활용

기업들은 서비스 개발·배포·운영(CI/CD) 를 위해
클라우드 기반 인프라를 사용할 수밖에 없다.
예: AWS(Amazon Web Services) 등에서는
Kubernetes를 적용해 컨테이너형 클라우드 환경을 운영한다.

🧩 5. Kubernetes의 주요 기능 (Kube 시스템)

Kube는 컨테이너의 조직과 관리, 스케줄링, 서비스 발견, 모니터링 등을
체계적으로 통합한 Orchestration(오케스트레이션) 도구이다.
주요 기능
- Virtual Server & Auto Scaling
- Service Discovery 및 Load Balancing
- Monitoring & Management
기업들은 이를 활용해 연산(Computing) 능력을 확장하고,
GPU 자원을 묶어 대규모 연산 처리를 수행할 수 있다.
(예: AWS 인스턴스, GPU 연산 노드 등)

🌐 6. Kubernetes EcoSystem

Hadoop EcoSystem처럼 Kubernetes도 다양한 오픈소스 툴과 연동된다.
대표 구성 도구:

Fluentd, Elastic, Kibana, Jenkins, Prometheus, Grafana, Helm 등

→ 이들 도구가 통합되어 Kubernetes EcoSystem을 구성하며,
클라우드 환경에서 완전한 서비스 자동화 및 모니터링 체계를 구축할 수 있다.

요약하자면,

네임스페이스와 cgroup이 리눅스 컨테이너의 기반 기술이라면,
Kubernetes는 이를 클라우드 수준으로 확장하여
오케스트레이션 + 모니터링 + 확장성을 통합 제공하는 플랫폼이다.

☸️ Kubernetes EcoSystem과 클라우드 운영의 장점

🧩 1. Kubernetes EcoSystem

Hadoop EcoSystem처럼 Kubernetes도 다양한 오픈소스 도구와 통합되어 작동한다.
대표 구성 도구:
Fluentd, Elastic, Kibana, Jenkins, Prometheus, Grafana, Helm 등
이러한 도구들이 모여 클라우드 오케스트레이션 및 자동화 환경을 형성한다.

💡 2. 클라우드 기반 컨테이너 운영의 장점

✅ (1) H/W 초기 투자비용 절감

기업은 클라우드에서 Docker 기반 컨테이너 운영을 활용함으로써
초기 하드웨어 도입 비용을 크게 절감할 수 있다.
클라우드 리소스를 탄력적으로 조정해 필요한 만큼만 사용 및 결제가 가능하다.
이를 통해 APPs 및 리소스 최적화 운영이 가능하다.

✅ (2) Add-on 서비스 개발/구축비용 절감

개발 및 운영에 필요한 Add-on 서비스를 All-in-One 형태로 제공하므로
별도의 추가 비용이 발생하지 않는다.
예:
- 기존에는 Windows OS를 설치한 뒤 MS Word를 별도 설치해야 했으나,
- 이제는 MS Word가 포함된 Docker 이미지를 배포하여 즉시 실행 가능.
- 실제로 Microsoft Edge 브라우저나 Office 365도
  VDI(Virtual Desktop Interface) 기반에서
  컴퓨터에 설치하지 않고 바로 사용할 수 있다.

✅ (3) 운영 및 업그레이드 효율성

플랫폼이 자동화된 운영 환경을 지원하기 때문에
서버 OS 관리, 업그레이드, 패키지 유지보수 등의
운영 인건비와 관리 비용을 절감할 수 있다.

요약하자면,

Kubernetes EcoSystem은 다양한 오픈소스 도구를 통합하여
비용 절감 + 운영 효율화 + 확장성 향상을 동시에 실현하는
클라우드 기반의 컨테이너 오케스트레이션 플랫폼이다.

🐋 Docker 및 Kubernetes 설치 환경과 실행 권장사항

⚙️ 1. 설치 환경

Docker 운영을 위해서는 Ubuntu 18.04 이상 버전을 설치하여 사용하는 것이 권장된다.
OpenStack(SDN 기반 소프트웨어 스위치) 를 이용해
로컬 Docker 컨테이너 머신들을 외부 네트워크와 연결하려면
게이트웨이(소프트웨어 라우터) 설정이 필요하다.
특히, Ubuntu 20.04 Live-Server 버전을 사용하는 것이 안정적이다.

⚡ 2. 실행 권장사항

🔑 Docker와 Kubernetes의 모든 작업은 root 권한으로 실행하는 것이 좋다.

🧱 3. 설치 및 구성 순서 (예시)

멀티 모드 하둡(Multi-Mode Hadoop) 환경 구축
- Hadoop Master / Slave 노드 구성
Master 노드에 Docker 설치
- 이후 master, slave1, slave2 노드에 순차적으로 Docker Swarm 및 Kubernetes 설치
관리 도구 사용
- 기존에 Xshell로 관리했다면,
  Kubernetes 환경에서는 Ansible로 통합 관리하면 효율적이다.

요약하자면,

Docker 및 Kubernetes 실습 환경 구축 시
Ubuntu 18.04 이상(권장: 20.04 Live-Server) 환경에서
root 권한으로 설치 및 실행하는 것이 가장 안정적이며,
Ansible 기반 자동화 관리를 통해 클러스터 운영 효율성을 높일 수 있다.

실습

/etc/docker/docker.json 설정 파일

도커 설치 과정을 해주고
sudo systemctl status docker

🐋 Docker 주요 명령어 정리

⚙️ 기본 사용법

docker COMMAND --help
→ 각 명령어(COMMAND)의 옵션과 세부 설명을 확인할 수 있다.

🚀 자주 사용하는 명령어 목록

명령어	설명
run	이미지를 기반으로 새로운 컨테이너를 생성하고 실행한다. 예: `-it` 옵션을 주면 컨테이너 쉘로 진입 가능 (`docker run -it ubuntu /bin/bash`)
exec	이미 실행 중인 컨테이너 안에서 명령어를 실행한다.
ps	현재 실행 중인 컨테이너 목록을 확인한다.
images	로컬에 저장된 이미지 목록을 출력한다.
create	컨테이너를 생성만 하고 실행하지 않는다. (보통 `docker run` 명령이 더 자주 사용됨)
attach / detach	실행 중인 컨테이너에 접속하거나(background/foreground 전환), 분리(detach)한다.
start	중지(stopped)된 컨테이너를 다시 시작한다.
stop	실행 중인 컨테이너를 정지시킨다.
rm / rmi	컨테이너(`rm`) 또는 이미지(`rmi`)를 삭제한다.
inspect	Docker 객체(이미지, 컨테이너 등)에 대한 자세한 정보를 출력한다.
commit	실행 중인 컨테이너를 새로운 이미지로 저장한다. (즉, Bare Image → Custom Image 생성 과정)

💡 팁

컨테이너 실습 시 직접 명령을 입력해보며 동작을 확인하면 가장 효과적이다.
run → exec → stop → start → rm 순으로 실습하면
Docker의 기본 동작 흐름을 쉽게 이해할 수 있다.

docker ps,
docker ps -a

4개 실행
각각의 하나의 프로세스임.

🐋 Docker Image

📦 1. 개요

Docker Image는

OS 계열: CentOS, Ubuntu, Rocky 등
애플리케이션 계열: PDF, 웹서버,
DB 계열: MySQL, MariaDB 등

다양한 스냅샷 형태로 제공되며, 대부분 무료로 사용할 수 있다.

⚙️ 2. 이미지 생성 및 실행

필요한 이미지는 Docker Hub에서 다운로드하거나
직접 Dockerfile을 작성하여 생성할 수도 있다.
```
docker build -t myimage .
docker run myimage
```
실행 시 외부 Ubuntu 상의 프로세스 중 하나로 컨테이너 형태로 동작한다.

🧩 3. 컨테이너와 노드 구조

여러 개의 Ubuntu 머신(노드)을 구성하면,
각 노드에서 여러 컨테이너(Kubernetes에서는 Pod)가 실행된다.
이때 컨테이너와 노드를 관리하는 방식에는 두 가지가 있다:
1. Docker Swarm
2. Kubernetes (K8s)

→ Kubernetes는 노드 및 컨테이너를 통합적으로 관리하며,
클러스터 전체의 상태를 제어한다.

🗂️ 4. Hadoop과의 개념적 유사성

Docker Swarm과 Kubernetes는
Hadoop 시스템에서의 Master/Slave 구조와 유사하게 동작한다.
즉, 마스터 노드(Kubernetes Control Plane) 가
여러 슬레이브 노드(Worker Node) 를 관리하는 구조로,
Hadoop의 NameNode ↔ DataNode 관계와 비슷하다.

요약하자면,

Docker Image는 OS·App·DB 등 다양한 환경을 스냅샷 형태로 제공하며,
Docker Swarm과 Kubernetes는 이를 분산 환경에서 관리하는 오케스트레이션 도구로 작동한다.

respective(각각의)

옆에 보라색 마크는 우수마크

docker pull rockylinux:8
docker pull centos:7

docker images

기존 버전의 거의 1/10 수준의 크기를 가짐.

docker run rockylinux:8 => 포그라운드(foreground) 실행
docker run -d rockylinux:8 => 백그라운드 실행
3699ff7d6ada3a9d85255354a5efab17bd903abb47179670873f9d305667968d

🐋 Docker Hub와 다양한 이미지 크기 비교

1️⃣ Bare Image 개념

https://hub.docker.com 에서 예를 들어 CentOS7 이미지를 다운로드하면,
Bare Image(순수 기본 이미지) 형태로 내려받게 된다.
Bare Image는 어떤 용도에도 맞게 커스터마이징되지 않은 오리지널 OS 이미지이며,
조직에서는 이를 기반으로 필요한 APPs, FW, DB 서버 설정 등을 추가하여
내부에서 사용할 커스텀 이미지(Custom Image) 로 변환한다.
이후 CI/CD 프로세스에 따라 배포하면,
업데이트된 이미지가 자동으로 교체되어 업데이트 부담 없이 운영할 수 있다.
컨테이너는 각각 독립된 CPU 프로세스로 동작하므로,
여러 개의 컨테이너를 실행해도 외부 Ubuntu 호스트에 부하가 거의 없다.

2️⃣ CentOS vs Rocky Linux vs Alpine 비교

구분	이미지명	용량	특징
CentOS 7	`centos:7`	약 450MB 이상	안정적이지만 이미지 크기가 큼
Rocky Linux 8	`rockylinux:8`	약 204MB	CentOS 계열 대체 OS, 크기가 작음
Alpine Linux	`alpine:latest`	약 20MB	초경량, Docker 환경에 최적화
Rocky (Full ISO)	`Rocky8.9 ISO`	약 4.6GB	OS 전체 설치 이미지 (Docker용 아님)

➡️ Alpine Linux는 20MB 수준으로 매우 가볍기 때문에
시스템 리소스가 부족한 환경(예: IoT, 소형 서버, Docker Cluster)에 최적화되어 있다.

3️⃣ 초소형 Linux 배포판 — BusyBox

BusyBox는 Linux의 경량화 버전으로,
예전 FDD(1.44MB) 크기에도 들어갈 정도로 작다.
Drone, IoT, Embedded System, Arduino, Raspberry Pi 등
저사양 환경이나 초소형 PC에서도 충분히 작동 가능하다.

즉, 리소스 제약이 있는 환경에서는 Alpine이나 BusyBox 기반 이미지가
Docker 컨테이너 운영 효율을 극대화하는 선택이다.

📘 요약

Bare Image → Custom Image로 변환해 CI/CD 환경에 맞게 배포
이미지 크기는 CentOS > Rocky > Alpine 순으로 작아짐
초경량 시스템엔 BusyBox 기반 이미지 사용 가능

🐋 Docker Hub와 Bare Image 개념

📦 1. Docker Hub에서의 이미지 다운로드

Docker 공식 사이트(hub.docker.com)에서 예를 들어
CentOS 7 이미지를 다운로드하면, 이는 Bare Image (기본 이미지) 형태이다.
이 이미지는 순수 오리지널 형태로,
어떤 용도로 사용할지에 대한 설정이 전혀 포함되어 있지 않다.

🧩 2. 조직 내 이미지 커스터마이징

조직에서는 이 Bare Image를 기반으로,
필요한 APPS / Firewall / DB 서버 등의 환경을 추가로 설정하여
새로운 Custom Image로 만들어 사용한다.
새로 만든 이미지를 조직 내 사용자에게 배포하면,
필요한 설정이 이미 포함된 최적화된 CentOS 7 운영체제를 즉시 활용할 수 있다.

🔄 3. CI/CD와 컨테이너 프로세스

이러한 과정은 CI/CD(Continuous Integration / Continuous Deployment) 흐름과 동일하다.
컨테이너는 하나의 CPU 프로세스 단위로 실행되며,
기존 이미지를 폐기해도 부담이 없고,
새로운 업데이트된 이미지를 바로 컨테이너에서 재실행할 수 있다.

→ 결과적으로 업데이트 부담이 없고,
외부 Ubuntu 호스트 노드에도 부하가 적다.

요약하자면,

Docker Hub에서 제공되는 Bare Image는 순수한 기본 OS 이미지이며,
조직은 이를 기반으로 커스터마이즈하여 자체 CI/CD 환경에서
효율적이고 가벼운 배포 시스템을 구축할 수 있다.

🐋 Docker `-d` 옵션 (detach mode) 실습 정리

🔹 `-d` 옵션의 의미

-d 옵션을 사용하면 컨테이너가 백그라운드 모드(detach mode) 로 실행된다.
실행 시 CONTAINER_ID가 출력되고,
즉시 터미널이 프롬프트로 돌아와 터미널을 계속 사용할 수 있다.
단, 컨테이너를 종료하려면 수동으로 docker stop 명령을 실행해야 한다.

💡 웹서버나 데이터베이스처럼 지속적으로 동작해야 하는 서비스를 실행할 때 유용하다.
여러 컨테이너를 동시에 띄워야 할 때에도 효과적이다.

🔹 예제 실습

a. docker run -d --name my_doc1 nginx:latest

→ nginx 컨테이너를 백그라운드로 실행

b. docker ps

→ 현재 실행 중인 컨테이너 목록 확인

c. docker stop my_doc1

→ 컨테이너 중지

d. docker ps

→ 실행 중인 컨테이너 없음

e. docker ps -a

→ 중지된(Exited) 상태의 컨테이너 포함 전체 목록 출력

f. docker start my_doc1

→ 중지된 컨테이너 다시 시작

g. docker ps

→ 다시 실행 중인 컨테이너로 표시됨

🔹 `-d` 옵션 없이 실행할 경우

docker run nginx

컨테이너가 포그라운드(foreground) 상태로 실행됨
실행 로그가 실시간으로 터미널에 출력되어 터미널 사용 불가
종료는 Ctrl + C 로 직접 중단해야 함
(→ 컨테이너도 함께 종료됨)

🔹 `-it` 옵션

docker run -it ubuntu /bin/bash

-it = -i(interactive) + -t(pseudo-TTY)
컨테이너 내부 쉘에 직접 접속하여 디버깅 또는 테스트 용도로 사용

✅ 정리표

실행 옵션	실행 형태	터미널 사용	종료 방식	주용도
`docker run -d`	백그라운드	가능	`docker stop`	서비스 실행용
`docker run`	포그라운드	불가	`Ctrl + C`	단발성 실행
`docker run -it`	인터랙티브	쉘 진입	`exit`	디버깅 / 실습용

몇 개로 나눠서 다운 받는 모습을 볼 수 있다.
=> 공통적인 부분을 Layer로 각각 구분해서 Cached에 넣어두면 상위 버전을 다운 받을 때 중복되는 부분은 바로 다시 캐시 메모리에서 바로 받고, 중복되지 않는 일부분만 받으므로 매우
빠르게 다운로드됨.

docker start mydoc1 해야
ps에서 보임.

docker run --name mydoc2 nginx:latest

포어그라운드에서 실행되면, 사용자는 현재 터미널을 사용할 수 없다.

새로운 터미널을 열어봄.

종료후

안보임.

멈춘 것을 확인

다시 start 명령어로 살릴 수 있음.

로그를 이렇게도 볼 수 있음

docker는 컨테이너 id, name 둘다 사용이 가능함

🐋 Docker 컨테이너 명령어 정리

명령어	주요 용도	비고
docker create	새로운 컨테이너를 생성만 할 때 사용	⚠️ 잘 사용하지 않음 (보통 `docker run`으로 대체됨)
docker run	이미지를 최초 실행할 때 사용 (없으면 자동 다운로드 후 실행)	가장 자주 사용
docker start	`docker ps -a`에서 Exited 상태인 컨테이너를 다시 실행할 때	중지된 컨테이너 재시작
docker exec -it <컨테이너명> /bin/bash	실행 중인 컨테이너에 들어가서 콘솔 명령어를 실행할 때	디버깅 및 설정용
docker stop <컨테이너명>	`docker ps`로 확인된 실행 중 컨테이너를 일시 정지할 때	컨테이너 종료
docker restart <컨테이너명>	`docker stop`으로 정지된 컨테이너를 다시 시작할 때	stop + start 결합 기능

💡 참고 팁

컨테이너를 실행할 때는 CONTAINER_ID보다 NAME으로 지정하는 것이
관리와 식별 모두 훨씬 편리하다.
CONTAINER_ID도 인식되지만, 너무 길어서 실무에서는 주로 --name 옵션을 사용한다.

📘 예시 명령어 흐름

docker run -d --name mynginx nginx:latest   # 컨테이너 실행
docker ps                                   # 실행 상태 확인
docker exec -it mynginx /bin/bash           # 내부 접속
docker stop mynginx                         # 중지
docker start mynginx                        # 재시작
docker rm mynginx                           # 삭제

docker는 데이터를 저장할 수 없기 때문이다.

ctrl+pq

🧩 핵심 요약: 컨테이너의 데이터 유지 규칙

상황	데이터 유지 여부	설명
`docker stop` → `docker start`	✅ 유지됨	컨테이너의 파일시스템이 그대로 남아 있기 때문에 Exited 후 재시작해도 데이터 존재
`docker rm` (삭제)	❌ 사라짐	컨테이너 자체가 삭제되므로 내부 데이터도 완전히 제거됨
`docker run` (새로 생성)	❌ 새 컨테이너라 데이터 없음	같은 이미지라도 완전히 새로운 인스턴스이므로 데이터는 새로 초기화됨
Volume 또는 Bind Mount 사용 시	✅ 영구 유지	`/var/lib/docker/volumes` 또는 호스트 디렉터리에 저장되어 컨테이너 삭제 후에도 유지 가능

🔍 예시로 보면

1️⃣ 컨테이너 생성 및 데이터 작성

docker run -it --name test1 centos:7 /bin/bash
echo "hello" > /tmp/data.txt
exit

2️⃣ 종료 후 다시 실행

docker start -ai test1
cat /tmp/data.txt
# 출력: hello ✅ (데이터 유지)

3️⃣ 컨테이너 삭제 후 재생성

docker rm test1
docker run -it --name test1 centos:7 /bin/bash
cat /tmp/data.txt
# 출력: No such file or directory ❌ (데이터 사라짐)

💾 원리 설명

컨테이너는 이미지 위에 얹힌 “임시 계층(Writable Layer)”에서 동작합니다.
stop 상태에서는 이 계층이 그대로 보존되지만,
rm으로 삭제하면 Writable Layer 자체가 사라져서 모든 변경 내용이 날아가요.
따라서 데이터를 영구히 유지하려면 반드시 Volume이나 Bind Mount를 사용해야 합니다.

✅ 정리 문장으로 기억

stop은 멈춤, 데이터 유지

rm은 삭제, 데이터 소멸

영구 보존하려면 Volume을 써라

“실제 Docker 컨테이너를 관리하는 하루 시나리오”처럼 자연스럽게 흐르는 예시
이걸 한 번 직접 따라 치면 run → exec → stop → start → ps → ps -a 흐름이 몸에 익습니다.

🧩 시나리오: “Nginx 컨테이너를 설치하고 관리하는 하루”

🕐 1단계: 새 컨테이너 생성 및 실행 (`docker run`)

처음으로 Nginx 서버를 띄워보자.

docker run -d --name web1 nginx:latest

📘 의미:

nginx:latest 이미지를 다운로드하여

web1이라는 이름의 컨테이너를

-d (백그라운드 모드)로 실행

이제 브라우저에서 localhost:80 으로 접속하면 nginx 화면이 보입니다.

🕑 2단계: 실행 중인 컨테이너 확인 (`docker ps`)

docker ps

✅ 결과: web1 컨테이너가 “Up” 상태로 표시됨

🕒 3단계: 실행 중인 컨테이너 내부 접속 (`docker exec`)

docker exec -it web1 /bin/bash

📘 의미:

실행 중인 web1 컨테이너에 접속해서 bash 쉘로 명령 실행

즉, 컨테이너 안의 “작업 현장”으로 들어간다.

컨테이너 내부에서 확인:

root@web1:/# echo "Hello Docker!" > /usr/share/nginx/html/index.html

이제 브라우저 새로고침 → "Hello Docker!" 페이지가 뜸 🖥️

🕓 4단계: 컨테이너 정지 (`docker stop`)

하루 작업이 끝나서 서버를 잠시 내린다.

docker stop web1

컨테이너가 정상 종료(Exited 상태)로 바뀜

🕔 5단계: 컨테이너 상태 확인 (`docker ps` vs `docker ps -a`)

docker ps

아무것도 안 나옴 (실행 중인 컨테이너 없음)

docker ps -a

web1이 “Exited” 상태로 표시됨

🕕 6단계: 컨테이너 다시 시작 (`docker start`)

서버를 다시 가동해보자.

docker start web1

web1이 다시 Up 상태로 전환됨 (데이터 유지됨)

🕖 7단계: 다시 확인 (`docker ps`)

docker ps

web1이 Up 상태로 다시 표시됨.
(아까 만들었던 “Hello Docker!” 페이지 그대로 유지됨 ✅)

🕗 8단계: 정리

처음 실행: docker run
실행 중 확인: docker ps
내부 접속: docker exec
정지: docker stop
재시작: docker start
전체 보기: docker ps -a

📋 전체 명령 흐름 한눈에 보기

docker run -d --name web1 nginx
docker ps
docker exec -it web1 /bin/bash
docker stop web1
docker ps
docker ps -a
docker start web1
docker ps

✅ 이해 포인트

run은 “처음부터 새로”
exec은 “이미 켜진 데 접속”
stop은 “잠시 멈춤”
start는 “다시 켜기”
ps, ps -a는 “상태 확인 도구”

[ 이미지 (Image) ]
│
▼
┌──────────────────────────────┐
│ docker run │
│ ▶ 새로운 컨테이너 생성 + 실행 │
└──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ 실행 중 (Running) │
│ • docker exec → 내부 접속 │
│ • docker ps → 실행 확인 │
│ • docker stop → 정지 │
└──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ 정지됨 (Stopped / Exited) │
│ • docker start → 재시작 │
│ • docker rm → 삭제 │
│ • docker ps -a → 전체 확인 │
└──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ 삭제됨 (Removed) │
│ • 다시 시작 불가 │
│ • docker run 으로 새로 생성 │
└──────────────────────────────┘

열공하는웅2

훌륭한 it 엔지니어 꿈나무

이전 포스트

클라우드

다음 포스트