18장. 인스턴스 및 컨테이너 그룹

노드를 정의할 때는 다음 기준을 사용합니다.

instance_group_* 로 그룹 이름을 지정하여 인벤토리 파일에서 사용자 지정 그룹을 정의할 수 있습니다. 여기서 * 는 API에서 그룹 이름이 됩니다. 설치가 완료된 후 API에 사용자 지정 인스턴스 그룹을 생성할 수도 있습니다.

현재 동작에서는 instance_group_* 의 멤버가 Automation controller 또는 execution_nodes 그룹의 일부가 될 것으로 예상합니다.

[automationcontroller]
126-addr.tatu.home ansible_host=192.168.111.126  node_type=control

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]

[instance_group_test]
110-addr.tatu.home ansible_host=192.168.111.110 receptor_listener_port=8928

설치 프로그램을 실행하면 다음 오류가 표시됩니다.

TASK [ansible.automation_platform_installer.check_config_static : Validate mesh topology] ***
fatal: [126-addr.tatu.home -> localhost]: FAILED! => {"msg": "The host '110-addr.tatu.home' is not present in either [automationcontroller] or [execution_nodes]"}

이 문제를 해결하려면 box 110-addr.tatu.home 을 execution_node 그룹으로 이동합니다.

[automationcontroller]
126-addr.tatu.home ansible_host=192.168.111.126  node_type=control

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]
110-addr.tatu.home ansible_host=192.168.111.110 receptor_listener_port=8928

[instance_group_test]
110-addr.tatu.home

결과는 다음과 같습니다.

TASK [ansible.automation_platform_installer.check_config_static : Validate mesh topology] ***
ok: [126-addr.tatu.home -> localhost] => {"changed": false, "mesh": {"110-addr.tatu.home": {"node_type": "execution", "peers": [], "receptor_control_filename": "receptor.sock", "receptor_control_service_name": "control", "receptor_listener": true, "receptor_listener_port": 8928, "receptor_listener_protocol": "tcp", "receptor_log_level": "info"}, "126-addr.tatu.home": {"node_type": "control", "peers": ["110-addr.tatu.home"], "receptor_control_filename": "receptor.sock", "receptor_control_service_name": "control", "receptor_listener": false, "receptor_listener_port": 27199, "receptor_listener_protocol": "tcp", "receptor_log_level": "info"}}}

자동화 컨트롤러 4.0 또는 이전 버전에서 업그레이드한 후 레거시 instance_group_ 멤버에 awx 코드가 설치되어 있을 가능성이 큽니다. 그러면 해당 노드가 Automation controller 그룹에 배치됩니다.

시스템 관리자로 /api/v2/instance_groups 에 POST를 수행하여 인스턴스 그룹을 생성할 수 있습니다.

생성되면 다음을 사용하여 인스턴스를 인스턴스 그룹과 연결할 수 있습니다.

HTTP POST /api/v2/instance_groups/x/instances/ {'id': y}`

인스턴스 그룹에 추가된 인스턴스는 그룹의 작업 큐에서 수신 대기하도록 자동으로 재구성됩니다. 자세한 내용은 다음 섹션을 참조하십시오. 인스턴스 그룹 정책.

정책을 정의하여 온라인 상태가 되면 인스턴스 그룹에 자동으로 참여하도록 자동화 컨트롤러 인스턴스를 구성할 수 있습니다. 이러한 정책은 온라인 상태의 모든 새 인스턴스를 대상으로 평가됩니다.

인스턴스 그룹 정책은 인스턴스 그룹의 다음 세 개의 선택적 필드에 의해 제어됩니다.

자동화 컨트롤러 UI(사용자 인터페이스)의 인스턴스 그룹 목록 보기는 인스턴스 그룹 정책에 따라 각 인스턴스 그룹의 용량 수준을 요약합니다.

다음 정책 고려 사항을 고려하십시오.

특정 인스턴스 그룹에만 할당되어야 하는 특수 인스턴스가 있지만 "percentage" 또는 "최소" 정책으로 다른 그룹에 자동으로 참여하지 않도록 하려면 다음을 수행합니다.

이렇게 하면 백분율 및 최소 정책에 따라 인스턴스가 다른 그룹에 자동으로 추가되지 않습니다. 이는 수동으로 할당한 그룹에만 속합니다.

HTTP PATCH /api/v2/instance_groups/N/
{
"policy_instance_list": ["special-instance"]
}
HTTP PATCH /api/v2/instances/X/
{
"managed_by_policy": False
}

인스턴스 그룹과 연결된 작업을 실행하는 경우 다음 동작을 기록해 둡니다.

인스턴스 그룹을 작업 템플릿, 인벤토리 또는 조직과 연결하는 경우 해당 작업 템플릿에서 실행되는 작업은 기본 동작을 수행할 수 없습니다. 즉, 이 세 개의 리소스와 연결된 인스턴스 그룹 내의 모든 인스턴스가 용량이 부족하면 용량을 사용할 수 있을 때까지 작업이 보류 중 상태로 유지됩니다.

작업을 제출할 인스턴스 그룹을 결정하는 기본 설정 순서는 다음과 같습니다.

인스턴스 그룹을 작업 템플릿과 연결하고 모든 작업이 용량에 있는 경우 인벤토리에 지정된 인스턴스 그룹 및 조직에 제출됩니다. 해당 그룹에서는 리소스를 사용할 수 있으므로 작업이 우선 순위순으로 실행되어야 합니다.

플레이북에 정의된 사용자 지정 인스턴스 그룹과 같은 글로벌 기본 그룹을 리소스와 연결할 수 있습니다. 이 인스턴스를 사용하여 작업 템플릿 또는 인벤토리에서 기본 인스턴스 그룹을 지정할 수 있지만, 용량이 부족한 경우에도 작업을 모든 인스턴스에 제출할 수 있습니다.

다음 두 가지 예제를 제공합니다.

이러한 방식으로 리소스를 배치하면 유연성을 제공합니다. 하나의 인스턴스만으로 인스턴스 그룹을 생성하여 자동화 컨트롤러 클러스터에서 매우 구체적인 호스트로 작업을 보낼 수도 있습니다.

인스턴스 그룹으로 전송되는 작업의 동시성 또는 사용할 최대 포크 수를 제한해야 하는 외부 비즈니스 논리가 있습니다.

기존 인스턴스 및 인스턴스 그룹의 경우 두 조직이 동일한 기본 인스턴스에서 작업을 실행할 수 있지만 각 조직의 총 동시 작업 수를 제한할 수 있습니다. 이를 위해 각 조직의 인스턴스 그룹을 생성하고 max_concurrent_jobs 의 값을 할당할 수 있습니다.

자동화 컨트롤러 그룹의 경우 자동화 컨트롤러는 일반적으로 OpenShift 클러스터의 리소스 제한을 인식하지 못합니다. 네임스페이스의 Pod 수에 제한을 설정하거나 자동 스케일링이 없는 경우 한 번에 특정 수의 Pod를 예약하는 데 사용할 수 있는 리소스만 설정할 수 있습니다. 이 경우 max_concurrent_jobs 의 값을 조정할 수 있습니다.

사용 가능한 또 다른 매개변수는 max_forks 입니다. 이는 인스턴스 그룹 또는 컨테이너 그룹에서 사용되는 용량을 제한하기 위한 추가 유연성을 제공합니다. 다양한 인벤토리 크기 및 "포크" 값이 실행되는 경우 이 작업을 사용할 수 있습니다. 조직에서 동시에 최대 10개의 작업을 실행하도록 제한할 수 있지만 한 번에 최대 50개의 포크를 사용할 수 없습니다.

max_concurrent_jobs: 10
max_forks: 50

포크 5개를 사용하는 10개의 작업이 각각 실행되면 11번째 작업은 해당 그룹 중 하나가 완료될 때까지 기다립니다(또는 용량이 있는 다른 그룹에서 예약됨).

각각 20개의 포크로 2개의 작업이 실행 중인 경우 task_impact 가 11개 이상인 세 번째 작업은 해당 그룹 중 하나가 완료될 때까지 기다립니다(또는 용량이 있는 다른 그룹에서 예약됨).

컨테이너 그룹의 경우 작업의 "포크" 값에 관계없이 동일한 리소스 요청이 있는 동일한 pod_spec 을 사용하여 모든 작업이 제출되는 경우 max_forks 값을 사용하는 것이 유용합니다. 기본 pod_spec 은 제한이 아닌 요청을 설정하므로 Pod는 제한되거나 다시 실행되지 않고 요청된 값 이상으로 "브스트링"할 수 있습니다. max_forks 값을 설정하면 포크 값이 너무 많은 작업이 동시에 예약되고 요청된 값보다 많은 리소스를 사용하여 여러 Pod로 OpenShift 노드가 오버서브스크립션되는 시나리오를 방지할 수 있습니다.

인스턴스 그룹에서 동시 작업 및 포크의 최대 값을 설정하려면 인스턴스 그룹 생성을 참조하십시오.

현재 클러스터는 의도적으로 또는 오류로 인해 오프라인 상태로 전환된 인스턴스를 구분하지 않으므로 설정 플레이북을 다시 실행하면 인스턴스가 프로비저닝 해제되지 않습니다. 대신 자동화 컨트롤러 인스턴스에서 모든 서비스를 종료한 다음 다른 인스턴스에서 프로비저닝 해제 툴을 실행합니다.

자동화 컨트롤러에서 인스턴스 그룹을 프로비저닝 해제해도 인스턴스 그룹을 자동으로 프로비저닝 해제하거나 제거하지는 종종 다시 프로비저닝되지 않는 경우가 많습니다. API 끝점 및 통계 모니터링에 계속 표시될 수 있습니다. 다음 명령을 사용하여 이러한 그룹을 제거할 수 있습니다.

awx-manage unregister_queue --queuename=<name>

인벤토리 파일의 인스턴스 그룹에서 인스턴스 멤버십을 제거하고 설정 플레이북을 다시 실행하면 인스턴스가 그룹에 다시 추가되지 않습니다. 인스턴스가 그룹에 다시 추가되지 않도록 하려면 API를 통해 해당 인스턴스를 제거하고 인벤토리 파일에서도 제거합니다. 인벤토리 파일에서 인스턴스 그룹 정의를 중지할 수도 있습니다. 자동화 컨트롤러 UI를 통해 인스턴스 그룹 토폴로지를 관리할 수 있습니다. UI에서 인스턴스 그룹을 관리하는 방법에 대한 자세한 내용은 인스턴스 그룹 관리를 참조하십시오.