Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/08/13/migrating-configurations-awx-24-aap-25
메모: 이 문서에서는 Ansible 커뮤니티에서 개발, 게시 및 유지 관리하는 Ansible 컬렉션(configify.aapconfig)을 활용합니다. Red Hat에서 지원하는 검증된 infra.aap_configuration Ansible 컬렉션을 참조하세요 .
이 시리즈의 이전 부분에서는 configify.aapconfig 컬렉션을 사용하여 처음부터 끝까지 코드로 구성을 통해 기존 Red Hat Ansible Automation Platform을 관리하는 방법을 설명했습니다 .
하지만 이 컬렉션을 다양한 유형의 마이그레이션에도 사용할 수 있습니다. 이 글에서는 AWX 24에서 Ansible Automation Platform 2.5로의 마이그레이션에 대해 설명합니다.
다음 시리즈를 팔로우하세요:
- 1부 : 기존 Ansible Automation Platform 인스턴스를 CaC로 관리하는 경로의 첫 번째 단계, 자동화를 실행하는 데 필요한 Ansible Automation Platform 계정, 컬렉션, 자격 증명, 프로젝트 및 작업 템플릿 설정, 일부 개체의 구성 내보내기, CaC에서 비밀 및 특수 문자열 처리, 구성 드리프트 관리.
- 2부 : 전환 완료: 모든 객체 내보내기, 가독성을 위한 구성 포맷, 검증, 액세스 제한 및 Git 관리.
- 3부 : AWX 24에서 Ansible Automation Platform 2.5로 구성 마이그레이션.
- 4부 : 스마트 인벤토리(향후 Ansible Automation Platform 릴리스에서 더 이상 사용되지 않음)를 구성된 인벤토리로 마이그레이션합니다.
- 5부 : Ansible Automation Platform 2.4에서 Ansible Automation Platform 2.5로 구성 마이그레이션.
준비 및 계획
AWX에서 Ansible Automation Platform으로 인플레이스 마이그레이션을 수행하는 방법이 있지만, 내보내기/가져오기 대신 내보내기/가져오기를 수행하는 것이 불가능하거나 더 나은 경우도 있습니다. 예를 들어, 온프레미스 인스턴스에서 가져온 백업을 복원할 수 없는 Red Hat Ansible Automation Platform 클라우드 서비스 중 하나로 마이그레이션하는 경우가 있습니다.
이 기사의 목적을 위해 우리는 다음과 같은 가정을 합니다.
- AWX 24 인스턴스를 실행하고 있습니다.
- Ansible Automation Platform 버전 2.5를 별도의 인스턴스로 배포했습니다.
- Galaxy 구성은 마이그레이션되지 않으며, Ansible Automation Platform Hub를 처음부터 구성해야 합니다.
구성 내보내기 계획 및 준비는 기존 인스턴스를 관리하거나 다른 인스턴스로 마이그레이션하는 경우 모두 동일합니다. 각 단계는 이전 두 문서에 자세히 설명되어 있습니다. 수행해야 할 작업을 간략하게 요약해 보겠습니다.
- 모든 필수 Red Hat 인증 컬렉션을 로컬 Galaxy 및 Hub에서 사용할 수 있는지 확인하세요. 오프라인 환경의 경우 모든 컬렉션을 로컬에서 사용할 수 있어야 합니다.
- 첫 번째 문서 에 설명된 대로 필요한 토큰과 구성을 생성합니다 . 이번에는 소스 클러스터(AWX)와 대상 클러스터(AAP)에서 단계를 두 번 수행해야 합니다. 구성은 다음과 같습니다.
- 컨트롤러(AWX) 및 게이트웨이(AAP)용 API 토큰
- 허브(AAP)용 API 토큰
- 허브 자격 증명에 대한 자격 증명 유형
- 컨트롤러, 허브(AAP) 및 게이트웨이(AAP)에 대한 자격 증명
- 빈 인벤토리
- Git 프로젝트
- 작업 템플릿
- 1부의 “Handling objects with secrets” 섹션에 설명된 대로 비밀을 처리하는 방법을 결정하고 필요한 구성을 준비합니다 .
- configify.aapconfig.aap_audit_problematic_objects.yml을 실행하고 문제가 있는 객체를 수정하고 2부의 “Pre-export steps” 섹션에서 설명한 대로 선택적 정리를 수행합니다 .
SSO를 통해 인증하는 외부 사용자는 별도로 고려해야 합니다. 이러한 사용자는 최초 로그인 시 클러스터에 추가되지만 로컬 사용자와 함께 내보내지지는 않습니다. 특정 외부 사용자에게 권한을 할당하는 경우(권장되지 않음), 해당 사용자가 로그인할 때까지 해당 사용자와 관련된 역할 가져오기를 지연해야 합니다. 이는 마이그레이션 전 정리 작업으로, 해당 역할을 팀으로 전환하는 것일 수 있습니다.
구성 내보내기
구성 내보내기는 2부에 설명된 것과 동일합니다. AWX 인스턴스에 대해 다음 플레이북을 만들고 실행합니다.
--- - name: Run playbook to export AAP configurations import_playbook: configify.aapconfig.aap_audit_all.yml
이번에는 AWX에서 내보내기 때문에 다음을 지정해야 합니다.
aap_platform: awx24
이 스위치는 플레이북이 API 호출에서 반환되는 데이터가 AWX에 국한되어야 한다고 가정하도록 지시하는데, 이는 경우에 따라 Ansible Automation Platform에서 반환되는 데이터와 약간 다를 수 있습니다. 또한, Ansible Automation Platform 2.5에서만 제공되는 구문 분석 구성을 건너뜁니다.
Ansible Automation Platform 2.5로 가져오기 때문에 다음을 사용하여 플레이북을 실행해야 합니다.
format_for_25: true
이렇게 하면 역할 및 인증자와 같은 특정 구성이 Ansible Automation Platform 2.5로 가져올 수 있도록 형식이 지정됩니다. 이 시리즈의 5부에서 차이점에 대한 자세한 내용을 확인할 수 있습니다.
내보낸 후 2부의 “Formatting the output” 섹션에 설명된 형식 지정 절차를 살펴보겠습니다.
구성 가져오기
가져오기 프로세스는 2부에서 설명한 것과 동일합니다. 다만 이번에는 다음과 같은 새로운 Ansible Automation Platform 클러스터에 대해 플레이북을 실행해야 합니다.
tasks:
- name: Include variables
ansible.builtin.include_vars: all_aap_objects
tags: always
- name: Run playbook to apply AAP configurations
import_playbook: configify.aapconfig.aap_configure.yml이 경우 기존 구성이 없으므로 체크 모드에서 import를 실행할 필요가 없습니다. 같은 이유로, controller_config_all_apply 태그를 사용하여 import playbook을 실행할 수 있습니다. 이 태그는 기존 객체와 구성 드리프트를 확인하지 않고 구성만 적용합니다.
가져오기를 완료한 후에는 준비 단계에서 새 클러스터에 생성된 객체(자격 증명 유형, 자격 증명, 프로젝트 및 작업 템플릿)를 CaC에 포함하는 것을 잊지 마세요. 다음과 같이 특정 태그를 사용하여 이러한 객체를 내보낼 수 있습니다.
export_credential_types export_credentials export_projects export_templates
그런 다음 기존 CaC에 병합합니다.
마지막 생각
configify.aapconfig 컬렉션에서 볼 수 있듯이, 동일한 클러스터에서 가져오거나 내보낼 필요가 없습니다. 매개변수가 다르기 때문에 플랫폼의 여러 버전 간에 유연하게 가져오거나 내보낼 수 있습니다. 더 많은 마이그레이션 시나리오를 논의할 다음 두 편을 기대해 주세요.
