Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/07/30/automating-configuration-existing-ansible-instance
메모: 이 문서에서는 Ansible 커뮤니티에서 개발, 게시 및 유지 관리하는 Ansible 컬렉션(configify.aapconfig)을 활용합니다. Red Hat에서 지원하는 검증된 infra.aap_configuration Ansible 컬렉션을 참조하세요 .
이 시리즈의 첫 번째 부분 에서는 configify.aapconfig 컬렉션을 위해 Red Hat Ansible Automation Platform을 구성하는 방법 , 특정 개체(예: 조직, 사용자 및 자격 증명 유형)에 대한 기존 인스턴스에서 구성을 내보내는 방법, 이러한 개체에 대한 구성을 적용하고 구성 드리프트를 관리하기 위해 자동화를 실행하는 방법에 대해 설명했습니다 .
이 문서에서는 기존 Ansible Automation Platform 인스턴스를 처음부터 끝까지 자동화하는 방법을 설명합니다. 여기에는 다음 내용이 포함됩니다.
- 인스턴스 구성 정리를 수행합니다.
- 문제가 있는 객체를 식별합니다.
- 모든 구성을 내보냅니다.
- JSON 형식으로 구성을 얻기 위해 출력을 포맷합니다.
- 구성 확인.
- Ansible Automation Platform에 대한 관리자 액세스를 제한합니다.
- 적절한 소스 제어 워크플로를 만듭니다.
내보내기 전 단계
이 시리즈의 첫 번째 기사에서 제시된 가정, 요구 사항 및 준비 단계는 변경되지 않았습니다. 자세한 내용은 다음 섹션을 참조하십시오.
기존 구성을 내보내고 configuration as code(CaC)으로 변환하기 전에 , 논리적이지만 필수적인 단계는 내보내기 전 정리 작업을 수행하는 것입니다. 이를 통해 사용하지 않거나 더 이상 필요하지 않은 구성이 CaC로 끌려가지 않도록 할 수 있습니다. 이 작업은 선택 사항이지만, 마이그레이션을 정리 작업의 기회로 활용하는 것이 좋습니다.
또한 CaC 실패의 원인이 될 수 있는 문제가 있는 객체를 식별하고자 합니다. 여기에는 동일한 이름을 가진 객체와 조직에 할당되지 않은 객체가 포함됩니다.
이를 위해 다음 플레이북을 만들어 실행해 보겠습니다.
--- - name: Run playbook to identify unused and problematic objects import_playbook: configify.aapconfig.aap_audit_problematic_objects.yml
작업 로그의 끝부분에는 다음과 유사한 여러 보고서가 있습니다.
TASK [List projects without an organization] **********************************************************************************************************
ok: [localhost] => {
"projects_without_org": [
"Project A"
]
}
TASK [List templates without inventory or project] *********************************************************************************************************
skipping: [localhost]
TASK [List credentials not used in credentials, templates, workflows, orgs and projects] *******************************************************************
ok: [localhost] => {
"unused_credentials": [
"Credential GitHub A",
"Credential Z (vault)"
]
}보고서에는 다음이 포함됩니다.
- 중복 객체: 자격 증명, 인벤토리, 프로젝트, 템플릿, 워크플로 및 알림 프로필. 이러한 객체는 이름이 동일합니다. 대부분의 경우 서로 다른 조직에 속하므로 중복된 이름이 허용됩니다. 중복 객체의 이름을 바꿀지 여부는 구성을 적용하고 변경하는 방식(즉, 모든 항목을 한 번에 또는 조직별로)에 따라 달라지며, 이에 대한 자세한 내용은 “구성 확인” 섹션에서 설명합니다. 향후 문제를 방지하려면 중복 객체의 이름을 바꾸는 것이 가장 좋습니다.
- 조직이 없는 프로젝트: 프로젝트에는 조직 필드가 필수이지만, 해당 프로젝트가 속한 조직이 삭제된 경우 이러한 개체가 존재할 수 있습니다. 모든 프로젝트가 조직에 속해 있는지 확인하세요. 그렇지 않으면 다른 클러스터로 마이그레이션하거나 다시 빌드할 때 해당 프로젝트를 생성할 수 없습니다.
- 인벤토리 또는 프로젝트가 없는 작업 템플릿: 조직이 없는 프로젝트와 마찬가지로, 템플릿에 할당된 인벤토리 또는 프로젝트가 삭제된 경우에도 이러한 문제가 발생할 수 있습니다. 이러한 작업 템플릿의 경우, 삭제하거나 필수 필드에 새 값을 입력하여 수정해야 합니다.
- 사용하지 않는 객체 :
- 다른 자격 증명, 템플릿, 워크플로, 조직 및 프로젝트에서 사용되지 않는 자격 증명입니다.
- 어떤 자격 증명에서도 사용되지 않는 사용자 정의 자격 증명 유형입니다.
- 템플릿, 워크플로 또는 동적 인벤토리에 사용되지 않는 프로젝트입니다.
- 템플릿, 워크플로 또는 프로젝트에서 사용되지 않는 알림 프로필입니다.
- 템플릿, 워크플로, 워크플로 노드 또는 구성된 인벤토리에 사용되지 않는 인벤토리입니다.
사람이 직접 이러한 보고서를 검토해야 합니다. 특정 객체가 사용되지 않는 것으로 보고되었다고 해서 자동으로 불필요한 객체가 되는 것은 아니며, 삭제할 수 있습니다. 예를 들어, 작업 템플릿이나 워크플로에서 특정 설정을 요청하는 경우 해당 설정을 선택해야 할 수 있습니다. 따라서 사용되지 않는 객체에 대한 보고서는 신중하게 검토해야 합니다.
이 시점에서는 문제가 있는 객체를 수정하고 내보내기를 진행해 보겠습니다.
개인 신원 증명서
조직이 없는 프로젝트는 문제가 되지만, 조직이 없는 자격 증명은 허용됩니다. 이러한 자격 증명은 해당 자격 증명을 만든 사용자가 소유한 개인 자격 증명이며, 소유자에게 명시적으로 권한이 부여되지 않는 한 해당 자격 증명이 속한 조직의 구성원에게는 표시되지 않을 수 있습니다.
유용성은 의문스럽지만, 현재 개인 자격 증명은 허용됩니다. 하지만 개인 자격 증명과 조직 자격 증명 간에 이름이 중복되는 것은 피하는 것이 좋습니다. 객체를 다시 생성해야 할 때 문제가 발생할 수 있기 때문입니다.
구성 데이터 내보내기
Ansible Automation Platform 인스턴스에서 모든 구성을 내보내는 것은 쉽습니다. 다음 플레이북을 생성하고 실행하세요.
--- - name: Run playbook to export AAP configurations import_playbook: configify.aapconfig.aap_audit_all.yml
기본적으로 Controller와 Hub의 구성을 내보냅니다. 태그를 사용하여 범위를 제한할 수 있습니다. 예를 들어 Controller 객체만 내보내려면 export_collections, export_repositories 태그를 건너뜁니다. 사용 가능한 태그의 전체 목록은 컬렉션 설명서에서 확인할 수 있습니다.
내보내기를 완료한 후 전체 작업 로그를 다운로드하고 다음 섹션으로 넘어가겠습니다.
출력 형식 지정
Ansible Automation Platform 클러스터의 크기와 객체 수에 따라 전체 내보내기 작업 출력이 상당히 커질 수 있습니다. 출력에서 특정 부분을 수동으로 복사하고 서식을 지정하는 작업은 시간이 많이 걸리고 지루할 수 있습니다.
VSCode의 Batch Replacer 확장 기능과 configify.aapconfig 컬렉션의 유지 관리자가 만든 스크립트를 사용하여 이 작업을 가속화하고 간소화하겠습니다.
작업 출력에서 Export Playbook이 수집한 객체를 출력하기 시작하는 부분을 찾아보겠습니다. 일반적으로 로그 중간 어딘가에 있을 것입니다. 건너뛰지 않은 첫 번째 “Show” 작업을 찾습니다.
태그가 건너뛰어지지 않았다고 가정하면 컬렉션을 표시하는 작업은 다음과 같습니다.
PLAY [Output all objects] *********************************************************************************************************
TASK [COLLECTIONS - Show published collections (formatted)] ************************************************************************************************
skipping: [localhost]
TASK [REPOS - Show configured remote repositories (formatted)] *********************************************************************************************
ok: [localhost] => {
"hub_objects_remotes": [
"{'name': 'rh-certified', 'repo_url': 'https://console.redhat.com/api/automation-hub/content/published/', 'repo_auth_url': 'https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token', 'repo_auth_token': '$encrypted$', 'requirements': {'collections': ['ansible.platform', 'ansible.controller']}}",
"{'name': 'community', 'repo_url': 'https://galaxy.ansible.com/api/', 'repo_auth_url': '', 'repo_auth_token': '', 'requirements': ''}"
]
}
TASK [SETTINGS - Show custom LDAP settings (formatted)] ****************************************************************************************************
ok: [localhost] => {
"controller_settings_ldap": {
"AUTH_LDAP_1_BIND_DN": "CN=user,CN=users,DC=examplec,DC=com",
"AUTH_LDAP_1_DENY_GROUP": "CN=user,OU=Users,DC=examplec,DC=com",
<...>첫 번째 “how” 작업부터 마지막 작업까지 출력을 복사합니다. 그런 다음 VSCode에서 다음을 실행합니다.
- Batch Replacer 확장 프로그램을 설치하세요.
- 빈 작업 공간(새 VSCode 창)을 엽니다.
- 앞서 복사한 출력 내용을 새 파일에 붙여넣고 저장합니다.
- 새 파일을 열고 aapconfig_testing 저장소 에서 Batch Replacer 스크립트를 붙여넣습니다 .
- 스크립트를 저장하지 않고 Ctrl + Shift + P 를 누르고 목록에서 Batch Replace를 선택하세요 . 확장 프로그램은 활성 탭의 바꾸기 규칙을 사용하여 현재 작업 공간의 모든 파일에 적용합니다.
- 오른쪽 하단에 “Batch replace completed.”라는 메시지가 표시되는지 확인하세요.
이 시점에서 이전에 내보낸 출력이 있던 파일에는 추가 Ansible 출력 없이 형식이 지정된 개체가 있어야 합니다.
hub_objects_remotes: [
{'name': 'rh-certified', 'repo_url': 'https://console.redhat.com/api/aut…..',
'repo_auth_url': 'https://sso.redhat.com/auth/realms/redhat…..',
'repo_auth_token': '$encrypted$',
'requirements': {'collections': ['ansible.platform', 'ansible.controller']}},
{'name': 'community', 'repo_url': 'https://galaxy.ansible.com/api/',
'repo_auth_url': '',
'repo_auth_token': '',
'requirements': ''}
] # type: ignore
controller_settings_ldap: {
'AUTH_LDAP_1_BIND_DN': 'CN=user,CN=users,DC=examplec,DC=com',
'AUTH_LDAP_1_DENY_GROUP': 'CN=user,OU=Users,DC=examplec,DC=com',
'AUTH_LDAP_1_GROUP_SEARCH': [
'DC=examplec,DC=com',
'SCOPE_SUBTREE',
'(objectClass=group)'
<...>형식화된 출력에 문제가 있을 것으로 예상하지는 않지만 파일을 살펴보고 형식에 명백한 문제가 없는지, Ansible 작업 출력이 남아 있지 않은지, 각 개체의 JSON 형식이 올바른지 확인하는 것이 좋습니다.
또한, Part 1의 ‘Handling objects with special characters’ 섹션에 설명된 대로 특수 문자에 문제가 없는지 확인합시다.
더불어, 특정 변수가 너무 많은 줄을 차지하는 경우 별도의 파일로 이동할 수 있습니다. 이 경우 플레이북에 다음과 같이 포함시킬 수 있습니다:
tasks:
- name: Include objects
ansible.builtin.include_vars:
dir: objects
extensions:
- ''
tags: always그렇지 않으면 이전 시리즈에서 설명한 대로 단일 파일일 수 있습니다.
tasks:
- name: Include variables
ansible.builtin.include_vars: all_aap_objects
tags: always구성 확인
CaC 객체의 포맷이 완료되고 준비가 되었으므로 이제 자동화를 실행하여 생성한 구성이 올바른지 확인할 수 있습니다. 안전을 위해 먼저 확인 모드에서 적용하여 특정 객체가 변경된 것으로 보고되는지 확인하는 것이 좋습니다.
이 시점에서 구성을 어떻게 적용할지 결정하는 것이 중요합니다. 첫 번째 옵션은 글로벌 관리자 계정을 사용하여 전체 구성을 한 번에 적용하는 것입니다. 이 경우, 앞서 설명한 대로 중복된 이름을 가진 객체를 제거하는 것이 중요합니다.
또 다른 옵션은 조직의 하위 집합을 관리하는 계정을 사용하는 것입니다. 이 접근 방식의 사용 사례로는 여러 팀이나 부서가 있고 각 부서가 구성의 하위 집합을 개별적으로 관리하는 대규모 조직을 들 수 있습니다. 이 경우, 중복된 개체가 다른 조직의 하위 집합에 속하기만 하면 동일한 이름을 가진 개체가 존재할 수 있습니다.
이 접근 방식을 구현하기 위해 구성을 별도의 파일이나 저장소로 분할할 필요는 없습니다. 각 팀은 다음과 같이 관리하는 조직 목록이 포함된 limit_organizations 변수를 사용하면 됩니다 .
limit_organizations: ['Org D','Org E']
이 접근 방식을 구현할 때는 실행 환경, 인증 설정, 인스턴스 그룹, 사용자, 팀, 자격 증명 유형, 허브 구성 등 특정 조직에 속하지 않는 구성이 있다는 점을 기억하는 것이 중요합니다. 이러한 설정은 글로벌 관리자가 적용해야 하며, 이를 위해 별도의 파일에 저장해야 할 수도 있습니다.
내보내기 과정에서 생성한 구성을 검증하기 위해, 객체 설명과 트리거를 포함하는 configify.aapconfig.aap_configure.yml 파일을 포함하는 플레이북을 만들어 보겠습니다. 검증을 위해 먼저 체크 모드에서 실행해 보겠습니다.
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출력에서 변경 사항을 보고하는 객체를 찾습니다. 이러한 항목을 조사하여 변경 사항이 다르게 표시된 이유를 파악해야 실제 모드에서 플레이북을 실행할 때 의도치 않게 원치 않는 변경 사항이 발생하는 것을 방지할 수 있습니다.
명심해야 할 몇 가지 사항이 있습니다.
- 이 글을 쓰는 시점에는 Ansible Automation Platform 2.5 전용 구성인 인증 모듈이 확인 모드를 따르지 않습니다. 인증 설정은 매 실행 시 적용됩니다. 이는 종속성 컬렉션 관련 문제이며, 관리자에게 티켓을 제출했습니다.
- 인벤토리, 호스트, 워크플로, 자격 증명이 포함된 알림 프로필 등 일부 객체는 검사 모드에서 항상 변경 사항을 보고합니다. 이는 종속성 컬렉션 중 하나와 관련된 문제이며, 이에 따라 티켓이 생성되었습니다.
- 기본 풀 정책이 적용된 실행 환경에서도 변경 사항이 보고됩니다. 이는 종속성 컬렉션의 해당 모듈에 기본 옵션이 없고 풀 정책 필드에 빈 값을 허용하지 않기 때문입니다.
Red Hat 인증 컬렉션과 관련된 이러한 문제가 해결될 때까지 가장 쉬운 해결책은 다음과 같습니다.
- 값이 올바른지 다시 한번 확인하세요.
- Ansible Automation Platform 인스턴스의 백업을 만듭니다.
- 보고된 다른 모든 변경 사항을 조사하고 수정한 후, 확인 모드를 끄고 확인 모드에서 변경 사항을 보고하던 설정이 이제 녹색인지 확인합니다.
그래도 가끔씩 일부 줄에서 문제가 해결되지 않으면 GUI를 통해 무엇이 변경되었는지 확인해야 할 수도 있습니다.
후속 조치 단계
이제 모든 Ansible Automation Platform 설정을 코드로 설명하는 좋은 상태가 되었습니다. 구성을 검증하고 필요에 따라 적용하거나 변경할 수 있습니다. 이 단계에서는 GUI를 통해 수동으로 변경할 수 있는 관리자 수를 제한하는 것이 좋습니다. 여기에는 전역 관리자와 특정 조직 또는 객체를 관리하는 관리자가 포함됩니다. 일부 조직에서는 기본 관리자 계정을 제외한 모든 관리자 계정을 비활성화합니다.
당연히 CaC를 통해 변경하고 싶습니다. 이를 위해 다음을 제거해 보겠습니다.
superuser필드가 True로 설정된 사용자를 설명하는 줄입니다 .- 역할 이름에 admin이 포함된 역할을 설명하는 줄(예: 조직 관리자, JobTemplate 관리자 등).
그런 delete_objects: true를 지정하여 자동화를 실행합니다.
고려해야 할 또 다른 후속 조치는 소스 제어와 관련된 적절한 워크플로를 구축하는 것입니다. 앞으로 Ansible Automation Platform 클러스터를 코드로 관리하게 되므로, 적절한 변경 관리 및 동료 검토, 브랜칭 전략, 그리고 Git 저장소 내 권한을 보장하는 것이 중요합니다. 다음 단계를 포함하되 이에 국한되지 않습니다.
- 자동화에 사용되는 브랜치에 직접 커밋하는 것을 허용하지 않습니다.
- 병합 요청을 병합하기 전에 하나 이상의 승인을 요구합니다.
- 변경 사항을 승인하고 병합할 수 있는 사용자 수를 제한합니다.
- 브랜치 이름과 커밋 메시지에 대한 특정 패턴이 필요합니다.
구성 단계는 소스 제어 시스템에 따라 다르며 이 문서의 범위를 벗어납니다.
마지막 생각
작업에 적합한 도구를 선택하면 코드 구성은 단순한 코딩이 아닌 조직 및 프로세스 관련 과제로 더욱 중요해집니다. 다양한 마이그레이션에 대해 논의할 이 시리즈의 다음 편을 기대해 주세요.
다음 시리즈를 팔로우하세요:
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로 구성 마이그레이션.
