Ansible 모듈을 juniper.device.config 사용하여 Junos OS 구성 검색 또는 비교
Ansible 모듈을 사용하여 juniper.device.config Junos OS를 실행하는 디바이스와 Junos OS Evolved를 실행하는 디바이스의 구성을 검색하거나 비교할 수 있습니다.
주니퍼 네트웍스는 Junos OS를 실행하는 디바이스와 Junos OS Evolved를 실행하는 디바이스의 구성을 관리할 수 있는 Ansible 모듈을 제공합니다. 표 1 은 Junos 디바이스 구성을 검색하거나 비교하는 데 사용할 수 있는 사용 가능한 모듈을 간략하게 보여줍니다.
| 컬렉션 |
모듈 세트 |
모듈 이름 |
|---|---|---|
|
|
이 모듈을 juniper.device.config 사용하여 전체 구성을 요청할 수 있습니다. 또한 기본 Junos OS 구성과 디바이스에 추가된 타사 YANG 데이터 모델에 해당하는 구성 데이터에 대해 선택한 구성 부분을 요청할 수도 있습니다.
구성을 검색하려면 매개 변수가 있는 모듈을 juniper.device.config 실행합니다.retrieve 옵션이 로 false설정되지 않는 한 return_output 모듈의 응답에는 및 키에 config config_lines 텍스트 형식의 구성이 포함됩니다. 또한 활성 구성을 이전에 커밋한 구성과 비교할 수도 있습니다.
다음 섹션에서는 모듈을 사용하여 구성을 검색하거나 비교하는 방법에 대해 설명합니다.
구성 데이터에 대한 소스 데이터베이스 지정 방법
모듈을 juniper.device.config 사용하여 구성을 검색할 때 모듈의 인수 목록에 매개 변수를 retrieve 포함해야 합니다. 매개 변수는 retrieve 데이터를 검색할 구성 데이터베이스를 지정합니다. 다음 값으로 설정 retrieve 하여 각 데이터베이스에서 구성 데이터를 반환할 수 있습니다.
-
candidate- 후보 구성에서 데이터를 검색합니다. -
committed- 커밋된 구성에서 데이터를 검색합니다.
커밋된 구성 데이터베이스
다음 플레이북은 인벤토리 그룹의 각 디바이스에 대해 텍스트 형식으로 커밋된 전체 구성을 검색합니다.
---
- name: Get Junos OS configuration
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get committed configuration
juniper.device.config:
retrieve: committed
register: response
- name: Print result
ansible.builtin.debug:
var: response
응시자 구성 데이터베이스
다음 플레이북은 인벤토리 그룹의 각 디바이스에 대한 전체 후보 구성을 텍스트 형식으로 검색합니다.
---
- name: Get Junos OS configuration
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get candidate configuration
juniper.device.config:
retrieve: candidate
register: response
- name: Print result
ansible.builtin.debug:
var: response
반환할 구성 데이터의 범위를 지정하는 방법
전체 Junos OS 구성을 검색하는 것 외에도, 매개 변수를 filter 사용하여 구성의 특정 부분을 검색할 수 있습니다. 매개 변수의 filter 값은 반환할 구성 문을 선택하는 하위 트리 필터를 포함하는 문자열입니다. 하위 트리 필터는 선택 기준과 일치하는 구성 데이터를 반환합니다. 여러 계층을 요청하는 경우, 의 filter 값은 루트(요소로 <configuration> 표시됨)에서 시작하여 표시할 각 요소까지 구성 계층의 모든 수준을 나타내야 합니다.
다음 플레이북은 각 디바이스에 대해 커밋된 구성 데이터베이스의 및 [edit protocols] 계층 수준에서 [edit interfaces] 구성을 검색하고 인쇄합니다.
---
- name: Get Junos OS configuration hierarchies
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get selected configuration hierarchies
juniper.device.config:
retrieve: committed
filter: "<configuration><interfaces/><protocols/></configuration>"
register: response
- name: Print result
ansible.builtin.debug:
var: response
다음 플레이북은 ge-1/0/1 인터페이스에 대한 구성을 검색하고 출력합니다.
---
- name: Get Junos OS configuration hierarchies
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get selected configuration hierarchies
juniper.device.config:
retrieve: committed
filter: "<interfaces><interface>
<name>ge-1/0/1</name></interface></interfaces>"
register: response
- name: Print result
ansible.builtin.debug:
var: response
다음 플레이북은 계층 수준에서 커밋된 구성을 검색하고 인쇄합니다.[edit system services]
---
- name: Get Junos OS configuration hierarchies.
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get selected configuration hierarchies
juniper.device.config:
retrieve: committed
filter: "system/services"
register: response
- name: Print result
ansible.builtin.debug:
var: response
반환할 구성 데이터의 형식을 지정하는 방법
이 모듈을 juniper.device.config 사용하여 구성을 검색할 때, 이 모듈은 구성 데이터를 다른 형식으로 반환할 수 있는 Junos XML 프로토콜 <get-configuration> 작업을 호출합니다. 기본적으로 모듈은 구성 데이터를 서식이 지정된 텍스트로 반환합니다. 텍스트 형식은 줄 바꿈, 탭 및 기타 공백, 중괄호 및 대괄호를 사용하여 문 간의 계층 관계를 나타냅니다.
구성 데이터를 반환할 형식을 지정하려면 모듈의 매개 변수를 format 필요한 형식과 동일하게 설정합니다. 허용 가능한 값은 다음과 같습니다.
-
json—JavaScript 객체 표기법(JSON) -
set—Junos OSset명령 -
text- 서식이 지정된 텍스트(기본값) -
xml—Junos XML 요소
플레이북 출력에서 및 config_lines 키에는 config 요청된 형식의 구성이 포함됩니다. Junos XML 또는 JSON 형식을 요청하는 경우 키에는 config_parsed JSON 형식의 동일한 구성이 포함됩니다.
다음 플레이북은 인벤토리 그룹의 각 디바이스에 대해 커밋된 전체 구성을 XML 형식으로 검색합니다.
---
- name: Get Junos OS configuration.
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get configuration in XML format
juniper.device.config:
retrieve: committed
format: xml
register: response
- name: Print result
ansible.builtin.debug:
var: response
대규모 구성을 처리하는 방법
Junos 디바이스는 RPC 응답을 XML 형식으로 반환합니다. JSON, 세트 또는 텍스트 형식의 데이터를 요청하는 경우에도 NETCONF 서버의 응답은 데이터를 XML 태그로 래핑합니다. 따라서 Ansible 모듈은 XML 파서를 사용하여 RPC 응답을 처리해야 합니다. XML 구문 분석기는 문서 깊이와 단일 텍스트 노드의 크기에 안전 제한을 적용하는 경우가 많습니다. 이러한 제한은 악의적인 공격, 메모리 고갈 및 일반적인 성능 문제를 방지하기 위한 기본 제공 보안 조치입니다.
네트워크 디바이스는 크고 복잡한 구성과 광범위한 명령 및 RPC 출력을 가질 수 있습니다. 기본적으로 XML 파서는 텍스트 노드에 일반적으로 약 10MB의 크기 제한을 적용합니다. 단일 텍스트 노드가 크기 제한을 초과하면 구문 분석기가 오류를 생성합니다. 예를 들면 다음과 같습니다.
TASK [Retrieve the committed configuration] **************************************** [ERROR]: Task failed: Module failed: Resource limit exceeded: Text node too long, try XML_PARSE_HUGE, line 83442, column 21 (<string>, line 83442)
일반적으로 XML 형식의 구성, 명령 또는 RPC 데이터를 요청하는 경우 문서에는 많은 작은 XML 노드가 포함되며 파서는 드문 경우를 제외하고는 이 제한에 직면하지 않습니다. 그러나 JSON, 세트 또는 텍스트 형식으로 동일한 데이터를 요청하는 경우 디바이스는 하나 이상의 XML 태그로 래핑된 데이터를 반환합니다. 예를 들어, 디바이스는 태그 외에도 <rpc-reply> 세트 및 텍스트 구성 데이터를 태그 또는 <configuration-text> 태그로 <configuration-set> 적절하게 래핑합니다. 마찬가지로 디바이스는 명령 출력을 텍스트 형식으로 요소에 <output> 둘러싸고 있습니다. 광범위한 데이터의 경우, 응답으로 인해 구문 분석기의 기본 한계를 초과하는 단일 XML 텍스트 노드가 발생할 수 있습니다.
어떤 형식으로든 큰 구성이나 광범위한 명령 또는 RPC 출력을 요청하면 XML 파서가 RPC 응답을 처리합니다. 따라서 모든 형식에서 node-size limit 오류가 발생할 수 있지만 XML 데이터의 경우는 더 드뭅니다. 이러한 경우 응답을 XML로 반환하는 것이 좋습니다.
다른 형식 중 하나가 필요한 경우 모듈 인수를 포함하여 huge_tree: true 구문 분석기 제한을 재정의할 수 있습니다. 를 사용하면 huge_tree: true최대 텍스트 노드 크기, 최대 속성 크기 및 최대 깊이에 대한 제한을 무시하는 옵션이 활성화 XML_PARSE_HUGE 됩니다. 결과적으로 구문 분석기는 큰 XML 문서, 심층 XML 트리 및 큰 텍스트 노드를 처리할 수 있습니다.
다음 플레이북은 인벤토리 그룹의 디바이스에 대한 형식으로 커밋된 구성을 set 검색합니다. 모듈 인수에는 juniper.device.config huge_tree: true. 이 옵션을 사용하면 특정 응답이 구문 분석기의 기본 노드 크기 제한을 초과하더라도 작업이 성공합니다.
---
- name: Handle large configurations
hosts: junos
connection: local
gather_facts: false
tasks:
- name: Retrieve the committed configuration
juniper.device.config:
retrieve: committed
diff: false
check: false
commit: false
format: set
huge_tree: true
register: response
- name: Print response
ansible.builtin.debug:
var: response
타사 YANG 데이터 모델에 대한 구성 데이터를 검색하는 방법
표준화 또는 사용자 지정 YANG 모듈을 Junos 디바이스에 로드하여 Junos OS에서 기본적으로 지원하지 않지만 변환으로 지원할 수 있는 데이터 모델을 추가할 수 있습니다. 후보 구성에서 해당 모델에 대해 정의된 구문을 사용하여 비네이티브 데이터 모델을 구성합니다. 구성을 커밋하면 데이터 모델의 변환 스크립트가 해당 데이터를 변환하고 해당 Junos OS 구성을 체크아웃 구성의 일시적인 변경으로 커밋합니다.
후보 및 활성 구성에는 해당 모델에 의해 정의된 구문의 비네이티브 YANG 데이터 모델에 대한 구성 데이터가 포함됩니다. 이 juniper.device.config 모듈을 사용하여 표준(IETF, OpenConfig) 및 사용자 정의 YANG 데이터 모델에 대한 구성 데이터를 검색할 수 있을 뿐만 아니라 기본 Junos OS 구성을 검색할 수도 있습니다. 기본적으로 모듈의 응답에는 타사 YANG 데이터 모델에 대한 구성 데이터가 포함되지 않습니다.
Junos OS 구성을 검색하는 것 외에도 비네이티브 YANG 데이터 모델로 정의된 구성 데이터를 검색하려면 매개 변수가 model 있는 모듈을 실행하고 적절한 경우 매개 변수를 namespace 포함합니다. model 인수는 다음 값 중 하나를 사용합니다.
-
custom- 사용자 정의 YANG 데이터 모델에 의해 정의된 구성 데이터를 검색합니다. 사용자 지정 YANG 데이터 모델에 대한 데이터를 검색할 때 인수를 포함namespace해야 합니다. -
ietf- IETF YANG 데이터 모델에 의해 정의된 구성 데이터를 검색합니다. -
openconfig- OpenConfig YANG 데이터 모델에 의해 정의된 구성 데이터를 검색합니다. -
True- 전체 Junos OS 구성 및 모든 YANG 데이터 모델의 데이터를 포함하여 모든 구성 데이터를 검색합니다.
인수가 또는 openconfig를 지정 ietf 하는 경우 model 모듈은 자동으로 적절한 네임스페이스를 사용합니다. 사용자 지정 YANG 데이터 모델에 대한 데이터를 검색하도록 지정 model: custom 하는 경우 해당 네임스페이스와 함께 인수도 포함 namespace 해야 합니다.
model 인수를 custom값 , ietf또는 openconfig 포함시키고 특정 XML 서브트리를 반환하는 인수도 포함 filter 하면 Junos OS는 비네이티브 데이터 모델에서 일치하는 계층만 반환합니다. Junos OS 구성에 동일한 이름의 계층(예: "interfaces")이 포함된 경우 응답에 포함되지 않습니다. 을 사용할 model: True때는 이 filter 옵션이 지원되지 않습니다.
모듈을 juniper.device.config 사용하여 네이티브가 아닌 구성 데이터를 검색할 때 매개 변수도 포함하는 경우에만 반환된 데이터의 형식을 지정할 수 있습니다.filter 매개 변수format: xml를 filter 생략하면 .
다음 플레이북은 커밋된 구성에서 OpenConfig interfaces 구성 계층을 검색합니다. 인수를 생 filter 략하면 RPC는 전체 Junos OS 및 OpenConfig 구성을 반환합니다.
---
- name: Retrieve OpenConfig configuration
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Retrieve the OpenConfig interfaces configuration
juniper.device.config:
retrieve: committed
model: openconfig
filter: interfaces
format: xml
register: response
- name: Print result
ansible.builtin.debug:
var: response
다음 작업은 주어진 네임스페이스를 가진 사용자 지정 YANG 데이터 모델에 대해 커밋된 구성에서 구성 계층을 검색 l2vpn 합니다.
tasks:
- name: Retrieve custom configuration
juniper.device.config:
retrieve: committed
model: custom
filter: l2vpn
remove_ns: False
namespace: http://yang.juniper.net/customyang/l2vpn
format: xml
register: response
다음 작업은 디바이스에 추가된 다른 YANG 데이터 모델에 대한 구성 데이터뿐만 아니라 전체 Junos OS 커밋 구성을 검색합니다.
tasks:
- name: Retrieve Junos OS and all third-party configuration data
juniper.device.config:
retrieve: committed
model: True
format: xml
register: response
동등한 모듈 인수가 없는 옵션을 지정하는 방법
모듈을 juniper.device.config 사용하여 구성을 검색할 때 모듈은 Junos XML 프로토콜 <get-configuration> 작업을 호출합니다. 이 모듈은 많은 <get-configuration> 속성(예: 속성)에 대한 명시적 인수를 지원합니다. format 또한 이 모듈은 인수를 지원 options 하므로 동일한 모듈 인수가 없는 추가 <get-configuration> 속성을 포함할 수 있습니다. options 인수는 연산에서 <get-configuration> 지원하는 모든 속성의 키/값 쌍 사전을 사용합니다.
Junos XML 프로토콜 <get-configuration> 작업에서 지원하는 전체 속성 목록은 <get-configuration>을 참조하십시오.
예를 들어, juniper.device.config 이 모듈은 상속 전 구성에서 데이터를 검색하며, <groups>여기서 , <apply-groups>, <apply-groups-except>, 및 <interface-range> 태그는 구성 출력에서 별도의 요소입니다. 상속 후 구성에서 데이터를 검색하려면 인수를 포함할 수 있습니다 options . inherit: inherit 상속 후 구성은 사용자 정의 그룹에서 상속된 문과 상속 문의 자식으로 범위를 표시합니다.
다음 플레이북은 상속 후 커밋된 구성에서 계층 수준의 구성 데이터를 [edit system services] 검색합니다. 상속 후 구성에서 다음과 [edit groups global system services] 같은 그룹 계층 수준에서 구성된 문은 검색된 구성 데이터에 상 [edit system services] 속되고 반환됩니다.
---
- name: Get Junos OS configuration hierarchies
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get selected hierarchy from the post-inheritance configuration
juniper.device.config:
retrieve: committed
filter: system/services
options:
inherit: inherit
register: response
- name: Print result
ansible.builtin.debug:
var: response
구성 데이터를 파일에 저장하는 방법
모듈을 juniper.device.config 사용하여 구성을 검색할 때 반환된 구성 데이터를 로컬 Ansible 제어 노드의 파일에 저장할 수 있습니다. 데이터를 파일에 저장하려면 모듈 dest_dir 또는 dest 매개 변수를 포함합니다. dest_dir 이 옵션은 디렉터리 경로를 지정합니다. dest 이 옵션은 경로와 파일 이름을 모두 지정할 수 있습니다. 대상 이름의 출력 파일이 이미 있는 경우 모듈은 파일을 덮어씁니다.
검색된 구성을 저장할 디렉터리를 지정하려면 인수를 대상 디렉터리의 경로로 설정합니다dest_dir. 각 디바이스의 구성은 .config라는hostname 별도의 파일에 저장됩니다.
다음 플레이북은 인벤토리 그룹의 모든 디바이스에서 커밋된 구성을 검색합니다. 플레이북은 각 디바이스 구성을 Ansible 제어 노드의 플레이북 디렉터리 아래의 configs 디렉터리에 있는 별도의 파일에 저장합니다.
---
- name: Get Junos OS configuration
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Save configuration to a file
juniper.device.config:
retrieve: committed
dest_dir: "{{ playbook_dir }}/configs"
출력 파일의 경로와 파일 이름을 지정하려면 인수를 dest 파일의 절대 경로 또는 상대 경로로 설정합니다. 인수를 포함 dest 하지만 디렉터리를 생략하면 파일이 플레이북 디렉터리에 저장됩니다. 여러 디바이스에 대한 구성을 검색하는 경우 인수에는 dest 각 디바이스의 파일 이름을 구별하는 것과 같은 {{ inventory_hostname }} 변수가 포함되어야 합니다. 파일 이름을 구별하지 않으면 각 디바이스의 구성 파일이 다른 디바이스의 구성 파일을 덮어씁니다.
다음 플레이북은 [edit system services] 인벤토리 그룹의 모든 디바이스에 커밋된 구성 데이터베이스에서 계층을 검색합니다. 플레이북은 각 디바이스 구성을 Ansible 제어 노드의 플레이북 디렉터리에 있는 별도의 파일에 저장합니다. 각 파일은 호스트 이름으로 고유하게 식별됩니다.
---
- name: Get Junos OS configuration
hosts: junos
connection: local
gather_facts: no
tasks:
- name: Get selected configuration hierarchies and save to file
juniper.device.config:
retrieve: committed
filter: "system/services"
dest: "{{ inventory_hostname }}-system-services-config"
구성 데이터를 파일에 저장하고 모듈의 응답에서 구성 데이터를 복제하지 않으려면 선택적으로 모듈의 인수 목록에 포함 return_output: false 할 수 있습니다. 로 false 설정하면 return_output 모듈이 응답에서 , config_lines, config_parsed 및 키를 생략config합니다. 디바이스가 상당한 양의 구성 데이터를 반환하는 경우 이 작업이 필요할 수 있습니다.
활성 구성을 이전 구성과 비교하는 방법
juniper.device.config 이 모듈을 사용하면 활성 구성을 이전에 커밋된 구성 또는 롤백 구성과 비교할 수 있습니다. 활성 구성을 이전 구성과 비교하려면 다음 모듈 인수를 포함합니다.
juniper.device.config: diff: true rollback: id check: false commit: false
기본적으로 인수를 포함 rollback: id 하면 모듈이 구성을 롤백하고 커밋 검사를 수행한 후 변경 사항을 커밋합니다. 구성을 비교하고 모듈이 롤백 구성을 로드하고 커밋하지 못하도록 인수를 포함 commit: false 해야 합니다. 인수를 포함하면 check: false 불필요한 커밋 검사 작업을 방지할 수 있습니다.
이 모듈은 및 diff diff_lines 키를 반환합니다. 키에는 활성 구성과 이전 구성 간의 구성 차이가 diff 또는 patch 형식으로 포함되어 있습니다.
-
diff- 이름의 단일prepared키와 해당 값(차이점을 포함하는 여러 줄 문자열)을 포함하는 사전입니다. -
diff_lines- 차이점을 포함하는 한 줄 문자열의 목록입니다.
로컬 Ansible 제어 노드의 파일에 차이점을 저장하려면 인수를 포함 diffs_file 하고 출력 파일의 절대 또는 상대 경로를 정의합니다. 인수를 포함 diffs_file 하지만 디렉터리를 생략하면 파일이 플레이북 디렉터리에 저장됩니다. 여러 디바이스의 구성을 비교하는 경우, 인수에는 diffs_file 각 디바이스의 파일 이름을 구별하는 것과 같은 {{ inventory_hostname }} 변수가 포함되어야 합니다. 파일명을 구분하지 않으면 각 디바이스의 출력 파일이 다른 디바이스의 출력 파일을 덮어씁니다.
다음 플레이북에서는 이전에 커밋된 구성의 롤백 ID를 묻는 메시지를 표시합니다. 그런 다음 플레이북은 커밋된 구성을 지정된 롤백 구성과 비교하고, 비교 결과를 고유한 이름의 파일에 저장하고, 응답을 표준 출력에 출력합니다.
---
- name: Compare configurations
hosts: dc1
connection: local
gather_facts: no
vars_prompt:
- name: ROLLBACK
prompt: "Rollback ID to compare with active configuration"
private: no
tasks:
- name: Compare active to previous configuration
juniper.device.config:
diff: true
rollback: "{{ ROLLBACK }}"
check: false
commit: false
diffs_file: "{{ inventory_hostname }}-diff-rollback-{{ ROLLBACK }}"
register: response
- name: Print diff
ansible.builtin.debug:
var: response
user@ansible-cn:~$ ansible-playbook configuration-compare-to-rollback.yaml
Rollback ID to compare with active configuration: 2
PLAY [Compare configurations] *************************************************
TASK [Compare active to previous configuration] ******************************
changed: [dc1a.example.net]
TASK [Print diff] ************************************************************
ok: [dc1a.example.net] => {
"response": {
"changed": true,
"diff": {
"prepared": "\n[edit system services]\n- netconf {\n- ssh;\n- }\n"
},
"diff_lines": [
"",
"[edit system services]",
"- netconf {",
"- ssh;",
"- }"
],
"failed": false,
"msg": "Configuration has been: opened, rolled back, diffed, closed."
}
}
PLAY RECAP ********************************************************************
dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
user@ansible-cn:~$ cat dc1a.example.net-diff-rollback-2
[edit system services]
- netconf {
- ssh;
- }