운영 Ansible Automation Platform


Red Hat Ansible Automation Platform 2.5

Ansible Automation Platform 설치를 원활하게 배포하기 위한 설치 구성 게시

Red Hat Customer Content Services

초록

이 가이드에서는 Red Hat Ansible Automation Platform의 설치 후 작업에 대한 지침 및 지침을 제공합니다.

머리말

Red Hat Ansible Automation Platform을 설치한 후 배포가 원활하게 실행되도록 시스템에 추가 구성이 필요할 수 있습니다. 이 가이드에서는 Red Hat Ansible Automation Platform을 설치한 후 수행할 수 있는 구성 작업에 대한 절차를 제공합니다.

면책 조항:이 정보에 포함된 외부 웹 사이트 링크는 편의를 위해서만 제공됩니다. Red Hat은 링크를 검토하지 않았으며 컨텐츠 또는 이용 가능 여부에 대해 책임을 지지 않습니다. 외부 웹 사이트에 대한 링크가 포함되어 있다고 해서 Red Hat이 해당 웹 사이트 또는 해당 엔티티, 제품, 서비스를 보증한다는 의미는 아닙니다. 사용자는 본인이 그러한 외부 사이트나 콘텐츠를 사용(또는 신뢰)하여 초래되는 어떠한 손실이나 비용에 대해 Red Hat이 어떠한 책임도 지지 않는 데 동의합니다.

Red Hat 문서에 관한 피드백 제공

이 문서를 개선하기 위한 제안이 있거나 오류를 찾을 수 있는 경우 https://access.redhat.com 에서 기술 지원에 문의하여 요청을 열 수 있습니다.

1장. Red Hat Ansible Automation Platform 활성화

조직 관리자인 경우 서비스 계정을 생성하고 클라이언트 ID 및 클라이언트 시크릿을 사용하여 서브스크립션을 활성화해야 합니다.

관리 액세스 권한이 없는 경우 클라이언트 ID 및 클라이언트 시크릿 필드에 Red Hat 사용자 이름과 암호를 입력하여 Ansible Automation Platform 인스턴스에 서브스크립션을 찾아 추가할 수 있습니다.

참고

클라이언트 ID와 클라이언트 시크릿을 입력했지만 서브스크립션을 찾을 수 없는 경우 서비스 계정에 올바른 권한이 설정되어 있지 않을 수 있습니다. 서비스 계정에 대한 자세한 내용 및 문제 해결 지침은 서비스 계정 자격 증명을 통해 인증하도록 Ansible Automation Platform 구성을 참조하십시오.

Red Hat Satellite의 경우 아래 필드에 Satellite 사용자 이름과 Satellite 암호를 입력합니다.

Red Hat Ansible Automation Platform은 사용 가능한 서브스크립션 또는 서브스크립션 매니페스트를 사용하여 Ansible Automation Platform 사용을 승인합니다. 서브스크립션을 얻으려면 다음 중 하나를 수행할 수 있습니다.

  1. Ansible Automation Platform을 시작할 때 Red Hat 사용자 이름 및 암호, 서비스 계정 인증 정보 또는 Satellite 인증 정보를 사용합니다.
  2. Red Hat Ansible Automation Platform 인터페이스를 사용하거나 Ansible 플레이북에서 수동으로 서브스크립션 매니페스트 파일을 업로드합니다.

자격 증명을 사용하여 Ansible Automation Platform을 활성화하려면 인증 정보로 활성화를 참조하십시오.

매니페스트 파일을 사용하여 Ansible Automation Platform을 활성화하려면 매니페스트 파일로 활성화를 참조하십시오.

2장. Red Hat Ansible Automation Platform에 대한 프록시 지원 구성

프록시를 사용하여 트래픽과 통신하도록 Red Hat Ansible Automation Platform을 구성할 수 있습니다. 프록시 서버는 다른 서버의 리소스를 찾는 클라이언트의 요청에 대해 중개자 역할을 합니다. 클라이언트는 프록시 서버에 연결하여 다른 서버에서 일부 서비스 또는 사용 가능한 리소스를 요청하고 프록시 서버는 요청을 간소화하고 복잡성을 제어하는 방법으로 평가합니다. 다음 섹션에서는 지원되는 프록시 구성과 설정 방법에 대해 설명합니다.

2.1. 로드 밸런서를 통한 프록시 지원 활성화

전달 프록시는 클라이언트 트래픽을 처리하여 이를 조정하고 보호합니다. 프록시 서버 지원을 제공하기 위해 자동화 컨트롤러는 자동화 컨트롤러의 REMOTE_HOST_HEADERS 목록 변수를 사용하여 프록시된 요청(예: ALB, NLB, HAProxy, Squid, Nginx 및 tinyproxy)을 처리합니다. 기본적으로 REMOTE_HOST_HEADERS["REMOTE_ADDR", "REMOTE_HOST"] 로 설정됩니다.

프록시 서버 지원을 활성화하려면 자동화 컨트롤러의 설정 페이지에서 REMOTE_HOST_HEADERS 필드를 편집합니다.

프로세스

  1. 탐색 패널에서 SettingsAutomation ExecutionSystem 을 선택합니다.
  2. 편집을클릭합니다.
  3. 원격 호스트 헤더 필드에 다음 값을 입력합니다.

    [
      "HTTP_X_FORWARDED_FOR",
      "REMOTE_ADDR",
      "REMOTE_HOST"
    ]
    Copy to Clipboard Toggle word wrap
  4. 저장을 클릭하여 설정을 저장합니다.

자동화 컨트롤러는 첫 번째 IP 주소가 있을 때까지 Remote Host Headers 의 헤더 목록을 검색하여 원격 호스트의 IP 주소를 결정합니다.

2.2. 알려진 프록시

자동화 컨트롤러가 REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST'] 로 구성된 경우 X-Forwarded-For 의 값이 자동화 컨트롤러 앞에 있는 프록시/로드 밸런서에서 발생했다고 가정합니다. 프록시/로드 밸런서를 사용하지 않고 자동화 컨트롤러에 도달하거나 프록시에서 헤더의 유효성을 검사하지 않는 경우 X-Forwarded-For 의 값을 위조하여 원래 IP 주소를 위조할 수 있습니다.

REMOTE _HOST_HEADERS 설정에서 HTTP_X_FORARDED _FOR를 사용하면 취약점이 발생합니다.

이를 방지하려면 허용되는 알려진 프록시 목록을 구성할 수 있습니다.

프로세스

  1. 탐색 패널에서 SettingsAutomation ExecutionSystem 을 선택합니다.
  2. 서비스에서 프록시 IP 허용 목록 필드에서 사용자 지정 원격 헤더 값을 신뢰해야 하는 프록시 IP 주소 목록을 입력합니다.

    참고

    알려진 프록시 목록에 없는 로드 밸런서 및 호스트로 인해 요청이 거부됩니다.

2.2.1. 알려진 프록시 구성

자동화 컨트롤러에 대해 알려진 프록시 목록을 구성하려면 시스템 설정 페이지의 프록시 IP 허용 목록 필드에 프록시 IP 주소를 추가합니다.

프로세스

  1. 탐색 패널에서 SettingsAutomation ExecutionSystem 을 선택합니다.
  2. 프록시 IP 허용 목록 필드에 다음 예의 구문을 사용하여 자동화 컨트롤러에 연결할 수 있는 IP 주소를 입력합니다.

    프록시 IP 허용 목록 항목 예

    [
      "example1.proxy.com:8080",
      "example2.proxy.com:8080"
    ]
    Copy to Clipboard Toggle word wrap

    중요
    • 프록시 IP 허용 목록에 있는 프록시는 헤더 입력을 적절히 제거하고 X-Forwarded-For 값을 클라이언트의 실제 소스 IP와 올바르게 설정합니다. 자동화 컨트롤러는 프록시 IP 허용 목록 의 IP 주소 및 호스트 이름을 사용하여 X-Forwarded- for에 스푸핑되지 않은 값을 제공할 수 있습니다.
    • 다음 조건을 모두 충족하지 않는 한 HTTP_X_FORWARDED_FOR원격 호스트 헤더 의 항목으로 구성하지 마십시오.

      • ssl 종료가 있는 프록시된 환경을 사용하고 있습니다.
      • 프록시는 클라이언트 스푸핑을 방지하기 위해 X-Forwarded-For 헤더의 종료 또는 검증을 제공합니다.
      • /etc/tower/conf.d/remote_host_headers.py 는 신뢰할 수 있는 프록시 또는 로드 밸런서의 원래 IP 주소만 포함하는 PROXY_IP_ALLOWED_LIST 를 정의합니다.
  3. 저장을 클릭하여 설정을 저장합니다.

2.3. 로드 밸런서를 통해 역방향 프록시 구성

역방향 프록시는 서버에 대한 외부 요청을 관리하고 추가 보안을 위해 부하 분산 및 서버 ID를 숨깁니다. 시스템 설정의 원격 호스트 헤더 필드에 HTTP_X_FORWARDED_FOR 을 추가하여 역방향 프록시 서버 구성을 지원할 수 있습니다. X-Forwarded-For (XFF) HTTP 헤더 필드는 HTTP 프록시 또는 로드 밸런서를 통해 웹 서버에 연결하는 클라이언트의 원래 IP 주소를 식별합니다.

프로세스

  1. 탐색 패널에서 SettingsAutomation ExecutionSystem 을 선택합니다.
  2. 원격 호스트 헤더 필드에 다음 값을 입력합니다.

    [
      "HTTP_X_FORWARDED_FOR",
      "REMOTE_ADDR",
      "REMOTE_HOST"
    ]
    Copy to Clipboard Toggle word wrap
  3. 아래 행을 /etc/tower/conf.d/custom.py 에 추가하여 애플리케이션이 올바른 헤더를 사용하는지 확인합니다.

    USE_X_FORWARDED_PORT = True
    USE_X_FORWARDED_HOST = True
    Copy to Clipboard Toggle word wrap
  4. 저장을 클릭하여 설정을 저장합니다.

2.4. 고정 세션 활성화

기본적으로 애플리케이션 로드 밸런서는 선택한 로드 밸런싱 알고리즘을 기반으로 각 요청을 등록된 대상으로 개별적으로 라우팅합니다. 로드 밸런서 뒤에서 자동화 허브의 여러 인스턴스를 실행할 때 인증 오류를 방지하려면 고정 세션을 활성화해야 합니다. 고정 세션을 활성화하면 로드 밸런서에 구성된 쿠키와 일치하는 사용자 지정 애플리케이션 쿠키가 설정되어 고정성을 활성화합니다. 이 사용자 지정 쿠키는 애플리케이션에 필요한 모든 쿠키 속성을 포함할 수 있습니다.

3장. 송신 프록시를 사용하도록 Ansible Automation Platform 구성

프록시 서버를 통해 다양한 용도로 플랫폼에서 송신하도록 Ansible Automation Platform을 배포할 수 있습니다. 송신 프록시를 사용하면 클라이언트가 프록시 서버를 통해 네트워크 서비스에 대한 간접 요청을 수행할 수 있습니다. 클라이언트는 먼저 프록시 서버에 연결하고 다른 서버에 있는 이메일과 같은 일부 리소스를 요청합니다. 그런 다음 프록시 서버는 지정된 서버에 연결하여 해당 서버에서 리소스를 검색합니다.

3.1. 개요

송신 프록시는 모든 RPM 및 컨테이너화된 설치 방법에 대해 Ansible Automation Platform의 시스템 및 구성 요소 수준에서 구성해야 합니다. 컨테이너화된 설치 프로그램의 경우 노드에서 podman의 시스템 프록시 구성은 프록시를 통해 액세스하는 대부분의 문제를 해결합니다. RPM 설치의 경우 시스템 및 구성 요소 구성이 모두 필요합니다.

3.1.1. 프록시 백엔드

HTTP 및 HTTPS 프록시의 경우 squid 서버를 사용할 수 있습니다. squid는 HTTP, HTTPS 및 FTP를 지원하는 웹을 위한 전달 프록시로, 자주 요청되는 웹 페이지를 캐싱하고 재사용하여 대역폭을 줄이고 응답 시간을 개선합니다. GNU GPL에 따라 라이센스가 부여됩니다. 전달 프록시는 다른 네트워크(일반적으로 인터넷)로 이동하여 내부 시스템을 대신하여 네트워크 트래픽을 가로채는 시스템입니다. squid 프록시를 사용하면 필요한 모든 통신을 통과할 수 있습니다.

필요한 모든 Ansible Automation Platform 컨트롤 플레인 포트가 squid 프록시 백엔드에서 열려 있는지 확인합니다. Ansible Automation Platform 특정 포트:

acl Safe_ports port 81
acl Safe_ports port 82
acl Safe_ports port 389
acl Safe_ports port 444
acl Safe_ports port 445
acl SSL_ports port 22
Copy to Clipboard Toggle word wrap

다음 포트는 컨테이너화된 설치용입니다.

acl SSL_ports port 444
acl SSL_ports port 445
acl SSL_ports port 8443
acl SSL_ports port 8444
acl SSL_ports port 8445
acl SSL_ports port 8446
acl SSL_ports port 44321
acl SSL_ports port 44322

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
Copy to Clipboard Toggle word wrap

3.2. 시스템 프록시 구성

아웃바운드 프록시는 컨트롤 플레인의 모든 노드에 대해 시스템 수준에 구성됩니다.

다음 환경 변수를 설정해야 합니다.

http_proxy=“http://external-proxy_0:3128”
https_proxy=“http://external-proxy_0:3128”
no_proxy=“localhost,127.0.0.0/8,10.0.0.0/8”
Copy to Clipboard Toggle word wrap

해당 변수를 /etc/environment 파일에 추가하여 영구적으로 만들 수도 있습니다.

설치 프로그램은 설치 중에 모든 외부 통신이 프록시를 통과하도록 합니다. 컨테이너화된 설치의 경우 해당 변수는 podman이 egress 프록시를 사용하는지 확인합니다.

3.3. 자동화 컨트롤러 설정

RPM 설치 프로그램을 사용한 후 송신 프록시를 사용하도록 자동화 컨트롤러를 구성해야 합니다.

참고

podman은 시스템 구성된 프록시를 사용하고 모든 컨테이너 트래픽을 프록시로 리디렉션하므로 컨테이너화된 설치 관리자에는 필요하지 않습니다.

자동화 컨트롤러의 경우 /api/v2/settings/ 에서 AWX_TASK_ENV 변수를 설정합니다. UI를 통해 이 작업을 수행하려면 다음 절차를 사용합니다.

프로세스

  1. 탐색 패널에서 SettingsAutomation ExecutionJob 을 선택합니다.
  2. 편집을 클릭합니다.
  3. 추가 환경 변수 필드에 변수 를 추가합니다.

    및 설정:

    "AWX_TASK_ENV": {
    "http_proxy": "http://external-proxy_0:3128",
    "https_proxy": "http://external-proxy_0:3128",
    "no_proxy": "localhost,127.0.0.0/8"
                    }
    Copy to Clipboard Toggle word wrap

RPM 기반 Ansible Automation Platform의 다음 절차에서는 SSH 프로토콜을 사용하여 프록시 서버와 함께 작동하여 자동화 컨트롤러 프로젝트 동기화를 사용하는 방법을 설명합니다.

프로세스

  1. 자동화 컨트롤러 노드에서 다음 단계를 수행합니다. ansible-builder가 아직 설치되지 않은 경우 먼저 설치합니다.

    # subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms
    # dnf install ansible-builder
    Copy to Clipboard Toggle word wrap
  2. 사용자 정의 실행 환경을 빌드합니다.

    1. 먼저 작업 디렉터리를 생성합니다.

      # su - awx
      $ mkdir -p builder/newee
      $ cd builder/newee
      Copy to Clipboard Toggle word wrap
  3. 다음 콘텐츠를 사용하여 execution-environment.yml 파일을 생성합니다.

    version: 1
    
    build_arg_defaults:
      EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel8:latest'
    
    additional_build_steps:
      prepend:
        - RUN microdnf install -y nc
    Copy to Clipboard Toggle word wrap
  4. registry.redhat.io에 로그인합니다.

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap
  5. ansible-builder를 실행하여 빌드 프로세스를 시작합니다.

    $ cd /var/lib/awx/builder/newee/
    $ ansible-builder build -t my-env -v 3
    Copy to Clipboard Toggle word wrap
  6. 생성한 사용자 정의 실행 환경을 추가합니다.
  7. 탐색 패널에서 자동화 실행 인프라 실행환경을 선택합니다.
  8. 실행 환경 생성을 클릭합니다.
  9. 이미지 필드에 localhost/my-env:latest 를 추가합니다.
  10. 실행 환경 생성을 클릭합니다.
  11. Ansible Automation Platform 설치 프로그램을 프로젝트 동기화로 사용할 사용자 지정 환경에서 실행 환경을 기본값에서 교체하는 다음 단계로 다시 실행합니다.

    참고

    설치 프로그램을 실행하기 전에 Ansible Automation Platform을 백업합니다.

    # ./setup.sh -b
    Copy to Clipboard Toggle word wrap
  12. setup.sh 파일과 동일한 위치에 있는 group_vars 디렉터리에 자동화 컨트롤러 파일을 생성합니다. 파일 내용은 다음과 같습니다.

    control_plane_execution_environment: localhost/my-env
    Copy to Clipboard Toggle word wrap
  13. setup.sh실행

    # ./setup.sh
    Copy to Clipboard Toggle word wrap
  14. 디렉터리에 ssh_config 를 만듭니다. 예를 들면 다음과 같습니다.

    Host github.com
    Hostname ssh.github.com
    ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p
    User git
    Copy to Clipboard Toggle word wrap
  15. 컨테이너 실행 환경에서 ssh_config 파일을 읽을 수 있도록 PATH에 ssh_config 파일의 디렉터리 경로를 추가하여 격리된 작업을 노출합니다.
  16. 탐색 패널에서 SettingsAutomation ExecutionJob 을 선택합니다.
  17. 편집을 클릭합니다.
  18. ssh_config 파일이 /var/lib/awx/.ssh/ssh_config 로 생성된 경우 격리된 작업에 노출할경로에 이 파일을 추가합니다.

    참고

    ssh_config 가 AWX 사용자가 소유하고 있는지 확인합니다. (#chown awx:awx /var/lib/awx/.ssh/ssh_config)

    [
    "/var/lib/awx/.ssh:/etc/ssh:O"
    ]
    Copy to Clipboard Toggle word wrap

3.4. AWS 인벤토리 동기화에 구성 가능한 프록시 환경 활성화

AWS 인벤토리 동기화에 대해 구성 가능한 프록시 환경을 활성화하려면 수동으로 재정의 구성 파일을 편집하거나 플랫폼 UI에서 구성을 설정할 수 있습니다.

  1. /usr/lib/systemd/system/receptor.service.d/override.conf 를 수동으로 편집하고 여기에 다음 http_proxy 환경 변수를 추가합니다.

    http_proxy:<value>
    https_proxy:<value>
    proxy_username:<value>
    Proxy_password:<value>
    Copy to Clipboard Toggle word wrap

    또는

  2. UI를 통해 이 작업을 수행하려면 다음 절차를 사용합니다.

프로세스

  1. 탐색 패널에서 SettingsAutomation ExecutionJob 을 선택합니다.
  2. 편집을 클릭합니다.
  3. 추가 환경 변수 필드에 변수 를 추가합니다.

    예: *

"AWX_TASK_ENV": {
        "no_proxy": "localhost,127.0.0.0/8,10.0.0.0/8",
        "http_proxy": "http://proxy_host:3128/",
        "https_proxy": "http://proxy_host:3128/"
                },
Copy to Clipboard Toggle word wrap

3.5. 자동화 허브에서 프록시 설정 구성

프라이빗 자동화 허브가 네트워크 프록시 뒤에 있는 경우 로컬 네트워크 외부에 있는 콘텐츠를 동기화하도록 원격에 프록시 설정을 구성할 수 있습니다.

사전 요구 사항

  • 수정 Ansible 리포지토리 콘텐츠 권한이 있습니다. 권한에 대한 자세한 내용은 액세스 관리 및 인증을 참조하십시오.
  • 다음 예제와 같이 Ansible Galaxy에서 동기화할 컬렉션을 식별하는 requirements.yml 파일이 있습니다.

    requirements.yml 예

    collections:
      # Install a collection from Ansible Galaxy.
      - name: community.aws
        version: 5.2.0
        source: https://galaxy.ansible.com
    Copy to Clipboard Toggle word wrap

프로세스

  1. Ansible Automation Platform에 로그인합니다.
  2. 탐색 패널에서 Automation ContentRemotes 를 선택합니다.
  3. 커뮤니티 원격의 세부 정보 탭에서 원격 편집을 클릭합니다.
  4. YAML requirements 필드에 requirements.yml 파일의 내용을 붙여넣습니다.
  5. 원격 저장을 클릭합니다.

결과

이제 Ansible Galaxy의 requirements.yml 파일에서 식별된 컬렉션을 프라이빗 자동화 허브로 동기화할 수 있습니다.

다음 단계

동기화 단계는 자동화 허브에서 Ansible 콘텐츠 컬렉션 동기화를 참조하십시오.

3.6. 이벤트 기반 Ansible에서 프록시 설정 구성

이벤트 기반 Ansible의 경우 프록시를 설정할 글로벌 설정이 없습니다. 모든 프로젝트에 대해 프록시를 지정해야 합니다.

프로세스

  1. 탐색 패널에서 자동화 의사 결정프로젝트를 선택합니다.
  2. 프로젝트 생성을클릭합니다.

Proxy 필드를 사용합니다.

3.7. 자동화 메시에 대한 프록시 설정 구성

프록시 서버를 통해 자동화 메시 노드의 수신기에서 아웃바운드 통신을 라우팅할 수 있습니다. 프록시가 TLS 인증서를 제거하지 않으면 Ansible Automation Platform 설치가 프록시 서버 사용을 자동으로 지원합니다.

메시의 모든 노드에는 설치 프로그램이 사용자를 대신하여 생성하는 인증 권한이 있어야 합니다.

인증 기관의 기본 설치 위치는 다음과 같습니다.

/etc/receptor/tls/ca/mesh-CA.crt

사용자를 대신하여 생성된 인증서 및 키는 이름에 nodeID를 사용합니다.

인증서의 경우: /etc/receptor/tls/NODEID.crt

키의 경우: /etc/receptor/tls/NODEID.key

4장. 고급 구성

플랫폼 관리자는 고급 구성을 구현하여 데이터베이스 연결, 로깅, 캐싱, gRPC 서버 매개변수를 포함하여 Ansible Automation Platform을 사용자 지정할 수 있습니다.

4.1. settings.py 파일

플랫폼 관리자는 settings.py 파일을 수정하여 데이터베이스 연결, 로깅 구성, 캐싱 등과 같은 Ansible Automation Platform의 다양한 측면을 구성할 수 있습니다.

두 개의 settings.py 파일이 있습니다. 기본 settings.py 파일은 코드베이스의 일부이며 편집해서는 안 되며 기본값을 재정의하는 데 사용할 수 있는 덮어쓰기 파일입니다.

재정의 설정.py 파일의 위치 및 관리는 배포(RPM 기반, 컨테이너 기반 설치 또는 운영자 기반 설치)에 따라 다를 수 있습니다.

4.1.1. RPM 배포

RPM 기반 설정의 덮어쓰기 settings.py 파일은 직접 편집할 수 있으며 플랫폼 게이트웨이 서비스를 다시 시작한 후 변경 사항이 적용됩니다. 파일을 편집하도록 선택하는 경우 적절한 구문 및 값을 사용해야 합니다. override settings.py 파일은 다음 디렉터리에 있습니다.

/etc/ansible-automation-platform/gateway/settings.py
Copy to Clipboard Toggle word wrap

4.1.2. 컨테이너 기반 배포

컨테이너 기반 설치 배포의 경우 Ansible Automation Platform은 컨테이너 내에서 실행되며 settings.py 파일은 컨테이너 내부에 포함됩니다. 그러나 업그레이드 또는 새 설치 중에 settings.py 파일을 덮어쓰므로 컨테이너 기반 설치 배포에서 settings.py 파일을 직접 편집하는 것은 권장되지 않습니다.

컨테이너 기반 설치 배포에서 설정을 사용자 지정하려면 extra_settings 매개변수를 사용하여 설치 프로그램 업데이트를 통해 사용자 지정이 유지되도록 할 수 있습니다. 자세한 내용은 컨테이너화된 설치 가이드의 인벤토리 파일 변수를 참조하십시오.

4.1.3. Operator 기반 배포

Operator 기반 설치 배포의 경우 settings.py 파일은 일반적으로 컨테이너 내부에 있지만 Red Hat OpenShift Container Platform의 컨테이너가 읽기 전용이므로 컨테이너에 직접 settings.py 파일을 수정할 수 없습니다.

대신 운영자 기반 배포의 경우 Ansible Automation Platform 사용자 정의 리소스에서 spec.extra_settings 매개변수를 사용하여 플랫폼 게이트웨이의 설정을 수정할 수 있습니다.

4.2. grpc_settings.py 파일

플랫폼 관리자는 grpc_settings.py 파일을 사용하여 gRPC 서버의 특수 또는 사용자 지정 매개변수를 정의할 수 있습니다.

두 개의 gRPC 설정 파일이 있습니다. 기본 grpc_default.py 는 코드베이스의 일부이며 편집해서는 안 되며 기본값을 재정의하는 데 사용할 수 있는 덮어쓰기 파일입니다. grpc_default.py 파일에는 정상적인 gRPC 연결을 유지하고 중단을 방지하기 위해 데이터베이스 keepalive OPTIONS가 포함되어 있습니다. 이러한 기본값을 변경해야 하는 경우 grpc_settings.py 파일을 사용하여 grpc_defauly.py 파일의 값을 재정의할 수 있습니다.

재정의 grpc_settings.py 파일의 위치 및 관리는 배포에 따라 다를 수 있습니다(RPM 기반, 컨테이너 기반 설치 또는 운영자 기반 설치).

4.2.1. RPM 배포

RPM 기반 설정의 재정의 grpc_settings.py 파일은 직접 편집할 수 있으며 게이트웨이 systemd 서비스를 다시 시작한 후 변경 사항이 적용됩니다. 파일을 편집하도록 선택하는 경우 적절한 구문 및 값을 사용해야 합니다. 재정의 grpc_settings.py 파일은 다음 디렉터리에 있습니다.

/etc/ansible-automation-platform/gateway/grpc_settings.py
Copy to Clipboard Toggle word wrap

4.2.2. grpc_settings.py 파일을 수정할 때의 영향

gRPC 서버는 다양한 플랫폼 서비스 간의 인증을 지원합니다. grpc_settings.py 파일에서 설정을 변경하면 특히 연결 안정성 측면에서 gRPC 연결의 동작 및 성능에 큰 영향을 미칠 수 있습니다.

gRPC 서버가 예상대로 작동하는지 확인하기 위해 프로덕션에 배포하기 전에 gRPC 설정에 대한 모든 변경 사항을 철저히 테스트하는 것이 중요합니다.

4.3. 설정 로드 순서

플랫폼 게이트웨이는 애플리케이션 설정을 관리하기 위해 Dynaconf 라이브러리를 활용합니다. Dynaconf는 여러 소스의 설정이 정의된 순서로 로드되고 나중에 소스가 이전 소스를 재정의하는 계층화된 구성 접근 방식을 따릅니다. Ansible Automation Platform은 다음 순서로 설정을 로드합니다.

  1. 애플리케이션 설정.py: 이 파일은 애플리케이션 자체에 있으며 추가 설정 파일의 로드 순서와 위치를 정의합니다.
  2. 애플리케이션 기본 설정: 플랫폼은 애플리케이션 자체의 일부인 defaults.py 파일에서 기본 설정을 로드합니다. 이 파일에는 API 서버와 gRPC 서버 모두에 대한 일반 구성이 포함되어 있습니다.
  3. 고객 덮어쓰기 파일: /etc/ansible-automation-platform/gateway/settings.py 파일이 자동으로 설치되고 defaults.py 의 설정을 재정의하는 데 사용할 수 있습니다. 이 파일의 변경 사항은 API 및 gRPC 서버 모두에 영향을 미칩니다.
  4. Application gRPC 기본 설정: 고객이 파일을 재정의한 후 애플리케이션은 grpc_default.py 파일에서만 gRPC 서버에 대한 추가 기본 설정을 로드합니다. 특히 이 파일에는 keepalive 매개변수와 같은 gRPC 서버의 데이터베이스 OPTIONS가 포함됩니다.
  5. Customer gRPC 덮어쓰기 파일: /etc/ansible-automation-platform/gateway/grpc_settings.py 파일이 다음에 로드되고 이 파일에 포함된 모든 설정은 gRPC 서버에만 적용됩니다.
  6. 플랫폼 덮어쓰기 설정 파일: /etc/ansible-automation-platform/settings.py 파일의 모든 설정은 gRPC 서버와 API 서버 모두에 적용됩니다. 단일 노드에 Ansible Automation Platform 서비스가 여러 개 있는 경우 이 파일의 항목이 모든 서비스에 적용됩니다.
  7. ENV vars: 구성 파일 외부에서 특정 Ansible Automation Platform 설정을 구성할 수 있는 환경 변수가 마지막으로 로드됩니다. 이전에 로드된 모든 설정을 재정의합니다.

5장. 자동화 컨트롤러에서 사용성 분석 및 데이터 수집 관리

자동화 컨트롤러 사용자 인터페이스에서 설정을 선택하거나 변경하여 자동화 컨트롤러에서 사용성 분석 및 데이터 수집에 참여하는 방법을 변경할 수 있습니다.

5.1. 유용성 분석 및 데이터 수집

사용성 데이터 수집은 자동화 컨트롤러 사용자가 자동화 컨트롤러와 구체적으로 상호 작용하는 방식을 더 잘 이해하고, 향후 릴리스를 개선하고, 사용자 환경을 계속 간소화하기 위해 데이터를 수집할 수 있는 자동화 컨트롤러에 포함되어 있습니다.

자동화 컨트롤러 평가판 또는 자동화 컨트롤러 신규 설치를 설치하는 사용자만 이 데이터 수집에 옵트인됩니다.

5.1.1. 자동화 컨트롤러에서 데이터 수집 제어

자동화 컨트롤러에서 SettingsAutomation ExecutionSystem 메뉴에서 데이터를 수집하는 방법을 제어할 수 있습니다.

프로세스

  1. 자동화 컨트롤러에 로그인합니다.
  2. 탐색 패널에서 SettingsAutomation ExecutionSystem 을 선택합니다.
  3. Automation Analytics에 대한 데이터 수집을 선택하여 자동화 컨트롤러에서 자동화에 대한 데이터를 수집하여 Automation Analytics로 보낼 수 있습니다.

6장. SSL/TLS 인증서 갱신 및 변경

현재 SSL/TLS 인증서가 만료되었거나 곧 만료되는 경우 Ansible Automation Platform에서 사용하는 SSL/TLS 인증서를 갱신하거나 교체할 수 있습니다.

새 호스트와 같은 새 정보로 다시 생성해야 하는 경우 SSL/TLS 인증서를 갱신해야 합니다.

내부 인증 기관에서 서명한 인증서를 사용하려면 SSL/TLS 인증서를 교체해야 합니다.

6.1. 컨테이너 기반 설치

컨테이너 기반 Ansible Automation Platform 설치에 대한 TLS 인증서 및 키를 변경할 수 있습니다. 이 프로세스에는 새 사용자 지정 인증서를 제공하거나 이전 인증서를 삭제하거나 이동한 다음 설치 프로그램을 실행하는 준비 단계가 포함됩니다.

6.1.1. 설치 프로그램을 사용하여 TLS 인증서 및 키 변경

다음 절차에서는 설치 프로그램을 사용하여 TLS 인증서 및 키를 업데이트하는 방법을 설명합니다.

프로세스

  1. 인증서 및 키를 준비하려면 다음 방법 중 하나를 선택합니다.

    • 사용자 정의 인증서 제공 - 업데이트된 TLS 인증서가 필요한 각 서비스에 대해 새 인증서와 키를 Ansible Automation Platform 설치 프로그램을 기준으로 경로에 복사합니다. 그런 다음 새 파일의 절대 경로로 인벤토리 파일 변수를 업데이트합니다.

      # Platform gateway
      gateway_tls_cert=<path_to_tls_certificate>
      gateway_tls_key=<path_to_tls_key>
      gateway_pg_tls_cert=<path_to_tls_certificate>
      gateway_pg_tls_key=<path_to_tls_key>
      gateway_redis_tls_cert=<path_to_tls_certificate>
      gateway_redis_tls_key=<path_to_tls_key>
      
      # Automation controller
      controller_tls_cert=<path_to_tls_certificate>
      controller_tls_key=<path_to_tls_key>
      controller_pg_tls_cert=<path_to_tls_certificate>
      controller_pg_tls_key=<path_to_tls_key>
      
      # Automation hub
      hub_tls_cert=<path_to_tls_certificate>
      hub_tls_key=<path_to_tls_key>
      hub_pg_tls_cert=<path_to_tls_certificate>
      hub_pg_tls_key=<path_to_tls_key>
      
      # Event-Driven Ansible
      eda_tls_cert=<path_to_tls_certificate>
      eda_tls_key=<path_to_tls_key>
      eda_pg_tls_cert=<path_to_tls_certificate>
      eda_pg_tls_key=<path_to_tls_key>
      eda_redis_tls_cert=<path_to_tls_certificate>
      eda_redis_tls_key=<path_to_tls_key>
      
      # PostgreSQL
      postgresql_tls_cert=<path_to_tls_certificate>
      postgresql_tls_key=<path_to_tls_key>
      
      # Receptor
      receptor_tls_cert=<path_to_tls_certificate>
      receptor_tls_key=<path_to_tls_key>
      Copy to Clipboard Toggle word wrap
    • 새 인증서를 생성하려면 설치 프로그램에서 서비스에 대한 새 인증서를 생성하거나 기존 인증서 및 키를 삭제하거나 이동합니다.

      Expand
      표 6.1. 서비스당 인증서 및 키 파일 경로
      서비스인증서 파일 경로키 파일 경로

      자동화 컨트롤러

      ~/AAP/controller/etc/tower.cert

      ~/AAP/controller/etc/tower.key

      이벤트 기반 Ansible

      ~/aap/eda/etc/eda.cert

      ~/aap/eda/etc/eda.key

      플랫폼 게이트웨이

      ~/aap/gateway/etc/gateway.cert

      ~/aap/gateway/etc/gateway.key

      자동화 허브

      ~/AAP/hub/etc/pulp.cert

      ~/AAP/hub/etc/pulp.key

      PostgreSQL

      ~/aap/postgresql/server.crt

      ~/aap/postgresql/server.key

      수신기

      ~/AAP/receptor/etc/receptor.crt

      ~/AAP/receptor/etc/receptor.key

      Redis

      ~/AAP/redis/server.crt

      ~/AAP/redis/server.key

  2. 인증서를 준비한 후 설치 디렉터리에서 설치 플레이북을 실행합니다.

    ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap

검증

서비스가 실행 중이고 액세스 가능한지 확인하여 새 TLS 인증서가 사용 중인지 확인합니다. 이렇게 하려면 curl 을 사용하여 특정 끝점을 확인합니다.

$ curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
Copy to Clipboard Toggle word wrap

이 명령의 출력은 TLS 핸드셰이크에 대한 세부 정보를 제공합니다. 다음 출력을 검색하여 올바른 인증서가 사용 중인지 확인합니다.

*  SSL certificate verify OK
Copy to Clipboard Toggle word wrap

6.2. Operator 기반 설치

다음 절차에서는 OpenShift Container Platform에서 실행되는 자동화 컨트롤러의 SSL 인증서 및 키를 변경하는 방법을 설명합니다.

프로세스

  1. 서명된 SSL 인증서 및 키를 보안 위치에 복사합니다.
  2. OpenShift 내에 TLS 시크릿을 생성합니다.

    oc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.key
    Copy to Clipboard Toggle word wrap
  3. 자동화 컨트롤러 사용자 정의 리소스를 수정하여 route_tls_secret 및 새 시크릿 이름을 spec 섹션에 추가합니다.

    oc edit automationcontroller/${CONTROLLER_INSTANCE}
    Copy to Clipboard Toggle word wrap
    ...
    spec:
      route_tls_secret: automation-controller-certs-2023-04-06
    ...
    Copy to Clipboard Toggle word wrap

TLS 시크릿의 이름은 임의의 이름입니다. 이 예에서는 시크릿이 생성된 날짜로 타임스탬프를 지정하여 자동화 컨트롤러 인스턴스에 적용된 다른 TLS 보안과 구별합니다.

  1. 변경 사항을 적용할 때까지 몇 분 정도 기다립니다.
  2. 새 SSL 인증서 및 키가 설치되었는지 확인합니다.

    true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443
    Copy to Clipboard Toggle word wrap

6.2.2. OpenShift Container Platform에서 자동화 허브의 SSL 인증서 및 키 변경

다음 절차에서는 OpenShift Container Platform에서 실행되는 자동화 허브의 SSL 인증서 및 키를 변경하는 방법을 설명합니다.

프로세스

  1. 서명된 SSL 인증서 및 키를 보안 위치에 복사합니다.
  2. OpenShift 내에 TLS 시크릿을 생성합니다.

    oc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.key
    Copy to Clipboard Toggle word wrap
  3. 자동화 허브 사용자 정의 리소스를 수정하여 route_tls_secret 및 새 시크릿 이름을 spec 섹션에 추가합니다.

    oc edit automationhub/${AUTOMATION_HUB_INSTANCE}
    Copy to Clipboard Toggle word wrap
    ...
    spec:
      route_tls_secret: automation-hub-certs-2023-04-06
    ...
    Copy to Clipboard Toggle word wrap

TLS 시크릿의 이름은 임의의 이름입니다. 이 예에서는 시크릿이 생성된 날짜로 타임스탬프를 지정하여 자동화 허브 인스턴스에 적용된 다른 TLS 시크릿과 구별합니다.

  1. 변경 사항을 적용할 때까지 몇 분 정도 기다립니다.
  2. 새 SSL 인증서 및 키가 설치되었는지 확인합니다.

    true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443
    Copy to Clipboard Toggle word wrap

6.3. RPM 기반 설치

RPM 기반 설치를 위한 SSL 인증서를 갱신하거나 변경하려면 인벤토리 파일을 편집하고 설치 프로그램을 실행할 수 있습니다. 설치 프로그램은 모든 Ansible Automation Platform 구성 요소가 작동하는지 확인합니다.

또는 수동으로 SSL 인증서를 변경할 수 있습니다. 이는 더 빠르지만 자동 확인은 없습니다.

설치 프로그램을 사용하여 Ansible Automation Platform 배포를 변경하는 것이 좋습니다.

6.3.1. 자체 서명된 SSL/TLS 인증서 업데이트

다음 단계에서는 모든 Ansible Automation Platform 구성 요소에 대해 새 SSL/TLS 인증서를 다시 생성합니다.

프로세스

  1. [all:vars] 섹션의 인벤토리 파일에 aap_service_regen_cert=true 를 추가합니다.

    [all:vars]
    aap_service_regen_cert=true
    Copy to Clipboard Toggle word wrap
  2. 설치 프로그램을 실행합니다.

검증

  • Event-Driven Ansible 컨트롤러에서 CA 파일 및 인증서 파일을 검증합니다.

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert
    openssl s_client -connect <EDA_FQDN>:443
    Copy to Clipboard Toggle word wrap
  • 플랫폼 게이트웨이에서 CA 파일 및 인증서 파일을 확인합니다.

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert
    openssl s_client -connect <GATEWAY_FQDN>:443
    Copy to Clipboard Toggle word wrap
  • 자동화 허브에서 CA 파일 및 인증서 파일을 확인합니다.

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt
    openssl s_client -connect <HUB_FQDN>:443
    Copy to Clipboard Toggle word wrap
  • 자동화 컨트롤러에서 CA 파일 및 인증서 파일을 확인합니다.

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert
    openssl s_client -connect <CONTROLLER_FQDN>:443
    Copy to Clipboard Toggle word wrap

6.3.2. 설치 프로그램을 사용하여 SSL/TLS 인증서 및 키 변경

다음 절차에서는 인벤토리 파일에서 SSL/TLS 인증서 및 키를 변경하는 방법을 설명합니다.

사전 요구 사항

  • 인증서는 PEM 형식이어야 합니다.
  • 중간 인증 기관이 있는 경우 서버 인증서에 추가해야 합니다.
  • 인증서에 대해 올바른 순서를 사용합니다. 서버 인증서가 먼저 오고 중간 인증 기관이 있습니다.

자세한 내용은 NGINX 문서의 ssl 인증서 섹션을 참조하십시오.

프로세스

  1. 새 SSL/TLS 인증서 및 키를 Ansible Automation Platform 설치 프로그램 관련 경로에 복사합니다.
  2. SSL/TLS 인증서 및 키의 절대 경로를 인벤토리 파일에 추가합니다. 이러한 변수 설정에 대한 지침은 인벤토리 파일 변수를 참조하십시오.

    • 이벤트 기반 Ansible 컨트롤러: automationedacontroller_ssl_cert,automationedacontroller_ssl_key,custom_ca_cert
    • 플랫폼 게이트웨이: automationgateway_ssl_cert,automationgateway_ssl_key,custom_ca_cert
    • 자동화 허브: automationhub_ssl_cert,automationhub_ssl_key,custom_ca_cert
    • 자동화 컨트롤러: web_server_ssl_cert,web_server_ssl_key,custom_ca_cert

      참고

      custom_ca_cert 는 중간 인증 기관에 서명한 루트 인증 기관이어야 합니다. 이 파일은 /etc/pki/ca-trust/source/anchors 에 설치됩니다.

  3. 설치 프로그램을 실행합니다.

6.3.3. 수동으로 SSL/TLS 인증서 및 키 변경

다음 절차에서는 모든 Ansible Automation Platform 구성 요소에 대해 SSL/TLS 인증서 및 키를 수동으로 변경하는 방법을 설명합니다.

프로세스

  1. 현재 SSL/TLS 인증서를 백업합니다.

    cp <CERT_PATH> <CERT_PATH>-$(date +%F)
    Copy to Clipboard Toggle word wrap
  2. 현재 키 파일을 백업합니다.

    cp <KEY_PATH> <KEY_PATH>-$(date +%F)
    Copy to Clipboard Toggle word wrap
  3. 새 SSL/TLS 인증서를 인증서 경로에 복사합니다.
  4. 새 키를 키 경로에 복사합니다.
  5. SELinux 컨텍스트를 복원합니다.

    restorecon -v <CERT_PATH> <KEY_PATH>
    Copy to Clipboard Toggle word wrap
  6. 인증서 및 키 파일에 대한 적절한 권한을 설정합니다.

    chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH>
    chmod 0600 <CERT_PATH> <KEY_PATH>
    Copy to Clipboard Toggle word wrap
  7. NGINX 구성을 테스트합니다.

    nginx -t
    Copy to Clipboard Toggle word wrap
  8. NGINX를 다시 로드합니다.

    systemctl reload nginx.service
    Copy to Clipboard Toggle word wrap
  9. 새 SSL/TLS 인증서 및 키가 설치되었는지 확인합니다.

    true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443
    Copy to Clipboard Toggle word wrap
    Expand
    표 6.2. SSL/TLS 인증서 및 서비스당 키 파일 경로
    서비스인증서 파일 경로키 파일 경로소유자:Group

    자동화 컨트롤러

    /etc/tower/tower.cert

    /etc/tower/tower.key

    root:awx

    자동화 허브

    /etc/pulp/certs/pulp_webserver.crt

    /etc/pulp/certs/pulp_webserver.key

    root:pulp

    이벤트 기반 Ansible 컨트롤러

    /etc/ansible-automation-platform/eda/server.cert

    /etc/ansible-automation-platform/eda/server.key

    root:eda

    플랫폼 게이트웨이

    /etc/ansible-automation-platform/gateway/gateway.cert

    /etc/ansible-automation-platform/gateway/gateway.key

    root:gateway

법적 공지

Copyright © 2025 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.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동