IT STUDY LOG
[Docker] 01. 왜 Docker인가? 본문
# 학습 목표
- 컨테이너 기술이 무엇인지, Docker가 왜 필요한지 알 수 있다.
- 컨테이너와 이미지, 레지스트리가 무엇인지 이해할 수 있다.
- 대표적인 레지스트리인 Docker Hub에서 이미지를 검색하고, 사용할 수 있다.
- 한 개의 이미지를 이용해서 컨테이너를 구축할 수 있다.
- 두 개 이상의 이미지를 이용해서 컨테이너를 구축하고 서로가 어떻게 연결되는지 알 수 있다.
- Docker CLI에서 명령어를 사용해서 이미지를 생성/수정/배포하고, 컨테이너를 생성/삭제할 수 있다.
- Dockerfile을 이용해 이미지를 생성할 수 있다.
- 애플리케이션을 컨테이너화할 수 있다.
# 학습 내용
목차
1. 컨테이너 기술과 Docker의 탄생 배경
2. 왜 Docker인가?
3. Docker 핵심 키워드
4. 컨테이너와 VM의 비교
1. 컨테이너 기술과 Docker의 탄생 배경
컨테이너
- 물류 컨테이너가 물자 수송에서 선박 입항 시간을 획기적으로 단축시키고, 필요한 인력을 대폭 감소시키는 아이디어에 착안
리눅스 컨테이너
- 소프트웨어의 배포에 사용
도커
- 리눅스 컨테이너에서 더 나아간 형태
- Docker Hub라는 소프트웨어 저장소와 함께 애플리케이션을 쉽게 빌드하고 컨테이너 방식으로 실행 가능
- 실행 환경에 구애받지 않고 애플리케이션 실행이 가능
2. 왜 Docker인가? - 컨테이너 방식의 장점
(1) 의존성 충돌 문제 해결
- 어떤 어플리케이션의 경우 해당 애플리케이션을 구축하기 위해 특정 환경이 구축되어 있어야 함
- 프로그램 A 실행에 다른 프로그램 B가 반드시 필요한 경우, 프로그램 A는 프로그램 B에 의존 관계를 가진다고 말함
- 의존성이 충돌하는 예시
컨테이너 기술을 통한 의존성 충돌 문제의 해결
- 애플리케이션을 컨테이너 내에 구성하므로, 컨테이너에서 실행 중인 애플리케이션은 어떠한 의존성도 공유하지 않고 각자 고유의 의존성을 포함
컨테이너가 격리하는 것
- 컴퓨터 안에 여러 대의 컨테이너가 존재하고, 이를 통해 애플리케이션 실행 환경이 격리
- 하나의 컴퓨터 내에 서로 다른 버전의 애플리케이션이 설치될 수 있는 것은 컨테이너 하나하나가 애플리케이션 실행과 관련해 높은 수준의 격리를 제공하기 때문
프로세스
- 특정 컨테이너에서 작동하는 프로세스는 기본적으로 그 컨테이너 안에서만 액세스가 가능
- 컨테이너 안에서 실행되는 프로세스는 다른 컨테이너의 프로세스에 영향을 줄 수 없음
네트워크
- 기본적으로 컨테이너 하나에 하나의 IP 주소가 할당
파일시스템
- 컨테이너 안에서 사용되는 파일 시스템은 구획화되어 있으므로 해당 컨테이너에서의 명령이나 파일 등의 액세스를 제한 가능
그렇다면 컨테이너는 가상 머신?
- 대표적인 가상머신 : VMware, VirtualBox, Barallels 등
- 도커를 비롯한 리눅스 컨테이너 기술은 가상 머신의 접근 방법과는 조금 다름
(2) 개발과 배포 환경의 일치
개발팀의 문제
기존 개발 방식
- 개발 환경을 구축하기 위해 특정 버전의 언어 (Java, Node.js 등)와 특정 버전의 DBMS(MySQL, Oracle 등) 등을 개발자들이 각각 본인의 OS에 설치
- 애플리케이션 실행을 위해 OS나 Node.js, Python과 같은 런타임 환경 버전 역시 얼추 비슷하게 맞추어야 하며, 시스템 환경 변수를 애플리케이션에 맞게 구성해야 제대로 작동
- 리눅스의 경우에도 배포판에 따라 전혀 다른 애플리 케이션 설치 과정이 진행
# 우분투에서 postgreSQL 설치
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get -y install postgresql
# CentOS에서 postgreSQL 설치
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo dnf -qy module disable postgresql
sudo dnf install -y postgresql14-server
sudo /usr/pgsql-14/bin/postgresql-14-setup initdb
sudo systemctl enable postgresql-14
sudo systemctl start postgresql-14∴ 개별 환경 구축, 사소한 실수나 사전 설치 항목 미비 등에 따른 시간 소모가 큼
도커를 적용한 개발 방식
- 도커가 실행 중이라면 O/S와 상관 없이 다음 명령어로 즉시 postgresSQL 설치, 실행이 가능
$ docker run --name postgres -e POSTGRES_PASSWORD=mysecret -d postgres- Docker Compose라는 툴을 이용해 애플리케이션 구성 자체를 컨테이너화할 경우 YAML 파일 하나, 명령어 하나로 모든 애플리케이션 실행 환경이 구성 가능
$ docker-compose up∴ OS와 상관 없이 즉시 애플리케이션 실행 환경을 만들 수 있으며, 컨테이너 환경에서 개발할 경우 모든 개발팀이 동일한 환경에서 개발 가능
배포 시의 문제
기존 배포 방식
- 웹 서비스 배포란 즉 "어떤 애플리케이션이 특정 런타임 환경 위에서 실행되고 이를 사용자에게 제공하는 것"
- 기존에는 서버에 파일 하나하나를 업로드하는 방식으로 서비스 제공
도커를 적용한 배포 방식
- Amazon Web Service EC2 상에 도커를 설치하거나, 도커 컨테이너를 EC2 서버에서 실행할 수 있게 하는 ECS를 사용해 쉽게 애플리케이션 배포가 가능
(3) 용이한 수평 확장 & 각 서버에 새로운 내용 배포가 용이
- 글로벌 웹 서비스의 경우 트래픽이 방대하므로(ex. 구글) 서비스 제공자들은 트래픽 분산을 위해 프록시프락시 서버를 운영하고, 프락시 서버는 여러 대의 동일한 서버 중 한 군데를 이용할 수 있도록 도움. 이러한 서버를 리버스 프락시의 한 종류인 로드 밸런서라고 칭함
- 컨테이너 기술의 가장 큰 장점은 "실행 환경의 일치"이므로 동일한 서비스가 여러 컴퓨터에서 작동하는 경우 도커를 적용하면 유용
- 트래픽으로 인한 서버 증설에 컨테이너 기술이 아주 활발하게 이용되는 중
- 동일한 애플리케이션 구성(=이미지)을 바탕으로 새로운 서버에 해당 애플리케이션을 컨테이너로 실행하고, 로드 뱁ㄹ런서에 이 서버를 추가하기만 하면 됨
- 해당 기술을 응용해 새로운 버전의 애플리케이션을 여러 서버 중 몇 대에만 운영해 테스트 하는 것도 가능 (새 버전의 문제 파악 및 영향도 최소화 가능)
- 쿠버네티스와 같은 오케스트레이션 도구가 이러한 일을 수행
3. Docker 핵심 키워드
컨테이너
- 애플리케이션이 의존성, 네트워크 환경, 파일 시스템에 구애받지 않고 도커라는 기술 위에서 실행 될 수 있도록 만든 애플리케이션 상자
이미지
- 이미지를 통해 실행되는 모든 컨테이너가 생성됨
- 이미지는 애플리케이션 및 애플리케이션 구성을 함께 담아놓은 템플릿
- 이미지를 이용한다면 여러 개의 컨테이너를 생성할 수 있으므로 수평 확장이 가능
- 이미지는 기본 이미지(base image)로부터 마치 git을 사용하는 것처럼 변경 사항을 추가/커밋해 또 다른 이미지를 만들 수 있음 (ex. node.js로 작성한 애플리케이션을 이미지로 만들고 싶다면 node.js 이미지를 기본 이미지로 삼고 내가 만든 애플리케이션을 추가해 이미지화할 수 있음)
- 참고 튜토리얼 : Node.js 웹 앱의 도커라이징
레지스트리
- 이미지가 저장되는 곳으로 도커 CLI에서 이미지를 이용해 컨테이너를 생성할 때, 호스트 컴퓨터에 이미지가 존재하지 않는다면 기본 레지스트리로부터 다운로드 받음
- 대표적인 이미지 레지스트리 : Docker Hub, Amazon ECR
4. 컨테이너와 VM의 비교
컨테이너와 VM의 작동 원리
VM
- 많은 컴퓨팅 자원 필요
- VM 사용을 위해서는 해당 VM 위에 OS를 설치하는 과정이 반드시 필요함
- VM을 생성하고 구동하는 소프트웨어인 하이퍼바이저(VirtualBox, VMware 등) 위에 VM이 올라감
컨테이너
- 한 호스트에 여러 컨테이너를 띄워도 크게 무리가 없음
- Docker Hub Registry를 통해 이미지를 살펴보면, 도커 이미지는 보통 애플리케이션 단위로 만들어져 있음 (OS 이미지도 존재하긴 함)
- 각 컨테이너는 호스트 OS의 커널(시스템 콜과 같이 OS의 핵심 기능을 구현한 프로그램)을 공유
- 도커의 목적은 애플리케이션을 컨테이너화해 실행하는 것이므로 특별히 컨테이너에 OS를 올릴 필요가 없음
- 호스트 OS 입장에서 컨테이너 하나는 프로세스 하나
💡 그렇다면 Docker Hub에 존재하는 각종 OS는 무슨 용도일까?
- 예를 들어 우분투, CentOS는 "동일한 리눅스 커널" 위에 만들어진 배포판이지만 각자 고유 디렉터리 구조, 패키지 시스템(apt, yum), 쉘(bash, zsh) 등을 사용함
- OS 이미지는 컨테이너 내 애플리케이션 구성의 편의를 위해 존재
💡 윈도우나 macOS용 도커의 경우 컨테이너 안 쪽은 리눅스로 작동되는데, 윈도우나 macOS는 리눅스가 아닌데 어떻게 컨테이너 안에서 리눅스 기반으로 작동할까?
- 윈도우나 macOS는 리눅스 커널을 사용하지 않으므로 해당 운영체제의 경우 리눅스 커널을 VM 형태로 실행시키는 하이퍼바이저를 자체적으로 구동
- 윈도우용, macOS용 도커는 하이퍼바이저 위의 리눅스 커널을 사용
- 윈도우용 도커의 경우 윈도우 커널을 사용한 윈도우 전용 컨테이너를 실행할 수 있는 기능을 제공하는데, 윈도우 커널을 사용하는 컨테이너는 리눅스용 도커에서는 사용이 불가함 (∵컨테이너는 커널을 공유)
💡 도커의 IP 주소는 어떻게 정해질까?
- Docker 데몬의 IP 주소는 Docker의 네트워킹 모드에 따라 다르게 정해짐
- 기본적으로 Docker는 "bridge" 네트워킹 모드를 사용하며, 이 모드에서 Docker 데몬은 가상의 브리지 네트워크를 생성하고, 컨테이너들은 이 가상 브리지 네트워크에 연결
- Docker 데몬의 IP 주소는 이 가상 브리지 네트워크의 IP 주소 범위 중에서 랜덤하게 선택되며, 기본적으로 Docker는 172.17.0.0/16 IP 주소 범위를 사용
- 따라서 Docker 데몬의 IP 주소는 이 범위 내에서 랜덤하게 할당되며, 새로운 가상 브리지 네트워크가 생성될 때마다 IP 주소가 변경될 수 있음
- docker 데몬의 IP 주소는 docker0라는 이름의 가상 네트워크 인터페이스에 할당되며, ifconfig나 ip addr 등의 명령어를 사용하여 확인 가능
- docker0 인터페이스의 IP 주소는 Docker 데몬의 IP 주소로 사용되고, Docker 컨테이너들이 이 IP 주소를 통해 Docker 데몬과 통신
# References
챗 gpt
'devops bootcamp 4 > 클라우드 서비스 운영' 카테고리의 다른 글
| [Docker] 03. Docker Image 다루기 (0) | 2023.04.12 |
|---|---|
| [Docker] 02. Docker CLI (0) | 2023.04.12 |
| [Docker] 00. Before You Learn (0) | 2023.04.11 |
| [YAML] 01. YAML과 JSON (0) | 2023.04.11 |
| [네트워크 기초] 02. 아키텍처를 구성하는 요소들 (0) | 2023.04.07 |
