Ansible Tower(AWX) 클러스터링 번역

Ansible Tower Administration Guide v3.4.3의 7. Clustering 대한 번역입니다.

원문 : https://docs.ansible.com/ansible-tower/latest/html/administration/clustering.html

Clustering

• Ansible Tower 3.1부터 클러스터링을 도입하였고,
• Ansible Tower 3.2부터 클러스터 된 인스턴스를 다른 풀과 큐에서 그룹화할 수 있습니다.
• 인스턴스는 여러 개의 인스턴스 그룹으로 그룹화될 수 있고, 아래 나열된 자원들에 복수로 할 당 될 수 있음.
  
  • Organizations
  • Inventories
  • Job Templates
• 자원중 하나와 연관된 작업이 실행되면, 연관된 인스턴스 그룹에 할당됨.
• Job Template > Inventory > Organization 순으로 인스턴스가 할당됨.
• Ansible Tower 3.3부터 OpenShift나 Kubernetes를 사용한, 컨테이너 기반 클러스터링을 지원합니다.
  • OpenShift Deployment and Configuration

Supported Operation Systems

• RHEL-7(Centos-7)
• Ubuntu 16
• 격리된 인스턴스는 현재 RHEL-7에만 설치할 수 있음

Setup Considerations

초기 설정에 대한 고려 사항만 다루고, 이미 존재하는 클러스터의 업그레이드에 관한 부분은 Upgrade Planning 참고하면 됩니다.

새로운 클러스터 환경에서의 중요한 고려사항

• PostgreSQL은 여전히 standalone 인스턴스이고, 클러스터화 되지 않습니다.
• Tower에서는 복제 설정이나, 데이터베이스 복구에 관련한 부분을 매니징 하지 않습니다.
• 클러스터 안에서 인스턴스의 수는 항상 홀수개여야 하고, 최소 3개~ 최대 20개 의 인스턴스일 경우에는 반드시 적용되어야 좋습니다. 그보다 많은 경우에는 홀수개가 반드시 요구되지는 않습니다.
• 모든 인스턴스는 서로 다른 모든 인스턴스에 접속 가능해야 하고, 데이터베이스에 접속할 수 있어야 합니다. 이것은 호스트가 안정적인 주소 또는/와 호스트네임(Tower 호스트 설정에 따름)을 갖는 것이 중요합니다.
• 모든 인스턴스는 지리적으로 동일하게 위치해야 하고, 인스턴스 사이에 접속은 신뢰할 수 있는 낮은 대기시간을 갖아야 합니다.
• RabbitMQ는 Tower 클러스터링의 시스템의 초석입니다. 요청사항과 동작 구성의 많은 부분이 RabbitMQ에 의해서 지시됩니다.
• 따라서, 커스텀 설정은 Tower의 셋업 플레이북에서 제한적이다. 각각의 Tower 인스턴스에 RabbitMQ가 배치되며, 그것은 다른 인스턴스와 RabbiMQ 인스턴스들과 함께 클러스터가 된다.
• 클러스터 환경으로 업그레이드하기 위해, 기본 인스턴스는 Tower의 인벤토리 그룹에 속 해야 하고, Tower 그룹 안에 리스트 된 첫 번째 호스트여야 한다.
• 수동 프로젝트는 수동으로 모든 고객의 모든 인스턴스를 동기화하고, 모든 인스턴스를 한 번에 업데이트해야 합니다.
• 새 Tower 시스템에서는 primary/secondary 개념이 아니고, 모든 시스템들이 primary입니다.
• 셋업 플래이북은 RabbitMQ의 설정을 변경하고, 호스트들에 올라온 네트워크의 타입을 규정합니다.
• Tower 배치에 대한 인벤토리 파일이 저장되고, 지속되어야 합니다. 만약 새로운 인스턴스가 프로비전 하려면, 호스트 네임, 패스워드와 구성 옵션을 설치 프로그램에서 사용할 수 있어야 한다.
• instance_group_tower라는 그룹 이름을 만들지 말아야 한다.
• 인스턴스 이름을 그룹 이름과 동일하게 지정하지 말아야 한다.

Install and Configure

새로운 인스턴스를 프로비저닝 하려면, 인벤토리 파일을 업데이트하고 셋업 플레이북을 재실행해야 한다.
인벤토리 파일에 클러스터 설치나 다른 인스턴스 재설정을 할 때 필요한 모든 패스워드와 정보가 포함돼있어야 합니다.
현재 standalone 인스턴스 설정은 3.1 이상에서는 변경되지 않습니다. 인벤토리 파일은 몇 가지 중요한 방식으로 변경됩니다.

• primary/secondary 구성이 아니기 때문에, 해당 인벤토리 그룹은 사라지고, tower라는 하나의 인벤토리 그룹으로 대체된다.
• 당신은 그룹 안에서 다른 그룹과 그룹 인스턴스들을 선택적으로 정의할 수 있다. 이런 그룹의 이름은 instance_group_ 로 시작해야 한다. 인스턴스는 다른 instance_group_ 그룹에 있어야 하는 것은 아니지만, 하나의 인스턴스는 반드시 tower 그룹에 있어야 합니다. 기술적으로는 tower는 어떠한 다른 instance_group_ 그룹이지만 그것이 항상 그런 것은 아니고, 만일 특정 리소스에 관련되어 있지 않으면, 모든 잡 실행이 tower 그룹으로 항상 되돌아갈 것입니다. 3.3에서 tower 인스턴스 그룹은 항상 존재할 겁니다.(이건 삭제되거나 이름 변경을 할 수 없음)

모든 인스턴스는 작업 스케줄링과 관련된 다양한 관리 작업(예: 작업 시작 위치 결정, 플래이 북 이벤트 처리, 정기적인 정리 작업)을 담당합니다.

만약 리소스를 위한 선택된 그룹이 없으면, tower 그룹이 사용된다. 하지만, 그룹을 선택했다면, tower 그룹은 사용되지 않습니다.

database 그룹은 외부 Postgres 지정하기 위해서 남아있습니다. 데이터베이스 호스트가 별도로 제공된다면, 이 그룹은 비어있어야 합니다.

Tower 인스턴스들은 외부에 프로비저닝 하는 것이 일반적이지만, 내부 주소 지정을 통해서 참조하는 게 가장 좋습니다. 외부 인터페이스에서 모든 서비스를 사용할 수 없도록 하는 것이 RabbitMQ 클러스터링 가장 중요합니다. 이를 위해서는 RabbitMQ 링크의 내부 주소를 다음과 같이 지정해야 합니다.

클러스터 안에서 인스턴스의 수는 항상 홀수개여야 하고, 최소 3개~ 최대 20개 의 인스턴스일 경우에는 반드시 적용되어야 좋습니다. 그보다 많은 경우에는 홀수개가 반드시 요구되지는 않습니다.

• redis_password 필드는 [all:vars] 설정으로 이전되었습니다.
• RabbitMQ를 위한 필드는 아래와 같습니다.
  • rabbitmq_port=5672 : RabbitMQ는 각 인스턴스에 설지 되고, 선택 사항이 아닙니다. 그것을 외부화하는 것도 불가능합니다. 이 설정은 수신 대기하는 포트를 구성합니다.
  • rabbitmq_vhost=tower : Tower가 RabbitMQ 가상 호스트를 구성하고, 자체 격리하는 설정을 제어합니다.
  • rabbitmq_username=tower and rabbitmq_password=tower : 각 인스턴스와 각 인스턴스들의 Tower 인스턴스는 이 값들로 구성됩니다. 이것은 Tower의 다른 사용자 이름/패스워드들과 유사하다.
  • rabbitmq_cookie=<somevalue> : 이 값은 standalone 배포에서는 사용하지 않지만, 클러스터 된 배포에서는 중요하다. 이것은 RabbitMQ 클러스터 멤버가 서로를 식별할 수 있게 하는 비밀 키 역할을 합니다.
  • rabbitmq_enable_manager : 이 값을 true로 하면, 각 인스턴스의 RabbitMQ 관리 웹 콘솔이 표시됩니다.

RabbitMQ Default Settings

아래 설정은 RabbitMQ를 위한 기본 설정을 보여준다.

rabbitmq_cookie는 민감한 값으로, Tower 안에 비밀키처럼 취급해야 합니다.

Instances and Ports Used by Tower

Tower에서 사용하는 포트들과 인스턴스:

• 80, 443 (일반 Tower 포트)
• 22 (ssh)
• 5432 (데이터베이스 인스턴스 - 외부 인스턴스로 데이터베이스가 설치되어있다면, tower 인스턴스들에 오픈이 필요함)

클러스터링/RabbitMQ 포트:

• 4369, 25672 (RabbitMQ가 클러스터를 유지하기 위해 특별히 사용하는 포트는 각 인스턴스 사이에서 열어야 합니다.)
• 15672 (RabbitMQ 관리 인터페이스가 허용된 경우, 이 포트를 열어야 합니다.(선택 사항)

Configuring Instances and Instance Groups from the API

인스턴스 그룹은 시스템 관리자가 /api/v2/instance_groups 포스팅을 통해서 생성할 수 있습니다.

생성된 인스턴스들은 하나의 인스턴스 그룹에 연계될 수 있습니다.

인스턴스 그룹에 추가된 인스턴스는 자동으로 그룹의 작업 큐에서 수신 대기하도록 구성됩니다. 자세한 내용은 다음 절에 나오는 Instance group polices을 확인하세요.

Instance group policies

Ansible Tower 3.3부터 사용자는 정책(policy)을 정의하여, 온라인 상태가 되면, 인스턴스 그룹에 자동으로 참여하도록 Tower 인스턴스를 구성할 수 있습니다. 이러한 정책은 온라인으로 제공되는 모든 새로운 인스턴스에 대해 평가됩니다.

인스턴스 그룹 정책은 인스턴스 그룹의 세 가지 선택적 필드로 제어됩니다:

• policy_instance_percentage : 0-100 사이의 숫자이고, 이는 활성화된 Tower 인스턴스의 비율이고, 해당 인스턴스 그룹에 추가됨을 보장합니다. 새 인스턴스가 온라인 상태가 되면, 이 그룹의 인스턴스 수에 대한 주어진 비율보다 적을 경우, 백분율 조건이 충족될 때까지 새 인스턴스가 추가됩니다.
• policy_instance_minimum : 이 정책은 인스턴스 그룹 안에 인스턴스를 최소한의 개수까지 유지하려고, 노력합니다. 최소로 사용 가능한 인스턴스 수보다 적으면, 모든 인스턴스들은 이 인스턴스 그룹으로 배치됩니다.
• policy_instance_list : 이것은 인스턴스 그룹 안에서 항상 포함되는 인스턴스 고정 목록입니다.

Ansible Tower 사용자 인터페이스의 인스턴스 그룹 목록보기는 각 인스턴스 그룹의 정책에 따른 각 인스턴스 그룹을 위한 요약된 사용량 레벨을 제공합니다.

 

Notable policy considerations

• policy_instance_percentage와 policy_instance_minimum 둘 다 최소 할당을 한다. 이런 룰은 더 많은 인스턴스가 그룹에 할당되는 효과를 결과를 가져옵니다. 예를 들면 policy_instance_percentage 가 50%이고, policy_instance_minimum 이 2이고 6개의 인스턴스를 시작하면, 그중 3개가 인스턴스 그룹에 지정됩니다. 클러스터의 총 인스턴스 수를 2로 줄이면, policy_instance_minimum을 만족시키기 위해서, 둘 다 인스턴스 그룹에 지정됩니다. 이 방법으로 사용 가능한 리소스량의 하한을 설정할 수 있습니다.
• 정책은 인스턴스가 여러 인스턴스 그룹과 연관되는 것을 적극적으로 방지하지 않지만, 백분율을 100으로 늘림으로써 정책을 효과적으로 수행될 수 있습니다. 4개의 인스턴스 그룹이 있는 경우 각각의 백분율 값을 25로 지정하면 인스턴스가 겹치지 않고 분산됩니다.

Manually pinning instances to specific groups

특정 인스턴스 그룹에 독점적으로 할당되어야 하지만, "백분율" 또는 "최소" 정책을 통해 다른 그룹에 자동으로 참여하지 못하게 하는 특별한 인스턴스가 있는 경우:

1. 하나이상의 인스턴스를 인스턴스 그룹의 policy_instance_list에 추가한다.
2. 인스턴스의 managed_by_policy 속성을 False로 업데이트한다.

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

Isolated Instance Groups

Ansible Tower 3.2 버전 이상에서는 보안상 제한된 네트워크 존에 작업 및 명령어를 실행할 수 있도록, 격리된 그룹을 정의할 수 있는 옵션이 추가되었습니다. 이 그룹의 인스턴스들은 Tower가 전체 설치되어 있지 않아도 되지만, 잡 실행을 위한 최소한의 유틸리티들은 가지고 있어야 합니다. 격리된 그룹은 isolated_group_ 로 시작하는 인벤토리 파일 안에 명시되어야 합니다. 다음은 격리된 인스턴스 그룹에 대한 인벤토리 파일의 예입니다.

 

격리된 인스턴스 그룹 모델에서 "controller" 인스턴스는 "isolated" 인스턴스와 SSH 위에 Ansible playbook 시리즈들을 통해서 상호 작용합니다. 설치 시에 기본 임의의 RSA 키가 생성되어있고 모든 "isolated" 인스턴스는 인증키가 배포되었습니다. 비공개 키는 암호화되어 Tower 데이터베이스에 저장되고, "controller" 인스턴스로부터 "isolated" 인스턴스까지 작업을 실행할 때 인증하는 데 사용됩니다.

"isolated" 인스턴스에서 스케줄 된 작업을 실행할 때:

• "controller" 인스턴스는 작업을 실행하는데, 필요한 메타데이터를 컴파일하고 이를 "isolated" 인스턴스에 복사합니다.
• 메타 데이터가 격리된 호스트에 동기화되면, "controller" 인스턴스는 "isolated" 인스턴스에 작업을 시작합니다. 이 인스턴스는 메타데이터를 소비하고, ansible/ansible-playbook을 실행하기 시작한다. 플래이북이 실행되면, 작업 산출물(stdout과 작업 이벤트 같은 것들)은 "isolated" 인스턴스의 디스크에 쓰인다.
• 작업이 "isolated"된 인스턴스에서 실행되는 동안, "controller" 인스턴스는 주기적으로, 작업 산출물(stdout과 작업 이벤트 같은 것들)을 "isolated" 인스턴스에서 복사한다. 이러한 작업은 "isolated" 인스턴스에 작업이 완료될 때까지 실행됩니다.

컨트롤러 노드는 격리된 실행 중에 오프라인 상태가 되면 실패됩니다. 플래이 북 실행 중에 Tower노드를 재시작하거나, 플래이북 실행 중에 중지되면, 온라인 상태가가 되었을 때 다시 시작되지 않습니다.

격리된 그룹(노드)들은 컨트롤러 그룹의 인스턴스만 액세스 할 수 있도록 하는 보안 규칙을 사용하여 VPC 내부에 존재할 수 있도록 만들어질 수 있습니다. "controller" 인스턴스에서 "isolated" 인스턴스로 SSH 통신만 허용됩니다. 격리된 노드를 프로비저닝 할 때, 당신의 설치 머신은 격리된 노드에 접속할 수 있어야 합니다. 격리된 노드는 직접 접속이 안되지만, 다른 호스트를 통해서 간접적으로 도달할 수 있는 경우에, ProxyCommand를 SSH 설정에 명시고, 인스톨러는 실행하여 "jump host"를 지정할 수 있습니다.

 

 

격리된 그룹에 추천하는 시스템 설정:

• isolated_group_tower라는 그룹 이름을 만들지 않습니다.
• 격리된 인스턴스를 tower 그룹이나, 다른 일반 인스턴스 그룹에 넣지 않습니다.
• 격리된 그룹 안에 모든 인스턴스들은 컨트롤러 변수를 그룹 변수나, 호스트 변수에 정의합니다. 같은 그룹의 격리된 인스턴스가 다른 변수를 가지도록 허용하지 마십시오. - 이 경우의 동작은 예측할 수 없습니다.
• 격리된 인스턴스가 둘 이상의 격리된 그룹에 두지 마십시오.
• 일반 그룹과 격리 그룹 모두에 인스턴스를 두지 마십시오.
• 격리된 인스턴스에 fact 캐싱을 사용하지 마십시오.

Optional SSH Authentication

"controller" 노드에서 "isolated" 노드로 SSH 인증을 관리를 Tower의 외부 시스템(외부에서 관리되는 암호 없는 SSH 키 같은)으로 하기를 희망하는 사용자를 위하여, 아래 두 개의 Tower API 세팅 변수의 값을 제거함으로 비활성화할 수 있습니다.

Status and Monitoring via Browser API

Tower는 자체 볼 수 있는 API에 /api/v2/ping을 통해서, 가능한 많은 상태를 보고하여, 다음과 같은 클러스터 상태의 유효성을 확인합니다.

• HTTP 요청을 서비스하는 인스턴스
• 클러스터의 내 모든 인스턴스의 마지막 하트비트 시간
• 해당 그룹의 인스턴스 그룹 및 인스턴스 멤버십

/api/v2/instances와 /api/v2/instance_groups에서 작업 실행과 멤버십 정보를 포함한, 인스턴스와 인스턴스 그룹에 대한 자세한 사항을 볼 수 있습니다.

Instance Services and Failure Behavior

각 Tower 인스턴스들은 협력적으로 작동하는 서로 다른 서비스들로 구성됩니다.

• HTTP 서비스 - 여기는 외부 웹서비스뿐만 아니라 Tower 애플리케이션 자체도 포함됩니다.
• 콜백 리시버 - Ansible 작업 실행으로부터 작업 이벤트 수신
• Celery - 모든 작업을 실행하고 처리하는 워커 큐
• RabbitMQ - Celery의 신호 메커니즘뿐만 아니라, 애플리케이션에 전파되는 모든 이벤트 데이터의 메시지 브로커로 사용된다.
• Memcached - 로컬에 있는 인스턴스를 위한 로컬 캐싱 서비스

Tower는 이러한 서비스나 컴포넌트가 실패하게 되면, 모든 서비스를 재시작하는 방식으로 구성되었습니다. 만약 짧은 시간에 충분한 실패를 하게 되면, 자동으로 예기치 않은 동작을 일으키지 않고, 재조정을 허용하기 위해서, 전체 인스턴스가 오프라인 상태로 변경됩니다.

클러스터 된 환경을 백업 및 복원하려면, Backup and Restore for Clustered Environments 섹션을 참고하세요.

Job Runtime Behavior

작업이 실행되어 Tower의 '일반' 사용자에게 보고되는 방식은 변경되지 않습니다. 시스템 측면에서 주목할만한 차이는 다음과 같습니다.

• API인터페이스에서 작업을 제출하면, RabbitMQ의 Celery 큐로 푸시됩니다. 단일 RabbitMQ 인스턴스는 개별 큐에 대한 책임 마스터이지만, 각 Tower 인스턴스는 특정 스케줄링을 사용하여, 큐에 연결하고 해당 큐에서 작업을 수신합니다. 클러스터의 모든 인스턴스는 작업을 수신하고, 해당 작업을 실행하는데, 만약 작업을 실행하는 동안에 인스턴스가 실패하면, 작업이 영구적으로 실패로 표시됩니다.

 

• 클러스터가 별도의 인스턴스 그룹으로 분리되면, 동작은 클러스터 전체와 유사합니다. 두 개의 인스턴스가 그룹에 지정되면 둘 중 하나는 동일한 그룹의 다른 인스턴스와 마찬가지로 작업을 수신할 가능성이 높습니다.
• Tower 인스턴스가 온라인 상태가 되면 타워 시스템의 작업 용량이 효과적으로 확장됩니다. 이러한 인스턴스가 인스턴스 그룹에도 배치되면 해당 그룹의 용량도 확장됩니다. 인스턴스가 작업을 수행 중이고 여러 그룹의 구성원인 경우 구성원인 모든 그룹에서 용량이 줄어듭니다. 인스턴스를 회수하면 클러스터의 용량에서 제거되고 인스턴스가 할당됩니다. 좀 더 자세한 내용은 다음 섹션의 Deprovision Instances and Instance Groups를 보면 됩니다.

모든 인스턴스가 동일한 용량으로 프로비저닝 되어야 하는 것은 아닙니다.

• 프로젝트 업데이트가 이전과 다르게 동작합니다. 이전에는 단일 인스턴스에서 실행되는 일반 작업이었습니다. 현재는 잠재적으로 작업을 실행할 수 있는 모든 인스턴스에서 성공적으로 실행되는 것 이 중요합니다. 프로젝트는 이제 작업을 실행하기 직전에 인스턴스의 올바른 버전과 동기화됩니다.
• 인스턴스 그룹이 구성되었지만 해당 그룹의 모든 인스턴스가 오프라인이거나 사용할 수 없는 경우 해당 그룹만을 대상으로 시작된 모든 작업은 인스턴스를 사용할 수 있게 될 때까지 대기 상태로 고정됩니다. 이 시나리오에서 발생할 수 있는 작업을 처리하려면 장애 복구 또는 백업 리소스를 프로비저닝 해야 합니다.

Control Where a Job Runs

기본적으로 작업이 tower 큐에 제출되면, 모든 워커에 의해서 그 작업이 선택될 수 있습니다. 그러나 , 작업이 실행되는 인스턴스를 제한하는 것과 같이 특정 작업이 실행되는 위치를 제어할 수 있습니다. 작업 템플릿, 인벤토리 또는 조직에 연관된 인스턴스 그룹이 있는 경우 해당 작업 템플릿에서 실행된 작업은 기본 동작에 적합하지 않습니다. 이러한 3개의 자원과 연관된 인스턴스 그룹의 모든 인스턴스가 용량 부족인 경우 용량을 사용할 수 있을 때까지 보류 상태로 유지됩니다.

작업을 제출할 인스턴스 그룹을 결정할 때 우선순위는 다음과 같습니다.

1. 작업 템플릿
2. 인벤토리
3. 조직(프로젝트를 방식에 의한)

인스턴스 그룹이 작업 템플릿과 연관되어있고, 이들 모두가 용량에 도달하면 인벤토리에 지정된 인스턴스 그룹으로 작업이 제출된 다음 조직으로 전송됩니다. 자원은 사용할 수 있는 대로 우선순위에 따라 해당 그룹에서 작업을 실행합니다.

플레이북에 정의된 커스텀 인스턴스 그룹과 마찬가지로 글로벌 tower 그룹은 여전히 자원과 연계될 수 있습니다. 작업 템플릿 또는 인벤토리에 우선되는 인스턴스 그룹을 지정하는 데 사용할 수 있지만, 여전히 용량이 부족한 경우에 해당 인스턴스를 제출할 수 있습니다.

일시적으로 인스턴스를 오프라인으로 가져오는 것을 지원하기 위해 각 인스턴스에 사용 가능하도록 정의된 속성이 있습니다. 이 속성을 사용하지 않음으로 하면, 해당 인스턴스에 작업이 배정되지 않습니다. 기존 작업은 완료되지만 새 작업은 할당되지 않습니다.

Job Run Examples

예를 들어, group_a를 작업 템플릿에 연계시키고, tower 그룹을 인벤토리에 연계시키면, group_a의 용량이 부족한 경우 tower 그룹을 대비책(폴백)으로 사용할 수 있습니다.

게다가, 인스턴스 그룹을 하나의 자원과 연관시키지 않고, 다른 자원을 폴백으로 지정할 수 있습니다. 예를 들어 인스턴스 그룹을 작업 템플릿과 연계시키지 않고 인벤토리 및 또는 조직의 인스턴스 그룹으로 되돌려 놓습니다.

다음은 두 가지 다른 유용한 사용 사례입니다.

1. 인스턴스 그룹을 인벤토리에 연계(작업 템플릿을 인스턴스 그룹에 지정하지 않음)하면, 특정 인벤토리에 대해 실행된 모든 플레이북이 연관된 그룹에서만 실행되도록 할 수 있습니다. 이는 해당 인스턴스 만이 관리 노드에 직접 연결되는 상황에서 매우 유용할 수 있습니다.
2. 관리자 인스턴스 그룹을 조직에 지정할 수 있습니다. 이를 통해서 관리자는 효과적으로 전체 인프라를 분류하고 각 조직이 다른 조직의 기능을 방해하지 않고, 작업을 실행할 수 있는 용량을 확보할 수 있습니다.

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

• A, B, C라는 세 개의 인스턴스 그룹이 있고, Org1과 Org2의 두 조직이 있습니다.
• 관리자는 그룹 A를 Org1에 할당하고, 그룹 B는 Org2에 할당한 다음 그룹 C를 Org1과 Org2 모두에 할당하여 필요한 추가 용량의 오버플로로 할당합니다.
• 조직 관리자는 인벤토리 또는 작업 템플릿을 원하는 그룹에 할당하거나, 조직의 기본 순서를 상속받도록 할 수 있습니다.

 

이 방법으로 리소스를 정렬하면 많은 유연성을 얻을 수 있습니다. 또한 하나의 인스턴스만으로 인스턴스 그룹을 만들 수 있으므로 Tower 클러스터를 매우 특정한 호스트로 직접 작업할 수 있습니다.

Deprovision Instances and Instance Groups

의도적으로 오프라인으로 전환한 인스턴스 또는 실패로 인해 클러스터가 현재 인스턴스를 구별하지 못하기 때문에 셋업 플레이북을 재실행해도 인스턴스가 자동으로 프로비저닝 해제되지 않습니다. 대신 인스턴스의 모든 서비스를 종료 한 다음 다른 인스턴스에서 프로비저닝 해제 도구를 실행하십시오.

1. ansible-tower-service stop 명령어를 사용하여 인스턴스를 종료하거나 서비스를 중지합니다.
2. 다른 인스턴스에서 Tower 클러스터 레지스터리와 RabbitMQ 클러스터 레지스트리를 제거하기 위하여, awx-manage deprovision_instance --hostname=<name used in inventory file> 디프로비저닝 명령어를 실행합니다.
   예) awx-manage deprovision_instance --hostname=hostB

마찬가지로, Tower의 프로비저닝 해제하는 인스턴스 그룹은 자동으로 디프로비저닝 또는 인스턴스 그룹 삭제가 자동으로 되지 않습니다. 심지어 재 프로비저닝은 종종 이것들을 사용하지 못하도록 한다. API의 엔드포인트나 통계 모니터링에 여전히 표시될 수 있습니다. 이런 그룹은 다음 명령어로 삭제할 수 있습니다.

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

인벤토리 파일의 인스턴스 그룹에서 인스턴스의 구성원 자격을 제거하고, 셋업 플레이북을 재실행한다고 해서 해당 인스턴스가 그룹에 다시 추가되지는 않습니다. 인스턴스가 그룹에 다시 추가되지 않도록 하려면 API를 통해 제거하고 인벤토리 파일에서 인스턴스를 제거하거나 인벤토리 파일에서 인스턴스 그룹을 모두 정의하는 것을 중지하십시오. 또한 Ansible Tower 사용자 인터페이스를 통해 인스턴스 그룹 토폴로지를 관리할 수 있습니다. UI에서 인스턴스 그룹을 관리하는 방법에 대한 자세한 내용은 Ansible Tower User Guide안에 Instance Groups을 참고하세요.