|rhaap|에 관심을 가져 주셔서 감사합니다. |aap|을 사용하면 조직 전체의 사용자가 간단하고 강력하며 에이전트가 없는 기술 구현을 통해 자동화 콘텐츠를 공유, 검사, 관리할 수 있습니다. IT 관리자는 개별 팀에 자동화 적용 방법에 대한 지침을 제공할 수 있습니다. 자동화 개발자는 복잡한 툴 및 프레임워크를 따르는 운영 오버헤드 없이 기존 지식을 사용하는 작업을 자유롭게 작성할 수 있습니다. 하이브리드 클라우드에서 에지에 이르기까지 포괄적인 자동화 솔루션을 배포할 수 있는 더 안전하고 안정적인 기반입니다.
|aap|에는 사용자가 엔터프라이즈 전체에서 자동화를 정의, 운영, 확장, 위임할 수 있는 |at|가 포함되어 있습니다.
플레이북이 실행되는 것을 실시간으로 보면서 체크인할 때 각 호스트를 확인합니다. 쉽게 돌아가서 특정 작업 및 호스트에 대한 결과를 매우 자세히 탐색할 수 있습니다. 특정 플레이 또는 호스트를 검색하여 해당 결과만 보거나 수정해야 하는 오류에 초점을 둘 수 있습니다.
|At|를 사용하면 역할 기반 액세스 제어(RBAC)를 통해 다른 팀이나 명시적 사용자에게 특정 작업(예: 파일 보기, 생성 또는 수정)을 수행할 수 있는 권한을 부여할 수 있습니다.
일부 프로젝트는 비공개로 유지하면서 일부 사용자는 인벤토리를 편집하고 다른 사용자는 특정 시스템에 대해서만 플레이북을 확인(시험 실행) 또는 라이브 모드로 실행할 수 있도록 허용합니다. 특정 사용자가 인증 정보를 노출하지 않고 사용하도록 허용할 수도 있습니다. 어떠한 작업을 수행하든 |at|는 편집된 오브젝트와 시작된 작업을 포함하여 작업에 대한 기록과 작업을 수행한 사용자를 기록합니다.
|at|는 사용자 피드백에 따라 역할 기반 액세스 제어를 확장하고 단순화합니다. 더 이상 작업 템플릿 가시성을 인벤토리, 프로젝트, 인증 정보에 대한 권한 조합을 통해 구성하지 않습니다. 사용자 또는 팀에 작업 템플릿을 사용할 수 있는 권한을 부여하려면 작업 템플릿에 직접 권한을 할당하기만 하면 됩니다. 마찬가지로 인증 정보는 |at| RBAC 시스템의 전체 오브젝트에 해당하며, 여러 사용자 및/또는 팀에 할당하여 사용할 수 있습니다.
|At|에는 시스템 자동화의 모든 측면을 볼 수 있지만 시스템 수준 감사자가 필요한 사람들을 위해 자동화를 실행하거나 변경할 권한이 없는 ‘감사자’ 유형이 포함됩니다. (이는 REST API에서 자동화 정보를 스크랩하는 서비스 계정에도 유용할 수 있습니다.) 자세한 내용은 :ref:`rbac-ug`를 참조하십시오.
|at|의 후속 릴리스에서는 더 세분화된 권한을 제공하여 더 쉽게 조직 내부에서 위임하고 자동화 병목 현상을 제거할 수 있습니다.
|At|에서는 요청 시 노드에서 구성을 요청할 수 있는 강력한 프로비저닝 콜백 기능을 제공합니다. 이 기능은 선택 사항이지만 Cobbler와 같은 프로비저닝 서버와 통합하는 클라우드 자동 확장 시나리오나 가동 시간을 예측할 수 없는 관리형 시스템을 처리할 때 이상적인 솔루션입니다. 원격 노드에 관리 소프트웨어를 설치할 필요가 없는 콜백 솔루션은 ‘curl’ 또는 ‘wget’에 대한 간단한 호출을 통해 트리거할 수 있으며, init 스크립트, kickstart 또는 preseed에 쉽게 포함할 수 있습니다. 인벤토리에 있는 머신에서만 구성을 요청할 수 있도록 액세스가 제어됩니다.
automation controller REST API는 시스템 관리 애플리케이션에 이상적인 RESTful API로, 모든 리소스가 완전히 검색 가능하고 페이지가 매겨지며 잘 모델링됩니다. 스타일이 지정된 API 브라우저에서는 API 루트(http://<server name>/api/)에서 API 탐색을 수행하여 모든 리소스와 관계를 표시할 수 있습니다. 사용자 인터페이스에서 수행할 수 있는 모든 작업과 그 이상을 API에서 수행할 수 있습니다.
시스템을 백업하고 복원하는 기능이 Ansible Automation Platform 설정 플레이북에 통합되어 필요에 따라 인스턴스를 쉽게 백업하고 복제할 수 있습니다.
자동화를 설명하는 사람들은 모두 “반복 금지”라는 주문을 반복해서 말합니다. Ansible Galaxy에서와 같이 중앙 집중식 Ansible 역할 복사본을 사용하면 이러한 철학을 플레이북에 적용할 수 있습니다. 프로젝트 디렉터리에 Ansible Galaxy requirements.yml 파일을 포함하면 |at|에서 Galaxy, GitHub 또는 로컬 소스 제어를 통해 플레이북에 필요한 역할을 자동으로 가져옵니다. 자세한 내용은 :ref:`ug_galaxy`을 참조하십시오.
Ansible은 모든 사용자가 사용할 수 있도록 OpenStack을 간소화하기 최선을 다하고 있습니다. 이러한 노력의 일환으로 OpenStack에 대한 동적 인벤토리 지원이 추가되었습니다. 이를 통해 OpenStack 클라우드에서 실행 중인 가상 머신 또는 이미지를 쉽게 대상으로 지정할 수 있습니다.
단일 사용자를 추가하거나, 단일 보안 취약점을 업데이트하거나, 오작동하는 서비스를 다시 시작하는 등 몇 개의 호스트에서 간단한 작업만 수행하면 되는 경우가 많습니다. |At|에는 원격 명령 실행 기능이 포함되어 있습니다. 단일 Ansible 플레이로 설명할 수 있는 모든 작업을 인벤토리의 호스트 또는 호스트 그룹에서 실행하여 시스템을 쉽고 빠르고 관리할 수 있습니다. 또한 RBAC 엔진 및 세부 감사 로깅이 모두 지원되므로 누가 어떤 머신에 어떤 작업을 수행했는지 질문할 필요가 없습니다.
사실 캐싱 기능을 사용하여 사실을 수집할 수 있습니다. 자세한 내용은 :ref:`ug_fact_caching`을 참조하십시오.
|at|에서는 자동화 상태를 쉽게 추적할 수 있습니다. 작업 템플릿, 프로젝트 또는 전체 조직에 대해 누적 가능한 알림을 구성하고 작업 시작, 작업 성공, 작업 실패, 작업 승인(워크플로우 노드의 경우)에 대해 서로 다른 알림을 구성할 수 있습니다. 다음 알림 소스가 지원됩니다.
이메일
Grafana
IRC
Mattermost
PagerDuty
Rocket.Chat
Slack
Twilio
Webhook(다른 툴과의 통합을 위해 임의의 Webhook에 게시)
또한 위 알림 유형 각각에 대해 :ref:`customize notification messages <ug_custom_notifications>`를 수행할 수 있습니다.
Red Hat Satellite 6의 동적 인벤토리 소스가 지원됩니다.
Ansible 명령행의 유연성을 활용하여 다음 중 하나를 요청할 수 있습니다.
인벤토리
인증 정보
작업 태그
제한
Automation controller supports integration with Red Hat Insights, which allows Insights playbooks to be used as a Ansible Automation Platform Project.
사용자 인터페이스의 레이아웃은 직관적인 탐색 요소로 구성됩니다. 정보가 한눈에 표시되므로 필요한 자동화를 직관적으로 찾고 사용할 수 있습니다. 필요에 따라 컴팩트 및 펼치기 보기 모드를 사용하여 정보를 표시하거나 숨기고, 다양한 기본 제공 특성을 통해 쉽게 정렬할 수 있습니다.
사용자 지정 Ansible 환경 지원을 사용하면 다양한 Ansible 환경을 보유하고 다양한 팀과 작업에 사용자 정의 경로를 지정할 수 있습니다.
Automation controller supports LDAP, SAML, token-based authentication. Enhanced LDAP and SAML support allows you to integrate your enterprise account information in a more flexible manner. Token-based Authentication allows for easily authentication of third-party tools and services with automation controller via integrated OAuth 2 token support.
클러스터 그룹 런타임 관리를 통해 확장을 쉽게 구성할 수 있습니다.
|aap|은 Red Hat OpenShift Container Platform에 컨테이너화된 Pod 서비스로 사용할 수 있으며, 필요에 따라 쉽게 확장 및 축소할 수 있습니다.
복잡한 프로비저닝, 배포, 오케스트레이션 워크플로우를 더 효과적으로 모델링하기 위해 |at|는 다음과 같은 다양한 방법으로 워크플로우를 확장했습니다.
워크플로우에 대한 인벤토리 덮어쓰기. 이제 워크플로우 정의 시 또는 시작 시에도 워크플로우 전체에서 인벤토리를 덮어쓸 수 있습니다. 애플리케이션 배포 워크플로우를 정의한 다음 여러 환경에서 쉽게 다시 사용할 수 있습니다.
워크플로우 통합 노드. 복잡한 프로세스를 모델링할 때 여러 단계가 완료될 때까지 기다린 후 진행해야 하는 경우가 있습니다. 이제 automation controller 워크플로우에서 이러한 방식을 쉽게 복제할 수 있습니다. 워크플로우 단계는 이전 워크플로우 단계가 몇 개든 모두 올바르게 완료될 때까지 기다린 후 진행할 수 있습니다.
워크플로우 중첩. 개별 워크플로우를 대규모 워크플로우의 구성 요소로 다시 사용합니다. 예를 들면 프로비저닝 및 애플리케이션 배포 워크플로우를 단일 마스터 워크플로우로 결합합니다.
워크플로우 일시 중지 및 승인. 사용자 개입이 필요한 승인 노드가 포함된 워크플로우를 빌드할 수 있습니다. 이렇게 하면 플레이북 간에 워크플로우를 일시 중지하여 사용자가 워크플로우의 다음 단계를 계속 진행하는 것에 대해 승인(또는 거부)할 수 있습니다.
자동화가 엔터프라이즈 수준으로 전환됨에 따라 대규모 자동화에 대한 필요성이 커지고 있습니다. |At|는 수천 대의 머신에서 실행되는 사실 수집 또는 구성 작업을 수행하고, 안정성 향상, 작업 완료 시간 단축, 클러스터 사용률 개선을 위해 |at| 클러스터에 배포할 수 있는 개별 작업 슬라이스로 작업을 분할하는 기능을 제공합니다. 이제 15,000개의 스위치에서 대규모로 매개변수를 변경하거나 수천 개의 노드가 있는 RHEL 자산에서 정보를 수집해야 하는 작업을 쉽게 수행할 수 있습니다.
|at|는 FIPS와 같은 제한된 모드에서 환경을 실행해야 하는 경우에도 배포 및 실행됩니다.
대부분의 대규모 조직에는 여러 조직에서 공유하는 인스턴스가 있습니다. 조직은 한 조직이 라이센스가 부여된 모든 호스트를 사용하는 것을 원하지 않습니다. 이 기능을 사용하면 슈퍼유저가 각 조직에 할당할 수 있는 라이센스가 부여된 호스트 수에 대해 지정된 상한을 설정할 수 있습니다. automation controller 알고리즘 요소는 조직에 대한 제한과 모든 조직의 총 호스트 수를 변경합니다. 인벤토리 동기화로 인해 조직이 정책을 준수하지 않는 경우 인벤토리가 업데이트되지 않습니다. 또한 슈퍼유저는 경고와 함께 라이센스를 ‘초과 할당’할 수 있습니다.
Ansible 2.9에서 인벤토리 업데이트가 실행되는 경우 업스트림 컬렉션의 다음 인벤토리 플러그인을 사용하도록 |at|가 업데이트되었습니다.
amazon.aws.aws_ec2
community.vmware.vmware_vm_inventory
azure.azcollection.azure_rm
google.cloud.gcp_compute
theforeman.foreman.foreman
openstack.cloud.openstack
ovirt.ovirt.ovirt
awx.awx.tower
시크릿 관리 시스템을 사용하면 외부 인증 정보가 저장되고 |at|에서 사용할 수 있도록 제공되므로 직접 제공할 필요가 없습니다.
|ah|는 |at|의 콘텐츠 공급자 역할을 하며, 이를 위해서는 |at| 배포와 Automation Hub 배포가 함께 실행되어야 합니다.