Ansible 플레이북에서 Junos Snapshot Administrator in Python(JSNAPy) 사용
Ansible 플레이북의 일부로 JSNAPy 테스트를 실행하여 Junos 디바이스의 런타임 환경 스냅샷을 캡처하고 감사합니다.
® JSNAPy(Junos Snapshot Administrator in Python)를 사용하면 Junos 디바이스의 런타임 환경 스냅샷을 캡처하고 감사할 수 있습니다. 디바이스의 구성 및 작동 상태를 캡처 및 확인하고 디바이스에 대한 변경 사항을 확인할 수 있습니다. 주니퍼 네트웍스는 Ansible 플레이북의 일부로 Junos 디바이스에 대한 JSNAPy 테스트를 실행하는 데 사용할 수 있는 Ansible 모듈을 제공합니다. 표 1 에는 사용 가능한 모듈이 요약되어 있습니다.
| 콘텐츠 세트 |
모듈 이름 |
|---|---|
모듈을 사용하려면 Ansible 제어 노드에 Python으로 Junos Snapshot Administrator를 juniper.device.jsnapy 설치해야 합니다. 설치 지침과 JSNAPy 구성 및 테스트 파일 생성에 대한 자세한 내용은 Python 설명서의 Junos 스냅샷 관리자를 참조하십시오.
다음 섹션에서는 Ansible 플레이북에서 juniper.device.jsnapy 모듈을 사용하는 방법에 대해 설명합니다.
모듈 개요
이 juniper.device.jsnapy 모듈을 사용하면 Ansible 플레이북 내에서 다음과 같은 JSNAPy 기능을 실행할 수 있습니다.
-
Runtime Environment 스냅샷 캡처 및 저장
-
두 스냅샷 비교
-
스냅샷 캡처 및 즉시 평가
모듈에서는 인수와 action config_file 또는 인수를 test_files 지정해야 합니다. 인수는 action 수행할 JSNAPy 작업을 지정합니다. 표 2 에는 유효한 action 값과 이에 상응하는 JSNAPy 명령이 요약되어 있습니다.
| action 값 |
묘사 |
동등한 JSNAPy 명령 |
|---|---|---|
|
|
주어진 테스트 케이스를 기반으로 두 개의 기존 스냅샷을 비교하거나, 테스트 케이스가 제공되지 않은 경우 스냅샷을 노드별로 비교합니다. |
|
|
|
주어진 장치를 변경한 후 테스트 파일에 지정된 명령 또는 RPC에 대한 스냅샷을 찍습니다. |
|
|
|
주어진 디바이스를 변경하기 전에 테스트 파일에 지정된 명령 또는 RPC에 대한 스냅샷을 찍습니다. |
|
|
|
테스트 파일에 지정된 명령 또는 RPC의 스냅샷을 생성하고 테스트 케이스의 사전 정의된 기준에 대해 스냅샷을 즉시 평가합니다. |
|
명령줄에서 JSNAPy를 실행하면 JSNAPy는 구성 파일의 hosts 섹션에 지정된 호스트에서 요청된 작업을 수행합니다. 반대로 Ansible 모듈은 Ansible 플레이북에 지정된 호스트에서 요청된 작업을 실행합니다. 결과적으로 모듈은 섹션을 무시하고 hosts 구성 파일을 참조하거나 하나 이상의 테스트 파일을 직접 참조할 수 있습니다.
따라서 인수 외에도 action 모듈에는 juniper.device.jsnapy 주어진 작업에 사용할 JSNAPy 구성 파일 또는 JSNAPy 테스트 파일을 지정하기 위한 인수 또는 test_files 인수가 필요합니다config_file. 표 3에는 및 test_files 인수가 config_file 요약되어 있습니다.
| 모듈 인수 |
값 |
추가 정보 |
|---|---|---|
|
|
JSNAPy 구성 파일에 대한 절대 또는 상대 파일 경로입니다. |
경로가 상대적인 경우 모듈은 다음 위치에서 표시된 순서대로 구성 파일을 확인합니다.
구성 파일이 상대 파일 경로를 사용하여 테스트 파일을 참조하는 경우 모듈은 먼저 플레이북 디렉터리에서 테스트 파일을 확인한 다음 기본 |
|
|
JSNAPy 테스트 파일에 대한 절대 또는 상대 파일 경로입니다. 단일 파일 경로 또는 파일 경로 목록일 수 있습니다. |
상대 경로를 지정하는 각 테스트 파일에 대해 모듈은 다음 위치에서 표시된 순서대로 파일을 확인합니다.
|
및 test_files 인수는 config_file 절대 또는 상대 파일 경로를 사용할 수 있습니다. 상대 파일 경로를 사용하는 경우 선택적으로 module 인수를 dir 포함하여 파일이 상주하는 디렉터리를 지정할 수 있습니다. 또는 test_files 인수가 config_file 상대 파일 경로를 사용하는 경우 모듈은 인수가 있더라도 dir 먼저 Ansible 플레이북 디렉터리에서 파일을 확인합니다. 파일이 플레이북 디렉터리에 없는 경우 모듈은 인수 디렉터리(지정된 경우) 또는 /etc/jsnapy/testfiles 디렉터리(인수가 dir 생략된 경우)를 확인합니다dir. 파일을 찾을 수 없는 경우 플레이북에서 오류 메시지를 생성합니다.
매개 변수를 포함할 dir 때 모듈은 지정된 config_file 또는 test_files 인수에 대해서만 해당 위치를 확인한다는 점에 유의해야 합니다. 따라서 구성 파일을 지정할 때 모듈은 구성 파일 내에서 지정한 테스트 파일에 대한 디렉토리를 dir 확인하지 않습니다. 구성 파일이 테스트 파일의 상대 경로를 참조하는 경우 모듈은 플레이북 디렉터리와 기본 testfiles 디렉터리에서만 테스트 파일을 확인합니다.
~/jsnapy/testfiles 디렉터리에 상주하고 여러 JSNAPy 테스트 파일을 참조하는 다음 JSNAPy 구성 파일 jsnapy_config_base_tests.yaml이 있다고 가정합니다.
user@ansible-cn:~/ansible$ cat ~/jsnapy/testfiles/jsnapy_config_base_tests.yaml tests: - system_util_baseline.yaml - verify_ldp_neighbors.yaml - verify_ospf_neighbors.yaml - verify_bgp_neighbors.yaml - test_interface_operstate.yaml
다음 샘플 플레이북은 snap_pre jsnapy_config_base_tests.yaml 구성 파일의 각 테스트 파일에 대한 작업을 수행합니다. 구성 파일이 플레이북 디렉터리에 없는 경우 모듈은 디렉터리에서 dir 파일(이 경우 ~/jsnapy/testfiles)을 확인합니다. 구성 파일은 테스트 파일의 상대 경로를 사용합니다. 결과적으로 모듈은 먼저 플레이북 디렉터리에서 테스트 파일을 확인한 다음 기본 testfiles 디렉터리에서 테스트 파일을 확인합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
또는 모듈에서 jsnapy test_files 매개 변수를 사용하여 사용할 개별 테스트 파일을 지정할 수 있습니다. 다음 플레이북은 이전 플레이북 예제와 동일한 테스트를 실행합니다. 이 경우 모듈은 먼저 플레이북 디렉터리에서 테스트 파일을 확인한 다음, 디렉터리에서 dir 테스트 파일을 확인합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
test_files:
- system_util_baseline.yaml
- verify_ldp_neighbors.yaml
- verify_ospf_neighbors.yaml
- verify_bgp_neighbors.yaml
- test_interface_operstate.yaml
Python 릴리스 1.3.0의 Junos Snapshot Administrator부터 구성 및 테스트 파일의 기본 위치는 ~/jsnapy/testfiles 입니다. 그러나 가상 환경 내부 또는 이전 릴리스의 기본 위치는 /etc/jsnapy/testfiles입니다.
모듈이 섹션을 포함하는 hosts 구성 파일을 참조하는 경우에도 모듈은 Ansible 플레이북에 지정된 호스트에서 요청된 작업을 수행합니다. 오류가 발생하고 JSNAPy 테스트를 실행하지 못하는 경우 모듈이 실패를 보고합니다. 하나 이상의 JSNAPy 테스트가 실패하면 실패를 보고 하지 않습니다 . JSNAPy 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 ansible.builtin.assert 응답에서 예상되는 결과를 확인합니다.
Python의 Junos 스냅샷 관리자는 기본적으로 /var/log/jsnapy/jsnapy.log 파일에 작업에 관한 정보를 기록합니다. 모듈에는 juniper.device.jsnapy 특정 작업에 대한 정보가 기록되는 Ansible 제어 노드의 쓰기 가능한 파일에 대한 경로를 지정하는 인수가 선택적으로 포함될 logfile 수 있습니다. Ansible의 세부 정보 표시 수준 및 디버그 옵션은 파일에 기록되는 정보의 수준을 결정합니다. 기본적으로 심각도 수준 WARNING 이상의 메시지만 기록됩니다. 심각도 수준 INFO 또는 심각도 수준 DEBUG보다 높거나 같은 메시지를 기록하려면 각각 또는 -vv 명령줄 옵션을 사용하여 플레이북을 -v 실행합니다.
Ansible 플레이북에서 JSNAPy 테스트를 실행할 때 실패한 JSNAPy 테스트에 대한 정보를 저장하거나 요약할 수 있습니다. 자세한 내용은 실패한 JSNAPy 테스트 검토를 참조하십시오.
스냅샷 찍기 및 비교
JSNAPy를 사용하면 변경 전후에 Junos 디바이스의 런타임 환경 스냅샷을 캡처한 다음 스냅샷을 비교하여 예상되는 변경 사항을 확인하거나 예기치 않은 문제를 식별할 수 있습니다. 이 juniper.device.jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 JSNAPy 스냅샷을 찍고 비교할 수 있습니다. 모듈은 미리 결정된 파일 이름을 사용하여 기본 JSNAPy 스냅샷 디렉터리의 별도 파일에 각 호스트에 대한 각 스냅샷을 저장합니다. 출력 파일에 대한 자세한 내용은 jsnapy 모듈 출력 이해를 참조하십시오.
변경하기 전에 하나 이상의 디바이스에 대한 기준 스냅샷을 찍으려면 모듈의 인수snap_pre를 action 로 설정하고 구성 파일 또는 하나 이상의 테스트 파일을 지정합니다.
다음 플레이북은 Ansible 인벤토리 그룹의 각 디바이스에 대한 PRE 스냅샷을 저장합니다. 작업은 ~/jsnapy/testfiles 디렉터리의 jsnapy_config_base_tests.yaml 구성 파일을 참조하고 플레이북 디렉터리의 jsnapy_tests.log 파일에 메시지를 기록합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
logfile: "jsnapy_tests.log"
변경을 수행한 후 하나 이상의 디바이스에 대한 스냅샷을 찍으려면 모듈의 인수snap_post를 action 로 설정하고 구성 파일 또는 하나 이상의 테스트 파일을 지정합니다.
다음 플레이북은 Ansible 인벤토리 그룹의 각 디바이스에 대한 POST 스냅샷을 저장합니다. 작업은 ~/jsnapy/testfiles 디렉터리에서 동일한 jsnapy_config_base_tests.yaml 구성 파일을 참조하고 플레이북 디렉터리의 jsnapy_tests.log 파일에 메시지를 기록합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a post-maintenance snapshot
juniper.device.jsnapy:
action: "snap_post"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
logfile: "jsnapy_tests.log"
모듈이 jsnapy 작업 또는 snap_post 작업을 수행할 snap_pre 때 각각 'PRE' 또는 'POST' 태그가 포함된 자동 생성된 파일 이름을 사용하여 각 호스트에 대한 각 스냅샷을 별도의 파일에 저장합니다. 및 POST 스냅샷을 비교 PRE 하여 업데이트를 빠르게 확인하거나 변경으로 인해 발생할 수 있는 문제를 식별하려면 모듈의 인수check를 action 로 설정하고 스냅샷을 만드는 데 사용된 것과 동일한 구성 파일 또는 테스트 파일을 지정합니다.
모듈이 작업을 수행할 check 때 JSNAPy는 각 디바이스의 각 테스트에 대한 PRE 및 POST 스냅샷을 비교하고 테스트 파일의 섹션에 정의된 tests: 기준에 따라 평가합니다. 테스트 파일이 테스트 케이스를 정의하지 않는 경우 JSNAPy는 대신 스냅샷을 노드별로 비교합니다. 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 ansible.builtin.assert 응답에서 예상 결과를 확인합니다.
다음 플레이북은 이전에 실행 snap_pre 된 스냅샷과 snap_post Ansible 인벤토리 그룹의 모든 디바이스에 대한 작업을 비교합니다. 결과는 구성 파일에서 참조되는 테스트 파일의 기준을 사용하여 평가됩니다. 플레이북은 모듈의 응답을 'test_result'로 등록하고 모듈을 사용하여 ansible.builtin.assert 지정된 디바이스에서 모든 테스트를 통과했는지 확인합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Compare PRE and POST snapshots
juniper.device.jsnapy:
action: "check"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
logfile: "jsnapy_tests.log"
register: test_result
- name: Verify JSNAPy tests passed
ansible.builtin.assert:
that:
- "test_result.passPercentage == 100"
플레이북을 실행하면 어설션이 테스트에 실패한 디바이스를 빠르게 식별합니다.
user@host:~$ ansible-playbook jsnapy-baseline-check.yaml
PLAY [Junos Snapshot Administrator tests] *************************************
TASK [Compare PRE and POST snapshots] *****************************************
ok: [dc1a.example.net]
ok: [dc1b.example.net]
TASK [Verify JSNAPy tests passed] *********************************************
ok: [dc1b.example.net] => {
"changed": false,
"msg": "All assertions passed"
}
fatal: [dc1a.example.net]: FAILED! => {
"assertion": "test_result.passPercentage == 100",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
to retry, use: --limit @/home/user/jsnapy-baseline-check.retry
PLAY RECAP ********************************************************************
dc1b.example.net : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
dc1a.example.net : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
Snapcheck 작업 수행
JSNAPy를 사용하면 JSNAPy 테스트 파일에 지정된 명령 또는 RPC에 대한 스냅샷을 생성하고 테스트 사례에 사전 정의된 기준에 따라 스냅샷을 즉시 평가할 수 있습니다. 이 juniper.device.jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 JSNAPy 스냅체크 작업을 수행할 수 있습니다.
스냅샷을 찍고 테스트 파일의 섹션에 미리 정의된 기준 tests: 세트를 기반으로 즉시 평가하려면 모듈의 인수snapcheck를 action 로 설정하고 구성 파일 또는 하나 이상의 테스트 파일을 지정합니다. 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 ansible.builtin.assert 응답에서 예상 결과를 확인합니다.
예를 들어 Ansible 인벤토리 그룹의 각 디바이스에 대해 다음 플레이북은 테스트 파일의 각 명령 또는 RPC에 대한 별도의 스냅샷을 저장하고, 모듈의 응답을 등록하고, 모듈을 사용하여 ansible.builtin.assert 테스트 파일에 정의된 모든 테스트가 해당 디바이스에 전달되었는지 확인합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a snapshot and immediately evaluate it
juniper.device.jsnapy:
action: "snapcheck"
dir: "~/jsnapy/testfiles/"
test_files:
- "test_interface_status.yaml"
- "test_bgp_neighbor.yaml"
logfile: "jsnapy_tests.log"
register: test_result
- name: Verify JSNAPy tests passed
ansible.builtin.assert:
that:
- "test_result.passPercentage == 100"
jsnapy 모듈 출력 이해하기
모듈이 juniper.device.jsnapy , snap_post또는 snapcheck 작업을 수행snap_pre하면 스냅샷이 JSNAPy 스냅샷 디렉터리에 자동으로 저장됩니다. JSNAPy 구성 파일(jsnapy.cfg)을 수정하여 다른 위치를 지정하지 않는 한 모듈은 기본 JSNAPy 디렉터리를 사용합니다. 모듈은 Ansible 인벤토리 그룹의 각 디바이스에서 실행되는 각 명령 또는 RPC에 대해 별도의 파일을 생성합니다. 표 4 에는 인수의 각 값에 대한 스냅샷 파일의 파일 이름이 요약되어 action 있습니다.
Python 릴리스 1.3.0의 Junos 스냅샷 관리자부터 JSNAPy 테스트 파일 및 스냅샷의 기본 디렉터리는 각각 ~/jsnapy/testfiles 및 ~/jsnapy/snapshots입니다. 그러나 가상 환경 내 또는 이전 릴리스의 기본 디렉토리는 /etc/jsnapy/testfiles 및 /etc/jsnapy/snapshots입니다.
|
|
출력 파일 |
|---|---|
|
|
hostname_PRE_hash_command입니다.format |
|
|
hostname_POST_hash_command입니다.format |
| |
hostname_snap_temp_hash_command입니다.format |
어디:
-
hostname- 명령 또는 RPC가 실행되는 디바이스의 호스트 이름.
-
(사전 | 게시물 | snap_temp) - 작업을 식별하는 태그입니다.
snapcheck이 작업은 현재 릴리스에서는PRE태그를 사용하지만, 이전 릴리스에서는 태그를 사용합니다snap_temp. -
hash- 및
kwargs키를 포함하는rpc테스트 파일에 대해 에서kwargs생성된 해시입니다.테스트 파일이 동일한 RPC를 사용하지만 다른 인수를 포함하고 RPC가 동일한 호스트에서 실행되는 경우 해시는 이러한 경우 고유한 출력 파일 이름을 보장합니다. 테스트 파일이 키를 정의
command하거나 테스트 파일이 키를 정의rpc하지만 키를 포함kwargs하지 않는 경우 해시가 생략됩니다. -
command- 매니지드 디바이스에서 실행된 명령 또는 RPC. 이 모듈은 명령 또는 RPC 이름의 공백과 특수 문자를 밑줄( _ )로 바꿉니다.
-
format- 출력 형식(예: xml)입니다.
모듈은 jsnapy 호스트 이름과 명령 또는 RPC만을 기반으로 지정된 작업에 대한 스냅샷 파일 이름을 구별합니다. 따라서 모듈이 동일한 명령 또는 RPC를 정의하는 테스트 파일을 사용하여 동일한 작업에 대해 동일한 디바이스에서 스냅샷을 만드는 경우 모듈은 동일한 파일 이름으로 스냅샷을 생성하고 새 파일이 이전 파일을 덮어씁니다.
예를 들어 모듈이 dc1a.example.net 및 dc1b.example.net 디바이스에서 및 show interfaces terse 명령어를 show chassis fpc 실행하는 테스트 파일을 포함 action: "snap_pre" 하고 참조하는 경우 결과 파일은 다음과 같습니다.
user@ansible-cn:~$ ls jsnapy/snapshots dc1a.example.net_PRE_show_chassis_fpc.xml dc1a.example.net_PRE_show_interfaces_terse.xml dc1b.example.net_PRE_show_chassis_fpc.xml dc1b.example.net_PRE_show_interfaces_terse.xml
모듈이 디바이스 dc1a.example.net 의 항목 interface_name: lo0 으로 kwargs RPC를 get-interface-information 실행하는 테스트 파일을 포함 action: "snap_post" 하고 참조하는 경우 결과 파일은 다음과 같습니다.
dc1a.example.net_POST_r1w59I99HXxC3u0VXXshbw==_get_interface_information.xml
스냅샷 파일을 생성하는 것 외에도 모듈은 jsnapy 모듈 응답에서 다음 키를 반환할 수도 있습니다.
-
action- 모듈이 수행하는 JSNAPy 작업. -
changed- 디바이스 상태가 변경되었는지 여부를 나타냅니다. JSNAPy는 상태에 대해서만 보고하므로 값은 항상false입니다. -
failed- 플레이북 작업이 실패했는지 여부를 나타냅니다. -
msg—JSNAPy 테스트 결과.
실패한 JSNAPy 테스트 검토
Junos 디바이스에 대해 JSNAPy 테스트를 실행할 때 모듈의 응답을 등록 jsnapy 하고 모듈을 사용하여 ansible.builtin.assert 이(가) passPercentage 100인지 확인하여 모든 JSNAPy 테스트가 통과했는지 빠르게 확인할 수 있습니다. 그러나 하나 이상의 테스트가 실패하는 경우 출력이 광범위하면 실패한 테스트를 식별하고 추출하기 어려울 수 있습니다.
이 juniper.device.jsnapy 모듈은 실패한 JSNAPy 테스트를 확인하기 위해 다음과 같은 옵션을 제공합니다.
-
jsnapycallback plugin - 플레이북 출력 후 실패한 JSNAPy 테스트의 요약을 인쇄합니다. -
dest_dirmodule 인수 - 실패한 JSNAPy 테스트를 지정된 디렉터리의 파일에 씁니다.
콜백 플러그인을 jsnapy 사용하면 실패한 JSNAPy 테스트에 대한 정보를 쉽게 추출하고 요약할 수 있습니다. 콜백 플러그인을 jsnapy 활성화하고 JSNAPy 테스트가 포함된 플레이북을 실행하면 플러그인은 플레이북 PLAY RECAP뒤에 실패한 JSNAPy 테스트에 대한 정보를 요약합니다.
콜백 플러그인은 jsnapy 기본적으로 비활성화되어 있습니다. 콜백 플러그인을 jsnapy 활성화하려면 Ansible 구성 파일에 문을 추가합니다 callback_whitelist = jsnapy .
[defaults] callback_whitelist = jsnapy
콜백 플러그인을 jsnapy 활성화하고 플레이북을 실행하면 플러그인이 실패한 JSNAPy 테스트를 사람이 읽을 수 있는 형식으로 요약합니다. 예를 들어:
...
PLAY RECAP ****************************************************************
qfx10002-01 : ok=3 changed=0 unreachable=0 failed=1
qfx10002-02 : ok=3 changed=0 unreachable=0 failed=1
qfx5100-01 : ok=1 changed=0 unreachable=0 failed=1
JSNAPy Results for: qfx10002-01 *******************************************
Value of 'peer-state' not 'is-equal' at '//bgp-information/bgp-peer' with {"peer-as": "64502", "peer-state": "Active", "peer-address": "198.51.100.21"}
Value of 'peer-state' not 'is-equal' at '//bgp-information/bgp-peer' with {"peer-as": "64510", "peer-state": "Idle", "peer-address": "192.168.0.1"}
Value of 'oper-status' not 'is-equal' at '//interface-information/physical-interface[normalize-space(admin-status)='up' and logical-interface/address-family/address-family-name ]' with {"oper-status": "down", "name": "et-0/0/18"}
JSNAPy Results for: qfx10002-02 *******************************************
Value of 'peer-state' not 'is-equal' at '//bgp-information/bgp-peer' with {"peer-as": "64502", "peer-state": "Active", "peer-address": "198.51.100.21"}
릴리스 1.0.6부터 juniper.device 모듈은 juniper.device.jsnapy dest_dir 인수도 지원합니다. 테스트 기준에 dest_dir 대해 스냅샷을 평가하는 및 snapcheck 작업에 대한 check 인수를 포함할 수 있습니다. 또는 snapcheck 작업을 수행하고 check 인수를 dest_dir 포함하면 모듈은 지정된 호스트에 대해 실패한 각 JSNAPy 테스트를 지정된 출력 디렉터리의 파일에 씁니다.
예를 들어 다음 플레이북을 고려하십시오.
---
- name: Verify BGP
hosts: bgp_routers
connection: local
gather_facts: no
tasks:
- name: Execute snapcheck
juniper.device.jsnapy:
action: "snapcheck"
dir: "~/jsnapy/testfiles"
test_files:
- "jsnapy_test_file_bgp_states.yaml"
- "jsnapy_test_file_bgp_summary.yaml"
logfile: "{{ logfile }}"
dest_dir: "{{ playbook_dir }}/jsnapy_failed_tests"
register: snapcheck_result
플레이북을 실행할 때 모듈은 지정된 호스트에서 실패한 각 테스트에 대해 디렉터리에 dest_dir 파일을 생성합니다. 예를 들어, 호스트 r1 및 r3의 실패 bgp_neighbor 및 bgp_summary 테스트에 대해 다음 파일이 생성되었습니다.
user@ansible-cn:~/ansible$ ls jsnapy_failed_tests r1_bgp_neighbor_False.text r3_bgp_neighbor_False.text r1_bgp_summary_False.text r3_bgp_summary_False.text
예: Ansible을 사용하여 JSNAPy Snapcheck 작업 수행
이 juniper.device.jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 Junos 디바이스에 대해 JSNAPy 테스트를 실행할 수 있습니다. 이 예에서는 모듈을 사용하여 jsnapy 특정 구성 변경 사항을 적용한 후 Junos 디바이스의 작동 상태를 확인하는 작업을 수행합니다 snapcheck .
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
-
실행 중인 Ansible 제어 노드:
-
Python 3.10 이상
-
컬렉션이
juniper.device설치된 Ansible 2.17 이상 -
Junos PyEZ 릴리스 2.7.3 이상
-
Python 릴리스 1.3.7 이상의 Junos Snapshot Administrator
-
Ansible 플레이북을 실행하기 전에 다음을 확인하십시오.
-
NETCONF over SSH가 활성화되고 적절한 권한으로 구성된 사용자 계정이 있는 Junos 디바이스
-
Ansible 제어 노드 및 Junos 디바이스에서 적절한 사용자에 대해 구성된 SSH 퍼블릭/프라이빗 키 쌍
-
필수 호스트가 정의된 기존 Ansible 인벤토리 파일
개요
이 예에서 Ansible 플레이북은 3개의 Junos 디바이스에서 BGP 피어링 세션을 구성하고 모듈을 사용하여 jsnapy BGP 세션이 각 neighbor 주소에 대해 설정되었는지 확인합니다. 플레이북에서 디바이스에 세션이 설정되었음을 확인하면 새 구성에 대한 커밋을 확인합니다. 플레이북이 커밋을 확인해주지 않으면 Junos 디바이스는 이전에 커밋한 구성으로 자동 롤백합니다. Ansible 프로젝트는 각각 및 host_vars 디렉터리 아래에 group_vars 플레이북에 대한 그룹 및 호스트 변수를 정의합니다.
플레이북에는 두 개의 연극이 있습니다. 첫 번째 플레이인 Load and commit BGP configuration은(는) 구성을 생성 및 어셈블하고, 디바이스에 구성을 로드하고, 커밋 확인 작업을 사용하여 커밋합니다. 구성이 업데이트되면 처리기 한 개에게 알림이 전송됩니다. 연극은 다음 작업을 실행합니다.
Remove build directory |
지정된 장치에 대한 기존 빌드 디렉터리(있는 경우)를 삭제합니다. |
Create build directory |
지정된 장치에 대해 비어 있는 새 빌드 디렉터리를 만듭니다. |
Build BGP configuration |
Jinja2 템플릿 및 호스트 변수와 함께 모듈을 사용하여 |
Assemble configuration parts |
모듈을 사용하여 이 예에서는 BGP 구성 파일만 존재하므로 결과 구성 파일은 이전 작업에서 렌더링된 BGP 구성 파일과 동일합니다. 나중에 새 작업을 추가하여 다른 템플릿 |
Load and commit config, require confirmation |
구성을 Junos 디바이스에 로드하고 작업을 사용하여 요청한 구성이 디바이스에 이미 있는 경우 모듈은 |
두 번째 재생인 Verify BGP은(는) JSNAPy 테스트 파일의 테스트를 사용하여 각 디바이스에서 JSNAPy snapcheck 작업을 수행합니다. 모든 테스트를 통과하면 플레이도 커밋을 확인합니다. 연극은 다음 작업을 실행합니다.
Execute snapcheck |
JSNAPy 이 예에서 플레이북은 인수를 |
Confirm commit |
첫 번째 플레이북 재생이 구성을 업데이트하고 모든 JSNAPy 테스트를 통과한 경우 이전 커밋 작업을 확인하는 커밋 확인 작업을 실행합니다. 플레이북이 구성을 업데이트하지만 커밋을 확인하지 않는 경우 Junos 디바이스는 자동으로 구성을 이전에 커밋한 구성으로 롤백합니다.
메모:
모듈에서 또는 인수에 각각 해당하는 |
Verify BGP configuration |
(선택 사항) 지정된 디바이스에서 JSNAPy 테스트의 통과 또는 실패 여부를 명시적으로 나타냅니다. 이 작업은 특별히 필요하지는 않지만 JSNAPy 테스트가 실패하는 경우와 디바이스에서 보다 쉽게 식별할 수 있습니다. |
구성
그룹 변수 정의하기
단계별 절차
그룹 변수를 정의하려면:
-
group_vars/all 파일에서 빌드 디렉터리와 구성 및 로그 파일의 파일 이름에 대한 변수를 정의합니다.
build_dir: "{{ playbook_dir }}/build_conf/{{ inventory_hostname }}" junos_conf: "{{ build_dir }}/junos.conf" logfile: "junos.log"
Jinja2 템플릿 및 호스트 변수 정의
Jinja2 템플릿 정의
BGP 구성을 생성하는 데 사용되는 Jinja2 템플릿을 생성하려면 다음을 수행합니다.
프로젝트의 플레이북 디렉터리에 bgp-template.j2 라는 파일을 만듭니다.
BGP 구성 템플릿을 파일에 추가합니다.
interfaces { {% for neighbor in neighbors %} {{ neighbor.interface }} { unit 0 { description "{{ neighbor.name }}"; family inet { address {{ neighbor.local_ip }}/30; } } } {% endfor %} lo0 { unit 0 { family inet { address {{ loopback }}/32; } } } } protocols { bgp { group underlay { import bgp-in; export bgp-out; type external; local-as {{ local_asn }}; multipath multiple-as; {% for neighbor in neighbors %} neighbor {{ neighbor.peer_ip }} { peer-as {{ neighbor.asn }}; } {% endfor %} } } lldp { {% for neighbor in neighbors %} interface "{{ neighbor.interface }}"; {% endfor %} } } routing-options { router-id {{ loopback }}; forwarding-table { export bgp-ecmp; } } policy-options { policy-statement bgp-ecmp { then { load-balance per-packet; } } policy-statement bgp-in { then accept; } policy-statement bgp-out { then { next-hop self; accept; } } }
호스트 변수 정의
BGP 구성을 생성하기 위해 Jinja2 템플릿과 함께 사용되는 호스트 변수를 정의하려면 다음을 수행합니다.
프로젝트의 host_vars 디렉터리에서 각 호스트에 대해 .yaml이라는hostname 별도의 파일을 만듭니다.
r1.yaml 파일에서 호스트 r1에 대한 변수를 정의합니다.
--- loopback: 192.168.0.1 local_asn: 64521 neighbors: - interface: ge-0/0/0 name: to-r2 asn: 64522 peer_ip: 198.51.100.2 local_ip: 198.51.100.1 peer_loopback: 192.168.0.2 - interface: ge-0/0/1 name: to-r3 asn: 64523 peer_ip: 198.51.100.6 local_ip: 198.51.100.5 peer_loopback: 192.168.0.3r2.yaml 파일에서 호스트 r2에 대한 변수를 정의합니다.
--- loopback: 192.168.0.2 local_asn: 64522 neighbors: - interface: ge-0/0/0 name: to-r1 asn: 64521 peer_ip: 198.51.100.1 local_ip: 198.51.100.2 peer_loopback: 192.168.0.1 - interface: ge-0/0/1 name: to-r3 asn: 64523 peer_ip: 198.51.100.10 local_ip: 198.51.100.9 peer_loopback: 192.168.0.3r3.yaml 파일에서 호스트 r3에 대한 변수를 정의합니다.
--- loopback: 192.168.0.3 local_asn: 64523 neighbors: - interface: ge-0/0/0 name: to-r1 asn: 64521 peer_ip: 198.51.100.5 local_ip: 198.51.100.6 peer_loopback: 192.168.0.1 - interface: ge-0/0/1 name: to-r2 asn: 64522 peer_ip: 198.51.100.9 local_ip: 198.51.100.10 peer_loopback: 192.168.0.2
JSNAPy 테스트 파일 생성
단계별 절차
이 모듈은 jsnapy ~/jsnapy/testfiles 디렉터리의 JSNAPy 테스트 파일을 참조합니다. JSNAPy 테스트 파일을 생성하려면 다음을 수행합니다.
명령을 실행하고
show bgp neighborBGP 피어 상태가 설정되었는지 테스트하는 jsnapy_test_file_bgp_states.yaml 파일을 생성합니다.bgp_neighbor: - command: show bgp neighbor - ignore-null: true - iterate: xpath: '//bgp-peer' id: './peer-address' tests: # Check if peers are in the established state - is-equal: peer-state, Established err: "Test Failed!! peer <{{post['peer-address']}}> state is not Established, it is <{{post['peer-states']}}>" info: "Test succeeded!! peer <{{post['peer-address']}}> state is <{{post['peer-state']}}>"명령을 실행하고
show bgp summaryBGP 다운 피어 수가 0이어야 한다고 어설션하는 jsnapy_test_file_bgp_summary.yaml 파일을 생성합니다.bgp_summary: - command: show bgp summary - item: xpath: '/bgp-information' tests: - is-equal: down-peer-count, 0 err: "Test Failed!! down-peer-count is not equal to 0. It is equal to <{{post['down-peer-count']}}>" info: "Test succeeded!! down-peer-count is equal to <{{post['down-peer-count']}}>"
Ansible 플레이북 생성
디바이스를 구성하기 위한 첫 번째 플레이를 정의합니다
구성을 렌더링하고, 디바이스에 로드하고, 커밋 확인 작업으로 구성을 커밋하는 첫 번째 플레이를 생성하려면 다음을 수행합니다.
플레이북에 대한 상용구와 모듈을 로컬에서 실행하는 첫 번째 플레이를 포함합니다.
--- - name: Load and commit BGP configuration hosts: bgp_routers connection: local gather_facts: no
기존 빌드 디렉터리를 새 구성 파일을 저장할 빈 디렉터리로 대체하는 작업을 만듭니다.
tasks: - name: Remove build directory file: path: "{{ build_dir }}" state: absent - name: Create build directory file: path: "{{ build_dir }}" state: directoryJinja2 템플릿 파일 및 호스트 변수에서 BGP 구성을 렌더링하고 해당 호스트의 빌드 디렉토리에 있는 bgp.conf 파일에 저장하는 작업을 생성합니다.
- name: Build BGP configuration template: src: "{{ playbook_dir }}/bgp-template.j2" dest: "{{ build_dir }}/bgp.conf"build 디렉터리의 구성 파일을 최종 junos.conf 구성 파일로 어셈블하는 작업을 만듭니다.
- name: Assemble configuration parts assemble: src: "{{ build_dir }}" dest: "{{ junos_conf }}"디바이스에 구성을 로드하고, 확인이 필요한 커밋 작업을 수행하고, 구성이 변경된 경우 지정된 처리기에 알리는 작업을 생성합니다.
- name: Load and commit config, require confirmation juniper.device.config: load: "merge" format: "text" src: "{{ junos_conf }}" confirm: 5 comment: "config by Ansible" logfile: "{{ logfile }}" register: config_result # Notify handler, only if configuration changes. notify: - Waiting for BGP peers to establish connections디바이스 구성이 업데이트되는 경우 플레이북 실행을 일시 중지하는 처리기를 만듭니다. 일시 중지 시간을 환경에 적합한 값으로 설정합니다.
handlers: - name: Waiting for BGP peers to establish connections pause: seconds=60
JSNAPy 작업을 수행하기 위한 두 번째 재생 정의
구성이 변경되고 JSNAPy 테스트를 통과한 경우, JSNAPy snapcheck 작업을 수행하고 커밋된 구성을 확인하는 두 번째 플레이를 생성하려면 다음을 수행합니다.
모듈을 로컬에서 실행하는 두 번째 플레이에 대한 상용구를 포함합니다.
- name: Verify BGP hosts: bgp_routers connection: local gather_facts: no
주어진 JSNAPy 테스트 파일의 테스트를 기반으로 JSNAPy snapcheck 작업을 수행하는 작업을 생성하고 모듈의 응답을 등록합니다.
tasks: - name: Execute snapcheck juniper.device.jsnapy: action: "snapcheck" dir: "~/jsnapy/testfiles" test_files: - "jsnapy_test_file_bgp_states.yaml" - "jsnapy_test_file_bgp_summary.yaml" logfile: "{{ logfile }}" register: snapcheck_result주어진 조건이 충족되는 경우 커밋을 확인하는 작업을 생성합니다.
# Confirm commit only if configuration changed and JSNAPy tests pass - name: Confirm commit juniper.device.config: check: true commit: false diff: false logfile: "{{ logfile }}" when: - config_result.changed - "snapcheck_result.passPercentage == 100"(선택 사항) 모듈을 사용하여
ansible.builtin.assertJSNAPy 테스트가 통과했음을 어설션하는 작업을 만듭니다.- name: Verify BGP configuration ansible.builtin.assert: that: - "snapcheck_result.passPercentage == 100" msg: "JSNAPy test on {{ inventory_hostname }} failed"
결과
Ansible 제어 노드에서 완료된 플레이북을 검토합니다. 플레이북에 의도한 코드가 표시되지 않으면 이 섹션의 지침을 반복하여 플레이북을 수정합니다.
---
- name: Load and commit BGP configuration
hosts: bgp_routers
connection: local
gather_facts: no
tasks:
- name: Remove build directory
file:
path: "{{ build_dir }}"
state: absent
- name: Create build directory
file:
path: "{{ build_dir }}"
state: directory
- name: Build BGP configuration
template:
src: "{{ playbook_dir }}/bgp-template.j2"
dest: "{{ build_dir }}/bgp.conf"
- name: Assemble configuration parts
assemble:
src: "{{ build_dir }}"
dest: "{{ junos_conf }}"
- name: Load and commit config, require confirmation
juniper.device.config:
load: "merge"
format: "text"
src: "{{ junos_conf }}"
confirm: 5
comment: "config by Ansible"
logfile: "{{ logfile }}"
register: config_result
# Notify handler, only if configuration changes.
notify:
- Waiting for BGP peers to establish connections
handlers:
- name: Waiting for BGP peers to establish connections
pause: seconds=60
- name: Verify BGP
hosts: bgp_routers
connection: local
gather_facts: no
tasks:
- name: Execute snapcheck
juniper.device.jsnapy:
action: "snapcheck"
dir: "~/jsnapy/testfiles"
test_files:
- "jsnapy_test_file_bgp_states.yaml"
- "jsnapy_test_file_bgp_summary.yaml"
logfile: "{{ logfile }}"
register: snapcheck_result
# Confirm commit only if configuration changed and JSNAPy tests pass
- name: Confirm commit
juniper.device.config:
check: true
commit: false
diff: false
logfile: "{{ logfile }}"
when:
- config_result.changed
- "snapcheck_result.passPercentage == 100"
- name: Verify BGP configuration
ansible.builtin.assert:
that:
- "snapcheck_result.passPercentage == 100"
msg: "JSNAPy test on {{ inventory_hostname }} failed"
플레이북 실행
플레이북을 실행하려면 다음을 수행합니다.
-
ansible-playbook제어 노드에서 명령을 실행하고 플레이북 경로 및 원하는 옵션을 제공합니다.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-bgp-configuration.yaml PLAY [Load and commit BGP configuration] ************************************* TASK [Remove build directory] ************************************************ changed: [r1] changed: [r2] changed: [r3] TASK [Create build directory] ************************************************ changed: [r1] changed: [r2] changed: [r3] TASK [Build BGP configuration] *********************************************** changed: [r2] changed: [r1] changed: [r3] TASK [Assemble configuration parts] ****************************************** changed: [r3] changed: [r2] changed: [r1] TASK [Load and commit config, require confirmation] ************************** changed: [r2] changed: [r1] changed: [r3] RUNNING HANDLER [Waiting for BGP peers to establish connections] ************* Pausing for 60 seconds (ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort) ok: [r3]
PLAY [Verify BGP] ************************************************************ TASK [Execute snapcheck] ***************************************************** ok: [r2] ok: [r1] ok: [r3] TASK [Confirm commit] ******************************************************** ok: [r2] ok: [r1] ok: [r3] TASK [Verify BGP configuration] ********************************************** ok: [r1] => { "changed": false, "msg": "All assertions passed" } ok: [r2] => { "changed": false, "msg": "All assertions passed" } ok: [r3] => { "changed": false, "msg": "All assertions passed" } PLAY RECAP ******************************************************************* r1 : ok=8 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 r2 : ok=8 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 r3 : ok=9 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
확인
BGP 인접 라우터 확인
목적
BGP 세션이 각 neighbor 주소에 대해 설정되었는지 확인합니다.
JSNAPy 테스트 파일은 BGP 세션이 각 neighbor 주소에 대해 설정되고 다운 피어가 없는지 테스트합니다. 작업 출력을 통해 해당 디바이스가 Verify BGP configuration 모든 JSNAPy 테스트를 통과했는지 신속하게 확인할 수 있습니다. JSNAPy passPercentage 가 100%와 같으면 태스크 출력에 포함됩니다 "msg": "All assertions passed" .
행동
작업 출력을 검토하고 각 디바이스가 Verify BGP configuration All assertions passed 메시지를 반환하는지 확인합니다.
TASK [Verify BGP configuration] **********************************************
ok: [r1] => {
"changed": false,
"msg": "All assertions passed"
}
ok: [r2] => {
"changed": false,
"msg": "All assertions passed"
}
ok: [r3] => {
"changed": false,
"msg": "All assertions passed"
}
의미
All assertions passed 이 메시지는 BGP 세션이 디바이스에서 성공적으로 설정되었음을 나타냅니다.
Ansible 플레이북 오류 문제 해결
구성 로드 오류 문제 해결
문제
Ansible 플레이북은 구문 오류로 인해 디바이스에 구성을 로드하지 못했음을 나타내는 오류를 생성합니다 ConfigLoadError .
fatal: [r1]: FAILED! => {"changed": false, "msg": "Failure loading the configuraton: ConfigLoadError(severity: error, bad_element: protocol, message: error: syntax error\nerror: error recovery ignores input until this point)"}
용액
플레이북은 Jinja2 템플릿과 host_vars 디렉터리에서 해당 디바이스에 대해 정의된 호스트 변수를 사용하여 Junos OS 구성을 렌더링합니다. 플레이북은 Jinja2 템플릿이 잘못된 구성을 생성할 때 구문 오류를 생성합니다. 이 오류를 해결하려면 Jinja2 템플릿을 업데이트하여 오류 메시지에서 키로 식별된 bad_element 요소를 수정합니다.
실패한 JSNAPy 테스트 문제 해결
문제
작업 출력은 Verify BGP configuration JSNAPy passPercentage 가 100%와 같지 않기 때문에 어설션이 실패했음을 나타냅니다.
TASK [Verify BGP configuration] *************************************************************
fatal: [r1]: FAILED! => {
"assertion": "snapcheck_result.passPercentage == 100",
"changed": false,
"evaluated_to": false,
"msg": "JSNAPy test on r1 failed"
}
디바이스가 인접 라우터와의 BGP 세션을 설정하지 않았거나 세션이 다운되면 어설션이 실패합니다. 어설션이 실패하고 해당 디바이스의 구성이 첫 번째 플레이에서 업데이트된 경우, 플레이북은 디바이스의 새로운 구성에 대한 커밋을 확인하지 않으며 디바이스는 이전에 커밋된 구성으로 구성을 롤백합니다.
용액
피어가 세션을 설정하기 전에 작업이 수행되거나 BGP 이웃이 올바르게 구성되지 않았기 때문에 JSNAPy 테스트가 실패 snapcheck 할 수 있습니다. 플레이북 출력에서 구성이 디바이스에 성공적으로 로드되고 커밋되었음을 나타내는 경우 처리기의 일시 중지 간격을 환경에 적합한 값으로 늘리고 플레이북을 다시 실행해 보십시오.
handlers:
- name: Waiting for BGP peers to establish connections
pause: seconds=75
테스트가 여전히 실패하는 경우 각 디바이스의 Jinja2 템플릿 및 호스트 변수에 올바른 데이터가 포함되어 있고 각 디바이스에 대한 결과 구성이 올바른지 확인합니다.
실패한 커밋 확인 문제 해결
문제
하나 이상의 디바이스에서 구성이 확인되지 않았습니다.
TASK [Confirm commit] *********************************************************************** skipping: [r2] skipping: [r2] skipping: [r3]
용액
플레이북은 구성이 변경되고 JSNAPy 테스트를 통과한 경우에만 구성을 확인합니다. 작업 출력에서 Load and commit config, require confirmation 구성이 변경되지 않았음을 나타내는 경우 플레이북은 커밋을 확인하는 작업을 실행하지 않습니다. 구성이 변경되었지만 확인되지 않은 경우 JSNAPy 테스트가 실패합니다. BGP 인접 항목이 올바르게 구성되지 않았거나 플레이북이 재생 사이에 디바이스가 BGP 세션을 설정할 수 있는 충분한 시간을 제공하지 않는 경우 JSNAPy 테스트가 실패할 수 있습니다. 자세한 내용은 실패한 JSNAPy 테스트 문제 해결을 참조하십시오.