Ansible Automation Platform 2.4에서 새로운 구성된 인벤토리 기능을 사용하는 방법

새로운 구성된 인벤토리 기능

이 블로그에서는 Ansible이 구성한 플러그인을 기반으로 인벤토리를 더 스마트하게 처리하는 새로운 방법에 대한 아이디어를 소개했습니다. 이제 Ansible Automation Platform 2.4에서 이 기능을 완벽하게 지원되는 기능으로 사용할 수 있습니다. 이 블로그에서 이 기능에 대해 자세히 알아보세요! 

구성된 인벤토리는 기존 스마트 인벤토리 기능의 후속 기능이며, 이제  Ansible Automation Platform 컨트롤러에서 인벤토리를 생성할 때 또 다른 선택 사항으로 표시됩니다. 이렇게 하면 '일반' 인벤토리 목록을 입력으로 사용하고, 사용자 정의 작업을 수행하고, 필터링하고, 입력 인벤토리의 콘텐츠로 결과 인벤토리를 생성합니다.

구성된 인벤토리란?

이 기능은 사용자가 여러 인벤토리의 호스트에 대해 작업을 실행할 수 있다는 점에서 기존 스마트 인벤토리와 유사합니다. 

그러나 구성된 인벤토리에는 hostvars와 groupvars를 둘 다 정의하고 사용하는 기본 제공 기능을 포함하여 새로운 기능이 도입되었습니다.

• 그룹은 구성된 인벤토리에 있으며 해당 구성에서 중요한 역할을 합니다.
• 사용자 정의 로직(그룹, 변수 및 하위 선택 호스트를 추가하는 데 사용됨)은 ansible-inventor를 통해 실행되며(컨트롤러에서 자동으로 수행됨), 인벤토리 업데이트를 통해 UI에 표시됩니다.
• 사용자 정의 로직의 형식은 널리 사용되는 Ansible 스타일 jinja2입니다.

기본 원칙은 구성된 인벤토리를 생성하는 경우 플레이북을 작성할 때와 동일하게 생각한다는 것입니다. 이는 애플리케이션의 관점에서 볼 때 인벤토리에 대해 생각해야 했던 스마트 인벤토리와는 대조적입니다.

UI의 구성된 인벤토리

Inventories(인벤토리) 아래에 있는 “Add constructed inventory(구성된 인벤토리 추가)”를 클릭하면 다음과 같은 메뉴가 표시됩니다.

구성된 인벤토리에 고유한 세 가지 주요 항목이 있습니다.

• Input inventory(입력 인벤토리)에는 구성된 인벤토리가 인벤토리 콘텐츠(호스트, 그룹 등)를 가져올 기존 인벤토리가 나열됩니다.
• Limit은 ansible-inventory에 직접 전달되며, Ansible 호스트 패턴의 표준 구문(Syntax)을 사용하여 호스트를 필터링할 수 있습니다.
• Source vars는 ansible.builtin.constructed 인벤토리 플러그인에 대한 입력입니다.

참고: 호스트 이름과 변수가 충돌하는 경우 마지막 인벤토리의 변수가 우선하도록 입력 인벤토리가 정렬됩니다. 변수는 병합되므로 이전 입력 인벤토리에서 변수를 설정 해제하지 않습니다. 호스트 이름과 변수가 충돌하지 않으면 문제가 되지 않으므로 여기에 사용된 예제에서는 순서를 언급합니다.

아래 예제에서 살펴볼 것이므로 지금은 이에 대해 걱정할 필요가 없습니다.

가장 단순한 형태의 구성된 인벤토리

입력 인벤토리는 1개 이상 있어야 하지만, 다른 필드는 입력할 필요가 없습니다. 경우에 따라 입력 인벤토리를 두 개 이상 제공하고 limit과 source-vars는 비워두는 것이 합리적일 수 있습니다. 그런 다음 두 입력 인벤토리에서 인벤토리 콘텐츠의 조합에 대해 작동하는 작업을 실행할 수 있습니다. 

고급 구성된 인벤토리 활용 사례

궁극의 뛰어난 기능을 제공하는 limit 및 Source vars의 기능을 설명하려면 구체적인 예를 살펴보는 것이 도움이 될 것입니다.

구성된 인벤토리 설정

동일한 클라우드 제공업체의 두 인벤토리가 있고 이 두 인벤토리가 서로 다른 지역을 다루므로, 서로 다른 호스트 집합이 있다고 가정해 보겠습니다. 이러한 인벤토리는 별도의 계정, 별도의 기능, 별도의 위치로 인해 별도로 유지됩니다. 이 예제에서는 간단히 동부/서부 지역 입력 인벤토리가 있다고 가정해 보겠습니다.

Git 기반의 .ini 파일에서 인벤토리를 가져옵니다. 이는 devops 유형 사례를 사용하여 config-as-code 접근 방식을 통해 유지 관리됩니다.

먼저 새 프로젝트를 설정하고 동기화하여 인벤토리 정보를 가져올 위치를 확인합니다. UI에서 Projects(프로젝트)를 선택하고 Add(추가)를 클릭합니다.

입력한 다음 저장하면 프로젝트가 자동으로 동기화됩니다.

이제 프로젝트 파일의 정보를 참조할 새 인벤토리를 생성합니다. Inventories(인벤토리)에서 Create(생성)를 클릭합니다.

이제 Inventory(인벤토리) Sources(소스)를 클릭하고 Add(추가)를 클릭합니다.

이 소스에 사용할 이름을 입력합니다. 이 경우 동부 지역 호스트의 소스를 프로젝트에서 가져옴으로 정의하고, 방금 추가한 프로젝트와 적절한 east.ini 소스 파일

을 제공합니다.

저장한 다음 Sync(동기화) 버튼을 클릭하여 정보를 가져옵니다.

동기화된 후에 작업 출력을 보면 처리된 내용을 확인할 수 있습니다.

이 경우 3개의 호스트와 3개의 그룹이 검색되어 자동으로 추가된 것을 확인할 수 있습니다. 이 정보는 UI의 Hosts(호스트)에서 확인할 수 있습니다.

이제 서부 지역에 대해 동일한 작업을 수행해야 합니다. 연습 삼아 위의 예제에 따라 직접 작업해 보세요. 단, 이 경우 west.ini 정보를 소스로 사용합니다.

이 가상 시나리오에서는 정의한 기준에 따라 일부 호스트(동부 지역과 서부 지역의 호스트)에 대해 작업을 동시에 실행하려고 합니다.

이제 UI에서 새로운 구성된 인벤토리를 생성합니다.

두 클라우드 인벤토리를 모두 입력으로 추가합니다. 그런 다음 source-vars를 사용하여 새 그룹 “target_group”을 구성한 다음 해당 그룹에서 limit을 사용하여 필터링합니다.

동기화되면 작업 출력을 통해 어떤 일이 발생하는지 확인할 수 있습니다.

이제 4개의 그룹과 4개의 호스트가 있으며, 이는 UI의 Hosts(호스트)와 Groups(그룹) 아래에서 찾아보고 결과를 확인할 수 있습니다. 이 특정 예제의 그룹을 살펴보겠습니다.

구성된 인벤토리 업데이트가 실행되면 입력 인벤토리의 "account_1234", "account_4321" 및 "accounts" 그룹이 구성된 결과 인벤토리로 복사됩니다. 

구성된 인벤토리에는 곧 짧게 설명할 “target_group” 그룹도 포함되어 있습니다.

이 구성된 인벤토리를 작업 템플릿에서 사용하여 작업을 실행하는 경우 정의된 모든 그룹을 작업에서 사용할 수 있습니다.

이제 본격적인 기능이 나오는데, 구성된 인벤토리 양식에서 source-vars를 참조하면 새로운 “target_group” 그룹의 정의를 찾을 수 있습니다.

    plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev"

"target_group"은 원래 동부 및 서부 인벤토리에는 없었습니다. 이는 업데이트가 수행될 때 구성된 인벤토리 플러그인에 의해 생성되었습니다. 

이 경우 jinja2 템플릿 {{ account_alias | default("") == "product_dev" }}가 지정된 호스트에 대해 사실인 값(예: 1, '1' 또는 True)으로 확인되면 호스트가 그룹에 추가됩니다. 

업데이트하는 동안 Ansible은 이러한 평가를 수행하기 위해 입력 인벤토리의 모든 호스트에 대해 이러한 템플릿을 렌더링합니다. 더 큰 입력 인벤토리의 경우 업데이트를 완료하는 데 몇 분 정도 걸릴 수 있습니다. 

구성된 인벤토리는 이를 사용하는 모든 템플릿의 작업 실행 전에 자동으로 업데이트되지만, 업데이트가 너무 오래 걸리는 경우 UI의 Constructed Inventory settings(구성된 인벤토리 설정)에서 Update cache timeout(업데이트 캐시 시간 초과) 옵션을 사용하여 업데이트 빈도를 완화할 수 있습니다. 이 옵션을 > 1 값으로 설정하면 구성된 인벤토리 업데이트 결과를 해당 시간(초) 동안 캐시합니다.

“target_group”을 생성하는 jinja2 템플릿은 if호스트를 포함합니다. 해당 호스트를 검사할 때 “account_alias”의 hostvar가 존재하고 “product_dev”와 같습니다. 

“| default” 구문(Syntax)은 일부 호스트에 대해 변수가 정의되지 않은 경우에 필요합니다. 

"strict: true"는 정의되지 않은 변수를 참조하면 인벤토리 업데이트에 실패하여 "| default"가 필요하도록 합니다. 

“|default| 와 strict 매개 변수는 정의되지 않은 대소문자를 명시적으로 지정하도록 하는 모범 사례입니다.

그룹을 구성하면 플레이북에서 참조할 그룹을 즉석에서 추가하는 데 유용할 수 있습니다. 그렇게 하려는 이유는 무엇일까요? 호스트 패턴에서 사용하는 것처럼(이 예시에서는 limit) hostvar를 사용하여 수행할 수 없는 작업을 그룹으로 수행할 수 있기 때문에 hostvar에서 그룹을 합성하는 것이 편리한 경우가 있습니다. 

구성된 인벤토리에 대해 생성된 모든 호스트를 보면 다음과 같습니다.

이 예제에서는 host3(동부 인벤토리)과 host5(서부 인벤토리)가 포함되어 있지 않음을 확인할 수 있습니다. 이는 입력 인벤토리에서 이러한 호스트가 지정된 "product_dev" 값과 일치하지 않는 "account_alias"가 있는 다른 계정(account_4321)에 있기 때문입니다. account_4321의 그룹을 구성된 인벤토리로 가져온 경우에도 해당 그룹의 호스트가 요구 사항과 일치하지 않으므로 가져온 그룹이 구성된 인벤토리에서 비어 있습니다.

Source vars 입력에는 그룹을 추가하는 것 외에도 호스트 변수가 포함될 수 있습니다.

Alan의 Github 리포지토리에는 유용할 수 있는 또 다른 예제도 포함되어 있습니다. construct.yml에서 호스트의 '상태'를 확인하고 종료 또는 특정 환경(dev)의 일부인지 여부에 따라 호스트를 여러 그룹에 할당합니다. 이 .yml 파일의 정보 소스는 Ansible Automation Platform 외부의 다른 시스템에서 가져올 수 있으며, 이를 사용하여 호스트의 하위 집합에 대한 자동화 실행을 즉석에서 수행할 수 있습니다.

디버깅 팁

위 예제를 사용하려면 구성된 인벤토리를 개발할 때 limit 값을 삭제하고 source-vars를 다음 콘텐츠로 변경하는 것이 좋습니다.

이렇게 하면 유사한 템플릿 {{ account_alias | default(“”) }}가 실행되고 “effective_account_alias”라는 이름의 변수에 저장됩니다. limit을 비워두면 입력 인벤토리에서 모든 호스트를 가져옵니다. 이를 통해 host3에 대해 아래에 표시된 개별 호스트의 포함 기준에 대한 세부 정보를 검사할 수 있습니다.

여기에서 hostvar “effective_account_alias” 평가 값이 “product_dev”가 아닌 “sustaining”임을 확인할 수 있습니다. 

구성된 인벤토리 플러그인에는 매우 유용하고 영향력이 클 수 있는 다양한 옵션이 있습니다. 자세한 내용은 https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html에서 플러그인 설명서를 참조하세요.

몇 가지 다른 예시는 https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed의 사용자 가이드에서도 확인할 수 있습니다.

요약:

이 블로그가 Ansible Automation Platform 내에서 구성된 인벤토리의 실제 사용을 이해하는 데 도움이 되기를 바랍니다. 

호스트 패턴 및 구성된 인벤토리 플러그인과 같은 기반 개념은 일반적인 Ansible 개념이므로 사용자는 임의로 복합적인 기준에 따라 그룹, 변수를 추가하거나 호스트를 포함할 수 있습니다.

장점은 다음과 같습니다.

• 여러 정보 소스에서 그룹을 동적으로 생성힐 수 있습니다.
• 여러 인벤토리에서 호스트를 필터링, 구문 분석 및 제한할 수 있지만 이를 자동화 실행에 사용되도록 허용할 수 있습니다.
• 필터링 시 사전 정의된 hostvars를 사용할 수 있습니다.
• 여러 팀이 호스트와 연결된 자체 인벤토리 및 메타데이터를 소유할 수 있으며 Ansible Automation Platform을 통해 중앙에서 사용할 수 있습니다.