'autumation'에 해당되는 글 7건

  1. 2016.08.20 Puppet Part 5
  2. 2016.08.18 Puppet Part 4
  3. 2016.08.12 Puppet Part 3
  4. 2016.08.09 Puppet Part2
  5. 2016.08.04 Puppet Part 1
  6. 2015.01.26 Programmability for Networker : Part 16 (Junos PyEZ:1)
  7. 2014.12.30 Automation for Networker[4] - Ansible : Part 2
DevOps/Automation2016.08.20 16:28

 

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, class, 클래스, module, 모듈

 

개인적으로 정리하는 Puppet의 5번째 포스팅입니다.

이번 포스팅은 지난 포스팅과 연장선상에 있는 manifest 모듈 작성과 관련한 내용입니다. 

지난 포스팅이 하나의 Environment에 대한 내용이었다면,

이번 포스팅은 다양한 Environment에서 사용 가능한 모듈을 작성하는 내용입니다.

아마도 모듈에 대한 내용은 추가적인 포스팅이 있을 것 같습니다.   

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

 


 

Puppet Part 5

 

 

Puppet  Module 1

   •manifest에서 Class 사용하기 위해서 Class 정의하기 위해서는 사용하고자 하는 Manifest에서 사용할 수도 있지만,

      Class들을 별도의 Manifest 파일로 작성 있음.

   •Class 별도의 Manifest 분리하여 Module로써 사용하게 되면 작성된 코드를 재사용하거나, 이력관리,

       코드의 유지 보수에 유용함.

   •Puppet 이용하여 관리되는 Node 정의하는 Manifest 실제 관리되는 Resource 대한 Attribute 선언하는

       Manifest 분리하여 작성하는 편이 유용.

 

 

 

Class 모듈화 예제

   •zigispace라는 file 내용을 갖는 blog라는 파일을 생성하는 blog.pp

   •Node OS 종류를 file 내용으로 갖는 osver라는 파일을 생성하는 osver.pp

   •blog.pp osver.pp class 가져다가 node 적용하는 maindev.pp

   •blog.pp osver.pp 다른 manifest 다른 node에서도 동일하게 적용 가능.

 

 

 

 

 

 

 

 

 

 

 

Puppet  Module 2

   하나의 environments에서 class 별도의 manifest 모듈로 분리하여 선언할 수도 있지만, 다수의 environment에서

     공용으로 사용할 있도록 구성할 있음.

   모듈로 사용하고자 하는 Manifest modules 디렉토리의 하위에 위치

   특정 기능을 하는 모듈 별로, modules 디렉토리 하위에 서브 디렉토리를 생성하고, 서브 디렉토리 하위에 manifests라는

      해당 모듈에 들어가는 manifest 위치할 디렉토리를 만들어서 manifest 파일을 관리함.

   •modules 디렉토리에서 manifest 모듈을 관리할 때에는 다음과 같은 규칙으로 관리를 해야 .

         - modules 하위에 module 이름으로 모듈 디렉토리를 생성

          - 모듈 디렉토리 하위에는 manifests라는 하위 디렉토리를 생성하고, 하위 디렉토리에서 manifest 파일을 생성

          - modules 내의 manifest 파일의 class명은 위에서 선언한 모듈디렉토리를 기준으로 지정. 

          - , module 이름과 동일한 이름의 class 경우에는 파일명을 init.pp 이라고 명명해야 .

          - init.pp 이외의 다른 manifest 파일의 클래스는 클래스 선언 , module 이름을 포함하여 클래스를 선언

              * module::클래스명

              * 기존의 프로그래밍에서 namespace 지정하는 것과 유사함.

           - manifest 파일명은 클래스명과 동일하게 지정. 

 

 

Puppet  Module 구성 에제

   •zigimod라는 module 2개의 manifest 파일을 구성하고, 사용하는 예제

   •modules 하위 디렉토리의 구성과 manifest 파일의 예제 코드

 

 

 

 

 maindev.pp

 init.pp

node 'agent1' {

   include zigimod

}

class zigimod {

   file { '/zigi/mod1':

     content => "module1\n",

   }

}

 

 

 

 maindev.pp

 mod2.pp

node 'agent1' {

   include zigimod::mod2

}

class zigimod::mod2 {

   file { '/zigi/mod2':

     content => "module2\n",

   }

}

 

 

 

Puppet  Module 3

 기본 Puppet 속성의 ModulePath 속성 이외에 Module 디렉토리를 사용하고자 경우에는 ModulePath 추가해야 .

 •modules 디렉토리에는 모듈 형태로 사용하고자 하는 manifest 뿐만 아니라 file, plug-in, template 등도 추가하여 사용.

 •module에서 사용하는 자원들의 종류에 따라서 개별 디렉토리 사용.

           ex> manifest manifests 디렉토리, file files 디렉토리 ..

Posted by 네떡지기
DevOps/Automation2016.08.18 14:46

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, class, 클래스, 상속, inherits, 매개변수

 

개인적으로 정리하는 Puppet의 4번째 포스팅입니다.

이번 포스팅은 Puppet의 Manifest를 모듈화 하여 작성하기 위한 방법인 class 작성 방법과 예제입니다.

기존의 OOP에서처럼, 모듈화하고, 코드의 재사용 등 기존의 OOP의 class와 동일한 쓰임새로 사용된다고 보면 될 것 같습니다.

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

 


 

Puppet Part 4

 

Puppet  Class

   •manifest 자주 사용되는 내용들은 별도의 Class 구성하여 사용 가능.

   별도의 Class 구성하여 서로 다른 Environment에서 동일한 manifest 작성하지 않아도 .

 

Puppet Class 정의

   •class 키워드 사용

   •class 지정

   class 매개변수 지정 가능.

         - 매개변수 지정방법 : ( Data_Type $변수 = Default_Value)

             * Datatype 선언은 필수는 아니면, Default로는 any

   다른 class 상속하는 경우에 Inherits 함께 상속받을 클래스 입력

   하나 이상의 Resource 대한 Puppet Code 작성

 

 

Class 사용법

   동일한 Manifest 작성하거나, 혹은 별개의 Manifest 작성

   사용하고자 하는 manifest에서 include class 으로 사용 가능

Dev.pp

mainDev.pp

class osver {

     file { '/zigi/osversion':

     content => $osversion,

   }

node 'agent1' {

   include osver

}

 

 

Class 작성 예제

 

Class 작성 예제1

class blog {

     file { '/zigi/blog':

       content => 'zigispace.net',

       }

       file {'/zigi/nickname':

          content => 'no-name',

       }

 }

 

 

Class 작성 예제2 - 상속

class Info inherits Blog {

     file ['/zigi/nickname']{

       content => 'ZIGI',

   }

      file { '/zigi/mail':

         content => 'zigi@zigispace.net',

     }

} 

Class 상속 받는 경우에는 상속하는 Class 동일한 Resource Title 중복이 되는 경우에는

   해당 값을 Override 있음.

 

 

Class 작성 예제2-1 - 상속 (오류)

class Info inherits Blog {

     file {'/zigi/nickname':

       content => 'ZIGI',

   }

      file { '/zigi/mail':

         content => 'zigi@zigispace.net',

     }

} 

Error : Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: File[/zigi/blog] is already declared in file /etc/puppetlabs/code/environments/dev/manifests/ss.pp:2; cannot redeclare at /etc/puppetlabs/code/environments/dev/manifests/ss.pp:12 at /etc/puppetlabs/code/environments/dev/manifests/ss.pp:12:3 on node agent1.puppet.local

, 상속 시의 Overrding하는 Title 기존 선언하는 방식과 동일하게 선언하게 되면, 중복선언으로 에러가 발생하게 . 

관련 Manifest 작성은 추후 포스팅에서 다뤄질 예정입니다.

 

 

 

Class 작성 예제3 - 상속 2

class apache {

  service {'apache':

    require => Package['httpd'],

  }

}

 

class apache::ssl inherits apache {

  Service['apache'] {

    require +> [ File['apache.pem'], File['httpd.conf'] ],

  }

}

Class 상속 받는 경우에는 상속하는 Class 동일한 Resource Title 특정 속성 값을

   추가하고자 때에는 Attribute => value 대신에 Attribute +> value 표기하면 된다. (=> +>)

 

Class 작성 예제4 - 매개변수 사용

class nginx  (String $ver = 'latest') {

     package { 'nginx':

       ensure => $ver,

   }

Posted by 네떡지기
DevOps/Automation2016.08.12 14:42

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, Architecture, 아키텍처, Catalog, 카탈로그, facts 

 

지난 번에 이은, Puppet의 3번째 포스팅입니다.

이번 포스팅은 Puppet을 조금 더 이해하기 위한 간단한 아키텍처와 동작 방식에 대한 내용입니다.

우선 짧지만, 정리하는 데로 추가로 올리거나 업데이트 할 예정입니다.

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

 


 

 

Puppet Part 3

 

Puppet Architecture 일반

   • Puppet 일반적은 master/agent(혹은 Server/Client) 구조의 Puppet Master Puppet Agent 사용.

   • Puppet Apply Application 통한 self-contained(Standalone) 구조로도 실행 가능.

 

Puppet 통한 Node 관리를 위한 2개의 Main Stage

   • Catalog 컴파일

   • Catalog 적용

 

Master/Agent 구조에서의 기본 동작

   • Agent에서는 Puppet Agent App Background 서비스 처럼 동작하고 하나 이상의 Puppet master App

       동작하는 Puppet Server 동작.

   •Agent 주기적으로(Default 30) Master에게 자신의 facts 전송하고, Catalog 요청

   •Master Catalog 생성을 위해서 컴파일 후에 Node에게 Catalog 전송

   •Agent Catalog 수신 받아서, catalog 정의된 내용과 현재의 Resource 비교하여 Catalog 내용을 적용.

   • Catalog 적용 , Agent Report Master 전송

 

 

 

 

Standalone 구조에서의 기본 동작

   •Puppet Apply 통해서 노드를 관리

   일반적으로 예약된 작업(Scheduled task)혹은 Cron Job으로 수행.

   •Master/Agent 구조와 마찬가지로 Puppet 노드 관리를 수행하기 위해서 컴파일 과정을 거치게 .

   컴파일 Catalog 통해서 Resouce들을 Catalog 내용대로 적용.

   •Catalog 적용 , Report Disk 저장

 

 


Catalog

관리하는 자원에 대해서 자원에 대해 원하는 상태(Desired state) 기술

특정 순서로 관리를 해야 하는 경우에, 리소스에 설정에 대한 종속성 정보를 제공 가능.

 노드를 설정할 (configuring), Puppet agent catalog라고 부르는 Master 서버로부터 전송 받은 document 사용.

  

Catalog Compile

• Puppet 3가지의 설정 정보의 main-sources 사용하여 catalog 컴파일 .

    Agent-provided data

        - agent catalog 받기 위해서 master에게 자신의 정보를 전송할 아래의 4가지 정보를 전송.

           1. name.  (일반적으로 certname 같다.)                     2. certficate

           3. facts                                                                                      4. environment

   External data

   Puppet manifests

        - main manifests Modules ( Puppet Forge 부터 다운, 사이트에서 직접 작성)

 

FACTS

catalog 요청 전에 Facter 사용하여 시스템의 정보를 수집.

puppet 이렇게 수집된 정보를 facts 정보라 하고, 이것은 manifest에서 사용 pre-set variables 사용.

 .

 

Posted by 네떡지기
DevOps/Automation2016.08.09 17:01

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, ruby, resource, title, attribute, value, 명세서

 

지난 번에 이은, Puppet의 2번째 포스팅입니다.

사실 이번 포스팅은 예전에 정리했던 Automation for Networker 주제의 포스팅을 다시 재가공하였습니다.

기존에 포스팅한 것보다는 조금 내용이 변경 혹은 추가 되었습니다. 

앞으로 몇 번에 걸쳐서 추가 포스팅이 되지 않을까? 싶습니다.

단지, 포스팅 전에 테스트와 무작정 정리한 걸 다시 포스팅 용으로 작성 하는 데 시간이 걸려서.

언제 올라올지는 모르겠지만.. 멀지 않은 시일 내에 또 올리도록 하겠습니다.

그리고 혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

 


 

Puppet Part 2 .

 

 

Manifest

    - Puppet languatge 파일로, '.pp' 확장자를 가진다.

    - Target 시스템에 적용되어야 하는 Resource Value 지정하는 일종의 명세서 같은 역할.

    - UTF8 인코딩 사용

    

    

Manifest 기본 구성 형식

  

Node 'Node_Name'

Resource { 'TITLE':

   ATTRIBUTE => VALUE,

   ...

}

 

Node

   - 다수의 Puppet Agent 적용 시에, 각 Node를 구분하기 위한 Keyword이며 이는 Device의 Hostname을 Node 뒤에 써주면 해당

   - Hostname에을 가진 Device에 대해서만 해당 Attribute가 적용

 

Resource

   - Puppet이 관리하는 Configuration의 구성요소, File, Service, Package, User등의 Type과 Attribute를 갖는다.

   - Defined Type Custom resource type 있음.

    

 

TITLE

  - 하나의 Resource Type에서 유일한 이름으로 사용 되어야 .

  - 중복된 TITLE 사용 시에는 Manifest 컴파일 시의 에러 발생

  - 서로 다른 Resource 간의 TITLE 중복은 가능.  (Ex. package 'ntp', service 'ntp'

  - Resource Type 따라서 Target System 특정 Resouce 뜻하기도 하며(이러한 경우의 'namevar' 속성이라고 ),

    단순히, '이름' 뜻하기도 .

  - namevar 경우에는 하나의 resource type 하나의 값을 뜻하는 경우도 있지만, 어떤 경우의 namevar 해당 이름만으로는

    명확하게 없는 경우가 있다. 예를 들어서, service mysql Target System 내에 설치된 mysql 서비스로 명확하지만,

    package mysql mysql 받아오는 방법에 따라서 다를 있다. (ex. Yum, gem .. )

  Ex) File  : File의 절대 경로/파일명

        Package / Service : 실제 패키지나 서비스

 

Attribute

    - 해당 Resource의 설정되어야 하는 속성

    - manifest에서 target system 적용하고자 하는 속성 값을 선언
    -
소문자로 쓰여지고, " " 사용하지 않음.

 

VALUE

    - 특정 Resource의 Attribute에 적용되는 내용, 상태 등을  나타내는 값.

 

 

지정 가능한 Resource Types

 

 

 

 

Resource 

 

File Resource

  path : 파일에 대한 경로 지정. 만약 속성을 선언하지 않으면 default Title path 값으로 갖게 .

  ensure : 지정된 파일의 생성 , 어떤 종류인지 지정. (present, absent, file, directory, link)

  contents : 실제 파일의 내용. 속성은 source  / target 속성과 함께 사용할 없음.

  source : 복사할 파일의 Source 지정. 속성은 contents / target 속성과 함께 없음.

                   puppet, file, http 지정 가능.  Ex) 'puppet:///modules/nfs/conf'

  target : link 생성 , 사용. Symlinks type 지원. (link 생성 시의 원본 경로)

                 contents, source 속성과 함께 사용 없음.

 

file { '/temp/blog':

    content => 'http://zigispace.net',

}

 

file { '/etc/inetd.conf':

  ensure => '/etc/inet/inetd.conf',

}

 

file { '/etc/inetd.conf':

  ensure => link,

  target => '/etc/inet/inetd.conf',

}

 

 

package Resource

  provider: 동일한 패키지가 다양한 Source에서 관리되는 경우에 받아올 곳을 지정.

                     apt, dpkg, gem, rpm, pip, yum windows, zypper

 name : 패키지 . 만약 속성을 선언하지 않으면 default Title 패키지 명이 .

   ensure : 패키지의 상태. (Default : installed) . 특정 버전 지정 가능

                   present(installed), absent, purged, held, latest

  install_options  : 설치 시의 추가적인 옵션 지정. 옵션은 package-specific .

  source : 패키지를 가져오게 위치. Provider에서 자동으로 패키지를 다운 받을 없는 경우에 사용.

                  예를 들어서, yum이나 apt provider 지정할 경우에는 속성은 무시.

 

 

package { 'nginxrpm':

   ensure => installed,

   provider => 'rpm',

   source => 'http://nginx.org/packages/centos/7/noarch/RPMS/nginx-releas-centos-7-0.el7.ngx.noarch.rpm',

}

 

package { 'nginx':

   ensure => installed,

   require => Package['nginxrpm'],

 }

 

package { 'mysql':

  ensure          => installed,

  source          => 'N:/packages/mysql-5.5.16-winx64.msi',

  install_options => [ '/S', { 'INSTALLDIR' => 'C:\mysql-5.5' } ],

}

 

 

 

service Resource

  name : service . 만약 속성을 선언하지 않으면 default Title service명이 .

  ensure :  servicer running 상태인지 아닌지 지정.

                    running(true), stopped(false)

  enable : 시스템이 boot 시에 service 활성화 것인지 지정.

                   true, false, manual, mask

  path :  init scripts 대한 경로

 

 

 

service { 'httpd':

  ensure => running,

  enable => true,

}

service { 'sshd':

  ensure    => running,

  enable    => true,

  subscribe => File['/etc/ssh/sshd_config'],

}

service { 'ntp':
  name      => ntpd

  ensure    => running,
  enable    => true,
}

 

 

 

 

 

Posted by 네떡지기
DevOps/Automation2016.08.04 22:02

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, 설치, install, master, agent 

 

이번 포스팅은 Puppet에 대한 포스팅입니다.

약 2년여전에 관련 Automation for Networker라는 주제로 포스팅을 할 때 ansible과 함께 잠깐 정리했던 내용을

다시 정리해보려고 합니다.  아무래도 제 포스팅이 대체로 제가 다시 보기 위해서 정리하면서 공유하는 게 목적이오니~

보시는 분들은 참고하시면 되겠습니다 ^^

그리고 혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

 


 

Puppet를 사용하기 위한 요구사항

 

◇ 하드웨어

    · 최소 Puppet master server : 2CPU Core, 1GB RAM
    · 약 1,000 node 관리를 위해서 2-4 CPU Core, 최소 4 GB RAM.

 

◇ 지원 OS

    · Redhat Enterprise Linux 7,6,5

    · Debian 8 “Jessie”, Debian 7 “Wheezy”

    · Ubuntu 16.04 LTS “Xenial Xerus”, 15.10 “Wily Werewolf”, 14.04 LTS “Trusty Tahr” , 12.04 LTS “Precise Pangolin”

    · Fedora 23, 22

    · Windows Server 2012 R2, 2015, 2008 R2, 2012, 2008

    · Windows Vista, 7, 8, 8.1, 10

    · OS X 10.11 El Capitan, 10.10 Yosemite, 10.9 Mavericks

    · *SUSE Linux Enterprise Server, version 11 and higher

    · *Gentoo Linux

    · *Mandriva Corporate Server 4

    · *Arch Linux

    · *Oracle Solaris, version 10 and higher (Puppet performs limited automated testing on Solaris 11)

    · *AIX, version 5.3 and higher

    · *FreeBSD 4.7 and later

    · *OpenBSD 4.1 and later

    · *HP-UX

 

※ *표기는 Puppet Open-source 버전에서는 미지원하고, Puppet-Enterprise에서 지원.

 

 

Master와 Agent에 따른 지원 플랫폼 (PE 기준)

 

 

 

 

 

 

◇ 네트워크 요구사항

    · Firewall

       - Master Server는 8140 Service Port가 오픈되어야 함. (in-bound)

    · Name resolution

       - 모든 노드는 유일한 Hostname을 가지고 있어야 함.

       - 정방향, 역방향에 대한 DNS 모두 설정 필요.

           * DNS 미 사용시에는 Node의 Hosts 파일에 해당 내용이 포함되어 있어야 함.

 

◇ 기타 필요 패키지

    · Ruby 2.1.x, 2.0.x, 1.9.3

    · Facter 2.4.3 이상, Hiera 2.0.0 이상, json gem, rgen gem 0.6.6 이상

    · msgpack gem (Optional)

 

 


 

Puppet 설치

 

◇ 설치환경 및 패키지 (TEST 환경)

    · CentOS 7.2 (Master / Agent)

    · Puppet 4.5   

    · Hosts에 Node 정보 등록 (DNS 미사용)

   

 ◇ Package 레포지토리 설치 

    · rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

       - 각 Linux ~~ 및 버전별로 다름.

       - https://docs.puppet.com/puppet/latest/reference/puppet_collections.html

 


 

◇ Puppet package 설치 

    · yum install puppetserver

        - puppetserver 설치 시, dependency 때문에 puppet-agent도 함께 설치

        - 본 테스트 시에는 Master Node와 Agent Node의 설치는 동일하게 진행하였음. (여기까지 진행 후, VM 복제)

 

 

◇ Master와 Agent Config 설정

    · Hostname / Domain

        - Master : puppet

        - Agent : agent01

        - Domain : puppet.local

    · puppet.conf 설정

        - Master : [master] 섹션에 certname 추가

           [master]

           certname = puppet.puppet.local

        - Agent : [agent] 섹션에 certname 추가

           [agent]

           certname = agent01.puppet.local

    · DNS 혹은 hosts 파일에 master와 agent01 정보 추가 

    ·

 

 ◇  Puppet Master 노드 구동 

    ·  #puppet master --no-daemonzide -d -v

 

 

 

 

 ◇ Puppet Agent 노드 구동 

    ·  #Puppet agent --server master-fqdn --no-daemonize --verbose

 

 

 ◇ Puppet  인증 확인 

    · Master와 Agent 간의 통신을 위해서 인증 작업을 거쳐야 함.

    · Agent 등록 후(Agent가 Master에 접속 후), 현재 인증된 전체 리스트를 확인하기 위해서

      # puppet cert --all and --list 

      명령으로 확인을 하면, 아래와 같이 표기

      puppet.puppet.local (Master)에 대한 정보와 agent1.puppet.local(agent) 정보가 확인되는 데,

      아직 agent가 등록만 되고, 인증이 되지 않았기 때문에 Node 제일 앞에 '+' 표기가 agent1에는 되어 있지 않음 

 

 

 ◇ Puppet 인증 및 확인 

    · Master에서 agent1 Node 인증

      # puppet cert --sign agent1.puppet.local

    · 인증 후, 다시 인증된 리스트를 확인하면, agent1 node가 인증된 것을 확인 할 수 있음. (앞에 '+' 표기)

 

 

 ◇ Puppet Agent 노드 구동 

    · Agent 노드를 다시 실행해보면, 인증받은 인증서로 master와 통신을 성공하고, client가 동작하면서 catalog를 적용

 

 

 


 

Puppet Manifest 확인

◇ 기본 Manifest 테스트

    · /etc/puppetlabs/code/environments/production/manifest 디렉토리에 아래와 같은 manifests를 작성하고,

       agent를 재기동해보면, manifests가 agent1에 적용된 것을 확인할 수 있음.

      

node 'agent1' {

     file { '/zigi/osversion':

       content => $osname,

    }

 }

 

 

    ·  기타 manifest 적용하는 부분에 대한 내용은 이후 포스팅에서 다룰 예정이며,

        아래의 기존 포스팅에서도 일부 확인 가능합니다.

 

 

 

 

※ 기존 포스팅 확인 : http://zigispace.net/791

                            http://zigispace.net/789

 

 

Posted by 네떡지기
DevOps/Programmability2015.01.26 22:32



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

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



Juniper PyEZ Library


○ PyEZ 란?

     - Junos OS 장비를 원격에서 관리 및 자동화하는 Python으로 만든 'micro-framework'

     - Junos OS 혹은 , Junos OS XML API에 대한 이해가 복잡하게 필요하지 않음

     - 비개발자에게는 원격지의 Junos OS 장비의 자동화 업무 등의 할 수 있도록 하는 간단한 Power Shell 역할을 함.

     - 개발자에게는 보다 큰 네트워크 인프라의 자동화 관점에서 사용할 수 있는 확장성 있게 사용할 수 있는 Library 역할을 함. 


○ PyEZ 기능

     - Junos OS CLI의 기반에서의 동일한 기능을 할 수 있도록 설계.

     - 'fact'를 사용한 Software version, serial 등의 정보 제공

     - 현재 동작 상태 정보를 확인 ('Show' 명령)

     - snippets와 templates를 사용하여, unstructured configuration 변경

     - 추상화 된 모델을 통하여 structured configuration 변경

 

 Architecture

     - ncclient library는 NETCONF를 통해서 벤더에 상관없이 사용 가능하도록 함

     - Junos-pyez는 Junos OS 장비를 쉽게 통신하여 관리할 수 있도록 만들어진 Micro-framework.



 



PyEZ Library Install

 

1. 다음과 같이 PyEZ Library를 사용하기 위하여 Install을 한다. [ Windows 기준 ]

     ※ Install 문서 Link.

     https://techwiki.juniper.net/Automation_Scripting/010_Getting_Started_and_Reference/Junos_PyEZ/Installation#Windows

 

 

     정상적으로 Junos PyEZ  Library가 설치된 것을 확인할 수 있다.


※ 주의사항 Paramiko 설치되어 있어야 함.

                           → jnpr.junos.Device 에서 paramiko Library를 Import해서 사용. 

 




PyEZ 처음 사용해보기

   - PyEZ Library를 사용하여, Junos OS 장비에 접속하여 해당 장비의 Hostname과 Version 정보를 가져오기

   - 장비 접속 시, jnpr.junos의 Device라는 클래스를 사용하고, 해당 클래스에서 제공하는 facts를 사용하여 필요한 정보를 가져온다.

   - 아래는 10.1.1.97의 IP를 가진 Junos OS 장비에 접속하여 정보를 가져와서 출력하는 예제입니다.




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 네떡지기

티스토리 툴바