Consul 설정 방법

Tier: Premium, Ultimate Offering: Self-managed

Consul 클러스터는 서버 및 클라이언트 에이전트로 구성됩니다. 서버는 고유한 노드에서 실행되고, 클라이언트는 서버와 통신하는 다른 노드에서 실행됩니다.

GitLab Premium에는 Consul의 번들 버전이 포함되어 있으며, /etc/gitlab/gitlab.rb를 사용하여 관리할 수 있는 서비스 네트워킹 솔루션입니다.

사전 요구 사항

Consul을 구성하기 전에:

참조 아키텍처 문서를 검토하여 가져야 할 Consul 서버 노드의 수를 결정하세요.
필요한 경우, 방화벽에서 적절한 포트가 열려 있는지 확인합니다.

Consul 노드 구성

각각의 Consul 서버 노드에서:

선호하는 플랫폼을 선택하여 GitLab을 설치하는 지침에 따르되, EXTERNAL_URL 값을 제공하지 마십시오.

/etc/gitlab/gitlab.rb를 편집하고, 아래 내용을 추가하고 retry_join 섹션에 표시된 값을 대체하세요. 아래 예에서는 세 개의 노드가 있으며, 그중 두 개는 IP로, 나머지 하나는 FQDN으로 표시되어 있으며, 두 가지 표기법 중 원하는 표기법을 사용할 수 있습니다.

# Consul 외의 모든 컴포넌트를 비활성화합니다.
roles ['consul_role']
   
# Consul 노드: FQDN 또는 IP로 구분하여 나열합니다.
consul['configuration'] = {
  server: true,
  retry_join: %w(10.10.10.1 consul1.gitlab.example.com 10.10.10.2)
}
   
# 자동 마이그레이션을 비활성화합니다.
gitlab_rails['auto_migrate'] = false

변경 사항이 적용되도록 GitLab을 재구성합니다.

Consul이 올바르게 구성되었는지 확인하고 모든 서버 노드가 통신하는지를 확인하려면 다음 명령을 실행하세요:

sudo /opt/gitlab/embedded/bin/consul members

결과는 다음과 유사해야 합니다:

Node                 Address               Status  Type    Build  Protocol  DC
CONSUL_NODE_ONE      XXX.XXX.XXX.YYY:8301  alive   server  0.9.2  2         gitlab_consul
CONSUL_NODE_TWO      XXX.XXX.XXX.YYY:8301  alive   server  0.9.2  2         gitlab_consul
CONSUL_NODE_THREE    XXX.XXX.XXX.YYY:8301  alive   server  0.9.2  2         gitlab_consul

결과에서 상태가 alive가 아닌 노드가 표시되거나 세 개의 노드 중 어느 것이 빠졌다면, 문제 해결 섹션을 참조하십시오.

Consul 노드 업그레이드

Consul 노드를 업그레이드하려면 GitLab 패키지를 업그레이드합니다.

노드는 다음과 같아야 합니다:

리눅스 패키지를 업그레이드하기 전에 건전한 클러스터의 구성원이어야 합니다.
한 번에 한 노드씩 업그레이드해야 합니다.

각 노드에서 다음 명령을 실행하여 클러스터에서 기존의 건전함 상태를 확인하세요. 클러스터가 건전한 경우 빈 배열이 반환됩니다:

curl "http://127.0.0.1:8500/v1/health/state/critical"

Consul 버전이 변경된 경우, gitlab-ctl reconfigure의 끝에 새 버전을 사용하기 위해 Consul을 다시 시작해야 한다는 안내가 표시됩니다.

다음과 같이 각각의 노드에서 Consul을 재시작합니다:

sudo gitlab-ctl restart consul

Consul 노드는 raft 프로토콜을 사용하여 통신합니다. 현재 리더가 오프라인 상태인 경우 리더 선출이 이루어져야 합니다. 클러스터 전체에서 동기화를 촉진할 리더 노드가 존재해야 합니다. 너무 많은 노드가 동시에 오프라인 상태가 되면 클러스터가 크어럼을 상실하고 consensus가 깨짐으로 인해 리더가 선출되지 않게 됩니다.

업그레이드 후 클러스터가 회복되지 못하는 경우 문제 해결 섹션을 참조할 수 있습니다. 장애 복구가 특별히 유용할 수 있습니다.

GitLab은 Consul을 사용하여 쉽게 재생성할 수 있는 임시 데이터만 저장합니다. 번들에 포함된 Consul이 GitLab 이외의 프로세스에서 사용되지 않았다면 처음부터 클러스터를 재구축할 수 있습니다.

Consul 문제 해결

다음은 문제를 해결해야 할 경우 유용한 일부 작업입니다. 다음 명령을 실행하여 에러 로그를 확인할 수 있습니다:

sudo gitlab-ctl tail consul

클러스터 멤버십 확인

클러스터의 일부인 노드를 확인하려면 클러스터의 어떤 멤버에서 다음을 실행합니다:

sudo /opt/gitlab/embedded/bin/consul members

결과는 다음과 유사해야 합니다:

Node            Address               Status  Type    Build  Protocol  DC
consul-b        XX.XX.X.Y:8301        alive   server  0.9.0  2         gitlab_consul
consul-c        XX.XX.X.Y:8301        alive   server  0.9.0  2         gitlab_consul
consul-c        XX.XX.X.Y:8301        alive   server  0.9.0  2         gitlab_consul
db-a            XX.XX.X.Y:8301        alive   client  0.9.0  2         gitlab_consul
db-b            XX.XX.X.Y:8301        alive   client  0.9.0  2         gitlab_consul

이상적으로 모든 노드는 Status가 alive여야 합니다.

Consul 재시작

Consul을 재시작해야 하는 경우, 클러스터를 유지하기 위해 조절된 방식으로 이를 수행하는 것이 중요합니다. 만약 quorum이 상실된 경우, 클러스터를 회복하기 위해 Consul 장애 복구 프로세스를 따라야 합니다.

안전을 위해 클러스터가 유지되도록 오직 한 노드씩 Consul을 재시작하는 것이 권장됩니다. 더 큰 클러스터의 경우, 여러 노드를 동시에 재시작할 수 있습니다. 동시 재시작을 지원할 수 있는 실패 수에 대한 정보는 Consul consensus document에서 확인할 수 있습니다.

Consul을 다시 시작하려면:

sudo gitlab-ctl restart consul

Consul 노드간 통신 불가

기본적으로 Consul은 0.0.0.0에 바인딩을 시도하지만, 다른 Consul 노드가 통신할 수 있도록 노드의 첫 번째 사설 IP 주소를 광고합니다. 다른 노드가 이 주소로 노드와 통신할 수 없는 경우 클러스터는 실패 상태입니다.

이 문제가 발생하면 gitlab-ctl tail consul에서 다음과 같은 메시지가 출력됩니다.

2017-09-25_19:53:39.90821     2017/09/25 19:53:39 [WARN] raft: no known peers, aborting election
2017-09-25_19:53:41.74356     2017/09/25 19:53:41 [ERR] agent: failed to sync remote state: No cluster leader

이 문제를 해결하려면 다음을 수행합니다.

각 노드에서 다른 모든 노드가 해당 노드에 도달할 수 있는 주소를 선택합니다.

/etc/gitlab/gitlab.rb을 업데이트합니다.

consul['configuration'] = {
  ...
  bind_addr: 'IP 주소'
}

GitLab을 다시 구성합니다.
```
gitlab-ctl reconfigure
```

에러가 계속되는 경우 영향을 받는 노드에서 Consul 데이터베이스를 삭제하고 처음부터 다시 초기화해야 할 수 있습니다.

Consul 시작되지 않음 - 여러 사설 IP

노드에 여러 개의 사설 IP가 있는 경우, Consul은 광고해야 할 사설 주소를 알 수 없으며 즉시 시작을 종료합니다.

다음과 같은 메시지가 gitlab-ctl tail consul에 출력됩니다.

2017-11-09_17:41:45.52876 ==> Starting Consul agent...
2017-11-09_17:41:45.53057 ==> Error creating agent: Failed to get advertise address: Multiple private IPs found. Please configure one.

이 문제를 해결하려면 다음을 수행합니다.

다른 모든 노드가 해당 노드에 도달할 수 있는 노드의 주소를 선택합니다.

/etc/gitlab/gitlab.rb을 업데이트합니다.

consul['configuration'] = {
  ...
  bind_addr: 'IP 주소'
}

GitLab을 다시 구성합니다.
```
gitlab-ctl reconfigure
```

장애 복구

Consul 노드의 충분한 손실로 쿼럼이 깨져 클러스터가 실패로 간주되고 매뉴얼 개입 없이 작동할 수 없는 경우, 노드를 처음부터 다시 만들거나 복구를 시도할 수 있습니다.

처음부터 다시 만들기

기본적으로 GitLab은 다시 생성할 수 있는 Consul 노드에 어떠한 것도 저장하지 않습니다. 따라서 Consul 데이터베이스를 지우고 다시 초기화하려면 다음을 수행합니다.

sudo gitlab-ctl stop consul
sudo rm -rf /var/opt/gitlab/consul/data
sudo gitlab-ctl start consul

이후 노드가 다시 시작되고 나머지 서버 에이전트가 다시 참여합니다. 그 후에 클라이언트 에이전트도 다시 참여해야 합니다.

참여하지 않는 경우 클라이언트에서도 Consul 데이터를 지우어야 할 수 있습니다.

sudo rm -rf /var/opt/gitlab/consul/data

실패한 노드 복구

Consul을 사용하여 다른 데이터를 저장하고 실패한 노드를 복구하려면 Consul 가이드에 따라 복구합니다.

Consul 설정 방법

사전 요구 사항

Consul 노드 구성

Consul 노드 업그레이드

Consul 문제 해결

클러스터 멤버십 확인

Consul 재시작

Consul 노드간 통신 불가

Consul 시작되지 않음 - 여러 사설 IP

장애 복구

처음부터 다시 만들기

실패한 노드 복구

도움말

기능 사용 가능성과 제품 평가판

도움받기