고가용성 구성으로 Consul-Terraform-Sync 실행

고가용성(high availability)을 위해 구성된 Consul-Terraform-Sync(CTS)를 실행하는 방법을 설명해 드릴게요. 고가용성은 장애 조치(failover) 전환 중 발생하는 모든 Consul 변경 사항을 처리하고 CTS가 예상대로 계속 작동하도록 보장하는 엔터프라이즈 기능이에요.

출처: 문서

본문

엔터프라이즈

엔터프라이즈 라이선스는 Consul-Terraform-Sync(CTS)의 엔터프라이즈 배포판에만 필요해요.

이 문서에서는 고가용성을 위해 구성된 Consul-Terraform-Sync(CTS)를 실행하는 방법을 설명해요. 고가용성은 장애 조치 전환 중 발생하는 Consul의 모든 변경 사항이 처리되고 CTS가 예상대로 계속 작동하도록 보장하는 엔터프라이즈 기능이에요.

소개

네트워크에는 항상 CTS 클러스터의 인스턴스 중 정확히 하나가 지정된 리더(leader)로 있어요. 리더는 작업을 모니터링하고 실행하는 역할을 담당해요. 리더가 실패하면, 고가용성으로 구성된 CTS는 다음 과정을 트리거해요:

CTS 클러스터가 네트워크의 팔로워(follower) 풀에서 새 리더를 승격해요.
새 리더가 장애 조치 전환 기간 동안 발생한 변경 사항을 처리하기 위해 모든 기존 작업을 once-mode로 실행하기 시작해요. 이 모드에서 CTS는 모든 기존 작업을 한 번 실행해요.
새 리더는 once-mode 작동 중 발생하는 모든 오류를 로그로 기록하고, Consul의 변경 사항을 계속 모니터링해요.

표준 구성에서는 CTS 인스턴스가 once-mode로 작업을 실행할 때 오류가 발생하면 CTS가 종료돼요. 고가용성 구성에서는 CTS가 오류를 로그로 기록하고 중단 없이 계속 작동해요.

다음 다이어그램은 고가용성이 활성화된 상태에서의 작동 상태를 보여줘요. CTS 인스턴스 A가 현재 리더이며 모니터링과 작업 실행을 담당해요:

다음 다이어그램은 리더가 중지된 후의 CTS 클러스터 상태를 보여줘요. CTS 인스턴스 B가 모니터링과 작업 실행을 담당하는 리더가 돼요.

장애 조치 세부 사항

새 리더가 선출되는 데 걸리는 시간은 high_availability.cluster.storage.session_ttl 구성에 의해 결정돼요. 최소 장애 조치 시간은 session_ttl 값과 같아요. 최대 장애 조치 시간은 session_ttl 값의 두 배예요.
작업 실행 중에 장애 조치가 발생하면 새 리더가 선출돼요. 새 리더는 변경 사항 모니터링을 계속하기 전에 모든 작업을 한 번 실행하려고 시도해요.
HCP Terraform 드라이버를 사용하는 경우, 작업이 완료되고 CTS는 새 리더를 시작하여 HCP Terraform의 각 작업에 대해 once-mode에서 run을 큐에 넣으려고 시도해요.
Terraform 드라이버를 사용하는 경우, 작업은 장애 조치의 원인에 따라 완료될 수 있어요. 새 리더가 시작되어 각 작업을 once-mode로 실행하려고 시도해요. 모듈과 프로바이더에 따라 인프라와 Terraform 상태 간의 불일치를 수정하려면 수동 개입이 필요할 수 있어요.
작업이 실행되지 않을 때 장애 조치가 발생하면 CTS는 모든 작업을 once-mode로 실행하려고 시도하는 새 리더를 선출해요.

드라이버 동작은 CTS가 고가용성 모드에서 실행되는지 여부와 관계없이 일관된다는 점에 주의해 주세요.

요구 사항

CTS 실행을 위한 기본 요구 사항을 충족했는지 확인해 주세요.

CTS Enterprise 0.7 이상
Terraform CLI 0.13 이상
클러스터의 모든 인스턴스가 동일한 데이터센터에 있어야 해요.

클러스터에 적절한 ACL 권한을 구성해야 해요. 자세한 내용은 ACL 권한을 참고해 주세요.

고가용성 모드로 실행하려면 CTS 구성에서 HCP Terraform 드라이버를 지정하는 것을 권장해요.

구성

CTS 구성에 high_availability 블록을 추가하고 고가용성을 활성화하려면 필요한 설정을 구성해 주세요. high_availability 블록의 구성 필드에 대한 자세한 내용은 구성 참조를 참고해 주세요.

다음 예시는 cts-cluster라는 클러스터의 고가용성 기능을 구성해요:

cts-config.hcl

high_availability {
   cluster {
      name    = "cts-cluster"
      storage "consul" {
        parent_path = "cts"
        namespace = "ns"
        session_ttl = "30s"
      }
   }

   instance {
      address = "cts-01.example.com"
   }
}

ACL 권한

Consul 환경의 session 및 keys 리소스에는 write 권한이 있어야 해요. ACL 정책을 정의하는 방법에 대한 자세한 내용은 ACL 문서를 참고해 주세요.

high_availability.cluster.storage.namespace 필드가 구성된 경우 ACL 정책은 namespace 리소스에 대한 write 권한도 활성화해야 해요.

새 CTS 클러스터 시작

세 개의 CTS 인스턴스를 포함하는 클러스터를 배포하는 것을 권장해요. 이렇게 하면 클러스터에 리더 하나와 팔로워 둘이 생겨요.

포함하려는 설정(고 high_availability 블록)이 포함된 HCL 구성 파일을 만들어요. 모든 구성 옵션은 Consul-Terraform-Sync 구성 옵션을 참고해 주세요.
시작 명령을 실행하고 구성 파일을 전달해요. CTS 시작 모드에 대한 자세한 내용은 start 명령 참조를 참고해 주세요.

$ consul-terraform-sync start -config-file ha-config.hcl

/status API 엔드포인트를 호출하여 CTS가 모니터링하도록 구성된 작업의 상태를 확인할 수 있어요. 클러스터의 리더만 성공 응답을 반환해요. 사용법과 응답에 대한 자세한 내용은 /status API 참조 문서를 참고해 주세요.

$ curl localhost:<port>/status/tasks

클러스터의 나머지 인스턴스에 대해 이 절차를 반복하세요. 클러스터의 모든 인스턴스에 대해 거의 동일한 구성을 사용하는 것을 권장해요. 모든 경우에 정확히 동일한 구성을 사용하지 못할 수도 있지만, 동일한 구성으로 인스턴스를 시작하면 일관성이 향상되고 오류를 해결해야 할 때 혼란을 줄일 수 있어요.

인스턴스 구성 수정

CTS 인스턴스에 대한 비작업 구성(예: Consul 연결 설정)을 업데이트하기 위해 롤링 업데이트를 구현할 수 있어요. 인스턴스 구성에서 작업을 업데이트해야 한다면 작업 수정을 참고해 주세요.

status/cluster API 엔드포인트를 호출하거나 로그에서 다음 항목을 확인하여 리더 CTS 인스턴스를 식별해요:

[INFO] ha: acquired leadership lock: id=<ID-OF-CTS-INSTANCE>

팔로워 CTS 인스턴스 중 하나를 중지하고 새 구성을 적용해요.
팔로워 인스턴스를 다시 시작해요.
클러스터의 다른 팔로워 인스턴스에 대해 2단계와 3단계를 반복해요.
리더 인스턴스를 중지해요. 팔로워 인스턴스 중 하나가 리더가 돼요.
이전 리더 인스턴스에 새 구성을 적용하고 다시 시작해요.

작업 수정

고가용성이 활성화되면 CTS는 작업 및 이벤트 데이터를 유지해요. 자세한 내용은 상태 저장 및 영속성을 참고해 주세요.

고가용성이 활성화된 상태에서 작업을 수정하려면 다음 방법을 사용할 수 있어요. 메서드를 혼합하면 상태와 구성 간에 불일치가 발생할 수 있으므로 모든 작업 구성 변경에 단일 메서드를 선택하는 것을 권장해요.

작업 삭제 및 재생성

수정이 필요한 경우 작업을 삭제하고 재생성하는 것을 권장해요. CTS API를 사용하여 CTS 리더 인스턴스를 식별하고 작업을 교체해 주세요.

status/cluster API 엔드포인트를 호출하거나 로그에서 다음 항목을 확인하여 리더 CTS 인스턴스를 식별해요:

[INFO] ha: acquired leadership lock: id=<ID-OF-CTS-INSTANCE>

/task/<task-name> 엔드포인트에 DELETE 호출을 보내 작업을 삭제해요. 다음 예시에서 리더 인스턴스는 localhost:8558에 있어요:

$ curl --request DELETE  localhost:8558/v1/tasks/task_a

이 단계를 완료하려면 task delete 명령도 사용할 수 있어요.

/task/<task-name> 엔드포인트에 POST 호출을 보내고 페이로드에 업데이트된 작업을 포함해요.

$ curl --header "Content-Type: application/json" \
--request POST \
--data @payload.json \
localhost:8558/v1/tasks

이 단계를 완료하려면 task-create 명령도 사용할 수 있어요.

-reset-storage 플래그로 데이터 삭제

작업을 업데이트해야 하는 경우 -reset-storage 플래그를 사용하여 CTS 클러스터를 다시 시작하여 유지된 데이터를 삭제할 수 있어요.

팔로워 인스턴스를 중지해요.
인스턴스의 작업 구성을 업데이트해요.
인스턴스를 다시 시작하고 -reset-storage 플래그를 포함해요.
업데이트된 인스턴스가 리더가 되도록 다른 모든 인스턴스를 중지해요.
다른 모든 인스턴스를 다시 시작해요.
3단계에서 다시 시작한 인스턴스를 -reset-storage 플래그 없이 다시 시작하여 현재 상태로 시작되도록 해요. -reset-storage 플래그를 활성화한 인스턴스를 계속 실행하면 CTS는 인스턴스가 리더가 될 때마다 상태 데이터를 재설정해요.

문제 해결

이전 리더가 작업을 성공적으로 실행하고 있었는데 장애 조치 후 새 리더가 오류를 기록하는 경우 다음 문제 해결 절차를 사용해 주세요:

콘솔에 출력된 로그에서 오류를 확인해요. 로그를 찾는 방법에 대한 정보는 syslog 구성을 참고해 주세요. 다음 예시 출력에서 CTS는 401: Bad credentials 오류를 보고했어요:

2022-08-23T09:25:09.501-0700 [ERROR] tasksmanager: error applying task: task_name=config-task
error=
|| error tf-apply for 'config-task': exit status 1
||
|| Error: GET https://api.github.com/user: 401 Bad credentials []
||
|| with module.config-task.provider["registry.terraform.io/integrations/github"],
|| on .terraform/modules/config-task/main.tf line 11, in provider "github":
|| 11: provider "github" {

이전 리더와 새 리더 사이의 차이점(구성, 환경 변수, 로컬 리소스의 차이 등)을 확인해요.
문제를 해결하는 수정 사항을 적용하여 새 인스턴스를 시작해요.
문제가 있는 리더 인스턴스와 동일한 문제가 있을 수 있는 다른 인스턴스를 내려요(tear down).
영향을 받은 인스턴스를 다시 시작하여 수정 사항을 적용해요.

고가용성 구성으로 Consul-Terraform-Sync 실행