GCP Marketplace의 Red Hat Ansible Automation Platform 가이드
GCP Marketplace에서 Red Hat Ansible Automation Platform 설치 및 구성
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
Red Hat의 기술 콘텐츠에 대한 귀하의 피드백에 감사드리며, 귀하의 의견을 알려 주시기 바랍니다. 주석을 추가하거나, 인사이트를 제공하거나, 오타를 수정하거나, 질문을 하려면 문서에서 직접 이 작업을 수행할 수 있습니다.
Red Hat 계정이 있어야 하며 고객 포털에 로그인해야 합니다.
고객 포털에서 문서 피드백을 제출하려면 다음을 수행하십시오.
- 다중 페이지 HTML 형식을 선택합니다.
- 문서 오른쪽 상단에 있는 피드백 버튼을 클릭합니다.
- 피드백을 제공하려는 텍스트 섹션을 강조 표시합니다.
- 강조 표시된 텍스트 옆에 있는 피드백 추가 대화 상자를 클릭합니다.
- 페이지 오른쪽에 있는 텍스트 상자에 피드백을 입력한 다음 제출을 클릭합니다.
피드백을 제출할 때마다 추적 문제가 자동으로 생성됩니다. 제출 을 클릭한 후 표시되는 링크를 열고 문제 모니터링을 시작하거나 의견을 더 추가합니다.
면책 조항:이 문서에 포함된 외부 웹 사이트 (s)는 편의를 위해 제공됩니다. Red Hat은 링크를 검토하지 않았으며 컨텐츠 또는 이용 가능 여부에 대해 책임을 지지 않습니다. 외부 웹 사이트에 대한 링크가 포함되어 있다고 해서 Red Hat이 해당 웹 사이트 또는 해당 엔티티, 제품, 서비스를 보증한다는 의미는 아닙니다. 사용자는 본인이 그러한 외부 사이트나 콘텐츠를 사용(또는 신뢰)하여 초래되는 어떠한 손실이나 비용에 대해 Red Hat이 어떠한 책임도 지지 않는 데 동의합니다.
1장. 소개
GCP Marketplace의 Ansible Automation Platform은 GCP Marketplace 포털에서 배포할 수 있는 제품입니다. GCP Marketplace의 Ansible Automation Platform은 Ansible 콘텐츠 컬렉션 라이브러리에 액세스할 수 있으며 주요 GCP 서비스와 통합되어 있으므로 인프라 및 애플리케이션의 배포, 구성 및 관리를 빠르게 자동화할 수 있습니다.
다음 Red Hat Ansible Automation Platform 구성 요소는 GCP Marketplace의 Ansible Automation Platform에서 사용할 수 있습니다.
현재 GCP Marketplace의 Ansible Automation Platform에서는 자동화 메시를 사용할 수 없습니다.
1.1. 애플리케이션 아키텍처
GCP Marketplace의 Red Hat Ansible Automation Platform은 GCP 계정 내에서 실행되는 인프라 리소스에 설치됩니다.

GCP Marketplace의 Ansible Automation Platform은 기본적으로 공용 액세스가 허용되지 않고 비공개로 설계되었습니다.
이를 위해서는 자체 네트워크 요구 사항 및 보안 관행에 따라 배포된 IB( Internal Load Balancer )를 직접 노출해야 합니다. ILB를 노출하는 몇 가지 잠재적 방법은 VPC Peering, Transit Gateway, VPN, External Load Balancers가 있습니다.
모든 클라우드 인프라 구성 요소는 VPC( Virtual Private Cloud )에 배포됩니다.
고객은 기존 VPC에 배포하는 것을 선택하거나 제품을 새 VPC를 배포하도록 할 수 있습니다. 모든 VM 인스턴스 및 클라우드 인프라에는 기본적으로 프라이빗 IP 주소(배포 시 지정된 VPC 및 서브네트워크에 의해 결정됨)가 있습니다.
모든 내부 트래픽은 배포 시 생성된 자체 서명된 인증서를 사용하여 암호화됩니다(제품에서 배포한 Internal Load Balancer에 자체 인증서를 배포하여 외부 트래픽도 암호화할 수 있습니다).
Ansible Automation Platform 소프트웨어는 배포된 VM 인스턴스에서 컨테이너로 실행됩니다.
관리 인스턴스 그룹 (MIG)은 VM 인스턴스 라이프사이클을 관리하고 VM 인스턴스에서 실행 중인 각 서비스의 상태를 모니터링하고 VM 인스턴스를 자동으로 순환하고 상태 점검이 실패하는 경우 새 VM 인스턴스로 교체하여 Ansible Automation Platform 서비스가 요청을 유지하고 사용할 수 있도록 합니다.
VM 인스턴스는 사용자 지정 RedHat Enterprise Linux (RHEL) Google Cloud Machine Image를 기본 이미지로 실행합니다. 이 Google Cloud Machine Image는 Ansible Automation Platform(자동화 허브, 자동화 컨트롤러 및 실행 노드 구성 요소)을 실행하기 위해 필요한 모든 컨테이너 이미지와 패키지가 미리 로드됩니다.
공유 GFS(Google File Store) 볼륨은 제품에 의해 프로비저닝된 각 VM 인스턴스에 마운트되며 공통 파일 및 리소스에 대한 공유 액세스에 사용됩니다.
Google Cloud SQL Service는 배포 시 제품에 의해 프로비저닝되며 자동화 컨트롤러와 자동화 허브를 위한 데이터베이스가 모두 포함되어 있습니다.

Foundation 제품에는 자동화 컨트롤러 구성 요소와 동일한 VM 인스턴스에서 실행되는 두 개의 실행 노드가 포함됩니다(Ansible Automation Platform에서 하이브리드 노드 구성이라고 함). 추가 실행 노드 제품을 구입하여 스케일링(관리 노드 수)을 늘릴 수 있습니다. Ansible Automation Platform 배포는 자동화할 수 있는 라이센스입니다. 기존 Ansible Automation Platform Foundation 배포에 실행 노드 제품을 배포할 때 추가 실행 노드 VM 인스턴스를 배포하고 자동화 작업 처리를 즉시 시작하는 Foundation 배포의 자동화 컨트롤러에 자동으로 연결할 수 있습니다.
Ansible Automation Platform 구성 요소는 VM 인스턴스에서 Podman 컨테이너 런타임을 사용하여 컨테이너로 실행됩니다. Podman 런타임 구성은 시스템 서비스로 관리되어 가동 시간 및 가용성을 보장하고 실패한 컨테이너를 자동으로 다시 시작합니다.
SELinux는 VM 인스턴스에서 활성화되며 컨테이너 수준에서 지원됩니다.
추가 운영 자동화는 registry.redhat.io에서 다운로드할 수 있는 별도의 Docker 컨테이너로 제공되는 오퍼링에서 제공합니다. 이러한 추가 운영 자동화에는 백업, 복원 및 업그레이드가 포함됩니다.
RHEL OS 기본 이미지, Ansible Automation Platform 컨테이너 또는 포함된 모든 패키지에 있는 CVE( Common Vulnerabilities and Exposures )는 모든 필수 소프트웨어, 패키지 및 컨테이너를 포함한 최신 버전으로 기본 RHEL Google Cloud Machine 이미지를 교체하여 Ansible Automation Platform 제품을 업그레이드하는 동안 해결됩니다.
이 작업은 포함된 업그레이드 자동화를 사용하여 자동으로 수행됩니다.
고객은 이러한 운영 자동화를 활용하여 자체 기업 표준 내에서 Ansible Automation Platform의 운영 준비를 단순화하여 Ansible Automation을 개발하는 데 집중하여 Ansible Automation Platform을 관리하는 데 시간을 소비하지 않고 자체 인프라 및 애플리케이션을 관리하는 데 집중할 수 있습니다.
1.2. 서비스 설명
| 서비스 이름 | 설명 |
|---|---|
| 컴퓨팅 엔진 | GCP VM 컴퓨팅 플랫폼 |
| Cloud SQL | GCP 데이터베이스 서비스 |
| 파일 저장소 | GCP 파일 스토리지 서비스 |
| 가상 사설 클라우드(VPC) | GCP 네트워킹 서비스 |
| 클라우드 모니터링 | GCP 지표 수집기 |
| 클라우드 로깅 | GCP 로그 관리 서비스 |
2장. 설치
2.1. 사전 요구 사항
Ansible Automation Platform을 설치하고 등록하기 전에 서비스 작동 방식, 데이터 저장 방법, 이러한 서비스를 사용하여 존재할 수 있는 개인 정보 보호 영향을 포함하여 GCP에 대해 잘 알고 있어야 합니다. 또한 GCP( Google Cloud Platform )로 계정을 설정해야 합니다.
Google Cloud Platform의 다음 측면에 대한 실무 지식이 있어야 합니다.
- GCP Marketplace에서 솔루션 배포
- 컴퓨팅 엔진 VM( 가상 머신 ) 인스턴스
- PostgreSQL용 Cloud SQL
- 파일 저장소
GPC Virtual Private Clouds (VPC)
- 서브넷
- 경로 테이블
- 로드 밸런서
네트워크 설계
- Hub-and-spoke 네트워킹 설계
- VPC 피어링
- CIDR( Class Inter-Domain Routing ) 블록
- 전송 라우팅
GCP 클라우드 모니터링
- GCP Ops 에이전트
- SSH
Google Cloud Platform 및 용어에 대한 자세한 내용은 GCP 제품 설명서 를 참조하십시오.
2.2. 프로젝트 생성
Ansible Automation Platform을 설치하려면 아직 없는 경우 애플리케이션을 호스팅할 Google Cloud Platform 계정에 프로젝트를 생성해야 합니다. GCP 문서의 프로젝트 생성 및 관리 단원을 참조하십시오.
2.2.1. 필수 API
GCP(Google Cloud Platform) 프로젝트에서 Ansible Automation Platform 설치를 완료하려면 여러 API 서비스에 액세스해야 합니다. Marketplace 배포에서 프로세스는 다음 API를 자동으로 활성화합니다.
원하는 경우 API를 미리 활성화하여 조직에서 허용되는지 확인할 수 있습니다.
| API 서비스 | 콘솔 서비스 이름 |
|---|---|
| 컴퓨팅 엔진 API |
|
| Google 클라우드 API |
|
| IAM(ID 및 액세스 관리) API |
|
| Cloud SQL Admin API |
|
| Cloud Logging API |
|
| 클라우드 모니터링 API |
|
| 클라우드 리소스 관리자 API |
|
| Cloud Identity-Aware Proxy API |
|
| Secret Manager API |
|
| 서비스 네트워킹 API |
|
| 서비스 사용량 API |
|
| OS Config API |
|
| 클라우드 런타임 구성 API |
|
| 클라우드 파일 저장소 API |
|
2.2.2. 서비스 계정 생성
GCP Marketplace에서 Ansible Automation Platform을 설정하려면 서비스 계정이 있어야 합니다. 이 계정은 애플리케이션을 설치 및 구성하는 데 사용되며 Ansible Automation Platform 가상 시스템과 연결된 상태로 유지됩니다. 필요한 역할과 함께 기존 서비스 계정을 사용하거나 Ansible Automation Platform 배포를 통해 사용자를 대신하여 필수 역할로 생성할 수 있습니다. 기존 계정을 사용하거나 서비스 계정을 미리 생성하는 경우 다음과 같은 역할이 있어야 합니다.
- 편집기
- logs Writer
- Cloud SQL Client
- 클라우드 SQL 인스턴스 사용자
- Secret Manager Secret Accessor
- 컴퓨팅 네트워크 관리자
기존 서비스 계정에 필요한 역할을 추가하는 단계는 단일 역할 부여 를 참조하십시오.
Compute Network Administrator 역할은 애플리케이션을 올바르게 구성하기 위해 배포 시에만 필요합니다. 설치 및 구성이 완료되면 이 역할은 Ansible Automation Platform 가상 머신에 구성된 서비스 계정에서 제거할 수 있습니다.
2.2.3. 정책 및 권한
애플리케이션 아키텍처에 설명된 리소스뿐만 아니라 Ansible Automation Platform 배포를 성공적으로 생성하고 관리하려면 GCP 계정에는 다음과 같은 IAM( Identity and Access Management ) 권한이 있어야 합니다.
GCP 계정은 GCP Marketplace에서 Ansible Automation Platform을 배포해야 합니다.
IAM 정책이 이러한 리소스의 배포 및 관리를 제한하는 경우 애플리케이션이 배포되지 않을 수 있습니다.
애플리케이션에는 다음 두 가지 배포 옵션이 있습니다.
- 새 VPC를 사용하여 배포를 생성합니다.
- 기존 VPC를 사용하여 배포를 생성합니다.
두 옵션 모두 동일한 최소 권한이 필요합니다.
Cloud SQL Client Cloud SQL Instance User Compute Network Admin Editor Logs Writer Secret Manager Secret Accessor
2.3. 애플리케이션 배포
Google Cloud Console에서 서비스를 시작하려면 시장으로 이동하여 Red Hat Ansible Automation Platform 2 - 최대 100개의 관리형 노드를 검색합니다. 이 제안을 선택한 후 시작 을 클릭합니다.
배포 이름 길이에 임시 아직 필요한 제약 조건이 배치되었습니다. 이는 Ansible Automation Platform 배포를 구성하는 내부 구성 요소의 GCP 이름 지정 스키마 때문입니다. 이 이름 지정 체계를 기반으로 하는 구성 요소 이름은 너무 길 수 있으며 다른 서비스에서 지정한 이름 지정 제약 조건을 중단하여 배포 오류가 발생할 수 있습니다.
배포 이름 및 GCP 프로젝트 이름의 길이는 35자 미만이어야 하며 배포 이름의 길이는 30자 미만이어야 합니다.
아래 계산은 프로젝트에서 Ansible Automation Platform 배포 이름의 최대 길이를 찾는 데 도움이 됩니다.
배포 이름 < = (30에서 35 사이의 최소) - length(gcp 프로젝트 이름)
애플리케이션을 배포하는 방법은 다음 두 가지가 있습니다.
2.3.1. 새 VPC를 사용하여 애플리케이션 배포
이 절차에서는 새 VPC 네트워크를 생성하고 생성된 VPC에 애플리케이션을 배포합니다.
절차
- 배포 페이지에서 서비스 사용량 API 확인 확인란을 선택합니다.
- API/서비스 세부 정보 탭에서 API가 활성화되어 있는지 확인한 다음 배포 페이지로 돌아갑니다.
- Confirm Service Usage API is enabled 확인란을 선택합니다.
- 서비스 계정을 선택하거나 생성합니다. 자세한 내용은 서비스 계정을 참조하십시오.
- Region 필드에서 애플리케이션을 배포할 리전을 선택합니다.
- 영역 필드에서 Filestore를 배포할 영역을 선택합니다. 영역은 선택한 지역에 있어야 합니다.
- Observability 섹션에서 Cloud Logging 및 Cloud Monitoring으로 전송되는 로깅 및 메트릭을 활성화할 수 있습니다. 이러한 서비스 활성화에 따른 재무 비용은 Operations Suite 를 참조하십시오. 이 기능 구성에 대한 자세한 내용은 모니터링 및 로깅 을 참조하십시오.
- 네트워크 선택 섹션에서 새 네트워크를 선택합니다. Networking 섹션에서는 배포에 사용되는 모든 네트워크 범위에 대한 기본값을 제공합니다. 이러한 값을 수정하려면 네트워킹 옵션을 참조하십시오.
- 선택 사항: 추가 라벨 섹션에서 배포의 일부인 GCP 리소스에 추가할 추가 라벨 키 및 값 쌍을 제공합니다. 유효한 키와 값은 GCP 레이블 요구 사항을 충족해야 합니다. 키 의 경우 하이픈, 밑줄, 소문자 및 숫자만 허용됩니다. 키는 소문자로 시작해야 합니다. 값 의 경우 하이픈, 밑줄, 소문자 및 숫자만 허용됩니다.
- DEPLOY 를 클릭합니다.
- Deployment Manager는 실행 중인 배포를 표시합니다.
- 애플리케이션은 프로비저닝을 시작합니다. 인프라와 애플리케이션이 완전히 프로비저닝되는 데 시간이 걸릴 수 있습니다.
배포에 대한 경고가 표시됩니다.
This deployment has resources from the Runtime Configurator service, which is in Beta
이 경고는 예상되며 우려의 원인이 아닙니다.
네트워크 범위를 수정하려면 현재 배포를 삭제해야 하며 기존 VPC를 사용하여 애플리케이션 배포 지침을 따르십시오.
2.3.2. 기존 VPC를 사용하여 애플리케이션 배포
다음 절차에서는 기존 VPC 네트워크를 사용하여 애플리케이션을 배포합니다.
절차
- 배포 페이지에서 서비스 사용량 API 확인 확인란을 선택합니다.
- API/Service Details 탭에서 API가 활성화되어 있는지 확인한 다음 Deployment 페이지로 돌아갑니다.
- Confirm Service Usage API is enabled 확인란을 선택합니다.
- 서비스 계정을 선택하거나 생성합니다. 자세한 내용은 서비스 계정을 참조하십시오.
- Region 필드에서 애플리케이션을 배포할 리전을 선택합니다.
- 영역 필드에서 Filestore를 배포할 영역을 선택합니다. 영역은 선택한 지역에 있어야 합니다.
- Observability 섹션에서 Cloud Logging 및 Cloud Monitoring으로 전송되는 로깅 및 메트릭을 활성화할 수 있습니다. 이러한 서비스 활성화에 따른 재무 비용은 Operations Suite 를 참조하십시오. 이 기능 구성에 대한 자세한 내용은 모니터링 및 로깅 을 참조하십시오.
- 네트워크 선택 섹션에서 기존 네트워크를 선택합니다.
Existing Network 섹션에서 기존 VPC 네트워크 이름, 기존 서브넷 이름 및 기존 프록시 서브넷 이름을 지정합니다.
참고기존 프록시 서브넷은 로드 밸런싱을 위해 예약된 프록시 전용 서브넷인 Regional Managed Proxy 여야 합니다.
Cloud NAT 라우터 를 선택하여 VPC 네트워크에서 NAT 라우터 를 생성합니다.
- Networking 섹션에서는 배포에 사용되는 모든 네트워크 범위에 대한 기본값을 제공합니다. 기존 네트워크 구성을 기반으로 이러한 값을 제공합니다. 이러한 값을 수정하려면 네트워킹 옵션을 참조하십시오.
- 선택 사항: 추가 라벨 섹션에서 배포의 일부인 GCP 리소스에 추가할 추가 라벨 키 및 값 쌍을 제공합니다. 유효한 키와 값은 GCP 레이블 요구 사항을 충족해야 합니다. 키 의 경우 하이픈, 밑줄, 소문자 및 숫자만 허용됩니다. 키는 소문자로 시작해야 합니다. 값 의 경우 하이픈, 밑줄, 소문자 및 숫자만 허용됩니다.
- DEPLOY 를 클릭합니다.
- Deployment Manager 에 실행 중인 배포가 표시됩니다.
애플리케이션은 프로비저닝을 시작합니다. 인프라와 애플리케이션이 완전히 프로비저닝되는 데 시간이 걸릴 수 있습니다.
참고배포에 경고가 표시됩니다.
This deployment has resources from the Runtime Configurator service, which is in Beta.
이 경고는 예상되며 우려의 원인이 아닙니다.
2.4. 배포 정보
Ansible Automation Platform을 배포한 후 다음 절차를 사용하여 배포에 대한 정보를 검색합니다.
2.4.1. 관리 암호 검색
다음 절차에 따라 관리 암호를 검색합니다.
절차
- GCP UI에서 메인 메뉴를 선택합니다.
- Security 를 선택합니다. 보안이 표시되지 않는 경우 모든 제품 보기 를 선택합니다.
- Secret Manager 를 선택합니다.
-
배포 이름으로 필터링합니다. 보안 이름 형식은 <
DeploymentName>-aap-admin입니다. - 배포의 시크릿 이름을 클릭합니다.
- 배포 행에서 More Actions 아이콘 Cryostat를 클릭합니다.
- 시크릿 값 보기 를 선택합니다. 관리 암호가 표시됩니다.
2.4.2. 로드 밸런서 주소 검색
다음 절차에 따라 컨트롤러 및 허브 IP 주소를 검색합니다.
절차
- GCP UI에서 메인 메뉴를 선택합니다.
- Deployment Manager 를 선택합니다.
- 배포를 선택합니다.
- 배포 이름을 선택합니다.
- View Details 를 선택합니다.
- 오른쪽 창에서 배포 속성에서 레이아웃 행을 찾습니다.
- 보기를 선택합니다. Outputs: 섹션에는 controllerIp 및 hubIp 이름에 대한 finalValue 가 표시됩니다.
2.5. 배포 시 모니터링 및 로깅 설정
절차
- GCP UI에서 Observability 로 이동합니다.
연결 로깅 및 연결 지표 확인란을 선택합니다.
참고이러한 확인란은 기본 배포에서만 사용할 수 있습니다.
2.6. 확장 노드 배포
공용 또는 개인 제안에서 확장을 구입하여 시작한 후 확장 노드를 구성합니다.
절차
- 배포 이름 필드에 애플리케이션 배포에 설명된 대로 충분히 짧은 이름을 입력합니다.
- 서비스 계정 의 경우 최대 100개의 관리형 노드 배포가 있는 Red Hat Ansible Automation Platform과 함께 사용되는 서비스 계정을 선택합니다.
- Region 필드에서 애플리케이션을 배포할 리전을 선택합니다.
- 영역 필드에서 기본 제공을 배포할 때 선택한 지역에서 영역을 선택합니다. 이 필드는 네트워크 목록을 필터링하는 데만 사용됩니다.
기본 배포 이름 필드에 확장을 배포하는 기본 배포 이름을 입력합니다.
참고기본 배포 이름은 필수 필드입니다.
- 네트워킹 섹션에서 기본 옵션을 확장합니다.
-
Network 필드에서
-aap-net으로 끝나는 기존 기본 네트워크를 선택합니다. Subnetwork 필드에서
-aap-subnet으로 끝나는 기존 기본 서브네트워크를 선택합니다.중요-aap-proxy-subnet으로 끝나는 서브넷을 선택하지 마십시오.- 선택한 VPC에서 Ansible Automation Platform 배포 확장이 선택되었는지 확인합니다.
- DEPLOY 를 클릭합니다.
- Deployment Manager는 실행 중인 배포를 표시합니다.
확장은 프로비저닝을 시작합니다.
인프라와 확장 기능을 완전히 프로비저닝하는 데 시간이 걸릴 수 있습니다.
3장. 확장 노드 배포
기본 배포는 기본적으로 두 개의 자동화 컨트롤러 노드와 하나의 자동화 허브 노드로 배포됩니다. 실행 노드를 추가하여 GCP Marketplace에서 Ansible Automation Platform을 확장할 수 있습니다. 확장 노드 제안을 혼합하여 Ansible Automation Platform 배포를 확장 및 확장할 수 있습니다.
새 확장 노드를 배포하기 전에 Ansible Automation Platform 배포 백업을 생성해야 합니다.
절차에는 다음 단계가 포함됩니다.
- 확장 노드의 제안 유형을 결정합니다.
- 확장 노드를 관리하려면 최소 권한이 충족되었는지 확인합니다.
-
ansible-on-clouds-ops컨테이너 이미지를 가져옵니다. -
ansible-on-clouds-ops컨테이너를 실행하여 데이터 파일을 생성합니다. - 데이터 파일을 채웁니다.
-
ansible-on-clouds-ops컨테이너를 실행하여 확장 노드를 배포합니다.
사전 요구 사항
- Linux 또는 macOS 시스템( ansible-on-clouds-ops 컨테이너 이미지가 실행되는 경우).
- Docker
3.1. 오퍼 유형 결정
다음 표에는 제공 유형 및 해당 GCP 인스턴스 유형이 나열되어 있습니다. 워크로드 요구 사항에 따라 확장 노드에 더 적합한 제공 유형을 선택할 수 있습니다.
| 유형 제공(노드) | GCP 인스턴스 유형 |
|---|---|
| 100 | n2-standard-2 |
| 200 | n2-standard-4 |
| 400 | n2-standard-8 |
확장 노드 제안을 혼합하고 함께 일치시켜 Ansible Automation Platform 배포를 확장할 수 있습니다.
3.2. IAM 최소 권한
Ansible Automation Platform에서 확장 노드를 성공적으로 생성하고 관리하려면 GCP 계정에 다음과 같은 IAM( Identity and Access Management ) 권한이 있어야 합니다.
GCP 계정은 GCP Marketplace에서 Ansible Automation Platform용 확장 노드 제안을 배포하도록 라이센스가 부여되어야 합니다.
Minimum Permissions - Cloud SQL Client Cloud SQL Instance User Editor Logs Writer Secret Manager Secret Accessor IAP-secured Tunnel User
3.3. ansible-on-clouds-ops 컨테이너 이미지 가져오기
배포 중인 버전과 동일한 태그를 사용하여 Clouds 운영 컨테이너에서 Ansible의 Docker 이미지를 가져옵니다.
docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
예를 들어 기본 배포 버전이 2.4.20230630-00인 경우 기본 배포에 확장 노드를 배포하려면 태그 2.4.20230630인 운영 이미지를 가져와야 합니다.
다음 명령을 사용합니다.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
3.4. ansible-on-clouds-ops 컨테이너를 실행하여 데이터 파일 생성
다음 명령은 필요한 데이터 파일을 생성합니다. 이러한 명령은 디렉터리와 확장 노드를 배포하는 동안 채워지는 빈 데이터 템플릿을 생성합니다.
절차
구성 파일을 저장할 폴더를 생성합니다.
$ mkdir command_generator_data
command_generator_data폴더를 구성 파일 템플릿으로 채웁니다.$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_add_extension_nodes \ --output-data-file /data/extra_vars.yml
이러한 명령은
command_generator_data/extra_vars.yml템플릿 파일을 생성합니다. 이 템플릿 파일은 다음과 유사합니다.gcp_add_extension_nodes: cloud_credentials_path: deployment_name: extra_vars: gcp_compute_region: gcp_extension_node_subscription: gcp_instance_group_name: gcp_instance_template_name: gcp_offer_type:
3.5. 데이터 파일 채우기
작업을 트리거하기 전에 데이터 파일을 채워야 합니다. 데이터 파일에 나열된 변수는 다음과 같습니다.
-
cloud_credentials_path는 Google Cloud 서비스 계정 자격 증명 파일의 경로입니다. 이는 절대 경로여야 합니다. -
deployment_name은 확장 노드를 생성할 AAP 배포 관리자 배포의 이름입니다. -
gcp_instance_group_name은 확장 노드에 생성할 GCP 인스턴스 그룹의 이름입니다. -
gcp_instance_template_name은 생성할 GCP 인스턴스 템플릿의 이름입니다. -
gcp_offer_type은 확장 노드의 제안 유형입니다. 100, 200 또는 400이어야 합니다. -
gcp_compute_region은 기반 배포가 배포된 GCP 리전입니다. 이는 Deployment Manager 의 Deployments 구성을 확인하여 검색할 수 있습니다. -
gcp_extension_node_subscription은 확장 노드 서브스크립션을 구매할지 여부를 확인하는 플래그입니다.true또는false여야 합니다.
3.6. 확장 노드 배포
절차
확장 노드를 배포하려면 명령 생성기를 실행하여 CLI 명령을 생성합니다.
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator --data-file /data/extra_vars.yml
다음 명령을 제공합니다.
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro / --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> / --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_add_extension_nodes / -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> / gcp_instance_group_name=<instance_group_name> gcp_offer_type=100 gcp_extension_node_subscription=True' ===============================================
제공된 명령을 실행하여 확장 노드를 추가합니다.
$ docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro / --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=leena1 / --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_add_extension_nodes / -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> / gcp_instance_group_name=<instance_group_name> gcp_offer_type=100 gcp_extension_node_subscription=True'
Playbook 실행이 완료되면 출력은 다음과 유사합니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_add_extension_nodes : [deploy_extension_nodes] Extension node created] *** ok: [localhost] => { "msg": "Extension node is created for deployment test-ext1." } PLAY RECAP ********************************************************************* localhost : ok=39 changed=5 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0
4장. 확장 노드 제거
확장 노드를 제거하기 전에 Ansible Automation Platform 배포 백업을 생성해야 합니다.
다음 단계에 따라 GCP Marketplace 환경에서 Ansible Automation Platform에서 실행 노드를 제거합니다.
사전 요구 사항
-
Linux 또는 macOS 시스템(
ansible-on-clouds-ops컨테이너 이미지가 실행되는 경우) - Docker
단계
-
ansible-on-clouds-ops컨테이너 이미지를 가져옵니다. - ansible-on-clouds-ops 컨테이너를 실행하여 데이터 파일을 생성합니다.
- 데이터 파일을 업데이트합니다.
-
ansible-on-clouds-ops컨테이너를 실행하여 확장 노드를 제거합니다.
4.1. ansible-on-clouds-ops 컨테이너 이미지 가져오기
기반 배포와 동일한 태그를 사용하여 Clouds 운영 컨테이너에서 Ansible의 Docker 이미지를 가져옵니다.
docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
예를 들어 기본 배포 버전이 2.4.20230630-00인 경우 기본 배포에 확장 노드를 배포하려면 태그 2.4.20230630인 운영 이미지를 가져와야 합니다.
다음 명령을 사용합니다.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
4.2. ansible-on-clouds-ops 컨테이너를 실행하여 데이터 파일 생성
다음 명령은 필요한 데이터 파일을 생성합니다. 이러한 명령은 디렉터리와 업그레이드 중에 채워지는 경우 사용되는 빈 데이터 템플릿을 생성합니다.
절차
구성 파일을 저장할 폴더를 생성합니다.
$ mkdir command_generator_data
$(pwd)/command_generator_data폴더를 구성 파일 템플릿으로 채웁니다.$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_remove_extension_nodes \ --output-data-file /data/extra_vars.yml
이러한 명령을 실행하면 command_generator_data/extra_vars.yml 템플릿 파일이 생성됩니다. 이 템플릿 파일은 다음과 유사합니다.
gcp_add_extension_nodes:
cloud_credentials_path:
deployment_name:
extra_vars:
gcp_compute_region:
gcp_instance_group_name:
gcp_instance_template_name:4.3. 데이터 파일 채우기
작업을 트리거하기 전에 데이터 파일을 채워야 합니다. 데이터 파일에 나열된 변수는 다음과 같습니다.
-
cloud_credentials_path는 Google Cloud 서비스 계정 자격 증명 파일의 경로입니다. 이는 절대 경로여야 합니다. -
deployment_name은 확장 노드를 생성할 배포의 이름입니다. -
gcp_instance_group_name은 확장 노드에 생성할 GCP 인스턴스 그룹의 이름입니다. -
gcp_instance_template_name은 생성할 GCP 인스턴스 템플릿의 이름입니다. -
gcp_compute_region은 기반 배포가 배포된 GCP 리전입니다. Deployment Manager에서 Deployments config를 확인하여 검색할 수 있습니다.
4.4. ansible-on-clouds-ops 컨테이너를 실행하여 확장 노드 제거
절차
확장 노드 세트를 제거하려면 명령 생성기를 실행하여 CLI 명령을 생성합니다.
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator --data-file /data/extra_vars.yml
명령 생성기 출력은 다음 명령을 제공합니다.
d----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_remove_extension_nodes \ -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> \ gcp_instance_group_name=<instance_group_name>' ===============================================
제공된 명령을 실행하여 확장 노드 세트를 제거합니다.
$ docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_remove_extension_nodes \ -e 'gcp_deployment_name=<deployment_name> gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_compute_region=<region> gcp_instance_template_name=<instance_template_name> \ gcp_instance_group_name=<instance_group_name>'
오류가 없으면 확장 노드가 성공적으로 제거됩니다.
5장. 네트워킹 및 애플리케이션 액세스
GCP Marketplace의 Ansible Automation Platform을 배포하면 격리된 VPC에 설치되어 액세스할 수 없습니다. 다음 지침에서는 Ansible Automation Platform에서 사용하는 VPC를 GCP Marketplace에서 기존 GCP 네트워크로 연결하는 방법을 설명합니다. 연결할 때 사용자가 Ansible Automation Platform에 연결하는 방법을 결정해야합니다.
사설 네트워크 액세스를 위해 VPN, Google Cloud Interconnect 또는 bastion 서버와 같은 이러한 연결을 활성화하는 방법에는 여러 가지가 있습니다. 로드 밸런서와 같은 GCP 서비스를 사용하여 공용 인터넷 액세스가 가능한 플랫폼을 노출할 수도 있습니다.
GCP에서 애플리케이션 액세스를 구성하는 방법은 GCP Marketplace의 Red Hat 지침 및 Ansible Automation Platform에 대한 지원 범위를 벗어납니다. 자세한 내용은 이러한 항목에 대한 지침은 Securely Connect to VMs for guidelines를 참조하십시오.
5.1. 네트워킹 옵션
GCP Marketplace의 Ansible Automation Platform의 네트워크 토폴로지에는 조직의 네트워크 요구 사항에 맞게 변경할 수 있는 몇 가지 구성 가능한 네트워크 세그먼트가 포함되어 있습니다.
배포에서 공용 인터넷 또는 기존 VPC 네트워크를 사용하여 액세스할 수 없는 새 VPC 및 서브넷을 생성합니다. 네트워킹 및 애플리케이션 액세스에 설명된 대로 애플리케이션에 대한 액세스를 제공해야 합니다.
아래에서 다음 네트워크 범위를 지정할 때 기존 네트워크 구성을 고려하십시오. 각 범위가 여기에 지정된 다른 범위와 겹치지 않고 네트워크의 기존 범위와 겹치지 않도록 합니다. 각 범위는 사설 네트워크 클래스 내에 있어야 합니다.
애플리케이션 서브넷 범위
서비스에서 배포한 사용자 지정 VPC에서 사용하는 서브넷 범위를 정의하는 네트워크 CIDR입니다. 최소 /24 세그먼트여야 하며 프라이빗 네트워크 범위(1922.168 또는 10.0)여야 합니다.
기본값: 192.168.240.0/24
Cloud SQL 피어링 네트워크 범위
네트워크 CIDR은 GCP CloudSQL 네트워크를 오퍼링에서 배포한 애플리케이션 서브넷으로 피어링하는 데 사용되는 네트워크 세그먼트를 정의합니다. /24 세그먼트여야 합니다. /24 세그먼트 범위는 GCP CloudSQL 네트워크 피어링 구성의 요구 사항입니다.
기본값: 192.168.241.0/24
파일 저장소 피어링 네트워크 범위
GCP Marketplace의 Ansible Automation Platform은 GCP Filestore 서비스를 사용하여 배포의 일부로 프로비저닝된 여러 자동화 컨트롤러 및 자동화 허브 VM 간에 구성 파일을 공유합니다. 이 네트워크 CIDR 범위는 제공에서 GCP Filestore 네트워크와 오퍼링의 사용자 지정 VPC 애플리케이션 서브넷 간에 피어링하는 데 사용하는 피어 네트워크를 정의합니다. 최소 /29 세그먼트여야 합니다.
기본값: 192.168.243.0/29
로드 밸런서 프록시 서브넷 범위
GCP Marketplace의 Ansible Automation Platform은 GCP의 기본 클라우드 기능을 사용하여 확장 가능하고 안정적인 설치를 제공합니다. GCP Marketplace 배포 토폴로지의 Ansible Automation Platform의 일부로 자동화 허브 및 자동화 컨트롤러 VM 앞에 두 개의 로드 밸런서가 배포됩니다. 모든 트래픽은 이러한 로드 밸런서에 전달되며 사용 가능한 백엔드 VM에 프록시됩니다. 배포에서는 GCP의 기본 부하 분산 지원을 활용하여 고객이 요청을 로드 밸런서에 추가하여 요청을 백엔드 VM에 캡처하고 전달할 수 있습니다. 이는 또한 신뢰성 향상을 위해 요청 밸런싱 및 세션 추적 기능을 제공합니다. 로드 밸런서 배포의 일부로 GCP는 GCP가 기본적으로 백엔드 VM에 대한 요청 리디렉션을 처리하는 특수 프록시 네트워크를 생성해야 합니다. 이 특수 프록시 네트워크는 GCP의 로드 밸런서의 프록시 네트워크 요구 사항 이외의 다른 용도로 GCP Marketplace의 Ansible Automation Platform 내에서 사용되지 않습니다. /24 세그먼트가 필요합니다.
기본값: 192.168.242.0/24
컨트롤러 내부 로드 밸런서 IP 주소
이는 자동화 컨트롤러 로드 밸런서에 할당된 고정 IP 주소입니다. 이 주소는 애플리케이션 서브넷 범위 세그먼트 내에 있어야 합니다.
기본값: 192.168.240.20
Hub 내부 로드 밸런서 IP 주소
이는 자동화 허브 Load Balancer에 할당된 고정 IP 주소입니다. 이 주소는 애플리케이션 서브넷 범위 세그먼트 내에 있어야 합니다.
기본값: 192.168.240.21
5.2. 네트워크 피어링 옵션
플랫폼에 액세스하기 위한 많은 네트워킹 구성이 가능하지만 다음 구성이 GCP Marketplace의 Ansible Automation Platform에서 작동하도록 검증되었습니다.
이 콘텐츠에 대한 Google Cloud Platform 문서에 맞게 모든 노력을 기울이지만 시간이 지남에 따라 정확도가 변동될 수 있습니다. GCP 설명서 를 GCP의 네트워킹 주제와 관련된 정보 소스로 사용합니다.
5.3. VPC 피어링
Ansible Automation Platform이 프라이빗 VPC에 상주하거나 Google Cloud Platform과 온-프레미스 네트워크 간에 라우팅되는 위치에 액세스하는 데 VPC 피어링 이 필요합니다. GCP 인프라 내에서 다양한 네트워크를 직접 연결하는 기능을 제공합니다. VPC는 서로 개별적으로 연결되어 있으며 다른 라우팅 홉은 없습니다. VPC 배포는 기본적으로 공용 인터넷에서 액세스를 생략합니다.
GCP Marketplace의 Ansible Automation Platform에서 사용하는 GCP 아키텍처의 배포 모델이기도 합니다.
이는 간단한 피어링 모델이며 여러 네트워크를 연결할 때 유용합니다.
복잡한 피어링을 구성할 수 있지만 시간이 지남에 따라 라우팅이 더 복잡해질 수 있습니다.
VPC 피어링 및 라우팅이 구성된 경우 연결된 VPC 서브넷의 VM을 통해 Ansible Automation Platform에 액세스하거나 조직에서 GCP와 로컬 네트워크 간에 전송 라우팅 설정이 설정된 경우 직접 액세스할 수 있습니다.
두 개 이상의 네트워크가 피어링되면 Google은 자동 작업을 수행하여 라우팅을 지원하지만 라우팅 가능한 업데이트를 수행하여 GCP 인프라 내에서 트래픽 흐름을 활성화할 수 있습니다.
사전 요구 사항
VPC 피어링을 사용하여 VPC를 연결하기 전에 GCP Marketplace의 VPC 주소 공간에서 VPC와 Ansible Automation Platform 간 트래픽을 라우팅하려는 네트워크 주소 공간이 겹치지 않도록 해야 합니다. GCP 포털은 이를 시도한 경우 피어링을 허용하지 않아야 합니다.
다음 절차에 따라 Ansible Automation Platform을 사용하여 VPC 피어링을 구성합니다.
절차
- GCP 포털에서 VPC 네트워크로 이동합니다.
- VPC 메뉴에서 VPC Network 피어링을 선택합니다.
- 피어링 연결 생성을 클릭합니다.
- 계속 을 클릭합니다.
- 이름 필드에 필요한 피어링 연결의 이름을 입력합니다.
- Your VPC Network 필드에서 피어하려는 첫 번째 VPC를 선택합니다.
Peered VPC Network 필드에서 피어할 두 번째 VPC를 선택합니다. GCP Marketplace VPC의 Ansible Automation Platform이어야 합니다.
- 이 두 네트워크 간의 서브넷 경로는 기본적으로 생성됩니다. 따라서 Ansible Automation Platform에 대한 액세스는 피어된 VPC에 있는 VM에서 발생할 수 있습니다. 그러나 hub-and-spoke 네트워크 모델과 같이 더 복잡한 라우팅이 있는 경우 다른 경로를 생성해야 합니다.
- 공용 IP를 사용하여 사용자 지정 경로 및 Exchange 서브넷 경로를 신중하게 선택합니다. Google에서는 각 필드가 무엇을 하는지에 대한 설명을 제공합니다. 선택 사항은 트래픽이 VPC를 통과하는 방식에 영향을 미칩니다. 일반적으로 이러한 확인란은 경로 테이블 교환을 통해 새로 피어링된 네트워크와 다른 네트워크 간의 라우팅을 구성하고 네트워크 트래픽이 여러 네트워크(전송 라우팅)를 통과할 수 있도록 합니다.
- 생성을 클릭합니다.
라우팅 테이블, 방화벽 및 VPC 피어링과 관련된 기타 네트워킹 구성 요소에 대한 자세한 내용은 GCP 설명서 를 참조하십시오.
5.4. 외부 로드 밸런서 사용
사용자가 인터넷에 연결된 시스템에서 플랫폼에 액세스하도록 하려면 Ansible 자동화 컨트롤러 및 Ansible 개인 자동화 허브를 공용 인터넷에 노출할 수 있습니다.
보안상의 이유로 이 방법을 모범 사례로 사용하지 않는 것이 좋습니다.
그러나 이 구현은 다른 GCP 툴로 보호할 수 있습니다. 이 섹션에서는 공용 인터넷에 직면하는 로드 밸런서를 연결하는 방법을 설명하지만 Google의 보안 제품을 통한 액세스 강화 단계는 포함하지 않습니다. Google Cloud 10.0.0.1or 또는 유사한 제품으로 공용 엔드 포인트를 보호하려는 경우에만 이 방법을 사용하십시오.
GCP Marketplace의 Ansible Automation Platform은 두 개의 내부 애플리케이션 로드 밸런서와 함께 배포됩니다. 이러한 로드 밸런서는 로컬 VPC 내에서 트래픽을 지시하며 공용 로드 밸런서를 구성하는 경우에도 배포의 일부로 남아 있어야 합니다.
절차
- 왼쪽 상단에서 주 메뉴를 선택합니다.
- Network Services 를 선택합니다. 네트워크 서비스가 표시되지 않으면 모든 제품 보기 를 선택합니다.
- Load Balancing 을 선택합니다.
- 상단 메뉴에서 Create LOAD BALANCER 를 선택합니다.
- 애플리케이션 로드 밸런서(HTTP/S) 타일을 선택하고 START CONFIGURATION 을 클릭합니다.
- 인터넷에서 내 VM 또는 서버리스 서비스 및 글로벌 외부 애플리케이션 로드 밸런서 를 선택합니다.
- 계속 을 클릭합니다.
-
로드 밸런서의 이름을 지정합니다(예: <
DeploymentName>-aap-<cntrlr/hub>-ext-lb). - 화면 왼쪽에서end 구성이 선택되어 있는지 확인합니다.
end 구성 페이지에서 다음 필드를 완료합니다.
- 프로토콜: HTTPS.
- 포트: 443.
- IP 주소: 기존 IP 주소를 선택하거나 새 IP 주소를 만듭니다.
- 인증서: 자체 SSL 인증서를 사용하거나 Google 관리 인증서를 사용할 수 있습니다.
SSL 정책: GCP 기본값 또는 다른 구성된 정책입니다.
참고자세한 내용은 SSL 인증서를 참조하십시오.
- DONE 을 클릭합니다.
- 왼쪽 메뉴에서 백엔드 구성을 선택합니다.
- 백엔드 서비스 및 백엔드 버킷 드롭다운을 클릭합니다.
CREATE A BACKEND SERVICE 를 클릭합니다.
-
백엔드 서비스에 이름을 지정합니다(예: <
DeploymentName>-aap-<cntrlr/hub>-ext-lb-bknd-svc). - 백엔드 유형을 인스턴스 그룹으로 설정합니다.
-
프로토콜 을
HTTPS로 설정하고https로 이름이 지정된 포트 를 설정합니다. -
시간 초과 를
86400으로 변경합니다. 백엔드 섹션까지 아래로 스크롤하고 새 백엔드 필드에서 인스턴스 그룹 드롭다운을 선택합니다. 올바른 인스턴스 그룹을 선택합니다.
자동화 컨트롤러 로드 밸런서의 경우 올바른 인스턴스 그룹에는 접미사
-aap-cntrlr-igm이 있습니다.자동화 허브 로드 밸런서의 경우 올바른 인스턴스 그룹에는 접미사
-aap-hub-igm이 있습니다.- 결과 대화 상자에서 USE EXISTING PORT NAME 을 선택합니다.
- Balancing mode 를 Rate 로 설정합니다.
- 최대 RPS 를 300으로 설정합니다.
- Cloud CDN 이 표시될 때까지 아래로 스크롤합니다. Cloud CDN 의 확인란을 선택 해제합니다.
- Health 확인란 을 표시하는 텍스트 상자가 표시될 때까지 아래로 스크롤합니다.
- 드롭다운 메뉴를 선택하고 Create A HEALTH CHECK 를 클릭합니다.
-
상태 점검의 이름을 입력합니다(예: <
DeploymentName>-aap-<cntrlr/hub>-ext-lb-hc). 자동화 컨트롤러의 경우 다음 상태 점검 설정을 사용하십시오.
-
상태 점검 대화 상자에서 프로토콜 을
HTTPS로 설정하고 포트 를8052로 설정합니다. -
Request 를
/api/v2/ping/로 설정합니다.
-
상태 점검 대화 상자에서 프로토콜 을
자동화 허브의 경우 다음 상태 점검 설정을 사용하십시오.
-
상태 점검 대화 상자에서 프로토콜 을
HTTPS로 설정하고8080으로 포트 를 설정합니다. -
Request 를
/api/galaxy/pulp/api/v3/status/로 설정합니다.
-
상태 점검 대화 상자에서 프로토콜 을
- 아래로 스크롤하여 상태 기준 섹션까지 아래로 스크롤합니다.
- Check interval 필드에 값 15를 입력합니다.
- 시간 초과 필드에 값 10을 입력합니다.
- Healthy threshold 필드에 값 2를 입력합니다.
- Unhealthy threshold 필드에 값 10을 입력합니다.
CloudEvent 를 클릭합니다.
그러면 백엔드 서비스 및 백엔드 버킷 창으로 돌아갑니다.
CREATE 를 클릭합니다.
그러면 백엔드 구성 섹션으로 돌아갑니다.
- OK를 클릭합니다.
- CREATE 를 클릭하여 자동화 컨트롤러 또는 자동화 허브 UI에 대한 로드 밸런서를 생성합니다. 이 작업을 완료하는 데 몇 분이 걸립니다.
-
백엔드 서비스에 이름을 지정합니다(예: <
- 이제 로드 밸런서가 생성되었습니다.
- 로드 밸런서의 IP 주소를 가리키도록 SSL 인증서에서 사용한 도메인의 DNS 레코드를 구성합니다.
이 시점에서 Ansible Automation Platform 자동화 컨트롤러 UI에 액세스할 수 있어야 합니다. 관리 암호를 검색한 후 로그인할 수 있습니다.
프라이빗 자동화 허브에 대해 동일한 프로세스를 반복합니다. 백엔드 구성 중 인스턴스 그룹 -aap-hub-igm 을 선택하는 경우를 제외하고 프로세스는 동일합니다.
6장. 추가 구성
다음 장에서는 GCP에서 배포가 완료되면 수행할 수 있는 Ansible Automation Platform 구성 단계를 설명합니다.
6.1. 기본 관리자 암호 변경
GCP Marketplace에서 Ansible Automation Platform이 배포되면 Ansible Automation Platform의 기본 관리자 암호가 무작위로 생성됩니다. 다음 단계에 따라 자동화 컨트롤러 및 자동화 허브의 관리자 암호를 변경합니다.
절차
GCP Secrets Manager 콘솔로 이동합니다.
-
<
deployment_name> -aap-admin이라는 이름으로 Ansible Automation Platform 배포의 시크릿을 찾아 엽니다. - 새 버전을 추가하려면 새 VERSION 을 선택합니다.
- 암호 시크릿 값을 입력합니다.
- 이전 버전 모두 비활성화 확인란을 선택합니다.
- ADD NEW VERSION 을 클릭합니다.
-
<
새 관리자 암호를 사용하도록 실행 중인 Ansible Automation Platform VM 인스턴스를 변경합니다.
- GCP VM Instances 콘솔로 이동합니다.
- Ansible Automation Platform 배포를 위한 하나의 자동화 컨트롤러 VM 인스턴스와 하나의 자동화 허브 VM 인스턴스를 식별 및 삭제합니다.
- 자동화 컨트롤러 및 자동화 허브 인스턴스 그룹이 새 VM 인스턴스를 생성할 때까지 기다립니다.
- 새 자동화 컨트롤러 및 자동화 허브 VM 인스턴스가 실행 중인 인스턴스 상태에 도달할 때 새 관리자 암호를 사용할 수 있습니다.
6.2. 자동화 컨트롤러 및 자동화 허브 VM 인스턴스 SSL/TLS 인증서 및 키 교체
기본적으로 VM 인스턴스는 유효 기간이 10년인 자체 서명된 SSL/TLS 인증서로 보호됩니다. 인증서가 만료되거나 VM 인스턴스가 자체 인증서를 사용하도록 하려면 SSL/TLS 인증서 및 키를 교체해야 합니다.
절차
GCP Secrets Manager 콘솔로 이동합니다.
-
<deployment_name>
-pulp_cert라는 이름으로 Ansible Automation Platform 배포의 시크릿을 찾아 엽니다. - 새 버전을 추가하려면 새 VERSION 을 선택합니다.
- 새 SSL/TLS 인증서 값을 입력합니다.
- 이전 버전 모두 비활성화 확인란을 선택합니다.
- ADD NEW VERSION 을 클릭합니다.
-
<deployment_name>
GCP Secrets Manager 콘솔로 이동합니다.
-
<deployment_name>
-pulp_key 라는 이름으로 Ansible Automation Platform 배포의 시크릿을 찾아 엽니다. - 새 버전을 추가하려면 새 VERSION 을 선택합니다.
- 새 SSL/TLS 키 값을 입력합니다.
- 이전 버전 모두 비활성화 확인란을 선택합니다.
- ADD NEW VERSION 을 클릭합니다.
-
<deployment_name>
새 SSL/TLS 인증서 및 키를 사용하도록 실행 중인 Ansible Automation Platform VM 인스턴스를 변경합니다.
- GCP VM Instances 콘솔로 이동합니다.
- Ansible Automation Platform 배포를 위한 모든 자동화 컨트롤러 및 자동화 허브 VM 인스턴스를 식별하고 삭제합니다.
- 자동화 컨트롤러 및 자동화 허브 인스턴스 그룹이 새 VM 인스턴스를 생성할 때까지 기다립니다.
- 새 자동화 컨트롤러 및 자동화 허브 VM 인스턴스가 실행 중인 인스턴스 상태에 도달하면 새 인증서가 사용 중입니다.
6.3. SSL을 사용하여 내부 통신 보안
GCP Marketplace의 Ansible Automation Platform은 각각 허브 및 컨트롤러 인스턴스 앞에 하나씩 두 개의 내부 애플리케이션 로드 밸런서와 함께 배포됩니다. 이러한 내부 로드 밸런서는 배포가 완료된 후 SSL 인증서로 구성해야 합니다.
이러한 내부 로드 밸런서를 통해 트래픽을 보호하는 것은 이전 단계에서 외부 로드 밸런서를 통해 트래픽을 보호하는 것과 다릅니다. 이 프로세스는 트래픽이 프라이빗 GCP VPC로 지역화되어도 HTTP 트래픽이 암호화됩니다. 자동화 컨트롤러 및 자동화 허브 로드 밸런서 둘 다에 대해 동일한 절차를 따를 수 있습니다.
이름 형식 < DEPLOYMENT_NAME>-aap-<cntrlr/hub>-int-lb 인 자동화 컨트롤러 및 자동화 허브 로드 밸런서를 모두 수정하려면 다음을 수행합니다.
절차
다음 명령을 사용하여 자동화 컨트롤러 또는 자동화 허브 인증서를 생성합니다.
$ openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 365
- GCP 콘솔에서 로드 밸런싱 페이지로 이동합니다.
- 검색 창에 로드 밸런서로 필터링할 배포 이름을 입력합니다.
-
<
DEPLOYMENT_NAME>-aap-<cntrlr/hub>-int-lb를 클릭합니다. - 편집 을 클릭합니다.
- end 구성을 클릭합니다.
ADD FRONTEND IP and PORT를 클릭합니다. 다음 값을 사용합니다.
- protocol: HTTPS(HTTP/2 포함).
- 서브네트워크: 사용 가능한 aap-subnet을 선택합니다.
- 포트: 443
-
IP 주소: <
DEPLOYMENT_NAME>-aap<cntrlr/hub>-intl-lb-ip
이미 인증서를 추가한 경우 선택합니다.
- 인증서를 추가하지 않은 경우 Create A NEWNARTIFICATE를 클릭합니다.
- 인증서 이름을 입력합니다.
-
이전에 생성된 인증서를 사용하여
cert.pem콘텐츠를 복사하여 인증서 아래에 붙여넣습니다. -
이전에 생성된 인증서 키를 사용하여
key.pem콘텐츠를 복사하여 개인 키 에 붙여넣습니다. - 생성을 클릭합니다.
- Done 을 클릭합니다.
선택 사항: HTTP 10.0.0.1end 구성을 삭제하려면 다음을 수행합니다.
- 로드 밸런서 인스턴스를 엽니다.
- UI 왼쪽에 구성이 표시됩니다.
- 삭제할 구성으로 스크롤합니다.
- trashcan 아이콘을 클릭하여 구성을 삭제합니다.
- 업데이트를 클릭하고 업데이트를 확인합니다.
6.4. 보안 고려 사항
MFA( Multi factor Authentication )를 활성화할 수 있는 ID 공급자를 사용하여 Red Hat Single Sign-On을 구성하려면 Ansible Automation Platform에 엔터프라이즈 인증 연결을 위한 단계를 따르십시오. https://docs.ansible.com/automation-controller/latest/html/administration/ent_auth.html
인프라 서비스 보안은 모든 클라우드 배포에서 중요한 단계입니다. GCP Marketplace 배포의 Ansible Automation Platform의 일부로 사용되는 서비스에 대한 GCP 문서 의 구현 및 보안 제안을 따릅니다.
7장. 명령 생성기
명령 생성기는 Ansible-on-clouds 작동 플레이북 컬렉션에서 제공하는 운영 플레이북을 시작하기 위한 명령을 생성하는 데 사용됩니다.
이 프로세스는 5단계로 구성됩니다.
-
ansible-on-clouds-ops컨테이너 이미지를 가져옵니다. - 사용 가능한 플레이북을 나열합니다.
-
명령 생성기를 사용하여 실행할 데이터 파일 및 다음 명령을 생성합니다.
command_generator_vars및 command_generator는 docker 컨테이너를 사용하여 구현되며 docker 명령줄 인터페이스를 사용하여 실행됩니다. 데이터 파일을 채우고 이전에 생성된 명령을 실행합니다. 이렇게 하면 모든 매개변수가 포함된 최종 명령이 생성됩니다.
참고이 단계가 완료되면 생성된 명령을 저장하고 필요한 경우 플레이북을 실행할 수 있습니다.
- 최종 명령을 실행합니다.
사전 요구 사항
- Docker
- GCP 인증 정보 파일
- Google Cloud에 대한 인터넷 연결
7.1. ansible-on-clouds-ops 컨테이너 이미지 가져오기
배포와 동일한 태그 버전을 사용하여 Clouds 운영 컨테이너에서 Ansible의 Docker 이미지를 가져옵니다.
docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
예를 들어 기본 배포 버전이 2.4.20230630-00인 경우 태그 2.4.20230630을 사용하여 운영 이미지를 가져와야 합니다.
다음 명령을 사용합니다.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
7.2. 사용 가능한 플레이북 나열
절차
세부 정보 없이 사용 가능한 플레이북 목록에 대해 다음 명령을 사용합니다.
$ docker run --rm $IMAGE command_generator_vars | grep Playbook The current version of the operational playbooks collection contains the following playbooks: Playbook: aws_add_extension_nodes Playbook: aws_add_labels Playbook: aws_backup_delete Playbook: aws_backup_stack Playbook: aws_backups_delete Playbook: aws_check_aoc_version Playbook: aws_deployment_inventory Playbook: aws_get_aoc_version Playbook: aws_remove_extension_nodes Playbook: aws_remove_labels Playbook: aws_restore_stack Playbook: aws_upgrade Playbook: gcp_aap_health_check Playbook: gcp_add_extension_nodes Playbook: gcp_add_labels Playbook: gcp_backup_delete Playbook: gcp_backup_deployment Playbook: gcp_backup_list Playbook: gcp_backups_delete Playbook: gcp_check_aoc_version Playbook: gcp_deployment_inventory Playbook: gcp_get_aoc_version Playbook: gcp_health_check Playbook: gcp_list_deployments Playbook: gcp_nodes_health_check Playbook: gcp_remove_extension_nodes Playbook: gcp_remove_labels Playbook: gcp_restore_deployment Playbook: gcp_setup_logging_monitoring Playbook: gcp_upgrade
사용 가능한 모든 플레이북 목록을 제공하고 명령 생성기를 사용하려면 다음 명령을 사용합니다.
$ docker run --rm $IMAGE command_generator_vars
그러면 다음과 유사한 플레이북 및 명령 목록이 제공됩니다.
=============================================== Playbook: gcp_upgrade Description: Performs the upgrade of the Ansible Automation Platform from GCP Marketplace components to the latest version. ----------------------------------------------- Performs the upgrade of the Ansible Automation Platform from GCP Marketplace components to the latest version. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_upgrade [--ansible-config ansible_config_path>] \ -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_backup_taken=<true|false>' ===============================================
7.3. 데이터 파일 생성
절차
명령 생성기를 실행합니다.
$ docker run --rm -v <local_directory_data_file>:/data $IMAGE command_generator_vars <playbook_name> --output-data-file /data/<data-file>.yml
이 명령의 출력은 실행할 명령과 데이터 파일 템플릿입니다. 데이터 파일은 <
local_data_file_directory>에도 저장됩니다. 이 템플릿은 데이터로 채우는 템플릿입니다.다음 예제에서는
gcp_backup_deployment플레이북을 사용합니다.$ docker run --rm -v <local_data_file_directory>:/data $IMAGE command_generator_vars gcp_backup_deployment \ --output-data-file /data/backup.yml
다음 출력을 생성합니다.
=============================================== Playbook: gcp_backup_deployment Description: This playbook is used to backup the AoC Self-managed GCP environment. ----------------------------------------------- This playbook is used to backup the AoC Self-managed GCP environment. For more information regarding backup and restore, visit our official documentation - ----------------------------------------------- Command generator template: docker run --rm -v /tmp:/data $IMAGE command_generator gcp_backup_deployment --data-file /data/backup.yml Data template: gcp_backup_deployment: cloud_credentials_path: deployment_name: extra_vars: gcp_bucket_backup_name: gcp_compute_region: gcp_compute_zone: ===============================================
7.4. 데이터 파일 채우기
절차
데이터 파일 생성에서 생성된 데이터 파일을 편집합니다.
경로를 나타내는 모든 속성은 절대 경로여야 합니다.
command_generator는 최종 명령에 볼륨을 자동으로 마운트합니다.예를 들어
gcp_backup_deployment플레이북의 경우 파일은 다음이 됩니다.gcp_backup_deployment cloud_credentials_path: /path/to/credentials deployment_name: my-deployment extra_vars: cp_bucket_backup_name: my-bucket gcp_compute_region: us-east1 gcp_compute_zone: us-east1-b
7.5. 생성된 명령 실행
절차
마운트된 볼륨이 데이터 파일이 있는 디렉터리를 가리키는지 확인합니다.
gcp_backup_deployment플레이북의 예는 다음과 같습니다.$ docker run --rm -v /tmp:/data $IMAGE command_generator gcp_backup_deployment --data-file /data/backup.yml
다음 출력을 생성하는 방법은 다음과 같습니다.
Command to run playbook: $ docker run --rm --env PLATFORM=GCP -v /path/to/credentials:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE\ redhat.ansible_on_clouds.gcp_backup_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=my-deployment gcp_compute_region=us-east1 gcp_compute_zone=us-east1-b'
이 새 명령에는 플레이북을 실행하는 데 필요한 매개 변수, 환경 변수 및 마운트된 볼륨이 있습니다.
- 생성된 명령을 실행합니다. 필요한 경우 이 명령을 저장하여 나중에 다시 실행할 수 있습니다.
7.6. Playbook 사용
일부 플레이북은 이 문서에 설명되어 있지만 일부 플레이북은 설명되지 않습니다. 여기에서는 클라우드의 Ansible 배포에서 정보를 검색하거나 설명이 있는지 확인하는 데 사용되는 정보입니다. 이러한 플레이북은 배포를 수정하지 않습니다.
gcp_aap_health_check
이 플레이북은 Ansible 애플리케이션이 정상인지 확인합니다.
$ docker run --rm $IMAGE command_generator_vars gcp_aap_health_check
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_aap_health_check Description: This playbook checks if the deployment is healthy using the Ansible health service. ----------------------------------------------- The health check consists of checking the Ansible Automation Platform from GCP Marketplace environemnt to verify it is healthy. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_aap_health_check [--ansible-config ansible_config_path>] -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone>' ===============================================
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
... PLAY RECAP ********************************************************************* localhost : ok=29 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
0 과 같지 않으면 Ansible이 클라우드 배포에서 문제가 있음을 나타냅니다.
gcp_add_labels
이 플레이북은 배포에 레이블을 추가합니다.
$ docker run --rm $IMAGE command_generator_vars gcp_add_labels
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_add_labels Description: This playbook adds labels to the deployment. ----------------------------------------------- Add labels to the Ansible Automation Platform from GCP Marketplace deployment. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_add_labels -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_labels=<gcp_labels>' ===============================================
gcp_labels 매개변수는 추가하거나 업데이트할 키=값 쌍으로 이루어진 쉼표로 구분된 목록입니다. 예: key1=value1,key2=value2
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
... PLAY RECAP ********************************************************************* localhost : ok=22 changed=2 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
gcp_remove_labels
이 플레이북은 배포에서 레이블을 제거합니다.
$ docker run --rm $IMAGE command_generator_vars gcp_remove_labels
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_remove_labels Description: This playbook removes labels from the deployment. ----------------------------------------------- Remove labels from the Ansible Automation Platform from GCP Marketplace deployment. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_remove_labels -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_labels=<gcp_labels>' ===============================================
gcp_labels 매개변수는 제거할 쉼표로 구분된 키 목록입니다. 예: key1,key2
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
... PLAY RECAP ********************************************************************* localhost : ok=22 changed=2 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
gcp_check_aoc_version
이 플레이북은 Cloud 버전의 Ansible이 명령 생성기 컨테이너와 같은지 확인합니다. 이 검사는 플레이북이 호출될 때마다 수행됩니다.
$ docker run --rm $IMAGE command_generator_vars gcp_check_aoc_version
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_check_aoc_version Description: Check the operational container version matches the Ansible on Clouds version. ----------------------------------------------- Check the operational container version matches the Ansible on Clouds version. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_check_aoc_version [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> ===============================================
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
...
TASK [redhat.ansible_on_clouds.standalone_check_aoc_version : Verify operational playbook and Ansible on Clouds deployment versions] ***
ok: [localhost] => {
"changed": false,
"msg": "This operation playbook version and the Ansible on Clouds deployment version are identical: 2.4.20230606-00"
}
PLAY RECAP *********************************************************************
localhost : ok=8 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
실패한 0은 Clouds 배포 버전의 Ansible이 command_generator 컨테이너와 일치하지 않으며 명령 생성기가 해당 배포를 관리하는 데 다른 버전이 필요함을 의미합니다.
gcp_get_aoc_version
이 플레이북은 Clouds 배포에서 Ansible 버전을 검색합니다.
$ docker run --rm $IMAGE command_generator_vars gcp_get_aoc_version
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_get_aoc_version Description: Get the current Ansible on Clouds version. ----------------------------------------------- Get the current Ansible on Clouds version. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_get_aoc_version [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> ===============================================
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
...
TASK [Print version] ***********************************************************
ok: [localhost] => {
"msg": "The AOC version is 2.4.20230606-00"
}
PLAY RECAP *********************************************************************
localhost : ok=5 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0gcp_health_check
이 플레이북은 노드와 Ansible 애플리케이션이 정상인지 확인합니다.
$ docker run --rm $IMAGE command_generator_vars gcp_health_check
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_health_check Description: This playbook checks if the Ansible Automation Platform from GCP Marketplace deployment is healthy. ----------------------------------------------- The health check consists of checking the Ansible Automation Platform from GCP Marketplace heatlh checks and the health of the monitoring exporter. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_health_check [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone>' ===============================================
매개변수를 교체하여 이 명령을 시작하면 시작할 새 명령이 생성되고 출력됩니다.
... PLAY RECAP ********************************************************************* localhost : ok=47 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
0 과 같지 않으면 클라우드 배포에서 노드 또는 Ansible에 문제가 있음을 나타냅니다.
gcp_list_deployments
이 Playbook은 배포, 지역 및 영역은 선택 사항입니다.
$ docker run --rm $IMAGE command_generator_vars gcp_list_deployments
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_list_deployments Description: This playbook generates a list of available Ansible Automation Platform from GCP Marketplace deployments. ----------------------------------------------- This playbook is used to generate a list of available Ansible Automation Platform from GCP Marketplace deployments. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_list_deployments -c <cloud_credentials_path> --extra-vars '[gcp_compute_region=<gcp_compute_region>] [gcp_compute_zone=<gcp_compute_zone>]' ===============================================
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
...
TASK [Show deployment list] ****************************************************
ok: [localhost] => {
"msg": [
"Deployment list: ['dep1', 'dep2', 'dep3']"
]
}
PLAY RECAP *********************************************************************
localhost : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0gcp_nodes_health_check
이 플레이북은 노드가 정상인지 확인합니다.
$ docker run --rm $IMAGE command_generator_vars gcp_nodes_health_check
다음 출력을 생성하는 방법은 다음과 같습니다.
=============================================== Playbook: gcp_nodes_health_check Description: This role runs a health check on a group of nodes in the Ansible Automation Platform from GCP Marketplace deployment ----------------------------------------------- The playbook checks if the Ansible Automation Platform from GCP Marketplace monitoring exporter is up and running. ----------------------------------------------- Command generator template: docker run --rm $IMAGE command_generator gcp_nodes_health_check [--ansible-config ansible_config_path>] -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'check_monitoring=True' ===============================================
매개변수를 교체하여 이 명령을 시작하면 시작 및 출력할 새 명령이 생성됩니다.
... PLAY RECAP ********************************************************************* localhost : ok=47 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
0 과 일치하지 않으면 배포 중 노드에서 문제가 있음을 나타냅니다.
8장. 자동화 워크로드
GCP Marketplace의 기본 Ansible Automation Platform은 100개의 관리형 노드를 자동화하도록 설계 및 라이센스됩니다.
8.1. 자동화 성능
제안에서 라이센스가 부여된 관리형 노드 할당에 대한 자동화가 다음과 같은 운영 예상과 함께 제공됩니다. 이러한 기준의 범위를 벗어난 자동화는 지원되지 않지만 자동화에 따라 계속 작동할 수 있습니다.
| 메트릭 | 임계값 |
|---|---|
| 동시 작업 | 10 |
| 작업당 포크 | 10 |
GCP Marketplace의 Ansible Automation Platform은 자동화 컨트롤러와 자동화 허브를 실행하는 세 개의 n2-standard-2 인스턴스를 사용합니다. 자동화 컨트롤러 인스턴스는 100개의 관리형 활성 노드에 대한 표준 워크로드를 전체적으로 지원합니다. Red Hat은 이를 테스트하여 각각 10개의 포크에 대한 지원이 있음을 증명했습니다. 이 운영 기준이 두 자동화 컨트롤러 노드에서 7초 간격으로 2초 동안 생성되는 출력 집약적인 "chatty" 워크로드를 사용하여 설정 및 테스트되었습니다. I/O 집약적인 워크로드는 이러한 조건의 범위 내에서 작동하지 않을 수 있으며 이러한 자동화를 지원하기 위해 배포를 확장하기 위해 확장 노드를 사용해야 할 수 있습니다.
8.2. 배포 스케일링
지원되는 초기 관리 노드 수를 초과하여 배포를 확장하려면 별도로 판매된 확장 노드를 사용하여 GCP Marketplace의 Ansible Automation Platform을 수동으로 확장할 수 있습니다.
확장 노드는 즉각적인 확장 요구 사항에 따라 확장 또는 확장에 배포할 수 있는 추가 컴퓨팅 인스턴스입니다. 요구 사항이 더 높은 병렬 자동화 작업을 위한 경우, 시간이 지남에 따라 더 많은 노드를 자동화해야 하는 요구 사항이 있는 경우 확장되는 컴퓨팅 셰이프를 선택할 수 있는 반면, 확장되는 컴퓨팅을 선택할 수 있습니다.
확장 노드는 GCP Marketplace에서 Ansible Automation Platform의 기능을 확장하는 지원되는 방법입니다.
Red Hat은 고객 설계 및 구현을 통해 확장되는 환경을 지원하지 않습니다.
9장. 모니터링 및 로깅
Google Cloud Platform UI에서 시각화할 수 있는 Google Cloud Platform 모니터링 시스템으로 메트릭을 보낼 수 있습니다. GCP Marketplace 지표 및 로깅의 Ansible Automation Platform은 이러한 메트릭을 GCP로 보내는 비용이 있기 때문에 기본적으로 비활성화되어 있습니다. 자세한 내용은 Cloud Monitoring 및 Cloud Logging 을 각각 참조하십시오.
GCP 모니터링 및 로깅을 설정할 수 있습니다.
- 배포 시 배포 시 모니터링 및 로깅 설정을 참조하십시오.
- 배포 후
9.1. 배포 후 모니터링 및 로깅 설정
registry.redhat.com에서 사용할 수 있는 gcp_setup_logging_monitoring 플레이북을 사용하여 배포 후 로깅 및 모니터링을 시작하거나 중지할 수 있습니다.
9.1.1. 필요한 권한
로깅 및 모니터링을 설정하려면 다음과 같은 GCP IAM 권한이 있어야 합니다.
required-roles: Service Account User Compute Instance Admin (v1) required-permissions: cloudsql.instances.connect cloudsql.instances.get cloudsql.instances.login cloudsql.users.update compute.addresses.get compute.addresses.list compute.instances.delete compute.instances.get compute.instances.list compute.instances.setLabels compute.zoneOperations.get deploymentmanager.deployments.list deploymentmanager.manifests.get deploymentmanager.manifests.list file.instances.get file.instances.list file.instances.update file.operations.get iap.tunnelInstances.accessViaIAP logging.logEntries.create monitoring.timeSeries.create resourcemanager.projects.get runtimeconfig.variables.create runtimeconfig.variables.get runtimeconfig.variables.list runtimeconfig.variables.update secretmanager.secrets.create secretmanager.secrets.delete secretmanager.secrets.get secretmanager.versions.add secretmanager.versions.get secretmanager.versions.list servicenetworking.operations.get servicenetworking.services.addPeering serviceusage.services.list
9.1.2. ansible-on-clouds-ops 컨테이너 이미지 가져오기
Clouds 운영 컨테이너에서 Ansible의 Docker 이미지를 가져와 기반 배포 버전에 맞게 조정합니다.
docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
예를 들어 기본 배포 버전이 2.4.20230630-00인 경우 태그 2.4.20230630을 사용하여 운영 이미지를 가져와야 합니다.
다음 명령을 사용합니다.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
9.1.3. ansible-on-clouds-ops 컨테이너를 실행하여 데이터 파일 생성
다음 명령은 필요한 데이터 파일을 생성합니다. 이러한 명령은 디렉터리를 생성하고, 채워지면 플레이북을 생성하는 데 사용되는 빈 데이터 템플릿을 생성합니다.
절차
구성 파일을 저장할 폴더를 생성합니다.
$ mkdir command_generator_data
command_generator_data폴더를 구성 파일 템플릿으로 채웁니다.참고Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로
root:root에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후sudo chmod명령을 실행할 수 있습니다. 자세한 내용은 root가 소유한 명령 생성기 - Linux 파일을 참조하십시오.$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_setup_logging_monitoring \ --output-data-file /data/logging-monitoring.yml
이러한 명령을 실행하면
command_generator_data/logging-monitoring.yml템플릿 파일이 생성됩니다.참고다음 예제 파일에서
ansible_config_path는 선택 사항입니다.이 템플릿 파일은 다음과 유사합니다.
gcp_setup_logging_monitoring: ansible_config_path: cloud_credentials_path: deployment_name: extra_vars: components: default_collector_interval: logging_enabled: monitoring_enabled:
9.1.4. 데이터 파일 업데이트
매개변수가 필요하지 않은 경우 구성 파일에서 해당 매개변수를 제거합니다.
절차
-
command_generator_data/logging-monitoring.yml파일을 편집하고 다음 매개변수를 설정합니다. -
ansible_config_path는 기본적으로ansible-on-cloud 오퍼링의 표준 구성으로 사용되지만 사용자 환경에 추가 요구 사항이 있는 경우 직접 지정할 수 있습니다. -
cloud_credentials_path는 인증 정보를 위한 절대 경로입니다. 이는 절대 경로여야 합니다. -
deployment_name은 배포 이름입니다. -
구성 요소(선택 사항) 설정을 수행할 구성 요소 유형입니다. 기본값은 [ "controller", "hub" ]입니다. 즉, 자동화 컨트롤러와 자동화 허브에서 로깅 모니터링이 활성화됩니다. -
monitoring_enabled(선택 사항)는 모니터링을 활성화하기 위해true로 설정됩니다. 그렇지 않으면false입니다. 기본값 =false. -
logging_enabled(선택 사항)는 로깅을 활성화하려면true로 설정됩니다. 그렇지 않으면false입니다. 기본값 =false. default_collector_interval(선택 사항)은 모니터링 데이터를 Google Cloud로 보내야 하는 빈도입니다. 기본값은 59s입니다.참고이 서비스의 Google 비용은 주기성에 따라 달라지며 컬렉터 간격의 값이 높을수록 비용이 줄어듭니다.
59초 미만의 값을 설정하지 마십시오.
참고모니터링 및 로깅이 비활성화되면 'default_collector_interval' 값이 자동으로
0으로 설정됩니다.
데이터 파일을 채우면 다음과 같아야 합니다.
다음 값은 예제로 제공됩니다.
섹션에 설명된 선택적 매개 변수는 아래 데이터 파일 예제에서 생략됩니다. 플레이북은 데이터 파일에서 발생하는 선택적 매개 변수에 기본값을 사용합니다. 선택적 매개변수의 기본값을 재정의하려면 데이터 파일에 포함되고 값을 할당해야 합니다.
gcp_setup_logging_monitoring: cloud_credentials_path: ~/secrets/GCP-secrets.json deployment_name: AnsibleAutomationPlatform extra_vars:
9.1.5. 플레이북 생성
플레이북을 생성하려면 명령 생성기를 실행하여 CLI 명령을 생성합니다.
docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_setup_logging_monitoring \ --data-file /data/logging-monitoring.yml
다음 명령을 제공합니다.
docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> --env GENERATE_INVENTORY=true \ $IMAGE redhat.ansible_on_clouds.gcp_setup_logging_monitoring -e 'gcp_deployment_name=<deployment_name> \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials monitoring_enabled=<monitoring_enabled> \ logging_enabled=<logging_enabled> default_collector_interval=<interval>'
제공된 명령을 실행하여 플레이북을 실행합니다.
$ docker run --rm --env PLATFORM=GCP -v /path/to/credentials:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=mu-deployment \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_setup_logging_monitoring \ -e 'gcp_deployment_name=mu-deployment \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials components=["hubs","controllers"]\ monitoring_enabled=True logging_enabled=True default_collector_interval=60s'
프로세스는 시간이 걸릴 수 있으며 다음과 유사한 출력을 제공합니다.
TASK [redhat.ansible_on_clouds.setup_logging_monitoring : Update runtime variable logging_enabled] *** changed: [<user_name> -> localhost] TASK [redhat.ansible_on_clouds.setup_logging_monitoring : Update runtime variable monitoring_enabled] *** changed: [<user_name> -> localhost] PLAY RECAP ********************************************************************* <user_name> : ok=20 changed=6 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
9.2. 모니터링 및 로깅 사용자 정의
지표는 Ansible,Podman 및 Google Ops Agent 에서 제공합니다. Google Ops Agent 및 Podman은 자동화 컨트롤러 및 자동화 허브 VM 인스턴스에 설치되지만 Ansible 메트릭은 자동화 허브 인스턴스에만 설치됩니다.
구성 가능한 프로세스(collector)는 각 자동화 컨트롤러 VM 인스턴스 및 자동화 허브 VM 인스턴스에서 실행되어 수집된 Ansible 및 Podman 지표를 Google Cloud Platform 모니터링으로 내보냅니다. Google Ops 에이전트가 Google Cloud 솔루션의 일부이므로 자체 구성 파일이 있습니다.
Google Ops 에이전트도 로깅 구성을 담당합니다.
모니터링 및 로깅 기능에 대해 monitoring.googleapis.com 및 logging.googleapis.com 을 각각 활성화해야 합니다.
설정
구성 파일은 각 자동화 컨트롤러 및 자동화 허브에서 공유하는 디스크에 있습니다. /aap/bootstrap/config_file_templates/<controller|hub>/monitoring.yml 파일을 수정하여 모든 내보내기 및 에이전트를 구성합니다.
9.2.1. Ansible 및 podman 구성
자동화 컨트롤러 또는 자동화 허브의 /aap/bootstrap/config_file_templates/<controller|hub>/monitoring.yaml 파일에는 Ansible 및 podman 메트릭을 GCP로 수집하고 보내는 구성이 포함되어 있습니다.
자동화 컨트롤러의 기본 구성은 다음과 같습니다.
# This value will be set at deployment time. # Set to zero if monitoringEnabled is false otherwise 59s # The collection interval for each collector will be the minimum # between the defaultCollectorInterval and all send Interval # of a given collector # NB: The awx exported should not run on controllers as # it duplicates the number of records sent to GCP Monitoring defaultCollectorInterval: $DEFAULT_COLLECTOR_INTERVAL collectors: - name: podman endpoint: http://localhost:9882/podman/metrics enabled: true # list of metrics to exclude # excludedMetrics: # - podman_container_created_seconds metrics: - name: podman_container_exit_code # interval on which the metric must be pushed to gcp sendInterval: 59s
자동화 허브의 기본 구성은 다음과 같습니다.
# This value will be set at deployment time. # Set to zero if monitoringEnabled is false otherwise 59s # The collection interval for each collector will be the minimum # between the defaultCollectorInterval and all sendInterval # of a given collector # NB: The awx exporter should not run on controllers as # it duplicates the number of records sent to GCP Monitoring defaultCollectorInterval: 59s collectors: - name: awx userName: admin endpoint: http://<Controller_LB_IP>/api/v2/metrics/ enabled: true metrics: - name: awx_inventories_total # interval on which the metric must be pushed to gcp sendInterval: 59s - name: podman endpoint: http://localhost:9882/podman/metrics enabled: true # list of metrics to exclude # excludedMetrics: # - podman_container_created_seconds metrics: - name: podman_container_exit_code # interval on which the metric must be pushed to gcp sendInterval: 59s
여기서 수집기 는 수집기당 하나의 항목이 있는 구성 배열, 즉 awx 및 podman입니다.
awx 수집기에는 인증이 필요하므로 userName 을 admin 으로 설정해야 합니다. 암호는 secret-manager에서 검색됩니다.
엔드포인트는 변경하지 않아야 합니다.
defaultCollectorInterval 은 내보내기가 메트릭 끝점에서 정보를 수집하여 Google Cloud Platform Monitoring으로 전송하는 기본 간격을 지정합니다.
이 값을 0 으로 설정하거나 이 속성을 생략하면 모든 수집기가 비활성화됩니다.
각 수집기는 enabled를 true 또는 false 로 설정하여 별도로 활성화 하거나 비활성화할 수 있습니다.
수집기는 제품군별로 그룹화된 모든 메트릭을 반환하지만, 배열 제외 메트릭에 해당 이름을 추가하여 Google Cloud Platform Monitoring으로 전송해서는 안 되는 제품군을 제외할 수 있습니다.
다른 모든 제품군 지표의 경우 수집할 간격을 지정하여 Google Cloud Platform Monitoring으로 보낼 수 있습니다. 수집기 간격은 모든 제품군 지표 간격과 defaultCollectorInterval 사이의 최소값입니다. 이를 통해 Google Cloud Platform Monitoring으로 전송되는 각 메트릭 세트에 대한 컬렉션이 수행됩니다.
9.2.2. Google Cloud ops 에이전트 구성
설정 파일 세부 정보는 여기에서 확인할 수 있습니다.
구성 파일은 /etc/google-cloud-ops-agent/config.yml 에 있습니다.
이는 구성 요소 유형에 따라 공유 디스크 /aap/bootstrap/config_file_templates/controller/gcp-ops-agent-config.yml 또는 /aap/bootstrap/config_file_templates/hub/gcp-ops-agent-config.yml 에 대한 심볼릭 링크입니다.
구성 파일에는 ops 에이전트에서 수집해야 하는 항목을 지정하는 여러 수신자가 포함되어 있습니다.
배포 중에 연결 로깅 및 연결 메트릭 을 선택하면 파일에 포함된 파이프라인과 로그 및 메트릭이 GCP로 수집되어 전송됩니다.
배포 후 파이프라인을 추가해야 하는 경우 /aap/bootstrap/config_file_templates/hub|controller/gcp-ops-agent-config.yml 에 삽입할 수 있습니다.
gcp-ops-agent-config.yml 이 지난 10분 내에 변경된 경우 crontab 작업은 에이전트를 다시 시작합니다. 에이전트는 다시 시작한 후 구성을 다시 읽습니다.
10장. 백업 및 복원
- 백업과 동일한 작동 이미지 버전으로 복원해야 합니다.
- Ansible Automation Platform 배포를 백업하고 복원하려면 기존 Ansible Automation Platform 관리 시크릿 이름과 값을 안전한 곳에 보관해야 합니다.
- 또한 Cloud SQL 데이터베이스 인스턴스 및 파일 저장소 백업의 정기적인 수동 백업을 수행하여 배포가 이전 작동 상태에 최대한 가깝게 복원할 수 있도록 하는 것이 중요합니다.
Playbook 백업 및 복원은 GCP Marketplace 기반 배포에서 Ansible Automation Platform에 대한 백업 및 복원 지원을 제공합니다.
복원 프로세스는 파일 저장소 및 SQL 데이터베이스 인스턴스가 지정된 백업으로 복원되는 새로운 Ansible Automation Platform을 배포합니다.
10.1. 백업 프로세스
백업을 사용하면 데이터베이스와 공유 파일 시스템을 저장하여 환경을 백업할 수 있습니다. 저장된 공유 파일 시스템을 사용하여 복원 중에 새 환경이 생성됩니다. 새 환경이 배치되면 프로세스는 데이터베이스를 복원합니다.
백업 및 복원 프로세스에서는 동일한 버전을 사용해야 합니다. 이전 버전으로 백업을 수행한 경우 해당 버전의 복원 프로세스를 사용해야 합니다. 필요한 경우 업그레이드를 실행할 수 있습니다.
또한 업그레이드하기 전에 백업을 수행해야 합니다. 자세한 내용은 배포 업그레이드를 참조하십시오.
백업 프로세스에는 지정된 시점에서 Cloud SQL 데이터베이스 및 파일 저장소 인스턴스의 백업을 수행해야 합니다. 백업 플레이북에는 GCP Marketplace 기반 배포의 활성 Ansible Automation Platform이 실행되고 있어야 합니다.
복원 정보가 해당 버킷에 저장되므로 프로젝트에 버킷을 생성해야 합니다.
버킷은 동일한 배포 또는 다른 배포에서 여러 백업을 포함할 수 있습니다. 백업은 <prefix>-<deployment_name>-<timestamp>라는 디렉토리와 <prefix>-<deployment_name>-<timestamp>.json이라는 파일을 생성합니다. 디렉터리에는 awx 및 pulp 데이터베이스 백업, 배포 구성 및 시크릿이 포함되어 있습니다. json 파일에는 복원 절차에 대한 정보가 포함되어 있습니다.
CLI를 통해 플레이북이 제공되어 백업을 나열하고 삭제합니다.
다음 절차에서는 GCP Marketplace 배포에서 Ansible Automation Platform을 백업하는 방법을 설명합니다.
10.1.1. ansible-on-clouds-ops 컨테이너 이미지 가져오기
절차
기본 배포와 동일한 태그를 사용하여
ansible-on-clouds-ops컨테이너의 Docker 이미지를 가져옵니다.참고docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
10.1.2. 필요한 권한
스택을 백업하려면 다음 GCP IAM 권한이 있어야 합니다.
required-roles: Service Account User Compute Instance Admin (v1) required-permissions: compute.instances.list deploymentmanager.deployments.get deploymentmanager.manifests.get deploymentmanager.manifests.list deploymentmanager.resources.list file.backups.create file.operations.get iap.tunnelInstances.accessViaIAP storage.objects.create storage.objects.list
10.1.3. 환경 설정
절차
구성 파일을 저장할 폴더를 생성합니다.
$ mkdir command_generator_data
10.1.4. 백업 요구 사항
클라우드 배포 백업에 Ansible을 저장하려면 버킷을 생성해야 합니다. 버킷에는 백업 정보, 시크릿 및 데이터베이스 백업이 포함되어 있습니다.
절차
- Google Cloud 콘솔에서 Cloud Storage → Buckets로 이동합니다.
- 프로젝트를 선택합니다.
- 생성을 클릭합니다.
- 이름을 입력합니다.
- 가장 요구 사항에 맞는 데이터 위치를 입력합니다. 멀티 및 듀얼 리전을 사용하면 다른 지역으로의 복원을 실행할 수 있습니다.
- 요구 사항에 가장 적합한 스토리지 클래스를 입력합니다.
- 요구 사항에 가장 적합한 제어 액세스를 입력합니다.
- 가장 많은 요구 사항에 맞는 데이터 보호를 입력합니다.
- 생성을 클릭합니다.
문제 해결
버킷 이름이 다른 프로젝트에서 이미 사용된 경우 오류가 발생합니다.
10.1.5. 백업 데이터 파일 생성
절차
generator
command_generator_vars명령을 실행하여backup.yml을 생성합니다.참고Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로
root:root에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후sudo chmod명령을 실행할 수 있습니다. 자세한 내용은 root가 소유한 명령 생성기 - Linux 파일을 참조하십시오.docker run --rm -v $(pwd)/command_generator_data/:/data $IMAGE command_generator_vars gcp_backup_deployment --output-data-file /data/backup.yml
명령을 실행하면
$(pwd)/command_generator_data/backup.yml템플릿 파일이 생성됩니다. 이 템플릿 파일은 다음과 유사합니다.gcp_backup_deployment: cloud_credentials_path: deployment_name: extra_vars: backup_prefix: aoc-backup gcp_bucket_backup_name: gcp_compute_region: gcp_compute_zone:
10.1.6. backup.yml 파일의 매개변수
백업을 트리거하기 전에 데이터 파일을 채워야 합니다. 다음 변수는 데이터 파일에 나열된 매개 변수입니다.
-
cloud_credentials_path는 Google Cloud 서비스 계정 자격 증명 파일의 경로입니다. 이는 절대 경로여야 합니다. -
deployment_name은 백업하려는 AAP 배포 관리자 배포의 이름입니다. -
backup_prefix는 백업 이름에 추가할 접두사입니다(기본값: aoc-backup). -
gcp_bucket_backup_name은 이전에 백업에 사용하도록 생성된 버킷입니다. -
gcp_compute_region은 기반 배포가 배포된 GCP 리전입니다. Deployment Manager에서 Deployments config를 확인하여 검색할 수 있습니다. -
gcp_compute_zone은 기반 배포가 배포된 GCP 영역입니다. Deployment Manager에서 Deployments config를 확인하여 검색할 수 있습니다.
10.1.7. 백업 플레이북 실행
절차
백업을 실행하려면 명령 생성기를 실행하여 backup 명령을 생성합니다.
docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_backup_deployment --data-file /data/backup.yml
그 결과 다음과 같은 이점을 얻을 수 있습니다.
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name --env GENERATE_INVENTORY=true \ $IMAGE redhat.ansible_on_clouds.gcp_backup_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<deployment_name> gcp_compute_region=<region> gcp_compute_zone=<zone> \ gcp_bucket_backup_name=<bucket> backup_prefix=aoc-backup'
제공된 backup 명령을 실행하여 백업을 트리거합니다.
$ docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name --env GENERATE_INVENTORY=true \ $IMAGE redhat.ansible_on_clouds.gcp_backup_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<deployment_name> gcp_compute_region=<region> gcp_compute_zone=<zone> \ gcp_bucket_backup_name=<bucket> backup_prefix=aoc-backup'
Playbook 실행이 완료되면 출력은 다음과 유사합니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_backup : [backup_deployment] Print the variable required to restore deployment my-deployment] *** ok: [localhost] => { "msg": [ "AAP on GCP Backup successful. Please note below the bucket name and backup name which are required for restore process.", "gcp_bucket_backup_name: my-bucket", "backup_name: aoc-backup-my-deployment-20230616T134002" ] } PLAY RECAP ********************************************************************* localhost : ok=38 changed=6 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
10.1.8. 백업 목록
이 플레이북을 사용하면 기존 백업을 특정 버킷에 나열할 수 있습니다.
절차
command_generator_data디렉터리를 구성 파일 템플릿으로 채웁니다.참고Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로
root:root에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후sudo chmod명령을 실행할 수 있습니다. 자세한 내용은 기술 노트를 참조하십시오.docker run --rm -v $(pwd)/command_generator_data/:/data $IMAGE command_generator_vars gcp_backup_list --output-data-file /data/backups_list.yml
명령을 실행하면
$(pwd)/command_generator_data/backups_list.yml템플릿 파일이 생성됩니다. 이 템플릿 파일은 다음과 유사합니다.gcp_backup_list: cloud_credentials_path: extra_vars: gcp_bucket_backup_name:백업을 실행하려면 명령 생성기를 실행하여 backup 명령을 생성합니다.
docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_backup_list --data-file /data/backups_list.yml
그 결과 다음과 같은 이점을 얻을 수 있습니다.
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE redhat.ansible_on_clouds.gcp_backup_list \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_bucket_backup_name=<bucket>'
- 제공된 백업 명령을 실행하여 백업 목록을 트리거합니다.
Playbook 실행이 완료되면 출력은 다음과 유사합니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_backup_list : [list_backup] Display list of backups] *** ok: [localhost] => { "msg": [ "aoc-backup-deployment1-20230614T203926", "aoc-backup-deployment1-20230616T114134", "aoc-backup-deployment1-20230616T134002", "aoc-backup-deployment2-20230613T124127" ] } PLAY RECAP ********************************************************************* localhost : ok=11 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
10.1.9. 백업 삭제
백업을 삭제하는 두 개의 플레이북이 있습니다.
-
gcp_backup_delete플레이북을 사용하여 단일 백업을 삭제합니다. -
gcp_backups_delete플레이북을 사용하여 한 번에 여러 백업을 삭제합니다.
gcp_backups_delete 는 문자열 ["backup1","backup2",…]의 배열을 사용하지만 gcp_backup_delete 는 특정 백업의 이름인 하나의 문자열만 사용합니다.
gcp_backups_delete 의 사용은 이 섹션에 설명되어 있습니다.
절차
command_generator_data디렉터리를 구성 파일 템플릿으로 채웁니다.참고Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로
root:root에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후sudo chmod명령을 실행할 수 있습니다. 자세한 내용은 root가 소유한 명령 생성기 - Linux 파일을 참조하십시오.docker run --rm -v $(pwd)/command_generator_data/:/data $IMAGE command_generator_vars gcp_backups_delete --output-data-file /data/backups_delete.yml
명령을 실행하면
$(pwd)/command_generator_data/backups_delete.yml템플릿 파일이 생성됩니다. 이 템플릿 파일은 다음과 유사합니다.gcp_backups_delete: cloud_credentials_path: extra_vars: backup_names: delete: gcp_bucket_backup_name:
backup_names 매개 변수는 문자열 배열을 지정해야 합니다(예: ["backup1","backup2"] ). 성공적으로 삭제하려면 delete 매개변수를 true 로 설정해야 합니다.
백업을 삭제하려면 명령 생성기를 실행하여
gcp_backups_delete'명령을 생성합니다.docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_backups_delete --data-file /data/backups_delete.yml
그 결과 다음과 같은 이점을 얻을 수 있습니다.
----------------------------------------------- Command to run playbook: docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE redhat.ansible_on_clouds.gcp_backups_delete \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials gcp_bucket_backup_name=<bucket> \ backup_names=<backup_names> delete=True'
- 제공된 backup 명령을 실행하여 백업을 삭제합니다.
Playbook 실행이 완료되면 출력은 다음과 유사합니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_backup_delete : [delete_backup] Dry-run message] *** skipping: [localhost] PLAY RECAP ********************************************************************* localhost : ok=23 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
10.1.10. 백업 삭제 실패
백업 삭제에 실패한 경우 다음 작업을 수행합니다.
절차
- 백업을 포함하는 버킷으로 이동합니다.
- 백업의 이름이 있는 디렉터리를 찾습니다.
- 백업 디렉터리를 엽니다.
- 백업 이름이 있는 디렉터리를 삭제합니다.
-
백업 이름이
.json인 파일을 확장자로 삭제합니다. - Filestore → 백업 으로 이동합니다.
- 백업과 동일한 이름으로 Filestore 백업을 삭제합니다.
10.2. 복원 프로세스
복원 프로세스는 새 배포를 생성하고 filestore 및 SQL 데이터베이스 인스턴스를 지정된 백업으로 복원합니다.
- 백업에 사용된 동일한 작동 이미지 버전으로 복원해야 합니다.
다음 절차에서는 GCP Marketplace 배포에서 Ansible Automation Platform을 복원하는 방법을 설명합니다.
10.2.1. ansible-on-clouds-ops 컨테이너 이미지 가져오기
절차
기본 배포와 동일한 태그를 사용하여
ansible-on-clouds-ops컨테이너의 Docker 이미지를 가져옵니다.참고docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
10.2.2. 환경 설정
절차
구성 파일을 저장할 폴더를 생성합니다.
$ mkdir command_generator_data
10.2.3. 필요한 권한
스택을 복원하려면 다음과 같은 GCP IAM 권한이 있어야 합니다.
required-roles: Cloud SQL Client Cloud SQL Instance User Compute Instance Admin (v1) Compute Network Admin Editor Logs Writer Secret Manager Secret Accessor Service Account User required-permissions: compute.instances.list compute.networks.create deploymentmanager.deployments.create deploymentmanager.deployments.get deploymentmanager.operations.get file.instances.create file.operations.get iap.tunnelInstances.accessViaIAP secretmanager.secrets.create secretmanager.secrets.delete secretmanager.secrets.get secretmanager.secrets.update secretmanager.versions.add secretmanager.versions.list storage.objects.get storage.objects.list
10.2.4. restore.yml 파일 생성
절차
generator
command_generator_vars명령을 실행하여restore.yml을 생성합니다.참고Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로
root:root에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후sudo chmod명령을 실행할 수 있습니다. 자세한 내용은 기술 노트를 참조하십시오.docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator_vars gcp_restore_deployment --output-data-file /data/restore.yml
명령을 실행하면
$(pwd)/command_generator_data/restore.yml템플릿 파일이 생성됩니다. 이 템플릿 파일은 다음과 유사합니다.=============================================== Playbook: gcp_restore_deployment Description: This playbook is used to restore the Ansible Automation Platform from GCP Marketplace environment from a backup. ----------------------------------------------- This playbook is used to restore the Ansible Automation Platform from GCP Marketplace environment from a backup. For more information regarding backup and restore, visit our official documentation - https://access.redhat.com/documentation/en-us/ansible_on_clouds/2.x/html/red_hat_ansible_automation_platform_from_gcp_marketplace_guide/index ----------------------------------------------- Command generator template: docker run --rm -v <local_data_file_directory>:/data $IMAGE command_generator gcp_restore_deployment --data-file /data/restore.yml
템플릿은 다음과 유사합니다.
gcp_restore_deployment: cloud_credentials_path: deployment_name: extra_vars: backup_name: gcp_bucket_backup_name: gcp_cloud_sql_peering_network: gcp_compute_region: gcp_compute_zone: gcp_controller_internal_ip_address: gcp_existing_vpc: gcp_filestore_ip_range: gcp_hub_internal_ip_address:
10.2.5. restore.yml 파일의 매개변수
새 VPC 네트워크로만 복원할 수 있습니다.
새 VPC의 경우
새 VPC를 사용하여 복원하려면 다음 매개변수를 설정합니다.
-
gcp_existing_vpc는false로 설정해야 합니다.
다음 매개변수를 제거해야 합니다.
-
gcp_filestore_ip_range -
gcp_cloud_sql_peering_network -
gcp_controller_internal_ip_address -
gcp_hub_internal_ip_address
다음 매개변수의 값을 제공합니다.
-
gcp_existing_vpc는false로 설정해야 합니다. -
cloud_credentials_path는 Google Cloud 서비스 계정 자격 증명 파일의 경로입니다. -
deployment_name은 배포를 복원해야 하는 이름입니다. 이 이름으로 새 배포가 생성됩니다. 이 이름의 배포가 존재하지 않아야 합니다. -
backup_name은 버킷의 백업 이름입니다. 이 이름은gcp_backup_deployment또는gcp_backup_list명령을 사용하는 동안 표시됩니다. -
gcp_bucket_backup_name은 백업에 사용한 버킷 이름입니다. -
gcp_compute_region은 백업이 수행된 영역입니다. Deployment Manager에서 Deployments config를 확인하여 검색할 수 있습니다. -
gcp_compute_zone은 백업을 수행한 영역입니다. Deployment Manager에서 Deployments config를 확인하여 검색할 수 있습니다.
기존 VPC의 경우
기존 VPC를 사용하여 복원하려면 위에 표시된 매개변수를 설정해야 합니다.
다음과 같은 추가 매개변수도 설정해야 합니다.
-
gcp_existing_vpc가true로 설정됩니다. -
gcp_filestore_ip_range는 VPC의 무료 ip/29 범위로 설정해야 합니다. 예: 192.168.245.0/29. GCP Marketplace에서 Ansible Automation Platform을 배포할 때 사용되는 기본값으로 192.168.243.0/29를 사용해서는 안 됩니다. -
gcp_cloud_sql_peering_network를 무료/24서브넷으로 설정해야 합니다. 원래 배포 중에 사용되므로 192.168.241.0/24를 사용해서는 안 됩니다. -
gcp_controller_internal_ip_address는 VPC 네트워크에서 사용 가능한 IP로 설정해야 합니다. -
gcp_hub_internal_ip_address는 VPC 네트워크에서 무료 IP로 설정해야 합니다.
10.2.6. restore 명령 실행
$(pwd)/command_generator_data/restore.yml 이 입력되면 명령 생성기를 사용하여 restore 명령을 생성할 수 있습니다.
절차
명령 생성기를 실행합니다.
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_restore_deployment --data-file /data/restore.yml
이렇게 하면 필요한 모든 볼륨, 환경 변수 및 매개변수가 포함된 새 명령이 생성됩니다.
생성된 명령은 다음과 유사합니다.
docker run --rm --env PLATFORM=GCP -v <local_credential_file>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> --env GENERATE_INVENTORY=true -\ -env CHECK_GENERATED_INVENTORY=false $IMAGE redhat.ansible_on_clouds.gcp_restore_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<deployment_name> gcp_compute_region=<region> gcp_compute_zone=<zone> \ gcp_bucket_backup_name=<bucket> backup_name=<backup_name> gcp_existing_vpc=<existing_vpc>'
생성된 명령을 실행합니다.
$ docker run --rm --env PLATFORM=GCP -v <local_credential_file>:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg $IMAGE redhat.ansible_on_clouds.gcp_restore_deployment \ -e 'gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_deployment_name=<former_deployment_name> gcp_restored_deployment_name=<new_deployment_name> \ gcp_compute_region=<region> gcp_compute_zone=<zone> gcp_bucket_backup_name=<bucket> gcp_existing_vpc=False'
플레이북이 완료되면 출력은 다음과 유사합니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_restore : Display internal IP addresses] *** ok: [localhost] => msg: - 'Hub internal IP: 192.168.240.21' - 'Controller internal IP: 192.168.240.20' PLAY RECAP ********************************************************************* localhost : ok=33 changed=8 unreachable=0 failed=0 skipped=6 rescued=0 ignored=2
10.2.7. 복원 실패
복원 중에 다음과 유사한 메시지가 표시되면 복원을 수동으로 수행해야 하므로 지원팀에 문의해야 합니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_restore : [restore_deployment] Restore awx db] *
fatal: [localhost -> dvernier-restore1-aap-cntrlr-x2c6]: FAILED!11장. 업그레이드
기존 Ansible Automation Platform 배포를 최신 버전으로 업그레이드할 수 있습니다. 업그레이드 프로세스에서는 자동화 허브, 자동화 컨트롤러 및 확장 노드 업그레이드를 다룹니다. 업그레이드 프로세스는 Ansible Automation Platform 배포 설치와 거의 동일한 시간이 걸립니다. 업그레이드를 실행하기 전에 백업을 생성해야 합니다.
GCP Marketplace의 Ansible Automation Platform은 순차적 업그레이드를 지원합니다. 모든 업그레이드는 현재 업그레이드 중인 버전 뒤에 있는 하나의 주요 버전이 아니어야 합니다. 예를 들어 Ansible Automation Platform을 2.4.20230630으로 업그레이드하려면 버전 2.3.20230221에 있어야 합니다.
업그레이드를 실행하기 전에 로깅 및 모니터링을 비활성화해야 합니다. 업그레이드를 시작하기 전에 현재 버전에 대한 모니터링 및 로깅을 비활성화하려면 다음 지침을 따르십시오.
업그레이드가 완료되면 다음 지침에 따라 로깅 및 모니터링을 다시 활성화할 수 있습니다.
사전 요구 사항
- 업그레이드 플레이북을 실행하려면 Docker를 설치해야 합니다.
-
ansible-on-clouds-ops컨테이너 이미지가 실행되는 Linux 또는 macOS 시스템입니다. - 업그레이드 프로세스에는 여러 볼륨을 마운트해야 합니다. 이 프로세스에 사용할 새 디렉터리를 준비합니다.
다음 절차는 업그레이드 프로세스를 형성합니다.
Ansible Automation Platform 2.3 스택을 백업합니다.
Ansible Automation Platform 업그레이드
- ansible-on-clouds-ops 2.4 컨테이너 이미지를 가져옵니다.
- 필요한 최소 권한이 충족되었는지 확인
- 데이터 파일 생성
- 데이터 파일 업데이트
- 운영 컨테이너를 실행하여 Ansible Automation Platform 업그레이드를 시작합니다.
(선택 사항) 백업에서 스택을 복원합니다.
11.1. 업그레이드 전 백업
Ansible Automation Platform 환경 업그레이드를 시작하기 전에 먼저 현재 버전에서 환경 백업을 수행해야 합니다.
이전 버전에서 Ansible Automation Platform 환경을 백업하려면 Ansible on Clouds 2.3 백업 지침을 따르십시오.
11.2. Ansible Automation Platform 업그레이드
11.2.1. ansible-on-clouds-ops 컨테이너 이미지 가져오기
절차
업그레이드할 버전과 동일한 태그를 사용하여 Clouds 작동 컨테이너에서 Ansible의 Docker 이미지를 가져옵니다.
참고docker 이미지를 가져오기 전에 docker를 사용하여 registry.redhat.io에 로그인했는지 확인합니다. 다음 명령을 사용하여 registry.redhat.io에 로그인합니다.
$ docker login registry.redhat.io
레지스트리 로그인에 대한 자세한 내용은 레지스트리 인증을 참조하십시오.
참고클라우드의 Ansible 운영 이미지 태그는 업그레이드하려는 버전과 일치해야 합니다. 예를 들어 기반 배포 버전이 2.3.20230221인 경우 2.4.20230630 태그가 있는 운영 이미지를 가져와서 버전 2.4.20230630으로 업그레이드합니다.
$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630 $ docker pull $IMAGE --platform=linux/amd64
11.2.2. 필요한 권한
스택을 업그레이드하려면 다음과 같은 GCP IAM 권한이 있어야 합니다.
required-roles: - Service Account User - Compute Instance Admin (v1) required-permissions: - compute.healthChecks.update - compute.healthChecks.use - compute.healthChecks.useReadOnly - compute.regionBackendServices.update - iap.tunnelInstances.accessViaIAP - runtimeconfig.variables.get - secretmanager.locations.get - secretmanager.locations.list - secretmanager.secrets.create - secretmanager.secrets.delete - secretmanager.secrets.get - secretmanager.secrets.list - secretmanager.secrets.update - secretmanager.versions.access - secretmanager.versions.add - secretmanager.versions.disable - secretmanager.versions.enable - secretmanager.versions.get - secretmanager.versions.list
11.2.3. 데이터 파일 생성
이 섹션의 명령은 디렉터리를 생성하고 업그레이드하는 동안 채워지는 빈 데이터 템플릿으로 채웁니다.
절차
다음 명령을 실행하여 필요한 데이터 파일을 생성합니다.
# Create a folder to hold the configuration files $ mkdir command_generator_data
command_generator_data폴더를 구성 파일 템플릿으로 채웁니다.참고Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로
root:root에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후sudo chmod명령을 실행할 수 있습니다. 자세한 내용은 root가 소유한 명령 생성기 - Linux 파일을 참조하십시오.$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE \ command_generator_vars gcp_upgrade \ --output-data-file /data/extra_vars.yml
이러한 명령을 실행하면
command_generator_data/extra_vars.yml템플릿 파일이 생성됩니다. 이 템플릿 파일은 다음과 유사합니다.gcp_upgrade: ansible_config_path: cloud_credentials_path: deployment_name: extra_vars: gcp_backup_taken: gcp_compute_region: gcp_compute_zone:
11.2.4. 데이터 파일 업데이트
업그레이드를 트리거하기 전에 데이터 파일을 채워야 합니다. 각 매개변수는 선택 사항으로 표시되지 않는 한 필요합니다. 매개 변수가 선택 사항으로 표시되면 해당 키와 값을 모두 데이터 파일에서 제거할 수 있습니다.
-
ansible_config_path(선택 사항)는 사용자 지정ansible_config로 재정의된 경우에만 사용합니다. -
cloud_credentials_path는 GCP 인증 정보 파일의 경로입니다. deployment_name은 foundation 배포의 이름입니다.- 이 이름은 기반을 배포할 때 사용한 이름과 같습니다.
-
gcp_backup_taken은 이 업그레이드를 실행하기 전에 현재 배포에 대한 수동 백업이 최근 생성되었는지 확인합니다. 여기에서true를 사용하여 최근 백업이 생성되었는지 확인합니다. -
gcp_compute_region은 기반 배포를 배포할 때 제공한 GCP 리전입니다. 기반을 배포할 때 리전을 제공하지 않은 경우 여기에서 기본 리전us-east1을 사용합니다. -
gcp_compute_zone은 기반 배포를 배포할 때 제공한 GCP 영역입니다. 기반을 배포할 때 영역을 제공하지 않은 경우 여기에서 기본us-east1-b를 사용합니다.
데이터 파일을 채우면 다음과 같아야 합니다.
다음 값은 예제로 제공됩니다.
gcp_upgrade:
ansible_config_path:
cloud_credentials_path: ~/secrets/GCP-secrets.json
deployment_name: AnsibleAutomationPlatform
extra_vars:
gcp_backup_taken: true
gcp_compute_region: us-east1
gcp_compute_zone: us-east1-b11.2.5. 업그레이드 Playbook 실행
Ansible Automation Platform을 2.4.20230630으로 업그레이드하면 내부 로드 밸런서의 프로토콜이 업데이트됩니다. 설치 후 추가 네트워킹 구성을 추가한 경우 연결을 보장하기 위해 업데이트해야 할 수도 있습니다. 자세한 내용은 업그레이드 노트를 참조하십시오.
업그레이드를 실행하려면 명령 생성기를 실행하여 upgrade CLI 명령을 생성합니다.
$ docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator --data-file /data/extra_vars.yml
이렇게 하면 다음 명령이 생성됩니다.
----------------------------------------------- docker run --rm --env PLATFORM=GCP -v ~/secrets/GCP-secrets.json:/home/runner/.gcp/credentials:ro --env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=AnsibleAutomationPlatform --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_upgrade \ -e 'gcp_deployment_name=AnsibleAutomationPlatform \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_compute_region=us-east1 gcp_compute_zone=us-east1-b gcp_backup_taken=True' ===============================================
지정된 업그레이드 명령을 실행하여 업그레이드를 트리거합니다.
$ docker run --rm --env PLATFORM=GCP -v ~/secrets/GCP-secrets.json:/home/runner/.gcp/credentials:ro \ --env ANSIBLE_CONFIG=../gcp-ansible.cfg \ --env DEPLOYMENT_NAME=AnsibleAutomationPlatform \ --env GENERATE_INVENTORY=true $IMAGE redhat.ansible_on_clouds.gcp_upgrade \ -e 'gcp_deployment_name=AnsibleAutomationPlatform \ gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials \ gcp_compute_region=us-east1 gcp_compute_zone=us-east1-b gcp_backup_taken=True'
업그레이드를 완료하는 데 시간이 다소 걸릴 수 있지만 시스템의 확장 노드 수에 따라 더 오래 걸릴 수 있습니다. 성공적인 업그레이드는 아래 로그에 표시됩니다.
TASK [redhat.ansible_on_clouds.standalone_gcp_upgrade : [upgrade] Show GCP current version] *** ok: [localhost] => { "msg": "gcp_current_version: 2.3.20230221-00" }- 이제 GCP Marketplace 배포의 Ansible Automation Platform이 최신 버전으로 업그레이드되고 배포 인증 정보를 사용하여 Red Hat Ansible Automation Platform 자동화 컨트롤러 및 자동화 허브에 로그인할 수 있습니다.
11.3. 백업에서 복원
이전 버전의 Ansible Automation Platform 환경을 업그레이드하기 전의 상태로 복원하려면 Clouds 2.3의 복원 지침을 따르십시오.
12장. 설치 제거
이 장에서는 Ansible Automation Platform을 제거하는 방법을 설명합니다.
12.1. 확장 노드 제거
이 작업은 취소할 수 없습니다.
확장 노드는 GCP Deployment Mananger에서 배포로 생성됩니다. 따라서 Ansible Automation Platform 확장 노드를 삭제하는 프로세스는 기본 Ansible Automation Platform 배포를 삭제하는 프로세스와 동일합니다.
절차
- 메인 메뉴를 선택합니다.
- Deployment Manager 를 선택합니다. Deployment Manager 가 표시되지 않는 경우 모든 제품 보기 를 선택합니다.
삭제할 확장 노드의 확인란을 선택합니다.
참고확장 노드와 기본 배포는 모두 Deployment Manager 에서 확인할 수 있습니다. 기본 배포가 아닌 확장 노드를 선택해야 합니다. 확장 노드의 이름은 이를 생성한 사용자가 선택합니다.
- 상단 표시줄에서 삭제 를 클릭합니다. 이 작업은 취소할 수 없습니다.
확장 노드가 삭제됩니다.
12.2. Ansible Automation Platform 설치 제거
절차
- 왼쪽 상단에서 주 메뉴를 선택합니다.
- Deployment Manager 를 선택합니다. Deployment Manager 가 표시되지 않는 경우 모든 제품 보기 를 선택합니다.
- 삭제할 배포 앞에 있는 확인란을 선택합니다.
- 상단 표시줄에서 삭제 를 클릭합니다. 이 작업은 취소할 수 없습니다.
삭제를 완료하는 데 시간이 걸릴 수 있습니다.
12.3. 업그레이드 리소스 제거
다음 절차에서는 업그레이드 후 남은 리소스를 삭제하는 방법을 설명합니다.
이러한 작업은 되돌릴 수 없습니다.
배포가 삭제된 경우에만 이러한 작업을 수행해야 합니다.
12.3.1. 보안 제거
이 작업은 취소할 수 없습니다.
배포가 삭제된 경우에만 이 작업을 수행합니다.
완료한 절차에 따라 찾을 수 있는 몇 가지 시크릿 이름이 있습니다.
- <deployment_name>-aap-secret-key
- <deployment_name>-aap-admin
- <deployment_name>-container_auth_private_key_pem
- <deployment_name>-container_auth_public_key_pem
- <deployment_name>-database_fields_symmetric_key
- <deployment_name>-pulp_cert
- <deployment_name>-pulp_key
절차
- 왼쪽 상단에서 주 메뉴를 선택합니다.
- Security 를 선택합니다. 보안이 표시되지 않는 경우 모든 제품 보기 를 선택합니다.
- Secret Manager 를 선택합니다.
- 위의 목록에 있는 이름을 찾아 배포 이름을 검색합니다.
- 배포 행에서 More Actions 아이콘 Cryostat를 클릭합니다.
- 삭제를 선택합니다. 관리 암호가 표시됩니다.
- 시크릿 이름을 입력합니다.
- 시크릿 삭제를 클릭합니다.
12.4. 백업 리소스 제거
다음 절차에서는 백업을 실행한 후 Ansible Automation Platform 배포를 제거할 때 남아 있는 모든 리소스를 삭제하는 방법을 설명합니다.
이러한 작업은 되돌릴 수 없습니다.
배포가 삭제된 경우에만 이러한 작업을 수행해야 합니다.
12.4.1. filestore 제거
이 작업은 취소할 수 없습니다.
- 절차
- 왼쪽 상단에서 주 메뉴를 선택합니다.
- Filestore 를 선택합니다. 파일 저장소가 표시되지 않으면 모든 제품 보기를 선택합니다.
- 백업을 선택합니다.
-
백업 이름의 형식은 <
DeploymentName>-filestore-<RandomSufix>입니다. 이 이름을 사용하여 필터링합니다. - 배포 행에서 More Actions 아이콘 Cryostat를 클릭합니다.
- 삭제를 선택합니다.
- 관리 암호가 표시됩니다.
- 시크릿 이름을 입력합니다.
- 백업 삭제를 클릭합니다.
12.4.2. 스토리지 버킷 제거
절차
- 왼쪽 상단에서 주 메뉴를 선택합니다.
- Cloud Storage 를 선택합니다. Cloud Storage 가 표시되지 않는 경우 모든 제품 보기를 선택합니다.
- 버킷을 선택합니다.
- 배포 이름을 검색합니다.
- 배포 행에서 More Actions 아이콘 Cryostat를 클릭합니다.
- 삭제를 선택합니다.
- 관리 암호가 표시됩니다.
- 시크릿 이름을 입력합니다.
- 보안 삭제를 클릭합니다.
12.5. 나머지 리소스 제거
다음 절차에서는 Ansible Automation Platform 배포를 제거할 때 남아 있는 리소스를 삭제하는 방법을 설명합니다.
이러한 작업은 되돌릴 수 없습니다.
배포가 삭제된 경우에만 이러한 작업을 수행해야 합니다.
12.5.1. 서비스 계정 제거
배포를 위해 새 서비스 계정을 생성하고 다른 위치에서 사용하지 않으면 삭제할 수 있습니다.
절차
- 왼쪽 상단에서 주 메뉴를 선택합니다.
- IAM 및 관리자를 선택합니다. IAM 및 관리자가 표시되지 않는 경우 모든 제품 보기 를 선택합니다.
- 서비스 계정을 선택합니다.
- 서비스 계정 이름으로 필터링합니다.
- 서비스 계정 행에서 More Actions 아이콘을 클릭합니다.
- 삭제를 선택합니다.
- 관리 암호가 표시됩니다.
- 삭제를 클릭합니다.
13장. 기술 노트
GCP Marketplace의 Ansible Automation Platform은 자체 관리 배포입니다. 다음은 GCP Marketplace 배포의 Ansible Automation Platform에 대한 기술 노트입니다.
13.1. 업그레이드 - 로깅 및 모니터링
업그레이드를 성공적으로 업그레이드하려면 업그레이드를 실행하기 전에 로깅 및 모니터링을 비활성화해야 합니다. 다음 지침에 따라 업그레이드를 시작하기 전에 현재 버전에 대한 모니터링 및 로깅을 전환합니다. 업그레이드가 완료되면 로깅 및 모니터링은 다음 지침에 따라 다시 활성화할 수 있습니다.
13.2. 명령 생성기 - root가 소유한 Linux 파일
Linux에서 명령 생성기가 생성한 모든 파일 또는 디렉터리는 기본적으로 root:root 에 의해 소유됩니다. 파일과 디렉터리의 소유권을 변경하려면 파일이 생성된 후 sudo chmod 명령을 실행할 수 있습니다.
# Change the owner of the command_generator_data directory recursively $ sudo chown -R $USER:$USER command_generator_data/ # Check the permissions $ ls -la command_generator_data/
명령 생성기는 현재 데몬 모드에서 Docker CLI를 사용할 것으로 예상합니다. 기본 Docker 설치에는 DAC( Discretionary Access Control)에 대한 User 네임스페이스 매핑이 없습니다. 따라서 컨테이너에서 root 가 생성한 모든 파일의 경우 파일이 공유 볼륨에 있는 경우 호스트의 root 가 소유합니다.
User 네임 스페이스를 포함하여 Linux 네임스페이스에 대한 자세한 내용은 The 7 most used Linux namespaces.
13.3. 업그레이드 노트
Ansible Automation Platform을 2.4.20230630으로 업그레이드하면 내부 로드 밸런서의 프로토콜을 HTTP에서 HTTP로 업데이트합니다. 추가 네트워킹 구성이 추가된 경우 연결을 보장하기 위해 업데이트할 수도 있습니다. 업그레이드에 성공하면 추가된 네트워킹 구성을 다시 검증해야 합니다.
13.4. Ansible Automation Platform Controller API
컨트롤러용 API 끝점에는 요청이 통과하려면 후행 슬래시가 포함되어야 합니다. 현재 GCP Marketplace의 Ansible Automation Platform 제공에서는 자동 후행 슬래시 리디렉션이 지원되지 않습니다. 예를 들어 < controller_base_url>/api/v2/metrics >/api/v2/metrics> /api/v2/metrics/ 와 같은 요청이 초과됩니다.
13.5. 확장 노드 노트 삭제
Ansible-on-Clouds ops 플레이북을 사용하여 확장 노드를 제거할 때 올바른 인스턴스 그룹 이름과 인스턴스 템플릿 이름을 제공해야 합니다. 잘못된 인스턴스 그룹 이름 및 인스턴스 템플릿 이름은 일부 고립된 리소스가 생성됩니다.
13.6. 보안 업데이트
GCP 시크릿 관리자의 시크릿을 업데이트할 때 최신 시크릿 버전이 활성화되어 있는지 확인합니다. 예를 들어 < deployment-name>-aap-admin 보안에 대한 두 가지 시크릿 버전이 있는 경우 시크릿 버전 2를 활성화해야 합니다. 여기서 < deployment-name >은 기반 배포의 이름입니다.
14장. 지원
GCP Marketplace의 Ansible Automation Platform은 자체 관리 배포입니다. 애플리케이션이 GCP 인프라에 배포되면 고객은 GCP 인프라, OS 패치 및 Ansible Automation Platform 패치의 유지 관리를 담당합니다.
Red Hat은 네트워킹을 위한 경로 테이블 구성 또는 문서화된 업그레이드 프로세스와 같은 프로세스를 설명하는 Red Hat의 설명서가 없는 한 솔루션의 일부로 배포된 인프라 리소스에 대한 변경을 지원하지 않습니다. 확장 노드 외부에 추가 컴퓨팅 리소스를 추가하면 GCP Marketplace 배포에서 Ansible Automation Platform에 대한 Red Hat 지원이 무효화됩니다.
GCP Marketplace에서 Ansible Automation Platform으로의 업그레이드는 자체 설치된 Ansible Automation Platform과 다르게 수행됩니다. dnf 또는 기타 수단을 사용하여 가상 머신에서 개별 패키지를 업그레이드하는 것도 지원되지 않습니다. 지침은 각 버전에 대한 관련 콘텐츠가 포함된 이 문서의 업그레이드 섹션에 제공됩니다.
14.1. 지원되는 인프라 구성 변경
Red Hat은 다음 옵션에 대한 변경을 지원합니다.
- VPC 경로 구성
- VPC 방화벽 구성
- VPC 로드 밸런서 구성
- 블록 스토리지 확장
-
DNS 및
resolv.conf파일
Red Hat Reonsibilities
Red Hat은 다음과 같은 책임이 있습니다.
- Ansible Automation Platform에 대한 프리미엄 지원
- GCP Marketplace에서 Ansible Automation Platform 업그레이드를 위한 지침 및 프로세스.
- Red Hat은 현재 Ansible Automation Platform 버전을 지원합니다. 버그 수정 및 CVE 패치를 사용하려면 최신 버전으로 업그레이드해야 합니다.
고객 책임
다음과 같은 책임이 있습니다:
- GCP 인프라 가동 시간
- 예를 들어 GCP 인프라 변경으로 블록 스토리지 크기 증가
- GCP 네트워크 피어링 및 구성
Ansible Automation Platform 업그레이드 애플리케이션
- 운영 체제 업그레이드 포함
- GCP 리소스 백업
14.2. VM 이미지 패키지
GCP Marketplace의 Ansible Automation Platform은 Red Hat Ansible 팀에서 생성한 VM 이미지를 기반으로 하는 가상 머신을 통해 제공됩니다. 이 이미지에는 Google Cloud Platform에서 제대로 작동하고 Red Hat Ansible Automation Platform을 실행하기 위해 Red Hat 및 Google의 패키지가 포함되어 있습니다. 이미지에는 다음과 같은 Google 패키지 및 컨테이너가 포함되어 있습니다.
| 패키지 이름 | 설명 |
|---|---|
|
| Google OS 구성 에이전트는 관리 서비스를 사용하여 일관된 구성, 즉 VM 인스턴스에 필요한 상태 및 소프트웨어를 배포, 쿼리, 유지 관리합니다. |
|
| Ops 에이전트는 Compute Engine 인스턴스에서 Telemetry를 수집하기 위한 기본 에이전트입니다. Ops 에이전트는 단일 에이전트로 로깅과 지표를 결합함으로써 로그에는 Fluent Bit을 사용하며, 이는 높은 처리량 로깅을 지원하고 지표에 대해 OpenTelemetry Collector를 지원합니다. |
|
| Cloud SQL Authorization 프록시는 가상 머신 서비스 계정을 사용하여 Ansible Automation Platform 구성 요소를 Cloud SQL 데이터베이스와 연결하는 데 사용됩니다. |
|
| gcloud 명령줄 인터페이스는 Ansible Automation Platform 설치를 구성하는 데 사용됩니다. |
부록 A. Clouds 2.4의 Ansible 릴리스 노트
이번 릴리스에는 GCP Marketplace의 Ansible Automation Platform용으로 구현된 여러 개선 사항, 추가 사항 및 수정 사항이 포함되어 있습니다.
자동화 메시 및 이벤트 기반 자동화는 현재 클라우드 제품의 자체 관리 Ansible에서 아직 지원되지 않습니다.
기능 개선
GCP Marketplace의 Ansible Automation Platform의 릴리스 2.4.20230630에는 다음과 같은 향상된 기능이 포함되어 있습니다.
- Ansible Automation Platform 2.4에 대한 지원이 추가되었습니다.
웹 서버에 내부 암호화 추가
- 사용자 정의 인증서 추가가 지원됩니다.
사용자 정의 태그 및 라벨링에 대한 지원이 추가되었습니다.
- 배포가 소유한 리소스에 대한 태그 지원을 추가하거나 제거하기 위해 GCP에 지원이 추가되었습니다.
- GCP Marketplace의 Ansible Automation Platform에는 확장 노드를 추가하고 제거하는 운영 플레이북이 있습니다.
백업 및 복원 기능이 개선되었습니다.
- 여러 백업을 수행하기 위한 지원이 추가되었습니다.
- 사용 가능한 백업을 나열하기 위해 운영 플레이북이 추가되었습니다.
- 선택한 백업을 삭제하기 위해 작동 중인 플레이북이 추가되었습니다.
- 기존 VPC를 복원하는 기능이 추가되었습니다.
현재 버전을 확인하는 작동 기능이 추가되었습니다.
- 이제 운영 플레이북이 작업을 시작하기 전에 운영 중인 Ansible Automation Platform 환경이 동일한 버전에 있는지 확인합니다.
사용되지 않거나 삭제된 기능
이전 릴리스에서 사용 가능하던 일부 기능이 더 이상 사용되지 않거나 삭제되었습니다. 더 이상 사용되지 않는 기능은 여전히 Ansible Automation Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새 배포에는 사용하지 않는 것이 좋습니다. 다음은 Ansible Automation Platform 2.3에서 더 이상 사용되지 않고 삭제된 주요 기능 목록입니다.
- 온프레미스 구성 요소 자동화 서비스 카탈로그가 Ansible Automation Platform 2.4 이상에서 제거되었습니다.
- Ansible Automation Platform 2.4 릴리스에서는 Ansible 2.9(ee-29-rhel-8)의 실행 환경 컨테이너 이미지가 더 이상 자동화 컨트롤러 구성에 로드되지 않습니다.
Ansible Automation Platform과 관련된 추가 릴리스 노트
- Red Hat Enterprise Linux 9의 최신 기능 확인
- 최신 Ansible Automation Platform 기능에대해 자세히 알아보기