Ansible Automation Platform 2.6 업그레이드 경로 계획

Red Hat Ansible Automation Platform 2.6 릴리스는 중요한 이정표가 되었습니다. 업그레이드를 시작하기 전에 원활한 전환을 위해 알아야 할 3가지 주요 사항이 있습니다.

• 이 버전은 RPM 기반 설치 프로그램을 지원하는 마지막 버전입니다. RPM 방식을 사용하는 Red Hat Ansible Automation Platform 2.6은 Red Hat Enterprise Linux(RHEL) 9에서만 사용할 수 있으며, RPM 설치 프로그램은 이번 릴리스 이후에 지원이 종료됩니다. Ansible Automation Platform 2.7은 컨테이너화된 설치 방법, Red Hat OpenShift 오퍼레이터 또는 Red Hat의 클라우드 서비스만 지원하므로 지금 바로 전환을 시작해야 합니다.
• Ansible Automation Platform 2.6은 핵심 릴리스입니다. 향후 플랫폼 버전으로 업그레이드하려면 반드시 2.6 버전을 거쳐야 합니다. 이 과정은 생략할 수 없습니다.
• RHEL 8은 더 이상 지원되지 않습니다. 여전히 RHEL 8을 사용 중인 경우, Ansible Automation Platform 2.6으로 업그레이드하기 전에 RHEL 9(또는 RHEL 10)로 마이그레이션해야 합니다.

업그레이드 계획 수립

Ansible Automation Platform 2.6으로의 전환을 계획할 때는 다음 두 가지 중요한 사항을 고려하여 업그레이드 계획을 수립해야 합니다.

한 번에 하나의 요소만 변경할 수 있습니다. 기본 운영 체제(OS), 설치 방법, 제품 버전 중 무엇을 변경하든 설치 프로그램은 실행당 하나의 변경 사항만 처리합니다. 따라서 설치 프로그램을 여러 번 실행해야 할 수도 있습니다. 자세한 작동 방식은 공식 문서를 참조하세요.

대부분의 경우 새로 설치해야 합니다. 동일한 아키텍처에서 2.5를 2.6으로 업그레이드하거나 특정 Red Hat OpenShift 오퍼레이터 배포와 같은 몇 가지 시나리오를 제외하고는, 새로운 Ansible Automation Platform 2.6 인스턴스를 배포한 후 구성을 마이그레이션해야 합니다.

여기에서 다음과 같은 핵심 질문이 생깁니다. 기존 구성을 어떻게 새 인스턴스로 가져올 수 있을까요? 그 답은 Ansible Automation Platform 구성이 PostgreSQL 데이터베이스에 저장된다는 점을 이해하는 것에서 시작됩니다. 업그레이드 전략은 해당 데이터를 어떻게 이전할 것인지에 관한 것입니다.

업그레이드 접근 방식

Ansible Automation Platform 2.6으로 가는 경로는 데이터베이스 중심 마이그레이션과 API 중심 마이그레이션의 두 가지가 있습니다. 환경, 요구 사항, 절충 가능한 요소에 따라 적절한 방식을 선택하세요.

데이터베이스 중심 접근 방식은 Ansible Automation Platform을 데이터가 정보 소스(Source of Truth)인 스테이트풀(Stateful) 시스템으로 취급합니다. API 중심 접근 방식은 플랫폼을 코드형 구성(Configuration as Code, CaC)으로 취급하며, 정보 소스는 구성 파일에 있습니다. 아래 표를 참조하여 각 접근 방식에 대한 기술적 고려 사항을 평가해 보세요.

데이터베이스 중심 마이그레이션

데이터베이스 중심 마이그레이션은 문서화되고 완전하게 지원되는 경로로, 업그레이드 프로세스를 통해 전체 데이터베이스를 보존하고 마이그레이션합니다. 무엇이 문제일까요? "업그레이드 댄스(Upgrade dance)"가 그 원인입니다. RHEL 8에서 RHEL 9로, RPM 방식에서 컨테이너화 방식으로, 그리고 Ansible Automation Platform 2.4/2.5에서 2.6으로 전환할 수 있습니다. 이때 각 단계는 별도의 단계로서 자체 인프라가 필요합니다. 

이로 인해 프로비저닝하고 관리해야 할 중간 환경이 많아질 수 있습니다. 마이그레이션 작업의 시작점과 최종 목표, 그리고 환경 규모(데이터베이스 크기)에 따라 이 작업은 많은 시간이 소요될 수 있습니다.

중요 주의 사항: 이러한 복잡성으로 인해 Ansible Automation Platform의 관리형 클라우드 서비스 오퍼링을 사용하려는 경우, 데이터베이스를 관리형 서비스에 업로드하려면 지원 티켓을 생성해야 합니다. 이 프로세스에 대한 상세 내용은 여기에서 확인할 수 있습니다. 이 작업을 직접 수행하려면 API 중심 접근 방식을 사용해야 합니다.

API 중심 마이그레이션

이 접근 방식은 Red Hat에서 공식적으로 지원하지 않습니다. 다만 이 마이그레이션 기술을 지원하는 개별 구성 요소는 지원 대상에 포함됩니다. 그럼에도 불구하고 이 방식은 특히 대규모 환경에서 작업 속도를 크게 높여줄 수 있습니다. 타겟 플랫폼으로 한 번에 이동하므로 중간 설치 과정이 필요하지 않습니다.

이 방법에서는 API 호출을 사용하여 Ansible Automation Platform의 구성을 내보낸 후, 구성 파일이나 임시 데이터베이스와 같은 로컬 환경에 저장합니다. 이후 필요에 따라 파일을 수정한 다음, 다시 API를 통해 다른 플랫폼으로 복원할 수 있습니다. 이 방법에는 다음과 같은 추가적인 장점도 있습니다. 워크플로우에 코드형 구성(Configuration as Code, CaC)을 도입하므로, 향후 CaC 방식을 사용하여 플랫폼을 관리할 수 있는 기반을 마련해 줍니다.

고려해야 할 사항은 무엇일까요? 작업 내역이 손실될 수 있으나 외부 로그 애그리게이터를 통해 보완할 수 있으며, 비밀 정보(Secrets)는 외부 비밀 정보 관리자를 사용하여 신중하게 처리해야 합니다. 특히 private automation hub 및 Event-Driven Ansible 오브젝트의 경우, 가져오기에 적합한 형식을 맞추기 위해 내보낸 구성 파일을 편집해야 할 수도 있습니다.

비밀 정보에 대한 참고 사항

자격 증명 및 알림 비밀 정보는 구성 데이터베이스에 저장되며 데이터베이스 SECRET_KEY로 암호화됩니다. 이 정보는 암호화되어 있으므로 API를 통해 값을 내보낼 수 없습니다. 따라서 구성의 비밀 정보에 액세스하려면 데이터베이스 서버에 대한 root 액세스 권한이 필요합니다. 이 과정에서 비밀 정보가 일반 텍스트로 노출되므로, 비밀 정보를 Ansible vault로 다시 암호화하는 등 매우 주의하여 처리해야 합니다. 

하지만 HashiCorp Vault와 같은 외부 비밀 정보 관리자를 사용하는 경우, 해당 정보가 Ansible Automation Platform에 저장되지 않으므로 문제가 되지 않습니다. 또는 관리할 비밀 정보가 적은 경우에는 새 플랫폼에서 직접 비밀 정보를 입력하는 것이 더 간단할 수 있습니다.

두 가지 방법 모두에 대한 고려 사항

어떤 경로를 선택하든 다음 사항에 유의하세요. 외부 통합 및 API 토큰에 대한 점검이 필요할 수 있습니다. 

Ansible Automation Platform 2.5에는 오토메이션 컨트롤러, Ansible 오토메이션 허브, Event-Driven Ansible 컨트롤러를 단일 인터페이스로 연결하는 통합 프론트엔드인 오토메이션 게이트웨이가 도입되었습니다. 이로 인해 많은 API 엔드포인트가 새로운 경로로 이동했습니다. 버전 2.6에서는 이러한 통합 엔드포인트에 대한 이전 버전과의 호환성을 유지하지만, 향후 릴리스를 위해 이를 업데이트해야 합니다. 또한 플랫폼에서 발급한 대부분의 토큰을 재생성하고 재배포해야 합니다. 추가 서버 프로비저닝이 필요할 수 있으며, 로드 밸런서를 새로운 게이트웨이 서비스로 업데이트해야 합니다.

외부 관리 데이터베이스

외부에서 관리되는 데이터베이스를 사용하는 고객은 추가 사항을 고려해야 합니다.  첫째, Ansible Automation Platform 2.4는 Postgres 13을 사용합니다. 이 데이터베이스는 2.5 버전의 경우 Postgres 15로, 2.6 버전의 경우 PostgreSQL 15로 업그레이드됩니다. Ansible Automation Platform 2.6은 고객이 제공하는 PostgreSQL 16 및 17 데이터베이스도 지원합니다. 이 데이터베이스 업그레이드 절차는 마이그레이션 및 "업데이트 프로세스"에서 핵심적으로 고려해야 할 사항입니다. 또한 고객이 이 업데이트 과정을 거치지 않고 기존 데이터베이스를 재사용할 수 없는 주요 이유이기도 합니다.  특히 Ansible Automation Platform 2.5 이상 버전에서는 고객이 제공하는 데이터베이스에서 ICU(International Components for Unicode)를 활성화해야 합니다. 이 기능은 EDB, Amazon Web Services Relational Database Service(AWS RDS), Azure SQL Database와 같은 대부분의 주요 데이터베이스 제공업체에서 지원하지만 기본적으로 활성화되어 있지는 않습니다. 이러한 데이터베이스 호환성 문제로 인해 기존 데이터베이스의 스키마를 단순히 업데이트하는 방식은 사용할 수 없습니다.

플레이북 호환성

Ansible Automation Platform을 업그레이드하면 기본 실행 환경에 포함된 ansible-core 버전도 함께 업그레이드됩니다. 최신 버전의 플랫폼에서도 항상 이전 실행 환경을 실행할 수 있으므로 이전 버전과의 호환성은 유지됩니다. 다만 새로운 기능과 보안 수정 사항을 활용할 수 있도록 업그레이드하는 것을 적극 권장합니다.

실행 환경을 업그레이드하면 새로운 버전의 Ansible core로 업그레이드되므로 몇 가지 변경 사항이 발생할 수 있습니다.  변경 사항은 다음과 같습니다.

Ansible Automation Platform 2.4에서 2.6으로 업그레이드(ansible-core 2.15에서 2.16으로 업그레이드)

이것은 마이너 업그레이드입니다. 가장 주목할 만한 변경 사항은 조건문의 일부 경고를 이제 오류로 처리한다는 점입니다. 그 외의 영향은 미미합니다.

ansible-core 2.18로 업그레이드(Ansible Automation Platform 2.6의 선택적 실행 환경) Ansible Automation Platform 2.6에서 선택적으로 지원하는 실행 환경인 이 업그레이드 버전은 훨씬 더 많은 변화를 가져옵니다. 구체적인 내용은 다음과 같습니다.

• 대상 노드의 Python 2.7 및 3.6 버전은 더 이상 지원되지 않습니다. 따라서 이 실행 환경으로는 더 이상 RHEL 6 호스트를 대상으로 작업할 수 없습니다. RHEL 7 호스트를 Ansible Automation Platform으로 자동화하려면 Red Hat Software Collections를 통해 제공되는 Python 3.8이 필요합니다.
• 이제 실행 환경에는 Python 3.11 버전이 포함됩니다. 사용자 지정 및 타사 Python 라이브러리는 3.11과 호환되는 라이브러리로 업데이트해야 합니다.
• Python의 "dead batteries" 정리가 진행 중입니다. PEP 594는 향후 출시될 여러 Python 릴리스에서 유지 관리되지 않거나 안전하지 않고 더 이상 사용되지 않는 라이브러리를 표준 라이브러리에서 제거할 예정입니다. Python 3.11부터 지원 중단(Deprecation) 경고가 시작됩니다. 일부 라이브러리는 3.12 버전에서 제거되며, 3.13 버전에서 대대적인 삭제가 이루어집니다.

대다수 고객에게 이는 즉각적인 우려 사항은 아니지만, 미리 대비할 수 있도록 지금부터 지원 중단 경고에 주의를 기울이는 것이 좋습니다.

지원되는 ansible-core 버전에 대한 자세한 내용은 Red Hat의 공식 지원 정책을 참조하세요.

Ansible Automation Platform 2.6으로의 전환은 단순한 버전 업데이트를 넘어 차세대 자동화의 기반을 마련하는 전략적 조치입니다. 현재 인프라에 가장 적합한 마이그레이션 경로를 선택하여 자동화의 복원력을 유지하고 보안을 강화하며 향후 변화에 대비할 수 있습니다.

추가 리소스

• 문서: Python, AsyncIO 및 대량 작업을 활용한 Ansible Automation Platform 2.6 업그레이드 자동화
• Ansible Automation Platform 릴리스 노트 및 문서를 확인해 보세요.
• Ansible Automation Platform의 새로운 기능