분류없음2017.03.08 12:36

안녕하세요.


이번 포스팅은 간단한 동영상으로 올려봅니다.


앞으로 포스팅을 위해서 준비 중인(?) ACI와 관련한 간단한 동영상입니다.


ACI에서 EPG를 생성하고, Contract을 생성하고, Contract을 맺어주기 위한 작업을 JSON을 통해서 진행을 하는 내용입니다.

다만, JSON을 생성하는 것을 EPG와 Contract를 변수로 하여,

Ansible을 통해서 변수로 지정된 EPG와 Contract을 생성 및 연결하는 JSON을 생성하고 이를 통해서 ACI에 적용합니다.

JSON을 수동으로 변경해서 만드는 것에 비해서 잘못 수정할 부분이나,

보다 많은 부분에 적용해야 하는 경우가 발생하는 경우에 조금 유용하게 사용할 수 있지 않을까 싶습니다.

물론 이 방법 이외에도 추가적으로 보다 유연하고 편리하게 사용하게 사용하기 위한 방법들에 대해서는 고민 중입니다.

 

 






Posted by 네떡지기
DevOps/Automation2017.02.16 19:38

이번 포스팅은 예전에 정리했던 Ansible 관련한 내용 중에 Install이 빠져 있어서 현재 기준으로 간단하게 포스팅을 합니다.

아마 Ansible을 이용한 다른 포스팅을 시작하게 될 듯 싶어서, 다시 설치를 하는 김에  기존에 설치 내용이 포스팅에 없어서, 

정리를 해봅니다.

  - 기존 포스팅은 ZIGISPACE.NET에서 ansible로 검색하시면 됩니다! ^^


 

 

* 설치환경 : CentOS 7

 

1. Extra Packages for Enterprise Linux 

 Fedora를 쓰는 경우에는 직접 Ansible이 설치가 가능하지만, Fedora 계열의 Redhat이나 CentOS 등을 사용하는 경우에는

먼저 epel-release RPM을 설치.

   * epel = Extra Packages for Enterprise Linux

 rpm -iUvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm 

 

2. Yum을 이용해서 Ansible을 설치.

 sudo yum install ansible

 

3. Ansible 설치 확인

 ansible --version

 

○ 각 Distro에 따른 Ansible 설치는 아래의 홈페이지를 확인하시면 됩니다.

  - Ansible 설치 : http://docs.ansible.com/ansible/intro_installation.html#id13

 

 

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 네떡지기
분류없음2015.04.24 23:22

Ansible Arista  vEOS eAPI  : Today key


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

이번 포스팅은 Ansbile을 사용하여 Arista 장비의 상태 값을 가져오는 예제입니다. 

 

 

지난 번에 간단한 테스트까지만 해두고 놔두었다가, 오늘 지인의 물음에 의해서 다시 점심시간에... 후다닥..

다시 테스트하고... 간단하게 나마.. 포스팅해봅니다.


 

Automation Tool인 Ansible을 활용한 Arista 상태 값 확인


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

이번에는 동일하게 Library를 사용하여 Arista 장비의 상태 값을 확인하는 예제를 다뤄봅니다.

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

 

 

 

예제1) Version 정보 확인

 

[ YML 작성하기 ]

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

    - eAPI에서 JSON을 사용한 eos_command를 적용하기 위해, eos_command를 라이브러리를 사용한다.

    - 적용하고자 하는 command를 vars에 지정한다. 아래의 예제에서는 1개의 명령어만 있지만, 여러개를 지정할 수 있다.

    - register를 사용하여, Command한 결과 값을 변수처럼 저장하여 사용할 수 있다. 

      이렇게 저장된 값은 template, action, statements에서 사용하게 된다.

    - 그리고, Playbook 실행 시에 결과 값을 볼 수 있도록 debug에 해당 결과 값을 출력하게 하였다.

    - 마지막으로 결과 값을 템플릿을 사용하여 파일로 생성할 수 도 있다.

 

 

 

※ 마지막의 action 항목은 Ansible 0.8 이후부터는 anction 대신에 다음과 같이 사용해도 된다. (결과 값은 동일)

 

 template: src=my.j2 dest=./result1

 

 

 

 

[ Template ]

    - Playbook에서 사용된 결과 값에 대해 파일로 저장하기 위해서 사용한 Template 파일을 보면 아래와 같다.

    - result에서의 'output'에 대한 값만을 결과값 내용으로 취한다.

      무슨 내용인지는 아래의 실행 결과와 생성된 파일의 내용을 보면 보다 이해하기 쉽다.

 

 

 

 

[ YML(Playbook) 실행하기 ]

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

    - Debug에서 보면, show version에 대한 결과 값을 확인할 수 있다.

      결과 값은 eapi의 json을 사용하여 나온 결과 값으로 출력되게 된다.

    - 결과 값에서서 보면 result안에 output이라는 항목이 이고, 실제 이 output이 원하는 show version에 대한 내용이다.

      위에서 본 template에서 result안의 output라고 지정한 이유는 이 때문이다. 실제 아래 생성된 결과 파일의 내용을 보면

      Debug에서 볼 수 있는 전체 결과가 아닌 output에 대한 결과값만 저장되었음을 볼 수 있다.

 

 

[ 생성된 결과 파일 확인하기 ]

    - 위의 결과 값 중에 output에 대한 내역에 대해서만 결과 파일로 저장된 것을 확인할 수 있다.

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 네떡지기
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/Automation2015.03.21 18:42

○ 자동화 도구(Automation Tool)

      - 자동화 도구로 쓰이는 Puppet, Chef, Ansible, Salt 에 대한 간단한 비교 장표입니다.

 

 

 

 

Posted by 네떡지기
DevOps/Automation2015.03.09 22:39

 

Ansible Arista 제어

 

거의 한 달여만의 포스팅이자, Automation for Networker 시리즈로는 거의 3~4달여만 남기는 것 같습니다.

이래 저래.. 일도 있고, 2월부터 4월까지 예정중인 네트워크 타임즈 기고 건 때문에 조금 더디게 정리하고 있기도 합니다. ^^;

이번 포스팅은 4월 네트워크 타임즈 기고에서도 다뤄지게 될 내용인, Ansible을 통한 Arista Switch를 제어하기의 첫 번째 시간인

환경 구축입니다.  다음 포스팅은 이 환경 구축을 통한 실제 Ansible로 Arista swtich 제어하는 에제를 다루게 될 예정입니다.

길이는 무척이나 짧지만, 인고의 삽질 끝에 얻어낸 축약된 내용입니다. ^^;


Ansible로 Arista Switch 제어하기 

 

1. Arista 장비에서 EOS Command API를 활성화

    ZIGI-ARI# management api http-commands

    ZIGI-ARI(config-mgmt-api-http-cmds)# no shutdown

 

 

2. Ansible에서 Arista 장비를 SSH 통해서 제어하기 위해서,  Ansible Control Node가 Arista Linux Shell에 직접 접근하도록 구성.

        - Ansible Control Node는 Arista EOS Node에 Password를 입력하지 않고 SSH Key를 통해서 접속하도록 구성

    2-1 Ansible에서 사용할 SSh 접속용 User 생성

    2-2 Ansible Control Node에서 SSH Key를 전송하기 위한 디렉토리를 생성 후, 권한 설정

 

 

 

 

 

3. Ansible Control Node에서 SSH Key를 Arista EOS Node로 전송 후, SSH 접속 테스트

         - Key를 접속하기 전에는 SSH 접속 시, Password를 입력해야 하지만 Key 전송 후에는 바로 접근 가능

 

 

 

 

4. Arista 장비에서 Ansible 사용자가 key를 이용해서만 Login하도록, 재부팅 시에 Password를 할당하지 않게 설정한다.

 

 

 

 


 

● 라이브러리 종속성

     - Ansible을 사용하여 Arista Switch를 제어하기 위한 설치 과정에서 아래와 같은 종속성이 있기 때문에 각각 모두 설치가 필요하다.

 

 

※ 초기에는 devops extension을 설치하였지만, 현재는 arista.eos로 대체

 

 

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 네떡지기
DevOps/Automation2014.12.08 10:22

 


기존에 포스팅을 시작한 Puppet에 이어서 비슷한 자동화 Tool인 Ansible에 대한 정리입니다.

Puppet를 정리를 시작하다가, 잠깐 다른 부분을 정리하다보니 Ansible 부분을 다시 먼저 정리하기 시작했습니다.

기존 Puppet도 마찬가지고 Ansible도 함께 포스팅이 될 예정이며 제목은 Automation for Networker이라는 이름으로

통합 포스팅이 될 예정입니다.

Automation Tool이 Network보다는 System쪽에 보다 촛점이 맞혀져 있겠지만,

제 Posting에서는 보다 Networker를 위한 중심으로 진행될 예정입니다. ^^;

 

수정해야 할 부분, 보완해야 할 부분이 있으면 알려주시면 감사하겠습니다.


 

 

 

Ansible

  - 시스템 구성(환경 설정), 초기 소프트웨어 Deploy는 물론 다운타임이 없이 Update에 따라 지속적인 Deploy가 가능.

 - 단순하고, 사용하기 편리하도록 하는 것이 Ansible의 목표

 - 에이전트가 없는 구조. 에이전트 관리에 신경을 쓰지 않아도 됨.

 - SSH를 통한 통신.

 - DevOps Tool

 - 네트워크 엔지니어 활용 방법

       : Configuration Management / Network Configuration Template

 

 

Ansible 기능

  - Packge management : apt, yum, ..

  - Remote execution : command, shell

  - Service management : service

  - File handling : copy, template..

  - SCM : get_url, git, subversion...

 

 

Ansible 설치

  - 별도의 Agent가 없기 때문에 서버에서만 Ansible을 설치

     ※ 단, Agent에 의해 관리받는 Host가 Python 2.4 이하 버전 사용 시에는 simplejson 모듈 설치 필요.

 

 


Ansible File


 

 

Inventory File

  - Remote Server에 대한

  - /etc/ansible/hosts/Ansible-hosts [Default]

  - '-i' 옵션으로 별도의 inventory File 지정 가능

  - Remote host Grouping 가능

 

Template File

  - 실제 처리하고자 하는 업무에 대한 Template

  - Jinja2 적용 가능(Template Task인 경우)

  - 관례상 확장자는 '.j2'

 

Playbook File

  - ansible 환경 설정 및 배포

  - yaml 문법을 사용하여 기술

  - 조건(when), 반복(with_items), Variables, include, register 지원.

  - YAML의 제일 첫 줄은 '---'로 시작하며, 이는 YAML 포맷의 시작 지점을 뜻함.

 - List의 동일한 Member들은 '-' 문자를 먼저 쓰고 뒤에 항목들을 입력한다.

 - 각 항목들의 Indent는 동일하게 구성(2칸)

 - Dictiory 혹은 Hash라고 부르는 key:value 의 형식으로 사용된다.

 - 다양한 방식의 boolean 값을 사용할 수 있다.

     ex) yes , no, True, TRUE, false

  - 하나 이상의 'play'를 가진다. (play는 여러 호스트들에 정의된 'role'과 'task'를 매핑하는 역할)

        ‡ task : ansible module을 호출하는 단위(필수)

 

 


YAML & Jinja2


 

YAML

  - 사람에게 친숙한 데이터 직렬화 양식으로 모든 프로그래밍 언어에서 사용

     * Site: http://www.yaml.org/spec/1.2/spec.html#id2759768

 

Jinja2

  - Jinja2 is a modern and designer-friendly templating language for Python, modelled after Django’s templates.

  - Jinja2 is a full featured template engine for Python.

    It has full unicode support, an optional integrated sandboxed execution environment, widely used and BSD licensed.

     * Site : http://jinja.pocoo.org/


 

 

 

 


Ansible Example 1


  우선 Ansible을 실행하기 위한 아주 기본 구성은 하나의 Template 파일(.j2), Playbook(.yml)로 구성하여 예제를 실행해봅니다.

  Playbook 파일의 대략적인 구성은 아래와 같습니다. 

hosts :

vars:

   구분자 : 실제 대입될 값

tasks:

  - name : Task명                                                                       - 출력 시에, 실행한 Task 이름을 표기

    template: src=Template파일(경로 포함)  dest =완성된 파일(경로포함)

 

실제 예제 파일의 내용입니다. . 

Template파일에는 기본적인 Configuration 설정이 있고, Hostname 부분에만 {{ }}로 묶인 것이 있습니다.

이 부분이 Template에서 변경이 이뤄질 부분입니다.

 

아래 Playbook 파일을 보면, vars 란에 hostname이라는 부분이 있습니다. 이것이 Template에 {{ }} 안에 변수명입니다.

즉 Template의 {{ }} 선언된 변수명이 Playbook 내에서 Vars 항목에 선언되어 있어야 합니다.

task는 실제 처리할 내용입니다. myT.j2(Template) 내용을 처리해서, hostname.cfg라는 파일로 만들어지게 됩니다.

 

이제 Playbook을 실행해봅니다.

실행은

    ansible-playbook playbook_file

으로 실행하면 됩니다.

 

정상적으로 실행된 것을 확인할 수 있으며(실제 처음 실행하게 되면, Ok뒤의 Changed로도 체크가 됩니다.)

결과 파일을 살펴보면, hostname 부분이 vars에서 선언한 내용으로 변경되어 있음을 찾아볼 수 있습니다.

 

 


 Ansible Example 2


  두 번째 예제는 다수의 Variable을 사용하는 방법입니다.

  vars 항목 대신에 task에서 with_items라는 항목을 넣고, 변수명:데이터값 을 지정하게 됩니다.

  여기에서 선언한 개수만큼 해당 Task는 실행이 되게 됩니다. 

  간단한 예제로 보겠습니다.

 

 

hosts :

tasks:

  - name : Task명

    template: src=Template파일(경로 포함)

                      dest =/home/zigi/{{item.변수명}}

    with_items:                                                                                     // 순환문 처럼 아래 변수에 대해서 차례대로 순환

       - 변수명 : 실제 대입될 값1

       - 변수명 : 실제 대입될 값2

       - 변수명 : 실제 대입될 값3

       - 변수명 : 실제 대입될 값4  

 

 예제 1과 Template은 동일하지만, Playbook 파일을 보면, vars부분 대신에 task의 with_items이 생긴 것을 볼 수 있습니다.

 

playbook을 실행하면 정상적으로 수행됨을 볼 수가 있고, Task에서도 5번의 changed가 생긴 것을 볼 수 있습니다.
(ex1에서 얘기했듯이 최초의 실행을 하게 되면, changed도 함께 표기가 됩니다. 파일을 생성자체가 변경사항이기 때문입니다.

 

  실제 만들어진 파일의 내부를 보면, with_items에 선언된 값으로 변경되어 있음을 볼 수 있습니다.

 

 

 


  Ansible Example 3


  세 번째 예제는 하나의 Template에 하나의 값이 아니라 다수의 값을 지정하려고 하는 경우입니다.

  기존의 변수와 값을 선언하던 것을 { }로 묶어서, 내부에서는 ','로 구분만 해주면 됩니다.

  아래 예제를 보면 보다 쉽게 이해할 수 있습니다.

 

hosts :

tasks:

  - name : Task명

    template: src=Template파일(경로 포함)                                        // Templeate 파일

                      dest =/home/zigi/{{item.변수명}}

    with_items:                                                                                     // 순환문 처럼 아래 변수에 대해서 차례대로 순환

       - {변수명1: 실제 대입될 값1-1, 변수명2:실제 대입될 값1-2, ... }

       - {변수명2: 실제 대입될 값2-1, 변수명2:실제 대입될 값2-2, ... }

       - {변수명3: 실제 대입될 값3-1, 변수명2:실제 대입될 값3-2, ... }

       - {변수명4: 실제 대입될 값4-1, 변수명2:실제 대입될 값4-2, ... }

 

 

아래 Template을 보시면, hostname뿐만이 아니라 Loopback의 address부분/ ip route의 nexthop이 추가된 것을 볼 수 있습니다.

playbook에서도 with_items 부분에 { }로 각 변수와 값이 들어가 있습니다

 

 

 Playbook을 실행하면, Task에 각 item들이 입력된 값을 볼 수 있습니다.

 

실제 생성된 파일의 내용을 보면

정상적으로 각 variable 란에 지정된 변수 값으로 데이터가 들어간 것을 볼 수 있습니다.

 

 


 

 

 

Posted by 네떡지기

티스토리 툴바