도커 서비스 구축
서비스란
어떠한 프로세스 process, 기능 functionality 혹은 데이터가 네트워크를 통해 이용가능할 때 서비스라고 할 수 있다.
도커 스웜 노드를 통한 서비스 구축 및 Docker Compose 파일 작성을 통해 선언적 방식으로 서비스를 실행하는 방법을 알아본다.
11.1 Service "Hello World"
hello-world 서비스 : 간단한 hello-world 컨테이너를 하나 실행하는 명령어 예제.
docker swarm init // establish service abstraction
docker service create
--publish 8080:80
--name hello-world
dockerinaction/ch11_service_hw:v1 // starts local server listens on 8080
도커 서비스는 docker swarm mode가 실행될 때 가능하다. docker service create 명령어는 컨테이너 실행과 비슷하다.
docker swarm init : 도커 엔진은 도커 서비스 오케스트레이션 (서비스를 구성하는 노드를 유지하는 도구) 기능을 제공하는 docker swarm node를 실행한다. 내부적으로 오케스트레이션을 위한 데이터베이스를 시작하는 것을 포함한다.
docker service create는 8080 포트에서 서비스하는 컨테이너를 하나 실행한다.
도커 스웜은 "hello-world 컨테이너 실행"을 하는 "task" 작업을 정의서를 가지고 있다.
이 작업을 통해 실제 컨테이너 하나가 실행되도록 Swam Node는 서비스를 유지한다.
docker service ps 를 통해 실행중인 서비스 상태를 확인한다.
서비스의 복구와 복제 기능
서비스는 실행되는 노드가 목표로하는 노드 수를 유지하려고 한다. 현재 유지해야하는 노드 (컨테이너)가 한 개이고 이 노드가 중단된다면, 서비스는 노드를 하나 다시 실행한다.
REPLICAS 1/1 로 표기되어 있는 의미는 한 개의 노드를 반드시 유지하도록 되어 있다는 뜻이다.
1) 컨테이너 하나를 강제로 중지한다.
2) 잠시후 docker service ps hello-world를 통해 서비스 상태를 확인한다.
중지한 컨테이너 기록이 있고 그 이후에 다시 컨테이너를 새로 실행한 것을 확인할 수 있다.
DESIRED STATE, CURRENT STATE
Desired State는 유저가 서비스를 통해 유지되어야할 상태를 나타내고 Current State는 현재 상태를 의미한다. 오케스트레이션 도구는 서비스 상태를 추적하여 상태 변화를 감지한다.
docker service inspect 서비스 인스펙션
서비스 이름, Service ID, 버전, 타임스탬프 등등 서비스 상태를 표시한다.
노드 스케일 설정 변경
docker service scale hello-world=3
도커 스웜으로 실행중인 서비스 노드 수를 조절 가능하며 효력은 즉시 일어난다. 필요한 컨테이너 수 만큼 실행이 되며 각 컨테이너 이름은 hello-world.1, hello-world.2, hello-world.3 을 prefix로 하여 실행된다.
자동화된 롤아웃
새로운 실행 파일 교체 등 서비스 업데이트를 위한 명령을 알아본다.
docker service update \
--image dockerinaction/ch11_service_hw:v2 \
--update-order stop-first \
--update-parallelism 1 \
--update-delay 30s
hello-world
docker service update는 새로운 이미지 ch11_service_hw:v2 로 실행되는 컨테이너로 교체하는 작업을 시작한다.
각 작업은 하나씩 기존 서비스를 중지하고 새로운 이미지로 실행하는 서비스를 시작한다.
각 서비스 업데이트 사이에 30초의 딜레이가 존재한다.
서비스 업데이트가 모두 완료되면, Service converaged 사인이 출력되고 정상 처리되었음을 알 수 있다.
서비스 헬스 체크와 롤백
비정상적인 서비스를 업데이트 했을 때, 서비스 업데이트 사항을 롤백할 수 있는 기능을 제공한다.
1) 영원히 실행하지 않는 서비스를 하나 실행한다.
docker service update \
--image dockerinaction/ch11_service_hw:start-failure \
hello-world
상태가 "실패" 상태로 유지되고 있음을 확인한다.
2) 롤백 처리를 실행한다.
docker service update --rollback hello-world
서비스 배포 시 실패가 감지 되면 자동 롤백처리를 실행하는 옵션을 사용한다.
docker service update --update-failure-action rollback --update-max-failure-ratio 0.7 --image dockerinaction/ch11_service_hw:start-failure hello-world
헬스 체크
v2 이미지는 헬스 체크 기능을 내장하고 있다. 내장 기능 httpping 프로그램을 통해 컨테이너가 localhost, '/' 경로에서 정상 응답 200을 받고 있다는 것을 확인하고 컨테이너 상태가 "health" 임을 확인할 수 있다.
해당 이미지의 도커 파일에는 다음과 같이 헬스 체크를 하도록 명시되어 있다.
HEALTHCHECK --interval=10s CMD ["/bin/httpping"]
헬스 체크 기능이 없는 이미지를 사용하면 더 이상 컨테이너 상태는 "healthy" 인 지 알 수 없게 된다.
docker service update \
--update-failure-action rollback \
--image dockerinaction/ch11_service_hw:no-health \
hello-world
서비스 중단
docker service rm hello-world예제로 사용한 서비스를 중단한다.
Compose V3를 사용한 도커 서비스 환경 구축
명령적 방식이 아닌 파일을 사용하여 구축할 서비스를 정의하고 이를 통해 서비스를 실행하는 방법을 알아본다.
docker stack
도커 스택은 모든 도커 서비스, 볼륨, 네트워크 그리고 다른 설정 요소들의 구성을 의미한다.
Compose V3 파일은 도커 스택을 정의하며, YAML 포맷으로 작성된다.
database.yml 예제
version: "3.7"
volumes:
pgdata:
services:
postgres:
image: dockerinaction/postgres:11-alpine
volumes:
- type: volume
source: pgdata
target: /var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: example
mariadb:
image: dockerinaction/mariadb:10-bionic
environment:
MYSQL_ROOT_PASSWORD: example
adminer:
image: dockerinaction/adminer:4
ports:
- 8080:8080
deploy:
replicas: 2
volumes : 도커의 볼륨을 정의한다.
services : 도커의 서비스를 정의한다.
각 엔트리의 구성 요소는 postgres, mariadb, adminer 서비스를 구성하는 것을 알 수 있따.
각 서비스는 사용할 이미지, 볼륨, 환경 변수, 포트, 복제 노드 수 등을 작성하여 실행할 서비스의 설정을 구성한다.
도커 스택 배포하기
docker stack deploy -c database.yml my-databases
서비스 상태 확인하기
docker service ls 서비스 상태 확인하기
docker stack ps로 스택 상태를 확인할 수 있다.
yml 파일을 수정하여 adminer 서비스의 replicas 수를 조정하고 다시 배포해본다.
조정된 수로 실행된 adminer 서비스 수를 확인할 수 있다.
로드밸런싱, 서비스 디스커버리, 그리고 네트워크
adminer 웹 서비스는 8080 포트를 통해 접근 가능하다는 것을 알 수 있다.
실제 컨테이너는 두 개가 실행되고 있으며 컨테이너에 할당된 포트 번호는 8080과는 다르다.
도커는 virtual IP를 생성하여 서비스를 중재하고 들어오는 요청을 내부 실행되는 컨테이너에게 적절히 전달하는 로드 밸런싱을 수행한다. 호스트의 인터페이스로 부터 요이 들어오면 서비스의 VIP로 포워딩을 한다.
ingress 네트워크
docker service inspect my-databases_adminer 를 실행하면, 다음과 같이 일부분에서 호스트 인터페이스와 연결된 ingress 네트워크와 두 개의 adminer 서비스 VIP들이 있는 것을 확인할 수 있다.
docker network inspect ingress
ingress 네트워크를 자세히 보면, 두 adminer 컨테이너에 대한 Endpoint와 ingress 네트워크의 Endpoint를 확인할 수 있다.
이는 도커 내부에서 사용되는 주소이며 로드 밸런서가 외부 요청을 전달할 주소이다. 외부 호스트 인터페이스와 연결된 ingress-sbox는 내부 IP로 10.0.0.2/24 주소를 갖는다.
스택 기본 네트워크 : my-databases_default
스택에 참여하는 모든 서비스는 기본 네트워크를 통해 통신이 가능하다. 각 컨테이너의 자신의 Endpoint를 가진 고유 네트워크는 스택 기본 네트워크와 연결되어 있다.
docker network inspect my-databases_default를 통해 상세 내용을 확인할 수 있다.
해당 IPv4는 도커 컨테이너의 IP 혹은 로드 밸런서가 바라보는 내부 요청을 전달할 타겟 주소들이다.
실행 중인 postgres 컨테이너 1개
my_databases_postgres.1 : 10.0.2.40/24
실제 postgres 서비스의 IP 인터페이스는 VIP로 생성되며, 다음과 같이 확인할 수 있다.
docker service inspect my-databases_postgres
VIP는 로드 밸런서에 의해 관리되며, VIP를 통한 연결은 postgres service 복제 노드로 전달된다.
docker network ls를 통해 도커 스웜이 생성한 두 네트워크를 직접 확인 가능하다.
default 네트워크를 대체하려면 Compose 파일의 networks 엔트리에 명시하라
version: "3.7"
networks:
foo:
driver: overlay
volumes:
pgdata:
services:
postgres:
image: dockerinaction/postgres:11-alpine
volumes:
- type: volume
source: pgdata
target: /var/lib/postgresql/data
networks:
- foo
environment:
POSTGRES_PASSWORD: example
mariadb:
image: dockerinaction/mariadb:10-bionic
networks:
- foo
environment:
MYSQL_ROOT_PASSWORD: example
adminer:
image: dockerinaction/adminer:4
networks:
- foo
ports:
- 8080:8080
deploy:
replicas: 2
요약
서비스는 네트워크를 통해 제공되는 프로세스, 기능, 데이터를 의미하낟.
스웜과 같은 오케스트레이터는 유저가 설정한 상태를 충족시키기 위해 서비스, 볼륨, 네트워크를 유지한다.
오케스트레이터는 복제, 복원, 배포, 헬스 체크, 롤백 기능을 수행한다.
목표 상태는 유저가 시스템으로 요구하는 달성해야할 상태를 의미하며, docker compose 파일로 작성 가능하다.
compose 파일은 YAML 형식이다.
compose 파일은 도커 서비스, 볼륨, 네트워크를 정의하며 스택을 만드는 정의서이다.
'Cloud > Docker' 카테고리의 다른 글
| Docker In Action 12. First-class configuration abstractions (1) | 2024.12.14 |
|---|---|
| Docker In Action 9. Public and private software distribution (1) | 2024.12.09 |
| Docker In Action 8. Building image automaticall with Dockerfiles (1) | 2024.12.08 |
| Docker In Action 7. Packaging software in images (1) | 2024.12.06 |
| Docker In Action 6. Limiting risk with resource controls (1) | 2024.12.04 |