Ansible Tower에서 Ansible Content Collections의 인벤토리 플러그인 사용

IT 환경은 점점 더 복잡해지고 있습니다. 이러한 조건에서는 IT 자동화 시스템이 네트워크에 존재하고 처리 대상인 노드에 대한 최신 정보를 보유하는 것이 중요합니다. Red Hat Ansible Automation Platform에서는 이 문제가 소위 인벤토리(목록) – 관리 노드 목록입니다.

가장 간단한 형태의 인벤토리는 정적 파일입니다. Ansible로 작업을 시작할 때는 이것이 이상적이지만 자동화가 증가할수록 불충분해집니다.

그 이유는 다음과 같습니다.

1. 상황이 지속적으로 변할 때, 워크로드와 그에 따라 실행되는 노드가 왔다 갔다 할 때 모니터링되는 노드의 전체 목록을 어떻게 업데이트하고 유지 관리합니까?
2. 특정 자동화를 적용하기 위한 노드를 구체적으로 선택하기 위해 IT 인프라의 구성 요소를 어떻게 분류합니까?

동적 재고는 이 두 가지 질문에 대한 답변을 제공합니다(동적 인벤토리) – 진실의 소스를 참조하여 자동화할 노드를 검색하는 스크립트 또는 플러그인입니다. 또한 동적 인벤토리는 특정 Ansible 자동화를 수행하기 위한 대상 시스템을 보다 정확하게 선택할 수 있도록 노드를 자동으로 그룹으로 분류합니다.

인벤토리 플러그인 Ansible 사용자에게 외부 플랫폼에 액세스하여 대상 노드를 동적으로 검색하고 인벤토리를 생성할 때 이러한 플랫폼을 정보 소스로 사용할 수 있는 기능을 제공합니다. Ansible의 표준 소스 목록에는 클라우드 플랫폼 AWS EC2, Google GCP 및 Microsoft Azure가 포함되어 있으며 Ansible을 위한 다른 많은 인벤토리 플러그인도 있습니다.

Ansible Tower에는 다양한 기능이 포함되어 있습니다. 인벤토리 플러그인는 즉시 사용 가능하며 위에 나열된 클라우드 플랫폼 외에도 VMware vCenter, Red Hat OpenStack Platform 및 Red Hat Satellite와의 통합을 제공합니다. 이러한 플러그인의 경우 대상 플랫폼에 연결하기 위한 자격 증명을 제공하기만 하면 Ansible Tower에서 인벤토리 데이터 소스로 사용할 수 있습니다.

Ansible Tower에 포함된 표준 플러그인 외에도 Ansible 커뮤니티에서 지원하는 다른 인벤토리 플러그인이 있습니다. 전환과 함께 Red Hat Ansible 콘텐츠 컬렉션 이러한 플러그인은 해당 컬렉션에 포함되기 시작했습니다.

이 게시물에서는 고객이 자신의 모든 장치에 대한 정보를 CMDB에 저장하는 인기 있는 IT 서비스 관리 플랫폼인 ServiceNow용 인벤토리 플러그인을 사용하는 예를 살펴보겠습니다. 또한 CMDB에는 서버 소유자, 서비스 수준(프로덕션/비프로덕션), 설치된 업데이트, 유지 관리 기간에 대한 정보 등 자동화에 유용한 컨텍스트가 포함될 수 있습니다. Ansible 인벤토리 플러그인은 ServiceNow CMDB와 함께 작동할 수 있으며 컬렉션의 일부입니다. 서비스 포털에서 galaxy.ansible.com.

Git 저장소

Ansible Tower 컬렉션의 인벤토리 플러그인을 사용하려면 해당 플러그인을 프로젝트 소스로 설정해야 합니다. Ansible Tower에서 프로젝트는 자동화 플레이북뿐만 아니라 변수 및 인벤토리 목록도 동기화하는 데 사용할 수 있는 git 저장소와 같은 일종의 버전 제어 시스템과의 통합입니다.

우리 저장소는 실제로 매우 간단합니다.

├── collections
│   └── requirements.yml
└── servicenow.yml

servicenow.yml 파일에는 플러그인 인벤토리에 대한 세부 정보가 포함되어 있습니다. 우리의 경우 ServiceNow CMDB에서 사용하려는 테이블을 지정하기만 하면 됩니다. 또한 노드 변수로 추가될 필드와 생성하려는 그룹에 대한 특정 정보를 설정합니다.

$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
  - key: sn_sys_class_name | lower
	prefix: ''
	separator: ''
  - key: sn_os | lower
	prefix: ''
	separator: ''

이는 어떤 방식으로든 연결할 ServiceNow 인스턴스를 지정하지 않으며 연결을 위한 자격 증명도 지정하지 않습니다. 나중에 Ansible Tower에서 이 모든 것을 구성하겠습니다.

파일 컬렉션/requirements.yml Ansible Tower가 필수 컬렉션을 다운로드하여 필수 인벤토리 플러그인을 얻을 수 있도록 필요합니다. 그렇지 않으면 모든 Ansible Tower 노드에 이 컬렉션을 수동으로 설치하고 유지 관리해야 합니다.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

이 구성을 버전 제어에 푸시하면 해당 저장소를 참조하는 Ansible Tower에서 프로젝트를 생성할 수 있습니다. 아래 예는 Ansible Tower를 github 저장소에 연결합니다. SCM URL에 주의하세요. 이를 통해 개인 저장소에 연결하기 위한 계정을 등록할 수 있을 뿐만 아니라 체크아웃할 특정 브랜치, 태그 또는 커밋을 지정할 수 있습니다.

ServiceNow에 대한 자격 증명 만들기

앞서 언급했듯이 저장소의 구성에는 ServiceNow에 연결하기 위한 자격 증명이 포함되어 있지 않으며 통신할 ServiceNow 인스턴스를 지정하지 않습니다. 따라서 이 데이터를 설정하기 위해 Ansible Tower에서 자격 증명을 생성합니다. 에 따르면 ServiceNow 인벤토리 플러그인 설명서, 예를 들어 다음과 같이 연결 매개변수를 설정하는 데 사용할 여러 환경 변수가 있습니다.

= username
    	The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE

    	set_via:
      	env:
      	- name: SN_USERNAME

이 경우 SN_USERNAME 환경 변수가 설정되면 인벤토리 플러그인은 이를 ServiceNow에 연결하기 위한 계정으로 사용합니다.

또한 SN_INSTANCE 및 SN_PASSWORD 변수를 설정해야 합니다.

그러나 Ansible Tower에는 ServiceNow에 대해 이 데이터를 지정할 수 있는 이러한 유형의 자격 증명이 없습니다. 하지만 Ansible Tower를 사용하면 다음을 정의할 수 있습니다. 사용자 정의 자격 증명 유형, 기사에서 이에 대한 자세한 내용을 읽을 수 있습니다 "Ansible Tower 기능 스포트라이트: 사용자 정의 자격 증명".

우리의 경우 ServiceNow에 대한 사용자 지정 자격 증명의 입력 구성은 다음과 같습니다.

fields:
  - id: SN_USERNAME
	type: string
	label: Username
  - id: SN_PASSWORD
	type: string
	label: Password
	secret: true
  - id: SN_INSTANCE
	type: string
	label: Snow Instance
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

이러한 자격 증명은 동일한 이름을 가진 환경 변수로 노출됩니다. 이는 인젝터 구성에 설명되어 있습니다.

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

따라서 필요한 자격 증명 유형을 정의했습니다. 이제 ServiceNow 계정을 추가하고 다음과 같이 인스턴스, 사용자 이름 및 비밀번호를 설정할 수 있습니다.

우리는 인벤토리를 생성합니다

이제 Ansible Tower에서 인벤토리를 생성할 준비가 모두 완료되었습니다. ServiceNow라고 부르겠습니다.

인벤토리를 생성한 후 여기에 데이터 소스를 연결할 수 있습니다. 여기서는 이전에 생성한 프로젝트를 지정하고 소스 제어 저장소에 있는 YAML 인벤토리 파일의 경로를 입력합니다. 이 경우 프로젝트 루트의 servicenow.yml입니다. 또한 ServiceNow 계정을 연결해야 합니다.

모든 것이 어떻게 작동하는지 확인하려면 "모두 동기화" 버튼을 클릭하여 데이터 소스와 동기화해 보겠습니다. 모든 것이 올바르게 구성되면 노드를 인벤토리로 가져와야 합니다.

필요한 그룹도 생성되었습니다.

결론

이번 포스팅에서는 ServiceNow 플러그인을 예로 들어 Ansible Tower 컬렉션의 인벤토리 플러그인을 사용하는 방법을 살펴보았습니다. 또한 ServiceNow 인스턴스에 연결하기 위한 자격 증명을 안전하게 등록했습니다. 프로젝트의 인벤토리 플러그인 연결은 타사 또는 사용자 정의 플러그인과 함께 작동할 뿐만 아니라 일부 표준 인벤토리의 작동을 수정하는 데에도 사용할 수 있습니다. 이를 통해 점점 복잡해지는 IT 환경을 자동화할 때 Ansible Automation Platform을 기존 도구와 쉽고 원활하게 통합할 수 있습니다.

이 게시물에서 논의된 주제와 Ansible 사용의 다른 측면에 대한 자세한 정보는 다음에서 확인할 수 있습니다.

• 블로그 작성자: Ansible을 사용하여 ServiceNow 자동화.
• 나만의 컬렉션을 만드는 방법.
• Automation Hub 웹사이트의 Red Hat 지원 컬렉션 목록(cloud.redhat.com).
• Ansible 자동화 플랫폼 eBook.

*Red Hat은 여기에 포함된 코드가 정확하다는 점을 보장하지 않습니다. 달리 명시되지 않는 한 모든 자료는 비보증 기반으로 제공됩니다.

출처 : habr.com