'master'에 해당되는 글 3건

  1. 2016.08.09 Puppet Part2
  2. 2016.08.04 Puppet Part 1
  3. 2014.11.21 Automation for Networker[1] - Puppet : Part 1
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.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 네떡지기

티스토리 툴바