가상 머신에 API 게이트웨이 리스너 배포
가상 머신에 API 게이트웨이 리스너 배포 (Deploy API Gateway Listeners to Virtual Machines)
이 주제는 가상 머신(VM) 환경에서 운영되는 네트워크에 Consul API 게이트웨이 리스너를 배포하는 방법을 설명해요.
출처: 문서
본문
이 주제는 가상 머신(VM) 환경에서 운영되는 네트워크에 Consul API 게이트웨이 리스너를 배포하는 방법을 설명해요. Kubernetes 환경에서 API 게이트웨이 리스너를 구현하려면 Kubernetes에 API 게이트웨이 리스너 배포를 참고해요.
개요 (Overview)
API 게이트웨이는 Consul 서비스 메시의 서비스에 대한 요청의 인그레스 포인트 역할을 하는 하나 이상의 리스너를 가져요. API 게이트웨이 구성 항목을 만들고 인그레스를 위해 엔드포인트에 포트를 노출하는 리스너를 정의해요.
다음 단계는 VM 환경에 Consul API 게이트웨이를 배포하는 일반적인 워크플로를 설명해요:
- API 게이트웨이 구성 항목을 생성해요. 구성 항목은 리스너 구성과 TLS 인증서 참조를 포함해요.
- 리스너를 생성하기 위해 API 게이트웨이 구성 항목을 배포해요.
암호화 (Encryption)
외부 클라이언트와 API 게이트웨이가 트래픽을 라우팅하는 서비스 사이의 트래픽을 암호화하려면 리스너 TLS를 구성해요.
리스너 TLS는 두 가지 주요 방식으로 구성할 수 있어요:
Listeners[].TLS.Certificates로 인증서 항목 참조(예:inline-certificate)- 다음으로 SDS를 통한 동적 인증서 전달 구성:
- 게이트웨이 수준 기본값:
api-gateway.TLS.SDS - 리스너 수준 재정의/기본값:
api-gateway.Listeners[].TLS.SDS
- 게이트웨이 수준 기본값:
경로 서비스 재정의가 구성되면(http-route 또는 tcp-route 서비스 TLS.SDS) 인증서 선택 우선 순위는 다음과 같아요:
- 경로 서비스
TLS.SDS - 리스너
TLS.SDS - 게이트웨이 수준
TLS.SDS
추가 정보는 가상 머신에서 API 게이트웨이 트래픽 암호화를 참고해요.
경로 (Routes)
게이트웨이를 배포한 후 게이트웨이에 정의된 리스너에 HTTP 경로와 TCP 경로를 연결해 요청이 네트워크의 서비스로 라우팅되는 방식을 제어해요. 추가 정보는 VM에서 API 게이트웨이 경로 정의를 참고해요.
요구 사항 (Requirements)
VM에서 API 게이트웨이를 사용하려면 다음 요구 사항을 충족해야 해요:
- Consul 1.15 이상
- 서비스 메시가 활성화된 Consul 클러스터.
connect참고 - API 게이트웨이를 배포하는 머신과 Consul 클러스터 에이전트 또는 서버 간 네트워크 연결
ACL 요구 사항 (ACL requirements)
ACL이 활성화되면 Consul을 구성하고 API 게이트웨이를 배포하려면 다음 권한이 있는 토큰을 제시해야 해요:
Consul API 게이트웨이 구성과 상호작용할 수 있게 하는 정책 구성에 대한 자세한 내용은 Mesh 규칙을 참고해요.
게이트웨이 및 리스너 정의 (Define the gateway and listeners)
메시에서 리스너와 TLS 인증서를 정의하는 API 게이트웨이 구성 항목을 생성해요.
-
다음 필드를 지정해요:
Listeners 블록에서 필드를 정의하는 방법에 대한 자세한 내용은 API 게이트웨이 구성 항목 참조를 참고해요.
-
네임스페이스나 관리 파티션 같은 사용 사례에 필요한 추가 필드를 구성해요. 추가 정보는 API 게이트웨이 구성 항목 참조를 참고해요.
-
구성을 저장해요.
다음 예시에서 API 게이트웨이는 포트 8443에 HTTP 리스너를 지정해요. 또한 유효한 인증서와 개인 키 쌍을 포함하는 my-certificate라는 inline-certificate 구성 항목이 필요해요:
Kind = "api-gateway"
Name = "my-gateway"
// Each listener configures a port which can be used to access the Consul cluster
Listeners = [
{
Port = 8443
Name = "my-http-listener"
Protocol = "http"
TLS = {
Certificates = [
{
Kind = "inline-certificate"
Name = "my-certificate"
}
]
}
}
]
다음 예시는 리스너 수준 SDS 재정의가 있는 게이트웨이 수준 SDS를 보여줘요:
Kind = "api-gateway"
Name = "my-gateway"
TLS = {
SDS = {
ClusterName = "sds-cluster"
CertResource = "wildcard.example.internal"
}
}
Listeners = [
{
Port = 8443
Name = "my-http-listener"
Protocol = "http"
TLS = {
SDS = {
ClusterName = "sds-cluster"
CertResource = "api.example.com"
}
}
}
]
모든 구성 필드에 대한 정보는 API 게이트웨이 구성 참조를 참고해요.
게이트웨이와 경로는 일련의 상태 조건을 통해 현재 상태에 대한 피드백을 제공하는 최종 일관성(eventually-consistent) 객체예요. 따라서 경로가 게이트웨이에 성공적으로 바인딩되었는지 확인하려면 경로 상태를 수동으로 확인해야 해요.
API 게이트웨이 및 리스너 배포 (Deploy the API gateway and listeners)
consul config write 명령을 사용해 API 게이트웨이 구성 항목을 구현해요. 다음 명령은 기본 게이트웨이 객체에 대한 구성 항목을 적용해요:
$ consul config write gateways.hcl
다음 명령을 실행해 API 게이트웨이 인스턴스를 배포해요:
$ consul connect envoy -gateway api -register -service my-api-gateway
게이트웨이와 경로는 상태 조건을 노출하는 최종 일관성 객체예요. 배포 후 리스너와 경로가 수락되고 바인딩되었는지 확인해요.
검증 참고 사항 (Validation notes)
- 경로 또는 리스너
TLS.SDS가 구성되면CertResource가 필요해요. - 리스너
TLS.SDS는 해당 리스너에 대해 게이트웨이TLS.SDS를 재정의해요. - 경로 서비스 재정의(
Services[].TLS.SDS)는 리스너/게이트웨이 기본값을 재정의할 수 있어요. - 리스너에서
TLS.Certificates와TLS.SDS는 상호 배타적이에요.