Ansible을 사용하여 Junos 디바이스 구성
요약 주니퍼 네트웍스 Ansible 모듈을 사용하여 Junos 디바이스의 구성을 관리합니다.
주니퍼 네트웍스는 Junos 디바이스를 구성할 수 있는 Ansible 모듈을 제공합니다. 표 1 에는 사용 가능한 모듈이 요약되어 있습니다. 구성을 변경하는 데 사용되는 사용자 계정에는 각 디바이스에서 구성의 관련 부분을 변경할 수 있는 권한이 있어야 합니다.
콘텐츠 집합 |
모듈 이름 |
---|---|
릴리스 2.0.0부터 모듈은 , junos_install_config
junos_get_config
, 및 모듈의 기능을 junos_commit
결합하고 대체합니다junos_rollback
.Juniper.junos
juniper_junos_config
다음 섹션에서는 모듈을 사용하여 Junos 디바이스에서 구성을 수정 및 커밋하는 방법에 대해 설명합니다.
모듈 개요
config
및 juniper_junos_config
모듈을 사용하면 Junos 디바이스에서 다음 작업을 수행할 수 있습니다.
-
구성 데이터 로드
-
구성 커밋
-
구성 롤백
-
복구 구성 불러오기
구성을 수정하려면 모듈의 인수 목록에 새 구성 데이터를 로드하기 위한 매개 변수 또는 rollback
복구 구성 또는 이전에 커밋된 구성으로 되돌리기 위한 매개 변수가 포함되어야 load
합니다. 구성을 변경하기 위한 기본 프로세스는 구성을 잠그고, 구성 변경 사항을 로드하고, 구성을 커밋하여 활성화한 다음, 구성을 잠금 해제하는 것입니다.
기본적으로, config
및 juniper_junos_config
모듈은 모드를 사용하여 configure exclusive
후보 구성 데이터베이스를 변경하며, 이는 후보 글로벌 구성을 자동으로 잠그고 잠금 해제합니다. 후보 구성의 개인 복사본을 변경할 수도 있습니다. 구성 모드 지정에 대한 자세한 내용은 구성 모드 지정 방법을 참조하십시오.
새 구성 데이터를 로드할 때 구성 모드를 지정하는 것 외에도 로드 작업과 변경의 소스 및 형식을 지정할 수도 있습니다.
-
로드 작업 - 로드 작업은 구성 데이터가 후보 구성에 로드되는 방식을 결정합니다. 이 기능은 Junos OS CLI에서 사용할 수 있는 것과 동일한 로드 작업을 다수 지원합니다. 자세한 내용은 Load 동작을 지정하는 방법을 참조하십시오.
-
형식 - 지원되는 표준 형식 중 하나를 사용하여 Junos 디바이스를 구성할 수 있습니다. 구성 데이터 또는 Jinja2 템플릿을 텍스트, Junos XML 요소, Junos OS
set
명령 또는 JSON으로 제공할 수 있습니다. 구성 데이터의 형식을 지정하는 방법에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. -
구성 데이터 소스 - , , 또는
url
매개 변수를 각각 포함하여template
lines
src
문자열 목록, 로컬 Ansible 제어 노드의 파일, Jinja2 템플릿 또는 클라이언트 디바이스에서 연결할 수 있는 URL에서 구성 데이터를 로드할 수 있습니다. 구성 데이터의 소스 지정에 대한 자세한 내용은 다음 섹션을 참조하십시오.
config
또한 및 juniper_junos_config
모듈을 사용하여 복구 구성을 로드 및 커밋하거나 구성을 이전에 커밋한 구성으로 롤백할 수 있습니다. 복구 구성 또는 이전에 커밋된 구성을 로드하려면 module 인수를 rollback
포함해야 합니다. 자세한 내용은 다음 섹션을 참조하세요.
구성을 수정한 후에는 구성을 커밋하여 디바이스에서 활성 구성으로 만들어야 합니다. 기본적으로 config
및 juniper_junos_config
모듈은 구성에 대한 변경 사항을 커밋합니다. 이 동작을 변경하거나 추가 커밋 옵션을 제공하려면 구성을 커밋하는 방법을 참조하십시오.
기본적으로 또는 juniper_junos_config
모듈에 config
구성을 변경하기 위한 또는 rollback
인수가 포함되어 load
있으면 모듈은 모듈의 응답에서 diff 또는 patch 형식의 구성 변경 사항을 자동으로 반환합니다. 차이점은 및 diff_lines
변수에 반환됩니다diff
. 모듈이 차이를 계산하고 반환하지 않도록 하려면 module 인수를 diff
로 false
설정합니다.
구성 모드 지정 방법
후보 구성 데이터베이스를 수정할 때 사용할 구성 모드를 지정할 수 있습니다. 기본적으로 및 juniper_junos_config
모듈은 config
모드를 사용하여 configure exclusive
후보 구성 데이터베이스를 변경합니다. 배타적 모드 구성은 모듈이 구성에 대해 요청된 변경을 수행해야 하는 한 후보 전역 구성(공유 구성 데이터베이스라고도 함)을 잠급니다. 데이터베이스를 잠그면 잠금이 해제될 때까지 다른 사용자가 데이터베이스의 변경 내용을 수정하거나 커밋할 수 없습니다.
모드를 지정하려면 모듈의 인수 목록에 매개 변수를 포함합니다config_mode
. 지원되는 모드에는 및 가 private
포함됩니다exclusive
. 두 모드 모두 종료 시 커밋되지 않은 변경 사항을 삭제합니다.
다음 플레이북은 모드를 사용하여 configure private
구성을 수정합니다.
--- - name: "Configure Device" hosts: dc1 connection: local gather_facts: no tasks: - name: "Configure op script" juniper.device.config: config_mode: "private" load: "set" lines: - "set system scripts op file bgp.slax" register: response - name: "Print the config changes" debug: var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configure-script.yaml PLAY [Configure Device] ******************************************************* TASK [Configure op script] **************************************************** changed: [dc1a.example.net] TASK [Print the config changes] *********************************************** ok: [dc1a.example.net] => { "response.diff_lines": [ "", "[edit system scripts op]", "+ file bgp.slax;" ] } PLAY RECAP ******************************************************************** dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
로드 동작을 지정하는 방법
config
및 juniper_junos_config
모듈은 Junos OS CLI에서 지원되는 것과 동일한 로드 작업을 사용하여 구성 변경 로드를 지원합니다. 모듈의 인수 목록에 매개 변수를 포함하고 load
이를 해당 로드 작업의 값으로 설정하여 로드 작업을 지정합니다. 표 2에는 각 부하 작업 유형에 필요한 매개변수 설정이 요약되어 있습니다.
로드 작업 |
load 인수 |
묘사 |
---|---|---|
|
|
로드된 구성을 기존 구성과 병합합니다. |
|
|
전체 구성을 로드된 구성으로 대체합니다. |
|
|
로드된 구성을 기존 구성과 병합하되, 기존 구성의 문을 로드된 구성의 태그를 지정하는 |
|
|
패치 파일에서 구성 데이터를 로드합니다. |
|
|
형식의 구성 데이터를 로드합니다 |
|
|
전체 로드된 구성을 기존 구성과 비교합니다. 로드된 구성에서 다른 각 구성 요소는 기존 구성에서 해당 요소를 대체합니다. 커밋 작업 중에는 변경된 구성 요소의 영향을 받는 시스템 프로세스만 새 구성을 구문 분석합니다. |
로드할 구성 데이터의 형식을 지정하는 방법
config
및 juniper_junos_config
모듈을 사용하면 지원되는 표준 형식 중 하나를 사용하여 Junos 디바이스를 구성할 수 있습니다. 구성 데이터를 문자열 또는 파일로 제공할 수 있습니다. 파일에는 구성 데이터 또는 Jinja2 템플릿이 포함될 수 있습니다. 문자열, 파일 또는 Jinja2 템플릿 내에서 구성 데이터를 제공할 때 텍스트, Junos XML 요소, Junos OS set
명령 및 JSON이 데이터에 대해 지원되는 형식입니다.
Junos OS 릴리스 16.1R1부터 Junos 디바이스는 JSON 형식의 구성 데이터 로드를 지원합니다.
config
및 juniper_junos_config
모듈은 인수를 사용하여 문자열로 제공되는 구성 데이터의 형식을 자동 감지하려고 lines
시도합니다. 그러나 인수를 포함하여 문자열의 형식을 명시적으로 지정할 수 있습니다format
. 파일 또는 Jinja2 템플릿에 구성 데이터를 제공할 때 파일에 적절한 확장자를 추가하거나 인수를 format
포함하여 데이터 형식을 지정해야 합니다.
표 3 에는 구성 데이터에 대해 지원되는 형식과 파일 확장자 및 format
매개 변수에 대한 해당 값이 요약되어 있습니다. 인수를 format
포함하면 문자열에 대한 자동 검색 형식과 파일 확장명으로 표시된 형식이 모두 재정의됩니다.
구성 데이터 형식 |
파일 확장자 |
format 매개 변수 |
---|---|---|
CLI 구성 문(텍스트) |
.conf |
" |
JSON(JavaScript Object Notation) |
.json |
" |
Junos OS |
.집합 |
" |
Junos XML 요소 |
.xml |
" |
모듈의 load
인수를 또는 'update'
로 설정하면 Junos OS set
명령 형식을 'override'
사용할 수 없습니다.
구성 데이터를 문자열로 로드하는 방법
config
및 juniper_junos_config
모듈을 사용하면 문자열 목록에서 구성 데이터를 로드할 수 있습니다. 구성 데이터를 문자열로 로드하려면 적절한 load
인수와 인수를 lines
포함합니다. 인수는 lines
로드할 구성 데이터가 포함된 문자열 목록을 사용합니다.
모듈은 구성 데이터의 형식을 lines
자동 감지하려고 시도합니다. 그러나 인수를 포함하여 형식을 명시적으로 지정할 수 있습니다 format
. 형식 지정에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. 모듈의 인수 목록에 매개 변수를 포함 format
하면 자동 검색 형식이 재정의됩니다.
다음 플레이북은 두 개의 op 스크립트를 구성하고 커밋합니다. 이 경우, load
의 구성 데이터가 lines
Junos OS set
명령문 형식을 사용하기 때문에 인수는 값을 'set'
갖습니다.
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration data using strings and commit" juniper.device.config: load: "set" lines: - "set system scripts op file bgp.slax" - "set system scripts op file bgp-neighbor.slax" register: response - name: "Print the response" debug: var: response
다음 플레이북은 텍스트 형식의 구성 데이터와 함께 사용하여 lines
동일한 문을 구성합니다. 이 경우 이 load: "merge"
사용됩니다.
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration data using strings and commit" juniper.device.config: load: "merge" lines: - | system { scripts { op { file bgp.slax; file bgp-neighbor.slax; } } } register: response - name: "Print the response" debug: var: response
로컬 또는 원격 파일에서 구성 데이터를 로드하는 방법
config
및 juniper_junos_config
모듈을 사용하면 파일에서 구성 데이터를 로드할 수 있습니다. 파일은 다음 위치 중 하나에 상주할 수 있습니다.
-
Ansible 제어 노드
-
클라이언트 장치
-
클라이언트 디바이스에서 연결할 수 있는 URL
파일에서 구성 데이터를 로드할 때 파일에 있는 구성 데이터의 형식과 파일의 위치를 나타내야 합니다. 지원되는 구성 데이터 형식에는 텍스트, Junos XML 요소, Junos OS set
명령 및 JSON이 포함됩니다. Jinja2 템플릿이 포함된 파일을 로드하는 방법에 대한 자세한 내용은 Jinja2 템플릿을 사용하여 구성 데이터를 로드하는 방법을 참조하십시오.
모듈의 인수 목록에 매개 변수를 명시적으로 포함 format
하거나 구성 데이터 파일에 적절한 확장명을 추가하여 구성 데이터의 형식을 지정할 수 있습니다. 매개 변수를 지정하면 format
파일 확장명이 나타내는 형식보다 우선합니다. 형식 지정에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. 구성 데이터가 Junos XML 형식을 사용하는 경우 데이터를 최상위 <configuration>
태그로 둘러싸야 합니다.
NETCONF 세션 내에서 직접 디바이스를 구성할 때 필요에 따라 ASCII 텍스트, Junos OS set
명령 또는 JSON <configuration-text>
, <configuration-set>
또는 <configuration-json>
태그로 포맷된 구성 데이터를 동봉할 필요가 없습니다.
표 4 에서는 파일의 위치를 지정하기 위해 포함할 수 있는 모듈 매개변수를 간략하게 설명합니다.
모듈 매개 변수 |
묘사 |
---|---|
|
Ansible 제어 노드에 있는 파일의 절대 또는 상대 경로입니다. 기본 디렉토리는 플레이북 디렉토리입니다. |
|
클라이언트 디바이스, FTP 위치 또는 HTTP(Hypertext Transfer Protocol) URL에 있는 파일에 대한 절대 또는 상대 경로입니다. 클라이언트 디바이스의 기본 디렉터리는 현재 작업 디렉터리이며, 기본값은 사용자의 홈 디렉터리입니다. |
Ansible 제어 노드의 로컬 파일에서 구성 데이터를 로드하려면 인수를 src
구성 데이터가 포함된 파일의 절대 또는 상대 경로로 설정합니다. 예를 들어:
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration from a local file and commit" juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos.conf" register: response - name: "Print the response" debug: var: response
관리되는 Junos 디바이스의 파일 또는 FTP 또는 HTTP URL에서 구성 데이터를 로드하려면 매개 변수를 사용하고 url
로드할 구성 데이터가 포함된 파일의 경로를 지정합니다. 예를 들어:
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration from a remote file and commit" juniper.device.config: load: "merge" url: "/var/tmp/junos.conf" register: response - name: "Print the response" debug: var: response
의 url
값은 절대 또는 상대 로컬 파일 경로, FTP 위치 또는 HTTP(Hypertext Transfer Protocol) URL일 수 있습니다.
-
로컬 파일 이름은 다음 형식 중 하나일 수 있습니다.
-
/path/filename—로컬 플래시 디스크 또는 하드 디스크에 마운트된 파일 시스템의 파일입니다.
-
ᅡ:filename 또는 a:path/filename—로컬 드라이브의 파일입니다. 기본 경로는 /(루트 수준 디렉터리)입니다. 이동식 미디어는 MS-DOS 또는 UNIX(UFS) 형식일 수 있습니다.
-
-
FTP 서버에 있는 파일의 파일 이름은 다음과 같은 형식입니다.
ftp://username:password@hostname/path/filename
-
HTTP 서버에 있는 파일의 파일 이름은 다음과 같은 형식입니다.
http://username:password@hostname/path/filename
각각의 경우, 변수의 기본값은 path 사용자의 홈 디렉토리입니다. 절대 경로를 지정하기 위해 응용 프로그램은 %2F 문자로 경로를 시작합니다. 예를 들면 ftp://username:password@hostname/%2Fpath/filename와 같습니다.
Jinja2 템플릿을 사용하여 구성 데이터를 로드하는 방법
config
및 juniper_junos_config
모듈을 사용하면 Ansible 제어 노드의 Jinja2 템플릿 파일에서 구성 데이터를 렌더링하고 Junos 디바이스에서 구성을 로드 및 커밋할 수 있습니다. Jinja는 사전 정의된 템플릿에서 문서를 생성할 수 있는 Python용 템플릿 엔진입니다. 원하는 언어로 된 텍스트 파일인 템플릿은 표현식과 변수를 사용하여 유연성을 제공합니다. ASCII 텍스트, Junos XML 요소, Junos OS 명령 및 JSON을 포함하는 지원되는 구성 형식 중 하나로 Jinja2 템플릿을 사용하여 Junos OS set
구성 데이터를 생성할 수 있습니다. Ansible 모듈은 Jinja2 템플릿과 제공된 변수 사전을 사용하여 구성 데이터를 렌더링합니다.
Jinja2 템플릿을 사용하여 구성 데이터를 로드하고 커밋하려면 모듈의 인수 목록에 및 vars
매개 변수를 포함합니다template
.
-
template
- Jinja2 템플릿 파일의 경로 -
vars
- Jinja2 템플릿을 렌더링하는 데 필요한 키 및 값 사전
템플릿의 파일 확장명이 format
데이터 형식을 나타내지 않는 경우에도 매개 변수를 포함해야 합니다. 형식 지정에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오.
예를 들어 interfaces-mpls.j2 파일에는 다음과 같은 Jinja2 템플릿이 포함되어 있습니다.
interfaces { {% for item in interfaces %} {{ item }} { description "{{ description }}"; unit 0 { family {{ family }}; } } {% endfor %} } protocols { mpls { {% for item in interfaces %} interface {{ item }}; {% endfor %} } rsvp { {% for item in interfaces %} interface {{ item }}; {% endfor %} } }
또는 juniper_junos_config
모듈을 사용하여 config
Jinja2 템플릿을 로드하려면 인수를 template
템플릿 파일의 경로로 설정하고 사전에서 템플릿 vars
에 필요한 변수를 정의합니다. 다음 플레이북은 Jinja2 템플릿과 에 vars
정의된 변수를 사용하여 구성 데이터를 렌더링하고 대상 호스트에서 로드 및 커밋합니다. 매개변수는 format
템플릿 파일에 있는 구성 데이터의 형식을 나타냅니다.
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load a configuration from a Jinja2 template and commit" juniper.device.config: load: "merge" template: "build_conf/templates/interfaces-mpls.j2" format: "text" vars: interfaces: ["ge-1/0/1", "ge-1/0/2", "ge-1/0/3"] description: "MPLS interface" family: "mpls" register: response - name: "Print the response" debug: var: response
모듈은 다음과 같은 구성 데이터를 생성하며, 이 데이터는 디바이스의 후보 구성에 로드되어 커밋됩니다.
interfaces { ge-1/0/1 { description "MPLS interface"; unit 0 { family mpls; } } ge-1/0/2 { description "MPLS interface"; unit 0 { family mpls; } } ge-1/0/3 { description "MPLS interface"; unit 0 { family mpls; } } } protocols { mpls { interface ge-1/0/1; interface ge-1/0/2; interface ge-1/0/3; } rsvp { interface ge-1/0/1; interface ge-1/0/2; interface ge-1/0/3; } }
복구 구성을 로드하는 방법
복구 구성을 사용하면 알려진 작동 구성 또는 언제든지 복원할 수 있는 알려진 상태의 구성을 정의할 수 있습니다. 알려진 구성으로 되돌려야 할 때 또는 디바이스 구성 및 백업 구성 파일이 복구할 수 없을 정도로 손상된 경우 최후의 수단으로 복구 구성을 사용합니다. 복구 구성을 생성하면 디바이스는 가장 최근에 커밋된 구성을 복구 구성으로 저장합니다.
config
및 juniper_junos_config
모듈을 사용하면 Junos 디바이스의 기존 복구 구성으로 되돌릴 수 있습니다. 디바이스에서 복구 구성을 로드하고 커밋하려면 모듈의 rollback: "rescue"
인수를 포함합니다. 예를 들어:
--- - name: "Revert to rescue configuration" hosts: dc1a connection: local gather_facts: no tasks: - name: "Load and commit rescue configuration" juniper.device.config: rollback: "rescue" register: response - name: "Print response" debug: var: response
구성을 롤백하는 방법
Junos 디바이스는 플랫폼에 따라 가장 최근에 커밋된 구성의 사본과 최대 49개의 이전 구성을 저장합니다. 저장된 구성으로 롤백할 수 있습니다. 이는 구성 변경으로 인해 바람직하지 않은 결과가 발생하고 알려진 작업 구성으로 되돌리려는 경우에 유용합니다. 구성 롤백은 디바이스에서 구성을 변경하는 프로세스와 유사하지만, 구성 데이터를 로드하는 대신 전체 후보 구성을 이전에 커밋된 구성으로 대체하는 롤백을 수행합니다.
config
및 juniper_junos_config
모듈을 사용하면 Junos 디바이스에서 이전에 커밋된 구성으로 롤백할 수 있습니다. 구성을 롤백하고 커밋하려면 모듈의 rollback
인수를 포함하고 롤백 구성의 ID를 지정합니다. 유효한 ID 값은 0(가장 최근에 커밋된 구성의 경우 0)에서 저장된 이전 구성 수(최대 49개)보다 1이 적은 값입니다.
다음 플레이북은 복원할 구성의 롤백 ID를 묻는 메시지를 표시하고, 구성을 롤백하고 커밋한 다음, 구성 변경 사항을 표준 출력으로 출력합니다.
--- - name: "Roll back the configuration" hosts: dc1a connection: local gather_facts: no vars_prompt: - name: "ROLLBACK" prompt: "Rollback ID of the configuration to restore" private: no tasks: - name: "Roll back the configuration and commit" juniper.device.config: rollback: "{{ ROLLBACK }}" register: response - name: "Print the configuration changes" debug: var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configuration-rollback.yaml Rollback ID of the configuration to restore: 1 PLAY [Roll back the configuration] ******************************************** TASK [Roll back the configuration and commit] ********************************* changed: [dc1a.example.net] TASK [Print the configuration changes] *************************************** ok: [dc1a.example.net] => { "response.diff_lines": [ "", "[edit interfaces]", "- ge-0/0/0 {", "- unit 0 {", "- family mpls;", "- }", "- }" ] } PLAY RECAP ******************************************************************** dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
구성을 커밋하는 방법
기본적으로 또는 juniper_junos_config
모듈을 사용하여 config
또는 rollback
인수를 사용하여 load
구성을 수정하면 모듈이 자동으로 커밋 검사를 수행하고 변경 사항을 커밋합니다. 모듈이 커밋 검사를 수행하거나 변경 사항을 커밋하지 않도록 하려면 또는 commit
인수false
를 check
각각 로 설정합니다.
또한 Junos OS CLI에서 사용할 수 있는 것과 동일한 여러 옵션을 사용하여 커밋 작업을 사용자 지정할 수도 있습니다. 표 5 에는 다양한 커밋 옵션을 지정하는 데 사용할 수 있는 모듈 인수가 요약되어 있습니다.
모듈 인수 |
묘사 |
및 |
---|---|---|
|
커밋 검사를 수행하거나 이전에 확인된 커밋 작업을 확인합니다. |
|
|
커밋 확인과 커밋 작업 사이에 지정된 시간(초)을 대기합니다. |
– |
|
해당 커밋 작업에 대한 코멘트를 시스템 로그 파일과 디바이스의 커밋 기록에 기록합니다. |
– |
|
구성 변경 사항을 커밋하거나 이전에 확인된 커밋 작업을 확인합니다. |
|
|
후보 구성과 커밋된 구성 간에 차이가 없더라도 구성 변경을 커밋합니다. |
|
|
커밋 작업은 초기 커밋 후 지정된 시간 내에 확인되어야 합니다. 그렇지 않으면 이전에 커밋한 구성으로 롤백합니다.
|
– |
구성을 커밋할 때 커밋된 변경 사항의 목적을 설명하는 간단한 코멘트를 포함할 수 있습니다. 변경 내용을 설명하는 주석을 기록하려면 메시지 문자열과 comment: "comment string"
함께 인수를 포함합니다.
기본적으로 및 juniper_junos_config
모듈은 config
커밋 검사와 커밋 작업을 모두 실행합니다. 인수는 check_commit_wait
커밋 확인과 커밋 작업 사이에 대기하는 시간(초)을 정의합니다. 디바이스가 커밋 확인 작업을 완료하고 커밋 작업을 시작하기 전에 구성 잠금을 해제할 수 있는 충분한 시간을 제공해야 하는 경우 이 인수를 포함합니다. 이 인수를 생략하면 커밋 확인 작업이 구성에 대한 잠금을 해제하기 전에 디바이스가 커밋 작업을 시작하여 커밋 작업이 실패하는 CommitError
특정 상황이 발생할 수 있습니다.
기본적으로 후보 구성과 커밋된 구성 간에 차이가 없는 경우 모듈은 변경 사항을 커밋하지 않습니다. 차이가 없는 경우에도 커밋 작업을 강제 적용하려면 인수를 commit_empty_changes: true
포함합니다.
초기 커밋 후 지정된 시간 내에 커밋 작업을 확인하도록 요구하려면 인수를 confirmed: minutes
포함합니다. 지정된 제한 시간 내에 커밋이 확인되지 않으면 구성은 이전에 커밋된 구성으로 자동 롤백됩니다. 허용되는 범위는 1분에서 65,535분까지입니다. 확인된 커밋 작업은 구성 변경이 올바르게 작동하는지 확인하는 데 유용하며 디바이스에 대한 관리 액세스를 방해하지 않습니다. 변경으로 인해 액세스가 차단되거나 다른 오류가 발생하는 경우, 이전 구성으로 자동 롤백하면 롤백 기한이 지난 후 디바이스에 액세스할 수 있습니다. 커밋 작업을 확인하려면 또는 인수와 check: true
함께 또는 juniper_junos_config
모듈을 호출합니다config
.commit: true
다음 플레이북에서 첫 번째 작업은 구성을 수정하고, 커밋 확인과 커밋 작업 사이에 10초 동안 대기하며, 커밋 작업이 5분 이내에 확인되어야 합니다. 또한 커밋에 대한 주석을 기록합니다. 두 번째 작업은 커밋을 확인하는 작업을 실행합니다 commit check
. 실제 시나리오에서는 초기 커밋 후 유효성 검사 작업을 수행하고 작업이 특정 유효성 검사 기준을 통과하는 경우에만 커밋 확인을 실행할 수 있습니다.
--- - name: "Load configuration and confirm within 5 minutes" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration. Wait 10 seconds between check and commit. Confirm within 5 min." juniper.device.config: load: "merge" format: "text" src: "build_conf/{{ inventory_hostname }}/junos.conf" check_commit_wait: 10 confirmed: 5 comment: "updated using Ansible" register: response - name: "Print the response" debug: var: response - name: "Confirm the commit with a commit check" juniper.device.config: check: true diff: false commit: false register: response - name: "Print the response" debug: var: response
장치를 구성할 때 경고를 무시하는 방법
config
및 juniper_junos_config
모듈을 사용하면 Junos 디바이스에서 구성을 수정하고 커밋할 수 있습니다. 경우에 따라 RPC 응답에 심각도 수준이 경고 이상인 요소가 포함되어 <rpc-error>
모듈에서 예외가 발생하여 RpcError
로드 또는 커밋 작업이 실패할 수 있습니다.
어떤 경우에는 로드 및 커밋 조작에 RpcError
대한 경고에 응답하여 발생하는 예외를 억제하는 것이 필요하거나 바람직할 수 있습니다. 및 모듈에 config
모듈의 인수 목록에 매개 변수를 포함하여 ignore_warning
경고에 대해 발생하는 예외를 표시하지 않도록 RpcError
지시할 수 juniper_junos_config
있습니다. 인수는 ignore_warning
부울, 문자열 또는 문자열 목록을 사용합니다.
모듈이 수행하는 로드 및 커밋 작업에 대한 모든 경고를 무시하도록 모듈에 지시하려면 인수를 ignore_warning: true
포함합니다. 다음 예제에서는 로드 및 커밋 작업에 대한 모든 경고를 무시합니다.
--- - name: Configure Device hosts: dc1 connection: local gather_facts: no tasks: - name: Configure op script juniper.device.config: config_mode: "private" load: "set" lines: - "set system scripts op file bgp.slax" ignore_warning: true register: response - name: Print the response debug: var: response
포함하고 ignore_warning: true
모든 <rpc-error>
요소의 심각도 수준이 경고인 경우 응용 프로그램에서는 모든 경고를 무시하고 예외를 RpcError
발생시키지 않습니다. <rpc-error>
그러나 심각도 수준이 더 높은 요소는 여전히 예외를 발생시킵니다.
모듈에 특정 경고를 무시하도록 지시하려면 인수를 ignore_warning
무시할 경고가 포함된 문자열 또는 문자열의 목록으로 설정합니다. 다음 예제에서는 두 가지 특정 경고를 무시합니다.
--- - name: Configure Device hosts: dc1 connection: local gather_facts: no tasks: - name: Configure Junos device and ignore warnings juniper.device.config: config_mode: "private" load: "merge" src: "build_conf/{{ inventory_hostname }}/junos.conf" ignore_warning: - "Advertisement-interval is less than four times" - "Chassis configuration for network services has been changed." register: response - name: Print the response debug: var: response
이 모듈은 모든 <rpc-error>
요소의 심각도 수준이 경고이고 응답의 각 경고가 지정된 문자열 중 하나 이상과 일치하는 경우 예외를 표시하지 않습니다RpcError
.
예: Ansible을 사용하여 Junos 디바이스 구성
이 config
모듈을 사용하면 Junos 디바이스의 구성을 관리할 수 있습니다. 이 예에서는 모듈을 사용하여 config
SSH를 통한 NETCONF를 통해 Junos 디바이스의 구성을 변경합니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
컬렉션이
juniper.device
설치된 Ansible 2.10 이상을 실행하는 구성 관리 서버NETCONF가 활성화된 Junos 디바이스 및 적절한 권한으로 구성된 사용자 계정
Ansible 컨트롤러 및 Junos 디바이스에서 해당 사용자에 대해 구성된 SSH 퍼블릭/프라이빗 키 쌍
필수 호스트가 정의된 기존 Ansible 인벤토리 파일
개요
이 예에서는 모듈을 사용하여 config
대상 Junos 디바이스의 구성에서 새 op 스크립트를 활성화하는 Ansible 플레이북을 보여줍니다. 구성 데이터 파일 junos-config.conf에는 텍스트 형식의 관련 구성 데이터가 포함되어 있습니다.
플레이북에는 Checking NETCONF connectivity
Ansible 모듈을 활용하여 wait_for
NETCONF 기본 포트(830)를 사용하여 대상 디바이스와 NETCONF 세션을 설정하려고 시도하는 작업이 포함되어 있습니다. 제어 노드가 플레이북 실행 중에 대상 디바이스와 NETCONF 세션을 설정하지 못하면 해당 디바이스에 대한 플레이의 나머지 작업을 건너뜁니다.
디바이스를 구성하는 작업은 NETCONF 검사가 config
성공한 경우 모듈을 실행합니다. module 인수는 load: "merge"
연산을 사용하여 새 구성 데이터를 후보 구성으로 로드합니다load merge
. 기본적으로 config
모듈은 및 rollback
작업을 위해 load
디바이스에 구성 데이터를 커밋합니다. 모듈 인수에는 디바이스의 시스템 로그 파일 및 커밋 기록에 커밋 코멘트를 기록하는 인수가 포함됩니다comment
.
구성
구성 데이터 파일 만들기
단계별 절차
모듈에서 사용하는 구성 데이터 파일을 만들려면 다음을 수행합니다.
구성 데이터의 형식(이 예에서는 텍스트)에 따라 적절한 확장명을 가진 새 파일을 만듭니다.
파일에 원하는 구성 변경 사항을 포함합니다.
user@ansible-cn:~/ansible$ cat build_conf/dc1a.example.net/junos-config.conf system { scripts { op { file bgp.slax; } } }
Ansible 플레이북 생성
단계별 절차
모듈을 사용하여 config
Junos 디바이스에서 구성을 변경하는 플레이북을 생성하려면 다음을 수행합니다.
모듈을 로컬에서 실행하는 플레이북 상용구를 포함합니다.
--- - name: Load and commit configuration data on a Junos device hosts: dc1 connection: local gather_facts: no
(선택 사항) NETCONF 연결을 확인하는 작업을 생성합니다.
tasks: - name: Checking NETCONF connectivity wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5
디바이스에 구성을 로드하고 커밋하는 작업을 생성합니다.
- name: Merge configuration data from a file and commit juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos-config.conf" comment: "Configuring op script with Ansible" register: response
(선택 사항) diff 형식의 구성 변경 내용을 포함하는 응답을 인쇄하는 작업을 생성합니다.
- name: Print the response debug: var: response
결과
Ansible 제어 노드에서 완료된 플레이북을 검토합니다. 플레이북에 의도한 코드가 표시되지 않으면 이 예제의 지침을 반복하여 플레이북을 수정하십시오.
--- - name: Load and commit configuration data on a Junos device hosts: dc1 connection: local gather_facts: no tasks: - name: Checking NETCONF connectivity wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5 - name: Merge configuration data from a file and commit juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos-config.conf" comment: "Configuring op script with Ansible" register: response - name: Print the response debug: var: response
플레이북 실행
플레이북을 실행하려면:
-
ansible-playbook
제어 노드에서 명령을 실행하고 플레이북 경로와 원하는 옵션을 제공합니다.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-junos-config.yaml PLAY [Load and commit configuration data on a Junos device] **** TASK [Checking NETCONF connectivity] ************************************** ok: [dc1a.example.net] TASK [Merge configuration data from a file and commit] ******************** changed: [dc1a.example.net] TASK [Print the response] ************************************************* ok: [dc1a.example.net] => { "response": { "changed": true, "diff": { "prepared": "\n[edit system scripts op]\n+ file bgp.slax;\n" }, "diff_lines": [ "", "[edit system scripts op]", "+ file bgp.slax;" ], "failed": false, "file": "build_conf/dc1a.example.net/junos-config.conf", "msg": "Configuration has been: opened, loaded, checked, diffed, committed, closed." } } PLAY RECAP **************************************************************** dc1a.example.net : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
확인
구성 확인
목적
Junos 디바이스에서 구성이 올바르게 업데이트되었는지 확인합니다.
행동
Ansible 플레이북 출력을 검토하여 구성 작업의 성공 또는 실패 여부를 확인합니다. 또한 Junos 디바이스에 로그인하고 구성, 커밋 기록 및 로그 파일을 보고 구성 및 커밋을 확인할 수 있습니다. 예를 들면 다음과 같습니다.
user@dc1a> show configuration system scripts op { file bgp.slax; }
user@dc1a> show system commit 0 2020-12-17 15:33:50 PST by user via netconf Configuring op script with Ansible
user@dc1a> show log messages Dec 17 15:33:39 dc1a mgd[33444]: UI_COMMIT: User 'user' requested 'commit' operation (comment: Configuring op script with Ansible) Dec 17 15:33:57 dc1a mgd[33444]: UI_COMMIT_COMPLETED: commit complete
플레이북 오류 문제 해결
시간 초과 오류 문제 해결
문제
플레이북은 오류 메시지를 생성하고 TimeoutExpiredError
디바이스 구성을 업데이트하지 못합니다.
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply
NETCONF RPC의 시간 초과에 대한 기본 시간은 30초입니다. 대규모 구성 변경으로 인해 이 값을 초과하면 구성을 업로드하고 커밋하기 전에 작업 시간이 초과될 수 있습니다.
용액
기본 RPC 시간 초과 간격보다 긴 커밋 시간이 필요할 수 있는 구성 변경을 수용하려면 모듈의 timeout
인수를 적절한 값으로 설정하고 플레이북을 다시 실행합니다.
구성 잠금 오류 문제 해결
문제
플레이북은 LockError
구성을 잠글 수 없음을 나타내는 오류 메시지를 생성합니다. 예를 들어:
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: None, message: configuration database modified)"}
또는
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: lock-configuration, message: permission denied)"}
구성 잠금 오류는 다음과 같은 이유로 발생할 수 있습니다.
다른 사용자가 구성에 대한 배타적 잠금을 가지고 있습니다.
다른 사용자가 구성 데이터베이스를 변경했지만 아직 변경 내용을 커밋하지 않았습니다.
Ansible 모듈을 실행하는 사용자에게는 디바이스를 구성할 수 있는 권한이 없습니다.
용액
메시지 문자열은 LockError
일반적으로 문제의 근본 원인을 나타냅니다. 다른 사용자가 구성에 대한 배타적 잠금을 가지고 있거나 구성을 수정한 경우 잠금이 해제되거나 변경 사항이 커밋될 때까지 기다렸다가 플레이북을 다시 실행합니다. 문제의 원인이 사용자에게 디바이스를 구성할 수 있는 권한이 없는 경우, 필요한 권한이 있는 사용자와 함께 플레이북을 실행하거나, 적절한 경우 현재 사용자에게 변경을 수행하는 데 필요한 권한을 부여하도록 Junos 디바이스를 구성합니다.
구성 변경 오류 문제 해결
문제
플레이북은 권한이 거부되었기 때문에 구성을 수정할 수 없음을 나타내는 오류 메시지를 생성합니다 ConfigLoadError
.
FAILED! => {"changed": false, "msg": "Failure loading the configuraton: ConfigLoadError(severity: error, bad_element: scripts, message: error: permission denied)"}
이 오류 메시지는 Ansible 모듈을 실행하는 사용자에게 구성을 변경할 수 있는 권한이 있지만 요청된 구성 섹션을 변경할 수 있는 권한이 없는 경우에 생성됩니다.
용액
필요한 권한이 있는 사용자로 플레이북을 실행하거나, 적절한 경우 현재 사용자에게 변경에 필요한 권한을 부여하도록 Junos 디바이스를 구성합니다.
변경 내역 테이블
기능 지원은 사용 중인 플랫폼 및 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.
junos_install_config
junos_get_config
, 및 모듈의 기능을
junos_commit
결합하고 대체합니다
junos_rollback
.
Juniper.junos
juniper_junos_config