Red Hat Ansible Automation Platform on Microsoft Azure 가이드

Red Hat Ansible Automation Platform 2.1

Microsoft Azure에 Red Hat Ansible Automation Platform 설치 및 구성

Red Hat Customer Content Services

초록

피드백 제공:
이 문서를 개선하기 위한 제안이 있거나 오류를 발견한 경우, Docs 구성 요소를 사용하여 Ansible Automation Platform Jira 프로젝트에서 문제를 생성하기 위해 기술 지원에 문의하십시오 https://access.redhat.com.

머리말

Red Hat Ansible Automation Platform에 관심을 가져 주셔서 감사합니다. Ansible Automation Platform은 Ansible 기반 환경에 제어, 지식 및 위임을 추가하여 팀이 복잡한 다중 계층 배포를 관리하는 데 도움이 되는 상용 서비스입니다.

이 안내서는 Microsoft Azure에서 Ansible Automation Platform의 설치 및 사용을 이해하는 데 도움이 됩니다. 이 문서는 Microsoft Azure에서 Ansible Automation Platform의 최신 릴리스 정보를 포함하도록 업데이트되었습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. Microsoft Azure의 Ansible Automation Platform 소개

1.1. Microsoft Azure의 Red Hat Ansible Automation Platform 정보

Microsoft Azure의 Red Hat Ansible Automation Platform은 Azure Marketplace 포털에서 Azure 테넌트의 리소스 그룹에 배포할 수 있는 관리형 애플리케이션입니다. Microsoft Azure의 Ansible Automation Platform은 Ansible 콘텐츠 컬렉션 라이브러리에 액세스할 수 있으며 주요 Azure 서비스와 통합되므로 인프라 및 애플리케이션 배포, 구성 및 관리를 빠르게 시작할 수 있습니다.

Microsoft Azure의 Red Hat Ansible Automation Platform에서 다음과 같은 Red Hat Automation Platform 구성 요소를 사용할 수 있습니다.

  • 자동 컨트롤러
  • Automation Hub
  • Private Automation Hub
  • Automation Service Catalog
  • Azure용 Microsoft 컬렉션을 포함한 Ansible 콘텐츠 컬렉션
  • 자동화 실행 환경
  • Red Hat Ansible Automation Platform용 Red Hat Insights에 대한 액세스를 포함한 Ansible 콘텐츠 툴
참고

자동화 메시는 Microsoft Azure의 Ansible Automation Platform에서 사용할 수 없습니다.

1.2. 애플리케이션 아키텍처

Microsoft Azure의 Red Hat Ansible Automation Platform은 관리형 애플리케이션으로 설치됩니다. Red Hat은 인프라가 Azure 테넌트에서 실행되는 동안 기본 Azure 리소스와 이 리소스에서 실행되는 소프트웨어를 모두 관리합니다.

관리형 애플리케이션 리소스 그룹은 테넌트의 다른 리소스 그룹과 완전히 분리됩니다. Red Hat은 관리형 애플리케이션 리소스 그룹에만 액세스할 수 있으며 다른 테넌트 리소스에는 액세스할 수 없습니다.

이 작동 방식 및 리소스 및 액세스가 나머지 Azure 리소스와 격리되는 방법에 대한 자세한 내용은 Microsoft Azure 관리 애플리케이션 가이드의 Azure 관리 애플리케이션 개요 를 참조하십시오.

Microsoft Azure의 Ansible Automation Platform은 다음 리소스 그룹을 사용합니다.

  • 테넌트의 신규 또는 기존 리소스 그룹(RG)입니다. 이 리소스 그룹에는 Microsoft Azure 관리 애플리케이션 배포에서 Ansible Automation Platform을 참조하는 단일 리소스가 포함됩니다. Red Hat은 관리된 앱에 액세스하여 지원, 유지 관리 및 업그레이드를 수행할 수 있지만 리소스 그룹은 Red Hat의 관리 범위를 벗어납니다.
  • Microsoft Azure에서 Ansible Automation Platform을 작동하는 데 필요한 대부분의 인프라를 포함하는 다중 테넌트 관리 리소스 그룹(MRG)입니다. 이 다중 테넌트 리소스 그룹은 Red Hat 테넌트와 테넌트 간에 공유됩니다. Red Hat은 전체 관리 권한을 가지며 리소스 그룹에 대한 읽기 전용 권한을 갖습니다.
  • AKS 노드 풀 리소스 그룹(NPRG). Microsoft는 AKS 배포를 위해 10.0.0.1RG가 필요합니다. AKS가 작동하는 데 사용하는 리소스가 포함되어 있습니다. 배포 시 생성되며 Red Hat의 관리 범위를 벗어납니다. CHAPRG에 대한 자세한 내용은 Microsoft의 AKS 문서를 참조하십시오.
참고

Microsoft Azure SRE 팀의 Red Hat Ansible Automation Platform에서 명시적으로 전달하지 않는 한 노드 풀 리소스 그룹(NPRG)의 리소스와 상호 작용하지 마십시오. iPXERG의 리소스에 대한 변경 사항은 Red Hat에서 보호할 수 없으며 애플리케이션에 복구할 수 없는 손상을 초래할 수 있습니다.

Red Hat은 CHAPRG의 리소스를 변경하거나 삭제하는 기능을 제한할 수 없습니다.

Microsoft Azure에 Ansible Automation Platform을 설치할 때 배포가 공용인지 프라이빗인지 선택합니다. 이는 사용자가 Ansible Automation Platform 사용자 인터페이스에 액세스할 수 있는 방법에 영향을 미칩니다.

퍼블릭 또는 프라이빗 배포를 선택하든 관계없이 Ansible Automation Platform에서 자동화하려는 리소스가 포함된 프라이빗 네트워크로의 아웃바운드 통신에 대한 네트워크 피어링을 구성해야 합니다. Microsoft Azure의 Ansible Automation Platform에서 프라이빗 Azure VNet으로 네트워크 피어링을 구성하고 Azure에서 라우팅을 전송하는 온-프레미스 또는 다중 클라우드 네트워크로 구성할 수 있습니다.

1.2.1. 공용 배포

공용 배포를 통해 공용 인터넷을 통해 Microsoft Azure 사용자 인터페이스의 Ansible Automation Platform에 수신할 수 있습니다. 배포 시 도메인 이름은 Microsoft Azure 인스턴스의 Ansible Automation Platform에 발행됩니다. Ansible Automation Platform에 액세스하기 위한 구성이 필요하지 않습니다. 사용자는 공용 인터넷에서 도메인으로 이동하여 사용자 인터페이스에 로그인할 수 있습니다.

다음 다이어그램에서는 Microsoft Azure의 Ansible Automation Platform 공용 배포 시 관리되는 애플리케이션 리소스 그룹에 배포된 애플리케이션 리소스 및 아키텍처를 Azure 구독에 간략하게 설명합니다. 배포에 설정한 네트워킹 주소 범위에 따라 IP 범위가 변경됩니다.

Azure 공용 배포 시 AAP

1.2.2. 프라이빗 배포

Ansible Automation Platform의 프라이빗 배포는 외부 소스에서 액세스할 수 없는 격리된 Azure VNet에 있습니다. 공용 인터넷 및 기타 Azure VNet 및 서브넷이 차단됩니다.

Ansible Automation Platform 사용자 인터페이스의 URL에 액세스하려면 네트워크 피어링을 구성해야 합니다.

피어링 및 라우팅이 구성되면 연결된 Azure 서브넷의 VM을 통해 또는 조직에서 Azure와 로컬 네트워크 간에 라우팅이 설정된 경우 직접 Ansible Automation Platform에 액세스할 수 있습니다.

참고

두 개의 Azure 네트워킹 구성이 동일하지 않습니다. Ansible Automation Platform URL에 액세스할 수 있도록 하려면 조직에서 Azure 관리자와 함께 작업하여 개인 액세스 배포를 연결해야 합니다.

다음 다이어그램에서는 Microsoft Azure의 Ansible Automation Platform 개인 배포 시 관리되는 애플리케이션 리소스 그룹에 배포된 애플리케이션 리소스 및 아키텍처를 Azure 구독에 간략하게 설명합니다. 배포에 설정한 네트워킹 주소 범위에 따라 IP 범위가 변경됩니다.

Azure 개인 배포의 AAP

1.3. 네트워크

Microsoft Azure 애플리케이션의 Ansible Automation Platform에서 사용하는 VNet에 대한 네트워킹 주소 범위(CIDR 블록)를 구성할 수 있습니다. Microsoft Azure에 Ansible Automation Platform을 배포할 때 네트워크 구성 양식에서 애플리케이션의 CIDR 블록을 설정합니다. 배포 후 변경할 수 없기 때문에 Ansible Automation Platform을 Microsoft Azure 애플리케이션에 배포하기 전에 네트워킹 구성을 계획합니다.

네트워크 구성을 계획할 때 다음 사항에 유의하십시오.

  • 관리 애플리케이션에는 최소 4개의 서브넷으로 분할된 /24 Vnet이 필요합니다. 서브넷에는 최소 주소 간격이 있습니다.

    네트워킹 엔티티최소 CIDR 블록

    VNet

    /24

    클러스터 서브넷

    /26

    게이트웨이 서브넷

    /28

    데이터베이스 서브넷

    /28

    프라이빗 링크 서브넷

    /28

  • 구성하는 VNet 범위가 AKS 클러스터의 기본 CIDR 블록 (10.0.0.0/16)과 충돌하지 않는지 확인합니다. Azure 사용자 인터페이스에서 이 범위를 입력하는 것을 방해하지 않지만 VNet에 기본 AKS CIDR 블록을 사용하면 네트워킹 문제가 발생합니다.
  • Microsoft Azure의 Ansible Automation Platform과 기존 네트워크 간의 네트워크 피어링 및 통신에 성공하려면 엔터프라이즈 네트워크 범위가 VNet 네트워크 범위와 겹치지 않아야 합니다.
  • 기존 Azure VNet이 없는 경우 Azure 사용자 인터페이스에서 VNet의 기본 CIDR 블록과 범위를 제안합니다. 이 기본값을 사용하지 마십시오. 대신 계획한 네트워크 구성을 사용합니다.

네트워크 주소 범위를 계획하고 배포에서 네트워킹 구성 양식을 작성하는 방법에 대한 자세한 내용은 Microsoft Azure VNet 준비에서 Red Hat Ansible Automation Platform 을 참조하십시오.

1.4. Microsoft Azure 인프라 사용 시 Ansible Automation Platform

Microsoft Azure에 Ansible Automation Platform을 설치할 때 다음 인프라가 Azure 서브스크립션에 배포됩니다.

Azure Kubernetes 서비스(AKS)

Ansible Automation Platform 애플리케이션 및 서비스를 배포하는 데 사용되는 Kubernetes 클러스터입니다.

서비스 셰이프:

  • 컴퓨팅 노드: Standard_D4s_v3 (4 vCPU x 16GiB)
  • 최소 노드 자동 스케일링: 2
  • 자동 스케일링 최대 노드: 20
관리형 ID
Ansible Automation Platform 구성 요소가 데이터베이스, DNS, 스토리지 및 기타 서비스와 같은 다른 Azure 서비스와 통신할 수 있도록 하는 Azure 서비스입니다.
키 자격 증명 모음
Ansible Automation Platform 배포에 고유한 시크릿을 저장하는 데 사용되는 보안 키 자격 증명 모음입니다.
로그 분석 작업 공간
Red Hat 사이트 안정성 엔지니어를 통해 Microsoft Azure에서 Ansible Automation Platform의 운영을 검사할 수 있는 Azure 서비스입니다.
프라이빗 DNS 영역
Microsoft Azure의 Ansible Automation Platform에서 사용하는 서비스에 대한 로컬 DNS 요청을 관리합니다.
Azure Database for PostgreSQL

Ansible Automation Platform의 PostgreSQL 데이터베이스에 사용되는 Azure 데이터베이스 서비스입니다.

서비스 셰이프: 1TB

스토리지 계정

Azure 서비스는 프로젝트, 컨테이너 등의 로컬 스토리지를 위한 파일 및 블록 스토리지에 사용됩니다.

Service Shape: StorageV2 - Standard_LRS

가상 네트워크

Azure 서비스는 모든 내부 네트워킹 및 Azure Application Gateway와 같은 종속 서비스를 관리하는 데 사용됩니다.

서비스 셰이프: 애플리케이션 게이트웨이: WAF_v2

정확한 인프라 사용은 관리 애플리케이션이 테넌시에 배포된 시간과 Kubernetes 클러스터가 워크로드의 요구 사항을 충족하도록 자동 스케일링할 수 있는 자동화 요구 사항에 따라 달라집니다.

Microsoft는 Azure 제품 및 서비스에 대한 비용을 추정하는 데 필요한 계산기를 제공합니다. Red Hat은 가격 계산기에 예제 시나리오를 구성했습니다. Azure Infrastructure에서 Red Hat Ansible Automation Platform을 사용하여 조직의 워크로드에 따라 Kubernetes 예상 자동 스케일링 변수를 조정합니다.

1.5. 라이프사이클 관리

Red Hat Ansible은 Microsoft Azure 코어 시스템에서 기본 서비스 및 Ansible Automation Platform의 모니터링, 상태 및 유지 관리뿐만 아니라 Microsoft Azure 자체에서 Ansible Automation Platform의 운영을 담당합니다. 여기에는 구성 요소의 라이프사이클 관리가 포함됩니다.

1.6. Microsoft Azure 스케일링의 Ansible Automation Platform

자동 스케일링을 위한 Microsoft Azure 클러스터 자동 스케일러의 Microsoft Azure 기본 구성의 Ansible Automation Platform은 다음 설정으로 노드 수를 제한합니다.

  • 최소 노드: 1
  • 최대 노드: 20

1.7. Migration

Red Hat은 기존 배포를 Microsoft Azure의 Ansible Automation Platform으로 마이그레이션할 수 있는 솔루션을 제공하지 않습니다.

2장. Microsoft Azure에 Red Hat Ansible Automation Platform 설치

2.1. 사전 요구 사항

Azure 요구 사항

  • Microsoft Azure 용 서브스크립션입니다.
  • 해당 Azure 서브스크립션에 대한 기여자 또는 관리자 액세스 권한이 있어야 합니다.
  • Azure CLI에 액세스합니다.

Ansible Automation Platform 요구 사항

  • Red Hat 고객 포털의 계정(access.redhat.com).
  • Red Hat Ansible Automation Platform에 대한 특정 서브스크립션 인타이틀먼트.

2.1.1. Azure 리소스 할당량 및 인프라 제한

Microsoft는 각 Azure 리전 내에서 리소스 제한을 적용합니다. CPU 제한은 Microsoft Azure에서 Red Hat Ansible Automation Platform에 영향을 줄 가능성이 가장 높습니다.

Microsoft Azure에 Ansible Automation Platform을 설치하기 전에 관리 애플리케이션을 원하는 리전에 배포할 수 있는 용량이 있는지 확인하십시오. 인프라 요구 사항은 Azure 인프라 사용을 참조하십시오.

2.1.1.1. 지역 vCPU 제한

관리 애플리케이션 배포 중에 사용된 Azure 리소스는 Azure 인프라 사용량 의 리소스 요구 사항을 임시로 초과합니다. 관리 애플리케이션을 배포할 때 총 지역 vCPU 할당량이 일시적으로 사용됩니다.

모든 Azure 리전에는 별도의 Total Region vCPU 할당량이 있습니다. 설치 실패를 방지하려면 관리 애플리케이션을 배포하려는 Azure 리전에 최소 80 DS2_V3 vCPU를 사용할 수 있어야 합니다.

다음 단계에서는 Azure 콘솔을 서브스크립션에 대한 리소스 할당량을 확인하는 방법을 설명합니다.

  1. Azure 콘솔에서 할당량을 검색하고 내 할당량 페이지를 엽니다.
  2. 관리 애플리케이션을 배포할 리전을 선택하여 해당 리전의 할당 및 사용량 지표를 확인합니다. 하나의 리전을 선택했는지 확인합니다. 한 번에 모든 리전을 보면 단일 Azure 리전의 제한이 표시되지 않습니다.

2.1.1.2. 지역 StandardCore 제한

StandardCore 제한은 관리 애플리케이션을 배포할 때 일시적으로 소비되는 리소스에 대한 컴퓨팅 메트릭입니다.

Microsoft Azure의 Ansible Automation Platform은 StandardCore 제한에 도달하지 않고 배포할 수 있습니다. 소비된 리소스가 StandardCore 제한에 도달했기 때문에 배포가 실패하면 오류 메시지에 컨테이너 그룹 할당량 'ECDHECores' 초과 가 포함됩니다.

code: DeploymentFailed
message:
  At least one resource deployment operation failed. Please list deployment operations for details.
  Please see https://aka.ms/DeployOperations for usage details.
details:
  - code: DeploymentScriptContainerGroupInvalidSettings
    message:
      Resource type 'Microsoft.ContainerInstance/containerGroups'
      container group quota 'StandardCores' exceeded in region 'eastus'.
      Limit: '10', Usage: '10' Requested: '1'.

StandardCore 제한 요청

StandardCore 메트릭은 Azure 콘솔의 내 할당량 페이지에 표시되지 않습니다. 지역 제한 값을 요청하려면 Microsoft에 직접 문의하십시오.

소비된 리소스가 이 제한에 도달하므로 배포가 실패하는 경우 StandardCore 에 대한 리소스 증가 요청을 Microsoft에 제출해야 합니다. 이 문제로 인해 배포 실패 시 할당량 증가 요청만 제출합니다.

다음 정보를 사용하여 Microsoft 지원의 질문에 응답합니다.

컨테이너 그룹이 Linux 또는 Windows에서 실행됩니까?
Linux
컨테이너 그룹 인스턴스에 코어 및 메모리는 무엇입니까?
Red Hat은 20개의 코어, 16GB 권장
모든 컨테이너 그룹 인스턴스는 언제 생성할 것입니까?
Microsoft Azure에 Red Hat Ansible Automation Platform을 관리하는 애플리케이션 배포 중
컨테이너 그룹을 얼마나 자주 생성/삭제할 수 있습니까?
Microsoft Azure에서 Red Hat Ansible Automation Platform을 관리하는 애플리케이션 배포 시에만 해당

2.2. 서비스 주체 생성

Ansible Automation Platform 애플리케이션에서 Azure 리소스에 액세스하고 관리할 수 있도록 하려면 배포 후 권한 부여 자격 증명을 제공해야 합니다. Microsoft Azure 컬렉션은 서비스 주체 인증을 지원합니다.

서비스 주체를 만들려면 Azure 테넌트에 대한 테넌시 전체 권한이 있는 관리자 권한이 있어야 합니다. Microsoft Azure의 Ansible Automation Platform은 이 단계에서 생성된 서비스 주체와 동일한 서브스크립션 ID로 프로비저닝됩니다.

  1. Azure 포털로 이동하여 Cloud Shell 아이콘을 클릭하여 브라우저에서 bash Cloud Shell을 엽니다.
  2. Azure 서비스 자동화에 사용할 서브스크립션을 사용하도록 Azure CLI를 설정합니다. 쉘에서 다음 명령을 실행합니다.

    az account set --subscription <your_subscription_id>
  3. Azure CLI를 사용하여 다음 명령을 실행하여 Azure AD에서 권한 있는 서비스 주체를 생성합니다.

    az ad sp create-for-rbac --name ansible --role Contributor

    출력에 서비스 주체의 appIDtenant 키가 표시됩니다.

    {
      "appId": "xxxxxxx-xxx-xxxx",
      "displayName": "ansible",
      "name": "xxxxxxx-xxx-xxxx",
      "password": "xxxxxxx-xxx-xxxx",
      "tenant": "xxxxxxx-xxx-xxxx"
    }
  4. 시크릿을 생성할 때만 표시되는 대로 서비스 주체 세부 정보를 안전하게 저장합니다. Automation Controller를 배포할 때 필요합니다.

2.2.1. 서비스 주체 유지

서비스 주체 자격 증명에는 Azure AD 구성에 설정된 수명이 제한됩니다.Service principal credentials have a limited lifetime that is set in your Azure AD configuration. 연장된 기간 동안 Azure에 대해 자동화하려는 경우 서비스 주체의 수명을 추적합니다. 필요할 때 새로 만들 수 있습니다.

업데이트 또는 삭제된 서비스 원칙에 대한 레코드를 보려면 다음 Azure CLI 명령을 실행합니다.

az ad sp list -o table | grep ansible

이 명령은 서비스 주체의 시크릿을 표시하지 않습니다. 서비스 주체를 삭제하고 시크릿이 손실된 경우 새 주체를 생성합니다.

만료된 서비스 주체를 교체하기 위해 새 서비스 주체를 생성하는 경우 교체 중인 서비스 주체를 사용하는 인증 정보를 업데이트해야 합니다. 인증 정보가 업데이트되지 않으면 해당 인증 정보를 사용하는 자동화가 실패합니다.

2.3. Azure Marketplace에서 Ansible Automation Platform 배포

2.3.1. Azure Marketplace에서 Ansible Automation Platform 검색

  1. 브라우저에서 Azure Marketplace로 이동합니다.
  2. 탐색 패널의 화면 왼쪽에 있는 메뉴에서 개인 제품을 선택합니다.
  3. Red Hat Ansible Automation Platform 검색.
  4. 검색에 반환되는 카드를 클릭합니다. Red Hat에서 공식 오퍼링을 선택해야 합니다.
  5. 지금 가져오기를 클릭하고계속 진행한 다음 만들기 를 클릭하여 배포 프로세스를 시작합니다.

2.3.2. Microsoft Azure에 Red Hat Ansible Automation Platform 프로비저닝

Azure Marketplace에서 Red Hat Ansible Automation Platform 관리 앱 배포를 시작하면 Microsoft Azure에서 Red Hat Ansible Automation Platform 생성 창에 양식이 표시됩니다.

양식을 작성하기 전에 Microsoft Azure에서 Ansible Automation Platform의 공개 또는 프라이빗 배포를 생성할지 여부를 결정합니다.

  • 공용 배포를 통해 공용 인터넷을 통해 Microsoft Azure 사용자 인터페이스의 Ansible Automation Platform에 수신할 수 있습니다. 애플리케이션 URL에 액세스하기 위한 구성이 필요하지 않습니다.
  • 프라이빗 배포는 공용 인터넷에서의 액세스를 차단하는 격리된 Azure VNet에서 생성됩니다. Microsoft Azure 사용자 인터페이스에서 Ansible Automation Platform에 액세스하려면 네트워크 피어링 및 라우팅을 구성해야 합니다.

배포를 시작할 때 Microsoft Azure VNet에서 Ansible Automation Platform에 대한 네트워크 구성을 생성합니다. 관리 애플리케이션을 배포하기 전에 네트워크 구성 계획을 참조하십시오. 네트워크 구성 계획에 대한 자세한 내용은 네트워킹 구성을 참조하십시오.

Red Hat Ansible Automation Platform 인프라 및 리소스를 Azure 테넌트에 프로비저닝하려면 양식을 작성합니다.

  1. 양식에 다음 필드에 배포 값을 입력합니다.

    • 서브스크립션: 클라우드에서 Ansible을 선택합니다.
    • Resource Group: 관리 애플리케이션을 배포하려는 리소스 그룹을 생성하거나 선택합니다.
    • region: 애플리케이션이 배포될 Azure 리전입니다.
    • Application Name: 관리되는 애플리케이션의 고유 이름입니다.
    • 관리자 암호: 배포에 사용할 관리자 암호를 생성합니다.

      Administrator Password 는 최소 8자를 포함해야 하며 대문자, 소문자, 숫자를 포함해야 합니다.

    • 관리자 암호 확인: 관리자 암호 확인 .
    • 액세스: 배포가 공용인지 비공개인지 여부를 선택합니다.
    • 관리 리소스 그룹: 관리형 애플리케이션 인프라의 리소스 그룹입니다.

      관리 애플리케이션을 배포할 리소스 그룹을 포함하여 다른 리소스 그룹과 분리하여 이 리소스 그룹을 유지합니다.

  2. 입력한 정보를 안전한 장소에 저장합니다. 자동화 컨트롤러 및 프라이빗 자동화 허브에 액세스하려면 관리자 암호를 제공해야 합니다.
  3. 다음을클릭합니다.
  4. Microsoft Azure VNet의 Red Hat Ansible Automation Platform 단계에 따라 네트워크 구성을 구성합니다.
  5. Review + Create 를 클릭합니다.
  6. 양식에 입력한 정보가 유효한 경우 해당 창에 Validation Passed 가 표시됩니다.
  7. Co-Admin 액세스 권한 사용 약관을 수락하도록 I agree 를 선택합니다.
  8. 생성을 클릭하여 애플리케이션의 프로비저닝 프로세스를 시작합니다.

애플리케이션은 프로비저닝을 시작합니다.

인프라 및 소프트웨어를 완전히 프로비저닝하는 데 30분 이상 걸릴 수 있습니다.

프로비저닝이 완료되면 새 Ansible Automation Platform 인스턴스에 액세스하여 로그인하고 자동화 컨트롤러 및 자동화 허브를 시작할 수 있습니다.

2.4. Microsoft Azure에서 Red Hat Ansible Automation Platform에 액세스

Azure Marketplace에서 Red Hat Ansible Automation Platform 관리 앱 배포를 시작하면 Microsoft Azure에서 Red Hat Ansible Automation Platform 생성 창에 양식이 표시됩니다. 양식을 작성하여 Ansible Automation Platform 인프라 및 리소스를 Azure 테넌트에 프로비저닝합니다.

  1. 웹 브라우저에서 Azure 콘솔에서 Managed Applications 로 이동합니다.
  2. 배포한 Microsoft Azure에서 Red Hat Ansible Automation Platform의 인스턴스를 선택합니다.
  3. 왼쪽 탐색 메뉴의 Settings 섹션에서 Parameters and Outputs 를 선택합니다.
  4. 자동화 컨트롤러 및 자동화 허브에 대한 URL 링크를 복사한 다음 저장합니다. 링크의 이름은 automationControllerUrlautomationHubUrl 입니다.
  5. 브라우저에서 자동화 컨트롤러 URL로 이동한 다음 다음 인증 정보를 사용하여 로그인합니다.

    • 사용자 이름: admin
    • 암호: Ansible Automation Platform 애플리케이션을 배포할 때 제공한 관리자 암호를 사용합니다.

Microsoft Azure에서 Ansible Automation Platform에 처음 로그인하는 경우 서브스크립션을 구성하고 약관에 동의해야 합니다.

2.4.1. 라이센스 연결

Red Hat은 Microsoft Azure에서 Red Hat Ansible Automation Platform에 등록할 때 특정 서브스크립션 인타이틀먼트 매니페스트를 제공했습니다.

라이센스에 대한 정보를 제출하라는 메시지가 표시되면 access.redhat.com에서 얻은 라이센스 매니페스트 파일을 선택합니다.

2.4.2. Azure Active Directory (Azure AD) SSO 구성

아래 절차에 따라 Azure Active Directory (Azure AD)를 사용하여 SSO를 구성합니다. 조직에서 애플리케이션 권한 부여에 Azure AD를 사용하지 않는 경우 Ansible Automation Platform의 사용자 관리 시스템에 사용자를 생성할 수 있습니다.

Ansible Automation Platform 배포의 기본 URL 구성

  1. 브라우저에서 Automation 컨트롤러 URL로 이동하여 다음 인증 정보를 사용하여 로그인합니다.

    • 사용자 이름: admin
    • 암호: Ansible Automation Platform 애플리케이션을 배포할 때 제공한 관리자 암호를 사용합니다.
  2. 자동화 컨트롤러 콘솔에서 설정을 클릭합니다.
  3. 시스템 설정에서 기타 시스템 설정을 클릭합니다.
  4. 편집 을 클릭합니다. 서비스 필드의 기본 URl에 Automation 컨트롤러 URL을 입력합니다.
  5. 저장을 클릭합니다.

Ansible Automation Platform에 대한 인증 구성

Microsoft Azure Active Directory (Azure AD)에 대한 엔터프라이즈 인증을 설정하려면 Azure에 Ansible Automation Platform 배포를 등록하여 OAuth2 키와 시크릿을 가져와야 합니다.

Azure에서 자동화 컨트롤러 인스턴스를 등록하려면 자동화 컨트롤러 설정에서 Azure AD OAuth2 콜백 URL 을 제공해야 합니다.

Azure AD OAuth2 콜백 URL 가져오기

  1. 웹 브라우저에서 자동화 컨트롤러 콘솔을 엽니다.
  2. 메뉴에서 설정을 클릭하여 기본 설정 페이지를 엽니다.
  3. 인증 카테고리에서 Azure AD 설정을 클릭하여 세부 정보 페이지를 엽니다.
  4. Azure AD OAuth2 콜백 URL 의 값을 복사합니다. 배포된 애플리케이션을 Azure AD에 등록할 때 이 값이 필요합니다.

Azure AD에서 등록된 애플리케이션 생성

  1. 웹 브라우저에서 Azure 포털을 엽니다.
  2. Ansible Automation Platform을 배포한 테넌트를 사용하고 있는지 확인합니다.
  3. 검색 창에 Azure Active Directory 를 입력합니다.
  4. 검색 결과에서 Azure Active Directory 를 선택합니다.
  5. 메뉴 옵션에서 앱 등록+관리를 선택합니다.
  6. 앱 등록 페이지에서 + 새 등록을 클릭합니다.
  7. 다음과 같이 새 등록을 구성합니다.

    • 이름 필드에 배포된 애플리케이션에 사용한 것과 동일한 이름을 입력합니다.
    • 지원 계정 유형 의 기본값을 선택합니다.
    • 리디렉션 URI(선택 사항) 에 대해 Web 을 선택합니다.
    • 리디렉션 URI(선택 사항) 필드에 자동화 컨트롤러에서 가져온 Azure AD OAuth2 콜백 URL 값을 입력합니다.
  8. 등록을 클릭하여 등록을 생성합니다.

등록이 완료되면 Automation Controller 애플리케이션의 등록 페이지가 표시됩니다.

통신을 위한 보안 생성

  1. Azure의 자동화 컨트롤러 애플리케이션 등록 페이지에서 Application (client) ID 값을 복사 및 저장합니다.

    Ansible Automation Platform 설정에서 Azure AD OAuth2 키에 이 값을 사용합니다.

  2. Manage& secrets 를 선택합니다.
  3. 클라이언트 시크릿 을 클릭한 다음 새 클라이언트 시크릿 을 클릭합니다.
  4. 새 보안에 대한 설명을 제공합니다.

    인증서를 자동으로 갱신하거나 만료 시기를 확인할 수 없습니다.

    설명에 날짜를 포함하는 것이 유용합니다(예: AAP Client Secret <Today's Date in YYY-MM-DD format> ).

  5. 새 보안의 만료 날짜를 제공합니다.

    인증서의 최대 수명은 2 년입니다. 장기 인증서 생성을 방지하는 특정 보안 요구 사항이 없는 경우 24 개월 의 만료 날짜를 선택합니다.

  6. 시크릿 값을 로컬 머신의 위치에 저장합니다. 이 페이지를 벗어나면 숨겨지고 더 이상 검색할 수 없습니다.

Ansible Automation Platform 설정에 보안 추가

Azure에서 생성한 시크릿의 키 (애플리케이션(클라이언트) ID ) 및값(값)을 Ansible Automation Platform 인스턴스에 추가합니다.

  1. 웹 브라우저에서 자동화 컨트롤러 콘솔을 엽니다.
  2. SettingsAzure AD settings 를 클릭합니다.
  3. 편집 을 클릭합니다.
  4. Azure AD에서 생성한 시크릿에 대한 정보를 입력합니다.
  5. Azure AD OAuth2 키 에서 애플리케이션(클라이언트) ID 를 붙여넣습니다.
  6. Azure AD OAuth2 시크릿 에서 시크릿 값을 붙여넣습니다.
  7. 저장을 클릭합니다.

자동화 컨트롤러에 Azure 자격 증명 추가

  1. 웹 브라우저에서 자동화 컨트롤러를 엽니다.
  2. 리소스자격 증명을 선택하고 추가 를 클릭하여 새 자격 증명 생성 페이지를 엽니다.
  3. 새 인증 정보의 이름을 입력하고 인증 정보 유형으로 Azure Resource Manager 를 선택합니다.
  4. 형식 값을 작성하려면 서비스 주체 세부 정보를 사용합니다.

    • 이름: 인증 정보를 설명하는 이름(예: *Azure Infrastructure* )을 선택합니다.
    • 서브스크립션 ID: Azure에서 생성한 리소스를 연결해야 하는 서브스크립션 ID를 입력합니다. 이는 테넌트에 고유합니다. 조직에 여러 서브스크립션 ID가 있을 수 있습니다. 사용해야 하는 서브스크립션 ID에 대한 Azure 관리자에게 문의하십시오.
    • 클라이언트 ID: 서비스 주체 생성에서 appId 값을 입력합니다.
    • 클라이언트 시크릿: 서비스 주체 생성 시 암호를 입력합니다.
    • 테넌트 ID: 서비스 주체 생성 시 테넌트를 입력합니다.
  5. 저장 을 클릭하여 자격 증명을 저장합니다.

3장. 프라이빗 네트워크 피어링

Microsoft Azure의 Ansible Automation Platform은 자체 Azure 가상 네트워크(VNet)를 사용하여 독립 관리 리소스 그룹에 배포됩니다.

처음 배포되면 Microsoft Azure의 VNet의 Ansible Automation Platform은 공용 인터넷을 통해 외부 네트워크에만 요청을 보낼 수 있습니다.

Microsoft Azure에서 Ansible Automation Platform을 사용하여 인터넷 배포의 리소스에 액세스할 수 있도록 하려면 프라이빗 가상 네트워크와 Microsoft Azure의 관리 애플리케이션 VNet에서 Red Hat Ansible Automation Platform 간의 Azure 네트워크 피어링을 구성해야 합니다.

여러 Azure VNet과 Azure VNet과 외부 VPN 라우팅 네트워크 간의 개인 전송 라우팅을 활성화하도록 Azure VNet을 구성할 수 있습니다. 이러한 VPN 네트워크는 온-프레미스 또는 다른 클라우드에 있을 수 있습니다.

두 개의 Azure 네트워킹 구성이 동일하지 않습니다. Microsoft Azure의 Ansible Automation Platform에 대한 사용자 액세스를 활성화하려면 Azure 관리자와 협력하여 VNet 및 외부 VPN 라우팅 네트워크에 배포를 연결합니다.

참고

네트워크 피어링은 Azure 네트워킹에 익숙한 Azure 관리자가 구성해야 합니다. Azure 계정에 대한 네트워크 변경 사항을 구성하면 중단 또는 기타 중단이 발생할 수 있습니다.

이 문서에 설명된 네트워크 피어링 절차는 Microsoft Azure에서 프로세스 및 서비스를 제어하고 관리하므로 Red Hat에서 지원하지 않습니다. Azure 네트워크 피어링에 대한 지원을 받으려면 Microsoft에 문의하십시오.

이 콘텐츠에 대한 Microsoft의 문서에 맞게 모든 노력을 기울이지만 시간이 지남에 따라 정확도가 달라질 수 있습니다. Microsoft의 설명서는 Azure의 네트워킹 항목에 대한 정보에 대한 최종 소스입니다.

Azure는 프라이빗 네트워크를 피어링하는 다양한 방법을 제공합니다. 일반적으로 다음 두 가지 범주로 나뉩니다.

  • Hub-and-spoke peering:이 토폴로지에는 다른 가상 네트워크가 피어하는 중앙 집중식 허브 VNet이 있습니다. 이 허브 네트워크에는 전송 라우팅을 통해 트래픽을 라우팅하는 메커니즘이 있습니다. 온-프레미스 및 기타 클라우드 네트워크와의 VPN/Express Connect 연결을 비롯한 클라우드 네트워크는 허브 VNet을 통해 통신할 수 있습니다.Cloud networks, including VPN/Express Connect connections with on-premises and other cloud networks, can communicate through the hub VNet.
  • Azure Virtual phone (VWAN): Azure VirtualECDHE는 Azure, 온-프레미스 및 기타 VPN/Direct Connect 네트워크에서 간소화된 허브 및 맞춤형 네트워크 모델링을 제공하는 네트워킹 서비스입니다. VWAN에 대한 자세한 내용은 Microsoft의 Virtual iPXE 설명서를 참조하십시오.
  • 직접 피어링: 사설 네트워크는 개별적으로 서로 연결되어 있고 라우팅 홉은 없습니다. 더 간단한 피어링 모델입니다. 몇 개의 네트워크만 연결하려는 경우 유용합니다.

조직에 대한 올바른 피어링 접근 방식을 결정하기 위해 Microsoft 애플리케이션 아키텍처 기본 가이드 의 가상 네트워크 피어링 및 VPN 게이트웨이 간의 Select between virtual network peering and VPN gateways 를 참조하십시오.

3.1. Hub-and-spoke peering (Transit routes)

참고

라우팅 테이블을 잘못 업데이트하면 네트워크가 손상될 수 있습니다. 예기치 않은 네트워크 동작을 되돌릴 수 있다는 확신이 있는 경우에만 이 절차의 단계를 실행합니다.

3.1.1. Hub-and-spoke 피어링 프로세스 개요

사전 요구 사항

  • Microsoft Azure에 Ansible Automation Platform을 배포했습니다.
  • Azure 테넌트에서 Azure VNet Hub-and-spoke 구현을 구성하고 테스트했습니다. 이 사전 요구 사항에서는 가상 네트워크 게이트웨이를 포함하여 많은 Azure 리소스를 구성해야 합니다.
  • VPN을 포함하여 spoke 네트워크 간의 전송 라우팅을 구성했습니다. 자세한 내용은 Microsoft Azure 문서의 가상 네트워크 피어링에 대한 VPN 게이트웨이 전송 구성을 참조하십시오.
  • 다음을 확인했습니다.

    • Microsoft Azure UI의 Ansible Automation Platform에 액세스해야 하는 기존 VNet의 CIDR 블록( VPN 및 직접 연결 포함)입니다.
    • 기존 VNet의 CIDR 블록( VPN 및 직접 연결 포함)은 Ansible 자동화를 위한 호스트 또는 엔드포인트를 포함합니다.
    • 애플리케이션의 관리형 리소스 그룹에서 Microsoft Azure VNet의 Ansible Automation Platform의 CIDR 블록입니다. 자세한 내용은 관리 리소스 그룹의 CIDR 블록 찾기를 참조하십시오.

네트워크를 피어링하기 전에 프라이빗 VNet과 Microsoft Azure 네트워크의 Ansible Automation Platform 간에 겹치는 네트워크 주소 공간이 없는지 확인합니다.

절차

  1. Microsoft Azure 관리 애플리케이션 Kubernetes 클러스터에서 Ansible Automation Platform의 CIDR 블록을 찾습니다. 관리되는 애플리케이션 Kubernetes 클러스터의 CIDR 블록 찾기를 참조하십시오.
  2. Ansible Automation Platform 서브넷을 사용하여 네트워크 피어링을 구성합니다. Ansible Automation Platform 서브넷을 사용하여 네트워크 피어링 구성을 참조하십시오.
  3. 경로 테이블을 업데이트합니다.

    1. 기존 네트워크의 라우팅 테이블을 구성하여 트래픽을 관리되는 애플리케이션 CIDR로 보냅니다. Ansible Automation Platform 사용자 인터페이스를 요청하는 모든 네트워크의 라우팅 테이블에 경로를 추가하고 해당 리소스에 대해 자동화가 수행될 모든 네트워크의 라우팅 테이블에 경로를 추가해야 합니다. Microsoft Azure의 Ansible Automation Platform으로 라우팅 을 참조하십시오.
    2. Ansible Automation Platform이 자동화 또는 사용자 인터페이스에 액세스하기 위해 Ansible Automation Platform과 통신할 각 스팟에 대해 VNet으로 라우팅을 구성합니다. VNet으로 라우팅을 참조하십시오.

3.1.1.1. 관리 리소스 그룹의 CIDR 블록 검색

  1. Azure 포털에서 리소스 그룹 페이지로 이동합니다.
  2. Microsoft Azure에서 Red Hat Ansible Automation Platform의 관리형 리소스 그룹을 클릭합니다. 리소스 그룹 이름에 "-mrg"가 접두사로 지정됩니다.
  3. 리소스 그룹 내에서 VNet을 선택하여 개요 페이지에서 해당 설정을 확인합니다.

    클러스터의 CIDR 블록이 Address Space 에 표시됩니다.

자세한 내용은 Microsoft Azure 가상 네트워크 가이드의 가상 네트워크 및 설정 보기 를 참조하십시오.

3.1.1.2. Ansible Automation Platform 서브넷을 사용하여 네트워크 피어링 구성

Azure 콘솔 내에서 Azure 가상 네트워크(VNet)는 이 가상 네트워크 라고 하며, 피어하려는 VNet을 원격 가상 네트워크 라고 합니다.

Azure 포털의 가상 네트워크 페이지에서 다음 설정을 사용하여 Microsoft Azure 앱의 Ansible Automation Platform과 피어링할 Azure VNet과 VNet 간의 피어링을 구성합니다.

  • 이 가상 네트워크에서 Microsoft Azure 가상 네트워크의 Ansible Automation Platform에 대한 설정을 선택합니다.

    • 피어링 링크 이름: < hub_to_aap_peering_link_name>
    • 원격 가상 네트워크로의 트래픽: 허용
    • 가상 네트워크 제거에서 전달된 트래픽: 허용
    • 가상 네트워크 게이트웨이 또는 경로 서버: 이 네트워크의 게이트웨이 또는 경로 서버 사용
  • 원격 가상 네트워크에서 Azure와 피어할 가상 네트워크의 설정을 선택합니다.

    • 피어링 링크 이름: < aap_to_hub_peering_link_name>
    • 원격 가상 네트워크로의 트래픽: 허용
    • 원격 가상 네트워크에서 전달된 트래픽: 허용
    • 가상 네트워크 게이트웨이 또는 경로 서버: 원격 가상 네트워크의 게이트웨이 또는 경로 서버 사용

피어링 구성에 대한 자세한 내용은 Microsoft Azure 가상 네트워크 가이드에서 피어 만들기 를 참조하십시오.

3.1.1.3. 경로 테이블 업데이트

경로 테이블을 업데이트하기 전에 hub-and-spoke 피어 프로세스에 대한 사전 요구 사항을 충족하는지 확인하십시오.

Microsoft Azure에서 Ansible Automation Platform으로 라우팅

  1. Azure 포털에서 경로 테이블로 이동합니다.
  2. hub-and-spoke 구성의 일부로 네트워크 간 경로를 정의하는 하나 이상의 경로 테이블을 생성했습니다. 이러한 경로 테이블 중 하나를 클릭합니다.
  3. 경로 테이블 메뉴 모음에서 RoutesAdd 로 이동합니다.
  4. 경로 테이블 메뉴 모음에서 경로추가 를 선택합니다.
  5. 기존 네트워크에서 Ansible Automation Platform으로 트래픽을 전송하도록 경로를 구성합니다. Ansible Automation Platform 사용자 인터페이스를 요청하는 모든 네트워크와 해당 리소스에 대해 자동화가 수행될 네트워크의 경로를 구성해야 합니다. 추가할 각 경로에 대해 다음 정보를 입력합니다.

    • Route name: Ansible Automation Platform 관리 애플리케이션 네트워크의 경로 이름을 입력합니다.
    • Address Prefix: 관리 애플리케이션 kubernetes 클러스터의 CIDR 블록
    • 다음 Hop 유형: 가상 네트워크 게이트웨이
  6. 확인을 클릭하여 경로 목록에 새 경로를 저장합니다.

트래픽을 Ansible Automation Platform으로 라우팅하려는 다른 모든 경로 테이블에 대해 이 절차를 반복합니다.

VNet으로 라우팅

Ansible Automation Platform이 자동화 또는 사용자 인터페이스에 액세스하는 데 사용할 각 대화 상자 네트워크에 대한 경로를 추가합니다.

  1. Azure 포털에서 경로 테이블로 이동합니다.
  2. 경로 테이블 목록에서 Microsoft Azure 관리 애플리케이션의 Ansible Automation Platform의 경로 테이블을 선택합니다.

    Ansible Automation Platform 경로 테이블의 이름은 다음 규칙을 사용합니다.

    aks-agentpool-<numbers>-routetable
  3. 경로 테이블 메뉴 모음에서 RoutesAdd 로 이동합니다.
  4. Ansible Automation Platform이 자동화 또는 사용자 인터페이스 모두에 대해 통신하도록 각 스팟으로의 VNet 라우팅을 구성합니다.
  5. 추가할 각 경로에 대해 다음 정보를 입력합니다.

    • Route name: Ansible Automation Platform에서 라우팅할 대화 상자 네트워크의 경로 이름을 입력합니다.
    • Address Prefix: spoke network의 CIDR 블록
    • 다음 Hop 유형: 가상 네트워크 게이트웨이
  6. 확인을 클릭하여 경로 목록에 새 경로를 저장합니다.

라우팅 규칙을 구성한 후 트래픽이 허브 네트워크를 통해 Azure의 Ansible Automation Platform으로 라우팅됩니다.

가상 어플라이언스를 통한 아웃 바운드 라우팅

조직에서 Virtual 10.0.0.1 연결을 통해 Azure 방화벽 서비스 또는 타사 방화벽 어플라이언스를 사용하는 경우, Red Hat이 애플리케이션을 유지 관리하고 외부 리소스에 대한 자동화를 활성화하도록 관리형 애플리케이션에서 아웃바운드 연결을 구성해야 합니다.

이를 구현하는 가장 쉬운 방법은 포트 443에서 모든 아웃바운드 트래픽을 허용하는 방화벽 규칙을 생성하는 것입니다.

포트 443의 모든 아웃바운드 트래픽을 허용하지 않도록 선택하는 경우 경로를 구성해야 합니다.

  • Red Hat이 Microsoft Azure에서 Ansible Automation Platform을 관리 및 업그레이드하고 보안 패치를 실행하려면 Azure Kubernetes 서비스(AKS) 클러스터의 모든 시스템에서 Ansible Automation Platform에서 사용하는 컨테이너 업데이트 가져오기 요청을 제출할 수 있어야 합니다. Microsoft Azure 관리 애플리케이션에 있는 Ansible Automation Platform의 Ansible Automation Platform의 전체 CIDR 범위에서 아웃바운드 트래픽에 대한 Ansible Automation Platform 경로 테이블에 경로를 다음 도메인에 추가합니다.

    • registry.redhat.io
    • quay.io
  • 또한 Ansible Automation Platform에서 자동화 작업을 실행하도록 방화벽에서 다른 외부 도메인 또는 IP 주소로의 트래픽을 허용해야 합니다. 그렇지 않으면 방화벽에서 자동화를 위해 Ansible Automation Platform과 대상 간의 연결을 차단합니다.
3.1.1.3.1. 추가 리소스

Azure의 경로 테이블에 경로를 추가하는 방법에 대한 자세한 내용은 Microsoft Azure 가상 네트워크 가이드에서 경로 만들기를 참조하십시오.

3.2. Azure Virtual phone (VWAN)

3.2.1. Microsoft Azure 네트워크의 Ansible Automation Platform에 VWAN Hub 피어링

피어링하기 전에 Microsoft Azure에서 Ansible Automation Platform을 연결하려는 Azure VWAN의 허브 네트워크에 허브 네트워크와 하나 이상의 대화 상자 네트워크를 연결해야 합니다.

사전 요구 사항

  • 사전 구성된 Azure VWAN입니다.
  • VWAN에 대한 다음 링크 중 하나 이상:

    • 사용자가 원격으로 로그인하여 Microsoft Azure의 Ansible Automation Platform에 액세스할 수 있는 Azure 가상 머신이 포함된 DMZ 네트워크입니다.
    • 로컬 머신이 Microsoft Azure의 Ansible Automation Platform에 액세스하기 위해 SSH 터널링을 사용하여 연결할 수 있는 Azure 가상 머신이 포함된 DMZ 네트워크입니다.
    • 로컬 머신에서 Microsoft Azure의 Ansible Automation Platform으로 트래픽을 라우팅하는 VPN 또는 Direct Connect 서비스입니다.

절차

  1. Ansible Automation Platform 인스턴스와 피어할 VWAN의 가상 네트워크 연결 페이지로 이동합니다.
  2. VWAN 허브와 Ansible Automation Platform 인스턴스 간 연결을 생성하려면 다음 설정을 사용합니다.

    • 연결 이름: & lt;Ansible_Automation_Platform_connection_name>
    • hubs: 관리형 애플리케이션 VNet에서 피어링할 하나 이상의 VWAN 허브 네트워크를 선택합니다.
    • Subscription: Microsoft Azure의 Ansible Automation Platform이 배포된 서브스크립션을 선택합니다.
    • resource group : 관리되는 애플리케이션의 관리되는 리소스 그룹입니다. 일반적으로 "mrg-"가 접두사로 지정됩니다.
    • 가상 네트워크: 관리되는 애플리케이션의 VNet입니다. 관리 리소스 그룹에는 VNet이 하나만 있습니다.
    • none으로 전파: 아니요
    • 연결 경로 테이블: 조직에서 VWAN에 대해 구성한 기본 경로 테이블 또는 적절한 경로 테이블을 선택합니다.
    • Route Tables로 전파: 조직에서 VWAN에 대해 구성한 하나 이상의 기본 라우팅 테이블 또는 적절한 경로 테이블을 선택합니다.
    • 라벨로 전파: 조직에서 사용하는 경우 라벨을 선택합니다.
    • static routes:이 필드를 완료하지 마십시오.

네트워크 피어링이 완료되면 VWAN 허브 네트워크를 통해 Microsoft Azure의 Ansible Automation Platform으로 라우팅됩니다.

추가 리소스

3.3. 직접 피어링

직접 피어링을 사용하여 가상 네트워크를 직접 연결할 수 있습니다. 두 네트워크가 피어링되면 Azure는 트래픽 간에 트래픽이 자동으로 전달될 수 있도록 해당 네트워크 간에 경로를 업데이트합니다.

직접 피어링 방법은 hub-and-spoke 모델보다 구성할 수 있습니다. 그러나 직접 네트워크 피어링 수는 제한됩니다. 각 새 네트워크는 다른 모든 네트워크를 피어링해야 하므로 가상 네트워크 수가 증가함에 따라 직접 피어링을 관리하기가 어려워집니다.

3.3.1. 직접 네트워크 피어링 구성

Azure 포털의 가상 네트워크 페이지에서 Azure 네트워크와 VNet 간의 네트워크 피어링을 구성할 수 있습니다.

Azure 콘솔 내에서 Azure 가상 네트워크는 이 가상 네트워크 라고 하며 피어하려는 VNet을 원격 가상 네트워크 라고 합니다.

Azure 포털의 가상 네트워크 페이지에서 다음 설정을 사용하여 Microsoft Azure 앱의 Ansible Automation Platform과 피어링할 Azure 네트워크 및 VNet을 구성합니다.

  • 이 가상 네트워크에서 Microsoft Azure 가상 네트워크의 Ansible Automation Platform에 대한 설정을 선택합니다.

    • 피어링 링크 이름: < hub_to_aap_peering_link_name>
    • 원격 가상 네트워크로의 트래픽: 허용
    • 원격 가상 네트워크에서 전달된 트래픽: 허용
    • 가상 네트워크 게이트웨이 또는 경로 서버: 이 네트워크의 게이트웨이 또는 경로 서버 사용
  • 원격 가상 네트워크에서 Azure와 피어할 가상 네트워크의 설정을 선택합니다.

    • 피어링 링크 이름: < aap_to_hub_peering_link_name>
    • Subscription: Microsoft Azure의 Ansible Automation Platform이 배포된 서브스크립션을 선택합니다.
    • 가상 네트워크: Microsoft Azure 가상 네트워크에서 Ansible Automation Platform 선택: vnet-<aap_identifier>-<region>
    • 원격 가상 네트워크로의 트래픽: 허용
    • 원격 가상 네트워크에서 전달된 트래픽: 허용
    • 가상 네트워크 게이트웨이 또는 경로 서버: 원격 가상 네트워크의 게이트웨이 또는 경로 서버 사용

직접 네트워크 피어링을 구성한 후 Microsoft Azure의 Ansible Automation Platform과 개인 호스트 및 Vnet의 IP 간 트래픽 경로를 구성합니다.

피어링 구성에 대한 자세한 내용은 Microsoft Azure 가상 네트워크 가이드에서 피어 만들기 를 참조하십시오.

직접 피어링에 대한 자세한 내용은 Microsoft Azure 가상 네트워크 가이드의 가상 네트워크 피어링을 참조하십시오.

4장. Red Hat Ansible Automation Platform에 연결

네트워크 피어링이 완료되고 Azure 라우팅 구성이 설정되면 팀이 Azure 네트워크 구성을 통해 Ansible Automation Platform에 액세스하는 방법을 선택할 수 있습니다.

4.1. 액세스 세부 정보

Ansible Automation Platform이 공용 또는 프라이빗 액세스 권한을 통해 배포되었는지 여부에 관계없이 DNS 레코드 세트가 생성됩니다. Ansible Automation Platform이 배포에 유효한 TLS 인증서를 발행하고 애플리케이션에 쉽게 액세스할 수 있도록 DNS 레코드가 생성됩니다.

Ansible Automation Platform 애플리케이션의 URL 목록을 보려면 배포에 대한 Azure Marketplace 관리 애플리케이션 목록의 매개 변수 및 출력 페이지로 이동합니다.

4.2. 공용 배포

Microsoft Azure에 Ansible Automation Platform을 배포할 때 공용 액세스를 선택한 경우 브라우저에서 공용 인터넷을 통해 Ansible Automation Platform 애플리케이션 URL에 액세스할 수 있습니다.

4.3. 프라이빗 배포

Microsoft Azure에 Ansible Automation Platform을 배포할 때 개인 액세스를 선택한 경우 Microsoft Azure 애플리케이션의 Red Hat Ansible Automation Platform에 발행된 DNS 레코드는 관리 애플리케이션이 배포될 때 선택한 CIDR 블록 내의 개인 주소를 가리킵니다. 네트워크 피어링을 생성한 후 이 주소에 대한 액세스를 구성해야 합니다.

Microsoft Azure의 Ansible Automation Platform에 연결하기 위해 선택하는 구성 및 액세스 방법은 조직에서 Azure 인프라를 관리하는 방법에 따라 달라집니다. Azure 관리자는 조직에 적합한 모델을 결정하고 설정을 구성해야 합니다.

다음은 가장 일반적인 옵션입니다.

4.3.1. Azure 호스트 가상 머신

소수의 사용자가 Azure 네트워크에서 개인 네트워크 리소스에 액세스하도록 하는 간단한 방법은 사용자가 공용 인터넷에서 원격으로 로그인할 수 있는 DMZ VNet(Gragin Network)에 jumpbox VM을 생성하는 것입니다. jumpbox VM에는 GUI 및 브라우저와 같은 워크스테이션 기능이 필요합니다.

사용자는 VNC, RDP 또는 기타 화면의 프로토콜을 통해 온-프레미스 머신에서 공개적으로 액세스 가능한 가상 머신에 원격으로 로그인할 수 있습니다.

Azure 프라이빗 네트워크에서 Ansible Automation Platform 웹 UI에 액세스하기 위해 사용자는 jumpbox VM에서 브라우저를 사용하여 URL로 이동합니다.

DMZ VNet은 네트워크 피어링을 통해 다른 Azure VNet에 연결되어 있으며 Ansible Automation Platform VNet으로 네트워크 트래픽을 전송하도록 라우팅 규칙이 설정되어 있습니다.

다음 다이어그램에서는 Azure 가상 머신을 통한 프라이빗 네트워크 액세스 구성 예제를 보여줍니다.

azure private nw 액세스 vm의 AAP
  • DMZ(DMZ) 네트워크에 대한 자세한 내용은 Microsoft Azure Cloud Adoption Framework 설명서의 Perimeter Networks 를 참조하십시오.
  • 건너뛰기 상자에 대한 자세한 내용은 Microsoft Azure Cloud Adoption Framework 설명서의 Azure bastion 호스트 및 jumpboxes 정보를 참조하십시오.

4.3.2. VPN

조직에서 많은 사용자가 개인 연결을 통해 Ansible Automation Platform에 액세스해야 하거나 조직에서 이미 VPN을 사용하거나 Azure와의 직접 연결을 사용해야 하는 경우 이 방법이 적합할 수 있습니다.

이 구성에서는 네트워크 애플리케이션 게이트웨이를 통해 온-프레미스 인프라가 Azure에 연결되고 로컬 네트워크의 연결된 컴퓨터에 Ansible Automation Platform에 액세스할 수 있는 라우팅 규칙이 있습니다. 가상 네트워크 게이트웨이에 연결된 VNet은 네트워크 피어링을 통해 다른 Azure VNet에 연결되어 있으며 네트워크 트래픽을 Ansible Automation Platform VNet으로 보내는 라우팅 규칙이 설정되어 있습니다.

이 구성을 사용하면 사용자가 공용 액세스 접근 방식을 사용하는 것처럼 애플리케이션 URL을 통해 Ansible Automation Platform에 액세스할 수 있습니다.

azure private nw 액세스 vpn의 AAP

4.3.3. SSH 터널

VPN이 옵션이 아니며 로컬 사용자가 더 기술적이면 사용자가 로컬 시스템의 브라우저에서 Ansible Automation Platform에 액세스할 수 있는 안전한 대안입니다.

이 액세스 모델을 구현하려면 Azure 호스팅 가상 머신 방법과 유사한 DMZ 네트워크에 경량 Linux 기반 SSH 서버를 만듭니다. SSH 서버에는 사용자 로컬 시스템과 Microsoft Azure의 Ansible Automation Platform 간의 프록시 역할을 하기 때문에 워크스테이션 기능이 필요하지 않습니다.

각 사용자는 서버에서 SSH 사용자로 구성해야 합니다. 그런 다음 로컬 시스템에서 SSH 서버로 SSH 터널을 설정하여 Microsoft Azure의 Ansible Automation Platform에 대한 트래픽을 라우팅할 수 있습니다.

이 방법은 Linux 및 macOS 호스트 시스템에서 보다 쉽게 구현할 수 있지만 Windows에서 수행할 수 있습니다.

  1. Ansible Automation Platform URL이 DNS 레코드가 구성된 개인 IP 대신 로컬 시스템으로 트래픽을 라우팅하도록 로컬 호스트 파일을 업데이트합니다. hosts 파일에 다음 행을 추가합니다.

    127.0.0.1 controller.<your_AAPonAzure_instance>.az.ansiblecloud.com

    다음 예제는 hosts 파일의 행을 보여줍니다.

    ##
    # Host Database
    #
    # localhost is used to configure the loopback interface
    # when the system is booting. Do not change this entry.
    #
    127.0.0.1       localhost
    255.255.255.255 broadcasthost
    ::1             localhost
    
    127.0.0.1 controller.<your_AAPonAzure_instance>.az.ansiblecloud.com
  2. root 권한이 있는 사용자로 ssh 명령을 실행하여 SSH 터널을 설정합니다.

    아래 예제에서 SSH_server_IP 는 DMZ에 있는 SSH 서버의 IP 주소를 나타냅니다.

    sudo ssh azureuser@<SSH_server_IP> -i ~/.ssh/id_ssh_key -N -f -L 443:controller.<your_AAPonAzure_instance>.az.ansiblecloud.com:443

    -L 플래그는 포트 443(HTTP)을 통해 자동화 컨트롤러 URL에 대한 로컬 시스템 라우팅 트래픽을 만듭니다.

    참고

    라우팅 경로 양쪽에서 포트 443을 사용해야 합니다. 로컬 시스템에서 다른 포트를 사용하면 일부 Ansible Automation Platform 기능이 제대로 작동하지 않습니다.

SSH 터널이 설정되고 Azure 라우팅이 구성된 경우 로컬 브라우저에서 https://controller.<your_AAPonAzure_instance>.az.ansiblecloud.com에서 자동화 컨트롤러 URL에 액세스할 수 있습니다.

azure private nw 액세스 ssh의 AAP

 

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.