Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Ansible 플레이북에서 JSNAPy(Junos Snapshot Administrator in Python) 사용

요약 Ansible 플레이북의 일부로 JSNAPy 테스트를 실행하여 Junos 디바이스의 런타임 환경 스냅샷을 캡처하고 감사할 수 있습니다.

JSNAPy(Junos Snapshot Administrator in Python)를 사용하면 네트워크 Junos® 디바이스의 런타임 환경 스냅샷을 캡처하고 감사할 수 있습니다. 디바이스의 구성 및 작동 상태를 캡처 및 확인하고 디바이스에 대한 변경 사항을 확인할 수 있습니다. 주니퍼 네트웍스는 Ansible 플레이북의 일부로 Junos 디바이스에 대해 JSNAPy 테스트를 실행할 수 있는 Ansible 모듈을 제공합니다. 표 1 에는 사용 가능한 모듈이 요약되어 있습니다.

표 1: JSNAPy 모듈

콘텐츠 집합

모듈 이름

juniper.device 컬렉션

jsnapy

Juniper.junos 역할

juniper_junos_jsnapy

모듈을 사용하려면 Ansible 제어 노드에 Python으로 Junos Snapshot Administrator를 설치해야 합니다. JSNAPy 구성 및 테스트 파일 생성에 대한 설치 지침과 정보는 Python 설명서의 Junos 스냅샷 관리자를 참조하십시오.

참고:

릴리스 2.0.0 juniper_junos_jsnapy 부터 Juniper.junos 모듈은 모듈의 기능을 대체합니다junos_jsnapy.

다음 섹션에서는 Ansible 플레이북의 모듈을 사용하는 방법에 대해 설명합니다.

모듈 개요

jsnapyjuniper_junos_jsnapy 모듈을 사용하면 명령줄에서 JSNAPy를 사용하여 실행할 수 있는 것과 동일한 JSNAPy 기능을 Ansible 플레이북에서 실행할 수 있습니다.

  • 런타임 환경 스냅샷 캡처 및 저장

  • 두 스냅숏 비교

  • 스냅샷 캡처 및 즉시 평가

모듈에서는 인수와 또는 인수를 config_file test_files 지정해야 action 합니다. 인수는 action 수행할 JSNAPy 작업을 지정합니다. 표 2 에는 유효한 action 값과 동등한 JSNAPy 명령이 요약되어 있습니다.

표 2: jsnapy 및 juniper_junos_jsnapy 작업 인수 값

action 값

설명

동등한 JSNAPy 명령

check

지정된 테스트 사례를 기반으로 두 개의 기존 스냅숏을 비교하거나, 테스트 사례가 제공되지 않은 경우 노드별로 스냅숏을 비교합니다.

jsnapy --check

snap_post

지정된 디바이스를 변경한 후 테스트 파일에 지정된 명령 또는 RPC에 대한 스냅샷을 생성합니다.

jsnapy --snap

snap_pre

주어진 장치를 변경하기 전에 테스트 파일에 지정된 명령 또는 RPC에 대한 스냅샷을 찍습니다.

jsnapy --snap

snapcheck

테스트 파일에 지정된 명령 또는 RPC의 스냅샷을 찍고 테스트 케이스에서 사전 정의된 기준에 따라 스냅샷을 즉시 평가합니다.

jsnapy --snapcheck

명령줄에서 JSNAPy를 실행하면 JSNAPy는 구성 파일의 섹션에 지정된 호스트에서 요청된 hosts 작업을 수행합니다. 반대로 Ansible 모듈은 플레이북에 정의된 Ansible 인벤토리 그룹의 호스트에서 요청된 작업을 실행합니다. 따라서 모듈은 섹션을 무시하고 hosts 구성 파일을 참조하거나 하나 이상의 테스트 파일을 직접 참조할 수 있습니다.

따라서 인수 외에도 action 및 모듈에는 지정된 조치에 사용할 JSNAPy 구성 파일 또는 JSNAPy 테스트 파일을 지정하기 위해 또는 test_files 인수 jsnapy 중 하나가 config_file 필요합니다. 표 3에서는 및 juniper_junos_jsnapy test_files 인수를 config_file 간략하게 설명합니다.

표 3: jsnapy 및 juniper_junos_jsnapy 파일 인수

Module 인수

추가 정보

config_file

JSNAPy 구성 파일에 대한 절대 또는 상대 파일 경로입니다.

경로가 상대적인 경로인 경우 모듈은 다음 위치에서 표시된 순서대로 구성 파일을 확인합니다.

  • Ansible 플레이북 디렉토리

  • dir 인수 디렉터리(제공된 경우)

  • /etc/jsnapy/testfiles 디렉토리(인수가 생략된 dir 경우에만)

구성 파일이 상대 파일 경로를 사용하여 테스트 파일을 참조하는 경우, 모듈은 먼저 플레이북 디렉토리에서 테스트 파일을 확인한 다음 JSNAPy 릴리스 및 사용자 환경에 따라 달라지는 기본 testfiles 디렉토리에서 테스트 파일을 확인합니다.

test_files

JSNAPy 테스트 파일의 절대 또는 상대 파일 경로입니다. 단일 파일 경로 또는 파일 경로 목록일 수 있습니다.

상대 경로를 지정하는 각 테스트 파일에 대해 모듈은 다음 위치 및 표시된 순서대로 파일을 확인합니다.

  • Ansible 플레이북 디렉토리

  • dir 인수 디렉터리(제공된 경우)

  • /etc/jsnapy/testfiles 디렉토리(인수가 생략된 dir 경우에만)

test_files 인수는 config_file 절대 또는 상대 파일 경로를 사용할 수 있습니다. 상대 파일 경로를 사용하는 경우 선택적으로 module 인수를 포함하여 dir 파일이 상주하는 디렉토리를 지정할 수 있습니다. 또는 test_files 인수가 config_file 상대 파일 경로를 사용하는 경우 모듈은 인수가 있더라도 dir 먼저 Ansible 플레이북 디렉토리 아래에서 파일을 확인합니다. 파일이 플레이북 디렉토리 아래에 존재하지 않는 경우, 모듈은 인수 디렉토리 아래dir(지정된 경우) 또는 인수가 생략된 경우 dir /etc/jsnapy/testfiles 디렉토리 아래에서 확인합니다. 플레이북은 파일을 찾을 수 없는 경우 오류 메시지를 생성합니다.

다음 샘플 플레이북은 snap_pre configuration_interface_status.yaml 구성 파일을 사용하여 작업을 수행합니다. 구성 파일이 플레이북 디렉토리에 없는 경우, 모듈은 jsnapy/testfiles 서브디렉토리 아래의 사용자 홈 디렉토리에서 파일을 확인합니다.

참고:

Python 릴리스 1.3.0의 Junos Snapshot Administrator부터 구성 및 테스트 파일의 기본 위치는 ~/jsnapy/testfiles입니다. 그러나 가상 환경 내부 또는 이전 릴리스의 기본 위치는 / etc/jsnapy/testfiles입니다.

모듈은 섹션이 포함된 구성 파일을 참조하는 경우에도 Ansible 플레이북에 지정된 호스트에서 요청된 hosts 작업을 수행합니다. 오류가 발생하여 JSNAPy 테스트를 실행하지 못하면 모듈 보고서가 실패했습니다. 하나 이상의 JSNAPy 테스트가 실패하는 경우 실패를 보고 하지 않습니다 . JSNAPy 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 assert 응답의 예상 결과를 확인합니다.

Python의 Junos Snapshot Administrator는 기본적으로 /var/log/jsnapy/jsnapy.log 파일에 운영 관련 정보를 기록합니다. jsnapyjuniper_junos_jsnapy 모듈은 특정 태스크에 logfile 대한 정보가 기록되는 Ansible 제어 노드에서 쓰기 가능한 파일의 경로를 지정하는 인수를 선택적으로 포함할 수 있습니다. 파일에 기록되는 정보 수준은 Ansible의 세부 정보 표시 수준 및 디버그 옵션에 따라 결정됩니다. 기본적으로 심각도 수준 WARNING 이상의 메시지만 기록됩니다. 심각도 수준 INFO 또는 심각도 수준 DEBUG보다 높거나 같은 메시지를 기록하려면 각각 또는 -vv 명령줄 옵션을 사용하여 플레이북을 -v 실행합니다.

Ansible 플레이북에서 JSNAPy 테스트를 실행할 때 콜백 플러그인을 활성화 jsnapy 하여 실패한 JSNAPy 테스트에 대한 정보를 캡처하고 요약할 수 있습니다. 콜백 플러그인을 활성화하려면 Ansible 구성 파일에 문을 추가합니다 callback_whitelist = jsnapy . 자세한 내용은 jsnapy 콜백 플러그인 활성화를 참조하십시오.

스냅숏 찍기 및 비교

JSNAPy를 사용하면 변경 전후에 네트워크 Junos 디바이스의 런타임 환경 스냅샷을 캡처한 다음 스냅샷을 비교하여 예상되는 변경 사항을 확인하거나 예기치 않은 문제를 식별할 수 있습니다. jsnapyjuniper_junos_jsnapy Ansible 모듈을 사용하면 Ansible 플레이북의 일부로 JSNAPy 스냅샷을 생성하고 비교할 수 있습니다. 모듈은 미리 결정된 파일 이름을 사용하여 기본 JSNAPy 스냅샷 디렉토리의 별도 파일에 각 호스트에 대한 각 스냅샷을 저장합니다. 출력 파일에 대한 자세한 정보는 jsnapy 및 juniper_junos_jsnapy 모듈 출력 이해의 내용을 참조하십시오.

변경하기 전에 하나 이상의 디바이스에 대한 기준 스냅샷을 찍으려면 모듈의 action 인수를 snap_pre로 설정하고 구성 파일 또는 하나 이상의 테스트 파일을 지정합니다.

다음 플레이북은 Ansible 인벤토리 그룹의 각 디바이스에 대한 PRE 스냅샷을 저장합니다. 이 작업은 ~/jsnapy/testfiles 디렉터리의 configuration_interface_status.yaml 구성 파일을 참조하고 플레이북 디렉터리의 jsnapy_tests.log 파일에 메시지를 기록합니다.

변경을 수행한 후 하나 이상의 디바이스에 대한 스냅샷을 찍으려면 모듈의 action 인수를 snap_post로 설정하고 구성 파일 또는 하나 이상의 테스트 파일을 지정합니다.

다음 플레이북은 Ansible 인벤토리 그룹의 각 디바이스에 대한 POST 스냅샷을 저장합니다. 이 작업은 ~/jsnapy/testfiles 디렉터리에서 동일한 configuration_interface_status.yaml 구성 파일을 참조하고 플레이북 디렉터리의 jsnapy_tests.log 파일에 메시지를 기록합니다.

또는 모듈이 jsnapy 작업 또는 작업을 수행할 snap_pre 때 각각 'PRE' 또는 juniper_junos_jsnapy snap_post 'POST' 태그가 포함된 자동 생성된 파일 이름을 사용하여 각 호스트에 대한 각 스냅샷을 별도의 파일에 저장합니다. 및 POST 스냅숏을 PRE 비교하여 업데이트를 신속하게 확인하거나 변경으로 인해 발생할 수 있는 문제를 식별하려면 모듈의 action 인수를 check로 설정하고 스냅숏을 만드는 데 사용된 것과 동일한 구성 파일 또는 테스트 파일을 지정합니다.

모듈이 작업을 수행할 check 때 각 디바이스의 각 테스트에 대한 기존 PREPOST 스냅샷이 테스트 파일의 섹션에 정의된 tests: 기준에 따라 비교 및 평가됩니다. 테스트 파일이 테스트 케이스를 정의하지 않는 경우 JSNAPy는 대신 스냅샷을 노드별로 비교합니다. 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 assert 응답의 예상 결과를 확인합니다.

다음 플레이북은 이전에 실행 snap_pre snap_post 된 스냅샷과 Ansible 인벤토리 그룹의 모든 디바이스에 대한 작업을 비교합니다. 결과는 구성 파일에서 참조되는 테스트 파일의 기준을 사용하여 평가됩니다. 플레이북은 모듈의 응답을 ''test_result로 등록하고 모듈을 사용하여 assert 지정된 디바이스에서 모든 테스트를 통과했는지 확인합니다.

플레이북을 실행하면 어설션이 테스트에 실패한 디바이스를 빠르게 식별합니다.

Snapcheck 작업 수행

JSNAPy를 사용하면 JSNAPy 테스트 파일에 지정된 명령 또는 RPC에 대한 스냅샷을 생성하고 테스트 케이스에서 사전 정의된 기준에 따라 스냅샷을 즉시 평가할 수 있습니다. jsnapyjuniper_junos_jsnapy Ansible 모듈을 사용하면 Ansible 플레이북의 일부로 JSNAPy 스냅체크 작업을 수행할 수 있습니다.

스냅숏을 만들고 테스트 파일 섹션의 미리 정의된 기준 tests: 집합에 따라 즉시 평가하려면 모듈의 action 인수 snapcheck를 로 설정하고 구성 파일 또는 하나 이상의 테스트 파일을 지정합니다. 테스트 결과를 확인하려면 모듈의 응답을 등록하고 모듈을 사용하여 assert 응답의 예상 결과를 확인합니다.

예를 들어, Ansible 인벤토리 그룹의 각 디바이스에 대해 다음 플레이북은 테스트 파일의 각 명령 또는 RPC에 대한 별도의 스냅샷을 저장하고, 모듈의 응답을 등록하고, assert 모듈을 사용하여 테스트 파일에 정의된 모든 테스트가 해당 디바이스에 전달되었는지 확인합니다.

jsnapy 및 juniper_junos_jsnapy 모듈 출력 이해

또는 모듈이 , snap_post또는 snapcheck 작업을 수행하면 snap_pre스냅샷을 JSNAPy 스냅샷 디렉토리에 자동으로 저장합니다.juniper_junos_jsnapy jsnapy JSNAPy 구성 파일을 수정하여 다른 위치를 지정하지 않는 한 모듈은 기본 JSNAPy 디렉토리를 사용합니다. 이 모듈은 Ansible 인벤토리 그룹의 각 디바이스에서 실행되는 각 명령 또는 RPC에 대해 별도의 파일을 생성합니다. 표 4에서는 인수의 각 값에 대한 스냅샷 파일의 파일 이름을 간략하게 action 설명합니다.

참고:

Python 릴리스 1.3.0의 Junos Snapshot Administrator부터 JSNAPy 테스트 파일 및 스냅샷의 기본 디렉터리는 각각 ~/jsnapy/testfiles 및 ~/jsnapy/snapshots입니다. 그러나 가상 환경 내부 또는 이전 릴리스의 기본 디렉토리는 /etc/jsnapy/testfiles 및 /etc/jsnapy/snapshots입니다.

표 4: JSNAPy 출력 파일 이름

action

출력 파일

snap_pre

hostname_PRE_hash_command입니다.format

snap_post

hostname_포스트_hash_command.format

snapcheck

hostname_snap_temp_hash_command.format
또는
hostname_PRE_hash_command입니다.format

어디:

  • hostname- 명령 또는 RPC가 실행되는 디바이스의 호스트 이름입니다.

  • (사전 | 게시물 | snap_temp) - 작업을 식별하는 태그입니다. snapcheck 현재 릴리스에서는 작업에 태그가 사용되지만 이전 릴리스에서는 태그가 PRE snap_temp 사용됩니다.

  • hash- 및 kwargs 키를 포함하는 테스트 파일에 대해 생성된 해시 원본 kwargs 입니다rpc.

    테스트 파일이 동일한 RPC를 사용하지만 다른 인수를 포함하고 RPC가 동일한 호스트에서 실행되는 경우 해시는 이러한 경우 고유한 출력 파일 이름을 보장합니다. 테스트 파일이 키를 정의하거나 테스트 파일이 키를 정의 command rpc 하지만 키를 포함하지 kwargs 않는 경우 해시가 생략됩니다.

  • command- 매니지드 디바이스에서 실행되는 명령 또는 RPC. 모듈은 명령 또는 RPC 이름의 공백 및 특수 문자를 밑줄( _ )로 바꿉니다.

  • format- 출력 형식(예: xml)입니다.

참고:

jsnapyjuniper_junos_jsnapy 모듈은 호스트 이름과 명령 또는 RPC에 따라 지정된 작업에 대한 스냅샷 파일 이름만 구별합니다. 따라서 모듈이 동일한 명령 또는 RPC를 정의하는 테스트 파일을 사용하여 동일한 작업에 대해 동일한 디바이스에서 스냅샷을 만드는 경우 모듈은 동일한 파일 이름으로 스냅샷을 생성하고 새 파일은 이전 파일을 덮어씁니다.

예를 들어, 모듈이 디바이스 dc1a.example.net 및 dc1b.example.net 에서 및 show interfaces terse 명령을 실행하는 show chassis fpc 테스트 파일을 포함하고 action: "snap_pre" 참조하는 경우 결과 파일은 다음과 같습니다.

모듈이 디바이스 dc1a.example.net 의 항목 interface_name: lo0 으로 kwargs RPC를 get-interface-information 실행하는 테스트 파일을 포함하고 action: "snap_post" 참조하는 경우 결과 파일은 다음과 같습니다.

스냅샷 파일을 jsnapy 생성하는 것 외에도 및 juniper_junos_jsnapy 모듈은 모듈 응답에서 다음 키를 반환할 수도 있습니다.

  • action—모듈에 의해 수행된 JSNAPy 작업입니다.

  • changed- 디바이스의 상태가 변경되었는지 여부를 나타냅니다. JSNAPy는 상태만 보고하므로 값은 항상 false입니다.

  • failed- 플레이북 작업이 실패했는지 여부를 나타냅니다.

  • msg—JSNAPy 테스트 결과.

jsnapy 콜백 플러그인 활성화

Junos 디바이스에 대해 JSNAPy 테스트를 실행했는데 하나 이상의 테스트가 실패하면 출력이 광범위하면 실패한 테스트를 식별하고 추출하기 어려울 수 있습니다. jsnapy 콜백 플러그인을 사용하면 실패한 JSNAPy 테스트에 대한 정보를 쉽게 추출하고 요약할 수 있습니다. 콜백 플러그인을 활성화 jsnapy 하고 JSNAPy 테스트가 포함된 플레이북을 실행하면 플러그인은 플레이북 PLAY RECAP이후 실패한 JSNAPy 테스트에 대한 정보를 요약합니다.

jsnapy 콜백 플러그인은 기본적으로 활성화되어 있지 않습니다. 콜백 플러그인을 활성화하려면 jsnapy Ansible 구성 파일에 문을 추가합니다callback_whitelist = jsnapy.

콜백 플러그인을 활성화 jsnapy 하고 플레이북을 실행하면 플러그인은 실패한 JSNAPy 테스트를 사람이 읽을 수 있는 형식으로 요약합니다. 예를 들어:

예: Ansible을 사용하여 JSNAPy 스냅 체크 작업 수행

jsnapy 모듈을 사용하면 Ansible 플레이북의 일부로 Junos 디바이스에 대해 JSNAPy 테스트를 실행할 수 있습니다. 이 예제에서는 모듈을 사용하여 jsnapy 특정 구성 변경을 적용한 후 Junos 디바이스의 작동 상태를 확인하는 작업을 수행합니다 snapcheck .

요구 사항

이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.

  • 실행 중인 Ansible 제어 노드:

    • Python 3.7 이상

    • 컬렉션이 juniper.device 설치된 Ansible 2.10 이상

    • Junos PyEZ 릴리스 2.6.0 이상

    • Python 릴리스 1.3.6 이상의 Junos Snapshot Administrator

Ansible 플레이북을 실행하기 전에 다음을 확인하십시오.

  • SSH를 통한 NETCONF가 활성화되고 적절한 권한으로 구성된 사용자 계정이 있는 Junos 디바이스

  • Ansible 제어 노드 및 Junos 디바이스에서 해당 사용자에 대해 구성된 SSH 퍼블릭/프라이빗 키 쌍

  • 필수 호스트가 정의된 기존 Ansible 인벤토리 파일

개요

이 예에서 Ansible 플레이북은 3개의 Junos 디바이스에서 BGP 피어링 세션을 구성하고 모듈을 사용하여 jsnapy BGP 세션이 각 neighbor 주소에 대해 설정되었는지 확인합니다. 플레이북이 디바이스에 세션이 설정되었음을 확인하면 새 구성에 대한 커밋을 확인합니다. 플레이북이 커밋을 확인하지 않으면 Junos 디바이스는 이전에 커밋된 구성으로 자동 롤백합니다. Ansible 프로젝트는 및 디렉토리 아래에서 group_vars 플레이북에 대한 그룹 및 host_vars 호스트 변수를 각각 정의합니다.

플레이 북에는 두 가지 연극이 있습니다. 첫 번째 플레이인 Load and commit BGP configuration은(는) 구성을 생성 및 어셈블하고, 디바이스에 구성을 로드하고, 커밋 확인 작업을 사용하여 커밋합니다. 구성이 업데이트되면 하나의 처리기에 알림이 전송됩니다. 연극은 다음 작업을 실행합니다.

Remove build directory

지정된 장치에 대한 기존 빌드 디렉터리(있는 경우)를 삭제합니다.

Create build directory

지정된 장치에 대해 비어 있는 새 빌드 디렉터리를 만듭니다.

Build BGP configuration

template 모듈을 Jinja2 템플릿 및 호스트 변수와 함께 사용하여 지정된 디바이스에 대한 BGP 구성을 렌더링하고 디바이스의 빌드 디렉터리에 있는 파일에 저장합니다.

Assemble configuration parts

assemble 모듈을 사용하여 해당 장치의 빌드 디렉터리에 있는 파일에서 장치 구성 파일을 어셈블합니다.

이 예에서는 BGP 구성 파일만 존재하므로 결과 구성 파일은 이전 작업에서 렌더링된 BGP 구성 파일과 동일합니다. 나중에 새 작업을 추가하여 다른 템플릿 assemble 에서 추가 구성 파일을 생성하는 경우 모듈은 모든 파일을 단일 구성으로 결합합니다.

Load and commit config, require confirmation

Junos 디바이스에 구성을 로드하고 작업을 사용하여 commit confirmed 구성을 커밋합니다. 커밋이 영구적이 되기 위해서는 명시적인 확인이 필요합니다. 이 작업으로 구성이 변경되면 두 번째 재생이 실행되기 전에 BGP 피어가 연결을 설정할 수 있도록 지정된 시간 동안 플레이북 실행을 일시 중지하는 핸들러에도 알립니다.

요청된 구성이 디바이스에 이미 존재하는 경우, config 모듈은 구성을 로드 및 커밋하지 않습니다. 이 경우 모듈은 를 반환 changed: false하므로 처리기에 알리지 않습니다.

두 번째 재생 Verify BGP인 은(는) JSNAPy 테스트 파일의 테스트를 사용하여 각 디바이스에서 JSNAPy snapcheck 작업을 수행하고 모든 테스트가 통과하는 경우 커밋을 확인합니다. 연극은 다음 작업을 실행합니다.

Execute snapcheck

JSNAPy snapcheck 작업을 수행합니다. 이 경우 디바이스의 각 인접 라우터에 대해 BGP 세션이 설정되었고 다운 피어가 없는지 검증합니다.

이 예에서 플레이북은 인수를 test_files JSNAPy 테스트 파일 목록과 동일하게 설정하여 JSNAPy 테스트 파일을 직접 참조합니다. 인수는 dir 테스트 파일이 저장되는 디렉터리를 지정합니다.

Confirm commit

첫 번째 플레이북 플레이가 구성을 업데이트하고 모든 JSNAPy 테스트를 통과한 경우 이전 커밋 작업을 확인하는 커밋 검사 작업을 실행합니다. 플레이북이 구성을 업데이트하지만 커밋을 확인하지 않는 경우, Junos 디바이스는 자동으로 구성을 이전에 커밋된 구성으로 롤백합니다.

참고:

모듈에서 각각 config 또는 인수에 check: true 해당하는 디바이스의 또는 commit commit: true 작업을 통해 commit check 이전 커밋 작업을 확인할 수 있습니다.

Verify BGP configuration

(선택 사항) 지정된 디바이스에서 JSNAPy 테스트가 통과 또는 실패했는지 여부를 명시적으로 나타냅니다. 이 작업은 특별히 필요하지는 않지만 JSNAPy 테스트가 실패하는 시기와 어떤 장치에서 실패하는지 보다 쉽게 식별할 수 있습니다.

구성

그룹 변수 정의

단계별 절차

그룹 변수를 정의하려면 다음을 수행합니다.

  • group_vars/all 파일에서 빌드 디렉터리에 대한 변수와 구성 및 로그 파일의 파일 이름에 대한 변수를 정의합니다.

Jinja2 템플릿 및 호스트 변수 정의

Jinja2 템플릿 정의

BGP 구성을 생성하는 데 사용되는 Jinja2 템플릿을 생성하려면 다음을 수행합니다.

  1. 프로젝트의 플레이북 디렉터리에 bgp-template.j2 라는 파일을 만듭니다.

  2. BGP 구성 템플릿을 파일에 추가합니다.

호스트 변수 정의

BGP 구성을 생성하기 위해 Jinja2 템플릿과 함께 사용되는 호스트 변수를 정의하려면 다음을 수행합니다.

  1. 프로젝트의 host_vars 디렉터리에서 각 호스트에 대해 .yaml이라는 별도의 파일을 hostname만듭니다.

  2. r1.yaml 파일에서 호스트 r1에 대한 변수를 정의합니다.

  3. r2.yaml 파일에서 호스트 r2에 대한 변수를 정의합니다.

  4. r3.yaml 파일에서 호스트 r3에 대한 변수를 정의합니다.

JSNAPy 테스트 파일 만들기

단계별 절차

jsnapy 모듈은 ~/jsnapy/testfiles 디렉토리의 JSNAPy 테스트 파일을 참조합니다. JSNAPy 테스트 파일을 생성하려면 다음을 수행합니다.

  1. 명령을 실행하고 show bgp neighbor BGP 피어 상태가 설정되었는지 테스트하는 jsnapy_test_file_bgp_states.yaml 파일을 생성합니다.

  2. 명령을 실행하고 show bgp summary BGP 다운 피어 수가 0이어야 한다고 어설션하는 jsnapy_test_file_bgp_summary.yaml 파일을 생성합니다.

Ansible 플레이북 생성

장치를 구성하기 위한 첫 번째 재생 정의

구성을 렌더링하고, 디바이스에 로드하고, 커밋 확인 작업으로 구성을 커밋하는 첫 번째 플레이를 생성하려면 다음을 수행합니다.

  1. 플레이북에 대한 상용구와 모듈을 로컬에서 실행하는 첫 번째 플레이를 포함합니다.

  2. 기존 빌드 디렉터리를 새 구성 파일을 저장할 빈 디렉터리로 바꾸는 작업을 만듭니다.

  3. Jinja2 템플릿 파일 및 호스트 변수에서 BGP 구성을 렌더링하고 해당 호스트의 빌드 디렉터리에 있는 bgp.conf 파일에 저장하는 작업을 생성합니다.

  4. build 디렉터리의 구성 파일을 최종 junos.conf 구성 파일로 어셈블하는 작업을 생성합니다.

  5. 디바이스에 구성을 로드하고, 확인이 필요한 커밋 작업을 수행하며, 구성이 변경된 경우 지정된 핸들러에 알리는 작업을 생성합니다.

  6. 디바이스 구성이 업데이트되면 플레이북 실행을 일시 중지하는 처리기를 만들고 일시 중지 시간을 사용자 환경에 적합한 값으로 설정합니다.

JSNAPy 작업을 수행하기 위한 두 번째 재생 정의

구성이 변경되고 JSNAPy 테스트를 통과한 경우 JSNAPy 스냅체크 작업을 수행하고 커밋된 구성을 확인하는 두 번째 플레이를 만들려면 다음을 수행합니다.

  1. 모듈을 로컬에서 실행하는 두 번째 플레이에 대한 상용구를 포함합니다.

  2. 지정된 JSNAPy 테스트 파일의 테스트를 기반으로 JSNAPy 스냅 검사 작업을 수행하는 작업을 만들고 모듈의 응답을 등록합니다.

  3. 지정된 조건이 충족되는 경우 커밋을 확인하는 작업을 생성합니다.

  4. (선택 사항) 모듈을 사용하여 assert JSNAPy 테스트를 통과했음을 어설션하는 작업을 만듭니다.

결과

Ansible 제어 노드에서 완료된 플레이북을 검토합니다. 플레이북에 의도한 코드가 표시되지 않으면 이 섹션의 지침을 반복하여 플레이북을 수정합니다.

플레이북 실행

플레이북을 실행하려면:

  • ansible-playbook 제어 노드에서 명령을 실행하고 플레이북 경로와 원하는 옵션을 제공합니다.

확인

BGP 인접 라우터 확인

목적

각 neighbor 주소에 대해 BGP 세션이 설정되었는지 확인합니다.

JSNAPy 테스트 파일은 BGP 세션이 각 neighbor 주소에 대해 설정되고 다운 피어가 없는지 테스트합니다. Verify BGP configuration 작업 출력을 통해 지정된 디바이스가 모든 JSNAPy 테스트를 통과했는지 신속하게 확인할 수 있습니다. JSNAPy passPercentage 가 100%와 같으면 태스크가 태스크 출력에 포함됩니다 "msg": "All assertions passed" .

작업

Verify BGP configuration 작업 출력을 검토하고 각 디바이스가 메시지를 반환 All assertions passed 하는지 확인합니다.

의미

All assertions passed 메시지는 BGP 세션이 디바이스에 성공적으로 설정되었음을 나타냅니다.

Ansible 플레이북 오류 문제 해결

구성 로드 오류 문제 해결

문제

Ansible 플레이북은 구문 오류로 인해 디바이스에서 구성을 로드하지 못했음을 나타내는 오류를 생성합니다 ConfigLoadError .

솔루션

플레이북은 Jinja2 템플릿과 host_vars 디렉터리에서 해당 디바이스에 대해 정의된 호스트 변수를 사용하여 Junos OS 구성을 렌더링합니다. 플레이북은 Jinja2 템플릿이 잘못된 구성을 생성할 때 구문 오류를 생성합니다. 이 오류를 수정하려면 Jinja2 템플릿을 업데이트하여 오류 메시지에서 키로 식별된 bad_element 요소를 수정합니다.

실패한 JSNAPy 테스트 문제 해결

문제

태스크 출력은 Verify BGP configuration JSNAPy passPercentage 가 100%가 아니기 때문에 어설션이 실패했음을 나타냅니다.

디바이스가 인접 라우터와 BGP 세션을 설정하지 않았거나 세션이 중단되면 어설션이 실패합니다. 어설션이 실패하고 해당 디바이스에 대한 구성이 첫 번째 플레이에서 업데이트된 경우, 플레이북은 디바이스의 새 구성에 대한 커밋을 확인하지 않고 디바이스는 구성을 이전에 커밋된 구성으로 롤백합니다.

솔루션

피어가 세션을 설정하기 전에 작업이 수행되거나 BGP 인접 라우터가 올바르게 구성되지 않아 JSNAPy 테스트가 실패할 snapcheck 수 있습니다. 플레이북 출력에 구성이 디바이스에 성공적으로 로드되고 커밋되었음을 나타내는 경우 핸들러의 일시 중지 간격을 환경에 적합한 값으로 늘리고 플레이북을 다시 실행해 보십시오.

테스트가 계속 실패하는 경우, 각 디바이스에 대한 Jinja2 템플릿 및 호스트 변수에 올바른 데이터가 포함되어 있는지, 그리고 각 디바이스에 대한 결과 구성이 올바른지 확인하십시오.

커밋 확인 실패 문제 해결

문제

하나 이상의 장치에서 구성이 확인되지 않았습니다.

솔루션

플레이북은 구성이 변경되고 JSNAPy 테스트를 통과한 경우에만 구성을 확인합니다. 작업 출력에 Load and commit config, require confirmation 구성이 변경되지 않은 것으로 표시되면 플레이북은 커밋을 확인하는 작업을 실행하지 않습니다. 구성이 변경되었지만 확인되지 않은 경우 JSNAPy 테스트가 실패했습니다. BGP 인접 항목이 올바르게 구성되지 않았거나 플레이북이 디바이스가 BGP 세션을 설정할 수 있도록 플레이 사이에 충분한 시간을 제공하지 않는 경우 JSNAPy 테스트가 실패할 수 있습니다. 자세한 내용은 실패한 JSNAPy 테스트 문제 해결을 참조하십시오.

릴리스 기록 테이블
릴리스
설명
2.0.0
릴리스 2.0.0 juniper_junos_jsnapy 부터 Juniper.junos 모듈은 모듈의 기능을 대체합니다 junos_jsnapy.