Ansible 모듈을 juniper.device.config 사용하여 Junos OS 구성 관리
Ansible 모듈을 사용하여 juniper.device.config Junos OS를 실행하는 디바이스와 Junos OS Evolved를 실행하는 디바이스의 구성을 관리할 수 있습니다.
주니퍼 네트웍스는 Junos 디바이스를 구성할 수 있도록 지원하는 Ansible 모듈을 제공합니다. 표 1은 사용 가능한 모듈의 개요입니다. 컬렉션에서 juniper.device 지정된 모듈 세트를 이미 사용하고 있는 경우 해당 세트에 대한 모듈을 사용합니다.
|
컬렉션 |
모듈 세트 |
모듈 이름 |
|---|---|---|
|
|
||
|
|
juniper.device.junos_config |
다음 섹션에서는 모듈을 juniper.device.config 사용하여 Junos 디바이스의 구성을 수정하고 커밋하는 방법에 대해 설명합니다. 모듈에 대한 juniper.device.junos_config 자세한 내용은 juniper.device.junos_config Ansible 모듈을 사용하여 Junos 디바이스 구성을 참조하십시오.
모듈 개요
juniper.device.config 이 모듈을 사용하면 Junos 디바이스에서 다음 작업을 수행할 수 있습니다.
-
구성 데이터 로드
-
구성 커밋
-
구성 롤백
-
복구 구성 로드
구성을 변경하는 기본 프로세스는 구성을 잠그고, 구성 변경 내용을 로드하고, 구성을 커밋하여 활성화한 다음, 구성을 잠금 해제하는 것입니다. 구성을 변경하는 데 사용되는 사용자 계정에는 각 디바이스에서 구성의 관련 부분을 변경할 수 있는 권한이 있어야 합니다. 구성을 수정하려면 모듈의 인수 목록에 다음 매개 변수 중 하나가 포함되어야 합니다.
-
load- 새 구성 데이터를 로드합니다. -
rollback—복구 구성 또는 이전에 커밋된 구성으로 되돌립니다.
기본적으로 모듈은 juniper.device.config 후보 전역 구성을 자동으로 잠그고 잠금 해제하는 모드를 사용하여 configure exclusive 후보 구성 데이터베이스를 변경합니다. 다른 구성 모드를 지정할 수도 있습니다. 예를 들어, 후보 구성의 프라이빗 사본 또는 임시 구성 데이터베이스를 변경할 수 있습니다. 구성 모드 지정에 대한 자세한 내용은 구성 모드 지정 방법을 참조하십시오.
새 구성 데이터를 로드할 때 구성 모드를 지정하는 것 외에도 로드 작업과 변경 소스 및 형식을 지정할 수도 있습니다.
-
로드 작업 - 로드 작업은 구성 데이터가 선택한 구성 데이터베이스에 로드되는 방식을 결정합니다. Junos OS CLI에서 사용할 수 있는 많은 동일한 로드 작업 중에서 선택할 수 있습니다. 자세한 내용은 로드 작업 지정 방법을 참조하십시오.
-
형식 - 지원되는 표준 형식 중 하나를 사용하여 Junos 디바이스를 구성할 수 있습니다. 구성 데이터 또는 Jinja2 템플릿을 텍스트, Junos XML 요소, Junos OS
set명령 또는 JSON으로 제공할 수 있습니다. 구성 데이터의 형식을 지정하는 방법에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. -
구성 데이터 소스 - 문자열 목록, 로컬 Ansible 제어 노드의 파일, Jinja2 템플릿 또는 클라이언트 디바이스에서 연결할 수 있는 URL에서 구성 데이터를 로드할 수 있습니다. 구성 데이터의 소스 지정에 대한 자세한 내용은 다음 섹션을 참조하십시오.
juniper.device.config 또한 이 모듈을 사용하면 구조 구성을 로드 및 커밋하거나 이전에 커밋된 구성으로 구성을 롤백할 수 있습니다. 복구 구성 또는 이전에 커밋된 구성을 로드하려면 모듈 인자를 포함 rollback 해야 합니다. 자세한 내용은 다음 섹션을 참조하십시오.
구성을 수정한 후 디바이스에서 활성 구성되도록 구성을 커밋해야 합니다. 기본적으로 모듈은 juniper.device.config 구성에 대한 변경 사항을 커밋합니다. 이 동작을 변경하거나 추가 커밋 옵션을 제공하려면 구성 커밋 방법을 참조하십시오.
기본적으로 모듈에 juniper.device.config OR rollback 인수가 포함되어 load 있으면 모듈의 응답이 diff 또는 패치 형식으로 구성 변경 사항을 자동으로 반환합니다. 이 모듈은 및 diff_lines 필드의 차이점을 반환합니다.diff 모듈이 차이를 계산하고 반환하지 못하도록 하려면 모듈 인수를 false로 설정합니다diff.
구성 모드를 지정하는 방법
디바이스 구성을 수정할 때 사용할 구성 모드를 지정할 수 있습니다. 작업에서 구성 모드를 지정하려면 모듈의 매개 변수를 config_mode 포함합니다. 지원되는 구성 모드는 다음과 같습니다.
-
batch -
dynamic -
ephemeral -
exclusive -
private
기본적으로 모듈은 juniper.device.config 모드를 사용하여 configure exclusive 후보 구성 데이터베이스를 변경합니다. 구성 제외 모드는 모듈이 요청된 구성 변경을 수행해야 하는 한 후보 전역 구성( 공유 구성 데이터베이스라고도 함)을 잠급니다. 데이터베이스를 잠그면 다른 사용자가 동시에 데이터베이스에 대한 변경 사항을 수정하거나 커밋할 수 없습니다.
다음 예는 후보 구성의 프라이빗 사본을 구성하는 방법과 임시 데이터베이스를 구성하는 방법을 보여줍니다.
예: config_mode: "private"
다음 플레이북은 구성 모드를 사용하여 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
ansible.builtin.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
임시 데이터베이스 구성
이 모듈을 사용하여 juniper.device.config 이 데이터베이스를 지원하는 디바이스의 임시 구성 데이터베이스 를 업데이트할 수 있습니다. 임시 데이터베이스는 Junos 디바이스에서 구성 업데이트를 수행하기 위한 빠른 프로그래밍 인터페이스를 제공하는 대체 구성 데이터베이스입니다.
임시 구성 데이터베이스의 기본 인스턴스를 열고 구성하려면 인수를 포함합니다. config_mode: ephemeral 예를 들면 다음과 같습니다.
---
- name: Configure ephemeral database
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Configure the default ephemeral database
juniper.device.config:
config_mode: ephemeral
load: set
lines:
- "set protocols mpls label-switched-path to-hastings to 192.0.2.1"
임시 구성 데이터베이스의 기존 사용자 정의 인스턴스를 열고 구성하려면 인수를 포함 config_mode: ephemeral 하고 인수를 인스턴스 이름으로 설정합니다 ephemeral_instance .
tasks:
- name: Configure a user-defined ephemeral instance
juniper.device.config:
config_mode: ephemeral
ephemeral_instance: eph1
load: set
lines:
- "set protocols mpls label-switched-path to-hastings to 192.0.2.2"
로드 동작을 지정하는 방법
이 모듈은 juniper.device.config Junos OS CLI에서 지원되는 것과 동일한 많은 로드 작업을 사용하여 구성 변경 로드 로드를 지원합니다. 모듈의 load 인수를 해당 로드 작업의 값으로 설정하여 로드 작업을 지정합니다. 표 2 에는 다양한 로드 작업에 대한 인수 값이 요약되어 있습니다.
|
로드 작업 |
|
설명 |
|---|---|---|
|
|
|
로드된 구성을 기존 구성과 병합합니다. |
|
|
|
전체 구성을 로드된 구성으로 대체합니다. 모든 시스템 프로세스가 구성을 구문 분석합니다. |
|
|
|
패치 파일에서 구성 데이터를 로드합니다. |
|
|
|
로드된 구성을 기존 구성과 병합하되 기존 구성의 문을 태그를 지정하는 로드된 구성의 문으로 바꿉니다 |
|
|
|
형식의 |
|
|
|
전체 구성을 로드하고 기존 구성과 비교합니다. 후보 구성에서 변경된 부분만 교체합니다. 커밋 작업 중에는 영향을 받는 시스템 프로세스만 새 구성을 구문 분석합니다. |
로드할 구성 데이터의 형식을 지정하는 방법
juniper.device.config 이 모듈을 사용하면 지원되는 표준 형식 중 하나를 사용하여 Junos 디바이스를 구성할 수 있습니다. 구성 데이터를 문자열 또는 파일로 제공할 수 있습니다. 파일에는 구성 데이터 또는 Jinja2 템플릿이 포함될 수 있습니다. 문자열, 파일 또는 Jinja2 템플릿 내에서 구성 데이터를 제공할 때 데이터에 대해 지원되는 형식에는 텍스트, Junos XML 요소, Junos OS set 명령 및 JSON이 포함됩니다.
juniper.device.config 이 모듈은 인수 내에서 문자열로 제공하는 구성 데이터의 형식을 자동 감지하려고 시도합니다lines. 그러나 인수를 포함하여 문자열의 형식을 명시적으로 지정할 수 있습니다.format 파일 또는 Jinja2 템플릿에 구성 데이터를 제공할 때 데이터 형식을 지정해야 합니다. 파일에 적절한 확장자를 추가하거나 인수를 포함합니다.format
표 3 에는 구성 데이터에 대해 지원되는 형식과 파일 확장 및 format 매개 변수에 대한 해당 값이 요약되어 있습니다. 인수를 포함 format 하면 문자열의 자동 검색 형식과 파일 확장명으로 표시된 형식이 모두 재정의됩니다.
|
구성 데이터 형식 |
파일 확장자 |
|
|---|---|---|
|
CLI 구성 명령문(텍스트) |
.conf |
|
|
JSON(JavaScript Object Notation) |
.json |
|
|
Junos OS |
.세트 |
|
|
Junos XML 요소 |
.xml |
|
모듈의 load 인수를 override or 로 update설정하면 Junos OS set 명령 형식을 사용할 수 없습니다.
구성 데이터를 문자열로 로드하는 방법
juniper.device.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
ansible.builtin.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"
ansible.builtin.debug:
var: response
로컬 또는 원격 파일에서 구성 데이터를 로드하는 방법
juniper.device.config 이 모듈을 사용하면 파일에서 구성 데이터를 로드할 수 있습니다. 파일은 다음 위치 중 하나에 있을 수 있습니다.
-
Ansible 제어 노드
-
클라이언트 디바이스
-
클라이언트 디바이스에서 연결할 수 있는 FTP 또는 HTTP URL
파일에서 구성 데이터를 로드할 때, 파일의 위치와 파일 내 구성 데이터의 형식을 지정해야 합니다. 지원되는 구성 데이터 형식에는 텍스트, Junos XML 요소, Junos OS set 명령 및 JSON이 포함됩니다. Jinja2 템플릿이 포함된 파일 로드에 대한 자세한 내용은 Jinja2 템플릿을 사용하여 구성 데이터 로드 방법을 참조하십시오.
형식을 지정하려면 모듈의 format 매개 변수를 포함하거나 구성 데이터 파일에 적절한 확장자를 추가합니다. 매개 변수를 format 지정하면 파일 확장명으로 표시된 형식이 재정의됩니다. 형식 지정에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. 구성 데이터가 Junos XML 형식을 사용하는 경우 데이터를 최상위 <configuration> 태그로 묶어야 합니다.
텍스트, Junos OS set 명령 또는 JSON<configuration-text><configuration-set>으로 형식화된 구성 데이터를 NETCONF 세션 내에서 직접 디바이스를 구성할 때 필요에 따라 , , 또는 <configuration-json> 태그로 묶을 필요가 없습니다.
표 4 는 파일 위치를 지정하기 위해 포함할 수 있는 모듈 매개 변수를 간략하게 보여줍니다.
|
모듈 매개 변수 |
설명 |
|---|---|
|
|
|
|
|
|
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
ansible.builtin.debug:
var: response
Junos 디바이스의 파일이나 FTP 또는 HTTP URL에서 구성 데이터를 로드하려면 매개 변수를 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
ansible.builtin.debug:
var: response
의 url 값은 절대 또는 상대 로컬 파일 경로, FTP 위치 또는 HTTP 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 템플릿을 사용하여 구성 데이터를 로드하는 방법
juniper.device.config 이 모듈을 사용하면 Ansible 제어 노드의 Jinja2 템플릿 파일에서 구성 데이터를 렌더링하고 Junos 디바이스에서 구성을 로드하고 커밋할 수 있습니다. Jinja는 미리 정의된 템플릿에서 문서를 생성할 수 있는 Python용 템플릿 엔진입니다. 원하는 언어로 된 텍스트 파일인 템플릿은 표현식과 변수를 사용하여 유연성을 제공합니다. ASCII 텍스트, Junos XML 요소, Junos OS set 명령 및 JSON을 포함하는 지원되는 구성 형식 중 하나로 Jinja2 템플릿을 사용하여 Junos OS 구성 데이터를 생성할 수 있습니다. 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.device.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
ansible.builtin.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;
}
}
복구 구성을 로드하는 방법
복구 구성을 사용하면 알려진 작업 구성 또는 언제든지 복원할 수 있는 알려진 상태의 구성을 정의할 수 있습니다. 알려진 구성으로 되돌려야 할 때 또는 디바이스 구성과 백업 구성 파일이 복구할 수 없을 정도로 손상된 경우 최후의 수단으로 복구 구성을 사용합니다. 구조 구성을 생성할 때 디바이스는 가장 최근에 커밋된 구성을 구조 구성으로 저장합니다.
juniper.device.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
ansible.builtin.debug:
var: response
구성을 롤백하는 방법
Junos 디바이스는 플랫폼에 따라 가장 최근에 커밋된 구성과 최대 49개의 이전 구성의 사본을 저장합니다. 저장된 구성으로 롤백할 수 있습니다. 이 기능은 구성 변경으로 인해 원하지 않는 결과가 발생하고 알려진 작업 구성으로 되돌리려는 경우에 유용합니다. 구성 롤백은 디바이스에서 구성을 변경하는 프로세스와 유사합니다. 그러나 구성 데이터를 로드하는 대신 롤백을 수행하여 전체 후보 구성을 이전에 커밋한 구성으로 교체합니다.
juniper.device.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
ansible.builtin.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.device.config 구성을 수정할 때 모듈은 자동으로 커밋 검사를 수행하고 변경 사항을 커밋합니다. 모듈이 커밋 검사를 수행하거나 변경 사항을 커밋하지 못하도록 하려면 or commit 인수를 false각각 로 설정합니다check.
또한 Junos OS CLI에서 제공되는 것과 동일한 많은 옵션을 사용하여 커밋 작업을 사용자 지정할 수도 있습니다. 표 5 에는 다양한 커밋 옵션을 지정하는 데 사용할 수 있는 모듈 인수가 간략하게 나와 있습니다.
|
모듈 인수 |
설명 |
및 |
|---|---|---|
|
|
커밋 검사를 수행하거나 이전에 확인된 커밋 작업을 확인합니다. |
|
|
|
커밋 검사와 커밋 작업 사이에 지정된 시간(초)만큼 대기합니다. |
– |
|
|
시스템 로그 파일 및 디바이스의 커밋 기록에 해당 커밋 작업에 대한 코멘트를 기록합니다. |
– |
|
|
구성 변경 사항을 커밋하거나 이전에 확인된 커밋 작업을 확인합니다. |
|
|
|
후보 구성에 변경 사항이 없더라도 구성을 커밋합니다. |
|
|
|
다른 라우팅 엔진에 열려 있는 구성 세션이나 커밋되지 않은 구성 변경 사항이 있더라도 모든 라우팅 엔진에서 구성을 동기화하고 라우팅 엔진을 커밋합니다. |
|
|
|
모든 라우팅 엔진에서 구성을 동기화하고 커밋합니다. |
|
|
|
초기 커밋 후 지정된 시간 내에 커밋 작업을 확인해야 합니다. 지정된 시간 내에 커밋을 확인하지 않으면 이전에 커밋한 구성으로 롤백합니다. 옵션 또는 옵션을 사용하여 |
– |
|
|
지정된 값을 시간 제한으로 사용하여 작업이 완료될 때까지 기다립니다. |
30초 |
커밋 코멘트
구성을 커밋할 때 커밋된 변경 사항을 설명하는 간단한 코멘트를 포함할 수 있습니다. 변경 사항을 설명하는 코멘트를 기록하려면 메시지 문자열과 함께 인수를 포함 comment: "comment string" 합니다.
커밋 검사
기본적으로 모듈은 juniper.device.config 커밋 검사와 커밋 작업을 모두 실행합니다. check_commit_wait 이 인수는 커밋 검사와 커밋 작업 사이에 대기할 시간(초)을 정의합니다. 디바이스가 커밋 확인 작업을 완료하고 커밋 작업을 시작하기 전에 구성 잠금을 해제할 수 있도록 충분한 시간을 제공해야 하는 경우 이 인수를 포함합니다. 커밋 검사 작업이 구성에 대한 잠금을 해제하기 전에 디바이스가 커밋 작업을 시작하면 커밋 작업이 실패하고 모듈이 .CommitError
빈 변경 사항 커밋
기본적으로 후보 구성과 커밋된 구성에 차이가 없으면 모듈은 변경 사항을 커밋하지 않습니다. 차이가 없어도 커밋 작업을 강제로 수행하려면 인수를 포함합니다.commit_empty_changes: true
커밋 동기화
디바이스에 이중 라우팅 엔진이 있는 경우, 인수를 포함하여 commit_sync: true 두 라우팅 엔진의 구성을 동기화하고 커밋할 수 있습니다. 다른 라우팅 엔진에 열려 있는 구성 세션이나 커밋되지 않은 구성 변경 사항이 있더라도 작업이 성공하도록 강제 commit synchronize 하려면 인수를 사용합니다 commit_force_sync: true . 옵션을 commit_force_sync: true 포함하면 디바이스는 구성을 동기화하고 커밋하기 전에 다른 라우팅 엔진의 모든 구성 세션을 종료합니다.
커밋 확인
초기 커밋 후 지정된 시간 내에 커밋 작업을 확인하도록 요구하려면 인수를 포함합니다.confirmed: minutes 주어진 시간 제한 내에 커밋을 확인하지 않으면 구성은 이전에 커밋된 구성으로 자동 롤백됩니다. 허용되는 범위는 1분에서 65,535분입니다. 확인된 커밋 작업은 구성 변경이 올바르게 작동하는지 확인하는 데 유용하며 디바이스에 대한 관리 액세스를 차단하지 않습니다. 이러한 변경으로 인해 액세스가 차단되거나 다른 오류가 발생하는 경우, 이전 구성으로의 자동 롤백을 통해 롤백 기한이 지난 후 디바이스에 액세스할 수 있습니다. 커밋 작업을 확인하려면 or commit: true 인수를 사용하여 check: true 모듈을 juniper.device.config 호출합니다.
다음 플레이북에서 첫 번째 작업은 구성을 수정하고 커밋 확인과 커밋 작업 사이에 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
ansible.builtin.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
ansible.builtin.debug:
var: response
디바이스 구성 시 경고를 무시하는 방법
juniper.device.config 이 모듈을 사용하면 Junos 디바이스의 구성을 수정하고 커밋할 수 있습니다. 경우에 따라 RPC 응답에는 모듈에서 예외를 RpcError 발생시키는 심각도 수준 경고 이상의 요소가 포함될 <rpc-error> 수 있습니다. 예외로 인해 RpcError 로드 또는 커밋 작업이 실패할 수 있습니다.
특정 경우에는 로드 및 커밋 작업에 대한 경고에 대한 응답으로 발생하는 예외를 억제 RpcError 해야 하거나 바람직할 수 있습니다. 모듈의 인수 목록에 매개 변수를 ignore_warning 포함하여 경고에 대해 발생하는 예외를 표시하지 않도록 RpcError 모듈에 지시 juniper.device.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
ansible.builtin.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
ansible.builtin.debug:
var: response
모든 요소의 <rpc-error> 심각도 수준이 경고이고 응답의 각 경고가 지정된 문자열 중 하나 이상과 일치하는 경우 모듈은 예외를 표시하지 않습니다RpcError.
예: Ansible을 사용하여 Junos 디바이스 구성
juniper.device.config 이 모듈을 사용하면 Junos 디바이스에서 구성을 관리할 수 있습니다. 이 예는 모듈을 config 사용하여 SSH를 통한 NETCONF를 통해 Junos 디바이스에서 구성을 변경합니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
-
컬렉션이
juniper.device설치된 상태에서 Ansible 2.17 이상을 실행하는 구성 관리 서버 -
NETCONF가 활성화되고 적절한 권한으로 구성된 사용자 계정이 있는 Junos 디바이스
-
Ansible 컨트롤러 및 Junos 디바이스에서 적절한 사용자에 대해 구성된 SSH 공개/비공개 키 쌍
-
필수 호스트가 정의된 기존 Ansible 인벤토리 파일
개요
이 예에서는 이 모듈을 juniper.device.config 사용하여 대상 Junos 디바이스의 구성에서 새로운 op 스크립트를 활성화하는 Ansible 플레이북을 보여줍니다. 구성 데이터 파일 junos-config.conf에는 텍스트 형식의 관련 구성 데이터가 포함되어 있습니다.
플레이북에는 Ansible 모듈을 ansible.builtin.wait_for 활용하여 NETCONF 기본 포트(830)를 사용하여 대상 디바이스와의 NETCONF 세션을 설정하려는 작업이 포함되어 Check NETCONF connectivity 있습니다. 제어 노드가 플레이북 실행 중에 대상 디바이스와 NETCONF 세션을 설정하는 데 실패하면 해당 디바이스에 대한 재생에 있는 나머지 작업을 건너뜁니다.
플레이북은 모듈을 juniper.device.file_copy 사용하여 Ansible 제어 노드에서 Junos 디바이스로 새 op 스크립트를 복사합니다. 모듈 인수는 로컬 디바이스에 있는 스크립트의 디렉터리와 파일명을 지정하고 원격 디바이스에 있는 대상 디렉터리를 지정합니다.
디바이스를 구성하는 작업은 NETCONF 검사가 성공한 경우 모듈을 실행합니다 juniper.device.config . load: "merge" 인수는 작업을 사용하여 새로운 구성 데이터를 후보 구성에 로드합니다 load merge . 기본적으로 모듈은 config 작업을 위해 load rollback 디바이스의 구성 데이터를 커밋합니다. 모듈 인수에는 디바이스의 시스템 로그 파일 및 커밋 기록에 커밋 코멘트를 기록하는 인수가 포함됩니다 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: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5 -
새 op 스크립트를 디바이스에 복사하는 작업을 생성합니다.
- name: Copy the op script to the device juniper.device.file_copy: action: put file: bgp.slax local_dir: scripts remote_dir: /var/db/scripts/op -
디바이스에 구성을 로드하고 커밋하는 작업을 생성합니다.
- 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 ansible.builtin.debug: var: response
결과
Ansible 제어 노드에서 완료된 플레이북을 검토합니다. 플레이북에 의도한 코드가 표시되지 않으면 이 예제의 지침을 반복하여 플레이북을 수정합니다.
---
- name: Load and commit configuration data on a Junos device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: 830
timeout: 5
- name: Copy the op script to the device
juniper.device.file_copy:
action: put
file: bgp.slax
local_dir: scripts
remote_dir: /var/db/scripts/op
- 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
ansible.builtin.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 [Check NETCONF connectivity] ***************************************** ok: [dc1a.example.net] TASK [Copy the op script to the device] *********************************** changed: [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=4 changed=2 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 디바이스를 구성합니다.