Red Hat Summit5.3. 실행 플레인
기본 또는 컨트롤러 실행 플레인에서만 test 및 cleanup 작업을 실행할 수 있습니다. 다른 모든 자동화는 실행 플레인에서 실행되도록 구성해야 합니다.
AWS 서브스크립션의 Ansible Automation Platform Service의 일부로 실행 플레인을 실행하기 위한 RHEL(Red Hat Enterprise Linux) 인타이틀먼트가 10개 제공됩니다. 추가 RHEL 또는 OpenShift 라이센스는 별도로 구매할 수 있습니다.
5.3.1. 셰이프
실행 플레인의 크기와 모양은 자동화 유형과 메시에 연결된 위치에 따라 달라집니다. 자동화 메시 구현에 다음 지침을 사용합니다.
Ansible Automation Platform 최소 요구 사항:
홉 노드: AWS의 Red Hat Ansible Automation Platform Service에는 고객이 실행 노드와 상호 작용하는 데 사용할 수 있는 두 개의 홉 노드가 포함되어 있습니다. 일반적으로 최소한의 리소스가 필요합니다. 홉 노드의 모양은 연결된 실행 노드 수에 따라 달라집니다. vCPU 2개와 2GB RAM이 있는 VM(가상 머신)은 2-4 실행 노드의 트래픽을 라우팅할 수 있습니다.
- 자동화 메시 구성에 대한 도움말은 관리 클라우드 또는 Operator 환경의 자동화 메시를 참조하십시오.
- 더 적은 수의 위치(예: 특정 지역 또는 클라우드)에서 자동화하려면 수직으로 확장할 수 있는 VM 수가 적은 메시를 생성합니다. 대부분의 클라우드 및 하이퍼바이저는 다운타임을 최소화하여 변경할 수 있습니다.
- CPU 또는 RAM 집약적인 자동화의 경우 더 큰 머신 셰이프를 사용합니다.
- 여러 위치에 걸쳐 있는 자동화의 경우 해당 위치에 연결하는 노드로 메시를 생성합니다.
- ARM 및 예약된 인스턴스와 같은 다른 CPU 아키텍처를 사용하여 실행 플레인 비용을 줄이는 것이 좋습니다.
- 자동화 메시에서 중복성을 구성하려면 동일한 리전 내의 다른 가용성 영역에서 동일한 두 개의 메시 노드를 설정하여 각 시스템을 두 개의 호스트 홉 노드에 연결합니다.
- 실행 플레인을 자동 확장해야 하는 경우 OpenShift를 사용합니다.
5.3.2. 네트워킹
5.3.2.1. 자동화 메시
AWS의 Ansible Automation Platform Service는 기본 "mesh-ingress" 홉 노드를 제공합니다. 이러한 호스팅 홉 노드를 사용하면 실행 노드가 고객의 프라이빗 네트워크에서 송신을 통해 자동화 작업을 폴링할 수 있으므로 인바운드 방화벽 포트를 열 필요가 없습니다. 호스트 홉 노드는 인바운드 트래픽에 포트 443을 사용합니다.
다음은 이 모델을 통해 AWS의 Ansible Automation Platform Service에 연결된 송신 전용 인터넷 액세스가 있는 프라이빗 주소 공간의 실행 노드의 예입니다.
컨트롤 플레인에서 실행 플레인으로 아웃바운드 연결을 사용하여 자동화 메시를 구성하여 자동화 메시에서 사용하는 포트를 지정할 수도 있습니다.
자세한 내용은 관리 클라우드 또는 운영자 환경 설명서에 자동화 메시를 사용할 수 있습니다.
5.3.2.2. 연결
실행 플레인은 다음 조건에서 컨트롤 플레인과 통신할 수 있습니다.
- 폴링(mesh-ingress): 실행 노드는 상태 저장 송신 트래픽을 포트 443을 통해 Ansible Automation Platform 배포 도메인으로 라우팅해야 합니다.
- 푸시: Ansible Automation Platform이 실행 노드로 정보를 푸시할 수 있도록 구성 가능한 방화벽 포트가 고객의 원격 네트워크에서 열려 있어야 합니다.
방화벽, 프록시 서버 및 유사한 서비스 뒤에 자동화 메시 노드를 구성할 수 있습니다. 이러한 서비스는 자동화 메시의 기능에 영향을 줄 수 있는 헤더, 페이로드 또는 기타 정보를 변경하지 않고 Ansible Automation Platform에서 발생하는 트래픽을 라우팅하거나 프록시 트래픽을 라우팅합니다.
5.3.3. 모니터링
실행 플레인에서 선택한 모니터링 및 강화 툴을 구성할 수 있습니다. 작업, 기능 및 유지 관리에 대한 책임이 있으므로 실행 플레인의 작업을 방해하지 않습니다.
실행 플레인의 추가 워크로드에는 도구가 배포된 가상 머신 또는 OpenShift 클러스터의 추가 리소스가 필요합니다. 이러한 추가 요구 사항을 충족하기 위해 리소스 크기를 적절하게 조정하십시오.
5.3.4. DNS
실행 노드는 DNS 쿼리에 호스트 시스템의 DNS 구성을 사용합니다. 자동화 실행 중에 적절한 조회를 보장하기 위해 표준 RHEL 네트워크 사례를 사용하여 DNS를 구성합니다.
5.3.5. 중복되는 CIDR 블록이 있는 네트워킹
자동화 메시는 컨트롤 플레인을 동일한 CIDR(Classless Inter-Domain Routing) 블록(즉, 다른 클라우드 또는 데이터 센터에서 반복하는 동일한 클래스 A 주소 공간)을 공유하는 여러 네트워크에 연결합니다. 실행 노드는 배포 네트워크를 로컬 네트워크로 간주합니다. 각 네트워크에서 자동화를 대상으로 하려면 하나 이상의 실행 노드 인스턴스가 인스턴스 그룹과 페어링되어야 합니다.
5.3.6. 업데이트 및 유지 관리
자동화 메시 실행 노드는 컨트롤 플레인이 업데이트될 때 실행 플레인을 패치할 필요성을 최소화하도록 설계되었습니다. 그러나 향후 기술 업데이트에서는 각 실행 플레인 노드의 구성 요소를 업데이트하기 위해 고객이 개입해야 합니다. 패치가 필요한 경우 고객은 자동화 메시 노드 업데이트 프로세스를 따라야 합니다. 수신기 업데이트에 대한 도움말은 관리 클라우드 또는 Operator 환경의 자동화 메시 의 수신기 업데이트 섹션을 참조하십시오.
