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

Ansible Automation Platform 2.1 이상에서 버전 2.4로 업그레이드하려면 설치 패키지를 다운로드한 다음 다음 단계를 수행해야 합니다.

Ansible Automation Platform 2.0 이하에서 버전 2.4로 업그레이드하려면 호환성을 위해 Ansible 콘텐츠를 마이그레이션해야 합니다.

다음 단계에서는 레거시 업그레이드 프로세스에 대한 개요를 제공합니다.

업그레이드 프로세스를 시작하기 전에 다음 고려 사항을 검토하여 Ansible Automation Platform 배포를 계획하고 준비합니다.

자동화 컨트롤러

자동화 허브

이벤트 기반 Ansible 컨트롤러

Red Hat Enterprise Linux 환경 인터넷 연결을 기반으로 필요한 Red Hat Ansible Automation Platform 설치 프로그램을 선택합니다. 다음 시나리오를 검토하고 요구 사항을 충족하는 Red Hat Ansible Automation Platform 설치 프로그램을 결정합니다.

tarball 설치

RPM 설치

RPM 설치 프로그램을 사용하면 파일이 /opt/ansible-automation-platform/installer 디렉터리에 배치됩니다.

Red Hat Ansible Automation Platform 설치를 업그레이드하기 전에 원하는 구성과 일치하도록 인벤토리 파일을 편집합니다. 기존 Ansible Automation Platform 배포에서 동일한 매개변수를 유지하거나 환경에 대한 변경 사항과 일치하도록 매개변수를 수정할 수 있습니다.

인벤토리 파일 업데이트를 완료한 후 설정 스크립트를 실행할 수 있습니다.

설치가 시작됩니다.

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

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

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

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

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

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

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

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

# 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

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: []

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

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

# subscription-manager list --consumed

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

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

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

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

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

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

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

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

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

이전 Ansible 버전에서 최신 버전으로의 마이그레이션의 일환으로 사용 중인 모듈이 포함된 컬렉션을 찾아 다운로드해야 합니다. 해당 컬렉션 목록을 찾으면 다음 옵션 중 하나를 사용하여 컬렉션을 로컬로 포함할 수 있습니다.

컬렉션 기반 콘텐츠에서 컬렉션 기반 콘텐츠로 마이그레이션하는 경우 예기치 않은 동작을 방지하려면 플레이북 및 역할에 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'

기본 호스트에 이미 이 작업이 있으므로 aape1.local 실행 노드를 대상으로 합니다.

[awx@aape1 ~]$ ls -la /mydata/
total 4
drwxr-xr-x.  2 awx  awx   41 Apr 28 09:27 .
dr-xr-xr-x. 19 root root 258 Apr 11 15:16 ..
-rw-r--r--.  1 awx  awx   33 Apr 11 12:34 file_read
-rw-r--r--.  1 awx  awx    0 Apr 28 09:27 file_write

간단한 플레이북을 사용하여 절전으로 자동화를 시작하여 사용자가 액세스할 수 있도록 하고 프로세스를 이해하고 파일에 대한 읽기 및 쓰기를 시연합니다.

# vim:ft=ansible:

- hosts: all
  gather_facts: false
  ignore_errors: yes
  vars:
    period: 120
    myfile: /mydata/file
  tasks:
    - name: Collect only selected facts
      ansible.builtin.setup:
        filter:
          - 'ansible_distribution'
          - 'ansible_machine_id'
          - 'ansible_memtotal_mb'
          - 'ansible_memfree_mb'
    - name: "I'm feeling real sleepy..."
      ansible.builtin.wait_for:
        timeout: "{{ period }}"
      delegate_to: localhost
    - ansible.builtin.debug:
        msg: "Isolated paths mounted into execution node: {{ AWX_ISOLATIONS_PATHS }}"
    - name: "Read pre-existing file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_read'
    - name: "Write to a new file..."
      ansible.builtin.copy:
        dest: "{{ myfile }}_write"
        content: |
          This is the file I've just written to.

    - name: "Read written out file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_write') }}"

Ansible Automation Platform 2 탐색 패널에서 설정을 선택합니다. 그런 다음 작업 옵션에서 Job settings 를 선택합니다.

격리된 작업을 노출하는 경로:

[
"/mydata:/mydata:rw"
]

볼륨 마운트는 컨테이너의 동일한 이름으로 매핑되며 읽기-쓰기 기능이 있습니다. 그러면 작업 템플릿을 시작할 때 사용됩니다.

각 실행의 수면 기간을 조정할 수 있도록 시작 시 프롬프트 를 extra_vars 로 설정해야 합니다. 기본값은 30초입니다.

시작된 후 wait_for 모듈은 sleep에 대해 호출되므로 실행 노드로 이동하여 실행 중인 항목을 확인할 수 있습니다.

실행이 성공적으로 완료되었는지 확인하려면 다음 명령을 실행하여 작업의 출력을 가져옵니다.

$ podman exec -it 'podman ps -q' /bin/bash
bash-4.4#

이제 실행 중인 실행 환경 컨테이너 내부에 있습니다.

권한을 보면 awx 가 'root'가되었지만 rootless Podman을 사용하고 있기 때문에 사용자를 샌드박스와 유사한 커널 네임스페이스로 매핑하기 때문에 슈퍼유저에서와 같이 루트가 아닙니다. shadow-utils에서 rootless Podman의 작동 방식에 대해 자세히 알아보십시오.

bash-4.4# ls -la /mydata/
Total 4
drwxr-xr-x. 2 root root 41 Apr 28 09:27 .
dr-xr-xr-x. 1 root root 77 Apr 28 09:40 ..
-rw-r—--r–. 1 root root 33 Apr 11 12:34 file_read
-rw-r—--r–. 1 root root  0 Apr 28 09:27 file_write

결과에 따르면 이 작업이 실패했습니다. 이유를 이해하려면 나머지 출력을 확인해야 합니다.

TASK [Read pre-existing file…]******************************* 10:50:12
ok: [localhost] =>  {
    “Msg”: “This is the file I am reading in.”

TASK {Write to a new file...}********************************* 10:50:12
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: PermissionError: [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b' /mydata/file_write'
Fatal: [localhost]: FAILED! => {"changed": false, :checksum": "9f576o85d584287a3516ee8b3385cc6f69bf9ce", "msg": "Unable to make b'/root/.ansible/tmp/anisible-tim-1651139412.9808054-40-91081834383738/source' into /mydata/file_write, failed final rename from b'/mydata/.ansible_tmpazyqyqdrfile_write': [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b'/mydata/file_write}
...ignoring

TASK [Read written out file...] ****************************** 10:50:13
Fatal: [localhost]: FAILED: => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError;>, original message: could not locate file in lookup: /mydate/file_write. Vould not locate file in lookup: /mydate/file_write"}
...ignoring

:rw 가 설정되어 있어도 작업이 실패했으므로 쓰기 기능이 있어야 합니다. 프로세스에서 기존 파일을 읽을 수 있었지만 쓸 수는 없었습니다. 이는 SELinux 보호로 인해 컨테이너에 마운트된 볼륨 콘텐츠에 적절한 라벨을 배치해야 하기 때문입니다. 레이블이 없으면 SELinux에서 프로세스가 컨테이너 내에서 실행되지 않을 수 있습니다. OS에서 설정한 레이블은 Podman에서 변경하지 않습니다. 자세한 내용은 Podman 설명서를 참조하십시오.

이는 일반적인 잘못 해석이 될 수 있습니다. Podman이 공유 볼륨에서 파일 오브젝트의 레이블을 다시 지정하도록 하는 기본값을 :z 로 설정했습니다.

따라서 :z 를 추가하거나 그대로 둘 수 있습니다.

격리된 작업을 노출하는 경로:

[
   "/mydata:/mydata"
]

이제 플레이북이 예상대로 작동합니다.

PLAY [all] **************************************************** 11:05:52
TASK [I'm feeling real sleepy. . .] *************************** 11:05:52
ok: [localhost]
TASK [Read pre-existing file...] ****************************** 11:05:57
ok: [localhost] =>  {
	"Msg": "This is the file I'm reading in."
}
TASK [Write to a new file…] ********************************** 11:05:57
ok: [localhost]
TASK [Read written out file…] ******************************** 11:05:58
ok: [localhost] =>  {
      “Msg”: “This is the file I’ve just written to.”

기본 실행 노드 호스트에서 다시, 새로 작성된 콘텐츠가 있습니다.

활성화하면 이 값을 volumeMounts 및 실행에 사용할 Pod 사양 내에 삽입합니다. 다음과 같이 표시됩니다.

apiVersion: v1
kind: Pod
Spec:
   containers:
   - image: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8
  args:
    - ansible runner
    - worker
    - –private-data-dir=/runner
  volumeMounts:
mountPath: /mnt2
name: volume-0
readOnly: true
mountPath: /mnt3
name: volume-1
readOnly: true
mountPath: /mnt4
name: volume-2
readOnly: true
volumes:
hostPath:
  path: /mnt2
  type: “”
name: volume-0
hostPath:
  path: /mnt3
  type: “”
name: volume-1
hostPath:
  path: /mnt4
  type: “”
name: volume-2

실행 중인 컨테이너 내부의 스토리지는 오버레이 파일 시스템을 사용하고 있습니다. 실행 중인 컨테이너 내부의 모든 수정 사항은 마운트 해제되는 tmpfs와 유사하게 작업이 완료된 후 삭제됩니다.

데이터가 해당 호스트에 연결되므로 로컬 자동화 컨트롤러 파일 시스템을 비생산적인 것으로 간주합니다. 다중 노드 클러스터가 있는 경우 매번 다른 호스트에 연결하여 서로 다른 워크플로우를 생성하는 경우 문제가 발생할 수 있습니다. 예를 들어 다른 노드가 플레이북을 실행하는 동안 한 노드에서만 디렉터리가 생성된 경우 결과가 일치하지 않습니다.

솔루션은 Amazon S3, Gist 또는 데이터를 데이터 끝점에 rsync 역할과 같은 공유 스토리지 솔루션의 일부 형식을 사용하는 것입니다.

옵션은 런타임 시 컨테이너에 데이터 또는 구성을 삽입하는 데 있습니다. 이를 위해 자동화 컨트롤러의 분리된 작업 경로 옵션을 사용할 수 있습니다.

이를 통해 런타임 시 디렉터리 및 파일을 실행 환경에 마운트할 수 있습니다. 이 작업은 ansible-runner를 사용하여 Podman 컨테이너에 삽입하여 자동화를 시작하는 자동화 메시를 통해 수행됩니다. 다음은 격리된 작업 경로를 사용하는 몇 가지 사용 사례입니다.

사용할 수 있는 경고는 다음과 같습니다.

경고는 신중하게 관찰해야합니다. Ansible Automation Platform 2 내에서 사용되는 작업 경로의 [:OPTIONS] 부분인 rootless Podman 및 Podman 볼륨 마운트 런타임 옵션을 읽는 것이 좋습니다.

[awx@aape1 ~]$ ls -la /mydata/
total 4
drwxr-xr-x.  2 awx  awx   41 Apr 28 09:27 .
dr-xr-xr-x. 19 root root 258 Apr 11 15:16 ..
-rw-r--r--.  1 awx  awx   33 Apr 11 12:34 file_read
-rw-r--r--.  1 awx  awx    0 Apr 28 09:27 file_write

# vim:ft=ansible:

- hosts: all
  gather_facts: false
  ignore_errors: yes
  vars:
    period: 120
    myfile: /mydata/file
  tasks:
    - name: Collect only selected facts
      ansible.builtin.setup:
        filter:
          - 'ansible_distribution'
          - 'ansible_machine_id'
          - 'ansible_memtotal_mb'
          - 'ansible_memfree_mb'
    - name: "I'm feeling real sleepy..."
      ansible.builtin.wait_for:
        timeout: "{{ period }}"
      delegate_to: localhost
    - ansible.builtin.debug:
        msg: "Isolated paths mounted into execution node: {{ AWX_ISOLATIONS_PATHS }}"
    - name: "Read pre-existing file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_read'
    - name: "Write to a new file..."
      ansible.builtin.copy:
        dest: "{{ myfile }}_write"
        content: |
          This is the file I've just written to.

    - name: "Read written out file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_write') }}"

[
"/mydata:/mydata:rw"
]

$ podman exec -it 'podman ps -q' /bin/bash
bash-4.4#

bash-4.4# ls -la /mydata/
Total 4
drwxr-xr-x. 2 root root 41 Apr 28 09:27 .
dr-xr-xr-x. 1 root root 77 Apr 28 09:40 ..
-rw-r—--r–. 1 root root 33 Apr 11 12:34 file_read
-rw-r—--r–. 1 root root  0 Apr 28 09:27 file_write

TASK [Read pre-existing file…]******************************* 10:50:12
ok: [localhost] =>  {
    “Msg”: “This is the file I am reading in.”

TASK {Write to a new file...}********************************* 10:50:12
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: PermissionError: [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b' /mydata/file_write'
Fatal: [localhost]: FAILED! => {"changed": false, :checksum": "9f576o85d584287a3516ee8b3385cc6f69bf9ce", "msg": "Unable to make b'/root/.ansible/tmp/anisible-tim-1651139412.9808054-40-91081834383738/source' into /mydata/file_write, failed final rename from b'/mydata/.ansible_tmpazyqyqdrfile_write': [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b'/mydata/file_write}
...ignoring

TASK [Read written out file...] ****************************** 10:50:13
Fatal: [localhost]: FAILED: => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError;>, original message: could not locate file in lookup: /mydate/file_write. Vould not locate file in lookup: /mydate/file_write"}
...ignoring

[
   "/mydata:/mydata"
]

PLAY [all] **************************************************** 11:05:52
TASK [I'm feeling real sleepy. . .] *************************** 11:05:52
ok: [localhost]
TASK [Read pre-existing file...] ****************************** 11:05:57
ok: [localhost] =>  {
	"Msg": "This is the file I'm reading in."
}
TASK [Write to a new file…] ********************************** 11:05:57
ok: [localhost]
TASK [Read written out file…] ******************************** 11:05:58
ok: [localhost] =>  {
      “Msg”: “This is the file I’ve just written to.”

apiVersion: v1
kind: Pod
Spec:
   containers:
   - image: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8
  args:
    - ansible runner
    - worker
    - –private-data-dir=/runner
  volumeMounts:
mountPath: /mnt2
name: volume-0
readOnly: true
mountPath: /mnt3
name: volume-1
readOnly: true
mountPath: /mnt4
name: volume-2
readOnly: true
volumes:
hostPath:
  path: /mnt2
  type: “”
name: volume-0
hostPath:
  path: /mnt3
  type: “”
name: volume-1
hostPath:
  path: /mnt4
  type: “”
name: volume-2