잡 스펙의 `update` 블록

update 블록은 그룹의 업데이트 전략을 지정해요. 업데이트 전략은 롤링 업그레이드와 카나리 배포 같은 것을 제어하는 데 사용돼요. 생략하면 기본 업데이트 전략이 적용돼요. 잡 레벨에서 지정하면 그 설정이 잡 안의 모든 그룹에 적용돼요. 여러 update 블록이 지정되면 그룹 블록이 가장 높은 우선순위를 차지하고 그다음 잡으로 병합돼요.

출처: 문서

본문

배치	`job -> update`
	`job -> group -> update`

job "docs" {
  update {
    max_parallel      = 3
    health_check      = "checks"
    min_healthy_time  = "10s"
    healthy_deadline  = "5m"
    progress_deadline = "10m"
    auto_revert       = true
    auto_promote      = true
    canary            = 1
    stagger           = "30s"
  }
}

매개변수 (Parameters)

max_parallel (int: 1) - 태스크 그룹 안에서 동시에 파괴적으로 업데이트할 수 있는 할당 수. 태스크 그룹 자체는 병렬로 업데이트돼요. 인플레이스(in-place) 업데이트는 한 번에 모두 수행돼요.
- max_parallel = 0 - 배포 대신 강제 업데이트를 사용해야 함을 지정.

참고: 시스템 잡은 노드당 할당 하나만 지원해요. canary가 설정되면 시스템 잡 업데이트는 최대 max_parallel 파괴적 업데이트를 하거나, 실현 가능한 노드의 canary 백분율에 배치할 만큼의 할당을 파괴적으로 업데이트하며, 둘 중 낮은 쪽을 따르는 업데이트를 해요. 원하는 모든 카나리를 배포할 수 있도록 max_parallel 값을 조정해야 해요.

health_check (string: "checks") - 할당의 건강 상태가 결정되는 메커니즘. 가능한 값:
- "checks" - 모든 태스크가 실행 중이고 관련 checks가 healthy일 때 할당이 healthy로 간주되고, 태스크 중 하나라도 실패하거나 모든 체크가 healthy가 되지 않으면 unhealthy로 간주되도록 지정. "task_states" 모드의 상위 집합이에요.
- "task_states" - 모든 태스크가 실행 중일 때 할당이 healthy로 간주되고 태스크가 실패하면 unhealthy로 간주되도록 지정.
- "manual" - Nomad가 자동으로 건강 상태를 결정하지 않고 운영자가 HTTP API를 사용해 할당 건강 상태를 지정하도록 지정.
min_healthy_time (string: "10s") - 할당이 healthy로 표시되고 추가 할당 업데이트의 잠금이 풀리기 전에 healthy 상태에 있어야 하는 최소 시간. "30s" 또는 "15m" 같은 레이블 접미사로 지정돼요.
healthy_deadline (string: "5m") - 할당이 healthy로 표시되어야 하는 deadline. 이후 할당은 자동으로 unhealthy로 전환돼요. "2m" 또는 "1h" 같은 레이블 접미사로 지정돼요. progress_deadline이 0이 아니면 healthy_deadline보다 커야 해요. 그렇지 않으면 progress_deadline이 할당이 healthy_deadline에 도달하기 전에 배포를 실패시킬 수 있어요.
progress_deadline (string: "10m") - 할당이 healthy로 표시되어야 하는 deadline. 이 deadline은 배포의 첫 번째 할당이 생성될 때 시작되고, 배포의 일부로 할당이 healthy 상태로 전환되거나 배포가 수동으로 승격될 때마다 재설정돼요. progress deadline 전에 어떤 할당도 healthy 상태로 전환되지 않으면 배포는 failed로 표시돼요. progress_deadline이 0으로 설정되면 unhealthy로 표시되는 첫 번째 할당이 배포를 실패시켜요. "2m" 또는 "1h" 같은 레이블 접미사로 지정돼요.
auto_revert (bool: false) - 배포 실패 시 잡이 마지막 안정적인 잡으로 자동 되돌릴지 여부. 잡의 배포 일부인 모든 할당이 healthy로 표시되면 잡은 stable로 표시돼요.
auto_promote (bool: false) - 배포 중 모든 카나리가 healthy가 되면 잡이 카나리 버전으로 자동 승격할지 여부. 기본값은 false이며, 이는 카나리를 nomad deployment promote 명령으로 수동으로 업데이트해야 함을 의미해요. 잡에 여러 태스크 그룹이 있으면 배포가 자동으로 승격되려면 모두 auto_promote = true로 설정해야 해요.
canary (int: 0) - 파괴적 업데이트를 초래할 잡 변경이 이전 할당을 중지하지 않고 지정된 수의 카나리를 만들어야 함을 지정. 운영자가 카나리가 healthy하다고 판단하면 승격할 수 있고, 그러면 max_parallel 비율로 나머지 할당의 롤링 업데이트 차단이 풀려요. 카나리 배포는 per_alloc = true일 때 볼륨과 함께 사용할 수 없어요.

시스템 잡에서 canary 설정은 Nomad가 파괴적 할당 업데이트를 하는 실현 가능한 노드의 백분율을 나타내요. 시스템 잡은 노드당 둘 이상의 할당을 지원하지 않으므로, canary를 양의 정수로 설정하는 것은 업데이트가 파괴적일 때 이 백분율의 실현 가능한 노드가 잡의 새 버전을 받는다는 것을 의미해요. 비파괴적 업데이트는 canary 필드를 무시해요. canary를 100으로 설정하면 모든 노드에서 잡을 업데이트해요. 노드 백분율은 항상 가장 가까운 정수로 올림돼요. canary가 설정되면 배포 중 등록되는 노드는 배포가 승격된 후에만 배치를 받아요.

참고: canary가 설정된 업데이트는 최대 max_parallel 파괴적 업데이트를 하거나, 실현 가능한 노드의 canary 백분율에 배치할 만큼의 할당을 파괴적으로 업데이트하며, 둘 중 낮은 쪽을 따르는 업데이트를 해요. 원하는 모든 카나리를 배포할 수 있도록 max_parallel 값을 조정해야 해요.

stagger (string: "30s") - 시스템 잡을 업데이트할 때 각 max_parallel 업데이트 세트 사이의 지연. 이 설정은 폐기 예정이며 min_healthy_time과 동일해요.

예시 (Examples)

다음 예시는 update 블록만 보여줘요. update 블록은 위에 나열된 배치에서만 유효하다는 점을 기억하세요.

체크 기반 병렬 업그레이드 (Parallel upgrades based on checks)

이 예시는 한 번에 3개 업그레이드를 수행하고, 롤링 업그레이드를 계속하기 전에 할당이 최소 30초간 healthy여야 해요. 각 할당은 자동으로 unhealthy로 표시되고 배포가 실패하기 전에 건강 상태를 결정할 수 있는 시간이 최대 2분 주어져요.

update {
  max_parallel     = 3
  min_healthy_time = "30s"
  healthy_deadline = "2m"
}

태스크 상태 기반 병렬 업그레이드 (Parallel upgrades based on task state)

이 예시는 이전과 같지만 태스크만 healthy하면 되고 등록된 서비스 체크가 healthy할 필요는 없어요.

update {
  max_parallel     = 3
  min_healthy_time = "30s"
  healthy_deadline = "2m"
  health_check     = "task_states"
}

카나리 업그레이드 (Canary upgrades)

이 예시는 잡이 업데이트될 때 카나리 할당을 만들어요. 카나리는 잡의 이전 할당을 중지하지 않고 만들어지며, 운영자가 잡의 새 버전을 롤아웃해야 할지 결정할 수 있게 해요.

update {
  canary       = 1
  max_parallel = 3
}

운영자가 새 잡을 배포해야 한다고 결정하면 배포를 승격할 수 있으며, 그룹 나머지 할당이 새 버전으로 롤링될 때까지 한 번에 3개 업데이트를 수행하는 롤링 업데이트가 발생해요.

# Promote the canaries for the job.
$ nomad job promote <job-id>

블루/그린 업그레이드 (Blue/Green upgrades)

카나리 수를 태스크 그룹의 count와 같게 설정하면 블루/그린 배포를 달성할 수 있어요. 잡의 새 버전이 제출되면 기존 할당의 롤링 업그레이드를 하는 대신, 그룹의 새 버전이 기존 세트 옆에 배포돼요. 이는 업그레이드 과정에서 필요한 리소스를 복제하지만, 그룹의 원래 버전이 손대지 않기 때문에 매우 안전한 배포를 가능하게 해요.

group "api-server" {
    count = 3

    update {
      canary       = 3
      max_parallel = 3
    }
    ...
}

운영자가 그룹의 새 버전이 안정적이라고 판단하면 그룹을 승격할 수 있으며, 이는 그룹의 이전 버전에 대한 모든 할당이 종료되는 결과를 낳아요. 이것으로 파란색에서 초록색으로, 또는 이전 버전에서 새 버전으로의 업그레이드가 완료돼요.

# Promote the canaries for the job.
$ nomad job promote <job-id>

직렬 업그레이드 (Serial upgrades)

이 예시는 직렬 업그레이드 전략을 사용해요. 즉 정확히 하나의 태스크 그룹이 한 번에 업데이트된다는 뜻이에요. 할당은 기본 min_healthy_time 10초 동안 healthy해야 해요.

update {
  max_parallel = 1
}

Update 블록 상속 (Update block inheritance)

이 예시는 여러 태스크 그룹이 있을 때 상속이 잡을 단순화할 수 있는 방법을 보여줘요.

job "example" {
  ...

  update {
    max_parallel     = 2
    health_check     = "task_states"
    healthy_deadline = "10m"
  }

  group "one" {
    ...

    update {
      canary = 1
    }
  }

  group "two" {
    ...

    update {
      min_healthy_time = "3m"
    }
  }
}

공유 매개변수를 잡의 update 블록에 배치하면 각 그룹의 update 블록을 최소로 유지할 수 있어요. 각 그룹에 대한 병합된 update 블록:

group "one" {
  update {
    canary           = 1
    max_parallel     = 2
    health_check     = "task_states"
    healthy_deadline = "10m"
  }
}

group "two" {
  update {
    min_healthy_time = "3m"
    max_parallel     = 2
    health_check     = "task_states"
    healthy_deadline = "10m"
  }
}

잡 스펙의 `update` 블록