Docker에 대해 공부해보자

도커는 사이드 프로젝트를 해보며 써본 경험이 있다. 

하지만 개념을 모른채, 당장 실무에 적용만 해보았다. 그래서 Docker에 대해 물어보면 잘 대답을 하지 못했다. 

이번 9주차에 Docker에 대하여 깊게 배웠는데, 나름대로 복습도 하고 공부도 하며 개념을 잊지 않기 위해 정리해본다.

---

 

1. 클라우드 및 Docker 개념 학습

우선 컨테이너에 대한 개념을 알아보자.

개발을 하다보면 운영체제, 라이브러리 버전, 설정파일 등에서 발생하는 환경 의존성 문제로 인해 다양한 문제가 발생할 수 있다.

나의 로컬에서의 버전와 프로젝트의 버전이 다르면 이러한 문제가 자주 발생한다.

Docker가 이러한 문제를 해결하기 위해 컨테이너라는 기술을 제공한다.

 

컨테이너란?

애플리케이션과 필요한 모든 요소(os, 라이브러리, 설정 등)을 하나의 패키지로 묶어 어디서나 동일한 환경에서 실행하 수 있도록 보장하는 기술이다. 

쉽게 말해 모든것들을 하나의 컨테이너로 묶어서, 그 컨테이너라는 묶음으로 다른 pc에서 펼쳐서 동일하게 실행할 수 있는 개념이다!

 

 

Docker의 개념

컨테이너 기반의 가상화 플랫폼으로, 응용 프로그램과 그 종속성을 격리된 환경인 컨테이너로 패키징하여 실행하는 기술이다. 

앞서 말한 컨테이너를 이 도커를 통해 사용할 수 있는 것이다

 

Docker의 특징

1. 경량화: 가상머신보다 더 적은 리소스를 사용하며 빠르다

2. 이식성: 한 번 컨테이너를 만들면 어떤 환경에서도 실행가능

3. 확장성: 컨테이너 기반의 마이크로서비스 아키텍처 구현에 최적화 되어 있다.

 

여기서 이해하는데 조금 어려웠던건 도커와 가상머신의 차이점이다.

가장 크게 두드러지는 차이점은 게스트os의 유무이다.

이 뜻은 즉, 가상머신은 하나씩 증가할 때 마다 os를 위한 자원을 할당해줘야한다는것이다. 그럼 당연히 리소스를 많이 쓰게 된다.

반면에 도커는, 실행에 필요한 패키지들만 있어도 구동할 수 있다.

 

도커는 OS 커널을 공유하여 애플리케이션과 실행 환경을 격리하고, VM은 하이퍼바이저를 통해 전체 하드웨어와 게스트 OS를 가상화하여 격리한다는 근본적인 차이가 있다.

 

하이퍼바이저를 이용하여 물리 서버의 하드웨어를 가상화한다. 그리고 각 VM마다 독립적인 게스트 os를 설치하여 실행하는 방식이다.

이 게스트 os를 설치할때 cpu, ram 등이 필요해서 무겁다.

 

반면 도커는 호스트 OS의 커널을 공유하며, 애플리케이션 실행에 필요한 라이브러리와 종속성만 패키징(컨테이너)하여 격리된 환경에서 실행한다. 즉 같은 운영체제를 공유하며 필요한 도구만 담은 격리된 작업 공간(컨테이너)'을 만드는 것이다

 

 

Docker의 구성요소 및 아키텍처

 

• Docker Client (CLI, REST API, UI)
  • 사용자가 Docker와 상호작용할 수 있도록 명령을 전달하는 인터페이스
  • CLI(Command Line Interface) 또는 REST API를 사용하여 컨테이너를 실행하거나 관리할 수 있음
• Docker Daemon (dockerd)
  • Docker의 핵심 엔진으로, 컨테이너와 이미지를 관리하는 역할
  • Clinet 로 부터 명령을 받아 컨테이너 생성, 네트워크 관리, 스토리지 할당 등을 처리
• Docker Images
  • 컨테이너를 실행하는 데 필요한 파일 시스템과 애플리케이션 코드가 포함된 템플릿
  • Layer 기반의 구조로, 같은 이미지에서 여러 개의 컨테이너 생성 가능
• Containers
  • 독립적으로 실행되는 애플리케이션 인스턴스
  • 각 컨테이너는 자체 파일 시스템과 네트워크 인터페이스를 가지며, 다른 컨테이너와 격리됨
  • docker run 명령으로 생성 가능
• Docker Registry (Docker Hub, Private Registry)
  • Docker 이미지를 저장하고 배포하는 서비스
  • Docker Hub(공개), Amazon ECR, Google GCR 등의 사설 레지스트리를 사용 가능
  • docker pull 또는 docker push 명령으로 이미지를 업로드/다운로드
• Storage & Networking
  • Storage: 컨테이너의 데이터를 지속적으로 저장하기 위해 Volumes, Bind Mounts, Tmpfs 사용
  • Networking: 브리지(Bridge), 호스트(Host), 오버레이(Overlay) 등의 네트워크 드라이버를 통해 컨테이너 간 통신을 제공

 

 

 

---

2. Docker 이미지 생성 및 docker hub

Docker 이미지란?

• Docker 이미지는 실행 가능한 애플리케이션을 포함한 패키지이며, 컨테이너를 실행하는 데 사용
• 컨테이너는 Docker 이미지를 기반으로 실행되며, 이미지에는 애플리케이션 코드, 라이브러리, 의존성 등이 포함
• Layer 기반 구조로 구성되며, 동일한 레이어를 공유하여 효율적인 스토리지 사용 가능

즉 이미지는 클래스와 같다. (실체화된 녀석이 아니지만, 실체화를 시킬수 있는 틀이다.)\

 

Dockerfile이란?

• Dockerfile은 Docker 이미지를 빌드하는 데 사용되는 스크립트 파일
• 기본 이미지 선택, 패키지 설치, 애플리케이션 복사, 실행 명령어 지정 등 다양한 설정 포함

Docker 이미지 최적화 방법

도커의 이미지 개념을 알기 전까지는 최적화를 도커에서 할 수 있다는걸 몰랐다.

하지만 이미지는 레이어 기반이다. 그렇다는 것은 레이어들이 많으면 많을수록 효율이 떨어지고, 이를 최적화 할 수 있다는 것이다.

 

 

 

도커는 베이스 이미지(FROM) 부터 시작하여, RUN, COPY, ADD 등등 명령어가 실행될때마다 레이어가 쌓이게 된다.

쓸데없이 레이어가 쌓이면? 당연히 성능이 비효율적이게 된다.

이때 레이어 최적화를 할 수 있다.

 

레이어 캐싱

이미지를 빌드할 때, Dockerfile의 각 명령어를 순서대로 실행하며 레이어를 만드는데,  이때 명령어의 내용이 이전 빌드와 동일하다면, 새로운 레이어를 만들지 않고 기존에 만들어 두었던 레이어를 재사용하는 방식

자주 변경되지 않는 내용은 앞부분에, 자주 변경되는 내용은 뒷부분에 배치하면 효율적으로 사용할 수 있다.

 

 

Dockerfile Multi Stage

하나의 Dockerfile 안에 독립된 여러 개의 빌드 단계를 정의하는 기능이다.

예를 들어 첫번째 빌드에서는 기본적인 환경세팅, 라이브러리 등을 구성하고, 두번째 빌드에서는 실제 결과물을 구성한다. 

이렇게 구성하면, 추후에 코드 내용이 변경되더라도 첫번째 빌드한 내용을 건들일 필요가 없는 장점이 있다.

 

 

---

3. Docker 네트워크 및 데이터 관리

해당 파트는 사용해본적이 아예 없고, 네트워크에 대한 지식이 부족하다 보니 어려웠다.

우선 도커에도 네트워크 개념이 있고, 컨테이너간 통신을 한다!

 

Docker 네트워크란?

• Docker 컨테이너 간 통신을 관리하는 기능
• 기본적으로 컨테이너는 격리된 환경에서 실행되며, 네트워크를 통해 서로 통신 가능

 

도커는 기본 명령어를 통해 각 컨테이너들의 네트워크가 어떤 건지 조회할 수 있다.

이렇게 각 컨테이너들의 네트워크 상태도 확인할 수 있다.

 

 

 

1. Bridge 네트워크 (디폴트값)

• 컨테이너 간 통신 가능, DNS 지원

도커의 브릿지 네트워크 모드는 컨테이너들이 서로 통신할 수 있게 해주는 가상의 네트워크 브릿지를 생성한다.

• 기본 bridge 네트워크에서 컨테이너 간 직접 통신이 안 되는 이유
  1. 기본 bridge 네트워크에서는 컨테이너 이름 기반 DNS 해석이 지원되지 않음
  2. IP 주소를 직접 사용해야 하지만, IP는 컨테이너 재시작 시 변경될 수 있어 관리가 어려움
  3. 사용자 정의 네트워크를 만들면 컨테이너 이름을 통해 자동으로 통신 가능
• 해결책
  • 기본 bridge 네트워크를 사용할 경우, 컨테이너 간 통신 시 IP 주소를 사용해야 한다.
  • 컨테이너 이름으로 통신하려면 사용자 정의 네트워크(docker network create <네트워크명>)를 사용해야 한다.

 

svc3와 svc4가 같은 네트워크(my-network)에 있꼬 서로 통신을 하고 있는걸 볼 수 있다.

 

 

2. Host 네트워크 

• 도커 컨테이너가 독자적인 네트워크 환경을 갖지 않고, 호스트 컴퓨터의 네트워크 환경을 그대로 공유하는 방식이다. 포트 매핑이 필요하지 않음 (p 옵션 불필요)
• 컨테이너가 마치 호스트에서 직접 실행되는 것처럼 동작

3. None 네트워크 

• 컨테이너가 어떠한 외부 네트워크와도 연결되지 않도록 하는 네트워크
• 이 네트워크 모드를 사용하면 컨테이너는 외부와의 네트워킹이 완전히 차단되며, 로컬호스트 내에서만 독립적으로 실행됨

4. Overlay 네트워크 

• Docker Swarm 클러스터 내의 다양한 노드에 걸쳐 있는 컨테이너들 사이의 통신을 가능하게 하는 네트워크
• 이 네트워크는 여러 호스트에서 실행 중인 컨테이너 간에 안전하고 격리된 네트워크를 구축할 수 있도록 해 준다.
• Overlay 네트워크는 내부적으로 VXLAN 기술을 사용하여 물리 네트워크 위에 가상 네트워크를 구축

5. macvlan 네트워크 

• Docker 컨테이너에 대한 고급 네트워킹 옵션을 제공하며, 각 컨테이너에 고유한 MAC 주소를 할당하여 물리 네트워크와 동일한 방식으로 통신하도록 한다.

 

대부분은 브릿지 네트워크를 사용한다.

 

 

 

---

4. Docker 를 활용한 Log 관리

Docker 볼륨이란?

• 컨테이너 내부의 데이터가 사라지는 문제를 해결하기 위해 사용
• 호스트 시스템의 특정 경로에 데이터를 저장하여 지속성 제공
• 컨테이너를 삭제해도 데이터는 유지됨

도커 컨테이너는 기본적으로 휘발성이다. 컨테이너를 삭제하면 내부에서 생성된 데이터도 함께 사라진다. 이를 해결하기 위해 도커는 데이터를 영구적으로 보존하거나 효율적으로 관리하는 방법을 제공한다.

 

• Container Storage(기본)
  • 컨테이너 내에 데이터를 저장하며, 컨테이너가 삭제되면 데이터도 함께 삭제된다 이 방식은 일시적인 데이터 저장이나 실험적 환경에 적합함. 읽기전용이다.
• Bind Mounts
  • 호스트 머신의 특정 절대 경로를 컨테이너 내부의 경로와 직접 연결(Mapping)하는 방식.  코드나 리소스를 컨테이너와 실시간으로 공유할 수 있어 편리함.
• Volumes (가장권장)
  • 도커가 직접 관리하는 호스트 파일 시스템의 특정 영역을 사용, 컨테이너가 삭제되어도 볼륨에 저장된 데이터는 유지된다. 데이터베이스나 중요한 파일 저장에 사용된다.
• Tmpfs Mounts
  • 메모리에 데이터를 저장하여 처리 속도가 매우 빠르나, 컨테이너가 종료되면 데이터는 사라진다. 보안이 중요한 임시 데이터 처리에 적합하다.

도커 볼륨 생성

MySQL 컨테이너 실행 (볼륨 마운트)

MySQL 접속 후 데이터베이스/테이블 생성 및 데이터 삽입

컨테이너 삭제 후, 다시 볼륨 생성하여 데이터 확인 > 볼륨에 데이터가 남아 있으면 삭제/재생성 이후에도 테이블 및 데이터가 유지된다.

 

 

볼륨 및 바인드 마운트 비교

• 어떤 경우에 어떤 방식을 사용해야 할까?
  • 볼륨: 데이터 영속성 보장, 컨테이너 간 공유
  • 바인드 마운트: 특정 호스트 디렉토리 사용 필요 시

 

1. 볼륨

그림에서 'Docker area'라고 표시된 부분으로 화살표가 가는 방식이다.

호스트 파일 시스템 내부에 도커가 관리하는 특정 디렉토리(리눅스 기준 /var/lib/docker/volumes/)를 전용 저장소로 사용한다.

도커 환경에 최적화되어 있어 바인드 마운트보다 성능이 안정적이며, 운영체제 간(Windows/Linux) 이동 시 경로 문제로부터 자유롭다.

-> 디비 저장소, 로그 보관, 백업 및 마이그레이션 등 중요한 데이터 보관에 용이하다.

 

 

2. 바인드 마운트 (내 컴퓨터와 실시간 연결)

호스트 시스템의 특정 절대 경로를 컨테이너 내부의 디렉토리와 직접 연결한다.

호스트에서 파일을 수정하면, 컨테이너에 즉시 반영된다. 반대로 컨테이너가 파일을 생성하면 내 컴퓨터 폴더에 바로 나타난다.

 

 

3. Tmpfs 마운트

메모리에 직접 데이터 저장