[docker-swarm] docker swarm 고급 (1)

업데이트: 2023.01.18 Updated: 2023.01.18

카테고리: docker

태그: docker

🎯Docker Swarm 고급 (1)

Swarm에서 노드 관리
Swarm에 서비스 배포

Swarm에서 노드 관리

docker node ls 명령을 관리자 노드에서 실행한 결과를 보고 AVAILABILITY와 MANAGER STATUS 컬럼이 무엇을 뜻하는지 확인해봅니다.

$ docker node ls

ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
46aqrk4e473hjbt745z53cr3t    node-5    Ready   Active        Reachable
61pi3d91s0w3b90ijw3deeb2q    node-4    Ready   Active        Reachable
a5b2m3oghd48m8eu391pefq5u    node-3    Ready   Active
e7p8btxeu3ioshyuj6lxiv6g0    node-2    Ready   Active
ehkv3bcimagdese79dn78otj5 *  node-1    Ready   Active        Leader

AVAILABLITY: 스케줄러가 task를 노드에 할당할 수 있는지 여부가 표시됩니다.
- Active: 스케줄러가 task를 노드에 할당할 수 있음을 의미합니다.
- Pause: 스케줄러가 노드에 새 task를 할당하지 않지만 기존 task는 계속 실행 중임을 의미합니다.
- Drain: 스케줄러가 노드에 새 task를 할당하지 않음을 의미합니다. 스케줄러는 기존 task를 종료하고 사용 가능한 노드에 task를 예약합니다.
MANAGER STATUS: Raft 합의에 대한 노드 참여를 보여줍니다.
- 값이 없으면 스웜 관리에 참여하지 않는 작업자 노드를 의미합니다.
- Leader: 노드가 스웜에 대한 모든 스웜 관리 및 오케스트레이션 결정을 내리는 기본 관리자 노드임을 의미합니다.
- Reachable: 노드가 Raft 합의에 참여하는 관리자 노드임을 의미합니다. Leader 노드가 사용할 수 없게 되면 Reachable 노드가 새 Leader로 선출될 수 있습니다.
- Unavailable: 노드가 다른 관리자와 통신할 수 없는 상태의 관리자 노드를 의미합니다. 관리자 노드를 사용할 수 없게 되면 새 관리자 노드를 Swarm에 가입시키거나 작업자 노드를 관리자로 승격시켜야 합니다.

개별 노드 검사

관리자 노드에서 docker node inspect <NODE-ID> 명령을 실행 하여 개별 노드에 대한 세부 정보를 볼 수 있습니다. 출력은 기본적으로 JSON 형식을 갖지만 --pretty 플래그를 추가하여 사람이 읽기 쉬운 형태로 결과를 출력할 수 있습니.

$ docker node inspect self --pretty

ID:                     ehkv3bcimagdese79dn78otj5
Hostname:               node-1
Joined at:              2016-06-16 22:52:44.9910662 +0000 utc
Status:
 State:                 Ready
 Availability:          Active
Manager Status:
 Address:               172.17.0.2:2377
 Raft Status:           Reachable
 Leader:                Yes
Platform:
 Operating System:      linux
 Architecture:          x86_64
Resources:
 CPUs:                  2
 Memory:                1.954 GiB
Plugins:
  Network:              overlay, host, bridge, overlay, null
  Volume:               local
Engine Version:         1.12.0-devdocker node inspect self --pretty

ID:                     ehkv3bcimagdese79dn78otj5
Hostname:               node-1
Joined at:              2016-06-16 22:52:44.9910662 +0000 utc
Status:
 State:                 Ready
 Availability:          Active
Manager Status:
 Address:               172.17.0.2:2377
 Raft Status:           Reachable
 Leader:                Yes
Platform:
 Operating System:      linux
 Architecture:          x86_64
Resources:
 CPUs:                  2
 Memory:                1.954 GiB
Plugins:
  Network:              overlay, host, bridge, overlay, null
  Volume:               local
Engine Version:         1.12.0-dev

노드 AVAILABILITY 변경

$ docker node update --availability drain node-1

# node-1 에서 task를 할당받지 않고 스웜 관리 작업만 수행하도록 AVALIABILITY를 drain으로 변경합니다.

$ docker node update --availability active node-1

# node-1 에서 다시 task를 할당받도록 AVALIABILITY를 active로 변경합니다.

라벨 메타데이터 추가 또는 삭제

서비스 제약 조건에서 노드 레이블을 사용할 수 있습니다. 제약 조건을 적용하여 서비스를 생성할 때 스케줄러가 task를 할당하는 노드를 제한합니다.
관리자 노드에서 docker node update --label-add 실행 하여 라벨 메타데이터를 노드에 추가합니다. --label-add 플래그는 <key> 또는 <key>=<value> 쌍을 지원합니다.
각 라벨에 대해 한 번씩 --label-add 플래그를 추가합니다.

$ docker node update --label-add foo --label-add bar=baz node-1

Note:

docker node update를 사용하여 노드에 대해 설정한 라벨은 swarm 내의 노드에만 적용됩니다. 독립적으로 실행되는 dockerd의 docker 데몬 라벨과 혼동하지 마십시오.

Swarm 에서 노드 제거

docker swarm leave 명령을 실행 하여 Swarm에서 노드를 제거할 수 있습니다.
노드가 Swarm을 떠나면 Docker 엔진은 Swarm 모드에서 실행을 중지하고 오케스트레이터는 더 이상 작업을 해당 노드에 예약하지 않습니다.
Swarm을 떠나는 노드가 관리자인 경우 경고가 표시됩니다. 경고를 무시하려면 --force 플래그를 추가합니다. 마지막 관리자 노드가 Swarm을 떠나면 Swarm을 사용할 수 없는 상태가 되므로 재해 복구 조치를 취해야 합니다.
노드가 Swarm을 떠나고 나면 관리자 노드에서 docker node rm 명령을 실행하여 노드 목록에서 제거할 수 있습니다.

[node-2]$ docker swarm leave
[manger]$ docker node rm node-2

Swarm에 서비스 배포

Swarm은 원하는 상태를 유지하기 위해 서비스 상태를 다음의 정보를 포함하여 정의합니다.

서비스 컨테이너가 실행해야 하는 이미지 이름 및 태그
서비스에 참여하는 컨테이너 수
Swarm 외부의 클라이언트에 포트가 노출되는지 여부
Docker가 시작될 때 서비스가 자동으로 시작되어야 하는지 여부
서비스가 다시 시작될 때 발생하는 특정 동작
서비스가 실행될 수 있는 노드의 특성

비공개 레지스트리의 이미지를 사용하여 서비스 만들기

로그인이 필요한 개인 레지스트리에 이미지가 있는 경우 로그인 후 docker service create 와 함께 --with-registry-auth 플래그를 사용합니다.

$ docker login registry.example.com
$ docker service  create \
  --with-registry-auth \
  --name my_service \
  registry.example.com/acme/my_image:latest

# registry.example.com: 개인 레지스트리

서비스 업데이트

docker service update 명령을 사용하여 기존 서비스에 대한 거의 모든 것을 변경할 수 있습니다. 서비스를 업데이트하면 Docker는 해당 컨테이너를 중지하고 새 구성으로 다시 시작합니다.
포트 게시를 추가하려면 --publish-add 플래그를 사용하고 이전에 게시된 포트를 제거하려면 --publish-rm 플래그를 사용합니다.

$ docker service update --publish-add 80 my_web
$ docker service ls

ID                  NAME                MODE                REPLICAS            IMAGE                                                                                             PORTS
4nhxl7oxw5vz        my_web              replicated          1/1                 docker.io/library/nginx@sha256:41ad9967ea448d7c2b203c699b429abe1ed5af331cd92533900c6d77490e0268   *:0->80/tcp

# my-web 서비스에 80번 포트를 게시합니다.

기존 서비스가 실행하는 명령을 업데이트하려면 --args 플래그를 사용할 수 있습니다.
다음 예제는 이전에 helloworld 서비스에서 실행 중이던 명령 대신 ping docker.com 명령을 실행하도록 서비스를 업데이트합니다.

$ docker service update --args "ping docker.com" helloworld

런타임 환경 구성

--env: 환경 변수
--workdir 컨테이너 내부의 작업 디렉토리
--user: 사용자 이름 또는 UID
다음 서비스의 컨테이너에는 $MYVAR 환경 변수가 myvalue 값을 갖고 /tmp 디렉토리에서 실행되고 my_user 사용자로 실행됩니다.

$ docker service create --name helloworld \
  --env MYVAR=myvalue \
  --workdir /tmp \
  --user my_user \
  alpine ping docker.com

서비스에서 사용해야 하는 이미지 버전 지정

서비스를 생성할 때 이미지 버전을 지정하지 않는 경우 latest가 적용됩니다.
서비스를 생성할 때 특정 태그 또는 다이제스트를 이용할 수 있습니다.
특정 태그를 지정하는 경우 관리자 노드는 해당 태그를 다이제스트로 확인합니다.
작업자 노드에 task 생성 요청이 오면 작업자 노드는 다이제스트를 확인하여 컨테이너를 생성합니다.
특정 태그의 다이제스트를 확인하려면 다음 명령을 사용합니다.

$ docker inspect ubuntu:latest
"RepoDigests": [
    "ubuntu@sha256:35bc48a1ca97c3971611dc4662d08d131869daa692acb281c7e9e052924e38b1"
],

서비스 이미지 업데이트

각 태그는 Git해시와 유사한 다이제스트를 가집니다. latest와 같은 태그는 새 다이제스트를 가리키도록 자주 업데이트됩니다.
--image 플래그를 사용하여 service update 명령을 실행하면 Swarm 관리자는 태그가 현재 가리키는 다이제스트에 대해 Docker Hub 또는 프라이빗 Docker 레지스트리에 쿼리하고 해당 다이제스트를 사용하도록 서비스 task를 업데이트합니다.

포트 게시

Swarm 서비스를 만들 때 다음 두 가지 방법으로 해당 서비스의 포트를 swarm 외부의 호스트에 게시할 수 있습니다.

라우팅 메시
노드에 직접 서비스 포트 게시

라우팅 메시

--publish <PUBLISHED-PORT>:<SERVICE-PORT> 플래그를 사용하여 Swarm은 모든 Swarm 노드의 publish된 포트에서 서비스에 액세스할 수 있도록 합니다.
스웜 노드의 해당 포트에 연결 요청이 오면 라우팅 메시가 이를 자동으로 task로 라우팅합니다.
아래의 예제는 Swarm에서 3개의 Nginx task를 갓는 서비스를 생성합니다. 이떄 Nginx task는 포트 80을 사용하고 스웜에 게시되는 포트는 8080입니다.

$ docker service create --name my-web \
--replicas 3 \
--publish 8080:80
nginx

# 어떤 노드에서 task가 실행되는지 알 필요없이 스웜으로 구성된 노드 중 하나의 8080포트에 연결하면 3개의 task중 하나에 연결됩니다.
# 테스트하려면 스웜 노드 중 하나에서 localhost:8080 으로 curl을 시도합니다.
# 후속 연결은 동일한 노드 또는 다른 노드로 라우팅될 수 있습니다.

노드에 직접 서비스 포트 게시

요청을 서비스 task로 라우팅하는 프로세스를 완전히 제어해야 하는 경우 라우팅 메시를 사용하는 것이 애플리케이션에 적합하지 않을 수 있습니다.
실행 중인 노드에서 서비스의 포트를 직접 게시하려면 --publish 플래그에 대한 mode=host 옵션을 사용합니다.
아래의 예제는 Swarm의 각 노드에서 nginx를 서비스로 실행하고 각 Swarm 노드에서 8080포트를 게시합니다.

$ docker service creaet --name nginx \
--mode global \
--publish mode=host, target=80, published=8080 \
nginx:latest

# 모든 Swarm 노드의 포트 8080포트에서 nginx 서버에 연결할 수 있습니다.
# Swarm에 노드가 추가되면 해당 노드에서 nginx task 작업이 자동으로 실행됩니다.
# 각 노드에서 게시된 8080포트는 다른 task를 통해 사용될 수 없습니다.

Note:

Swarm 노드에 직접 서비스 포트를 게시할 때 mode=host로 설정하고 pubilshed=<PUBLISHED-PORT>를 지정하면 해당 노드에서 게시된 포트로 하나의 task만 실행될 수 있습니다. 이를 해결하려면 pubilished=<PUBLISHED-PORT>를 지정하지 않을 수 있습니다. 이렇게 하면 Docker가 각 task에 대한 임의의 포트를 할당합니다.

서비스 배치 제어

Swarm 서비스는 서로 다른 노드에서 서비스의 규모와 배치를 제어할 수 있는 몇 가지 방법을 제공합니다.

replica 또는 global service
CPU 또는 Memory 요구 사항
배치 제약 조건
배치 기본 설정

Note:

제약 조건과 달리 기본 설정은 최선의 노력이며 노드가 기본 설정을 충족할 수 없다고 해서 서비스 배포에 실패하지 않습니다. 서비스에 대한 기본 설정을 지정하면 Swarm 관리자가 서비스 task를 실행해야 하는 노드를 결정할 때 기본 설정과 일치하는 노드의 순위가 더 높아집니다.

replica 또는 global service

Swarm 모드에는 replica 및 global 두 가지 유형의 서비스가 있습니다.
replica의 경우 Swarm 관리자가 사용 가능한 노드에 예약할 복제본의 task 개수를 지정합니다.
global의 경우 스케줄러는 서비스의 배치 제약 조건 및 리소스 요구 사항을 충족하는 사용 가능한 각 노드에 하나의 task를 배치합니다.
--mode 플래그를 사용하여 서비스 유형을 제어합니다. 모드를 지정하지 않으면 기본적으로 replica로 지정됩니다.
replica 유형의 서비스의 경우 --replicas 플래그를 사용하여 복제본 task 개수를 지정합니다.
global 유형의 서비스를 시작하려면 docker service create 명령에 --mode global 플래그를 전달합니다.
아래의 예제는 replica, global 유형의 서비스를 생성하는 작업을 수행합니다.

# TODO 1. replica
$ docker service create --name my-web \
--replicas 3 \
nginx

# TODO 2. global
$ docker service create --name my-web \
--mode global
nginx

리소스 요구사항

서비스에 대해 지정된 양의 메모리 또는 CPU 수를 예약하려면 --reserve-memory 또는 reserve-cpu 플래그를 사용합니다.
요구 사항을 만족하는 사용 가능한 노드가 없는 경우 서비스는 해당 task를 실행하는 데 사용할 수 있는 적절한 노드가 있을 때가지 pending 상태로 유지됩니다.

Note:

서비스에서 Swarm 노드가 사용할 수 있는 것보다 더 많은 메모리를 사용하려고 하면 OOME(메모리 부족 예외)가 발생할 수 있습니다. 이렇게 되면 컨테이너 또는 Docker 데몬이 커널 OOM 킬러에 의해 종료될 수 있습니다.

배치 제약

배치 제약 조건을 사용하여 서비스를 할당할 수 있는 노드를 제어합니다.
플래그는 --constraint 등호(== 또는 !=)를 사용합니다.
배치 제약 조건과 함께 리소스 제약 조건을 사용할 수도 있습니다.
docker-compose.yml 파일에서 서비스 수준 constraint키를 사용할 수도 있습니다.
replica 서비스 유형의 경우 모든 서비스가 동일한 노드에서 실행되거나 각 노드가 하나의 복제본만 실행하거나 일부 노드가 복제본을 실행하지 않을 수 있습니다.
global 서비스 유형의 경우 배치 제약 조건 및 리소스 요구 사항을 만족하는 모든 노드에서 하나의 task만 실행됩니다.
아래의 예제는 제약 조건을 지정하여 서비스를 생성합니다.

# TDOO 1. region==east 인 노드에서 실행
$ docker service create --name my-nginx \
--replicas 5 \
-- constraint node.labels.region==east \
nginx

# 여러 배치 제약 조건을 지정하는 경우 서비스는 모든 제약 조건을 만족하는 노드에만 배포됩니다.

# TODO 2. region==east 이면서 type!=devel인 노드에서 실행
$ docker service create --name my-nginx \
--replicas 5 \
--constraint node.labels.region==east \
--constraint node.labels.type!=devel \
nginx

배치 기본 설정

배치 제약 조건은 서비스가 실행될 수 있는 노드를 제한하는 반면 배치 기본 설정은 적절한 노드에 task를 배치하려고 시도합니다.
기본 설정에서 지정한 레이블이 있는 노드가 없으면 기본 설정이 지정되지 않은 것처럼 서비스가 배포됩니다.
global 서비스의 경우 배치 기본 설정이 무시됩니다.
배치 제약 조건 또는 리소스 제약 조건과 함께 배치 기본 설정을 사용할 수 있습니다.
docker service update 명령에 --placement-pref-add 또는 --placement-pref-rm 플래그를 사용하여 기본 설정을 추가 또는 제거할 수 있습니다.
아래의 예제는 배치 기본 설정을 사용하여 서비스를 생성합니다.

# TODO 1. datacenter 레이블이 설정된 노드에서 균등하게 배포됩니다.
$ docker service create --name redis_2 \
--replicas 9 \
--placement-pref 'spread=node.labels.datacenter' \
redis:3.0.6

# 여러 배치 기본 설정을 지정할 수 있으며 발생하는 순서대로 처리됩니다.

# TODO 2. datacenter 레이블이 설정된 노드에서 균등하게 배포된 후 rack 레이블 설정된 노드에서 배포됩니다.
$ docker service create --name redis_2 \
--replicas 9 \
--placement-pref 'spread=node.labels.datacenter' \
--placement-pref 'spread=node.labels.rack' \
redis:3.0.6

서비스의 업데이트 동작 구성

서비스를 생성할 때 Swarm이 서비스에 변경 사항을 적용하는 방법에 대한 롤링 업데이트 동작을 지정할 수 있습니다.
docker service update 명령의 인수로 여러가지 플래그를 사용할 수 있습니다.
- update-delay: 업데이트 사이의 시간 지연
- update-parallelism: 스케줄러가 동시에 업데이트하는 최대 서비스 task 수
- update-failure-action: 개별 task에 대한 업데이트가 RUNNING 상태를 반환하면 스케줄러는 모든 task가 업데이트될 때까지 다른 task를 계속하여 업데이트 하지만 업데이트 중 task에서 FAILED 상태를 반환하면 스케줄러가 업데이트를 기본적으로 중지합니다. 이때 update-failure-action을 지정하면 FAILED 상태일 때 동작을 제어할 수 있습니다.
- update-max-failure-ratio: 전체 업데이트가 실패한 것으로 간주되는 비율을 제어합니다. 예를 들어 update-max-faulure-ratio 0.1, --update-failure-action pause 플래그를 사용하면 업데이트 중인 task의 10%가 실패하면 전체 업데이트가 실패한 것으로 간주되고 업데이트는 일시 중지됩니다.
- --update-monitor: 모니터링 기간 내에 실행이 중지되면 개별 task 업데이트가 실패한 것으로 간주됩니다. 기본 값은 30초입니다.
아래의 예제에서 스케줄러는 한 번에 최대 2개의 복제본을 업데이트하고 업데이트된 task가 RUNNING 또는 FAILED 상태를 반환하면 스케줄러는 업데이트할 다음 task을 중지하기 전에 10초 동안 기다립니다.

$ docker service create \
--replicas 10 \
--name my-web \
--update-delay 10s \
--update-parallelism 2 \
--update-failure-action continue \
alpine

서비스의 이전 버전으로 롤백

서비스 버전이 예상대로 작동하지 않는 경우 docker service update의 --rollback 플래그를 사용하여 서비스의 이전 버전으로 수동 롤백할 수 있습니다.
이것은 서비스를 가장 최근에 사용한 docker service update 이전의 구성으로 되돌립니다.
서비스 업데이트 배포에 실패한 경우 자동으로 롤백하도록 서비스를 구성할 수 있습니다. 업데이트 실패 시 자동 롤백을 참고하세요.
--rollback 플래그는 --update-delay 플래그와 함께 사용할 수 있습니다. 예를 들어 작업 지연 시간없이 롤백을 실행하려면 아래와 같이 사용합니다.

$ docker service update \
--rollback \
--update-delay 0s \
my-web

업데이트 실패 시 자동 롤백

서비스 업데이트로 인해 재배포가 실패하는 경우 서비스가 자동으로 이전 구성으로 롤백되도록 서비스를 구성할 수 있습니다.
서브시 생성 또는 업데이트 시 다음 플래그 중 하나 이상을 설정할 수 있습니다. 값을 설정하지 않으면 기본값이 사용됩니다.

플래그	기본	설명
`--rollback-delay`	`0s`	다음 task를 롤백하기 전에 task를 롤백한 후 대기하는 시간입니다.
`--rollback-failure-action`	`pause`	task 롤백에 실패하는 경우 `pause` 또는 `continue` 할지 여부를 결정합니다.
`--rollback-max-failure-ration`	`0`	롤백 중에 허용되는 실패 율로 0과 1사이의 부동 소수점 숫자로 지정됩니다. `0`은 실패가 허용되지 않음을 의미하고 `1`은 모든 실패가 허용됨을 의미합니다.
`--rollback-monitor`	`5s`	이 기간이 경과하기 전에 task가 중지되면 롤백이 실패한 것으로 간주됩니다.
`--rollback-parallelism`	`1`	병렬로 롤백할 최대 task 수를 의미합니다. 기본적으로 한 번에 하나의 task가 롤백됩니다. `0`으로 설정된 경우 모든 task가 병렬로 롤백됩니다.

$ docker service create --name my-web \
--replicas 5 \
--rollback-parallelism 2 \
--rollback-monitor 20s \
--rollback-max-failure-ration .2 \
redis:latest

# 업데이트에 실패한 경우 자동으로 롤백되도록 구성하고 롤백 작업은 2개씩 병렬로 수행됩니다. 또한 task가 바로 종료되지 않도록 20초 동안 모니터링하고 최대 실패율은 20%까지 허용됩니다.

서비스 볼륨

스웜에서는 데이터 볼륨과 바인드 마운트 2가지 유형의 마운트를 생성할 수 있습니다.
사용하는 마운트 유형에 관계없이 서비스를 생성할 때 --mount 플래그를 사용합니다. 기본값은 데이터 볼륨입니다.
기존 서비스를 업데이트할 때 --mount-add 또는 --mount-rm을 사용할 수 있습니다.

데이터 볼륨

데이터 볼륨은 컨테이너와 독립적으로 존재하는 스토리지입니다.
Swarm 서비스에서 데이터 볼륨의 수명 주기는 컨테이너에서와 유사합니다. 볼륨은 task 및 서비스보다 오래 지속되므로 제거하려면 별도로 관리해야 합니다.
서비스를 배포하기 전에 볼륨을 생성할 수 있고 또는 task가 예약된 특정 호스트에 볼륨이 없으면 서비스의 볼륨 사양에 따라 자동으로 생성할 수 있습니다.
task가 특정 호스트에 예약될 때 <VOLUME-NAME>이 동일한 볼륨이 존재하지 않으면 하나가 생성됩니다.
기본 볼륨 드라이버는 local이고 다른 볼륨 드라이버를 사용하려면 volume-driver=<DRIVER> 플래그를 사용하여 드라이버 및 해당 옵션을 지정합니다.
아래의 예제는 데이터 볼륨을 사용합니다.

# TODO 1. 서비스와 함께 기존 데이터 볼륨을 사용합니다.
$ docker service create \
--mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH> \
--name myservice \
<IMAGE>

# TODO 2. 볼륨 드라이버와 볼륨 옵션을 지정하여 생성
$ docker service create \
--mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=<DRIVER>,volume-opt=<KEY0>=<VALUE0>,volume-opt=<KEY1>=<VALUE1>
--name myservice \
<IMAGE>

바인드 마운트

스케줄러가 task를 배포하는 노드의 파일 시스템 경로입니다.
Swarm이 task를 생성하기 전에 파일 시스템 경로가 존재해야 합니다.
아래의 예제는 바인드 마운트를 사용합니다.

# TODO 1. 읽기-쓰기 바인드 마운트
$ docker service create \
--mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH> \
--name myservice \
<IMAGE>

# TODO 2. 읽기 전용 바인드 마운트
$ docker service create \
--mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH>,readonly \
--name myservice \
<IMAGE>

템플릿을 사용하여 서비스 만들기

Go의 text/template 패키지에서 제공하는 구문을 사용하여 일부 플래그에 대한 템플릿을 사용할 수 있습닏나.
다음 플래그가 지원됩니다.
- --hostname
- --mount
- --env
Go 템플릿의 유효한 Placeholder는 다음과 같습니다.
- .Service.ID
- .Service.Name
- .Service.Labels
- .Node.ID
- .Node.Hostname
- .Task.Name
- .Task.Slot
다음은 서비스 이름과 컨테이너가 실행 중인 노드의 ID를 기반으로 생성된 컨테이너의 hostname을 템플릿으로 설정합니다.

$ docker service create --name hosttemp1 \
--hostname="-" \
busybox top

$ docker service ps

ID            NAME         IMAGE                                                                                   NODE          DESIRED STATE  CURRENT STATE               ERROR  PORTS
wo41w8hg8qan  hosttempl.1  busybox:latest@sha256:29f5d56d12684887bdfa50dcd29fc31eea4aaf4ad3bec43daf19026a7ce69912  2e7a8a9c4da2  Running        Running about a minute ago

$ docker inspect --format="" hosttempl.1.wo41w8hg8qanxwjwsg4kxpprj

📌출처

Docker Docs

👍 개인 공부 기록용 블로그입니다. 오류나 조언이 있으시면 언제든지 댓글 혹은 메일로 남겨주시면 감사하겠습니다! 😄

맨 위로 이동하기

갱동구리