8. 컨테이너 및 인스턴스 그룹¶

8.1.1. automationcontroller 그룹 정책¶

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

• automationcontroller 그룹의 노드는 node_type hostvar을 ``hybrid``(기본값) 또는 ``control``로 정의할 수 있습니다.

• execution_nodes 그룹의 노드는 node_type hostvar을 ``execution``(기본값) 또는 ``hop``으로 정의할 수 있습니다.

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

현재 동작에서는 instance_group_*``의 멤버가 ``automationcontroller 또는 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]"}

이 오류를 해결하려면 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 코드가 설치되어 해당 노드가 automationcontroller 그룹에 배치될 가능성이 큽니다.

8.1.2. API에서 인스턴스 그룹 구성¶

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

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

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

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

8.1.3. 인스턴스 그룹 정책¶

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

인스턴스 그룹 정책은 ``Instance Group``의 세 가지 선택 필드로 제어됩니다.

• policy_instance_percentage: 0에서 100 사이의 숫자입니다. 이 백분율의 활성 컨트롤러 인스턴스가 이 인스턴스 그룹에 추가됩니다. 새 인스턴스가 온라인 상태가 될 때 총 인스턴스 수와 비교해 이 그룹의 인스턴스 수가 지정된 백분율보다 작으면 백분율 조건이 충족될 때까지 새 인스턴스가 추가됩니다.

• policy_instance_minimum: 이 정책은 인스턴스 그룹의 인스턴스 수를 이 값 이상으로 유지하려고 합니다. 사용 가능한 인스턴스 수가 이 최소값보다 작으면 모든 인스턴스가 이 인스턴스 그룹에 배치됩니다.

• policy_instance_list: 이 인스턴스 그룹에 항상 포함할 인스턴스 이름의 고정 목록입니다.

automation controller 사용자 인터페이스의 인스턴스 그룹 목록 뷰는 인스턴스 그룹 정책에 따른 각 인스턴스 그룹의 용량 수준을 요약해서 보여 줍니다.

8.1.4. 주요 정책 고려 사항¶

• ``policy_instance_percentage``와 ``policy_instance_minimum``은 둘 다 최소 할당 값을 설정합니다. 그룹에 더 많은 인스턴스가 할당되게 하는 규칙이 적용됩니다. 예를 들어 ``policy_instance_percentage``가 50%이고 ``policy_instance_minimum``이 2인 경우 6개 인스턴스를 시작하면 3개 인스턴스가 인스턴스 그룹에 할당됩니다. 클러스터의 총 인스턴스 수를 2개로 줄이면 ``policy_instance_minimum``을 충족하기 위해 둘 다 인스턴스 그룹에 할당됩니다. 이렇게 하면 사용 가능한 리소스 양에 하한을 설정할 수 있습니다.

• 정책을 적용하더라도 인스턴스가 여러 인스턴스 그룹과 연결되는 것을 적극적으로 차단하지는 않지만 백분율 합계를 100으로 만들면 효과적으로 차단할 수 있습니다. 4개의 인스턴스 그룹이 있는 경우 각 그룹에 백분율 값 25를 할당하면 인스턴스가 겹치지 않고 그룹 간에 배포됩니다.

8.1.5. 인스턴스를 특정 그룹에 수동으로 고정¶

특정 인스턴스 그룹에 배타적으로 할당되어야 하는 특수 인스턴스가 있지만 《백분율》 또는 《최소값》 정책을 통해 다른 그룹에 자동으로 참여하지 않도록 하려면 다음을 수행합니다.

1. 하나 이상 인스턴스 그룹의 ``policy_instance_list``에 인스턴스를 추가합니다.

2. 인스턴스의 managed_by_policy 속성을 ``False``로 업데이트합니다.

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

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

HTTP PATCH /api/v2/instances/X/
{
"managed_by_policy": False
}

8.1.6. 작업 런타임 동작¶

인스턴스 그룹과 연결된 작업을 실행할 때 주목할 만한 몇 가지 동작은 다음과 같습니다.

• 클러스터가 개별 인스턴스 그룹으로 나누어져 있는 경우 클러스터 전체와 비슷하게 작동합니다. 두 인스턴스가 하나의 그룹에 할당된 경우 둘 중 하나는 동일한 그룹의 다른 인스턴스만큼 작업을 받을 가능성이 큽니다.

• 컨트롤러 인스턴스가 온라인 상태가 되면 시스템의 작업 용량이 효과적으로 확장됩니다. 이러한 인스턴스가 인스턴스 그룹에도 배치되는 경우 해당 그룹의 용량도 확장됩니다. 인스턴스가 작업을 수행하고 여러 그룹의 멤버인 경우 인스턴스가 속한 모든 그룹에서 용량이 줄어듭니다. 인스턴스를 프로비저닝 해제하면 인스턴스가 어디에서 할당되었든 클러스터 용량이 제거됩니다. 자세한 내용은 인스턴스 프로비저닝 해제 섹션을 참조하십시오.

8.1.7. 작업이 실행되는 위치 제어¶

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

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

1. 작업 템플릿

2. 인벤토리

3. 조직(프로젝트를 통해)

인스턴스 그룹이 작업 템플릿과 연결되어 있고 모든 그룹이 한도에 도달하면 인벤토리, 조직에서 차례로 지정된 인스턴스 그룹에 작업이 제출됩니다. 해당 그룹에서는 리소스를 사용할 수 있으므로 작업이 기본 설정 순서대로 실행됩니다.

글로벌 default 그룹은 플레이북에 정의된 사용자 지정 인스턴스 그룹과 마찬가지로 계속 리소스와 연결될 수 있습니다. 이 그룹을 사용하여 작업 템플릿 또는 인벤토리의 기본 설정 인스턴스 그룹을 지정할 수 있지만, 이 경우에도 용량이 부족하면 작업이 아무 인스턴스에나 제출될 수 있습니다.

예를 들어 group_a``를 작업 템플릿과 연결하고 ``default 그룹도 해당 인벤토리와 연결하면 group_a``의 용량이 부족할 경우 ``default 그룹이 대체로 사용될 수 있습니다.

또한 인스턴스 그룹을 하나의 리소스와 연결하지 않고 다른 리소스를 대체로 지정할 수 있습니다. 예를 들어 인스턴스 그룹을 작업 템플릿과 연결하지 않고 인벤토리 및/또는 조직의 인스턴스 그룹으로 대체되도록 합니다.

이런 방식의 다른 두 가지 주요 사용 사례는 다음과 같습니다.

1. 인스턴스 그룹에 작업 템플릿을 할당하지 않고 인스턴스 그룹을 인벤토리와 연결하면 사용자는 특정 인벤토리에 실행되는 플레이북이 해당 인벤토리와 연결된 그룹에서만 실행되도록 할 수 있습니다. 이 기능은 관리형 노드에 연결된 직접 링크가 해당 인스턴스에만 있는 경우 매우 유용할 수 있습니다.

2. 관리자는 조직에 인스턴스 그룹을 할당할 수 있습니다. 이렇게 하면 관리자가 효과적으로 전체 인프라를 분할하여 작업 실행 용량이 각 조직에 확보되도록 할 수 있습니다. 이때 다른 조직의 작업 실행 능력은 저해되지 않습니다.

마찬가지로, 관리자는 다음 시나리오에서처럼 각 조직에 여러 그룹을 원하는 대로 할당할 수 있습니다.

• 인스턴스 그룹 3개(A, B, C)와 조직 2개(Org1, Org2)가 있습니다.

• 관리자가 Org1에 그룹 A, Org2에 그룹 B를 할당한 다음, 필요할 수 있는 추가 용량을 위한 오버플로로 Org1과 Org2 둘 다에 그룹 C를 할당합니다.

• 그러면 조직 관리자가 원하는 그룹에 인벤토리 또는 작업 템플릿을 자유롭게 할당하거나 조직에서 기본 순서를 가져오도록 할 수 있습니다.

이런 방식으로 리소스를 배치하면 상당히 유연하게 작업할 수 있습니다. 또한 하나의 인스턴스만으로 인스턴스 그룹을 생성할 수 있으므로 컨트롤러 클러스터의 매우 구체적인 호스트로 작업을 보낼 수 있습니다.

8.1.8. 인스턴스 그룹 프로비저닝 해제¶

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

1. automation-controller-service stop 명령을 사용하여 인스턴스를 종료하거나 서비스를 중지합니다.

2. 다른 인스턴스에서 프로비저닝 해제 명령 ``$ awx-manage deprovision_instance –hostname=<name used in inventory file>``을 실행하여 컨트롤러 클러스터 레지스트리에서 제거합니다.

   예: awx-manage deprovision_instance --hostname=hostB

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

예: awx-manage unregister_queue --queuename=<name>

인벤토리 파일의 인스턴스 그룹에서 인스턴스 멤버십을 제거하고 설정 플레이북을 다시 실행하면 인스턴스가 그룹에 다시 추가될 수도 있습니다. 인스턴스가 그룹에 다시 추가되지 않도록 하려면 API를 통해 제거하고 인벤토리 파일에서도 제거하면 됩니다. 또는 인벤토리 파일에서 인스턴스 그룹 정의를 완전히 중지해도 됩니다. automation controller 사용자 인터페이스를 통해 인스턴스 그룹 토폴로지를 관리할 수도 있습니다. UI에서 인스턴스 그룹을 관리하는 방법에 대한 자세한 내용은 |atu|에서 :ref:`Instance Groups <userguide:ug_instance_groups>`을 참조하십시오.

8.2.1. 컨테이너 그룹 생성¶

``ContainerGroup``은 OpenShift 클러스터에 연결할 수 있는 관련 인증 정보가 있는 ``InstanceGroup``입니다. 컨테이너 그룹을 설정하려면 먼저 다음이 있어야 합니다.

• 시작할 수 있는 네임스페이스(《기본》 네임스페이스가 있지만 대체로 고객마다 다름)

• 이 네임스페이스의 Pod를 시작하고 관리할 수 있는 역할이 있는 서비스 계정

• 프라이빗 레지스트리에서 |ees|을 사용하고 이 환경에 연결된 컨테이너 레지스트리 인증 정보가 자동화 컨트롤러에 있는 경우 네임스페이스에서 비밀을 가져오고, 생성하고, 삭제하는 역할도 서비스 계정에 필요합니다. 이러한 역할을 서비스 계정에 부여하지 않으려면 ``ImagePullSecrets``를 사전 생성하여 ContainerGroup의 Pod 사양에 지정할 수 있습니다. 이 경우 |ee|에는 연결된 컨테이너 레지스트리 인증 정보가 없어야 합니다. 그렇지 않으면 컨트롤러가 네임스페이스에 비밀을 생성하려고 합니다.

• 서비스 계정과 연결된 토큰(OpenShift 또는 Kubernetes Bearer 토큰)

• 클러스터와 연결된 CA 인증서

다음은 서비스 계정을 생성하고 automation controller 구성에 필요한 정보를 수집하는 방법의 예입니다.

1. 위의 인증 정보를 가져오려면 이 예제를 containergroup sa 다운로드하여 사용하십시오.

2. containergroup-sa.yml::의 구성을 적용합니다.

   oc apply -f containergroup-sa.yml
   

3. 서비스 계정과 연결된 시크릿 이름을 가져옵니다.

   export SA_SECRET=$(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"')
   

4. 시크릿에서 토큰을 가져옵니다.

   oc get secret $(echo ${SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token
   

5. CA 인증서를 가져옵니다.

   oc get secret $SA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt
   

6. containergroup-sa.token 및 containergroup-ca.crt 콘텐츠를 사용하여 컨테이너 그룹에 필요한 OpenShift 또는 Kubernetes API 전달자 토큰 에 대한 정보를 제공합니다.

컨테이너 그룹을 생성하려면 다음을 수행합니다.

1. 컨트롤러 사용자 인터페이스를 사용하여 컨테이너 그룹과 함께 사용할 OpenShift 또는 Kubernetes API 전달자 토큰 인증 정보를 생성합니다. 자세한 내용은 |atu|에서 :ref:`ug_credentials_add`를 참조하십시오.

2. 왼쪽 탐색 모음에서 **인스턴스 그룹**을 클릭해 인스턴스 그룹 구성 창으로 이동하여 새 컨테이너 그룹을 생성합니다.

3. 추가 버튼을 클릭하고 **컨테이너 그룹 생성**을 선택합니다.

4. 새 컨테이너 그룹의 이름을 입력하고 이전에 생성된 인증 정보를 선택하여 컨테이너 그룹에 연결합니다.

8.2.2. Pod 사양 사용자 지정¶

|aap|에서 간단한 기본 Pod 사양을 제공하지만 기본 Pod 사양을 덮어쓰는 사용자 지정 YAML(또는 JSON) 문서를 제공할 수 있습니다. 이 필드는 유효한 Pod JSON 또는 YAML로 《직렬화》할 수 있는 모든 사용자 지정 필드(즉, ImagePullSecrets)를 사용합니다. 전체 옵션 목록은 `OpenShift documentation <https://docs.openshift.com/online/pro/architecture/core_concepts/pods_and_services.html>`_에서 확인할 수 있습니다.

Pod 사양을 사용자 지정하려면 토글을 사용하여 Pod 사양 덮어쓰기 필드를 활성화하고 확장하여 Pod 사양 덮어쓰기 필드에 네임스페이스를 지정한 다음, 완료되면 **저장**을 클릭합니다.

필요한 경우 추가 사용자 지정을 제공할 수 있습니다. **확장**을 클릭하여 전체 사용자 지정 창을 봅니다.

컨테이너 그룹이 성공적으로 생성되면 새로 생성된 컨테이너 그룹의 세부 정보 탭이 유지되므로 컨테이너 그룹 정보를 검토하고 편집할 수 있습니다. 인스턴스 그룹 링크에서 편집() 버튼을 클릭했을 때 열리는 메뉴와 같습니다. **인스턴스**를 편집하고 이 인스턴스 그룹과 연결된 **작업**을 검토할 수도 있습니다.

그에 따라 컨테이너 그룹과 인스턴스 그룹의 레이블이 지정됩니다.

8.2.3. 컨테이너 그룹 기능 확인¶

컨테이너 배포 및 종료를 확인하려면 다음을 수행합니다.

1. mock 인벤토리를 생성하고 인스턴스 그룹 필드에 컨테이너 그룹 이름을 채워 컨테이너 그룹을 인벤토리에 연결합니다. 자세한 내용은 |atu|에서 :ref:`ug_inventories_add`를 참조하십시오.

2. 변수를 사용하여 인벤토리에 《localhost》 호스트를 생성합니다.

{'ansible_host': '127.0.0.1', 'ansible_connection': 'local'}

3. ping 또는 setup 모듈을 사용하여 localhost에 애드혹 작업을 시작합니다. 머신 인증 정보 필드는 필수지만 이 간단한 테스트에서는 어떤 것을 선택하든 상관없습니다.

작업 세부 정보 뷰에서는 애드혹 작업 하나를 사용하여 컨테이너에 성공적으로 도달한 것을 확인할 수 있습니다.

OpenShift UI가 있는 경우 Pod가 배포되고 종료될 때 표시되고 사라지는 것을 확인할 수 있습니다. 또는 CLI를 사용해 네임스페이스에서 get pod 작업을 수행하여 동일한 이벤트가 발생하는 것을 실시간으로 확인할 수 있습니다.

8.2.4. 컨테이너 그룹 작업 보기¶

컨테이너 그룹과 연결된 작업을 실행하는 경우 세부 정보 뷰와 이 뷰의 연결된 인스턴스 그룹 및 실행 노드에서 해당 작업의 세부 정보를 확인할 수 있습니다.

8.2.5. Kubernetes API 실패 상태¶

컨테이너 그룹을 실행할 때 Kubernetes API가 리소스 할당량을 초과했다고 응답하는 경우 컨트롤러는 작업을 보류 상태로 유지합니다. 다른 실패가 발생하는 경우 다음 예제와 같이 실패 이유를 표시하는 오류 세부 정보 필드가 역추적됩니다.

8.2.6. 컨테이너 용량 제한¶

컨테이너의 용량 제한 및 할당량은 Kubernetes API에서 오브젝트를 통해 정의됩니다.

• 지정된 네임스페이스 내의 모든 Pod에 제한을 설정하려면 LimitRange 오브젝트를 사용합니다. `Quotas and Limit Ranges <https://docs.openshift.com/online/pro/dev_guide/compute_resources.html#overview>`_에 대한 OpenShift 문서를 참조하십시오.

• 컨트롤러에서 시작한 Pod 정의에 제한을 직접 설정하려면 Customize the Pod spec`_을 참조하고 `compute resources 옵션을 설정하려면 OpenShift 문서를 참조하십시오.