Red Hat Ansible 자동화 플랫폼 마이그레이션: Red Hat Enterprise Linux에서 RPM에서 컨테이너로

Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/12/04/migrating-ansible-automation-platform-rpm-container

알고 보니 우주는 엄청나게 넓습니다. 정말 엄청나게 넓죠. 그리고 그 광활한 혼돈의 공간 어딘가에, 커피 얼룩이 묻은 YAML 파일을 움켜쥐고 “의존성 지옥”이라고 중얼거리는 친절한 자동화 엔지니어가 앉아 있을 겁니다.

지난 1년 동안 저는 Red Hat Enterprise Linux 9 (RHEL)에서 실행되는 Red Hat Ansible Automation Platform 2.5 RPM 환경 에서 행복하게 지내왔습니다 . 시끄러운 은하계 속에서 다소 불안정하지만 흥미진진한 행성 같은 곳이었죠. 작업은 예정대로 실행되었고, 로그는 대부분 읽기 쉬웠으며, PostgreSQL 데이터베이스는 만족스러운 보곤족처럼 윙윙거렸습니다. 삶은 그럭저럭 괜찮았습니다.

그러다가 Red Hat Ansible Automation Platform 2.6이 출시되었는데, 이 버전은 Lightspeed 지능형 어시스턴트 , 셀프 서비스 포털 , 그리고 이전 버전을 왜 참아왔는지 의문이 들게 만드는 자동화 대시보드를 약속했습니다.

당연히 저는 가능한 한 오랫동안 그 문제를 무시했습니다. 대부분의 엔지니어처럼 저도 “불이 나지 않았으면 건드리지 마라”라는 단순한 원칙을 따르기 때문입니다. 하지만 어느 날, 릴리스 노트를 흘끗 보다가 “RHEL 10 지원”과 “컨테이너 배포”라는 단어를 보게 되었고, 제 현재 환경이 결국에는 구식이 될 것이라는 사실을 깨달았습니다.

그렇게 저는 RHEL 9의 편안한 RPM 환경을 뒤로하고, 눈부시게 빛나는 컨테이너 환경의 RHEL 10으로 향하는 여정을 시작했습니다. 물론 RHEL 9에서 이 모험을 시작할 수도 있었지만, 어차피 미지의 세계로 발을 들여놓는 김에 한 단계 더 발전된 운영체제를 사용해 보는 것도 좋겠다 싶었습니다.

이 이야기는 YAML, Podman, 그리고 가끔씩 찾아오는 존재론적 위기에 관한 것입니다. 수건을 챙기고 백업을 새로 만들어 두세요. 이제 마이그레이션을 시작할 테니까요.

지금 업그레이드해야 하는 이유는 무엇일까요?

요약하자면, Red Hat Ansible Automation Platform 2.7이 출시되면 RPM 설치는 공식적으로 사용이 중단됩니다. 다시 말해, 이제 새로운 프로젝트에 RPM 설치를 더 이상 사용하지 않아야 합니다.

또한, 업그레이드를 결정하게 만든 훌륭한 새 기능들이 많이 추가되었는데 , 여러분도 동의하실 거라고 생각합니다. 더 자세한 내용은 릴리스 노트를 참조하세요 .

공식적인 마이그레이션 경로는 여러 가지가 있습니다 . RHEL 8을 사용 중이고 Red Hat Ansible Automation Platform 2.6으로 업그레이드하려는 경우 RHEL 9 이상을 설치해야 합니다.

내 실험실 환경: “이전” 모습

저는 RHEL 9 운영체제에 Ansible Automation Platform 2.5(RPM 번들)가 설치된 6개의 가상 머신(VM)으로 시작했습니다.

• 제어 장치
• 게이트웨이
• Private automation hub
• Event-Driven Ansible controller
• 실행 노드
• PostgreSQL 데이터베이스(설치 프로그램 관리형)

저는 대칭을 좋아해서, 목표 환경은 Ansible Automation Platform 2.6(컨테이너 번들)을 호스팅할 수 있는 새로운 RHEL 10 VM 6개로 구성했습니다. 각 구성 요소에 컨테이너를 사용하면 협력적인 서비스로 이루어진 작은 생태계를 만들 수 있습니다(제 개인 자동화 허브만 해도 Redis, 웹, 콘텐츠 컨테이너를 호스팅하고 있으며, 모두 서로 협력하는 것처럼 작동합니다).

가장 좋은 점은 무엇일까요? 가상 머신에 패치를 적용하거나 재부팅해도 Ansible은 전혀 동요하지 않고 유지 관리 시간과 전혀 관계없이 자동화 작업을 계속 수행한다는 것입니다.

자, 여러분, 패치 작업을 계속하세요. 패치 작업을 멈추지 마세요. 다만 Podman은 계속 주시해야 합니다. Podman이야말로 컨테이너들이 반란을 일으키지 않도록 막아주는 핵심 프로그램이니까요.

범위 외 구성 요소

마이그레이션 후 일부 구성 요소를 수동으로 다시 생성해야 합니다.

• Event-Driven Ansible configuration
• Instance groups
• Hub content
• Custom CA for receptor mesh
• Non-default execution environments

필수 조건

시작하기 전에 다음 요구 사항을 충족했는지 확인하십시오.

• 데이터베이스 덤프 및 백업을 위한 저장 공간은 충분합니다.
• 소스와 대상 간에 네트워크 연결이 되어 있습니다.
• 백업! 네, 정말입니다. 시작하기 전에 백업을 만드세요.
• 출처: Ansible Automation Platform 2.5 RPM 배포를 최신 릴리스로 업데이트하세요  .
• 대상:  RHEL 10 VM이 컨테이너 번들을 설치할 준비가 되었습니다.
  • 최신  Ansible Automation Platform 2.5 컨테이너 설치 프로그램 번들을 다운로드하세요.
  • 바이너리 파일을 대상 노드에 복사하세요. 저는 미리 컨트롤러 노드가 될 곳에 바이너리 파일을 복사해 두어, 해당 노드가 초기에 자신의 역할을 숙지할 수 있도록 했습니다.

이주 순서

1. 소스 환경을 준비하고 평가합니다.
2. 내보내기 소스 환경
3. 마이그레이션 아티팩트 생성 및 검증
4. 목표 환경을 준비합니다
5. 가져오기 마이그레이션 콘텐츠
6. 가져오기 후 대상 조정
7. 대상 환경을 검증합니다.

소스

우선 가장 중요한 것은 원본 환경을 백업하는 것입니다. 안정성도 중요하지만, 복구 가능성이야말로 진정한 가치를 창출하기 때문입니다.

Ansible Automation Platform이 이미 최적의 상태로 작동하고 있는 원본 환경에서, Ansible Automation Platform 2.5 RPM 설치 패키지에 포함된 setup.sh와 인벤토리 파일이 있는 디렉토리로 이동합니다. 그런 다음 다음 명령어를 실행하고, 결과가 나올 때까지 숨을 참으세요.

./setup.sh -e 'backup_dest=/path/to/backups/' -e 'use_compression=True' -b

데이터베이스 검증

소스 환경부터 시작하겠습니다. 먼저 PostgreSQL 노드에서 postgres ID를 사용하여 PostgreSQL 버전이 15인지 확인합니다.

psql -c 'SELECT version();'

시크릿과 설정 저장

각 구성 요소에서 연결 정보를 수집합니다. 여기에는 세 가지 개별 작업이 있습니다.

컨트롤러에서:

awx-manage print_settings | grep '^DATABASES'

자동화 허브에서:

grep '^DATABASES' /etc/pulp/settings.py

게이트웨이에서:

aap-gateway-manage print_settings | grep '^DATABASES'

코드 조각 복사

아티팩트를 생성

게이트웨이 노드에서 파일을 준비하세요.

mkdir -p /tmp/backups/artifact/{controller,gateway,hub}
mkdir -p /tmp/backups/artifact/controller/custom_configs
touch /tmp/backups/artifact/secrets.yml
cd /tmp/backups/artifact

그다음에는 당신만의 소중한 secrets.yml 파일을 만드세요 :

awx_pg_database: awx # name of my controller database
automationhub_pg_database: automationhub # name of my hub
automationgateway_pg_database: automationgateway # name of my gateway database
controller_secret_key: "<controller_key>"
hub_secret_key: "<hub_key>"
hub_db_fields_encryption_key: "<hub_db_key>"
gateway_secret_key: "<gateway_key>"

안전하게 보관하십시오. 이것을 잃어버리면 이주가 실패하고 고고학 발굴 현장이 될 것입니다.

시크릿 내보내기

이제 RPM 환경에서 비밀 키를 내보낼 차례입니다. 각 구성 요소 그룹에서 노드 하나씩만 내보내면 됩니다. 마치 행성 간 보물찾기와 같지만, 상품 대신 YAML 항목을 얻게 되는 것입니다.

다음 각 작업을 수행하려면 루트 권한으로 로그인하십시오. 이는 “루트 권한 없이는 불가능”이라는 원칙이 실제로 적용되는 드문 경우 중 하나입니다.

자동화 컨트롤러 비밀 키

SSH를 사용하여 자동화 컨트롤러 노드에 로그인하고 비밀 키를 가져오세요.

cat /etc/tower/SECRET_KEY

해당 값을 secrets.yml파일의 . 아래에 복사하세요 controller_secret_key. 엄청난 힘을 얻은 기분이 들겠지만, 명심하세요… 강력한 비밀 키에는 그만큼의 책임이 따릅니다.

자동화 허브 비밀 키

다음으로 자동화 허브 노드로 이동하여 비밀 키를 추출하세요.

grep '^SECRET_KEY' /etc/pulp/settings.py | awk -F'=' '{ print $2 }'

해당 값을 secrets.yml의 hub_secret_key 아래 에 붙여넣으세요. 네, 이 명령어는 마치 DevOps 모임에서 냅킨 뒷면에 휘갈겨 쓴 것처럼 보일지 모르지만, 제대로 작동합니다.

자동화 허브 필드 암호화 키

자동화 허브 노드에서 데이터베이스 필드 암호화 키를 가져옵니다.

cat /etc/pulp/certs/database_fields.symmetric.key

이 값을 secrets.yml의 hub_db_fields_encryption_key에 추가 하세요 .

플랫폼 게이트웨이 비밀 키

마지막으로 플랫폼 게이트웨이 노드에 접속하여 비밀 키를 받으세요.

cat /etc/ansible-automation-platform/gateway/SECRET_KEY

이것을 secrets.yml의 gateway_secret_key 에 추가하세요 .

secrets.yml 내보내기 파일을 안전하게 보관하세요. 안전을 위해 암호화할 수도 있습니다. 파일을 가까이에 두세요. 그리고 제발, YAML을 생각해서라도 자신에게 이메일로 보내지 마세요.

축하합니다! 이제 당신은 플랫폼에 숨겨진 지식을 은하계를 넘어 완전히 추출하는 데 성공했습니다.

데이터베이스 내보내기

게이트웨이 노드에서 postgres 사용자 계정으로 데이터베이스를 덤프하십시오.

psql -h <pg_hostname> -U <component_pg_user> -d <database_name> -t -c 'SHOW server_version;' # ensure connectivity to the database

pg_dump -h pg.example.com -U awx -d awx --clean --create -Fc -f awx.pgc
pg_dump -h pg.example.com -U automationhub -d automationhub --clean \
--create -Fc -f pah.pgc
pg_dump -h pg.example.com -U automationgateway -d automationgateway \
--clean --create -Fc -f gw.pgc

ls -ld <component>/<component>.pgc
echo "<component>_pg_database: <database_name>" >> secrets.yml ## Add the database name for the component to the secrets file

데이터베이스를 내보낸 후에는 게이트웨이 노드(이전에 생성한 디렉터리 트리)의 /tmp/backups/artifact/{controller,gateway,hub}에 해당 데이터베이스를 배치하십시오. 제 경험상, 그 위치에 배치하지 않으면 나중에 어디에 두었는지 기억하기 어려울 것입니다.

자동화 컨트롤러 사용자 정의 구성 내보내기

만약 사용자 지정 설정이 있다면 /etc/tower/conf.d, 지금이 바로 그 설정을 보존할 때입니다. 사용자 지정 설정을 /tmp/backups/artifact/controller/custom_configs 폴더에 복사하세요. 해당 폴더의 모든 파일이 사용자 지정 설정은 아닙니다. 설치 프로그램이 일부 파일을 자동으로 관리하므로, 직접 만든 파일만 보존하면 됩니다. 다음 파일은 건너뛰어도 됩니다.

• /etc/tower/conf.d/postgres.py
• /etc/tower/conf.d/channels.py
• /etc/tower/conf.d/caching.py
• /etc/tower/conf.d/cluster_host_id.py

저는 사용자 지정 설정이 없었기 때문에 이 단계를 건너뛰었습니다.

모든 항목에 체크섬을 적용하세요. 신뢰는 얻어야 하는 것이기 때문입니다. 아카이브 디렉터리와 하위 디렉터리를 저장하는 게이트웨이 노드에서 다음 명령어를 실행하세요.

cd /tmp/backups/artifact/
[ -f sha256sum.txt ] && rm -f sha256sum.txt
find . -type f -name "*.pgc" -exec sha256sum {} \; >> sha256sum.txt
cat sha256sum.txt 

다음은 게이트웨이 노드의 아티팩트 디렉터리 트리가 모든 파일을 포함하여 어떻게 구성되어야 하는지 보여주는 예입니다.

├── controller
│   ├── awx.pgc
│   └── custom_configs  
├── gateway
│   └── gw.pgc
├── hub
│   └── pah.pgc
├── secrets.yml
└── sha256sum.txt

모든 아티팩트를 압축한 다음 체크섬 기록을 생성합니다.

tar cf artifact.tar artifact
sha256sum artifact.tar > artifact.tar.sha256

해시값을 확인하세요:

sha256sum --check artifact.tar.sha256

아카이브를 대상 위치로 전송하세요 (저는 컨트롤러로 보냈습니다).

scp artifact.tar <target>:/tmp

축하합니다! 소스 환경에서의 모든 작업을 완료하셨습니다. 이제 대상 환경으로 넘어가세요.

대상 환경

대상 시스템에서 압축 파일을 풀고 체크섬을 확인하세요. 전송 중에 파일이 손상되지 않았는지 다시 한번 확인하는 것만큼 “이 소프트웨어를 신뢰합니다”라고 말하는 확실한 방법은 없으니까요. 제 경우에는 이 모든 작업을 컨트롤러 노드에서 바로 수행하고 설치를 시작했습니다.

sha256sum --check artifact.tar.sha256
tar xf artifact.tar
sha256sum --check sha256sum.txt

diff를 사용해서 인벤토리를 비교한 다음 RHEL 10용 Ansible Automation Platform 2.5 컨테이너를 설치하세요. 네, 먼저 2.5 버전을 설치해야 하지만 걱정하지 마세요. 나중에 2.6 버전으로 업그레이드할 것입니다.

설치 프로그램을 실행하세요:

ansible-playbook -i inventory ansible.containerized_installer.install \
  -e @~/artifact/secrets.yml \
  -e "__hub_database_fields='{{ hub_db_fields_encryption_key }}'"

다음 작업 직후에 즉시 백업을 수행하십시오.

ansible-playbook -i inventory ansible.containerized_installer.backup

Podman을 사용하여 데이터베이스 가져오기

먼저 대상 환경에서 컨테이너화된 서비스(데이터베이스 제외)를 중지해야 합니다.

컨트롤러 노드에서:

systemctl --user stop automation-controller-task \
automation-controller-web automation-controller-rsyslog
systemctl --user stop receptor

개인 자동화 허브 노드에서:

systemctl --user stop automation-hub-api \
automation-hub-content automation-hub-web \
automation-hub-worker-1 automation-hub-worker-2

이벤트 기반 Ansible 컨트롤러 노드에서:

systemctl --user stop automation-eda-scheduler \
automation-eda-daphne automation-eda-web \
automation-eda-api automation-eda-worker-1 automation-eda-worker-2 \
automation-eda-activation-worker-1 automation-eda-activation-worker-2

게이트웨이 노드에서:

systemctl --user stop automation-gateway automation-gateway-proxy

이 시점에서 여러분이 목표로 하는 Ansible Automation Platform 2.5는 마치 선(禪)과 같은 고요하고 공허한 상태에 있습니다. 데이터베이스를 되살리기에 완벽한 시기입니다.

임시 PostgreSQL 컨테이너를 시작합니다

우리는 일회용 PostgreSQL 컨테이너를 사용하여 덤프를 복원할 것입니다. PostgreSQL 노드에서 artifact.tar.sha256 tarball을 홈 디렉터리에 놓고 압축을 해제하세요. 마치 Podman과 카페인으로 만든 타임머신이라고 생각하면 됩니다.

다음으로 Podman을 실행하세요.

podman run -it --rm --name postgresql_restore_temp --network host \
  --volume ~/aap/tls/extracted:/etc/pki/ca-trust/extracted:z \
  --volume ~/aap/postgresql/server.crt:/var/lib/pgsql/server.crt:ro,z \
  --volume ~/aap/postgresql/server.key:/var/lib/pgsql/server.key:ro,z \
  --volume ~/artifact:/var/lib/pgsql/backups:ro,z \
  registry.redhat.io/rhel8/postgresql-15:latest bash

컨테이너 내부

각 역할에 CREATEDB 권한을 일시적으로 부여하십시오:

psql -h pg.example.com -U postgres

다음 SQL 명령어를 실행하세요:

ALTER ROLE awx WITH CREATEDB;
ALTER ROLE automationhub WITH CREATEDB;
ALTER ROLE automationgateway WITH CREATEDB;
ALTER ROLE edacontroller WITH CREATEDB;
\q

역할에 부여된 CREATEDB 권한을 활용하여 /var/lib/pgsql 디렉터리로 이동할 때입니다.

cd /var/lib/pgsql/

이제 신성한 복원 의식을 행하십시오:

pg_restore --clean --create --no-owner -h pg26.example.com -U awx -d template1 controller/awx.pgc
pg_restore --clean --create --no-owner -h pg26.example.com -U automationhub -d template1 hub/pah.pgc
pg_restore --clean --create --no-owner -h pg26.example.com -U automationgateway \
-d template1 gateway/gw.pgc

임시 권한을 취소하세요:

psql -h pg26.example.com -U postgres

다음 SQL 명령어를 실행하세요:

ALTER ROLE awx WITH NOCREATEDB;
ALTER ROLE automationhub WITH NOCREATEDB;
ALTER ROLE automationgateway WITH NOCREATEDB;
ALTER ROLE edacontroller WITH NOCREATEDB;
\q

서비스 재시작

이제 서비스를 다시 시작할 수 있습니다. 컨트롤러 노드에서 다음 단계를 따르세요.

systemctl --user start automation-controller-task \
automation-controller-web automation-controller-rsyslog
systemctl --user start receptor

자동화 허브 노드에서:

systemctl --user start automation-hub-api \
automation-hub-content automation-hub-web \
automation-hub-worker-1 automation-hub-worker-2

이벤트 기반 Ansible 노드에서:

systemctl --user start automation-eda-scheduler \
automation-eda-daphne automation-eda-web \
automation-eda-api automation-eda-worker-1 automation-eda-worker-2 \
automation-eda-activation-worker-1 automation-eda-activation-worker-2

게이트웨이 노드에서:

systemctl --user start automation-gateway automation-gateway-proxy

연기나 이상한 소리 없이 모든 것이 순조롭게 시작된다면 축하합니다! 데이터베이스가 컨테이너화된 새로운 환경으로 안전하게 성공적으로 이전되었습니다.

우주는 미완성된 문제를 싫어합니다. 데이터베이스를 복원하고 서비스를 재시작했으니 이제 정리할 시간입니다.

기존 게이트웨이 구성을 해제

마이그레이션 과정에서 게이트웨이의 내부 데이터베이스에 오래되거나 일관성이 없는 객체가 누적될 수 있습니다. 이러한 객체 중 일부는 마치 지구가 이동했다는 사실을 받아들이지 못하는 로봇처럼 이전 클러스터 토폴로지에 대한 기억을 여전히 간직하고 있을 수 있습니다.

게이트웨이 노드에서 Podman을 사용하여 게이트웨이 컨테이너에 접근하고 이전 게이트웨이 구성을 제거하여 과거는 더 이상 관련이 없음을 알려줍니다.

podman exec -it automation-gateway bash​

aap-gateway-manage migrate​
aap-gateway-manage shell_plus​

>> HTTPPort.objects.all().delete(); ServiceNode.objects.all().delete();
ServiceCluster.objects.all().delete()

이러한 객체는 업그레이드된/새로운 컨트롤러 노드가 게이트웨이에 다시 등록될 때 자동으로 다시 생성됩니다.

사용자 지정 설정 전송

저는 사용자 지정 설정이 없었기 때문에 이 단계를 건너뛰었습니다. 하지만 사용자 지정 구성이 있는 경우 대상 환경에서 인벤토리 파일을 열고 component_extra_settings 변수 (예: controller_extra_settings, hub_extra_settings, eda_extra_settings, postgresql_extra_settings 등)를 사용하여 각 구성 요소에 관련 추가 설정을 적용해야 합니다.

다음은 대상 환경의 인벤토리 파일에서 사용할 변수들입니다. 마지막으로, Ansible Automation Platform 2.5 컨테이너 설치 시 참조할 새로운 위치(Ansible Automation Platform 2.6 컨테이너 버전으로 업그레이드하는 경우)가 표시됩니다. YAML 코드를 이해하기 전에 다음 예제를 참조하세요.

postgresql_extra_settings: ssl_ciphers:'HIGH:!aNULL:!MD5'

리소스 서버 비밀 키를 업데이트

리소스 비밀 키를 갱신할 시간입니다. 리소스 비밀 키가 없으면 구성 요소들이 서로 통신할 수 없게 되고, 이로 인해 자동화 시스템 간의 호환성이 깨집니다. 현재 리소스 비밀 키 값을 확인하세요.

터미널을 실행하고 게이트웨이 노드에서 비밀 키를 가져오세요.

podman exec -it automation-gateway bash -c 'aap-gateway-manage shell_plus --quiet -c "[print(cl.name, key.secret) for cl in ServiceCluster.objects.all() for key in cl.service_keys.all()]"'

현재 시크릿 값을 검증

모든 것이 여전히 원래대로 일치하는지 확인하십시오.

for secret_name in eda_resource_server hub_resource_server controller_resource_server
do
echo $secret_name
podman secret inspect $secret_name --showsecret | grep SecretData
done

뭔가 잘못됐다면 비밀 정보를 삭제하기만 하면 됩니다.

podman secret rm <SECRET_NAME>

허브 및 컨트롤러 비밀 키에 대해서도 동일한 과정을 반복하세요. 명령줄 반복을 통한 치료라고 생각하면 됩니다. 그런 다음 비밀 키를 다시 생성하세요.

echo "secret_value" | podman secret create <SECRET_NAME> -

 모든 경우에 <SECRET_NAME>각 구성 요소에 맞는 올바른 부품으로 교체해야 합니다.

• eda_resource_server: Event-Driven Ansible
• hub_resource_server: Automation Hub
• controller_resource_server: Automation Controller

완료되면 구성 요소들이 (완전히 암호화된 상태로) 다시 서로 통신할 수 있습니다. 조화가 복원되었습니다!

설치 프로그램을 다시 실행

이전에 이미 수행했던 작업이지만, 동일한 인벤토리를 사용하여 다시 한 번 수행해야 합니다. 한 가지 조언을 드리자면, 소스 환경에서 실행 환경을 가져와 대상 환경으로 옮기십시오.

이전 마이그레이션에서 생성된 로컬 및 원격 이미지 파일이 남아 있다면 모두 삭제하세요! 마이그레이션 과정에서 Pulp 파일이 복사되지 않기 때문에 이러한 이전 이미지는 불필요한 파일이며 공간만 차지합니다.

ansible-playbook -i inventory ansible.containerized_installer.install

오류 메시지 없이 이 과정이 완료되면 게이트웨이 재정렬이 성공적으로 이루어진 것입니다. 자동화 환경에 질서와 균형을 되찾았습니다.

검증 및 작동 확인

여기까지 오셨다면, 이제 여러분의 Ansible Automation Platform은 컨테이너화되고 모듈화되어 이론적으로 기능까지 갖춘 새로운 현실 속에 존재합니다. 하지만 승리를 선언하고 LinkedIn에 자랑하기 전에, 새롭게 배포한 Ansible Automation Platform 2.5 컨테이너가 실제로 제대로 작동하는지 검증해 보겠습니다.

컨트롤러 노드: 클러스터의 상태를 확인합니다.

SSH를 사용하여 컨트롤러 노드에 로그인하십시오. 이것이 전체 작업의 핵심입니다.

ssh controller26.example.com

podman exec -it automation-controller-task bash
awx-manage list_instances

모든 것이 정상이라면 다음과 같은 화면이 나타납니다.

[default capacity=272]
        controller26.example.com capacity=136 node_type=hybrid version=4.7.4 heartbeat="2025-11-10 21:10:53"
        en26.example.com capacity=136 node_type=execution version=ansible-runner-2.4.1 heartbeat="2025-11-10 21:10:44"
[controlplane capacity=136]
        controller26.example.com capacity=136 node_type=hybrid version=4.7.4 heartbeat="2025-11-10 21:10:53"
[executionplane capacity=136]
        en26.example.com capacity=136 node_type=execution version=ansible-runner-2.4.1 heartbeat="2025-11-10 21:10:44"

이 출력은 자동화 시스템에서 심장 박동과 같은 역할을 합니다. 해당 타임스탬프가 보이면 시스템이 정상적으로 작동하고 있는 것입니다.

기존 노드를 제거

마이그레이션 후에도 오래된 노드가 남아 있는 경우가 있습니다. 오래된 노드의 좋은 지표는 용량이 0으로 표시되는 것입니다. 이는 노드가 상태 점검에 실패하여 클러스터에 남아 있다는 것을 의미합니다. 이러한 노드를 제거하십시오.

awx-manage deprovision_instance --host=node1.example.org
awx-manage deprovision_instance --host=node2.example.org

Pulp 수리

다음으로, 콘텐츠 무결성이 중요하므로 Pulp에서 연결이 끊어진 자동화 허브 콘텐츠 링크를 복구해야 합니다.

curl -d '{"verify_checksums": true }' \
  -X POST -k https://<gateway-url>/api/galaxy/pulp/api/v3/repair/ \
  -u <gateway_admin_user>:<gateway_admin_password>

/repair/에서 JSON 형식의 응답이 반환 되더라도 당황할 필요는 없습니다. 특별히 오류 메시지가 표시되지 않는 한 일반적으로 아무것도 할 필요가 없습니다. 이는 처리해야 할 작업 목록이 아니라, Pulp에서 백그라운드 작업 객체가 정중하게 보고하는 내용일 뿐입니다.

만약 state = failed 메시지가 보이면 즉시 조치를 취해야 합니다. 다음 사항들을 확인해 보세요:

• error: 무엇이 잘못되었는지 알려줍니다.
• traceback:어디서 언제 문제가 발생했는지 알려줍니다.
• reserved_resources_record: 문제의 원인이 무엇인지 알려줍니다.

인스턴스 그룹 조정

인스턴스 그룹은 마이그레이션 패키지에 포함되어 있지 않습니다. 마이그레이션 후 인스턴스 그룹 연결을 다시 생성하고 남아 있는 불필요한 인스턴스를 연결 해제해야 합니다.

1. Ansible Automation Platform의 웹 UI에 로그인하세요.
2. Automation Execution > Infrastructure > Instance Groups 으로 이동합니다 .
3. 그룹을 선택하고 ‘ Instances‘ 탭을 클릭한 다음 필요에 따라 연결 또는 연결 해제하십시오.

이 단계에서는 어떤 노드가 속하는지 결정합니다.

의사결정 환경을 조화시키세요

다음으로 웹 UI에서 Automation Decisions > Decision Environments으로 이동합니다.

1. 더 이상 존재하지 않는 레지스트리 URL을 참조하는 각 결정 환경을 수정하십시오(또는 더 심각하게는 이전 클러스터를 가리키는 경우).
2. 새 허브 URL에 맞게 업데이트하세요.

이전 허브를 참조하는 자동화 허브 결정 환경이 있는 경우 해당 환경도 수정해야 합니다. 그렇지 않으면 Ansible Automation Platform 2.5에 계속 접근하려고 시도할 것입니다.

실행 환경과 자격 증명을 일치시키세요

웹 UI에서 Automation Execution > Infrastructure > Execution Environments 으로 이동하세요 .

1. 각 이미지 경로가 새 레지스트리를 가리키는지 확인하십시오.
2. 그런 다음 Automation Execution > Infrastructure > Credentials 으로 이동하여 레지스트리 자격 증명이 새 환경과 일치하는지 확인하십시오.

사용자 접근 권한 및 사용 권한을 검증합니다.

모든 사람이 출입할 수 있도록 하되, 지정된 장소에만 출입할 수 있도록 해야 할 때입니다.

• 사용자 인증: 몇 개의 계정으로 로그인 테스트를 진행하여 인증이 예상대로 작동하는지 확인합니다.
• 역할 기반 접근 제어: 조직, 프로젝트, 인벤토리 및 작업 템플릿 전반에 걸쳐 사용자가 올바른 권한을 여전히 갖고 있는지 다시 한번 확인하십시오. 예기치 않게 “슈퍼 관리자”로 승격되는 것을 원하지 않으실 겁니다!
• 팀 구성원: 팀이 여전히 존재하며 구성원이 올바른지 확인합니다.
• API 접근 권한: 자동화 시스템이 플랫폼과 올바른 위치에서 통신할 수 있도록 API 토큰을 테스트합니다.
• SSO 통합(해당되는 경우): 싱글 사인온(SSO)이 제대로 작동하는지 확인합니다.

추가 검증

모든 것을 검증하는 것이 중요합니다. 확인해야 할 사항은 다음과 같습니다.

플랫폼 게이트웨이

• 새로운 Ansible 자동화 플랫폼(특히 게이트웨이 URL)에 접속하세요.
• 대시보드가 ​​로드되었나요? 좋습니다.
• HTTP 500 오류가 없다고요? 그럼 더 좋겠네요.
• 게이트웨이 서비스가 컨트롤러에 연결되었나요? 좋습니다!

자동화 컨트롤러

• Automation Content 에서 프로젝트, 재고 및 작업 템플릿이 있는지 확인하십시오.
• 몇 가지 작업을 실행하고 성공적으로 완료되는지 확인하십시오.

자동화 허브

• 자동화 콘텐츠 에서 모든 컬렉션과 네임스페이스가 올바르게 표시되는지 확인하십시오.
• 필요한 경우 동기화하고 게시하세요.

Event-Driven Ansible

• Automation Execution > Decisions 사항 .
• 모든 규칙서, 활성화 및 규칙 감사가 성공적으로 마이그레이션되었는지 확인하십시오.

로그 모니터링

컨테이너에 문제가 있다고 생각되면 Podman을 사용하여 로그를 통해 진행 상황을 확인할 수 있습니다.

podman logs -f <container_name>

조용하면 괜찮습니다. 출력이 많으면 추가 조사가 필요합니다.

모든 것을 스모크 테스트

염두에 두어야 할 사항은 다음과 같습니다.

• 자격 증명: 자격 증명을 확인하세요 . 자격 증명이 작동하지 않으면 만료되었을 가능성이 높습니다.
• 작업 템플릿: 특히 서로 다른 자격 증명이나 프로젝트가 관련된 작업 템플릿은 여러 개 실행하세요.
• 워크플로 템플릿: 노드가 올바른 순서로 실행되고 작업이 중단 없이 완료되도록 보장합니다.
• 실행 환경: 작업이 올바른 환경에 배치되고 필요한 종속성이 사용 가능한지 확인합니다.
• 작업 결과물: 작업 결과물이 저장되고 조회 가능한지 확인하십시오.
• 일정: 예약된 작업이 예정된 시간에 제대로 실행되는지 확인하기 위해 테스트합니다.

사용자 접근 권한 및 사용 권한을 검증합니다.

• 로그인: 여러 사용자 계정을 시도해 보세요.
• RBAC: 조직, 프로젝트 및 인벤토리에 대한 역할을 검증합니다.
• 팀: 팀 구성원을 확인하세요.
• API 토큰: 테스트해 보세요. 나중에 분명 도움이 될 겁니다.
• SSO: ID 공급자 정보가 갑자기 사라지지 않도록 하세요.

콘텐츠 동기화 및 가용성을 확인

자동화 플랫폼은 콘텐츠를 찾지 못하면 그다지 유용하지 않습니다.

• 컬렉션 동기화: 원격 저장소에서 동기화가 여전히 작동하는지 확인하십시오.
• 컬렉션 업로드: 테스트용으로 하나를 업로드하세요.
• 컬렉션 저장소: 허브가 컬렉션을 제대로 제공하는지 확인하십시오.
• 프로젝트 동기화: Git 프로젝트가 여전히 성공적으로 복제되는지 확인합니다.
• 외부 소스: Ansible Galaxy 또는 원격 허브와의 연결을 테스트하십시오.
• 실행 환경 접근 권한: 필요한 모든 환경이 존재하고 접근 가능한지 확인하십시오.
• 종속성: 외부 콘텐츠가 필요한 작업을 실행합니다.

승리의 행진

모든 것이 정상이라면:

• 대시보드가 ​​녹색으로 빛납니다
• 작업이 깨끗하게 진행됩니다
• 로그는는 조용 

Ansible Automation Platform 2.6으로 업그레이드하세요

드디어 마지막 단계입니다! RHEL 10용 Ansible Automation Platform 2.6 컨테이너 번들을 다운로드하세요 . 이것으로 마이그레이션 여정의 최종 단계가 완료됩니다. 다운로드가 완료되면 대상 환경(저는 컨트롤러 노드에 복사했습니다)에 복사하세요.

YAML 파일을 하나라도 수정하기 전에, 새로 마이그레이션한 RHEL 10 VM의 2.5 컨테이너 환경을 다시 한 번 백업하십시오. 네, 다시 한번 백업해야 합니다.

ansible-playbook -i inventory ansible.containerized_installer.backup

AI 애호가를 위한 Red Hat Ansible Lightspeed

자, 이제 AI 모험을 떠나는 여러분을 위해 새로운 Ansible Lightspeed 인벤토리 변수를 살펴보겠습니다 . 플랫폼이 스스로 반응하도록 가르치는 것만큼 “현대적인 자동화”를 잘 보여주는 것도 없죠.

직접 사용해 보시려면 , 좋은 대규모 언어 모델(LLM)과 Ansible Lightspeed를 실행할 추가 가상 머신(VM)만 있으면 됩니다.

# AAP Lightspeed
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/containerized_installation/appendix-inventory-files-vars#ref-lightspeed-variables
# -----------------------------------------------------
# lightspeed_admin_password=<set your own>
# lightspeed_pg_host=externaldb.example.org
# lightspeed_pg_password=<set your own>
# lightspeed_chatbot_model_url=<set your own>
# lightspeed_chatbot_model_api_key=<set your own>
# lightspeed_chatbot_model_id=<set your own>
# lightspeed_mcp_controller_enabled=true
# lightspeed_mcp_lightspeed_enabled=true
# lightspeed_wca_model_api_key=<set your own>
# lightspeed_wca_model_id=<set your own>

Model context protocol (MCP)은 아직 기술 미리보기 단계이므로 사용해 보실 수 있습니다 .

지금 당장은 자동화를 사람의 힘으로 유지하고 싶다면, Lightspeed 변수를 생략하고 2.5 버전의 인벤토리 레이아웃을 사용하세요. 나중에 언제든지 AI 변수를 추가하고 설치 프로그램을 다시 실행할 수 있습니다.

미래를 경험할 시간

인벤토리를 업데이트하고 2.5 변수를 2.6으로 변환했으면 이제 본격적으로 시작해 봅시다. Ansible Automation Platform 2.6 설치 프로그램을 실행하세요.

ansible-playbook -i inventory ansible.containerized_installer.install

업그레이드가 완료되면 2.5 마이그레이션 후와 동일한 방식으로 환경을 검증하십시오.

드디어 해냈습니다! RHEL 9 기반 Ansible Automation Platform 2.5 RPM에서 RHEL 10 기반 Ansible Automation Platform 2.6 컨테이너로의 완벽한 마이그레이션을 완료했습니다.

” 자동화가 당신을 게으르게 만드는 건 아니라는 걸 명심하세요. 단지 YAML에 대해 불평할 시간을 더 많이 줄 뿐입니다 .”