땡글이LAB

스웜 모드는 자체적으로 롤링 업데이트를 지원하며, 매우 간단하게 사용할 수 있다. 우선 롤링 업데이트를 테스트하기 위한 서비스를 생성한다. 이 서비스는 앞에서 생성한 서비스와 유사하지만 이번에는 컨테이너 생성에 사용될 이미지를 nginx:1.10 으로 설정했다. $ docker service create --name myweb2 \ --replicas 3 \ nginx:1.10 서비스가 정상적으로 생성되면, docker service update 명령어로 서비스의 이미지를 업데이트할 수 있다. docker service update 명령어를 사용하면 생성된 서비스의 각종 설정을 변경할 수 있다. 이미지를 업데이트하려면 update 명령어의 --image 옵션을 설정하면 된다. 다음 명령은 myweb2 서..

이전 포스팅에서 계속 사용해온 도커 명령어의 제어 단위는 컨테이너였다. docker run 명령어는 컨테이너를 생성하고, docker rm 명령어는 컨테이너를 삭제했던 것처럼 도커 클라이언트에서 사용하는 명령어가 제어하는 것은 컨테이너이다. 하지만, 스웜 모드에서 제어하는 단위는 컨테이너가 아닌 서비스(Service)이다! 서비스(Service)는 같은 이미지에서 생성된 컨테이너의 집합이며, 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령이 수행된다. 서비스 내에 컨테이너는 1개 이상 존재할 수 있으며, 컨테이너들은 각 워커 노드와 매니저 노드에 할당된다. 이러한 컨테이너들은 '태스크(Task)'라고 한다. 스웜 스케줄러(Scheduler)는 서비스의 정의에 따라 컨테이너를 할당할 적합한 노드를..

지금까지 알아본 도커 사용법은 대부분 하나의 호스트를 기준으로 한다. docker ps 명령어는 하나의 도커 엔진에 존재하는 컨테이너의 목록을 출력하며 create, run 명령어 또한 하나의 도커 엔진에 컨테이너를 생성한다. 그러나 실제로 도커를 운영환경에 적용하려면 이야기가 달라진다. 하나의 호스트 머신에서 도커 엔진을 구동하다가 CPU나 메모리, 디스크 용량과 같은 자원이 부족하면 이를 어떻게 해결할까?? 가장 간단한 답은 "매우 성능이 좋고 디스크 용량이 큰 좋은 서버를 새로 산다"이다. 하지만, 자원의 확장성 측면이나 비용 측면에서도 이것은 좋은 해답은 아니다. 자원이 부족할 때마다 성능이 좋은 서버를 살 수 없을 뿐더러 높은 가격의 서버를 사고 유지하는 비용 또한 무시할 수 없기 때문에 이를 ..

도커의 구조 도커 명령어는 /usr/bin/docker 에 위치한 파일을 통해 사용되고 있다. 하지만, 도커 엔진의 프로세스는 /usr/bin/dockerd 파일로 실행되고 있다. 이렇게 되는 이유는 docker 명령어가 실제 도커 엔진이 아닌 클라이언트로서의 도커이기 때문이다. 도커의 구조는 크게 두 가지로 나뉜다. 클라이언트로서의 도커, 서버로서의 도커로 나뉜다. 실제로 컨테이너를 생성하고 실행하며 이미지를 관리하는 주체는 도커 서버이고, 이는 dockerd 프로세스로서 동작한다. 도커 엔진은 외부에서 API 입력을 받아 도커 엔진의 기능을 수행하는데, 도커 프로세스가 실행되어 서버로서 입력을 받을 준비가 된 상태를 도커 데몬이라고 한다. 다른 하나는 도커 클라이언트이다. 도커 데몬은 API 입력을 ..

이미지 생성하기 이미지를 생성할 때 생각나는 일반적인 프로세스는 다음과 같을 것이다. 이미지(CentOS, Ubuntu 등)으로 컨테이너를 생성 애플리케이션을 위한 환경을 설치하고 소스코드 등을 복사해 잘 동작하는 것을 확인 컨테이너를 이미지로 커밋(commit) 하지만, 위의 방법을 이용하면 애플리케이션이 동작하는 환경을 구성하기 위해 일일이 수작업으로 패키지를 설치하고 소스코드를 깃(Git)에서 복제하거나 호스트에서 복사해야 한다. 직접 컨테이너에서 애플리케이션을 구동해보고 이미지로 커밋하기 때문에 이미지의 동작을 보장할 수 있다는 장점도 있지만 매번 일일이 수작업을 하기에는 너무 힘들다. Dockerfile 도커는 위와 같은 일련의 과정을 손쉽게 기록하고 수행할 수 있는 빌드(build) 명령어를 ..

모든 컨테이너는 이미지를 기반으로 생성되며 이미지를 다루는 방법은 도커 관리에서 빼놓을 수 없는 부분이다. 이미지의 이름을 구성하는 저장소, 이미지 이름, 태그를 잘 관리하는 것 뿐만 아니라, 이미지가 어떻게 생성되고 삭제되는지 이미지의 구조는 어떻게 돼 있는지 등을 아는 것 또한 중요하다. 이번 장에서는 이미지를 관리하는 기본적인 방법을 알아본다. Debian 운영체제에서 apt-get install 을 실행하면 apt 리포지토리에서 패키지를 내려받고 RedHat 운영체제에서 yum install 을 실행하면 yum 리포지토리에서 패키지를 내려받듯이 도커는 기본적으로 도커 허브(Docker Hub)라는 중앙 이미지 저장소에서 이미지를 내려받는다. 도커 허브는 도커가 공식적으로 제공하고 있는 이미지 저장..

도커 네트워크 구조 컨테이너 내부에서 ifconfig 명령어를 입력하면, 컨테이너의 네트워크 인터페이스에 eth0과 lo 네트워크 인터페이스가 있는 것을 확인할 수 있다. 도커는 컨테이너에 내부 IP를 순차적으로 할당하며, 이 IP는 컨테이너를 재시작할 때마다 변경될 수 있다. 이 내부 IP는 도커가 설치된 호스트, 즉 내부 망에서만 쓸 수 있는 IP이므로 외부와 연결될 필요가 있다. 도커는 각 컨테이너에 외부와의 네트워크를 제공하기 위해 컨테이너마다 가상 네트워크 인터페이스를 호스트에 생성하며 이 인터페이스의 이름은 veth로 시작한다. veth 인터페이스는 사용자가 직접 생성할 필요는 없고 컨테이너가 생성될 때 도커 엔진이 자동으로 생성한다. veth이 의미하는 바는 'virtual eth' 이다...

도커 엔진에서 사용하는 기본 단위는 이미지와 컨테이너이고, 이 두 가지가 도커 엔진의 핵심이다. 두 가지에 대해 간단하게 다뤄보도록 하겠다. 도커 이미지 이미지는 컨테이너를 생성할 때 필요한 요소이며, 가상 머신을 생성할 때 사용하는 iso 파일과 비슷한 개념이다. 이미지는 여러 개의 계층으로 된 바이너리 파일로 존재하고, 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용된다. 이미지는 도커 명령어로 내려받을 수 있으므로 별도로 설치할 필요는 없다. 도커에서 사용하는 이미지의 이름은 기본적으로 "[저장소이름]/[이미지이름]:[태그]"의 형태로 구성된다. ex) alicek106/ubuntu:14.04 저장소(Repository) 이름 이미지가 저장된 장소를 의미한다. 저장소 이름이 명시되지 않은 이미지는..