내부 플레이북. 새로운 Ansible Engine 2.9의 네트워킹 기능

Red Hat Ansible Engine 2.9의 향후 릴리스에서는 흥미로운 개선 사항을 제공하며 그 중 일부는 이 문서에서 설명합니다. 언제나 그렇듯이 우리는 커뮤니티 지원을 통해 공개적으로 Ansible Network 개선 사항을 개발해 왔습니다. 우리와 함께하세요 – 살펴보세요 GitHub의 이슈 보드 개발 계획을 연구하고 Red Hat Ansible Engine 2.9 출시 위키 페이지에서 앤서블 네트워크.

최근에 발표한 바와 같이, Red Hat Ansible 자동화 플랫폼 이제 Ansible Tower, Ansible Engine 및 모든 Ansible Network 콘텐츠가 포함됩니다. 요즘 가장 널리 사용되는 네트워킹 플랫폼은 Ansible 모듈을 통해 구현됩니다. 예를 들어:

• 아리 스타 EOS
• 시스코 IOS
• 시스코 IOS XR
• 시스코 NX-OS
• 주니퍼 주노스
• 비오스

Ansible Automation 서브스크립션을 통해 Red Hat에서 완전히 지원하는 플랫폼의 전체 목록을 보려면 다음을 참조하세요. 여기에 게시.

우리는 무엇을 배웠나요?

지난 XNUMX년 동안 우리는 네트워크 자동화 플랫폼 개발에 대해 많은 것을 배웠습니다. 우리는 또한 그것을 배웠습니다 как 플랫폼 아티팩트는 최종 사용자의 Ansible 플레이북 및 역할에 사용됩니다. 그리고 우리가 알아낸 내용은 다음과 같습니다.

• 조직은 하나가 아닌 여러 공급업체의 장치를 자동화하고 있습니다.
• 자동화는 기술적 현상일 뿐만 아니라 문화적 현상이기도 합니다.
• 대규모 네트워크를 자동화하는 것은 자동화 설계의 기본 아키텍처 원칙으로 인해 생각보다 어렵습니다.

XNUMX년 전 우리가 장기적인 성장 계획을 논의했을 때 기업 고객들은 다음과 같은 사항을 요청했습니다.

• 사실 수집은 더 표준화되어야 하며 모든 장치의 자동화 워크플로에 맞춰 조정되어야 합니다.
• Ansible 모듈이 사실을 수집한 후 주기의 후반부를 처리할 수 있도록 장치의 구성 업데이트도 표준화되고 일관성이 있어야 합니다.
• 장치 구성을 구조화된 데이터로 변환하려면 엄격하고 지원되는 방법이 필요합니다. 이를 바탕으로 정보의 출처를 네트워크 장치에서 이동할 수 있습니다.

사실 개선

Ansible을 사용하여 네트워크 장치에서 정보를 수집하는 일은 종종 무작위로 발생합니다. 웹 기반 플랫폼은 다양한 수준의 사실 수집 기능을 갖추고 있지만 키-값 쌍의 데이터 표현을 구문 분석하고 표준화하는 기능은 거의 또는 전혀 없습니다. 읽다 게시 Ken Celenza가 사실 데이터를 분석하고 표준화하는 것이 얼마나 어렵고 고통스러울 수 있는지 설명합니다.

우리가 Ansible 네트워크 엔진 역할을 담당하고 있다는 사실을 눈치채셨을 것입니다. 당연히 24K 다운로드 이후 네트워크 엔진 역할은 네트워크 자동화 시나리오를 위해 Ansible Galaxy에서 가장 인기 있는 Ansible 역할 중 하나로 빠르게 자리 잡았습니다. Ansible 2.8에 필요한 사항을 준비하기 위해 이 중 많은 부분을 Ansible 2.9로 이동하기 전에 이 Ansible 역할은 명령을 구문 분석하고, 명령을 관리하고, 네트워크 장치에 대한 데이터를 수집하는 데 도움이 되는 첫 번째 도구 세트를 제공했습니다.

네트워크 엔진을 사용하는 방법을 알고 있다면 이는 Ansible에서 사용할 팩트 데이터를 수집, 구문 분석 및 표준화하는 매우 효율적인 방법입니다. 이 역할의 단점은 각 플랫폼과 모든 네트워크 활동에 대해 전체 파서를 생성해야 한다는 것입니다. 파서를 생성, 제공 및 유지 관리하는 것이 얼마나 어려운지 이해하려면 다음을 살펴보십시오. 1200개 이상의 파서 Cisco 직원들로부터.

간단히 말해서, 대규모 자동화를 위해서는 장치에서 정보를 얻고 이를 키-값 쌍으로 정규화하는 것이 필수적이지만, 공급업체와 네트워크 플랫폼이 많으면 이를 달성하기가 어렵습니다.

Ansible 2.9의 각 네트워크 팩트 모듈은 이제 추가 라이브러리, Ansible 역할 또는 사용자 정의 파서 없이도 네트워크 장치의 구성을 분석하고 구조화된 데이터를 반환할 수 있습니다.

Ansible 2.9부터는 업데이트된 네트워크 모듈이 출시될 때마다 팩트 모듈이 개선되어 구성의 이 섹션에 대한 데이터를 제공합니다. 즉, 사실과 모듈의 개발은 이제 동일한 속도로 이루어지며 항상 공통된 데이터 구조를 갖게 됩니다.

네트워크 장치의 리소스 구성은 두 가지 방법으로 검색하여 구조화된 데이터로 변환할 수 있습니다. 두 가지 방법 모두에서 새 키워드를 사용하여 특정 리소스 목록을 수집하고 변환할 수 있습니다. gather_network_resources. 리소스 이름이 모듈 이름과 일치하므로 매우 편리합니다.

사실을 수집하는 동안:

키워드 사용 gather_facts 플레이북 시작 부분에서 현재 장치 구성을 검색한 다음 전체 플레이북에서 사용할 수 있습니다. 장치에서 검색할 개별 리소스를 지정합니다.

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

이 예에서 새로운 점을 발견했을 수 있습니다. 즉, gather_facts: true 이제 네트워크 장치에 대한 기본 정보 수집에 사용할 수 있습니다.

네트워크 팩트 모듈을 직접 사용:

- name: collect interface configuration facts
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

플레이북은 인터페이스에 대해 다음 사실을 반환합니다.

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: true
        name: Ethernet1
        mtu: '1476'
      - enabled: true
        name: Loopback0
      - enabled: true
        name: Loopback1
      - enabled: true
        mtu: '1476'
        name: Tunnel0
      - enabled: true
        name: Ethernet1
      - enabled: true
        name: Tunnel1
      - enabled: true
        name: Ethernet1

Ansible이 Arista 장치에서 기본 구성을 검색하고 이를 구조화된 데이터로 변환하여 다운스트림 작업 및 운영을 위한 표준 키-값 쌍으로 사용하는 방법을 확인하십시오.

인터페이스 사실을 Ansible 저장 변수에 추가하고 즉시 또는 나중에 리소스 모듈에 대한 입력으로 사용할 수 있습니다. eos_interfaces 추가 처리나 변환 없이.

리소스 모듈

그래서 우리는 사실을 추출하고, 데이터를 정규화하고, 이를 표준화된 내부 데이터 구조 다이어그램에 맞추고 기성 진실 소스를 받았습니다. 만세! 물론 이것은 훌륭하지만 여전히 키-값 쌍을 특정 장치 플랫폼이 기대하는 특정 구성으로 다시 변환해야 합니다. 이제 이러한 새로운 사실 ​​수집 및 정규화 요구 사항을 충족하려면 플랫폼별 모듈이 필요합니다.

리소스 모듈이란 무엇입니까? 장치의 구성 섹션을 해당 장치에서 제공하는 리소스로 생각할 수 있습니다. 네트워크 리소스 모듈은 의도적으로 단일 리소스로 제한되며 복잡한 네트워크 서비스를 구성하기 위해 빌딩 블록처럼 쌓일 수 있습니다. 결과적으로 리소스 모듈에 대한 요구 사항과 사양은 자연스럽게 단순화됩니다. и 네트워크 장치에서 특정 네트워크 서비스를 구성합니다.

리소스 모듈의 기능을 설명하기 위해 새로운 네트워크 리소스 사실과 모듈을 사용하여 멱등성 작업을 보여주는 예제 플레이북을 살펴보겠습니다. eos_l3_interface.

- name: example of facts being pushed right back to device.
  hosts: arista
  gather_facts: false
  tasks:
  - name: grab arista eos facts
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: ensure that the IP address information is accurate
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: ensure config did not change
    assert:
      that: not result.changed

보시다시피, 장치에서 수집된 데이터는 변환 없이 해당 리소스 모듈로 직접 전송됩니다. 실행되면 플레이북은 장치에서 값을 검색하여 예상 값과 비교합니다. 이 예에서 반환된 값은 예상한 대로(즉, 구성 편차를 확인) 구성이 변경되었는지 보고합니다.

구성 드리프트를 감지하는 이상적인 방법은 Ansible 저장 변수에 사실을 저장하고 검사 모드에서 리소스 모듈과 함께 주기적으로 사용하는 것입니다. 이는 누군가가 수동으로 값을 변경했는지 확인하는 간단한 방법입니다. 대부분의 경우 조직에서는 수동으로 변경 및 구성을 허용하지만 많은 작업은 Ansible Automation을 통해 수행됩니다.

새로운 리소스 모듈은 이전 리소스 모듈과 어떻게 다릅니까?

네트워크 자동화 엔지니어의 경우 Ansible 3와 이전 버전의 리소스 모듈 간에는 2.9가지 주요 차이점이 있습니다.

1) 특정 네트워크 리소스(구성 섹션으로도 간주될 수 있음)에 대해 모듈과 사실은 지원되는 모든 네트워크 운영 체제에서 동시에 발전합니다. Ansible이 하나의 네트워크 플랫폼에서 리소스 구성을 지원한다면 모든 곳에서 이를 지원해야 한다고 생각합니다. 이제 네트워크 자동화 엔지니어가 기본 및 지원 모듈을 사용하여 모든 네트워크 운영 체제에서 리소스(예: LLDP)를 구성할 수 있으므로 리소스 모듈 사용이 단순화됩니다.

2) 이제 리소스 모듈에 상태 값이 포함됩니다.

• merged: 구성이 제공된 구성과 병합됩니다(기본값).
• replaced: 리소스 구성이 제공된 구성으로 대체됩니다.
• overridden: 리소스 구성이 제공된 구성으로 대체됩니다. 불필요한 리소스 인스턴스는 삭제됩니다.
• deleted: 리소스 구성이 삭제/기본값으로 복원됩니다.

3) 이제 리소스 모듈에 안정적인 반환 값이 포함됩니다. 네트워크 리소스 모듈이 네트워크 장치에 필요한 변경을 수행(또는 제안)하면 동일한 키-값 쌍을 플레이북에 반환합니다.

• before: 작업 전에 구조화된 데이터 형태로 장치에 대한 구성입니다.
• after: 장치가 변경된 경우(또는 테스트 모드를 사용하는 경우 변경될 수 있는 경우) 결과 구성이 구조화된 데이터로 반환됩니다.
• commands: 모든 구성 명령은 장치에서 실행되어 장치를 원하는 상태로 만듭니다.

이 모든 것이 무엇을 의미합니까? 왜 중요 함?

이 게시물에서는 복잡한 개념을 많이 다루지만 결국 기업 고객이 실제로 자동화 플랫폼을 위한 수집, 데이터 정규화 및 루프 구성을 요구하는 것이 무엇인지 더 잘 이해할 수 있기를 바랍니다. 그런데 왜 이러한 개선이 필요한가요? 이제 많은 조직이 IT 환경을 더욱 민첩하고 경쟁력 있게 만들기 위해 디지털 혁신을 추구하고 있습니다. 좋든 나쁘든, 많은 네트워크 엔지니어는 이기심이나 경영진의 요청으로 네트워크 개발자가 됩니다.

조직은 개별 네트워크 템플릿을 자동화해도 사일로 문제가 해결되지 않고 어느 정도 효율성만 향상된다는 점을 깨닫고 있습니다. Red Hat Ansible Automation Platform은 네트워크 장치의 기본 데이터를 프로그래밍 방식으로 관리하기 위한 엄격하고 규범적인 리소스 데이터 모델을 제공합니다. 즉, 사용자는 특정 공급업체 구현보다는 기술(예: IP 주소, VLAN, LLDP 등)에 중점을 둔 보다 현대적인 방법을 선호하여 개별 구성 방법을 점차적으로 포기하고 있습니다.

이는 신뢰할 수 있고 입증된 명령 모듈과 구성의 시대가 얼마 남지 않았음을 의미합니까? 어떠한 경우에도. 예상되는 네트워크 리소스 모듈은 모든 경우 또는 모든 공급업체에 적용할 수 없으므로 특정 구현을 위해 네트워크 엔지니어는 여전히 명령 및 구성 모듈을 필요로 합니다. 리소스 모듈의 목적은 대규모 Jinja 템플릿을 단순화하고 구조화되지 않은 장치 구성을 구조화된 JSON 형식으로 정규화하는 것입니다. 리소스 모듈을 사용하면 기존 네트워크가 읽기 쉬운 정보 소스를 나타내는 구조화된 키-값 쌍으로 구성을 변환하는 것이 더 쉬워집니다. 구조화된 키-값 쌍을 사용하면 각 장치에서 구성을 실행하는 것에서 독립적인 구조화된 데이터로 작업하는 것으로 전환하고 네트워크를 코드형 인프라 접근 방식의 최전선으로 가져올 수 있습니다.

Ansible Engine 2.9에는 어떤 리소스 모듈이 제공되나요?

Ansible 2.9에서 어떤 일이 일어날지 자세히 설명하기 전에 전체 작업 범위를 어떻게 나누었는지 기억해 보겠습니다.

우리는 7가지 범주를 식별하고 각 범주에 특정 네트워크 리소스를 할당했습니다.

참고: 굵게 표시된 리소스는 Ansible 2.9에서 계획 및 구현되었습니다.
기업 고객과 커뮤니티의 피드백을 기반으로 네트워크 토폴로지 프로토콜, 가상화 및 인터페이스와 관련된 모듈을 먼저 다루는 것이 논리적이었습니다.
다음 리소스 모듈은 Ansible Network 팀에서 개발했으며 Red Hat에서 지원하는 플랫폼에 해당합니다.

다음 모듈은 Ansible 커뮤니티에서 개발되었습니다.

• exos_lldp_global - 익스트림 네트웍스에서.
• nxos_bfd_interfaces - 시스코에서
• nxos_telemetry - 시스코에서

보시다시피 리소스 모듈의 개념은 플랫폼 중심 전략에 적합합니다. 즉, 네트워크 모듈 개발의 표준화를 지원하고 Ansible 역할 및 플레이북 수준에서 사용자 작업을 단순화하기 위해 필요한 기능을 Ansible 자체에 포함합니다. 리소스 모듈 개발을 확장하기 위해 Ansible 팀은 Module Builder 도구를 출시했습니다.

Ansible 2.10 이상에 대한 계획

Ansible 2.9가 출시되면 우리는 네트워크 토폴로지 및 정책을 추가로 구성하는 데 사용할 수 있는 Ansible 2.10의 다음 리소스 모듈 세트에 대해 작업할 것입니다. ACL, OSPF 및 BGP. 아직 개발 계획은 조정될 수 있으니 의견이 있으시면 제보 부탁드립니다. Ansible 네트워크 커뮤니티.

리소스 및 시작하기

Ansible 자동화 플랫폼에 대한 보도 자료
Ansible 자동화 플랫폼 블로그
Ansible 콘텐츠 전달의 미래
Ansible 프로젝트 구조 변경에 대한 고찰

출처 : habr.com