DevOps/Programmability2018.02.07 08:02

안녕하세요.

이번 포스팅은 Programmability for Networker의 25번째 포스팅입니다.

ACI Cobra를 이용하여 Port Channel 혹은 vPC Profile을 만들어주는 코드에 대해서 공유합니다.

세부적인 코드 설명은 포함되어 있지는 않지만, 현업에서 아래의 코드를 사용한다면

보다 쉽고, 빠르게 Profile을 만드실 수 있을겁니다.

이번 코드는  운영 중인 커뮤니티에서 진행된  '제 22회 네트워크 전문가 따라잡기 'N.EX.T''에서 발표하였던 코드이기도 합니다.

(정리해서 올리기로 하고.. 1년 가까이가 지났네요. ^^)

 

물론 포스팅 설명에 앞서서 한가지 미리 얘기를 드리면,

'왜 Port Channel이나 vPC Profile을 대량을 으로 만들어야 하지?' 라고 생각하실 수 있습니다.

ACI에 대한 포스팅을 준비만 하면서 계속하지 못하고 있어서 다루지 못한 부분이기는 하지만..

이 부분은 ACI를 어떻게 설계해서 사용하느냐에 따라서 많아질 수도.. 혹은 적어질 수도 있을 것이라고 생각합니다.

(물론 개인적인 생각은 최적화 된 Profile로 설계해서 사용한다면 그리 많지 않은 Profile로 모두 수용이 가능합니다.)

 

그럼 이제 본 내용을 시작합니다.

 


 

ACI에서 기본적으로 제공되는 APIC GUI에서 Click! Click을 이용해서 설정하는 방법 이외에

 

일괄적으로 대량을 설정을 하기 위해서는

JSON이나, XML 포맷의 파일을 미리 만들어 POST 하여 설정을 하거나,

ACI에서 제공되는 API를 이용해서 코드로 설정하는 방법이 있을 것입니다.  (CLI를 제외하고..)

 

하지만, 오늘 다룰 내용인 Interface Policies 항목에서는 POST를 할 수 있는 메뉴가 없습니다.

최상단의 Interface Policies에도 없고요.

 

 

 

 

 

 

하단의 Policy Groups에도 없습니다.

 

 

 

물론 그 하단인 Leaf Policy Groups에도 없습니다.

 

 

그래서 PC Profile이나 vPC Profile을 생성하기 위해서 ACI SDK인 Cobra를 이용하여 Port Channel이나 vPC Profile을 만들려고 합니다.

 

다음은 Port Channel이나 vPC Profile을 만드는 코드입니다.

 

 

위의 코드 이외에 Port Channel 혹은 vPC Profile의 이름이 선언된 info.txt라는 파일이 있어야 합니다.

info.txt에는 단순히 Profile에 사용할 이름만 한 줄씩 나열합니다.

 

그러면 info 파일에서 한 줄씩 읽어서 해당 이름으로 Profile을 생성하게 됩니다.

코드 본문에 있는 AEP 변수에서 사용하실 AEP 이름을 수정하시고

Port Channel을 사용할지, vPC를 사용할지에 따라서 AccBndlGrp 메서드 호출 시에 lagT에 대해서

 

Port Channel은 'link'로 설정하시고, vPC의 경우에는 'node'로 설정하시면 됩니다.

 

위의 코드에서는 Link Level Policy, Port Channel Policy, Attach Entity Profile에 대한 속성만 설정하였지만,

기타 그 밖의 설정을 추가할 수도 있습니다.

 

혹시라도 대량으로 PC, vPC Profile을 설정하셔야 하는 경우에 이 코드를 사용하시면 조금은 쉽게 설정이 가능하실 겁니다.

물론 자동화의 장점은 설정에 대한 편의성도 있지만, 잘못된 설정으로 인한 휴먼에러의 방지도 가능할 것입니다.

 

참고로, 위의 코드에서는 설정 시의 기본 예외처리만 만들었으며

기타 다른 상황에 대한 세부 예외 처리가 되어 있지 않기 때문에 더 보완해서 사용해보시는 것도 좋을 것 같습니다.

 

 

Posted by 네떡지기
분류없음2017.06.16 20:02

Today Keys : Programmable, config, 프로그래머블, 백업, netmiko, programmability, networker, network


 이번 포스팅은 다시 시작하는 Programmability for Networker의 23번째 포스팅입니다. 

 이번 내용은 장비의 Configuration을 백업해주는 코드입니다.  

 주기적으로 반복해서 수행되는 장비 백업 작업에 대해서 손쉽게 코드로 해결해 줄 수 있습니다. 

 이 포스팅에서는 앞 포스팅에서 소개한 netmiko 라이브러리를 사용하였고, Cisco 장비에 대해서만 진행했습니다.

 하지만 유사한 방식으로 다른 장비들도 손쉽게 구현이 가능할 것입니다.

 netmiko에서 지원되는 다양한 네트워크 장비들도 거의 동일한 방법으로 구현이 가능합니다. 

 물론 멀티벤더에 대한 부분들도 코드를 나눠서도 할 수 있겠지만, 하나의 코드에서 장비 벤더를 구분해서 코드를 

 실행하도록 할 수도 있을 것입니다. 

 하지만, 우선 시작하는 단계에서는 조금 더 쉽고 최대한 코드를 나눠서 연습해가며 진행을 하신다면 좋을 것 같습니다.

 



 아래의 코드는 별도의 파일에서 지정된 네트워크 장비 목록을 지정하고, 

 해당 목록의 모든 장비의 Configuration을 Text파일로 백업해주는 역할을 하게 됩니다. 

 아래의 코드를 Linux에서 크론탭으로 돌리거나, Windows의 스케쥴러를 이용하시면, 간단하게 정기적으로

 장비의 Configuration을 백업 받으실 수 있습니다. 


[ Config Backup ]

import device

from netmiko import ConnectHandler


for dev in device.ZIGI_devices:

    nwnode = ConnectHandler(**dev)

    hostname = nwnode.send_command("show hostname")

    print("Collecting {0}Device Running Coning".format(hostname))

    run_config = nwnode.send_command("show running")

    print("Collect Complete")

    filename = "c:\\backup\\" + hostname + "-" + backupdate + '.log'

    print("Saving configuration file")

    configFile = open(filename,'w')

    configFile.write(run_config)

    print("{0}Device Configuration Backup complete".format(hostname))

    configFile.close() 


nwnode = ConnectHandler(**dev)

 ▷ 별도의 파일에 백업하고 싶은 장비의 목록을 지정해놓고, 순환문을 이용해서 장비 정보를 불러오게 됩니다. 

     현재 백업하고자 하는 장비를 가져오는 부분입니다.

hostname = nwnode.send_command("show hostname")

  ▷ 현재 장비의 hostname을 가져오는 부분입니다. 'show hostname' 명령어를 이용해서 hostname을 변수에 

     저장하게 하게 됩니다. 

run_config = nwnode.send_command("show running")

 ▷ show running config 명령으로 전체 config를 가져와서 변수에 저장합니다.

filename = "c:\\backup\\" + hostname + "-" + backupdate + '.log'

 ▷ 파일을 저장하고 싶은 폴더에 파일명을 hostname과 백업 날짜를 해서, 텍스트 파일 형태로 이름을 지정합니다.

     여기에서는 backupdate라고 적혀있는 변수는 현재 날짜를 갖고 있는 변수라고 생각하시면 됩니다. 

     현재 시스템 날짜를 가져와서 변수에 넣어서 사용하시면 됩니다. 

configFile = open(filename,'w')

 ▷ 파일을 저장하기 위해서 file객체를 열고

configFile.write(run_config)

 ▷ running config 내용을 파일에 쓰게 됩니다.

configFile.close() 

 ▷ 마지막으로 파일 객체를 닫습니다. 


위와 같은 동작을 전체 장비 리스트를 다 백업할 때까지 반복하게 됩니다. 

아래의 코드는 실제 장비 리스트를 관리하는 파일입니다. 

계정은 공통 변수로 사용을 하게 되고, 각 장비의 이름과 ip를 지정해 놓았습니다. 


[ device.py ]

user1='admin'

pass1=‘zigipass'

dv='cisco_nxos'


CoreSW1={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.1'}

CoreSW2={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.2'}

ExtSW1={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.3'}

ExtSW2={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.4'}


ZIGI_devices = [CoreSW1,CoreSW2,ExtSW1,ExtSW2]


Posted by 네떡지기
DevOps/Programmability2017.05.01 09:49

안녕하세요.

 

이번 포스팅은 기존에 진행하던 Programmabiliy for Networker 라는 주제의 포스팅을..

다시 오랜만에 재개하기 위한 사전 동영상 포스팅입니다.

 

아래의 동영상은 Access-list를 관리하기 위한 방법으로 작성한 코드입니다.

차단하기 위한 별도의 IP리스트 파일을 관리를 하여,

기존의 있는 Access-list에 해당 파일에 있는 IP를 차단하는 역할을 해줍니다.

 

또한 이력관리를 위해서 앞에 Access-list Numbering을 ACL이 추가되는 현재의 날짜와 그 날의 순번대로 작성됩니다.

즉, 2017년 5월 1일에 작성되는 ACL의 경우에는 1705010000, 1705010001 과 같이 Accesss-list가 만들어집니다.

 

개인적으로 진행하는 스터디에서 다뤄질 소모임이기도 하고...

공부를 위한 부분이기도 하고..

6월에 진행되는 네전따 커뮤니티 세미나 발표를 위한 부분이기도 하고..

업무를 위해서 필요한 부분이기도 할...

Programmability for Networker 포스팅이.. 곧 다시.. 재개합니다. ^^

 

 

.

Posted by 네떡지기
분류없음2015.05.13 00:26

pyeapi, eapi, python, arista, example : Today Key 

이번 포스팅에서는 지난 번에 알아보았던  pyepai에서 제공하는 몇 가지 예제에 대해서 간략하게 알아보려고 합니다.

예제를 통해서 이러한 기능들도 사용할 수 있구나? 정도 ^^

무엇이든, 왜? 사용해야 하는지 아는게 중요할테니,

이번 포스팅에서는 몇 가지 예제를 통해서 왜? 써야 하는지를 생각해 볼 수 있었으면 합니다.

 


Arsita Python Client for eAPI (pyeapi) 예제


pyepai 예제 List

  • pyeapi를 설치하고 나면, 아래와 같이 몇 가지 예제를 코드를 제공합니다.

      여기에서는 simple과 유사한 기능을 하는 sysmac을 제외한 나머지 코드를 살펴보려고 합니다.

 

 

 

 

get-config.py

  • EOS 장비의 running-config와 startup-config 그리고 2개의 Config에 대한 비교 내용을 출력하는 예제입니다.

  • 해당 예제 코드를 실행하면 아래와 같은 결과를 볼 수 있습니다.

 

 

  •위의 실행 결과를 보여주는 코드는 다음과 같습니다.

 

 

  •pyeapi 라이브러리를 import한 이후에 node정보가 있는 configuration을 Load합니다.

     즉, 지난 pyeapi 첫 번째 시간에 얘기했던 configuration 파일을 default로 사용할 수도 있지만, 위의 예제처럼 원하는 파일을

     Load해서도 사용할 수 있습니다.

 

  •EOS 장비의 config를 가져오는 것은, get_config 메서드를 사용하며 매개변수로 running-config 혹은 startup-config를

     전달함에 따라서 알맞은 Config를 가져올 수 있습니다.

  •마찬가지로 2번째 매개변수로 'diffs'를 전달하게 되며, running-config와 startup-config를 비교한 결과 값을 출력할 수 있습니다.

  •하지만, 위의 결과 출력 값을 한 눈에 보기는 좀 어렵기 때문에 예제 소스의 출력 부분을 조금 수정하면 아래와 같이 보기 편하게

     나타낼 수도 있습니다.

 

 

 

simple

  •2번째 예제는 간단하게 장비의 MAC-Address를 가져와서 출력하는 예제입니다.

  •예제 코드는 직접 확인해보고 분석해보면 좋을 것 같습니다.  그렇게 길지도 않고 직관적으로 파악이 가능한 정도입니다.

 

 

 

vlans_api.py

  • 이번에는 Vlan정보를 출력하고, vlan을 생성 그리고 삭제하는 예제도 있습니다. 

       마찬가지로 예제 코드는 직접 확인해보시고 분석하시기를 추천해드립니다

 

 

 

      이번 포스팅에서는 첫 번째 예졔에서 약간의 부분을 빼고는 기술적인 부분은 거의 배제하고 올렸습니다.

      코드를 처음부터 다 짤 필요도 없으며, 다 짤 수 없어도 기존에 만들어진 예제를 보고 응용할 수 있으면 충분히 활용이 가능할 것입니다.

      그러기 위해서는 위아 같은 간단한 예제를 통해서, 이런 저런 다양한 기능에 대해서 미리 알아보는 과정이 필요하게 됩니다.

      반드시 예제로 주어진 코드는 한 번씩 살펴보고 예제 코드를 변형하여 자신만의 코드로 활용해 보시길 바랍니다. 

       

 

Posted by 네떡지기
분류없음2015.05.10 23:29

pyeapi, eapi, python, arista : Today Key 

 

Last Update : 2015.05.19 Windows에서 설치하기

이번 포스팅에서는 Arista EOS를 관리할 수 있는 방법 중에 하나로, 기존의 eAPI를 좀 더 쉽게 사용 할 수 있도록 제공해주는

 

Python 라이브러리인 pyeapi에 대해서 다뤄봅니다.

pyeapi를 이용한 EOS 장비 관리를 위한 환경 구축부터 몇 가지 예제를 앞으로 몇 번의 포스팅을 통해서 알아보게 됩니다.

또한, pyeapi를 사용하여 Ansible을 사용하는 예제는 Automation for Networker 시리즈의 포스팅으로도 알아볼 예정입니다.


 


Arsita Python Client for eAPI (pyeapi)


Arista EOS Command API(eAPI)

  • EOS Version 4.12부터 사용 가능

  • Management plane application을 구축하여, 장비의 상태 정보나 설정을 손쉬게 관리할 수 있도록 함.

 

Python Client for eAPI

  • eAPI 작업을 보다 쉽게 구축하기 위해 만들어진 Python Client.

  • 원격지의 EOS Node(장비)에 대해서 eAPI의 HTTP/S 를 통한 제어가 되도록 설계 됨.

 

 


○ 설치하기

  •pip를 사용하여 설치하거나, Github를 통해서 설치가 가능하다.

  •본 포스팅에서는 Github를 통해서 pyeapi를 설치한다.

  •아래와 같이 Github를 통해서 pyeapi를 다운 받은 후에, install 한다.

 

 

 

 Windows 에서 설치하기

 

 

 

 

 

 

 

 

 

○ pyeapi 초기 설정하기

  •pyepai를 사용하기 위해서는 관리하기 위한 Node에 대한 설정을 Configuration 파일에 해야 한다.

  •Configuration File은 INI Style로 구성하며, 다수의 Node를 포함 할 수 있다.

  •Configuration File은 ~/.eapi.conf 에 설정하며, 설정 파일 구성은 다음과 같다.

 

 [connection:zigi1]
 host: 10.1.1.11
 username: zigi
 password: zigi
 transport: https

 

 

 

 

○ pyeapi로 장비 Version 확인하기

  •pyeapi 라이브러리를 먼저 Import 한 후에 관리하고자 하는 장비를 연결하는 데,

     이 때에 Configuration 파일에서 지정한 Naming을 사용한다.

  •장비를 연결한 후에는 Node에 대한 인스턴스를 리턴한다.

  •위의 실행 예제에 대한 결과 값은 다음과 같다.

 

 

 •위의 결과 값은 사용자가 알아보기는 쉽지 않기 때문에 적절하게 다음과 같이 결과 값을 가공하면 좀 더 쉽게 알아볼 수 있다.

   

 

 

다음 포스팅에서는 pyeapi를 사용한 보다 다양한 예제를 다뤄보겠습니다.

 

 

 
Posted by 네떡지기
DevOps/Automation2015.05.02 04:47

Automation, Arista, Ansible, Configuration  : Today Key


Automation for Networker의 8번째이자, Ansible의 7번째 포스팅입니다.

이번 포스팅에서는 실제 가장 적용이 많이 될 만한, Ansible을 활용한 Configuration 백업에 대한 예제입니다.


 

 

Automation Tool인 Ansible을 활용한 Arista Config 백업하기

 


지난 번까지 Ansible에서 eAPI Library를 활용한 Arista 장비를 제어하는 예제를 알아보았습니다.

 

이번에는 제일 유용하게(?) 사용될만한 Configruation 백업에 대한 예제를 다뤄봅니다.

지난 번에 다뤄진 예제와 비슷한 듯 하지만, 몇 가지 더 고려해야 할 만한 부분이 있는 예제입니다.

 

 

< YML  작성하기 >

  - Configuration을 백업하기 위한 commands를 vars로 입력하는 데, enable을 먼저 한 이후에 show running-config를 한다.

    왜냐하면, show running-config를 실행하기 위해서는 enable 모드에서 사용하기 때문이다.

  - 기본 ansbile을 사용하기 위한 Arista Library의 eos_command에서는 json 모드만 지원한다.

    하지만, show running-config는 json을 사용하여 실행하려고 하면 eAPI에서 json으로는 해당 command를 지원하지 않기 때문에

    eos_command에서 json 방식이 아닌 text 방식으로 eAPI에 command를 전송하도록 변경해야 한다.

    (현재도 별도의 라이브러리의 변경없이 text방식이 지원된다면, YML에서만 수정을 해도 된다. 혹은 추후 지원 시..)

  - YML을 작성하면서 언급한 위의 show running-config를 하기 위한 모드 변경 및 방식 변경과 관련한 부분은 arista에서 지원하는

    eAPI Command를 통해서 웹접속으로 직접 명령과 결과 확인이 가능하다. 

 

---
-  name: ARISTA-ANSIBLE
   hosts: arista
   vars:
     commands:
       - enable
       - show running-config

   tasks:
     - name: ZIGI_Arista_eAPI_Command
       eos_command1: eapi_username={{eapi_username}}
                    eapi_password={{eapi_password}}
                    eapi_hostname={{eapi_hostname}}
                    eapi_port={{eapi_port}}
       args: { commands: "{{ commands }}" }
       register: result

     - debug: var=result
     - name: var=result
       template: src=my2.j2 dest=./result2

 

 

 

< Template >

   - 기존의 예제처럼 결과 값의 result의 output에 대한 템플릿을 사용할 수도 있지만,

     아래와 같이 템플릿을 지정하면, 실제 장비에 바로 설정이 가능한 config 형식으로 결과 값을 만들 수 있다.

     (결과 값으로 반환된 값을 Python 데이터 타입으로 확인해보면, 아래와 같이 템플릿으로 지정할 수 있다. )

 

 {{ result['output'][1]['response']['output'] }}

 

 

 

 

< Playbook 실행하기 >

   - 위에서 작성한 YML과 Template을 가지고 실행하면 다음과 같이 정상적으로 실행되었음을 알 수 있다.

   - 그리고 실제 결과 값은 아래와 같이 조금은 한 눈에 들어오지 않게 출력해준다.

 

 

 

 

< 결과 확인하기 >

    - 이제 템플릿을 사용하여, 가공한 결과 값의 파일(result2)를 확인해 보면, 실제 장비 Configuration을 백업하던 것처럼

      바로 적용이 가능하도록 Config가 백업된 것을 확인할 수 있다.

 

.

 

 

Posted by 네떡지기
DevOps/Automation2015.04.19 00:24

 

Ansible Arista  vEOS eAPI  : Today key


Automation for Networker의 7번째이자, Ansible의 5번째 포스팅입니다.  

이번 포스팅은 Ansbile을 사용하여 Arista 장비를 실질적으로 제어하는 예제에 대해서 다뤄봅니다.

실질적인 예제를 통해서 Ansbile을 활용하는 데, 조금은 익숙해질 수 있기를 바랍니다.

기본적으로 여기서는 Arsita 장비에 대해서 다뤘지만,

다른 벤더에서도 유사하게(지난 번 포스팅 처럼, 혹은 다루지 않은 NXAPI 등을 사용하여) 사용할 수 있을 것이기 때문에

해당 Library를 제공하는 모든 장비에 대해서 적용해 볼 수 있을 것 같습니다.


Automation Tool인 Ansible을 활용한 Arista 장비 제어


지난 Ansible Part 3 포스팅에서는  Ansbile을 이용한 Arista 장비 제어와 관련한 초기 환경 구축 설정에 대해서 알아보았습니다.

이번 포스팅에서는 실제 Ansible을 통한 Arista 장비를 제어하는 예제를 살펴봅니다.

전체 예제는 Ansible 관리 서버와 Arista VM 1대를 이용하여 진행을 하게 되며, 개인 PC에서도 동일하게 구성하여 테스트가 가능합니다.

 

 

예제1) VLAN 생성하기

 

[ YML 작성하기 ]

    - YML의 기본 작성 형식에 따라서 이름과, 적용할 Hosts에 대해서 지정한다.

    - 실제 VLAN을 생성할 Tasks를 만드는 데, VLAN을 다루는 예제이기 때문에 VLAN을 관리하기 위한 Library인 eos_vlan을 사용한다.

    - vlan name을 지정하고, vlanid를 설정한다.

 

 

 

[ YML(Playbook) 실행하기 ]

    - 위에서 작성한, Playbook을 실행하면 아래와 같이 정상적으로 작성이 성공한 것을 볼 수 있다.

    - 기존에 존재하지 않은 VLAN이었기 때문에 Task에서 Changed로 체크된다.

    - ansible_hosts에 설정된 host는 veos1 1대밖에 없었기 때문에, 1대에 대해서만 적용된다.

 

 

[ Arista에서 확인하기 ]

    - VLAN 정보를 확인해면, 아래와 같이 지정된 VLAN 이름을 가진 10번 VLAN이 생긴 것을 확인할 수 있다.

 

 

 

예제2) VLAN 삭제

 

[ YML 작성하기 ]

    - 예제 1과 모든 부분은 동일하며, 단지 state가 추가되었다.

    - state는 반드시 eos_vlan을 사용하기 위해 반드시 설정되어야 하는 속성은 아니며, 미 설정 시에 default로 configured 상태이다.

    - 즉, 예제 1번에서는 state를 사용하지 않았지만, default로 configured 상태이기 때문에 해당 vlan이 설정되게 된다.

    - 반면에 2번의 에제에서는 vlan 10에 대해서 unconfigured를 state로 설정하여 해당 config를 제거하게 된다.

 

 

 

 

[ YML(Playbook) 실행하기 ]

    - 위에서 작성한, 예제 2의 Playbook을 실행하면 예제 1ㅘ 마찬가지로 동일하게 정상적으로 작업이 성공됨을 볼 수 있다. 

 

 

 

[ Arista에서 확인하기 ]

    - 아래의 결과 중의 위의 결과는 예제 1을 실행했을 때의 vlan  10이ㅣ 생성된 거을 확인할 수 있고,

      아래의 결과가 예제 2를 실행하여 vlan 10이 제거된 것을 확인할 수 있다.     

 

 

 

 

예제3) Interface 설정

 

[ YML 작성하기 ]

    - 예제 3은 2개의 Task로 이루어져 있습니다.

    - 첫 번째  task는 Switchport를 설정하는 예제입니다. 특정 인터페이스에 vlan 10으로 Access 모드로 적용합니다.

    - 두 번 째 task는 특정 인터페이스에 Description을 적용합니다.

    - 각 Task는 eos_switchport와 eos_interface의 속성을 사용해서 YML을 작성하게 됩니다.

 

 

 

 

[ YML(Playbook) 실행하기 ]

    - 예제 3을 실행하면, 2개의 Task로 구성되어 있기 때문에 각각 Task를 실행하게 되며, 2개의 Task 적용이 되었음을 확인할 수 있습니다.

 

 

 

 

[ Arista에서 확인하기 ]

    - Eh2 인터페이스에 대해서 vlan 10과 ZIGI_DESC라는 Descritption이 생성됨을 확인할 수 있습니다.

 

 

 

 


 

 이번 포스팅에서는 Ansible을 사용하여 Arista 장비를 제어하는 예제를 3가지 살펴보았습니다.

 Ansible에서 eAPI를 사용하여 Arista 장비를 제어할 수 있는 Library를 통해서 예제에서 살펴본 것 이외의 다양한 설정을 할 수 있습니다.

 하나씩 그러한 예제를 살펴보면, Ansible을 네트워크 장비에서도 좀 더 효율적으로 사용 할 수 있을 것 같습니다.

 

 

 

Posted by 네떡지기
분류없음2015.04.06 22:59



PyEZ라는 Junos OS 장비를 다룰 수 있도록 해주는 Python용 micro-framwork라고 하는 Library를 다뤄봅니다.

이번 포스팅에서는 PyEZ가 무엇인지 아주 간단히, 그리고 아주 간단한 예제를 통해서 가볍게 접근해봅니다. 



Juniper PyEZ Library


○ PyEZ를 통한 Configuration 관리

    • PyEZ를 통한 설정 관리 : Unstructured / Structured
    • Unstructured  
          - 지원되는 특정 포맷 형식에 Junos Config를 전달하여 관리
          -  다수의 변수를 가진 Template을 사용하면 보다 쉽고 빠르게 사용 가능
    • Structured
          - 설정 / 속성에 접근하는 프로그래밍 방법을 잘 정의한 추상화 자원을 사용
      - 추상화 자원은 Puppet이나 Chef같은 IT frameworks와 유사하다.

 

 

 

 

 

○ Unstructured
 • Unstructed 변경은 Config 클래스를 사용 (jnpr.junos.utils.config.Config)
 • Config 클래스는 load() 메서드를 제공하여, snippet 혹은 Template을 불러오는 역할
 • Configuration의 Data로, Strings, files, XML 객체, Jinja2 Template 객체를 사용
       - Configuration Data  snippets와 Jinja2 Template가 포함될 수 있다.
  • String, Files, Jinja2 Templat에 들어가는 데이터 포맷은 ASCII Text,
     Junos XML elements, Junos OS set command가 지원된다.
  • 각 데이터 포맷은 load() 메서드 사용 시, format 매개변수를 사용하여 지정하거나,   설정 파일의 적절한 확장자를 지정하여 설정 가능.

 

 

 

 

○ PyEZ를 통한 Configuration 변경 예제 1

 • Unstructure 방식으로 Junos Device를 설정을 바꾸는 에제를 살펴본다.

 • Unstructure 방식을 사용하기 위해서 Config Class를 먼저 import 한다.

 • Junos Device에 연결하고, 해당 Device를 매개변수로 한 Config 객체를 만든다.

 • Junos의 Config 변경 방식 중의 Set Commands를 사용한 변경 방식을 사용을 위한 Set 명령을 만들고,

     Config 객체에서 이를 Load한다. 이 때에 기본 Configration Data Format은 XML이므로, Set으로 변경해준다.

 •변경될 Config를 확인하고, 장비에 적용한다.

 

 

 • 위의 Code를 실행하고 나면, Juniper 장비에는 아래와 같은 설정이 들어가게 된다.

 

 

 

 

○ PyEZ를 통한 Configuration 변경 예제 2

 • 2번째 에제는 Text 형태 포맷의 Configuration을 적용하는 예제이다.

 •Configuration의 TEXT를 별도의 파일로 만들어서 불러올 수 있기도 하고, 아래와 같이 Code에 Text 변수로 만들어서

    해당 변수를 불러와서 설정이 가능하다.

 •Configuration만 Text 형태로 작성하여 Format을 Text로 지정하는 것 이외에 기존과 거의 유사하다.

 •아래 Code를 실행하게 되면, Loopback 0으로 Interface가 1개 생성된다.

 

 

 

 

 

○ PyEZ를 통한 Configuration 변경 예제 3

 •3번째 예제는 Jinja 형식의 Template으로 Juniper 장비의 Configuration을 수정하는 예제입니다.

 •예제에서 사용된 Template은 아래와 같습니다.

    Junos에서 Hostname을 변경하기 위한 Config이며, Jinja 형식을 사용하여 hostname의 값을 변수 형식으로 사용합니다.

 

 

 

 •이번에는 Template를 file에서 불러오기 때문에 configuration 객체에서 Load 시에, Template 파일의 경로를 지정합니다.

 •Jinja에서 사용된 변수에 값을 적용하기 위해, load 시에 해당 변수에 들어갈 값이 있는 변수를 매개변수로 넣습니다.

    즉, Load 시에 Template File의 Path와 Template에서 사용된 변수를 할당합니다.

 •기타 나머지 실행은 동일합니다.

 •아래의 Config를 적용하고 나면, Juniper 장비의 Hostname이 변경됩니다.

 

  •다음은 위의 코드를 실행 한 후의 Junos 장비의 Hostname이 바뀐 내용입니다.

 

 

 

 

Posted by 네떡지기
DevOps/Automation2015.03.23 21:24

 


 

Automation for Networker로 다시 또, 오랜만에 포스팅을 하게 됩니다.

이번 포스팅은 Automation Tool인 Ansible을 활용하여 Cisco 장비를 제어하는 예제입니다.

기본 Ansible을 활용하여 Cisco 장비를 제어하는 것은 NX-API를 사용하는 데, NX-API는 제한적으로만 장비에서 지원되기 때문에

아직까지는 사용하는 데 있어서 제한이 있습니다.

이를 위해 SNMP를 사용하여 장비를 제어할 수 있도록 해주는 라이브러리를 사용하여 Ansbile로 시스코 장비를 다뤄봅니다.

 

원래 지난 Automation for Networker 5에 이어서 Arista 장비에 대한 예제를 다루려고 했으나,

네트워크 타임즈에 2월호부터 기고 중인 Programmability for Networker의 4월호(드디어 마지막. ㅠㅠ)의 내용들로 이루어지기

때문에 Arista 장비의 포스팅은 4월달에 포스팅 예정입니다. ^^;

 



Automation Tool인 Ansible을 활용한 Cisco IOS 장비 제어


 

Cisco 장비의 경우에는 Nexus에서 NX-API를 활용하여 Ansible을 통한 장비 제어가 가능하다.

하지만 NX-API를 사용할 수 없는 일반 IOS에서도 SNMP를 사용하여 Cisco 장비를 제어할 수 있도록 제공해주는 라이브러리가 있다.

Git-hub에서 아래의 링크에서 라이브러리를 다운 받으면, 시스코 장비에서 SNMP 설정만으로 Ansible을 통한 제어가 가능하다.

물론 현재는 Alpha Version의 코드이기 때문에 제약사항과 정상적으로 구동이 되지 않는 점이 있기는 하다.

하지만 추가적으로 개선이 될 부분이기도 하며, 또한 코드를 직접 개선하여 사용도 가능하다.  

 

※ 라이브러리 다운받기  https://github.com/networklore/ansible-cisco-snmp

 

 

 

 

그럼 ansible cisco snmp 라이브러리로 실제 시스코 장비를 제어해보자.

우선 시스코 장비에 Ansible을 사용해서 제어할 SNMP의 설정이 필요로 하다.

 

Cisco 장비 설정 (SNMP v2 기준)

  snmp-server community zigisnmp RW

 

단, 시스코 장비에는 기존에 설정하던, 단 한 줄의 snmp 설정만 해주면 된다.

이제 Ansible 서버에서 Playbook을 만들어 보자.

여기에서는 2개의 에제를 다룰 것이며, 각 에제는 별도의 라이브러리를 사용하여 시스코 장비를 제어하게 된다.

 

 


 

 

예제 1 : cisco_snmp_interfae 라이브러리 사용하기 


 

첫 번째 예제는 cisco_snmp_interface를 활용한 Playbook이다.

snmp v2를 사용하기 때문에, 버전은 2c로 지정을 하고 community 값은 시스코 장비에서 설정한 값을 지정한다.

그리고 interface를 제어하기 위하여 어떤 Interface를 제어할지 인터페이스를 지정한다.

원하는 description을 넣을 수 있으며, Interface 상태를 Admin Up/Down을 할 수도 있다.

 


그럼 이제 해당 Playbook을 Ansible 서버에서 실행해보자..

아래와 같이 Playbook을 실행하면

changed=1로 표기되면서 정상적으로 task가 수행되어 변경되었다는 것을 알 수 있다.

 

이제 실제 장비에서 원하는 설정이 되었는지 확인한다.

아래의 sh int desc은 Ansible에서 Playbook을 실행하기 전과 후의 상태이다.

G0/2의 상태가 up/up 이고, description이 없었다가

이후에 G0/2의 상태가 admin down / down으로 변경되고 Interface의 description가 생긴 것을 볼 수 있다.

실제 장비의 로그에서도 snmp에 의해서 설정이 변경된 걸 알 수 있다. (10.1.1.100은 Ansible 서버이다)

 

 

 


예제 2 : cisco_snmp_vlan 라이브러리 사용하기 


첫 번째 예제가 Interface 라이브러리를 사용한 것에 비해, 두 번째는 vlan 라이브러리를 사용해서 제어해 본다.

Playbook 파일을 보면, 나머지는 거의 동일하지만, vlan 관련된 부분만 다르다.

여기서 다루는 2번째 예제는 2개의 task를 수행하게 된다.

 

첫 번째는 Task는 VLAN을 생성한다.

생성하고자 하는 vlan_id와 vlan_name을 지정한다. 그리고 상태(state)에 Present로 지정하게 되면 기존에 있으면

원하는 설정을 변경할 수 있고, 기존에 없던 vlan이면 새로운 vlan을 생성하게 된다.

 

두 번째 Task는 VLAN을 삭제한다.

삭제하고자 하는 vlan_id를 지정하고 상태(state)를 absent로 지정하면 해당 vlan_id는 삭제가 된다.

 

 

 

마찬가지로 Playbook을 실행하면 각각 2개의 Task가 정상적으로 changed 되었다고 표기된 것을 볼 수 있다.

 

 

 

아래는 장비에서 해당 결과를 확인하는 화면이다. 

먼저 Playbook을 실행하기 전에 5번 VLAN이 있는 것을 확인할 수 있다.

 

 

  

Playbook을 실행하게 되면,  5번 VLAN 삭제되고, VLAN 20번이 ZIGI_VLAN이라는 이름으로 생성되어 있다.


 

 

Posted by 네떡지기
DevOps/Automation2014.12.30 21:54

 


Ansible 2번째 포스팅입니다.

Automation for Networker의 4번째 포스팅이기도 합니다.

실습하면서 포스팅 준비를 해 놓은 건, 한 달쯤 전인 듯 싶은데.. 이제서야 올리네요.

다른 내용도 조금씩 조금씩 보다보니,

포스팅이 다시 더뎌졌지만.. 그래도 조금씩 더 채울 수 있도록~ ^^

좋은 정보를 나눌 수 있도록 노력해보겠습니다.


  Ansible Example 4


Ansible 4번째 예제는 하나의 Playbook 파일을 나눠서 구성해 봅니다.

기본적으로 실행하게 되는 Playbook은 site.yml로 가장 최소화하게 구성을 하고,

Task와 Variable 등은 각각의 폴더에 구조적으로 나누게 됩니다.

 

이번 예제에서 살펴볼 구조는 아래와 같습니다.

 

 

 기본 폴더에 site.yml 파일을 놓고,

 하위로 roles 폴더에서 관리를 하게 되는 데, roles 안에서는 roles에 따라서 필요한 폴더를 생성하게 됩니다.

 여기서는 zigi_roles1이라는 role로 관리를 합니다.

 하나의 role안에는 task, template, var 등이 존재 할 수 있습니다.

 

 


site.yml 코드 보기

 

 

roles 항목에 실행하고자 하는 roles의 이름을 입력합니다.

여기서 사용되는 이름은 roles 하위에 관리자가 지정한 폴더 단위로 관리가 됩니다.

 


task 코드 보기


 

 

task는 기존 task 설정과 크게 다르지 않습니다.

기존에 variable을 분리한 것과 동일한 item은 별도로 분리하게 됩니다.

 


variable 코드 보기


 

 

 

variable에 대해서 정의합니다.

 


template 코드 보기


 

 

 

Template은 기존과 다른 점은 별도로 없습니다.

 


실행 결과 보기


 

구성이 완료되면 아래와 같이, site.yml로 실행을 합니다.

 

 

 

실행 이후에 결과값을 보면, 원하는 결과 값이 만들어졌음을 알 수 있습니다.

 

 

처음에 언급한대로, site.yml은 최소화 시키고

그 안에 사용되는 task, variable 등은 기능별로 나누어서 관리를 하는 것이 기능이 복잡해질 수록 더 편해집니다.

또한, 기존에 만든 내용을 각각 재사용할 수도 있습니다.

객체지향에서 추상화에 따른 역할 분리와 비슷하다고 볼 수 있을 것 같습니다.

 

 

 


 


   Ansible Example 5


Ansible 5번째 예제는 하나의 Playbook 내의 Template에서

원하는 조건에 따라서, 해당 Template 내용을 적용할지, 안할지를 지정할 수 있도록 해보는 예제입니다.

Ansible에서의 조건문이라고 보면 될 것 같습니다.

조건문에 대한 값은 Variable에서 선언할 수 있습니다.

 

아래 예제와 결과를 보시면 좀 더 쉽게 이해 할 수 있을 것입니다.

 

 


task 코드 보기


 

 


variable 코드 보기


 

 

variable을 보면, VLAN 30이라는 항목이 true 혹은 false으로 지정되어 있는 것을 볼 수 있습니다.

이 부분이 조건에 대한 값이라고 볼 수 있습니다.

 


template 코드 보기


 

 Template에서 보면, vlan 10 ,20은 기본적으로 있는 반면에

vlan 30에 대한 정의는

 

{% if 조건 %} 

    ~~

{% endif %}

 

로 둘러 쌓여 있음을 볼 수 있습니다.

조건문에 둘러쌓인 내부는 조건이 참인 경우에만 적용되는 template 입니다.

 

 


실행 결과 보기


 

 

실행을  해보면, 정상적으로 동일하게 실행되었음을 확인할 수 있습니다.

실행에 만들어진 파일의 내용을 보면 아래와 같습니다. 

 

 

ZIGI5_1은 vlan 30이 True이었기 때문에 정상적으로 vlan 30 부분이 만들어졌습니다.

 

 

반면에, ZIGI5_2는 VLAN 30이 False였기 때문에 VLAN 30에 대한 부분이 만들어지지 않았음을 볼 수 있습니다.

 

 

 

Posted by 네떡지기

티스토리 툴바