DevOps/Automation2016.09.05 23:14

 Today Key : Puppet, 퍼펫, Environment, 환경, Manifest, Group, 그룹, Production, conf, automation, 자동화

 

 

새로 쓰는 Puppet 관련 6번째 포스팅입니다.

정리를 해두고, 포스팅 하는 데까지 이래저래 시일이 걸리기도 하고 다른 것들을 보느라,

더뎌지고 있지만.. 앞으로 더 포스팅 예정입니다.

이번 포스팅은 Puppet의 Agent를 그룹화 하여 관리할 수 있는 Environment에 대한 내용입니다.

Environment에 대한 전부를 다루는 것은 아니지만, Environment를 조금이나마 이해하고

사용하는 데 도움이 되셨으면 합니다.

 


 

Puppet  Environments

  Production, QA, Development 같은 다양한 환경에서 Puppet으로 자원을 관리하고자 , Environment Puppet Agent들을 그룹으로 나눠서 관리할 있음.

  Master Server Environment별로 독립적인 Main manifest와 module paths 제공 가능 .

  물론 Puppet Master 분리하여 Agent 독립적으로 관리할 있지만, Environment 통해서 보다 유연하게 관리)

  Agent Node Environment 할당하기 위해서  Agent config 파일을 사용하여 Environment 지정하거나,  혹은 ENC 사용(External node classifier) 있음.

 

 

 

 

< Default Production Environment 적용 >

 

 

 

< Production Development Environment 적용 >

 

 

Puppet  Master에서 Environments 구성

  Environment는 directory로 구분되며, 몇 가지 규약이 있음 .

    - Directory의 이름이 environment의 이름이 됨.

    - puppet master서버의 environmentpath에 존재해야 하며, 일반적으로 $codedir/environment 를 사용.

       * default로 codedir/etc/puppetlabs/code Directory.

    - environment에는 modules directory를 포함할 수 있으며, 이 경우에는 해당 경로는 environment의 default modulepath의 일부가 된다.

   - manifest directory를 포함할 수 있으며,  그 디렉토리가 해당 environment에 default main manifest가 됨.

   - environment에서 environment.conf 파일을 포함할 수 있으며, 이 경우에는 modulepath와 manifest를 포함한 몇 가지 설정이 override될 수 있음. 

       * 특정 environment의 directory에 위치

 

< Environment 내의 설정파일 >

 

 

다음은 environments dev, production, zigimani 디렉토리가 생성된 구성 예제임.

 

 

< environment 구성 예제 : production, dev, zigimani 라는 3개의 environment 각각 존재 >

 

 

 

Agent 설정 파일로 Environment 설정하기

  • Agent node puppet.conf 설정 파일의 agent 혹은 main config section에서 설정 가능.

 

 

 

 

Environment 존재하지 않는 경우

  •Agent node 구성되지 않는 environment 할당될 없음.

  만약 environmentpath 디렉토리에 해당 environment 존재 하지 않는 경우에는 Puppet master 해당 Catalog

     컴파일이 실패함.

  , default environment production 없는 경우에는 agent 카탈로그를 검색. (Fail 아닌 Successfully)

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

○ 자동화 도구(Automation Tool)

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

 

 

 

 

Posted by 네떡지기
DevOps/Automation2014.12.20 11:58

 


Puppet 2번째 입니다. ^^

Automation for Networker 시리즈의 3번쨰 포스팅이기도 합니다.

이번 포스팅에서는 Puppet를 설치해보고,

아주 간단하게 구조 확인 및 예제를 실행해보고, 작은 모듈로도 구성해 봅니다.


Puppet 설치하기

 

  1. 파일 Download : wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb

 

 

  2. APT 설정 업데이트 : sudo apt-get update

 

  3. Install : sudo apt-get -y install puppet

                    ※ sudo yum install puppet   [ Yum 패키지 이용 시 ]

                         http://downloads.puppetlabs.com/windows  [ Windows의 설치패키지 이용 (MSI파일) ]

 

 

  4. Version 확인 : puppet --version

 


 

Manifest

    - Puppet 언어로 작성된 파일로, .pp 확장자를 가진다.

    - Resources와 Class를 선언하고, Variable, Function 등에 대한 설정을 한다.

    

 

Manifest 기본 구성 형식

  

Node 'Node_Name'

Resource { NAME:

   ATTRIBUTE => VALUE,

   ...
}

 

○ Node

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

    Hostname에을 가진 Device에 대해서만 해당 Attribute가 적용된다.

 

○ Resource

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

 

○ NAME

   Resource에서의  각 Instance와 구분용도로 쓰이는 이름

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

         Package : 패키지

 

○ Attribute

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

    Ex) File : Content (File 내용 : overwirte), owner, group , mode

           Package : ensure  -  installed  : 미 설치 시 설치

                                            -  absent : 설치 시 삭제

                                            -  latest : 최신 버전 업데이트

                                            -  특정 버전 ID : 특정 버전으로 동기화

 

○ VALUE

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

   

 

 


Manifest  적용   

 

~$ puppet apply site.pp

 


Manifest 예제 보기

 - 첫 번째 Puppet의 예제는, 특정 디렉토리에 지정한 내용을 가지는 file을 생성합니다.

 - /tmp/zigi 라는 디렉토리에 'ZIGI Puppet Ex1'이라는 내용(content)을 가지는 파일을 생성하게 되는 데,

   만약 기존에 파일이 존재할 경우에는 지정한 내용(content)로 다시 쓰여지게(overwrite) 됩니다.

 

Manifest 코드)

file { '/tmp/zigi':
        content => "ZIGI Puppet Ex1\n",
}

 

Manifest 실행)

ubuntu@ip-172-31-19-29:~/Puppet$ puppet apply site.pp
Notice: Compiled catalog for ip-172-31-19-29.ap-northeast-1.compute.internal in environment production in 0.04 seconds
Notice: /Stage[main]/Main/File[/tmp/zigi]/content: content changed '{md5}e3d06af3118fbd5c185ace31184bce1d' to '{md5}bfe6ff1231792c9cb81b6a5ed9d2be75'
Notice: Finished catalog run in 0.03 seconds

 

결과 확인)

ubuntu@ip-172-31-19-29:~/Puppet$ cat /tmp/zigi
ZIGI Puppet Ex1

 

 


Puppet 모듈화 하기

 

● 모든 내용을 하나의 Manifest로 작성해도 상관없지만, 관리 및 유지보수 측면에서 역할에 따라서 Manifest를 위와 같이

    구분해서 사용하는 것이 좋다

 

Class (init.pp)

  - 모든 Element(files, settings, moduels, scripts 등)를 포함하여 선언해 놓은 Resource의 집합

 

class zigimodule {
   file {'/tmp/zigimodule':
      content => "ZIGI Module Test\n",
   }
}

 

 

Node (ziginode.pp)

  -  Class, Resource, Variabled 집합을  특정 agent에 적용하도록 만든 Manifest  

 

node 'ZIGI'{
   include zigimodule
}

 

 

Main Manifests  (site.pp)

  - 주 실행 Manifest. 

 

import 'ziginode.pp'

 

 

디렉토리 구조 

  - 위에 열거한 파일에 대한 디렉토리 구조는 아래와 같다.

  - Class로 만들어진 init.pp는 modules 디렉토리 내부의 class명과 동일한 디렉토리 안에 manifests 디렉토리 내부에 위치한다.

     ※ module에 대한 상세 디렉토리 구조는 추후에 다시 다룰 예정입니다.

 

 

 

모듈화 Puppet 실행 및 결과

   - 모듈화된 manifest를 실행하고 난, 결과내용과 결과값이다.

 

 

 

 

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 네떡지기
DevOps/Automation2014.11.21 01:06

 


 

기존 것들도 우왕~좌왕하면서..

새로운 주제의 포스팅을 시작합니다.

이것도 한 2~3주전쯤에 초안 정리하다가...  보지도 않다가.. 다시 콩알 만큼씩 보려고...

우선 다시.. 급 보기좋게(?) 마저 정리해서 포스팅을 합니다.

자주 올리지는 않겠지만.. 더디더라도.. 꾸준히 올릴 수 있도록 해보겠습니다! ^^

 


Puppet

  ▷ 기존에 정의된 Manifest에 의해서 현재 설정과 Manifest와 비교하여 변경된 부분에 대해서(혹은 초기 구동 시)

      필요한 부분에 대해서 각 환경에 맞춰서 자동으로 환경을 구성함.

 

  ▷ 하나의 Manifest로 다수의 장치에 대해서 동일한 작업을 수행하고 서로 동일한 환경을 구성할 수 있다.

 

  ▷ 다수의 수작업이 필요한 환경 구성 및 업데이트 등의 작업을 Manifest 관리만을 통해서 자동화 할 수 있으며,

      개별 작업으로 발생할 수 있는 오류 발생 가능성을 없애준다.

 

  ▷ 다양한 OS를  지원하기 때문에 운영 환경에 상관없이 동일하게 사용할 수 있다. (일부는 Agent만 지원)

 

Puppet 구성 요소 & 정의

  ▷ agent nodes, : Puppet에 의해서 관리되는 가상 혹은 물리 서버.

  ▷ puppet master server, : Agent Node를 관리하는 서버.

  ▷ console server : Site 관리를 위해서 Agent를 분석 관리하는 서버 (Master 서버에서 이 역할을 할 수도 있다.)

  ▷ database support server : PuppetDB와 데이타베이스들이 동작하는 Console 지원 서버 (Master 서버에서 이 역할을 할 수도 있다.)

 

  ▷ Manifest : Puppet를 통해 설정하고자 하는 환경에 대한 정의. 자원에 대한 기술 명세서.

 

  ▷ 자 원 : 사용자, 파일, S/W 등의 Puppet 관리 대상 , Manifest 만드는 것은 자원을 선언하는 것으로 볼 수 있다.

                 File / User / Group / Host / Package / Service 등등

 

  ▷ Catalog  : Puppet Master에서 Agent에게 내리는 명령

 

 

 Puppet 데몬 프로세스

  ▷ puppetmasterd : Puppet의 관리서버에서 실행

 

  ▷ puppetd : Puppet의 관리서버에서 적용받는 각 서버에서 실행,

         * 정기적으로(Default 30분) puppetmasterd에 요청하여 받은 결과값을 현재 설정과 비교하여 수정된 부분은 반영하도록 한다.

            이 때의 설정 파일은 puppetmasterd에서 다운로드 되어 처리.

            또한 정기적으로 반영되는 것 이외에 수동으로 직접 puppetmasterd에서 내릴 수도 있다. (puppetrun)

 

    ※ puppetmasterd와 puppetd 간의 통신은 SSL을 통해서 이뤄진다.

 

 

 

Puppet 기본 동작

  ▷  Puppet은 하나의 Master 서버에서 설정(아파치 설정, WAS 기동 등..)을 하면 각 Agent에게 설정 정보를 보냅니다.

       (이러한 명령을 "catalog" 라고 합니다.)

 

  ▷  이를 수신한 Agent는 변경된 설정 정보를 실행하고, 결과 리포트는 Master에게 전송 합니다.

 

 

 

 


  

※ Puppet 3.3 지원 OS(https://docs.puppetlabs.com/pe/latest/install_system_requirements.html)

 

 


Puppet 기타 소개 

 

퍼펫은 IT자동화 소프트웨어업체 '퍼펫랩스(Puppet Labs)'에서 만들었다. 특정 운영체제(OS)에 종속된 명령어 대신 자체 시스템 구성 언어를 써서 각 사용자, 서비스, 패키지를 관리하는 모델기반의 IT자동화 도구로 묘사된다. 유명 리눅스 배포판 저장소에서 'APT'나 'YUM' 패키지 형태로 내려받아 쓸 수 있다.

퍼펫은 오픈소스 버전과 그에 기반한 엔터프라이즈 버전 형태로 제공된다. 오픈소스판은 지난 2005년 공개된 첫 버전부터 2.7.0 버전까지는 GPL 기반으로, 그뒤부터 지난달 4일 공개된 3.1.0 버전까지는 아파치2.0 라이선스로 제공된다. 엔터프라이즈버전은 지난 2011년 2월 첫선을 보였다.

퍼펫랩스 설명에 따르면 퍼펫이 구동되는 환경은 모든 주요 리눅스 배포판, 솔라리스와 HP-UX와 AIX같은 주요 유닉스플랫폼, 마이크로소프트(MS) 윈도를 아우른다. 물리적인 인프라 뿐아니라 클라우드와 하둡 기반 환경도 다룰 수 있다. 아마존EC2에 특화된 이미지 '리눅스AMI'에도 퍼펫이 포함돼 있다.

퍼펫을 쓰면 인프라에 필수패키지를 자동적으로 설치한 뒤 연관 서비스를 시작하고 관리자가 의도한 상태로 통제할 수 있다. 일례로 구글은 서비스운영단을 제외한 사내 모든 리눅스 및 맥OS 기반 데스크톱, 노트북, 서버 인프라를 퍼펫으로 관리한다. 이밖에 트위터, 징가, 델, 뉴욕증권거래소 등이 사용중이다.


 

 

Posted by 네떡지기

티스토리 툴바