Ansible을 사용하여 Junos 디바이스 구성
요약 주니퍼 네트웍스 Ansible 모듈을 사용하여 Junos 디바이스의 구성을 관리합니다.
주니퍼 네트웍스는 Junos 디바이스를 구성할 수 있는 Ansible 모듈을 제공합니다. 표 1 에는 사용 가능한 모듈이 요약되어 있습니다. 구성을 변경하는 데 사용되는 사용자 계정에는 각 디바이스에서 구성의 관련 부분을 변경할 수 있는 권한이 있어야 합니다.
| 콘텐츠 세트 |
모듈 이름 |
|---|---|
다음 섹션에서는 모듈을 사용하여 Junos 디바이스의 구성을 수정 및 커밋하는 방법에 대해 설명합니다.
모듈 개요
이 juniper.device.config 모듈을 사용하면 Junos 디바이스에서 다음 작업을 수행할 수 있습니다.
-
구성 데이터 로드Load configuration data
-
구성을 커밋합니다
-
구성을 롤백합니다
-
복구 구성을 로드합니다
구성을 수정하려면, 모듈의 인수 목록에 새 구성 데이터를 로드하기 위한 파라미터 또는 rollback 복구 구성이나 이전에 커밋된 구성으로 되돌리기 위한 파라미터가 포함되어야 load 합니다. 구성을 변경하는 기본 프로세스는 구성을 잠그고, 구성 변경 사항을 로드하고, 구성을 커밋하여 활성화한 다음, 구성을 잠금 해제하는 것입니다.
기본적으로 모듈은 config mode를 사용하여 configure exclusive 후보 구성 데이터베이스를 변경하며, 이 모드는 후보 전역 구성을 자동으로 잠그고 잠금 해제합니다. 다른 구성 모드를 지정할 수도 있습니다. 예를 들어, 후보 구성의 개인 복사본 또는 임시 구성 데이터베이스를 변경할 수 있습니다. 구성 모드 지정에 대한 자세한 내용은 구성 모드 지정 방법을 참조하십시오.
새로운 구성 데이터를 로드할 때 구성 모드를 지정하는 것 외에도 로드 작업과 변경 사항의 소스 및 형식을 지정할 수도 있습니다.
-
로드 작업 - 로드 작업은 구성 데이터가 선택된 구성 데이터베이스에 로드되는 방식을 결정합니다. 이 함수는 Junos OS CLI에서 사용할 수 있는 것과 동일한 여러 로드 작업을 지원합니다. 자세한 내용은 로드 동작을 지정하는 방법을 참조하십시오.
-
형식 - 지원되는 표준 형식 중 하나를 사용하여 Junos 디바이스를 구성할 수 있습니다. 구성 데이터 또는 Jinja2 템플릿을 텍스트, Junos XML 요소, Junos OS
set명령 또는 JSON으로 제공할 수 있습니다. 구성 데이터의 형식을 지정하는 방법에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. -
구성 데이터 소스—,
src,template또는url매개 변수를 각각 포함하여 문자열 목록, 로컬 Ansible 제어 노드의 파일, Jinja2 템플릿 또는 클라이언트 디바이스에서 연결할 수 있는 URL에서lines구성 데이터를 로드할 수 있습니다. 구성 데이터의 소스 지정에 대한 자세한 내용은 다음 섹션을 참조하십시오.
config 또한 이 모듈을 통해 구조 구성을 로드 및 커밋하거나 이전에 커밋한 구성으로 구성을 롤백할 수 있습니다. 구조 구성 또는 이전에 커밋된 구성을 로드하려면 module 인수를 rollback 포함해야 합니다. 자세한 내용은 다음 섹션을 참조하세요.
구성을 수정한 후 구성을 커밋하여 디바이스에서 활성 구성이 되도록 해야 합니다. 기본적으로 모듈은 config 구성에 대한 변경 사항을 커밋합니다. 이 동작을 변경하거나 추가 커밋 옵션을 제공하려면 구성 커밋 방법을 참조하십시오.
기본적으로 모듈에 config 구성을 변경하기 위한 또는 rollback 인수가 포함된 load 경우 모듈은 모듈의 응답에서 diff 또는 patch 형식으로 구성 변경 사항을 자동으로 반환합니다. 차이는 및 diff_lines 변수에 diff 반환됩니다. 모듈이 차이를 계산하고 반환하지 않도록 하려면 module 인수false를 diff .
구성 모드를 지정하는 방법
디바이스 구성을 수정할 때 사용할 구성 모드를 지정할 수 있습니다. 작업에서 구성 모드를 지정하려면 모듈의 config config_mode 매개 변수를 포함합니다. 지원되는 구성 모드는 다음과 같습니다.
-
batch -
dynamic -
ephemeral -
exclusive -
private
기본적으로 모듈은 juniper.device.config 모드를 사용하여 configure exclusive 후보 구성 데이터베이스를 변경합니다. 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 에는 각 유형의 하중 작업에 필요한 매개변수 설정이 요약되어 있습니다.
| 로드 작업 |
load 인수 |
묘사 |
|---|---|---|
|
|
|
로드된 구성을 기존 구성과 병합합니다. |
|
|
|
전체 구성을 로드된 구성으로 대체합니다. |
|
|
|
패치 파일에서 구성 데이터를 로드합니다. |
|
|
|
로드된 구성을 기존 구성과 병합하되, 기존 구성의 문은 로드된 구성의 태그를 지정하는 |
|
|
|
형식의 구성 데이터를 로드합니다 |
|
|
|
로드된 전체 구성을 기존 구성과 비교합니다. 로드된 구성에서 다른 각 구성 요소는 기존 구성에서 해당 요소를 대체합니다. 커밋 작업 중에는 변경된 구성 요소의 영향을 받는 시스템 프로세스만 새 구성을 구문 분석합니다. |
로드할 구성 데이터의 형식을 지정하는 방법
이 juniper.device.config 모듈을 통해 지원되는 표준 형식 중 하나를 사용하여 Junos 디바이스를 구성할 수 있습니다. 구성 데이터를 문자열 또는 파일로 제공할 수 있습니다. 파일에는 구성 데이터 또는 Jinja2 템플릿이 포함될 수 있습니다. 문자열, 파일 또는 Jinja2 템플릿 내에서 구성 데이터를 제공할 때 지원되는 데이터 형식에는 텍스트, Junos XML 요소, Junos OS set 명령 및 JSON이 포함됩니다.
모듈은 config 인수 내에서 문자열로 제공하는 구성 데이터의 형식을 자동으로 감지하려고 시도합니다 lines . 그러나 인수를 포함하여 format 문자열의 형식을 명시적으로 지정할 수 있습니다. 파일 또는 Jinja2 템플릿에 구성 데이터를 제공하는 경우 파일에 적절한 확장자를 추가하거나 인수를 format 포함하여 데이터 형식을 지정해야 합니다.
표 3 에는 구성 데이터에 대해 지원되는 형식과 파일 확장자 및 format 매개변수에 대한 해당 값이 요약되어 있습니다. 인수를 format 포함하면 문자열에 대한 자동 검색 형식과 파일 확장자로 표시된 형식을 모두 재정의합니다.
| 구성 데이터 형식 |
파일 확장자 |
format 매개 변수 |
|---|---|---|
| CLI 구성 문(텍스트) |
.conf (영문) |
"" |
| JSON(JavaScript Object Notation) |
.json |
"" |
|
|
.집합 |
"" |
| Junos XML 요소 |
.xml |
"" |
모듈의 load 인수를 또는 'update'으로 설정하면 Junos OS set 명령 형식을 'override' 사용할 수 없습니다.
구성 데이터를 문자열로 로드하는 방법
이 juniper.device.config 모듈을 사용하면 문자열 목록에서 구성 데이터를 로드할 수 있습니다. 구성 데이터를 문자열로 로드하려면 적절한 load 인수와 인수를 lines 포함합니다. 인수는 lines 로드할 구성 데이터를 포함하는 문자열 목록을 사용합니다.
모듈은 구성 데이터의 형식을 자동 감지하려고 시도합니다 lines . 그러나 인수를 포함하여 형식을 명시적으로 지정할 수 있습니다 format . 형식 지정에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. 인수를 format 포함하면 자동 감지된 형식을 재정의합니다.
다음 플레이북은 두 개의 op 스크립트를 구성하고 커밋합니다. 이 경우, 의 lines 구성 데이터가 Junos OS set 명령문 형식을 사용하므로 인수는 load 값을 '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 제어 노드
-
클라이언트 디바이스
-
클라이언트 디바이스에서 연결할 수 있는 URL
파일에서 구성 데이터를 불러올 때 파일의 위치와 파일 내 구성 데이터의 형식을 지정해야 합니다. 지원되는 구성 데이터 형식에는 텍스트, Junos XML 요소, Junos OS set 명령 및 JSON이 포함됩니다. Jinja2 템플릿이 포함된 파일을 로드하는 방법에 대한 자세한 내용은 Jinja2 템플릿을 사용하여 구성 데이터를 로드하는 방법을 참조하십시오.
구성 데이터의 형식은 모듈의 인수 목록에 매개 변수를 명시적으로 포함 format 하거나 구성 데이터 파일에 적절한 확장자를 추가하여 지정할 수 있습니다. 매개 변수를 지정 format 하면 파일 확장자가 표시하는 형식을 재정의합니다. 형식 지정에 대한 자세한 내용은 로드할 구성 데이터의 형식을 지정하는 방법을 참조하십시오. 구성 데이터가 Junos XML 형식을 사용하면, 데이터를 최상위 <configuration> 태그로 묶어야 합니다.
NETCONF 세션 내에서 디바이스를 직접 구성할 때 필요에 따라 ASCII 텍스트, Junos OS set 명령 또는 JSON으로 포맷된 구성 데이터를 , <configuration-set>또는 <configuration-json> 태그로 <configuration-text>묶을 필요가 없습니다.
표 4 에서는 파일의 위치를 지정하기 위해 포함할 수 있는 모듈 매개변수를 간략하게 설명합니다.
| 모듈 매개 변수 |
묘사 |
|---|---|
|
|
Ansible 제어 노드에 있는 파일의 절대 또는 상대 경로입니다. 기본 디렉터리는 플레이북 디렉터리입니다. |
|
|
클라이언트 디바이스에 있는 파일의 절대 또는 상대 경로, FTP 위치 또는 HTTP 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"
ansible.builtin.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"
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 명령 및 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.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)까지입니다.
다음 플레이북은 복원할 구성의 롤백 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 또는 rollback 인수를 사용하여 load 구성을 수정하면 모듈이 자동으로 커밋 검사를 수행하고 변경 사항을 커밋합니다. 모듈이 커밋 검사를 수행하거나 변경 사항을 커밋하지 않도록 하려면 또는 commit 인수false를 check 각각 에 설정합니다.
또한 Junos OS CLI에서 사용할 수 있는 것과 동일한 여러 옵션을 사용하여 커밋 작업을 사용자 지정할 수 있습니다. 표 5 에는 다양한 커밋 옵션을 지정하는 데 사용할 수 있는 모듈 인수가 요약되어 있습니다.
| 모듈 인수 |
묘사 |
및 |
|---|---|---|
|
|
커밋 검사를 수행하거나 이전에 확인된 커밋 작업을 확인합니다. |
|
|
|
커밋 검사와 커밋 작업 사이에 지정된 시간(초) 동안 대기합니다. |
– |
|
|
해당 커밋 작업에 대한 코멘트를 시스템 로그 파일과 디바이스의 커밋 기록에 기록합니다. |
– |
|
|
구성 변경 사항을 커밋하거나 이전에 확인된 커밋 작업을 확인합니다. |
|
|
|
후보 구성과 커밋된 구성 사이에 차이가 없더라도 구성 변경 사항을 커밋합니다. |
|
|
|
다른 라우팅 엔진에서 열린 구성 세션 또는 커밋되지 않은 구성 변경이 있더라도 다른 라우팅 엔진에서 구성을 동기화하고 커밋합니다. |
|
|
|
모든 라우팅 엔진에서 구성을 동기화하고 커밋합니다. |
|
|
|
초기 커밋 후 지정된 시간 내에 커밋 작업을 확인해야 합니다. 지정된 시간 내에 커밋이 확인되지 않으면 이전에 커밋한 구성으로 롤백합니다.
|
– |
|
|
지정된 값을 시간 제한으로 사용하여 작업이 완료될 때까지 기다립니다. |
30초 |
커밋 코멘트
구성을 커밋할 때 커밋된 변경 사항의 목적을 설명하는 간단한 코멘트를 포함할 수 있습니다. 변경 사항을 설명하는 코멘트를 기록하려면 메시지 문자열과 comment: "comment string" 함께 인수를 포함합니다.
커밋 확인
기본적으로 모듈은 config 커밋 검사와 커밋 작업을 모두 실행합니다. 인수는 check_commit_wait 커밋 검사와 커밋 작업 사이에 대기할 초 수를 정의합니다. 커밋 작업을 시작하기 전에 디바이스가 커밋 확인 작업을 완료하고 구성 잠금을 해제하는 데 충분한 시간을 제공해야 하는 경우 이 인수를 포함합니다. 인수를 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분까지입니다. 확인된 커밋 작업은 구성 변경이 올바르게 작동하는지 확인하는 데 유용하며 디바이스에 대한 관리 액세스를 차단하지 않습니다. 이러한 변경으로 인해 액세스가 차단되거나 다른 오류가 발생하는 경우, 이전 구성으로의 자동 롤백을 통해 롤백 기한이 지난 후 디바이스에 액세스할 수 있습니다. 커밋 작업을 확인하려면 또는 인수로 config 모듈을 호출하십시오check: true.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"
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 응답에는 모듈에서 예외를 발생시키는 심각도 수준이 경고 이상의 요소가 포함될 <rpc-error> 수 있습니다RpcError. 예외로 RpcError 인해 로드 또는 커밋 작업이 실패할 수 있습니다.
어떤 경우에는 로드 및 커밋 조작에 대한 경고에 대한 응답으로 발생하는 예외를 억제 RpcError 하는 것이 필요하거나 바람직할 수 있습니다. 모듈의 인수 목록에 매개 변수를 포함하여 ignore_warning 경고에 대해 발생하는 예외를 표시하지 않도록 RpcError 모듈에 지시 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
이 모듈은 RpcError 모든 <rpc-error> 요소의 심각도 수준이 경고이고 응답의 각 경고가 지정된 문자열 중 하나 이상과 일치하는 경우 예외를 표시하지 않습니다.
예: Ansible을 사용하여 Junos 디바이스 구성
이 juniper.device.config 모듈을 사용하면 Junos 디바이스의 구성을 관리할 수 있습니다. 이 예에서는 모듈을 사용하여 config SSH를 통해 NETCONF를 통해 Junos 디바이스의 구성을 변경합니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
-
콜렉션이
juniper.device설치된 Ansible 2.10 이상을 실행하는 구성 관리 서버 -
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 스크립트를 복사합니다. module 인수는 로컬 장치에 있는 스크립트의 디렉터리와 파일 이름, 원격 장치에 있는 대상 디렉터리를 지정합니다.
디바이스 구성 작업은 NETCONF 검사가 성공한 경우 모듈을 실행합니다juniper.device.config. 인수는 load: "merge" 연산을 사용하여 load merge 새로운 구성 데이터를 후보 구성에 로드합니다. 기본적으로 모듈은 config 및 rollback 작업을 위해 load 디바이스의 구성 데이터를 커밋합니다. module 인수에는 디바이스의 comment 시스템 로그 파일에 커밋 코멘트와 커밋 기록을 기록하는 인수가 포함됩니다.
구성
구성 데이터 파일 만들기
단계별 절차
모듈에서 사용하는 구성 데이터 파일을 작성하려면 다음을 수행하십시오.
구성 데이터의 형식(이 예에서는 텍스트)에 따라 적절한 확장자를 가진 새 파일을 만듭니다.
파일에 원하는 구성 변경 사항을 포함합니다.
user@ansible-cn:~/ansible$ cat build_conf/dc1a.example.net/junos-config.conf system { scripts { op { file bgp.slax; } } }
Ansible 플레이북 생성
단계별 절차
모듈을 사용하여 Junos 디바이스의 구성을 변경하는 플레이북을 config 생성하려면 다음을 수행합니다.
모듈을 로컬로 실행하는 플레이북 상용구를 포함합니다.
--- - 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 디바이스를 구성합니다.