Docker 기본 정리 (feat. 그림과 실습으로 배우는 도커 & 쿠버네티스)

책 소개

이름만 들어 본 도커와 쿠버네티스를 공부해 보고자 책을 한 권 빌려왔는데, 그 책이 너무 어려워서 한 장을 넘어가는 게 어려웠다. 그래서 좀 더 쉬운 책을 찾아보다가 발견한 보물 같은 책!
기본적으로 도커와 쿠버네티스가 뭔지도 모르는 사람에게 계단을 밟아 올라가듯 쉽게 단계별 설명을 제공한다. 더불어 단순 텍스트가 아닌 그림과 함께 제공이 되기 때문에 기술 서적 임에도 불구하고 다음이 궁금해서 계속 읽게 되는 책. 기술 그 자체가 아닌 저자에게 감탄한 첫 책이지 않나 싶다.

 

그림과 실습으로 배우는 도커 & 쿠버네티스

이 책은 컨테이너 기술이 어렵게 느껴지는 엔지니어나 백엔드 기술에 자신이 없는 분들을 위한 도커 입문서입니다. 자세한 그림과 친절한 실습을 통해 리눅스 지식이나 서버 구축 경험이 없어도 컨테이너와 도커, 쿠버네티스에 대한 지식을 쉽게 이해할 수 있습니다. 도커의 개념부터 동작 방식, 명령어 사용법, 컨테이너 운용, 나아가 도커 컴포즈와 쿠버네티스까지, 컨테이너 기술에 대한 배경지식이 전혀 없는 분들도 도커와 쿠버네티스의 개념과 기초 사용법을 익힐 수 있도록 안내합니다. 도커나 쿠버네티스를 배우고 싶은 초보자라면 철저하게 입문자의 눈높이에 맞춘 이 책으로 도커의 세계에 첫발을 내디뎌 보세요.

저자

오가사와라 시게타카

출판

위키북스

출판일

2022.04.05

목차 정리

목차는 도커를 이해하는 것부터 시작해서 왜 쿠버네티스가 필요한 지 까지를 설명한다.
사실상 쿠버네티스에 대한 설명은 가장 마지막에 이제 도커의 기본을 알았으니, 다음 스텝이 뭔지를 알려주는 수준으로 제공되고 있다.

1장 : 도커의 정의
2장 : 도커의 동작 원리 (구성 요소, 생애주기, 장/단점)
3장 : 도커 사용 (설치 및 기본 사용 법)
4장, 5장 : 도커 활용 (컨테이너 설치 및 실행)
6장 : 도커 심화 (도커 활용에 필요한 기술)
7장 : 도커 확장 ( 도커 컴포즈)
8장 : 쿠버네티스

한 번 읽는다고 모든 걸 기억할 수 있지 않기에 중요 개념 정도는 정리를 해두려고 한다.

도커의 정의

도커를 한 마디로 정의하면 ‘데이터 또는 프로그램을 격리시키는 기능’이다.
조금 더 풀어 말하면 다양한 프로그램과 데이터를 독립된 환경에 격리하는 기능을 제공한다.

그렇다면 왜 격리된 환경이 필요할까?

하나의 서버에 여러 개의 프로그램을 구동하는 경우, 가장 흔하게 발생하는 문제는 공유되는 자원의 버전 문제이다.
여러 개의 프로그램이 버전이 다른 라이브러리를 요구할 경우, 서버에서 어떤 라이브러리 버전을 유지해야 할 지에 대한 고민이 필요하다. 한쪽에 맞출 수 있다면 해결 가능하지만 맞출 수 없다면 라이브러리 버전을 맞추기 위해 추가 개발을 해야 하는 상황이 오기도 한다.
이런 경우, 각자 다른 환경을 가지고 있다면 각자 다른 버전을 갖고 있으면 고민할 일도 추가 개발을 할 일도 없어진다.
격리된 환경이 필요한 이유가 당연히 하나만은 아니다. 대표적인 예 일 뿐이다.

격리 환경을 만들기 위한 구성 요소

격리된 환경 자체를 의미하는 ‘컨테이너’
격리된 환경을 찍어낼 수 있는, 일종의 빵 틀과 같은 역할을 하는 ‘이미지’
이미지를 가지고 환경을 만들어 주는 것이 ‘도커 엔진’이다.

당연히 도커 엔진은 이미지로 여러 개의 같은 컨테이너를 생성할 수 있다. 하드웨어가 사용 가능 한 범위에서.

도커와 서버?

서버는 보통 아래의 두 가지의 의미로 사용된다.

• 여러 사람이 접속해서 사용할 수 있는 물리적인 컴퓨터로써 의미와
• 특정 서비스를 제공하는 의미

하나의 컴퓨터가 있을 경우 보통 ‘웹 서버’, ‘메일 서버’와 같이 여러 개의 서비스를 동시에 제공하게 되는데 이때 이 컴퓨터는 기능적 의미로서 2개의 서버 이자, 물리적으로 하나의 서버가 되는 것이다.
보통 비용과 관련되어서 여러 개의 서버를 못 두는 경우 여러 서비스를 하나의 물리적 서버를 통해서 제공하게 되는데, 이럴 경우 하나의 서비스가 다른 서비스에 필연적으로 영향을 줄 수밖에 없게 된다.
이런 상황에서 도움을 줄 수 있는 것이 도커이다.
도커를 이용해 각기 다른 환경을 만들어서 서비스를 제공하게 만든 다면 서비스 간의 영향도를 줄일 수 있다.

또한 도커를 이용해 생성된 컨테이너는 서버 의존성이 있지 않기 때문에, 개발 서버와 운영 서버에 동일한 컨테이너를 올릴 경우 동일한 환경에서 구동이 되는 것이 보장된다는 장점도 있다.
개발 서버와 운영 서버를 오가며 웹 서버 설정을 했었다면, 그럴 필요가 없는 셈이다.

도커의 동작 원리

동작 원리의 핵심은 도커는 ‘리눅스’에서만 구동 가능하며, 도커에서 생성한 컨테이너는 ‘리눅스의 주변 부분’을 가지고 있다. 주변 부분을 통해 실제 하드웨어의 리눅스 운영 체제에 있는 커널로 명령을 내리기 때문에, 도커는 리눅스에서만 구동이 가능한 것이다.

리눅스의 주변 부분 이란?

커널을 제외한 부분으로 커널을 제외하고 있기 때문에 가볍게 유지할 수 있다. Cent OS와 같은 리눅스 배포 판은 커널 + 주변 부분으로 구성이 된다.

윈도와 Mac os는 도커 사용이 불가한 가?

가상 환경 위에 리눅스 운영 체제를 설치하거나, 도커를 실행하는데 필요한 리눅스 운영 체제를 포함하는 패키지(도커 데스크톱)를 설치하게 되면 사용 가능하다. (ex. Hyper-V)

이미지, 컨테이너, 도커 허브 그리고 컨테이너 생애 주기

위에 설명한 대로 도커는 이미지(빵 틀)를 통해 컨테이너 (빵)를 생성한다.
도커를 사용하는 것은 ‘격리 환경’을 만드는 것이기 때문에 ‘컨테이너’ 또한 운영체제와 소프트웨어가 포함된 ‘환경’인 것이다.

그렇다면 이미지는 어떻게 만드는 것일까?

도커 허브(Docker)를 통해 유명한 이미지는 대부분 구할 수 있다. 다만 공인된 이미지와 아닌 것이 있으니 유의해야 한다.

컨테이너를 통해 이미지를 생성하는 것 또한 가능

도커 허브를 통해 받은 이미지 -> 컨테이너 생성 -> 필요한 환경 추가 구축 -> 컨테이너로부터 이미지 생성 -> 여러 개의 컨테이너 생성

위의 과정을 거치기 때문에 원하는 환경을 복제하는 것이 가능해진다.

컨테이너의 수명

컨테이너는 단순히 ‘환경’이기 때문에 업데이트를 하지 않고 ‘업데이트된 이미지’를 통해 새로운 컨테이너를 생성한다.
그렇기 때문에 업데이트가 필요한 시점이 온다면 해당 컨테이너는 ‘버린다’
일회용품인 것이다.

당연히 데이터는 컨테이너가 아닌 ‘외부 하드웨어’에 저장되어 있다.
컨테이너 안에 데이터를 넣을 수 있기에 폐기 전 확인은 필요하지만, 기본적으로 컨테이너는 쓰고 버리는 것이라는 개념을 기억해야 한다.

도커의 장단점과 용도

장점은 ‘복제 가능한 독립된 환경’으로 할 수 있는 모든 것이다.

• 동일한 개발 환경 구축 -> 컨테이너 이미지 활용
• 쉬운 테스트 환경 구축 -> 새로운 컨테이너 생성 후 테스트
• 여러 대의 서버와 유사한 환경 구축 -> 여러 개의 컨테이너 생성

저자가 단점으로 적어둔 것들은 개인적으로는 도커 자체의 문제라기보다는 도커가 필요한 상황이라면 단점이 될 수 없는 것이라 패스.

도커의 사용

실습까지 정리할 필요는 없을 것 같아서 간단히 필요한 내용만 정리

도커 실행 조건

64비트 운영체제에서만 동작
리눅스 운영 체제에서만 동작. 윈도, Mac os는 추가 환경 설치가 필요 (가상 환경 혹은 도커 데스크톱 등)

도커 명령어의 기본

docker 상위 명령 (하위 명령) (옵션) 대상 (인자)
ex) docker container run penguin
-> container 상위 명령 / run 하위 명령 / penguin 대상

컨테이너의 경우 상위 명령을 생략하고 작성해도 무방한 경우가 있다.
docker container run -> docker run

컨테이너의 생애주기

이미지 내려받기 -> 생성 -> 실행 -> 정지 -> 폐기 -> 이미지 폐기

생애 주기를 보면 컨테이너는 실행 중 폐기가 불가하다.
컨테이너를 폐기해도 이미지는 남아있다. 이미지는 틀이기 때문에 별도로 폐기하는 절차를 거쳐야 한다. 이미지 용량은 적지 않기 때문에 사용하지 않는 이미지는 바로 삭제하는 것이 좋다.

컨테이너 간의 연결

컨테이너 간의 연결은 도커 네트워크를 통해서 한다
워드프레스 컨테이너와 MySQL 컨테이너가 있을 경우, 두 개의 컨테이너를 생성한다고 해서 워드프레스 컨테이너가 MySQL 컨테이너에 읽고 쓰고 할 수가 없다. 이럴 때 가상 네트워크를 만들어서 두 컨테이너를 연결해 준다.

도커 응용

도커 관련된 응용 기술은 총 7가지가 적혀 있으며, 도커 허브는 옵션에 가깝고 도커 컴포즈는 아무래도 쿠버네티스를 쓴다면 필수라고 보기 어렵다. 아래 목록은 아래로 내려갈수록 옵션에 가깝다고 생각하면 될 것 같다.

• 파일 복사
• 볼륨 마운트
• 컨테이너 이미지 생성
• 컨테이너 개조
• 도커 허브
• 도커 컴포즈
• 쿠버네티스

위의 기술을 정리하는 것은 아마도 좀 더 공부를 하면서 따로 정리를 할 것 같아 포인트 중심 정도로 정리를 하였다.

파일 복사

호스트와 컨테이너 양방향 복사가 가능하다.

docker cp 원본_경로 복사_경로 

볼륨/바인드 마운트

볼륨은 저장 공간을 분할한 것이고, 마운트는 연결하다는 의미 정도로 생각하면 된다. 이 기능이 필요한 것은 컨테이너는 일회용이기 때문에 데이터를 컨테이너 내부가 아닌 외부에 두는 것이 일반 적이다. 이를 ‘data persistency’라고 부른다. 이때 데이터를 두는 장소가 마운트 된 스토리지 영역이다. (연결된 저장 공간이라는 의미)

데이터를 연결하는 방법은 두 가지가 있는데, 볼륨 마운트와 바인드 마운트가 있다. 임시 메모리 마운트라는 것도 있으나, 메모리 영역을 마운트 해서 도커 엔진 정지 혹은 재부팅으로 소멸하는 연결 방식이라 깊게 다루지 않은 듯함.

볼륨 마운트

도커 엔진이 관리하는 영역 내에 만들어진 볼륨을 컨테이너에 디스크 형태로 연결하는 것

• 도커 엔진 관리 하에 있으므로 사용자가 파일 위치를 신경 쓸 필요 없음. 이름만으로 관리가 가능
• 실수로 삭제할 여지가 적음 (도커 엔진 관리 하에 있으므로)
• 운영 체제에 따라 명령어가 달라지는 등 의존성 문제없음 (윈도, mac os 상관없이 이름만으로 사용하므로 환경에 따라 경로 변경도 없음)
• 직접 조작이 어렵고 백업도 어려움
• 임시 혹은 자주 쓰지 않지만 지우면 안 되는 파일을 두는 목적으로 많이 사용
• 볼륨 마운트의 백업은 임시 컨테이너를 만든 후, 볼륨 마운트를 압축하여 저장하고, 바인드 마운드로 외부 컴퓨터의 폴더에 연결을 하는 방식으로 진행 (복잡하므로 심도 있게 다루진 않음)

바인드 마운드

• 도커가 설치된 컴퓨터의 폴더를 컨테이너에 연결하는 방식. 폴더가 아닌 파일 단위로도 연결이 가능하다.
• 도커 엔진 밖에 있고 컴퓨터 내의 일반 폴더이므로 파일을 옮겨두거나, 열어보기 쉬움
• 자주 사용하는 파일을 두는 데 사용
• 컨테이너로 이미지 생성 commit 명령어와 dockerfile 스크립트로 생성하는 두 가지 방법이 있고 특별한 차이가 없다.
  이미지는 이미지 상태 그대로 옮기거나 복사가 불가하므로 도커 레지스트리 혹은 save 명령어를 통해 도커 엔진의 관리 영역 밖으로 내보내야 한다. (다시 가져올 때는 load 명령어 사용)

컨테이너 개조

누군가 만든 이미지로 컨테이너를 생성했다면 그 안에서 부가적으로 필요한 작업을 해야 하는데 이를 컨테이너 개조라고 부른다.
두 가지 방법이 있고 보통 혼용한다.
첫 번째는 파일 복사와 마운트를 이용하는 방식이고,
두 번째는 컨테이너 내에서 리눅스 명령어를 실행하는 방식 (소프트웨어 설치, 설정 변경 등)

 

두 번째 방식을 하기 위해서는 쉘(shell)이 있어야 하고, 쉘이 실행 상태여야 하는데 컨테이너를 실행하면 기본적으로 쉘 실행 상태가 아니다.
실행시키기 위해 docker run에 인자를 넣거나 docker exec를 활용한다.
이미 실행 중인 컨테이너의 경우 run 사용이 불가하므로 exec를 활용하며, docker run을 썼을 경우는 컨테이너 내의 소프트웨어가 아닌 bash를 실행하게 되므로(= 컨테이너는 실행 중인데, 내부 소프트웨어는 실행 중이지 않은 상태) 작업이 완료되면 docker start 명령을 통해 컨테이너 재 시작이 필요하다.

 

너무 당연하겠지만 명령을 입력하고 있는 창은 하나인데 docker exec를 통해 컨테이너 내의 bash를 실행시켰다면 해당 창은 bash를 통해 컨테이너 내부를 조작 중이므로 docker 명령 수행은 불가하다.
그러므로 컨테이너 내부 작업이 완료되면 exit를 통해 빠져나와야 한다.

 

또한 너무 당연하게도 컨테이너는 리눅스 배포판을 뭘 썼냐에 따라 해당 컨테이너에 맞는 명령을 입력해줘야 한다. 사용 중인 리눅스 서버가 Cent OS인데 컨테이너는 우분투 이미지로 생성했다면, 컨테이너 내의 작업을 할 때는 우분투 명령어를 사용해야 하는 것이다.

도커 허브

공식 도커 이미지는 도커 허브를 통해 다운로드가 가능하다. 덕분에 직접 이미지를 만드는 수고를 덜었고, 이로 인해 도커가 흥행한 것도 있다고 한다.
도커 허브에는 공식 이미지뿐만 아니라 비공식 이미지도 있는데, 누구나 올릴 수가 있다

레지스트리

이미지를 배포하는 장소. 도커 허브는 도커 제작사에서 운영 중인 공식 도커 레지스트리인 것.
비공개 레지스트리 생성도 가능.

레포지토리

레지스트리를 구성하는 단위. git으로 생각하면 git은 레지스트리이고, 그 안의 repository가 여기서 말하는 repository와 비슷한 개념이라고 생각할 수 있을 것 같다.

도커 컴포즈

시스템 구축과 관련된 명령어를 하나의 텍스트 파일(=정의 파일)에 기재해 명령어 한 번에 시스템 전체를 실행하고 종료와 폐기까지 한 번에 하도록 도와주는 도구

정의 파일

• yaml 포맷
• 컨테이너와 볼륨을 ’어떠한 설정으로 만들지 ‘에 대한 항목 기재
• 도커 명령어와 유사하지만 도커 명령어는 아님

주요 명령어

up

docker run과 유사. 이미지를 내려받고 컨테이너 생성 및 실행. 네트워크와 볼륨에 대한 기재도 있어 주변 환경을 한 번에 생성 간으

down

컨테이너 정지 및 삭제. 볼륨과 이미지 삭제는 안함. 컨테이너와 네트워크 삭제 없이 종료만 원한다면 stop 명령어 사용

도커 컴포즈 사용

• 도커 엔진과 별개의 소프트웨어 이므로 설치가 필요 (도커 데스크톱은 이미 도커 컴포즈가 함께 설치 되므로 별도 설치가 필요 없음)
• 파이썬으로 작성되었기 때문에, 리눅스에서는 파이썬 런타임이 필요
• 정의 파일 이름은 docker-compose.yml로 지정. 옵션을 통해 변경 가능은 함
• 정의 파일은 한 폴더에 하나만 존재 가능. 여러 개가 필요할 경우 각 폴더를 만들고 폴더 내 파일 이름은 docker-compose.yml로 생성
• 도커 컴포즈로 실행한 컨테이너 역시 도커 엔진을 통해 관리 가능. 다만 실행한 컨테이너의 이름은 임으로 결정이 됨 (ex. 폴더명_컨테이너명_번호)

쿠버네티스

쿠버네티스는 컨테이너 오케스트레이션 도구의 일종이다. 이름 그대로 컨테이너를 오케스트라처럼 지휘한다는 뜻이다.
Kubernetis는 이름이 꽤 길어서 그런지 k8s라고 불리기도 한다. k와 s 사이에 8개의 글자가 있다는 뜻이다.

워낙 유명하게 이름이 많이 알려지긴 했지만 기본적으로 동일한 구성의 컨테이너 여러 세트를 관리하는 도구인지라, 그 정도 대규모 시스템을 관리하지 않는 한 사용할 일도 프로그래머가 직접 관리할 일도 보통 없다.

도커는 한 대의 물지적 서버에서 실행되는 경우가 많았지만, 쿠버네티스는 여러 대의 물리적 서버가 존재하는 것을 전제로 한다.

이런 배경 때문에 직접 운영을 위해 배우기보다는 무엇을 할 수 있고, 어떤 개념이 있는지 정도를 정리하는 정도로 책에서 설명이 되고 있다.

마스터 노드와 워커 노드

노드는 클러스터 구성 방법에 따라 물리적 서버가 없을 수도 있지만, 물리적 서버와 거의 일치하는 개념이라고 보면 됨.

마스터 노드

• 감독과 같은 존재.
• 워커 노드에서 실행되는 컨테이너를 관리하는 역할.
• 컨테이너 실행이 없으므로 컨테이너 엔진도 설치되지 않는다.

워커 노드

• 컨테이너가 실제 동작하는 서버
• 컨테이너 엔진 또한 설치되어 있음

마스터 노드와 워커 노드로 구성된 한 세트의 쿠버네티스 시스템을 클러스터라고 부르며, 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 자율적으로 동작한다.

설치

쿠버네티스를 사용하기 위해서는 모든 노드에 쿠버네티스와 CNI(가상 네트워크 드라이버) 설치가 필요

CNI란, 같은 물리적 서버 내에서 연결해 주는 도커의 가상 네트워크와는 다른 개념으로 다른 물리적 컴퓨터를 같은 로컬 네트워크로 묶기 위해 사용

마스터 노드의 경우 컨테이너 상태 관리를 위한 etcd 데이터베이스와 초기 설정 및 조정을 할 수 있는 kubectl 설치가 필요
워커 노드에는 컨테이너 엔진 설치가 필요

쿠버네티스의 기본 아이디어

쿠버네티스는 ’바람직한 상태‘를 yaml에 정의하고, 자동으로 생성하거나 삭제하면서 이 상태를 만들고 유지하는 것이 기본적이 아이디어다.
도커 컴포즈는 이와 다르게 생성을 할 순 있지만 관리를 하진 않는다.

도커 컴포즈와 가장 큰 차이는 쿠버네티스는 정의 파일이 데이터베이스(etcd)로 관리되며 커맨드로 수정이 가능하다. 그렇기 때문에 최초 읽어드린 파일과 etcd에 저장된 정보가 일치하지 않게 되기 때문에 운영에 규칙을 정하고 철저한 관리가 필요하다.

쿠버네티스는 yaml에 정의된 바람직한 상태를 유지하기 위해, 장애가 있을 경우 자동으로 컨테이너를 삭제하고 생성하며 수동으로 삭제되었을 경우 자동으로 컨테이너를 복구하기도 한다.

 

"쿠버네티스는 정의된 바람직한 상태를 유지한다."
(책에서도 쓰여 있지만 어떤 면에서는 다소 미친 x 같은 느낌이기도 하다. 앞만 보며 간다!!!라는 느낌이랄까)

쿠버네티스의 구성과 용어

파드

컨테이너와 볼륨을 함께 묶은 것으로, 컨테이너는 파드 단위로 관리함.
파드에 포함되는 볼륨은 함께 있는 컨테이너 사이에 정보를 공유하기 위한 용도이므로 볼륨이 없는 경우도 많다.
기본적으로 파드 하나가 컨테이너 하나이고 볼륨이 없는 경우도 있다면, 굳이 파드 구성이 필요할까 싶지만 컨테이너 관리 단위가 파드이므로 모두 파드로서 다룬다.

서비스

파드를 모은 것. 서비스가 관리하는 파드는 모두 기본적으로 동일한 구성을 갖으며 구성이 다르다면 별도의 서비스로 관리한다.
서비스의 역할은 로드 밸런싱이다. 이를 위해 하나의 서비스는 하나의 ip 주소를 받으며, 이 주소로 들어온 요청을 서비스 내의 파드들에 적절히 분배해 준다. 다만, 워커 노드가 나뉘어 있다면 이 역할은 별도의 로드 밸런서가 진행을 하며 서비스가 하는 로드 밸런싱은 하나의 워커 노드 안으로 한정된다.

디플로이먼트와 레플리카세트

레플리카세트는 파드의 수를 관리한다. 쿠버네티스가 말하는 바람직한 상태를 유지시켜 주는 용도. 정의 파일에 정의된 대로 파드의 수가 있도록 보충 또는 감소시키는 역할을 한다.
레플리카세트가 관리하는 같은 구성의 파드를 레플리카라고 부른다. (레플리카의 복제라는 의미와 동일한 의미이다)
디플로이먼트는 파드가 사용하는 이미지 등 파드에 관한 정보를 가지고 있다. 레플리카세트가 파드의 수를 관리하기 위해서는 디플로이먼트의 정보가 필요하므로, 레플리카세트보다 좀 더 상위의 개념이다.

리소스

위에서 설명한 파드, 서비스, 디플로이먼트 등을 리소스라고 부르며 대략 50여 종의 종류가 있다.
리소스는 데이터베이스인 etcd에 등록된 상태에서는 오브젝트 형태로 관리되기 때문에 ‘oo오브젝트’라고 불리기도 한다. 그리고 이 오브젝트를 가지고 실제 인스턴스를 생성한다. -> 여러 용어는 혼란을 일으키지만 검색 용이를 위해 설명한 부분

정리를 마무리 하며... 

책은 쿠버네티스의 가장 기본적인 예제를 끝으로 마무리가 된다.
기본적으로 도커를 중점적으로 다루고 있고 쿠버네티스는 내용 자체가 좀 더 방대한 만큼, 깊게 다루기 어려운 부분이었다고 생각이 든다. 쿠버네티스는 용어 정리르 통해 다른 기본서를 볼 수 있게 되었다는 점에서 충분히 읽을만했다!