'퍼펫'에 해당되는 글 7건

  1. 2016.09.05 Puppet Part 6
  2. 2016.08.20 Puppet Part 5
  3. 2016.08.18 Puppet Part 4
  4. 2016.08.12 Puppet Part 3
  5. 2016.08.09 Puppet Part2
  6. 2016.08.04 Puppet Part 1
  7. 2014.12.20 Automation for Networker[3] - Puppet : Part 2
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/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 네떡지기

티스토리 툴바