Ansible Playbook의 Python(JSNAPy)에서 Junos 스냅샷 관리자 사용
요약 Ansible 플레이북의 일부로 JSNAPy 테스트를 실행하여 Junos OS를 실행하는 디바이스의 런타임 환경 스냅샷을 캡처하고 감사합니다.
JSNAPy(Junos® Snapshot Administrator in Python)를 사용하면 Junos OS를 실행하는 네트워크 디바이스의 런타임 환경 스냅샷을 캡처하고 감사할 수 있습니다. 디바이스의 구성 및 작동 상태를 캡처 및 확인하고 디바이스의 변경 사항을 확인할 수 있습니다. 주니퍼 네트웍스는 Ansible 플레이북의 일부로 Junos OS를 실행하는 장치에 대해 JSNAPy 테스트를 실행할 수 있는 Ansible 모듈을 제공합니다. 표 1 에서는 사용 가능한 모듈을 개략적으로 설명합니다.
컨텐츠 세트 |
모듈 이름 |
|---|---|
|
|
모듈을 사용하려면 Ansible 제어 노드에 Python에 Junos 스냅샷 관리자를 설치해야 합니다. JSNAPy 구성 및 테스트 파일 생성에 대한 설치 지침 및 정보는 Python 설명서의 Junos 스냅샷 관리자를 참조하십시오.
Juniper.junos 릴리스 2.0.0 juniper_junos_jsnapy 부터 모듈이 모듈의 junos_jsnapy 기능을 대체합니다.
다음 섹션에서는 Ansible 플레이북에서 모듈을 사용하는 방법에 대해 설명합니다.
모듈 개요
jsnapy 및 juniper_junos_jsnapy 모듈을 사용하면 명령줄에서 JSNAPy를 사용하여 실행할 수 있기 때문에 Ansible 플레이북에서 다음과 같은 많은 JSNAPy 기능을 실행할 수 있습니다.
런타임 환경 스냅샷 캡처 및 저장
두 개의 스냅샷 비교
스냅샷을 캡처하여 즉시 평가
모듈은 인수 및 인수 중 config_file test_files 하나를 지정 action 해야 합니다. 인수는 action 수행할 JSNAPy 작업을 지정합니다. 표 2에는 유효한 action 값과 동등한 JSNAPy 명령이 설명되어 있습니다.
조치 가치 |
설명 |
동급 JSNAPy 명령 |
|---|---|---|
|
주어진 테스트 케이스에 따라 기존 스냅샷 2개를 비교하거나 테스트 케이스가 제공되지 않는 경우 노드별로 스냅샷 노드를 비교합니다. |
|
|
지정된 디바이스를 변경한 후 테스트 파일에 지정된 명령어 또는 RPC에 대한 스냅샷을 만듭니다. |
|
|
지정된 디바이스를 변경하기 전에 테스트 파일에 지정된 명령어 또는 RPC에 대한 스냅샷을 만듭니다. |
|
|
테스트 파일에 지정된 명령어 또는 RPC에 대한 스냅샷을 가지고 테스트 케이스에서 미리 정의된 기준에 따라 스냅샷을 즉시 평가합니다. |
|
명령줄에서 JSNAPy를 실행하면 JSNAPy는 구성 파일의 섹션에 지정된 호스트에서 hosts 요청된 작업을 수행합니다. 반대로 Ansible 모듈은 플레이북에 정의된 Ansible 인벤토리 그룹의 호스트에서 요청된 작업을 실행합니다. 따라서 모듈은 섹션을 무시하고 hosts 구성 파일을 참조하거나 하나 이상의 테스트 파일을 직접 참조할 수 있습니다.
따라서 인수 외에도action, jsnapy 및 juniper_junos_jsnapy 모듈은 주어진 작업에 사용할 JSNAPy 구성 파일 또는 JSNAPy 테스트 파일을 지정하기 위한 인수 또는 test_files 인수를 요구 config_file 합니다. 표 3은 그 및 test_files 인수를 config_file 개략적으로 설명합니다.
모듈 인수 |
값 |
추가 정보 |
|---|---|---|
|
JSNAPy 구성 파일로 향하는 절대적 또는 상대적 파일 경로입니다. |
경로가 상대적인 경우 모듈은 다음 위치에 있는 구성 파일을 검사하고 순서대로 다음과 같이 표시합니다.
구성 파일이 상대 파일 경로를 사용하여 테스트 파일을 참조하는 경우, 모듈은 먼저 플레이북 디렉토리의 테스트 파일을 검사한 다음 기본 |
|
JSNAPy 테스트 파일에 대한 절대적 또는 상대적 파일 경로 이는 단일 파일 경로 또는 파일 경로 목록이 될 수 있습니다. |
상대 경로를 지정하는 각 테스트 파일에 대해 모듈은 다음 위치와 순서대로 해당 파일을 검사합니다.
|
인수 test_files 는 config_file 절대 또는 상대적 파일 경로를 취할 수 있습니다. 상대적 파일 경로를 사용할 때 선택적으로 모듈 인수를 dir 포함하여 파일이 있는 디렉토리를 지정할 수 있습니다. a config_file 또는 test_files 인수가 상대 파일 경로를 사용하는 경우, 모듈은 인수가 있는 경우에도 dir 먼저 Ansible 플레이북 디렉토리에서 파일을 검사합니다. 파일이 플레이북 디렉토리 아래에 없는 경우, 모듈은 인수 디렉토리에서dir, 또는 인수가 생략된 경우 dir /etc/jsnapy/testfiles 디렉토리에서 확인합니다. 파일을 찾을 수 없는 경우 플레이북에서 오류 메시지가 생성됩니다.
다음 샘플 플레이북은 configuration_interface_status.yaml 구성 파일을 사용하여 작업을 수행합니다snap_pre. 구성 파일이 플레이북 디렉토리에 없는 경우, 모듈은 jsnapy/testfiles 하위 디렉토리에 있는 사용자의 홈 디렉토리에 있는 파일을 검사합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot of the interfaces
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
config_file: "configuration_interface_status.yaml"
Python Release 1.3.0의 Junos 스냅샷 관리자에서 시작하여 구성 및 테스트 파일의 기본 위치는 ~/jsnapy/testfiles입니다. 그러나 가상 환경 내부 또는 이전 릴리스의 기본 위치는 /etc/jsnapy/testfiles입니다.
이 모듈은 섹션이 포함된 hosts 구성 파일을 참조하는 경우에도 Ansible 플레이북에 지정된 호스트에서 요청된 작업을 수행합니다. 이 모듈은 오류가 발생하고 JSNAPy 테스트를 실행하지 못할 경우 실패했다고 보고합니다. 하나 이상의 JSNAPy 테스트에 실패하면 실패했다고 보고 하지 않습니다. JSNAPy 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 assert 예상 결과를 확인합니다.
Python의 Junos 스냅샷 관리자는 작업에 관한 정보를 /var/log/jsnapy/jsnapy.log 파일에 기본적으로 기록합니다. 및 juniper_junos_jsnapy 모듈은 jsnapy 선택적으로 Ansible 제어 노드에서 특정 작업에 대한 정보가 기록된 필기 파일로 가는 경로를 지정하는 인수를 포함 logfile 할 수 있습니다. 파일에 기록된 정보 수준은 Ansible의 자세한 내용 수준과 디버그 옵션에 따라 결정됩니다. 기본적으로 심각도 수준 경고 또는 그 이상에 대한 메시지만 로깅됩니다. 심각도 수준 INFO 또는 심각도 수준 DEBUG보다 높은 메시지를 기록하려면 각각 또는 -vv 명령행 옵션을 사용하여 -v 플레이북을 실행합니다.
Ansible 플레이북에서 JSNAPy 테스트를 실행하는 경우 콜백 플러그인이 실패한 JSNAPy 테스트에 대한 정보를 캡처하고 요약할 수 jsnapy 있습니다. 콜백 플러그인을 사용하려면 Ansible 구성 파일에 명령문을 추가 callback_whitelist = jsnapy 하십시오. 자세한 내용은 jsnapy 콜백 플러그인 활성화를 참조하십시오.
스냅샷 촬영 및 비교
JSNAPy를 사용하면 변경 전후에 Junos OS를 실행하는 네트워크 디바이스의 런타임 환경 스냅샷을 캡처한 다음 스냅샷을 비교하여 예상 변경을 확인하거나 예기치 않은 문제를 식별할 수 있습니다. jsnapy Ansible juniper_junos_jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 JSNAPy 스냅샷을 들이고 비교할 수 있습니다. 모듈은 미리 정해진 파일 이름을 사용하여 기본 JSNAPy 스냅샷 디렉토리의 개별 파일에 각 호스트에 대한 각 스냅샷을 저장합니다. 출력 파일에 대한 자세한 내용은 jsnapy 및 juniper_junos_jsnapy Module Output의 이해를 참조하십시오.
변경하기 전에 하나 이상의 장치에 대한 기본 스냅샷을 하려는 경우 모듈의 action 인수를 snap_pre구성 파일 또는 하나 이상의 테스트 파일에 지정합니다.
다음 플레이북은 Ansible 인벤토리 그룹의 각 디바이스에 대한 PRE 스냅샷을 저장합니다. 작업은 ~/jsnapy/testfiles 디렉토리에 있는 configuration_interface_status.yaml 구성 파일을 참조하고 플레이북 디렉토리의 jsnapy_tests.log 파일에 메시지를 기록합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot of the interfaces
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
config_file: "configuration_interface_status.yaml"
logfile: "jsnapy_tests.log"
변경 사항을 수행한 후 하나 이상의 디바이스에 대한 스냅샷을 보려면 모듈의 action 인수를 snap_post구성 파일 또는 하나 이상의 테스트 파일에 지정합니다.
다음 플레이북은 Ansible 인벤토리 그룹의 각 디바이스에 대한 POST 스냅샷을 저장합니다. 작업은 ~/jsnapy/testfiles 디렉토리에 있는 동일한 configuration_interface_status.yaml 구성 파일을 참조하고 플레이북 디렉토리의 jsnapy_tests.log 파일에 메시지를 기록합니다.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a post-maintenance snapshot of the interfaces
juniper.device.jsnapy:
action: "snap_post"
dir: "~/jsnapy/testfiles"
config_file: "configuration_interface_status.yaml"
logfile: "jsnapy_tests.log"
또는 모듈이 jsnapy 조치 또는 juniper_junos_jsnapy 작업을 수행할 snap_pre 때 각각 'PRE' 또는 snap_post 'POST' 태그가 포함된 자동 생성 파일 이름을 사용하여 개별 파일의 각 호스트에 대한 각 스냅샷을 저장합니다. 스냅샷을 POST 비교 PRE 해 업데이트를 신속하게 검증하거나 변경으로 인해 발생할 수 있는 문제를 식별하려면 모듈의 action 인수를 check스냅샷을 다는 데 사용된 것과 동일한 구성 파일 또는 테스트 파일을 지정합니다.
모듈이 작업을 수행할 check 때 각 디바이스의 각 테스트에 대한 사전 및 POST 스냅샷을 테스트 파일 섹션에 정의된 tests: 기준에 따라 비교 및 평가합니다. 테스트 파일이 테스트 케이스를 정의하지 않으면 JSNAPy가 노드별로 스냅샷 노드를 비교합니다. 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 assert 사용하여 응답에서 예상되는 결과를 검증합니다.
다음 플레이북에서는 이전에 실행된 snap_pre 스냅샷과 snap_post Ansible 인벤토리 그룹의 모든 디바이스에 대한 작업을 비교합니다. 결과는 구성 파일에서 참조되는 테스트 파일의 기준을 사용하여 평가됩니다. 플레이북은 모듈의 응답을 'test_result'로 등록하고 모듈을 사용하여 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: "configuration_interface_status.yaml"
logfile: "jsnapy_tests.log"
register: test_result
- name: Verify JSNAPy tests passed
assert:
that:
- "test_result.passPercentage == 100"
플레이북을 실행할 때 가정은 테스트에 실패한 디바이스를 신속하게 식별합니다.
user@host:~$ ansible-playbook jsnapy-interface-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-interface-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
스냅체크 작업 수행
JSNAPy를 사용하면 JSNAPy 테스트 파일에 지정된 명령어 또는 RPC에 대한 스냅샷을 쳐서 테스트 케이스에서 미리 정의된 기준에 따라 스냅샷을 즉시 평가할 수 있습니다. jsnapy Ansible juniper_junos_jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 JSNAPy 스냅체크 작업을 수행할 수 있습니다.
스냅샷을 가지고 테스트 파일 섹션의 사전 정의된 기준 집합을 tests: 기반으로 즉시 평가하려면 모듈의 action 인수를 snapcheck구성 파일 또는 하나 이상의 테스트 파일을 지정합니다. 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 assert 사용하여 응답에서 예상되는 결과를 검증합니다.
예를 들어, Ansible 인벤토리 그룹의 각 디바이스에 대해 다음 플레이북은 테스트 파일의 각 명령 또는 RPC에 대한 별도의 스냅샷을 저장하고 모듈의 응답을 등록하며 어설트 모듈을 사용하여 테스트 파일에 정의된 모든 테스트가 해당 장치에 전달되었는지 확인합니다.
---
- 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
assert:
that:
- "test_result.passPercentage == 100"
jsnapy 및 juniper_junos_jsnapy 모듈 출력 이해
또는 모듈이 jsnapy , 또는 snapcheck 작업을 수행할 snap_postsnap_pre때 JSNAPy 스냅샷 디렉토리에 있는 스냅샷을 자동으로 저장합니다.juniper_junos_jsnapy 다른 위치를 지정하기 위해 JSNAPy 구성 파일을 수정하지 않는 한 모듈은 기본 JSNAPy 디렉토리를 사용합니다. 이 모듈은 Ansible 인벤토리 그룹의 각 디바이스에서 실행되는 각 명령 또는 RPC에 대해 별도의 파일을 만듭니다. 표 4는 인수의 각 값에 대한 스냅샷 파일의 action 파일 이름을 개략적으로 설명합니다.
Python Release 1.3.0의 Junos 스냅샷 관리자에서 시작하여 JSNAPy 테스트 파일 및 스냅샷의 기본 디렉토리는 각각 ~/jsnapy/testfiles 및 ~/jsnapy/스냅샷입니다. 그러나 가상 환경 내부 또는 이전 릴리스의 기본 디렉토리는 /etc/jsnapy/testfiles 및 /etc/jsnapy/스냅샷입니다.
|
출력 파일 |
|---|---|
|
hostname_PRE_hashcommand.format |
|
hostname_POST_hashcommand.format |
|
hostnamehash_snap_temp__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 호스트 이름 및 juniper_junos_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 모듈은 juniper_junos_jsnapy 모듈 응답에서 다음과 같은 키를 반환할 수 있습니다.
action—모듈이 수행하는 JSNAPy 작업.changed—디바이스 상태가 변경되었는지 나타낸다. JSNAPy는 상태에 대해서만 보고하기 때문에 값은 항상false입니다.failed—플레이북 작업이 실패했는지 나타낸다.msg—JSNAPy 테스트 결과.
jsnapy Callback Plugin 활성화
Junos OS를 실행하는 장치에 대해 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"}
예: Ansible을 사용하여 JSNAPy 스냅체크 작동 수행
이 jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 Junos OS를 실행하는 장치에 대해 JSNAPy 테스트를 실행할 수 있습니다. 이 예제에서는 모듈을 사용하여 jsnapy 특정 구성 변경을 적용한 snapcheck 후 Junos OS를 실행하는 디바이스의 작동 상태를 검증하는 작업을 수행합니다.
요구 사항
이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 사용합니다.
실행 중인 Ansible 제어 노드:
Python 3.7 이상
컬렉션이 설치된 Ansible 2.10 이상
juniper.deviceJunos PyEZ 릴리스 2.6.0 이상
Python 릴리스 1.3.6 이상에서 Junos 스냅샷 관리자
Ansible 플레이북을 실행하기 전에 다음 사항을 확인해야 합니다.
NETCONF over SSH를 지원하는 Junos OS를 실행하는 장치 및 적절한 권한으로 구성된 사용자 계정
Junos OS를 실행하는 Ansible 제어 노드 및 디바이스에서 적합한 사용자를 위해 구성된 SSH 퍼블릭/프라이빗 키 쌍
필요한 호스트가 정의된 기존 Ansible 인벤토리 파일
개요
이 예에서 Ansible 플레이북은 Junos OS를 실행하는 세 개의 디바이스에서 BGP 피어링 세션을 구성하고 모듈을 사용하여 jsnapy BGP 세션이 각 인접 주소에 대해 설정되었는지 확인합니다. 플레이북에서 세션이 장비에 설정되었는지 확인하면 새 구성에 대한 커밋이 확인됩니다. 플레이북이 커밋을 확인하지 않으면 Junos OS를 실행하는 디바이스가 이전에 커밋된 구성으로 자동 롤백됩니다. Ansible 프로젝트는 각각 및 디렉토리에서 플레이북에 group_vars 대한 그룹 및 host_vars 호스트 변수를 정의합니다.
플레이북에는 두 개의 연극이 있습니다. 첫 번째 플레이인 Load and commit BGP configuration, 구성을 생성 및 조합하고, 디바이스에서 구성을 로드한 다음, 커밋 확인된 작업을 사용하여 커밋합니다. 구성이 업데이트되면 한 처리기에게 통보를 받습니다. 플레이는 다음과 같은 작업을 실행합니다.
Remove build directory |
해당 디바이스에 대한 기존 빌드 디렉토리(있는 경우)를 삭제합니다. |
Create build directory |
해당 디바이스에 대한 새 빈 빌드 디렉토리를 만듭니다. |
Build BGP configuration |
이 모듈에 |
Assemble configuration parts |
모듈을 이 예에서는 BGP 구성 파일만 나타나므로 생성된 구성 파일은 이전 작업에서 렌더링된 BGP 구성 파일과 동일합니다. 나중에 다른 템플릿에서 추가 구성 파일을 생성하기 위해 새로운 작업을 추가하면 모듈은 |
Load and commit config, require confirmation |
Junos OS를 실행하는 디바이스에 구성을 로드하고 작업을 사용하여 구성을 요청된 구성이 장비에 이미 있는 경우, 모듈은 구성을 |
두 번째 플레이 Verify BGP는 JSNAPy snapcheck 테스트 파일의 테스트를 사용하여 각 디바이스에서 JSNAPy 작업을 수행하고 모든 테스트가 통과하면 커밋을 확인합니다. 플레이는 다음과 같은 작업을 실행합니다.
Execute snapcheck |
JSNAPy 이 예에서 플레이북은 JSNAPy 테스트 파일 목록과 같도록 인수를 |
Confirm commit |
첫 번째 플레이북 플레이가 구성을 업데이트하고 모든 JSNAPy 테스트가 통과한 경우 이전 커밋 작업을 확인하는 커밋 확인 작업을 실행합니다. 플레이북이 구성을 업데이트하지만 커밋을 확인하지 않으면 Junos OS를 실행하는 디바이스가 자동으로 구성을 이전의 커밋된 구성으로 롤백합니다.
참고:
모듈에서 각각 또는 인수에 해당하는 장비의 a |
Verify BGP configuration |
(선택사항) JSNAPy 테스트가 해당 디바이스에서 통과했는지 또는 실패했는지 여부를 명시적으로 나타낸다. 이 작업은 특별히 필요하지 않지만 JSNAPy 테스트에 실패할 때와 어떤 디바이스에 대해 더 쉽게 식별할 수 있습니다. |
구성
그룹 변수 정의
단계별 절차
그룹 변수를 정의하려면 다음을 수행합니다.
group_vars/모든 파일에서 빌드 디렉토리와 구성 및 로그 파일의 파일 이름에 대한 변수를 정의합니다.
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 테스트 파일을 만들려면 다음을 수행합니다.
BGP 피어 상태가 설정된 명령을 실행하고
show bgp neighbor테스트하는 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 down 피어 수가 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"빌드 디렉토리의 구성 파일을 최종 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 스냅체크 작업을 수행하고 커밋된 구성을 확인하는 두 번째 플레이를 생성하려면 다음을 수행합니다.
모듈을 로컬에서 실행하는 두 번째 플레이용 보일러플레이를 포함합니다.
- name: Verify BGP hosts: bgp_routers connection: local gather_facts: no
주어진 JSNAPy 테스트 파일의 테스트를 기반으로 JSNAPy 스냅체크 작업을 수행하고 모듈의 응답을 등록하기 위한 작업을 생성합니다.
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"(선택사항) 모듈을 사용하여
assertJSNAPy 테스트가 통과했다고 주장하는 작업을 생성합니다.- name: Verify BGP configuration 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
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 Neighbor 검증
목적
각 인접 주소에 대해 BGP 세션이 설정되었는지 확인합니다.
JSNAPy 테스트 파일은 BGP 세션이 각 인접 주소에 대해 설정되고 다운 피어가 없는지 테스트합니다. 작업 출력을 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 neighbor가 올바르게 구성되지 않았기 때문에 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 neighbor가 올바르게 구성되지 않았거나 플레이북이 디바이스에서 BGP 세션을 설정하기 위한 플레이 사이에 충분한 시간을 제공하지 못하는 경우 JSNAPy 테스트는 실패할 수 있습니다. 자세한 내용은 문제 해결 실패 JSNAPy 테스트를 참조하십시오.