Docker의 전체 그림

Docker를 이해하려면 먼저 큰 그림을 잡는 것이 중요.

처음부터 이미지, 컨테이너, 호스트, 포트, 볼륨 같은 용어를 전부 외우려고 하면 오히려 혼란.

그래서 먼저 봐야 할 것은 호스트, 이미지, 컨테이너의 관계.

호스트는 컨테이너가 실행되는 바깥쪽 컴퓨터.

이미지는 컨테이너를 만들기 위한 재료.

컨테이너는 이미지를 실제로 실행한 독립된 공간.

이 세 가지 관계를 이해하는 것이 Docker 구조를 이해하는 출발점.

 

Docker란 무엇인가

Docker는 애플리케이션을 컨테이너라는 독립된 실행 공간에서 실행할 수 있게 해주는 도구.

쉽게 말하면 내 컴퓨터 안에 프로그램별로 분리된 실행 공간을 만들어주는 기술.

이 공간 안에는 프로그램 실행에 필요한 파일, 라이브러리, 설정 등이 포함.

그래서 애플리케이션을 운영체제에 직접 설치하는 방식보다 더 깔끔한 분리 실행 가능.



예를 들어 Nginx를 사용한다고 가정.

일반적인 방식이라면 내 컴퓨터에 Nginx를 직접 설치해야 하는 과정.

설치 명령어 입력.

설정 파일 위치 확인.

서비스 실행.

필요하면 방화벽이나 포트 설정까지 확인.



하지만 Docker를 사용하면 Nginx 이미지를 가져와 컨테이너로 실행 가능.

이 경우 Nginx는 내 컴퓨터 전체에 직접 설치되는 것이 아니라, 분리된 실행 공간 안에서 동작하는 구조.

여기서 중요한 점은 Docker가 프로그램을 내 컴퓨터에 직접 흩뿌려 설치하는 방식이 아니라는 점.

이미지를 바탕으로 컨테이너를 만들고, 그 안에서 프로그램을 실행하는 방식.

 

호스트 컴퓨터란 무엇인가

호스트 컴퓨터는 컨테이너를 실행하는 바탕이 되는 컴퓨터.

내 노트북에서 Docker를 실행한다면 내 노트북이 호스트.

AWS EC2 서버에서 Docker를 실행한다면 EC2 서버가 호스트.

즉, 호스트는 컨테이너를 품고 있는 바깥쪽 컴퓨터.

그 위에 여러 개의 독립된 실행 공간이 올라가는 구조.



Mac을 사용할 때는 한 가지 보충 필요.

Docker 컨테이너는 기본적으로 Linux 커널 기능을 사용.

그런데 macOS는 Linux가 아닌 운영체제.

그래서 Docker Desktop은 내부적으로 작은 Linux 가상 환경을 만들고, 그 위에서 컨테이너를 실행하는 구조.



처음 공부할 때는 "내 Mac에서 Docker가 컨테이너를 실행한다"라고 이해해도 충분.

다만 더 정확히는 Docker Desktop 내부의 Linux 환경 위에서 컨테이너가 실행되는 구조.

이 부분은 나중에 Linux 서버나 EC2에서 Docker를 사용할 때 더 잘 이해되는 내용.

 

이미지란 무엇인가

이미지는 컨테이너를 만들기 위한 실행 틀.

컨테이너가 실제로 실행 중인 공간이라면, 이미지는 그 공간을 만들기 위한 설계도 또는 재료 묶음.

예를 들어 nginx 이미지는 Nginx 실행에 필요한 파일과 설정을 담은 이미지.

postgres 이미지는 PostgreSQL 실행에 필요한 파일과 설정을 담은 이미지.

openjdk 이미지는 Java 애플리케이션 실행을 위한 JDK 환경.

node 이미지는 Node.js 애플리케이션 실행을 위한 Node 환경.



처음에는 이미지를 프로그램 자체로 생각하기 쉬움.

하지만 이미지는 실행 중인 프로그램이 아닌 실행 전 준비물.

이미지를 실행해야 컨테이너 생성.

그리고 그 컨테이너 안에서 실제 프로그램 동작.



즉 이미지는 실행 전 상태.

컨테이너는 그 이미지를 바탕으로 실제 실행된 상태.

 

컨테이너란 무엇인가

컨테이너는 이미지를 실제로 실행한 독립된 공간.

처음에는 작은 실행 방처럼 생각하면 이해하기 쉬움.

각 컨테이너는 자기만의 파일 공간 보유.

자기만의 실행 프로세스 보유.

분리된 네트워크 공간 보유.



그래서 A 컨테이너 안에서 실행되는 프로그램과 B 컨테이너 안에서 실행되는 프로그램은 서로 분리.

A 컨테이너 안의 파일을 B 컨테이너가 마음대로 볼 수 없는 구조.

B 컨테이너 안에서 실행 중인 프로세스를 A 컨테이너가 마음대로 건드릴 수 없는 구조.



하지만 컨테이너를 완전한 가상머신과 똑같이 생각하면 안 되는 부분.

가상머신은 운영체제 전체를 새로 띄우는 방식에 가까움.

반면 컨테이너는 호스트의 커널을 공유하면서 애플리케이션 실행 공간만 격리하는 방식.

그래서 가상머신보다 가볍고 빠른 실행 가능.



쉽게 말하면 컨테이너는 진짜 컴퓨터 한 대라기보다는, 컴퓨터처럼 보이도록 분리된 실행 공간.

각 공간마다 필요한 프로그램과 파일이 들어 있고, 서로의 영역을 함부로 침범하지 못하도록 나뉘어 있는 구조.

 

이미지와 컨테이너의 관계

이미지와 컨테이너의 관계는 붕어빵 틀과 붕어빵으로 비유 가능.

이미지는 붕어빵 틀.

컨테이너는 그 틀로 찍어낸 실제 붕어빵.



같은 이미지에서 여러 개의 컨테이너 생성 가능.

예를 들어 nginx 이미지 하나로 여러 개의 Nginx 컨테이너 실행 가능.

각각은 같은 이미지를 바탕으로 만들어졌지만 서로 다른 실행 공간.



하나의 컨테이너를 삭제해도 이미지 자체가 바로 삭제되는 것은 아님.

이미지가 남아 있으면 그 재료를 사용해 다시 컨테이너 생성 가능.



처음 배울 때 가장 많이 헷갈리는 부분이 이미지 삭제와 컨테이너 삭제의 차이.

컨테이너 삭제는 이미지를 바탕으로 실행된 결과물을 삭제하는 것.

이미지 삭제는 컨테이너를 만들기 위한 재료 자체를 삭제하는 것.



컨테이너는 실행된 결과.

이미지는 그 결과를 만들기 위한 원본 재료.

이 차이 구분이 Docker 명령어 이해의 핵심.



 

Docker 실행 흐름

Docker의 기본 실행 흐름은 생각보다 단순.

먼저 이미지 가져오기.

그 이미지를 바탕으로 컨테이너 실행.

컨테이너 안에서 프로그램 동작.

필요하면 외부에서 접근할 수 있도록 포트 연결.

실행 상태 확인.

문제가 생기면 로그 확인.

필요하면 내부에 들어가 파일이나 설정 확인.



예를 들어 Nginx를 실행한다고 가정.

먼저 Nginx 이미지 필요.

내 컴퓨터에 해당 이미지가 없다면 Docker Hub에서 가져오는 과정 필요.

그 다음 이미지를 실행하면 Nginx 컨테이너 생성.

컨테이너 안에서 Nginx 프로세스 실행.

호스트 포트와 컨테이너 포트를 연결하면 브라우저에서 화면 확인 가능.



여기서 중요한 흐름은 하나.

이미지 가져오기.

컨테이너 실행.

프로그램 동작.

외부 접속을 위한 포트 연결.



이 흐름이 Docker 기본 사용법의 출발점.

 

Docker Hub란 무엇인가

Docker Hub는 Docker 이미지를 받을 수 있는 저장소.

쉽게 말하면 Docker 이미지들이 모여 있는 공개 창고.

Nginx, MySQL, PostgreSQL, Redis, Node, OpenJDK 같은 대표적인 이미지들이 Docker Hub에 등록.



처음부터 모든 이미지를 직접 만들 필요는 없음.

이미 공개되어 있는 이미지 사용 가능.

Nginx를 실행하고 싶다면 nginx 이미지 사용.

PostgreSQL을 실행하고 싶다면 postgres 이미지 사용.

Redis를 실행하고 싶다면 redis 이미지 사용.



나중에는 내가 만든 Spring Boot 프로젝트도 Dockerfile을 통해 이미지화 가능.

그 이미지를 Docker Hub나 AWS ECR 같은 저장소에 올리고, 서버에서 받아 실행 가능.



Docker Hub는 처음에는 이미지를 내려받는 곳.

나중에는 내가 만든 이미지를 보관하는 저장소 개념으로도 연결.

 

컨테이너의 독립성

컨테이너는 독립된 실행 공간을 가짐.

이 독립성 때문에 Docker가 유용한 도구.



첫 번째는 파일 시스템의 독립성.

컨테이너마다 자기만의 파일 공간 보유.

A 컨테이너 안의 파일을 B 컨테이너가 마음대로 볼 수 없는 구조.

그래서 각각의 애플리케이션을 분리해서 실행하기 좋은 방식.



두 번째는 프로세스의 독립성.

컨테이너 안에서 실행되는 프로그램은 해당 컨테이너 내부 프로세스로 관리.

호스트에서 보면 Docker가 실행한 프로세스이지만, 내부에서는 자기만의 실행 환경처럼 보이는 구조.



세 번째는 네트워크의 독립성.

컨테이너는 자기만의 네트워크 공간을 가질 수 있음.

그래서 컨테이너 내부에서 말하는 localhost와 내 컴퓨터에서 말하는 localhost는 서로 다른 대상일 수 있음.



이 부분은 처음에 헷갈리기 쉬운 지점.

내 컴퓨터에서 localhost는 내 컴퓨터 자신.

Spring Boot 컨테이너 안에서 localhost는 Spring Boot 컨테이너 자신.

MySQL 컨테이너 안에서 localhost는 MySQL 컨테이너 자신.



그래서 나중에 Spring Boot와 MySQL을 함께 실행할 때 localhost 대신 service 이름 사용.

이 내용은 Docker Compose와 네트워크를 다룰 때 다시 등장하는 중요한 개념.

 

컨테이너는 왜 쉽게 지우고 다시 만들 수 있는가

Docker에서는 컨테이너를 오래 고쳐 쓰기보다 새로 만들어 교체하는 방식이 자연스러움.

애플리케이션 코드가 바뀌면 이미지를 새로 만들고, 새 이미지로 컨테이너를 다시 실행하는 방식.

기존 컨테이너 안에 직접 들어가 이것저것 수정하는 방식은 좋은 관리 방법이 아님.



이유는 단순.

컨테이너 안에서 직접 수정한 내용은 기록으로 남기 어려움.



예를 들어 누군가가 컨테이너 내부 설정 파일을 직접 수정했다고 가정.

그 순간에는 문제가 해결된 것처럼 보일 수 있음.

하지만 나중에 컨테이너를 삭제하고 다시 만들면 그 수정 내용은 사라질 수 있음.

어떤 설정을 바꿨는지 기록도 애매한 상태.



그래서 Docker에서는 실행 환경을 Dockerfile이나 compose.yml 같은 파일로 관리하는 것이 중요.

컨테이너 안에서 직접 고치는 방식이 아니라, 이미지를 만드는 파일과 실행 설정 파일에 기록해두는 방식이 더 안전.



컨테이너는 영구적으로 아껴가며 쓰는 서버 한 대라기보다는 필요할 때 만들고 교체할 수 있는 실행 단위.

 

컨테이너 내부 데이터 문제

컨테이너는 쉽게 삭제하고 다시 만들 수 있다는 장점.

하지만 이 특징 때문에 생길 수 있는 문제도 존재.

컨테이너 내부에 중요한 데이터를 저장하면 삭제 시 함께 사라질 수 있기 때문.



예를 들어 MySQL이나 PostgreSQL 컨테이너를 실행했다고 가정.

그 안에 데이터베이스와 테이블을 만들고 데이터를 저장한 상태.

그런데 컨테이너를 삭제하고 다시 만들면 기존 데이터가 사라질 수 있음.



웹 서버처럼 다시 띄우면 되는 경우에는 큰 문제가 아닐 수 있음.

하지만 데이터베이스는 다른 문제.

회원 정보, 게시글, 주문 내역, 로그 같은 중요 데이터가 들어갈 수 있기 때문.

이 데이터가 컨테이너 삭제와 함께 사라지면 서비스 입장에서는 큰 문제.



그래서 데이터베이스 컨테이너에서는 Volume이라는 개념 필요.

Volume은 컨테이너 안에만 데이터를 저장하지 않고, 호스트 쪽 저장 공간에 데이터를 따로 보존하는 방법.

컨테이너는 지우고 다시 만들어도 데이터는 남겨두기 위한 구조.


여기서는 컨테이너는 쉽게 교체할 수 있지만, 데이터는 따로 보존해야 한다는 관점만 이해하면 충분.

 

Docker를 이해하는 최소 구조

Docker를 처음 공부할 때 최소한 다음 구조를 머릿속에 넣어두면 충분.


호스트 위에서 Docker 실행.

Docker가 이미지 가져오기.

가져온 이미지를 바탕으로 컨테이너 생성.

컨테이너 안에서 애플리케이션 실행.

필요하면 포트와 Volume을 연결해서 외부 접속과 데이터 보존 처리.


이 정도 구조를 잡고 나면 이후 명령어 이해가 훨씬 쉬움.

 

docker pull은 이미지를 가져오는 명령어.

docker run은 이미지를 컨테이너로 실행하는 명령어.

docker ps는 실행 중인 컨테이너를 확인하는 명령어.

docker stop은 컨테이너를 중지하는 명령어.

docker rm은 컨테이너를 삭제하는 명령어.

docker image rm은 이미지를 삭제하는 명령어.



명령어를 외우기 전에 이미지와 컨테이너의 관계를 먼저 이해해야 하는 이유가 여기에 있음.