일반 업그레이드 프로세스
일반 업그레이드 프로세스 (General Upgrade Process)
이 문서는 Consul을 업그레이드할 때 따라야 하는 전체 프로세스와 모범 사례를 설명해요. 새 버전 다운로드, 업그레이드 준비, 실제 업그레이드 수행, 문제 해결 과정을 다룰게요.
출처: 문서
본문
이 페이지는 Consul을 업그레이드할 때 따라야 하는 전체 프로세스와 모범 사례를 설명합니다. 일부 버전에는 해당 버전에 특정한 단계도 있으므로 현재 버전의 업그레이드 지침도 반드시 검토하세요.
새 버전 다운로드 (Download the New Version)
먼저 원하는 새 버전의 바이너리를 다운로드합니다.
Binary
Docker
Kubernetes
CE와 Enterprise 릴리즈의 모든 현재 및 과거 버전은 여기에서 사용할 수 있습니다:
Docker 컨테이너는 다음 위치에서 사용할 수 있습니다:
- CE: https://hub.docker.com/_/consul
- Enterprise: https://hub.docker.com/r/hashicorp/consul-enterprise
Kubernetes를 사용한다면 Kubernetes에서 Consul 업그레이드 문서를 검토하세요.
업그레이드 준비 (Prepare for the Upgrade)
-
문제가 발생할 경우 안전한 폴백 옵션을 보장하기 위해 스냅샷을 만듭니다.
$ consul snapshot save backup.snap스냅샷을 검사해 클러스터의 Raft 인덱스가 성공적으로 캡처되었는지 확인할 수 있습니다.
$ consul snapshot inspect backup.snap예제 출력:
ID 2-1182-1542056499724 Size 4115 Index 1182 Term 2 Version 1스냅샷을 안전한 곳에 저장합니다. 스냅샷에 대한 자세한 내용은 다음을 참조하세요:
-
에이전트의
log_level이debug로 설정되도록 Consul 구성을 임시로 수정합니다. 그런 다음 서버에서 다음 명령을 실행해 구성을 재로드합니다:$ consul reload클러스터 로그 수준을 변경하면 문제가 발생할 경우 Consul이 작업할 더 많은 정보를 제공합니다.
Enterprise 업그레이드 (Enterprise upgrades)
참고
Consul Enterprise에서 더 원활한 업그레이드 과정을 경험하려면 업그레이드 마이그레이션 기능을 비활성화할 것을 권장합니다.
Consul Enterprise는 자동 업그레이드를 지원하지만, autopilot 기능은 업데이트된 Consul 버전을 실행하는 노드가 기존 클러스터 리더의 버전이 업데이트되기 전에 새 리더를 선출하게 할 수 있습니다.
데이터센터가 Consul Enterprise를 실행한다면 autopilot의 업그레이드 마이그레이션을 비활성화하도록 서버 에이전트 구성 파일을 업데이트하거나 다음 CLI 명령을 실행합니다:
$ consul operator autopilot set-config -disable-upgrade-migration=true
업그레이드 수행 (Perform the Upgrade)
-
다음 명령을 실행해 현재 리더인 서버를 확인합니다:
$ consul operator raft list-peers다음과 유사한 출력을 받아야 합니다(정확한 형식과 내용은 버전에 따라 다를 수 있음):
Node ID Address State Voter RaftProtocol dc1-node1 ae15858f-7f5f-4dcb-b7d5-710fdcdd2745 10.11.0.2:8300 leader true 3 dc1-node2 20e6be1b-f1cb-4aab-929f-f7d2d43d9a96 10.11.0.3:8300 follower true 3 dc1-node3 658c343b-8769-431f-a71a-236f9dbb17b3 10.11.0.4:8300 follower true 3어느 에이전트가 리더인지 기록해 둡니다.
-
새
consul바이너리를 서버에 복사하고 기존 바이너리를 새 바이너리로 교체합니다. -
시스템 창에서 서버의 Consul 서비스를 재시작합니다. 팔로워 서버 에이전트를 먼저 재시작하고 리더 에이전트를 마지막에 남겨 두어야 합니다. 서비스 관리 시스템을 사용하지 않는다면 에이전트를 수동으로 재시작해야 합니다. 재시작 후 에이전트가 클러스터에 다시 조인하고 리더와 동기화되었는지 검증하려면 에이전트에 다음 명령을 실행합니다:
$ consul infocommit_index와last_log_index필드가 같은 값인지 확인합니다. 제대로 수행했다면 쿼럼 손실로 인한 예기치 않은 리더십 선거를 피할 수 있습니다. -
모든 서버가 예상대로 클러스터에 조인했고 올바른 버전을 실행하는지 다시 확인합니다. 다음 명령을 실행합니다:
$ consul members서버가
alive로 나열되고 같은 업데이트된 Consul 버전을 실행하는 출력을 받아야 합니다.Node Address Status Type Build Protocol DC dc1-node1 10.11.0.2:8301 alive server 1.8.3 2 dc1 dc1-node2 10.11.0.3:8301 alive server 1.8.3 2 dc1 dc1-node3 10.11.0.4:8301 alive server 1.8.3 2 dc1또한 Raft 상태를 다시 확인해 리더와 충분한 투표자가 있는지 확인합니다:
$ consul operator raft list-peers한 서버가
leader로, 나머지가follower로 나열되는 출력을 받아야 합니다:Node ID Address State Voter RaftProtocol dc1-node1 ae15858f-7f5f-4dcb-b7d5-710fdcdd2745 10.11.0.2:8300 leader true 3 dc1-node2 20e6be1b-f1cb-4aab-929f-f7d2d43d9a96 10.11.0.3:8300 follower true 3 dc1-node3 658c343b-8769-431f-a71a-236f9dbb17b3 10.11.0.4:8300 follower true 3 -
log_level을 원래 값으로 다시 설정하고 서버에서 다음 명령을 실행해 구성을 재로드합니다:$ consul reload
문제 해결 (Troubleshooting)
업그레이드 시 대부분의 문제는 리더 에이전트를 마지막에 업그레이드하지 않았거나, 팔로워 에이전트가 다른 서버로 이동하기 전에 클러스터에 완전히 다시 조인할 때까지 기다리지 않아서 발생합니다. 이로 인해 쿼럼이 손실될 수 있고 때로는 모든 서버가 쿼럼에 도달하고 리더를 선출하지 못한 채 끝없이 리더십 선거를 시작하려는 결과가 나올 수 있습니다. Consul Enterprise 사용자는 autopilot이 조기에 새 클러스터 리더를 선출하지 않도록 업그레이드 마이그레이션을 비활성화해야 합니다.
이러한 문제들은 대부분 Consul 클러스터 재해 복구 문서에 설명된 단계를 따르면 해결할 수 있습니다. 그곳에 설명된 복구 단계를 시도한 후에도 문제가 지속되면 추가 지원을 위한 다음 옵션을 사용할 수 있습니다:
- 유료 지원 계획이 없는 CE 사용자는 커뮤니티 포럼에서 도움을 요청할 수 있습니다.
- 유료 지원 계획이 있는 Enterprise 및 CE 사용자는 HashiCorp 지원에 연락할 수 있습니다.
HashiCorp 지원에 연락할 때 티켓에 다음 정보를 포함해 주세요:
- 업그레이드하는 FROM과 TO의 Consul 버전.
- 문제가 있는 클러스터의 모든 서버에서 디버그 수준 로그. 여기에는 업그레이드 시도 전부터 현재까지의 로그가 포함되어야 합니다. 로그가 업그레이드 전에 디버그 수준으로 설정되지 않았다면 그 로그도 포함하고, 구성을 디버그 로그로 업데이트한 후의 로그도 포함해 주세요.
- Consul 구성 파일(시크릿은 편집(redact)해 주세요).
- 클러스터의 각 서버에서
consul members -detailed와consul operator raft list-peers의 출력.