InfoGrab DocsInfoGrab Docs

Consul 설정 방법

요약

Consul 클러스터는 서버 에이전트와 클라이언트 에이전트 모두로 구성됩니다. GitLab Premium에는 /etc/gitlab/gitlab.rb로 관리할 수 있는 서비스 네트워킹 솔루션인 Consul의 번들 버전이 포함되어 있습니다.

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

GitLab Premium에는 /etc/gitlab/gitlab.rb로 관리할 수 있는 서비스 네트워킹 솔루션인 Consul의 번들 버전이 포함되어 있습니다.

사전 요구 사항#

Consul을 구성하기 전에 다음을 수행합니다.

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

Consul 노드 구성#

각 Consul 서버 노드에서 다음을 수행합니다.

  1. 선호하는 플랫폼을 선택하여 GitLab을 설치하는 지침을 따르되, 값을 요청받더라도 EXTERNAL_URL 값은 제공하지 않습니다.

  2. /etc/gitlab/gitlab.rb를 편집하고, retry_join 섹션에 표시된 값을 교체하여 다음을 추가합니다. 아래 예시에는 노드가 세 개 있으며, 두 개는 IP로, 하나는 FQDN으로 표시되어 있습니다. 어느 표기법이든 사용할 수 있습니다.

    # Disable all components except Consul
roles ['consul_role']

# Consul nodes: can be FQDN or IP, separated by a whitespace
consul['configuration'] = {
  server: true,
  retry_join: %w(10.10.10.1 consul1.gitlab.example.com 10.10.10.2)
}

# Disable auto migrations
gitlab_rails['auto_migrate'] = false

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

  4. 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 노드 보안#

TLS 또는 가십 암호화를 사용하여 Consul 노드 간 통신을 보호하는 방법은 두 가지입니다.

TLS 암호화#

기본적으로 Consul 클러스터에서는 TLS가 활성화되지 않습니다. 기본 구성 옵션과 그 기본값은 다음과 같습니다.

consul['use_tls'] = false
consul['tls_ca_file'] = nil
consul['tls_certificate_file'] = nil
consul['tls_key_file'] = nil
consul['tls_verify_client'] = nil

이 구성 옵션은 클라이언트 노드와 서버 노드 모두에 적용됩니다.

Consul 노드에서 TLS를 활성화하려면 consul['use_tls'] = true로 시작합니다. 노드의 역할(서버 또는 클라이언트)과 TLS 관련 선호 설정에 따라 추가 구성을 제공해야 합니다.

  • 서버 노드에서는 최소한 tls_ca_file, tls_certificate_file, tls_key_file을 지정해야 합니다.
  • 클라이언트 노드에서는 서버의 클라이언트 TLS 인증이 비활성화된 경우 (기본값은 활성화) 최소한 tls_ca_file을 지정해야 하며, 그렇지 않으면 tls_certificate_file, tls_key_file을 사용하여 클라이언트 TLS 인증서와 키를 전달해야 합니다.

TLS가 활성화되면 서버는 기본적으로 mTLS를 사용하고 HTTPS와 HTTP 모두에서 수신합니다(TLS RPC와 비TLS RPC도 함께). 서버는 클라이언트가 TLS 인증을 사용할 것으로 기대합니다. consul['tls_verify_client'] = false를 설정하면 클라이언트 TLS 인증을 비활성화할 수 있습니다.

반면 클라이언트는 서버 노드로 나가는 연결에만 TLS를 사용하고, 들어오는 요청에 대해서는 HTTP(및 비TLS RPC)에서만 수신합니다. consul['https_port']를 음수가 아닌 정수로 설정하면 (8501이 Consul의 기본 HTTPS 포트) 클라이언트 Consul 에이전트가 들어오는 연결에 TLS를 사용하도록 강제할 수 있습니다. 이렇게 하려면 tls_certificate_file과 tls_key_file도 함께 전달해야 합니다. 서버 노드가 클라이언트 TLS 인증을 사용하면 클라이언트 TLS 인증서와 키는 TLS 인증과 들어오는 HTTPS 연결 모두에 사용됩니다.

Consul 클라이언트 노드는 (서버와 달리) 기본적으로 TLS 클라이언트 인증을 사용하지 않으므로, consul['tls_verify_client'] = true를 설정하여 명시적으로 사용하도록 지시해야 합니다.

다음은 TLS 암호화 예시입니다.

최소 TLS 지원#

다음 예시에서 서버는 들어오는 연결에 TLS를 사용합니다(클라이언트 TLS 인증 없음).

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['configuration'] = {
  'server' => true
}

consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/server.crt.pem'
consul['tls_key_file'] = '/path/to/server.key.pem'
consul['tls_verify_client'] = false

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

다음은 예를 들어 Patroni 노드에서 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
patroni['consul']['url'] = 'http://localhost:8500'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

Patroni는 들어오는 연결에 TLS를 사용하지 않는 로컬 Consul 에이전트와 통신합니다. 그래서 patroni['consul']['url']에 HTTP URL을 사용합니다.

기본 TLS 지원#

다음 예시에서 서버는 상호 TLS 인증을 사용합니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['configuration'] = {
  'server' => true
}

consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/server.crt.pem'
consul['tls_key_file'] = '/path/to/server.key.pem'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

다음은 예를 들어 Patroni 노드에서 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/client.crt.pem'
consul['tls_key_file'] = '/path/to/client.key.pem'
patroni['consul']['url'] = 'http://localhost:8500'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

Patroni는 Consul 서버 노드에 TLS 인증을 사용하더라도, 들어오는 연결에는 TLS를 사용하지 않는 로컬 Consul 에이전트와 통신합니다. 그래서 patroni['consul']['url']에 HTTP URL을 사용합니다.

전체 TLS 지원#

다음 예시에서는 클라이언트와 서버 모두 상호 TLS 인증을 사용합니다.

상호 TLS 인증이 동작하려면 Consul 서버, 클라이언트, Patroni 클라이언트 인증서가 동일한 CA에서 발급되어야 합니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['configuration'] = {
  'server' => true
}

consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/server.crt.pem'
consul['tls_key_file'] = '/path/to/server.key.pem'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

다음은 예를 들어 Patroni 노드에서 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['use_tls'] = true
consul['tls_verify_client'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/client.crt.pem'
consul['tls_key_file'] = '/path/to/client.key.pem'
consul['https_port'] = 8501

patroni['consul']['url'] = 'https://localhost:8501'
patroni['consul']['cacert'] = '/path/to/ca.crt.pem'
patroni['consul']['cert'] = '/opt/tls/patroni.crt.pem'
patroni['consul']['key'] = '/opt/tls/patroni.key.pem'
patroni['consul']['verify'] = true

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

가십 암호화#

가십 프로토콜을 암호화하면 Consul 에이전트 간의 통신을 보호할 수 있습니다. 기본적으로 암호화는 활성화되지 않으며, 암호화를 활성화하려면 공유 암호화 키가 필요합니다. 편의를 위해 gitlab-ctl consul keygen 명령으로 키를 생성할 수 있습니다. 키는 길이가 32바이트여야 하고, Base 64로 인코딩되어야 하며, 모든 에이전트에서 공유되어야 합니다.

다음 옵션은 클라이언트 노드와 서버 노드 모두에서 동작합니다.

가십 프로토콜을 활성화하려면 다음을 수행합니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['encryption_key'] = <base-64-key>
consul['encryption_verify_incoming'] = true
consul['encryption_verify_outgoing'] = true

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

기존 데이터센터에서 암호화를 활성화하려면 롤링 업데이트를 위해 이 옵션을 수동으로 설정합니다.

Consul 노드 업그레이드#

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

노드는 다음 조건을 충족해야 합니다.

  • Linux 패키지를 업그레이드하기 전에 정상적인 클러스터의 멤버여야 합니다.
  • 한 번에 한 노드씩 업그레이드해야 합니다.

각 노드에서 다음 명령을 실행하여 클러스터에 존재하는 상태 문제를 파악합니다. 클러스터가 정상이면 명령은 빈 배열을 반환합니다.

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

Consul 버전이 변경되면 gitlab-ctl reconfigure 끝에 새 버전을 사용하려면 Consul을 재시작해야 한다는 알림이 표시됩니다.

한 번에 한 노드씩 Consul을 재시작합니다.

sudo gitlab-ctl restart consul

Consul 노드는 raft 프로토콜을 사용하여 통신합니다. 현재 리더가 오프라인 상태가 되면 리더 선출이 이루어져야 합니다. 클러스터 전반의 동기화를 지원하려면 리더 노드가 있어야 합니다. 너무 많은 노드가 동시에 오프라인 상태가 되면 클러스터는 정족수를 잃고, 손상된 합의 때문에 리더를 선출하지 못합니다.

업그레이드 후 클러스터가 복구되지 않으면 문제 해결 섹션을 참고합니다. 특히 중단 복구가 도움이 될 수 있습니다.

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을 재시작해야 한다면 정족수를 유지하도록 통제된 방식으로 수행하는 것이 중요합니다. 정족수를 잃으면 클러스터를 복구하기 위해 Consul 중단 복구 절차를 따릅니다.

안전을 위해 클러스터가 온전하게 유지되도록 한 번에 한 노드에서만 Consul을 재시작하는 것이 좋습니다. 더 큰 클러스터에서는 한 번에 여러 노드를 재시작할 수 있습니다. 허용할 수 있는 실패 수는 Consul 합의 문서를 참고합니다. 이 수가 동시에 감당할 수 있는 재시작 수입니다.

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

이를 수정하려면 다음을 수행합니다.

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

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

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

  3. 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.

이를 수정하려면 다음을 수행합니다.

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

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

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

  3. 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 설정 방법

GitLab v19.4
Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

Consul 클러스터는 서버 에이전트와 클라이언트 에이전트 모두로 구성됩니다. GitLab Premium에는 /etc/gitlab/gitlab.rb로 관리할 수 있는 서비스 네트워킹 솔루션인 Consul의 번들 버전이 포함되어 있습니다.

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

GitLab Premium에는 /etc/gitlab/gitlab.rb로 관리할 수 있는 서비스 네트워킹 솔루션인 Consul의 번들 버전이 포함되어 있습니다.

사전 요구 사항#

Consul을 구성하기 전에 다음을 수행합니다.

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

Consul 노드 구성#

각 Consul 서버 노드에서 다음을 수행합니다.

  1. 선호하는 플랫폼을 선택하여 GitLab을 설치하는 지침을 따르되, 값을 요청받더라도 EXTERNAL_URL 값은 제공하지 않습니다.

  2. /etc/gitlab/gitlab.rb를 편집하고, retry_join 섹션에 표시된 값을 교체하여 다음을 추가합니다. 아래 예시에는 노드가 세 개 있으며, 두 개는 IP로, 하나는 FQDN으로 표시되어 있습니다. 어느 표기법이든 사용할 수 있습니다.

    # Disable all components except Consul
roles ['consul_role']

# Consul nodes: can be FQDN or IP, separated by a whitespace
consul['configuration'] = {
  server: true,
  retry_join: %w(10.10.10.1 consul1.gitlab.example.com 10.10.10.2)
}

# Disable auto migrations
gitlab_rails['auto_migrate'] = false

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

  4. 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 노드 보안#

TLS 또는 가십 암호화를 사용하여 Consul 노드 간 통신을 보호하는 방법은 두 가지입니다.

TLS 암호화#

기본적으로 Consul 클러스터에서는 TLS가 활성화되지 않습니다. 기본 구성 옵션과 그 기본값은 다음과 같습니다.

consul['use_tls'] = false
consul['tls_ca_file'] = nil
consul['tls_certificate_file'] = nil
consul['tls_key_file'] = nil
consul['tls_verify_client'] = nil

이 구성 옵션은 클라이언트 노드와 서버 노드 모두에 적용됩니다.

Consul 노드에서 TLS를 활성화하려면 consul['use_tls'] = true로 시작합니다. 노드의 역할(서버 또는 클라이언트)과 TLS 관련 선호 설정에 따라 추가 구성을 제공해야 합니다.

  • 서버 노드에서는 최소한 tls_ca_file, tls_certificate_file, tls_key_file을 지정해야 합니다.
  • 클라이언트 노드에서는 서버의 클라이언트 TLS 인증이 비활성화된 경우 (기본값은 활성화) 최소한 tls_ca_file을 지정해야 하며, 그렇지 않으면 tls_certificate_file, tls_key_file을 사용하여 클라이언트 TLS 인증서와 키를 전달해야 합니다.

TLS가 활성화되면 서버는 기본적으로 mTLS를 사용하고 HTTPS와 HTTP 모두에서 수신합니다(TLS RPC와 비TLS RPC도 함께). 서버는 클라이언트가 TLS 인증을 사용할 것으로 기대합니다. consul['tls_verify_client'] = false를 설정하면 클라이언트 TLS 인증을 비활성화할 수 있습니다.

반면 클라이언트는 서버 노드로 나가는 연결에만 TLS를 사용하고, 들어오는 요청에 대해서는 HTTP(및 비TLS RPC)에서만 수신합니다. consul['https_port']를 음수가 아닌 정수로 설정하면 (8501이 Consul의 기본 HTTPS 포트) 클라이언트 Consul 에이전트가 들어오는 연결에 TLS를 사용하도록 강제할 수 있습니다. 이렇게 하려면 tls_certificate_file과 tls_key_file도 함께 전달해야 합니다. 서버 노드가 클라이언트 TLS 인증을 사용하면 클라이언트 TLS 인증서와 키는 TLS 인증과 들어오는 HTTPS 연결 모두에 사용됩니다.

Consul 클라이언트 노드는 (서버와 달리) 기본적으로 TLS 클라이언트 인증을 사용하지 않으므로, consul['tls_verify_client'] = true를 설정하여 명시적으로 사용하도록 지시해야 합니다.

다음은 TLS 암호화 예시입니다.

최소 TLS 지원#

다음 예시에서 서버는 들어오는 연결에 TLS를 사용합니다(클라이언트 TLS 인증 없음).

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['configuration'] = {
  'server' => true
}

consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/server.crt.pem'
consul['tls_key_file'] = '/path/to/server.key.pem'
consul['tls_verify_client'] = false

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

다음은 예를 들어 Patroni 노드에서 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
patroni['consul']['url'] = 'http://localhost:8500'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

Patroni는 들어오는 연결에 TLS를 사용하지 않는 로컬 Consul 에이전트와 통신합니다. 그래서 patroni['consul']['url']에 HTTP URL을 사용합니다.

기본 TLS 지원#

다음 예시에서 서버는 상호 TLS 인증을 사용합니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['configuration'] = {
  'server' => true
}

consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/server.crt.pem'
consul['tls_key_file'] = '/path/to/server.key.pem'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

다음은 예를 들어 Patroni 노드에서 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/client.crt.pem'
consul['tls_key_file'] = '/path/to/client.key.pem'
patroni['consul']['url'] = 'http://localhost:8500'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

Patroni는 Consul 서버 노드에 TLS 인증을 사용하더라도, 들어오는 연결에는 TLS를 사용하지 않는 로컬 Consul 에이전트와 통신합니다. 그래서 patroni['consul']['url']에 HTTP URL을 사용합니다.

전체 TLS 지원#

다음 예시에서는 클라이언트와 서버 모두 상호 TLS 인증을 사용합니다.

상호 TLS 인증이 동작하려면 Consul 서버, 클라이언트, Patroni 클라이언트 인증서가 동일한 CA에서 발급되어야 합니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['configuration'] = {
  'server' => true
}

consul['use_tls'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/server.crt.pem'
consul['tls_key_file'] = '/path/to/server.key.pem'

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

다음은 예를 들어 Patroni 노드에서 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['enable'] = true
consul['use_tls'] = true
consul['tls_verify_client'] = true
consul['tls_ca_file'] = '/path/to/ca.crt.pem'
consul['tls_certificate_file'] = '/path/to/client.crt.pem'
consul['tls_key_file'] = '/path/to/client.key.pem'
consul['https_port'] = 8501

patroni['consul']['url'] = 'https://localhost:8501'
patroni['consul']['cacert'] = '/path/to/ca.crt.pem'
patroni['consul']['cert'] = '/opt/tls/patroni.crt.pem'
patroni['consul']['key'] = '/opt/tls/patroni.key.pem'
patroni['consul']['verify'] = true

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

가십 암호화#

가십 프로토콜을 암호화하면 Consul 에이전트 간의 통신을 보호할 수 있습니다. 기본적으로 암호화는 활성화되지 않으며, 암호화를 활성화하려면 공유 암호화 키가 필요합니다. 편의를 위해 gitlab-ctl consul keygen 명령으로 키를 생성할 수 있습니다. 키는 길이가 32바이트여야 하고, Base 64로 인코딩되어야 하며, 모든 에이전트에서 공유되어야 합니다.

다음 옵션은 클라이언트 노드와 서버 노드 모두에서 동작합니다.

가십 프로토콜을 활성화하려면 다음을 수행합니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다.

    consul['encryption_key'] = <base-64-key>
consul['encryption_verify_incoming'] = true
consul['encryption_verify_outgoing'] = true

  2. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

기존 데이터센터에서 암호화를 활성화하려면 롤링 업데이트를 위해 이 옵션을 수동으로 설정합니다.

Consul 노드 업그레이드#

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

노드는 다음 조건을 충족해야 합니다.

  • Linux 패키지를 업그레이드하기 전에 정상적인 클러스터의 멤버여야 합니다.
  • 한 번에 한 노드씩 업그레이드해야 합니다.

각 노드에서 다음 명령을 실행하여 클러스터에 존재하는 상태 문제를 파악합니다. 클러스터가 정상이면 명령은 빈 배열을 반환합니다.

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

Consul 버전이 변경되면 gitlab-ctl reconfigure 끝에 새 버전을 사용하려면 Consul을 재시작해야 한다는 알림이 표시됩니다.

한 번에 한 노드씩 Consul을 재시작합니다.

sudo gitlab-ctl restart consul

Consul 노드는 raft 프로토콜을 사용하여 통신합니다. 현재 리더가 오프라인 상태가 되면 리더 선출이 이루어져야 합니다. 클러스터 전반의 동기화를 지원하려면 리더 노드가 있어야 합니다. 너무 많은 노드가 동시에 오프라인 상태가 되면 클러스터는 정족수를 잃고, 손상된 합의 때문에 리더를 선출하지 못합니다.

업그레이드 후 클러스터가 복구되지 않으면 문제 해결 섹션을 참고합니다. 특히 중단 복구가 도움이 될 수 있습니다.

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을 재시작해야 한다면 정족수를 유지하도록 통제된 방식으로 수행하는 것이 중요합니다. 정족수를 잃으면 클러스터를 복구하기 위해 Consul 중단 복구 절차를 따릅니다.

안전을 위해 클러스터가 온전하게 유지되도록 한 번에 한 노드에서만 Consul을 재시작하는 것이 좋습니다. 더 큰 클러스터에서는 한 번에 여러 노드를 재시작할 수 있습니다. 허용할 수 있는 실패 수는 Consul 합의 문서를 참고합니다. 이 수가 동시에 감당할 수 있는 재시작 수입니다.

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

이를 수정하려면 다음을 수행합니다.

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

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

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

  3. 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.

이를 수정하려면 다음을 수행합니다.

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

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

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

  3. 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 가이드를 따릅니다.