Consul 통합

Consul 통합 (Consul integration)

Nomad와 Consul의 통합 기능(자동 클러스터링, 서비스 등록, 동적 구성 렌더링 등)을 알아봐요.

출처: 문서

본문

Consul은 인프라에서 서비스를 발견하고 구성하는 도구예요. Consul의 주요 기능에는 서비스 디스커버리, 건강 검사, KV 저장소, 멀티 데이터 센터 배포에 대한 강력한 지원이 포함돼요. Nomad와 Consul의 통합은 자동 클러스터링, 내장 서비스 등록, 구성 파일과 환경 변수의 동적 렌더링을 가능하게 해요. 아래 섹션에서 이 통합을 더 자세히 설명해요.

구성

Nomad와 함께 Consul을 사용하려면 노드에 Nomad와 함께 Consul을 구성하고 설치하거나 시스템 작업으로 스케줄링해야 해요. Nomad는 Consul을 대신 실행하지 않아요.

Consul 통합을 활성화하려면 Nomad 에이전트 Consul 구성 문서를 참고해요.

Consul을 사용한 자동 클러스터링

실행 중인 Consul 클러스터가 이미 존재하고 각 호스트에 Consul 에이전트가 설치·구성되어 있으면 Nomad 서버와 클라이언트는 서로의 존재를 자동으로 알게 돼요. 자세한 내용은 Consul을 사용한 자동 클러스터링 가이드를 참고해요.

서비스 디스커버리

Nomad는 일반 호스트들의 클러스터 전반에 다양한 유형의 워크로드를 스케줄링해요. 이 때문에 배치를 미리 알 수 없고, 태스크를 클러스터 전반에 배포된 다른 서비스에 연결하려면 서비스 디스커버리를 사용해야 해요. Nomad는 Consul과 통합해 서비스 디스커버리와 모니터링을 제공해요.

작업이 서비스 디스커버리에 등록하도록 구성하려면 service 작업 명세 문서를 참고해요.

서비스 메시

Consul 서비스 메시는 상호 전송 계층 보안(mTLS)을 사용해 서비스 간 연결 인가와 암호화를 제공해요. Nomad는 태스크를 Consul의 서비스 메시에 안전하게 연결하는 데 필요한 구성 요소를 자동으로 프로비저닝할 수 있어요.

자세한 내용은 Consul Service Mesh 통합 페이지를 참고해요.

동적 구성

Nomad의 작업 명세에는 template 블록이 포함되며, 이는 Consul Template이라는 Consul 에코시스템 도구를 사용해요. 이 메커니즘은 환경 변수, Consul 데이터, Vault 시크릿 또는 일반 구성에서 채워지는 구성 파일을 Nomad 태스크 내로 보내는 편리한 방법을 만들어요.

Nomad의 template 블록과 Consul Template 활용에 대한 자세한 내용은 template 작업 명세 문서를 참고해요.

DNS

bridge 또는 CNI 네트워킹 모드를 사용하는 Nomad 워크로드에 Consul DNS를 제공하려면, Consul DNS 리스너가 워크로드 네트워크 네임스페이스에 노출되도록 구성하거나 systemd-resolved, dnsmasq 또는 유사한 DNS 스텁 리졸버가 DNS를 포워딩하도록 구성해야 해요. 자세한 내용은 Consul 서비스 디스커버리를 위한 DNS 포워딩을 참고해요.

Consul bind_addr를 비공개 IP 주소에 바인딩하면 Consul 에이전트를 공용 IP에 노출하는 것을 피할 수 있어요(기본값은 client_addr 사용). DNS 포워딩을 사용하지 않는다면 Consul이 DNS용 포트 53에 바인딩하도록 해야 해요.

또한 nameserver를 해당 주소로 설정해야 해요. 이 주소는 consul.dns.addr 노드 속성 또는 systemd-resolved의 DNSStubListener 구성 값으로 노출돼요.

더 간단한 해결책은 Consul 서비스 메시 transparent proxy 모드를 사용해 태스크가 Consul DNS를 사용하도록 자동으로 구성하는 것이에요.

Consul 접근 제어 목록(ACL)

Consul ACL 시스템은 클러스터를 무단 접근으로부터 보호해요. 활성화되면 Consul과 Nomad 모두 통합이 작동하도록 올바르게 구성되어야 해요.

자세한 내용은 Consul ACL 통합 페이지를 참고해요.

Consul 네임스페이스 (Enterprise)

Nomad는 service 블록에 지정된 서비스 등록과 template 블록의 Consul KV 읽기에 대한 Consul Namespaces 통합을 제공해요.

기본적으로 Nomad는 서비스 등록이나 KV 저장소 읽기에 Consul 네임스페이스를 지정하지 않으며, 그러면 Consul이 이를 암시적으로 "default" 네임스페이스로 해석해요. 이 기본 네임스페이스 동작은 Nomad 에이전트 Consul 구성 블록에서 namespace 필드를 설정해 수정할 수 있어요.

Consul 네임스페이스에 대한 더 많은 제어를 위해 Nomad Enterprise는 Nomad 작업 명세의 그룹 또는 태스크 수준에서 Consul namespace를 구성하는 것과 job run의 -consul-namespace 명령줄 인자를 지원해요.

그룹 내의 일련의 그룹 또는 태스크 서비스 등록, 그리고 template KV 저장소 접근에 사용되는 Consul 네임스페이스는 다음과 같은 높은 우선순위에서 낮은 우선순위 순서로 결정돼요.

• 그룹 및 태스크 구성: 태스크 또는 그룹 수준에서 작업에 정의된 Consul namespace field
• job run 명령 옵션: 작업 제출 시 -consul-namespace 명령줄 옵션에 정의된 Consul 네임스페이스
• job run 명령 환경 변수: 작업 제출 시 CONSUL_NAMESPACE 환경 변수로 정의된 Consul 네임스페이스
• 에이전트 구성: namespace Nomad 에이전트 Consul 구성 파라미터에 정의된 Consul 네임스페이스
• Consul 기본값: Consul 네임스페이스 옵션이 구성되지 않으면 Consul이 자동으로 "default" 네임스페이스를 사용해요.

여러 Consul 클러스터 (Enterprise)

Nomad Enterprise는 여러 Consul 클러스터에 대한 접근을 지원해요. name 값이 다른 여러 consul 블록으로 구성할 수 있어요. name이 제공되지 않으면 클러스터 구성은 default라고 불러요. Nomad 자동 클러스터링은 서비스 디스커버리에 default 클러스터를 사용해요.

Consul에 접근해야 하는 작업은 consul.cluster 파라미터로 사용할 Consul 클러스터를 지정할 수 있어요.

가정

• 각 Nomad 클라이언트는 같은 호스트에서 실행되는 로컬 Consul 에이전트를 가져야 하며, Nomad가 도달할 수 있어야 해요. Nomad 클라이언트는 Consul 에이전트를 공유하거나 Consul 서버에 직접 통신해서는 안 돼요. Nomad는 Consul Data Plane과 호환되지 않아요.
• Nomad의 서비스 디스커버리 기능은 운영자가 Nomad 클라이언트가 Consul 에이전트에 도달할 수 있는지 확인하는 것에 의존해요.
• Nomad 내부에서 실행되는 태스크도 Consul API 중 어느 것이든 사용하려면 Consul 에이전트에 도달해야 해요. 예: 브리지 모드의 docker 컨테이너 내부에서 실행되는 태스크는 호스트의 루프백 인터페이스에서 실행되는 Consul 에이전트와 통신할 수 없어요. 브리지 모드의 컨테이너는 자체 네트워크 인터페이스를 가지며 호스트의 전역 네트워크 네임스페이스의 인터페이스를 보지 못하기 때문이에요. 이를 해결하는 몇 가지 방법이 있어요. 한 가지 방법은 호스트 네트워킹 모드에서 컨테이너를 실행하거나, Consul 에이전트가 컨테이너의 네트워크 네임스페이스의 인터페이스에서 수신하도록 하는 것이에요.
• 클라이언트 노드에서 Envoy 프록시 사이드카를 실행하려면 consul 바이너리가 Nomad의 $PATH에 있어야 해요.
• 네트워크 네임스페이스를 사용하는 Consul 서비스 메시는 Linux에서만 지원돼요.

호환성

현재 지원되는 모든 Nomad 버전은 최신 Consul 버전과 호환돼요.

• Nomad는 Consul Data Plane과 호환되지 않아요.

더 알아보기 (Learn more)

• Nomad 에이전트 Consul 구성
• Consul Service Mesh 통합