한발 한발 나아가기

배경

ls -l /var/run/docker.sock
lrwxr-xr-x  1 root  daemon  44  5 24 10:25 /var/run/docker.sock -> /Users/choi-junyoung/.docker/run/docker.sock

내 컴퓨터에는 stella.jv와 choi-junyoung 두 개의 계정이 있다. 그런데 stella.jv 계정으로 접속했을 때, 저런 식으로 /var/run/docker.sock이 다른 사용자 계정을 바라보고 있었다.

처음에는 왜 저런지 전혀 알지 못했지만, 구글링 하다보니 심볼릭 링크와 관련되어 있다는 것을 알 수 있었다.

키워드를 파악하니 해결책을 쉽게 찾을 수 있었다.

해결 방법

sudo ln -s /Users/stella.jv/.docker/run/docker.sock /var/run/docker.sock

기존 /var/run/docker.sock을 삭제한 뒤, 위의 명령어를 입력하여 stella.jv 계정를 바라보도록 하였다.

그 다음 도커로 실행시켜보니, 내 docker desktop으로 정상적으로 확인할 수 있게 되었다.

쿠버네티스에서는 컨테이너 애플리케이션의 기본 단위를 파드라고 부른다.

쿠버네티스가 파드를 사용하는 이유는, 대표적으로 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위함이다. 그 말은 즉, 파드에 속한 여러 개의 컨테이너들은 동일한 네트워크 환경을 가진다는 것을 의미한다.

왜 하나의 파드에 여러 개의 컨테이너가 포함되는지 의문을 가질 수 있다. 실제로 대부분은 하나의 파드를 하나의 컨테이너로 구성한다.

하나의 파드는 하나의 완전한 애플리케이션이라는 점을 주목하자. 가령 어떤 Nginx 컨테이너가 로그 수집과 같은 부가적인 기능을 필요로 할 수 있다. 이런 경우 주 컨테이너는 Nginx로 하되, 기능 확장을 위한 사이드카 컨테이너를 파드에 포함시키면 된다. 

이것이 도커 컨테이너와 쿠버네티스 파드의 차이점이다.

참고자료

• 시작하세요! 도커/쿠버네티스 책

지속적인 보완이 필요한 글

Dockerfile이란 이미지 생성을 위해 컨테이너에 설치해야 하는 패키지, 추가해야 하는 소스코드, 실행해야 하는 명령어와 셸 스크립트 등의 일련의 작업들을 기록한 파일이다. 애플리케이션 개발 용도 이외에도, 도커 허브에 이미지 대신 생성 방법을 기록한 도커파일을 배포하는 경우도 있다.

초기 이미지를 바탕으로, 컨테이너 내부에서 애플리케이션을 위한 환경을 구성한 뒤에 커밋하는 방법도 있다. 하지만 아래의 장점으로 인해, Dockerfile을 사용하는 것이 좋다.

1. 이미지 생성 방법의 기록. 패키지 생성과 같이, 애플리케이션에 필요한 일련의 과정을 명확하게 표현할 수 있음
2. 이미지 생성 자동화
3. 쉽게 배포 가능

참고자료

• 시작하세요! 도커/쿠버네티스
• 도커 공식문서

컨테이너에 변경 사항을 저장하면, 컨테이너 삭제 시 데이터가 함께 삭제된다. 컨테이너와 무관하게 데이터를 관리하고 싶다면, 볼륨을 사용한다.

볼륨을 활용하는 방법으로는 1) 호스트와 볼륨을 공유, 2) 볼륨 컨테이너 활용, 3) 도커가 관리하는 볼륨을 생성하는 방법이 있다. 사실 세 방법 모두 호스트의 파일 디렉토리를 사용하며, 방법에 따라 조금씩 차이가 있을 뿐이다.

앞의 두 가지 방법도 나쁘지 않지만, 도커가 관리하는 볼륨을 사용하면 더욱 편리하다.

사용 방법

1. docker volume create —name [볼륨 이름] 으로 볼륨 생성
2. docker volume ls 로 생성된 볼륨 확인
3. docker run -it -v [볼륨 이름]:[컨테이너의 공유 디렉터리] image 명령어를 통해, 컨테이너가 실행될 때 볼륨을 마운트해준다.
4. docker inspect --type volume [볼륨 이름] 명령어를 통해, 볼륨이 저장되는 위치 등의 여러 정보를 확인할 수 있다. 참고로 inspect는 컨테이너, 이미지 등 도커의 모든 구성 단위의 정보를 확인할 때 사용할 수 있다.

-v 옵션 대신 —mount 옵션을 사용할 수도 있다. 서로 기능은 같되, 볼륨의 정보를 나타내는 방법이 다르기 때문에 편한 옵션으로 사용하면 된다.

참고자료

• 시작하세요! 도커/쿠버네티스
• 도커 공식문서

도커 엔진은 애플리케이션을 빌드하고 컨테이너화하기 위한 오픈 소스 컨테이너화 기술이다. 클라이언트는 도커 데몬을 통해 컨테이너 빌드, 실행 등의 무거운 작업을 수행한다.

도커 데몬

도커 데몬(dockerd)은 Docker API 요청을 수신하고 이미지, 컨테이너, 네트워크 및 볼륨과 같은 Docker 객체를 관리한다. 데몬은 다른 데몬과 통신하여 Docker 서비스를 관리할 수도 있다.

도커 클라이언트

도커 클라이언트(docker)는 대다수의 도커 사용자가 도커와 통신하는 주요 방법이다. docker run과 같은 명령어를 입력하면, 클라이언트는 해당 명령어를 도커 데몬으로 전송한다. Docker API를 사용하며, 도커 클라이언트는 여러 데몬과 통신할 수 있다.

도커 데스크탑

맥, 윈도우 또는 리눅스 환경을 위한 애플리케이션으로, 컨테이너화된 애플리케이션 및 마이크로서비스를 구축하고 공유할 수 있다. 도커 데스크탑에는 도커 데몬(dockerd), 도커 클라이언트(docker), 도커 컴포즈, 도커 content trust, 쿠버네티스 및 credential helper가 포함된다.

도커 레지스트리

도커 이미지를 저장하는 곳이다. 크게 공개 레지스트리와 사설 레지스트리가 있다.

• 도커 허브는 누구나 사용할 수 있는 공개 레지스트리이며, 도커는 기본적으로 도커 허브에서 이미지를 찾도록 되어있다.

이미지

컨테이너를 생성 지침이 포함된 읽기 전용 템플릿이다. 이미지를 만들어 사용할 수도 있고, 레지스트리에 저장된 이미지를 받아와 사용할 수도 있다.

• 이미지를 만들기 위해서는 Dockerfile을 작성해야 한다.
• [저장소 이름]/[이미지 이름]:[태그]의 형태로 구성된다. 저장소 이름 생략 시 도커 허브로 지정된다.

컨테이너

이미지로부터 실행 가능한 인스턴스인 컨테이너를 생성할 수 있다. 또한, 이미지와 컨테이너는 1:N 관계이다.

컨테이너를 생성하면, 이미지의 목적에 맞는 파일이 들어있는 파일 시스템과 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립적인 공간이 생성된다. 설정에 따라 네트워크, 스토리지 또는 기타 기본 하위 시스템이 다른 컨테이너 또는 호스트 시스템에서 얼마나 격리되는지 제어할 수 있다.

컨테이너는 이미지를 읽기 전용으로 사용하고, 변경된 사항만 컨테이너에 저장한다. 즉, 컨테이너에 무엇을 하든 원래 이미지는 영향을 받지않는다.

참고 자료

• 시작하세요! 도커/쿠버네티스 책
• 도커 공식문서

도커는 애플리케이션을 개발하고, 전달하고, 실행하기 위한 오픈소스 플랫폼이다. 

기존의 가상화 기술은 하이퍼바이저를 이용해 여러 개의 운영체제를 하나의 호스트에서 생성하는 방식이었다. 해당 방식은 완벽한 운영 체제를 생성할 수 있다는 장점은 있지만, 일반 호스트에 비해 성능 손실이 있고 이미지의 크기가 커서 배포하기 부담스럽다는 단점을 가지고 있다.

• 성능 손실은, 각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업이 하이퍼바이저를 반드시 거쳐야 하기 때문에 발생한다.
• 큰 이미지 크기는, 게스트 운영체제를 사용하기 위한 라이브러리와 커널 등을 모두 포함하기 때문이다.

이에 비해 도커 컨테이너는 이미지로 만들어 배포하는 시간이 가상 머신에 비해 빠르고, 성능 손실이 거의 없다는 장점이 있다.

• 리눅스 자체 기능인 chroot, 네임스페이스, cgroup을 사용함으로써 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없다.
• 컨테이너는 호스트의 커널을 공유해 사용하고, 애플리케이션을 구동하는데 필요한 라이브러리 및 실행 파일만 존재하기 때문에 이미지 의의 용량이 대폭 줄어들었다.

이러한 컨테이너 기술을 사용함으로써 애플리케이션의 개발과 배포가 편리해지고, 여러 애플리케이션의 독립성과 확장성이 높일 수 있다.

• 개발할 때 사용하던 환경을 다른 서버에서의 컨테이너에서 똑같이 복제가 가능하기 때문에, 그저 개발하고 이미지로 만들어 운영 환경으로 전달하기만 하면 된다.
• 오늘날 대규모 서비스에서는 확장성과 유연성을 위해 마이크로서비스 구조를 많이 사용한다. 가령 데이터베이스에 데이터를 적재하는 모듈과 적재된 데이터를 가공하는 모듈을 서로 다른 컨테이너로 분리했다고 가정해보자. 이러면 모듈 간의 이미지 버전을 따로 가져갈 수 있어서 유지 보수가 용이해지고, 특정 모듈의 컨테이너 수만을 늘려 부하를 분산할 수도 있다.

참고 링크

• 시작하세요! 도커/쿠버네티스 책
• 도커 공식문서