Red Hat Ansible Automation Platform 업그레이드 및 마이그레이션 가이드

Red Hat Ansible Automation Platform 2.1

최신 버전의 Ansible Automation Platform으로 업그레이드하고 기존 가상 환경을 자동화 실행 환경으로 마이그레이션

Red Hat Customer Content Services

초록

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

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

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

1장. 격리된 노드를 실행 노드로 업그레이드

버전 1.x에서 Red Hat Ansible Automation Platform의 최신 버전으로 업그레이드하려면 플랫폼 관리를 통해 격리된 기존 노드에서 실행 노드로 데이터를 마이그레이션해야 합니다. 이 마이그레이션은 자동화 메시를 배포하는 데 필요합니다.

이 가이드에서는 병렬 마이그레이션을 수행하는 방법을 설명합니다. 이렇게 하면 마이그레이션 프로세스 중에 원래 자동화 환경의 데이터가 그대로 유지됩니다.

마이그레이션 프로세스에는 다음 단계가 포함됩니다.

  1. 업그레이드 구성을 확인합니다.
  2. 원래 인스턴스를 백업합니다.
  3. 병렬 업그레이드를 위해 새 인스턴스를 배포합니다.
  4. ansible 컨트롤러를 사용하여 새 인스턴스에서 인스턴스 그룹을 재생성합니다.
  5. 원래 백업을 새 인스턴스로 복원합니다.
  6. 실행 노드를 설정하고 인스턴스를 Red Hat Ansible Automation Platform 2.1으로 업그레이드합니다.
  7. 업그레이드된 컨트롤러 인스턴스를 구성합니다.

1.1. Ansible Automation Platform 업그레이드를 위한 사전 요구 사항

Ansible Automation Platform 업그레이드를 시작하기 전에 환경이 다음 노드 및 구성 요구 사항을 충족하는지 확인하십시오.

1.1.1. 노드 요구 사항

Ansible Automation Platform 업그레이드 프로세스와 관련된 노드에 다음 사양이 필요합니다.

  • 컨트롤러 노드, 데이터베이스 노드, 실행 노드 및 홉 노드용 16GB RAM.
  • 컨트롤러 노드, 데이터베이스 노드, 실행 노드 및 홉 노드의 CPU 4개
  • 데이터베이스 노드의 150GB 이상의 디스크 공간
  • 데이터베이스 이외의 노드의 경우 40GB 이상의 디스크 공간
  • DHCP 예약은 무한 리스를 사용하여 고정 IP 주소로 클러스터를 배포합니다.
  • 모든 노드의 DNS 레코드입니다.
  • 모든 노드에 대해 설치된 Red Hat Enterprise Linux 8 이상 64비트(x86)입니다.
  • 모든 노드에 대해 구성된 chrony입니다.
  • 모든 콘텐츠 종속성에 대한 Python 3.8 이상

1.1.2. 자동화 컨트롤러 구성 요구사항

Ansible Automation Platform 업그레이드 프로세스를 진행하기 전에 다음 자동화 컨트롤러 구성이 필요합니다.

Chrony를 사용하여 NTP 서버 구성

클러스터의 각 Ansible Automation Platform 노드는 NTP 서버에 액세스할 수 있어야 합니다. chronyd 를 사용하여 시스템 시계를 NTP 서버와 동기화합니다. 이렇게 하면 노드 간 날짜 및 시간이 동기화되지 않는 경우 검증이 필요한 SSL 인증서를 사용하는 클러스터 노드가 실패하지 않습니다.

이는 업그레이드된 Ansible Automation Platform 클러스터에 사용된 모든 노드에 필요합니다.

  1. chrony 를 설치합니다.

    # dnf install chrony --assumeyes
  2. 텍스트 편집기를 사용하여 /etc/chrony.conf 를 엽니다.
  3. 공용 서버 풀 섹션을 찾아 적절한 NTP 서버 주소를 포함하도록 수정합니다. 하나의 서버만 필요하지만 3개의 서버를 사용하는 것이 좋습니다. iburst 옵션을 추가하여 서버와 올바르게 동기화하는 데 걸리는 시간을 단축합니다.

    # Use public servers from the pool.ntp.org project.
    # Please consider joining the pool (http://www.pool.ntp.org/join.html).
    server <ntp-server-address> iburst
  4. /etc/chrony.conf 파일에 변경 사항을 저장합니다.
  5. 호스트를 시작하고 chronyd 데몬을 활성화합니다.

    # systemctl --now enable chronyd.service
  6. chronyd 데몬 상태를 확인합니다.

    # systemctl status chronyd.service

모든 노드에 Red Hat 서브스크립션 연결

Red Hat Ansible Automation Platform을 사용하려면 모든 노드에 유효한 서브스크립션이 연결되어 있어야 합니다. 다음 명령을 실행하여 현재 노드에 Red Hat 서브스크립션이 있는지 확인할 수 있습니다.

# subscription-manager list --consumed

노드에 Red Hat 서브스크립션이 연결되어 있지 않은 경우 자세한 내용은 Ansible Automation Platform 서브스크립션 연결을 참조하십시오.

sudo 권한을 사용하여 root가 아닌 사용자 생성

Ansible Automation Platform을 업그레이드하기 전에 배포 프로세스에 sudo 권한이 있는 root 이외의 사용자를 생성하는 것이 좋습니다. 이 사용자는 다음을 위해 사용됩니다.

  • SSH 연결.
  • 설치 중 암호 없는 인증입니다.
  • 권한 상승(sudo) 권한.

다음 예제에서는 ansible 을 사용하여 이 사용자의 이름을 지정합니다. 업그레이드된 Ansible Automation Platform 클러스터에 사용된 모든 노드에서 ansible 이라는 root가 아닌 사용자를 생성하고 ssh 키를 생성합니다.

  1. root가 아닌 사용자를 생성합니다.

    # useradd ansible
  2. 사용자 암호를 설정합니다.

    # passwd ansible 1
    Changing password for ansible.
    Old Password:
    New Password:
    Retype New Password:
    1
    다른 이름을 사용하는 경우 1단계의 root가 아닌 사용자로 ansible 을 교체합니다.
  3. 사용자로 ssh 키를 생성합니다.

    $ ssh-keygen -t rsa
  4. sudo 사용 시 암호를 요구하지 않도록 비활성화합니다.

    # echo "ansible ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/ansible

모든 노드에 SSH 키 복사

ansible 사용자가 생성된 상태에서 업그레이드된 Ansible Automation Platform 클러스터에 사용된 모든 노드에 ssh 키를 복사합니다. 이렇게 하면 Ansible Automation Platform 설치가 실행될 때 암호 없이 모든 노드에 ssh 를 실행할 수 있습니다.

$ ssh-copy-id ansible@node-1.example.com
참고

클라우드 공급자 내에서 실행하는 경우 모든 노드에서 ansible 사용자의 공개 키가 포함된 ~/.ssh/authorized_keys 파일을 생성하고, 읽기 및 쓰기 액세스 권한(권한 600)만 소유자(Ansible)로만 권한을 authorized_keys 파일로 설정해야 할 수 있습니다.

방화벽 설정 구성

Ansible Automation Platform 업그레이드를 성공적으로 수행하기 위해 적절한 서비스 및 포트에 대한 액세스를 허용하도록 업그레이드된 Ansible Automation Platform 클러스터에 사용된 모든 노드에서 방화벽 설정을 구성합니다. Red Hat Enterprise Linux 8 이상의 경우 firewalld 데몬을 활성화하여 모든 노드에 필요한 액세스 권한을 활성화합니다.

  1. firewalld 패키지를 설치합니다.

    # dnf install firewalld --assumeyes
  2. firewalld 서비스를 시작합니다.

    # systemctl start firewalld
  3. firewalld 서비스를 활성화합니다.

    # systemctl enable --now firewalld

1.1.3. Ansible Automation Platform 구성 요구사항

Ansible Automation Platform 업그레이드 프로세스를 진행하기 전에 다음 Ansible Automation Platform 구성이 필요합니다.

실행 및 홉 노드에 대한 방화벽 설정 구성

Red Hat Ansible Automation Platform 인스턴스를 업그레이드한 후 메시 노드(실행 노드 및 홉)에 자동화 메시 포트를 추가하여 자동화 메시 기능을 활성화합니다. 모든 노드의 메시 네트워크에 사용되는 기본 포트는 27199/tcp 입니다. 인벤토리 파일 내의 각 노드의 변수로 recptor_listener_port 를 지정하여 다른 포트를 사용하도록 메시 네트워크를 구성할 수 있습니다.

홉 및 실행 노드 내에서 설치에 사용할 firewalld 포트를 설정합니다.

  1. firewalld 가 실행 중인지 확인합니다.

    $ sudo systemctl status firewalld
  2. 컨트롤러 데이터베이스 노드에 firewalld 포트를 추가합니다(예: 포트 27199).

    $ sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp
  3. firewalld 다시 로드:

    $ sudo firewall-cmd --reload
  4. 포트가 열려 있는지 확인합니다.

    $ sudo firewall-cmd --list-ports

1.2. Ansible Automation Platform 인스턴스를 백업

현재 환경의 콘텐츠 및 구성을 저장하는 backup_dir 플래그와 함께 .setup.sh 스크립트를 실행하여 기존 Ansible Automation Platform 인스턴스를 백업합니다.

  1. ansible-tower-setup-latest 디렉터리로 이동합니다.
  2. 아래 예에 따라 ./setup.sh 스크립트를 실행합니다.

    $ ./setup.sh -e ‘backup_dir=/ansible/mybackup’ -e ‘use_compression=True’ @credentials.yml -b 12
    1
    backup_dir 은 백업을 저장할 디렉터리를 지정합니다.
    2
    @credentials.yml 은 password 변수와 ansible-vault 를 통해 암호화된 값을 전달합니다.

백업에 성공하면 /ansible/mybackup/tower-backup-latest.tar.gz 에 백업 파일이 생성됩니다.

이 백업은 나중에 이전 인스턴스에서 새 인스턴스로 콘텐츠를 마이그레이션하는데 필요합니다.

1.3. 병렬 업그레이드를 위해 새 인스턴스 배포

side-by-side 업그레이드 프로세스를 진행하려면 동일한 인스턴스 그룹 구성으로 Ansible Tower 3.8.x의 두 번째 인스턴스를 배포합니다. 이 새 인스턴스는 원래 인스턴스의 콘텐츠 및 구성을 수신하며 나중에 Red Hat Ansible Automation Platform 2.1으로 업그레이드됩니다.

1.3.1. Ansible Tower의 새 인스턴스 배포

새 Ansible Tower 인스턴스를 배포하려면 다음을 수행합니다.

  1. Ansible Tower 설치 프로그램 페이지로 이동하여 원래 Tower 인스턴스와 일치하는 Tower 설치 프로그램 버전을 다운로드합니다.
  2. 설치 프로그램으로 이동한 다음 텍스트 편집기에서 인벤토리 파일을 열어 Tower 설치에 대한 인벤토리 파일을 구성합니다.

    1. Tower 구성 외에도 isolated_group 또는 instance_group 이 포함된 필드를 제거합니다.

      참고

      Ansible Automation Platform 설치 프로그램을 사용하여 Tower를 설치하는 방법에 대한 자세한 내용은 특정 설치 시나리오에 대한 Ansible Automation Platform 설치 가이드를 참조하십시오.

  3. setup.sh 스크립트를 실행하여 설치를 시작합니다.

새 인스턴스가 설치되면 원래 Tower 인스턴스의 인스턴스 그룹과 일치하도록 Tower 설정을 구성합니다.

1.3.2. 새 인스턴스에서 인스턴스 그룹을 다시 생성

새 인스턴스에서 인스턴스 그룹을 다시 생성하려면 다음을 수행합니다.

참고

원래 Tower 인스턴스의 모든 인스턴스 그룹을 기록해 둡니다. 이러한 그룹을 새 인스턴스에서 다시 생성해야 합니다.

  1. Tower의 새 인스턴스에 로그인합니다.
  2. 탐색 창에서 AdministrationInstance groups 을 선택합니다.
  3. 인스턴스 그룹 만들기를 클릭합니다.
  4. 원래 인스턴스의 인스턴스 그룹과 일치하는 이름을 입력한 다음 저장을 클릭합니다.
  5. 원래 인스턴스의 모든 인스턴스 그룹이 다시 생성될 때까지 반복합니다.

1.4. 새 인스턴스로 백업 복원

restore_backup_file 플래그를 사용하여 ./setup.sh 스크립트를 실행하면 원래 1.x 인스턴스의 백업 파일에서 새 인스턴스로 콘텐츠가 마이그레이션됩니다. 이렇게 하면 모든 작업 기록, 템플릿 및 기타 Ansible Automation Platform 관련 콘텐츠가 효과적으로 마이그레이션됩니다.

절차

  1. 다음 명령을 실행합니다.

    $ ./setup.sh -r -e ‘restore_backup_file=/ansible/mybackup/tower-backup-latest.tar.gz’ -e ‘use_compression=True’ -e @credentials.yml -r -- --ask-vault-pass 123
    1
    restore_backup_file 은 Ansible Automation Platform 백업 데이터베이스의 위치를 지정합니다.
    2
    Use_compression 은 백업 프로세스 중에 압축이 사용되기 때문에 True 로 설정됩니다.
    3
    - R은 복원 데이터베이스 옵션을 True로 설정합니다.
  2. 새로운 RHEL 8 Tower 3.8 인스턴스에 로그인하여 원래 인스턴스의 콘텐츠가 복원되었는지 확인합니다.

    1. AdministrationInstance groups (인스턴스 그룹) 로 이동합니다. 이제 다시 생성된 인스턴스 그룹에 원래 인스턴스의 합계 작업이 포함되어야 합니다.
    2. 측면 탐색 패널을 사용하여 작업, 템플릿, iPXE, 자격 증명 및 사용자를 포함하여 원래 인스턴스에서 콘텐츠를 가져왔는지 확인합니다.

이제 원래 인스턴스의 모든 Ansible 콘텐츠가 포함된 Ansible Tower의 새 인스턴스가 있습니다.

이 새 인스턴스를 Ansible Automation Platform 2.1으로 업그레이드하여 원래 인스턴스를 덮어쓰지 않고 이전 데이터를 모두 유지합니다.

1.5. Ansible Automation Platform 2.1으로 업그레이드

Ansible Tower 인스턴스를 Ansible Automation Platform 2.1으로 업그레이드하려면 원래 Tower 인스턴스에서 새 Tower 인스턴스로 인벤토리 파일을 복사하고 설치 프로그램을 실행합니다. Red Hat Ansible Automation Platform 설치 프로그램은 사전2.1 인벤토리 파일을 감지하고 업그레이드 프로세스를 계속 진행하기 위해 업그레이드된 인벤토리 파일을 제공합니다.

  1. Red Hat 고객 포털에서 Red Hat Ansible Automation Platform용 최신 설치 프로그램을 다운로드합니다.
  2. 파일을 추출합니다.

    $ tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz
  3. Ansible Automation Platform 설치 디렉터리로 이동합니다.

    $ cd ansible-automation-platform-setup-<latest-version>/
  4. 원래 인스턴스의 인벤토리 파일을 최신 설치 프로그램의 디렉터리에 복사합니다.

    $ cp ansible-tower-setup-3.8.x.x/inventory ansible-automation-platform-setup-<latest-version>
  5. setup.sh 스크립트를 실행합니다.

    $ ./setup.sh

    설정 스크립트를 일시 중지하고 "pre-2.x" 인벤토리 파일이 감지되었지만 원래 인스턴스를 계속 업그레이드할 수 있도록 inventory.new.ini 라는 새 파일을 제공합니다.

  6. 텍스트 편집기를 사용하여 inventory.new.ini 를 엽니다.

    참고

    설치 스크립트를 실행하여 설치 관리자는 원래 인벤토리 파일에서 [automationcontroller]로 이름 변경과 같은 몇 가지 필드를 수정했습니다.

  7. 새로 생성된 inventory.new.ini 파일을 수정하여 관련 변수, 노드 및 관련 노드 피어 연결을 할당하여 자동화 메시를 구성합니다.

    참고

    자동화 메시 토폴로지 설계는 환경의 자동화 요구 사항에 따라 다릅니다. 아래 예제에서는 자동화 메시 설계에 사용할 수 있는 하나의 시나리오를 제공하며 자동화 메시 토폴로지 설계는 환경의 자동화 요구 사항에 따라 다릅니다. 요구 사항에 맞는 설계에 대한 정보는 전체 Ansible Automation Platform 자동화 메시 가이드를 검토하십시오.

    홉 노드를 활용하는 세 개의 노드로 구성된 표준 컨트롤 플레인이 있는 인벤토리 파일의 예:

    [automationcontroller]
    control-plane-1.example.com
    control-plane-2.example.com
    control-plane-3.example.com
    
    [automationcontroller:vars]
    node_type=control 1
    peers=execution_nodes 2
    
    
    [execution_nodes]
    execution-node-1.example.com peers=execution-node-2.example.com
    execution-node-2.example.com peers=execution-node-3.example.com
    execution-node-3.example.com peers=execution-node-4.example.com
    execution-node-4.example.com peers=execution-node-5.example.com node_type=hop
    execution-node-5.example.com peers=execution-node-6.example.com node_type=hop 3
    execution-node-6.example.com peers=execution-node-7.example.com
    execution-node-7.example.com
    
    [execution_nodes:vars]
    node_type=execution

    1
    일반 작업이 아닌 프로젝트 및 인벤토리 업데이트 및 시스템 작업을 실행하는 제어 노드를 지정합니다. 이러한 노드에서 실행 기능이 비활성화됩니다.
    2
    [execution_nodes] 그룹에서 노드 간 연결에 대한 피어 관계를 지정합니다.
    3
    트래픽을 다른 실행 노드로 라우팅하는 홉 노드를 지정합니다. 홉 노드는 자동화를 실행할 수 없습니다.
  8. 자동화 메시를 위한 inventory.new.ini 구성을 완료한 후 inventory.new.ini 를 사용하여 설정 스크립트를 실행합니다.

    $ ./setup.sh -i inventory.new.ini -e @credentials.yml -- --ask-vault-pass
  9. 설치가 완료되면 모든 자동화 컨트롤러 노드에서 Ansible Automation Platform 대시보드 UI에 로그인하여 Ansible Automation Platform이 성공적으로 설치되었는지 확인합니다.

추가 리소스

1.6. 업그레이드된 Ansible Automation Platform 구성

1.6.1. 자동화 컨트롤러 인스턴스 그룹 구성

Red Hat Ansible Automation Platform 인스턴스를 업그레이드한 후 자동화 컨트롤러 UI에서 설정을 구성하여 원래 인스턴스를 해당 인스턴스 그룹과 연결합니다.

  1. 새 컨트롤러 인스턴스에 로그인합니다.
  2. 인증 정보, 작업, 인벤토리와 같은 이전 인스턴스의 콘텐츠가 이제 Controller 인스턴스에 표시되어야 합니다.
  3. AdministrationInstance Groups (인스턴스 그룹) 로 이동합니다.
  4. 인스턴스 그룹을 클릭하여 실행 노드를 연결한 다음 Instances 탭을 클릭합니다.
  5. Associate 를 클릭합니다. 이 인스턴스 그룹에 연결할 노드를 선택한 다음 저장 을 클릭합니다.
  6. 새 실행 노드의 연결을 끊으도록 기본 인스턴스를 수정할 수도 있습니다.

2장. 자동화 실행 환경으로 마이그레이션

2.1. 자동화 실행 환경으로 업그레이드하는 이유는 무엇입니까?

Red Hat Ansible Automation Platform 2.1은 자동화 실행 환경을 도입했습니다. 자동화 실행 환경은 단일 컨테이너 내에서 Ansible 자동화를 실행하는 데 필요한 모든 것을 포함하여 Ansible을 더 쉽게 관리할 수 있는 컨테이너 이미지입니다. 자동화 실행 환경은 다음과 같습니다.

  • RHEL UBI 8
  • Ansible 2.9 또는 Ansible Core 2.11
  • Python 3.8 이상
  • 모든 Ansible 콘텐츠 컬렉션
  • 컬렉션 python 또는 바이너리 종속 항목

Ansible은 이러한 요소를 포함하여 플랫폼 관리자에게 자동화를 실행하는 환경을 정의, 빌드 및 배포하는 표준화된 방법을 제공합니다.

새로운 자동화 실행 환경으로 인해 더 이상 관리자가 사용자 지정 플러그인 및 자동화 콘텐츠를 생성할 필요가 없습니다. 이제 관리자는 콘텐츠를 생성하기 위해 더 적은 시간에 더 작은 자동화 실행 환경을 가동할 수 있습니다.

이제 모든 사용자 지정 종속성은 관리 및 배포 단계가 아닌 개발 단계에서 정의됩니다. 컨트롤 플레인과 분리하면 환경 전반에서 개발 사이클, 확장성, 신뢰성 및 이식성이 빨라집니다. 자동화 실행 환경을 통해 Ansible Automation Platform은 분산 아키텍처로 이동할 수 있으므로 관리자가 조직 전체에서 자동화를 확장할 수 있습니다.

2.2. 레거시 venvs를 자동화 실행 환경으로 마이그레이션하는 정보

이전 버전의 자동화 컨트롤러에서 버전 4.0 이상으로 업그레이드할 때 컨트롤러는 조직, 인벤토리, 작업 템플릿과 관련된 이전 버전의 가상 환경을 감지하고 새 자동화 실행 환경 모델로 마이그레이션하도록 지시할 수 있습니다. 자동화 컨트롤러를 새로 설치하면 설치 중에 virtualenvs 두 개가 생성됩니다. 하나는 컨트롤러를 실행하고 다른 하나는 Ansible을 실행합니다. 기존 가상 환경과 마찬가지로 자동화 실행 환경을 사용하면 컨트롤러가 안정적인 환경에서 실행할 수 있으며, 플레이북을 실행하는 데 필요한 경우 자동화 실행 환경에 모듈을 추가하거나 업데이트할 수 있습니다.

자동화 실행 환경에서 새 자동화 실행 환경으로 마이그레이션하여 이전 사용자 지정 가상 환경에서 설치를 복제할 수 있습니다. 이 섹션에서 awx-manage 명령을 사용하여 다음을 수행합니다.

  • 현재 사용자 지정 가상 환경 및 해당 경로 목록(list_custom_venvs)
  • 특정 사용자 지정 가상 환경(custom_venv_associations)을 사용하는 리소스 보기
  • 자동화 실행 환경으로 마이그레이션하는 데 사용할 수 있는 형식으로 특정 사용자 지정 가상 환경을 내보냅니다(export_custom_venv).

다음 워크플로는 awx-manage 명령을 사용하여 레거시 venvs에서 자동화 실행 환경으로 마이그레이션하는 방법을 설명합니다.

2.3. 가상 환경을 자동화 실행 환경으로 마이그레이션

Red Hat Ansible Automation Platform 2.0 및 자동화 컨트롤러 4.0으로 업그레이드되면 다음 섹션을 사용하여 마이그레이션 프로세스의 추가 단계를 지원합니다.

2.3.1. 사용자 정의 가상 환경 나열

awx-manage 명령을 사용하여 자동화 컨트롤러 인스턴스의 가상 환경을 나열할 수 있습니다.

절차

  1. 자동화 컨트롤러 인스턴스에 SSH를 사용하여 다음을 실행합니다.

    $ awx-manage list_custom_venvs

검색된 가상 환경 목록이 표시됩니다.

# Discovered virtual environments:
/var/lib/awx/venv/testing
/var/lib/venv/new_env

To export the contents of a virtual environment, re-run while supplying the path as an argument:
awx-manage export_custom_venv /path/to/venv

2.3.2. 사용자 정의 가상 환경과 연결된 오브젝트 보기

awx-manage 명령을 사용하여 사용자 지정 가상 환경과 관련된 조직, 작업 및 인벤토리 소스를 확인합니다.

절차

  1. 자동화 컨트롤러 인스턴스에 SSH를 사용하여 다음을 실행합니다.

    $ awx-manage custom_venv_associations /path/to/venv

연결된 오브젝트 목록이 나타납니다.

inventory_sources:
- id: 15
  name: celery
job_templates:
- id: 9
  name: Demo Job Template @ 2:40:47 PM
- id: 13
  name: elephant
organizations
- id: 3
  name: alternating_bongo_meow
- id: 1
  name: Default
projects: []

2.3.3. 내보낼 사용자 정의 가상 환경 선택

awx-manage export_custom_venv 명령을 사용하여 내보낼 사용자 지정 가상 환경을 선택합니다.

절차

  1. 자동화 컨트롤러 인스턴스에 SSH를 사용하여 다음을 실행합니다.

    $ awx-manage export_custom_venv /path/to/venv

이 명령의 출력은 지정된 가상 환경에 있는 항목의 pip 동결 을 표시합니다. 이 정보는 Ansible Builder의 requirements.txt 파일에 복사하여 새 자동화 실행 환경 이미지를 생성할 수 있습니다.

numpy==1.20.2
pandas==1.2.4
python-dateutil==2.8.1
pytz==2021.1
six==1.16.0

To list all available custom virtual environments run:
awx-manage list_custom_venvs
참고

출력을 줄이기 위해 awx-manage list_custom_venvs 를 실행할 때 -q 플래그를 전달합니다.

2.4. 추가 리소스

3장. Ansible 콘텐츠 마이그레이션

ansible-core 버전에서 ansible-core 2.12+로 마이그레이션하는 경우 Ansible Core Porting Guides 를 검토하여 각 버전 간의 변경 사항 및 업데이트를 숙지하십시오. Ansible Core 포트 지정 가이드를 검토할 때 가이드의 왼쪽 상단에 있는 최신 버전의 ansible-core 또는 devel 을 선택해야 합니다.

완전히 지원 및 인증된 Ansible 콘텐츠 컬렉션 목록은 console.redhat.com 에서 Ansible Automation hub 를 참조하십시오.

3.1. Ansible 플레이북 및 역할을 Core 2.12로 마이그레이션

컬렉션 기반 콘텐츠에서 컬렉션 기반 콘텐츠로 마이그레이션하는 경우 예기치 않은 동작을 방지하려면 플레이북 및 역할에 FQCN(완전한 컬렉션 이름)을 사용해야 합니다.

FQCN이 있는 플레이북의 예:

- name: get some info
  amazon.aws.ec2_vpc_net_info:
    region: "{{ec2_region}}"
  register: all_the_info
  delegate_to: localhost
  run_once: true

ansible-core 모듈을 사용하고 다른 컬렉션에서 모듈을 호출하지 않는 경우 FQCN ansible.builtin.copy 를 사용해야 합니다.

FQCN이 있는 모듈의 예:

- name: copy file with owner and permissions
  ansible.builtin.copy:
  src: /srv/myfiles/foo.conf
  dest: /etc/foo.conf
  owner: foo
  group: foo
  mode: '0644'

법적 공지

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.