HieraとR10Kを使用したPuppetバージョン3.8のプログラミング例

もっと深くする必要があります。

インセプション



ここでは、プログラミングの例/テクニックを説明します。 理由は同じです。インターネット上にさらにドックが必要です。 前回の記事では 、Centos 6.5を使用してPuppetバージョン3.8をインストールおよび設定することを例として説明しました。 最も簡単な例は、クライアント/サーバーバンドルの機能をテストする場合です。 次に、これがどのように複雑になるのか、なぜこれが必要なのかを見てみましょう。

例1：モジュールマニフェストでパラメーターを使用する

class test1 { #    $text1 = “our” #   $text2 = “text” #   file { 'puppetenv file': #  ,  «puppetenv file» –    #   file.     . path => '/tmp/puppetenv', #    ensure => file, #   content => "test: ${text1} - ${text2}" #      } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パラメーター内のテキストの送信のチェーン：

クラス（$ text1 $ text2）->ファイル（コンテンツ（$ {text1}-$ {text2}）

例2：モジュールマニフェスト内のパラメーターの統合ストレージ

次のレベル：多くのクラスがあり、変数のライブラリの類似物を作りたいと思っています。 パラメータは1つのレシピに保存して、モジュール全体で使用できます。 たとえば、いくつかのシステム変数を収集し、独自のものを追加します。



基本を少し繰り返しましょう。



/ etc / puppet / modulesのマスターサーバーに移動して、スケルトンを生成します。

 puppet module generate myname-test1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これをすべてやり直すことができるため、入力を8回押します。 ディレクトリmyname-test1を取得し、test1に名前を変更します。 モジュールをビルドしてパブリックPuppet forgeにアップロードする場合は、フルネームが必要です。



ファイル/etc/puppet/modules/test1/manifests/init.ppを作成します

 class test1 ( $envname = $test1::params::env, #     params $text1 = $test1::params::text1 ) inherits test1::params { #    inherits file { 'puppetenv file': path => '/tmp/puppetenv', ensure => file, content => "${env} - test: ${text1}" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイル/etc/puppet/modules/test1/manifests/params.ppを作成します

 class test1::params { $env = $settings::environment #   puppet $text1 = 'ptestint' #    }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

説明：

test1-モジュール名-パペット値システムのプロジェクトのルート名。

init.pp、params.pp-マニフェスト-1つのマニフェストには1つのクラスが格納されます。 ファイル名とクラスは一致する必要があります。

class test1-初期クラス。クラスは単純なinclude test1を介して単純に呼び出されたときにデフォルトで動作します

必要に応じて、空のままにして、個別の名前クラスを作成できます（以下を参照）。

クラスtest1 :: params-名前クラス。 paramsという名前は、便宜上選択されており、どのような名前でもかまいません。



次の2つの方法でコードの構文を確認できます。

-次のようなコマンドで最初に利用可能：

 puppet parser validate /etc/puppet/modules/test1/manifests/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-gem install puppet-lint を使用して、より高度なスペルチェッカーppuppet-lintをインストールし 、ファイルを確認します（同時に、-fixスイッチを使用して構文を少し磨くことができます）。

 puppet-lint --fix /etc/puppet/modules/test1/manifests/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、実際にはそれらに依存しないでください。間違ったマニフェスト名のようなエラーを簡単にスキップできます。

 Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find parent resource type 'test::params' of type hostclass in production at /etc/puppet/modules/test1/manifests/init.pp:1 on node stage.test.net
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しになりますが、ブランチ3.8.4でモジュールコードが変更されると、puppetmasterサービスまたはhttpdサービスを再起動して、モジュールの変更が無視されないうちにすぐに適用されることに注意してください。 他のバージョンではおそらく表示されません。 モジュールのキャッシュが残っているのではないかと思われます。



test1モジュールの呼び出しを、テストノードstage.test.netの /etc/puppet/manifests/site.ppファイルに追加します。

 node default { } node 'stage.test.net' { include test1 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントで確認します。

サービスを構成し、XX（通常は30）分間待機してから、動作するまでログを確認できます。 そして、すべてを手動で実行できます。

 [root@stage ~]# puppet agent --test Info: Retrieving pluginfacts Info: Retrieving plugin Info: Caching catalog for stage.test.net Info: Applying configuration version '1459348679' Notice: /Stage[main]/Test1/File[puppetenv file]/ensure: defined content as '{md5}af1b5424181346c5f4827af742b07abf' Notice: Finished catalog run in 0.12 seconds [root@stage ~]# cat /tmp/puppetenv production - test: ptestint
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、ファイルは正常に作成されました。 誰もがパラメーターの使用がどこに行くことができるかを見たいなら、ここにapacheのサンプルモジュールがあります。



ptestintテキストの送信チェーン：

マニフェスト/ site.pp->モジュール/ test1 / init.pp（$ test1 :: params :: text1）-> file（content（$ {text1}）



ここで、/ etc / puppet / manifests / site.ppのデフォルト変数を変更するにはどうすればよいですか。これらは優先度が高いためです。

 node 'stage.test.net' { # include test1 class { 'test1': text1 => 'newparam', } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントで確認します。

...

-production-テスト：ptestint

\ファイルの最後に改行なし

+生産-テスト：newparam

\ファイルの最後に改行なし

...





ご覧のとおり、更新はうまくいきました。

テキストの送信のチェーンはnewparamです：

マニフェスト/ site.pp（$ text1）->モジュール/ test1 / init.pp（text1）-> file（コンテンツ（$ {text1}）



1つのディレクトリにすべてのマニフェストを作成するのではなく、 / test1 / manifests / check / time.ppという形式でもう 1つのレベルを作成する場合にも、このようなパラメーターの保存は便利です

そして、次の形式の呼び出しを通じて、どこでもこのクラスを使用します。

 class { '::test1::check::time': }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例3：テンプレートを追加します。

前の例のバリアントのマイナスは、 コンテンツに 1行しかないことです 。 したがって、テンプレートを使用して大きなファイルを生成することをお勧めします。



テストに追加します。

-ファイル/etc/puppet/modules/test1/manifests/usetmpl.pp-テンプレートを操作するための新しいクラス

 class test1::usetmpl ( $envname = $test1::params::env, #1 $text1 = $test1::params::text1 #2 ) inherits test1::params { file { 'puppetenv file from tmpl': path => '/tmp/puppetenv', ensure => file, content => template('test1/puppetenv.erb'), } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテンツテキストをpuppetenv.erbテンプレートを呼び出すことで置き換えることに加えて、すべてを個別のクラスに入れますが、init.ppに2番目のファイルを追加することもできます。



-ファイル/etc/puppet/modules/test1/templates/puppetenv.erb-ジェネレーターテンプレート。

 # Created by puppet Our text: <%= @text1 %> Env: <%= @envname %> Host: <%= @hostname %>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの変数$ {text1}は、Ruby形式で<％= @ text1％>として渡されます。 $ envnameはparams.ppから取得され、site.ppで$ text1を再定義し、同時に「システム」変数を追加しました（これらはpuppetでファクトと呼ばれます）<％= hostname ％>



クライアントで確認します。

 [root@stage ~]# puppet agent --test ... -production - test: newparam \ No newline at end of file +# Created by puppet +Our text: param_tmpl +Env: production +Host: stage ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果：

 [root@stage ~]# cat /tmp/puppetenv # Created by puppet Our text: param_tmpl Env: production Host: stage
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テキストparam_tmplのリンクチェーン：

manifests / site.pp（$ text1）-> modules / test1 / init.pp :: usetmpl（$ text1）-> file（content（puppetenv.erb（<％= @ text1％>）））

例4：Hieraまたはさらに集中化

1〜10台のサーバーで作業する必要がある場合は、通常のモジュールで十分ですが、さらに多くのモジュールがある場合、さらに各モジュールが独自の方法で構成されているサブクラスターに分割すると、パラメーターから膨張したsite.ppモジュールで混乱するか、同じ名前のモジュールとそのバージョン。 さらに深く、Hieraをセットアップします。



HieraはRubyライブラリであり、デフォルトでPuppetに含まれており、すべてのモジュールのデータを単一のディレクトリに整理するのに役立ちます。



ストレージを運用するには、次のものが必要です。



-このタイプに関する/etc/puppet/hiera.yamlファイルを作成します。

 :hierarchy: - "%{::clientcert}" - "%{::custom_location}" - "nodes/%{::fqdn}" - "nodes/%{::environment}" - "virtual/%{::virtual}" - common - "%{::environment}" :backends: - yaml :yaml: :datadir: "/etc/puppet/hieradata"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ネイティブファイル/etc/hiera.yamlの優先度の形式でシステムからのフラッシュを待っています

つまり、シンボリックリンク/etc/hiera.yaml-> /etc/puppet/hiera.yamlに置き換える必要があります



-フォルダー/ etc / puppet / hieradataを作成します（名前を指定して、datadirで指定できます）

このフォルダー内のファイルには、拡張子.yamlとデータ形式YAMLが必要です。



-ファイル/etc/puppet/hiera/common.yamlを作成します

たとえば、ここでは、すべてのノードで使用可能な2番目のテストパラメーターを記述できます

 test::text2: common-hiera
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディレクトリ「nodes /％{:: fqdn}」をノードパラメーターのストレージポイントとして指定したため、テストノード用にファイル/etc/puppet/hiera/nodes/stage.test.net.yamlを作成します。 ここで、3番目のテストパラメーターと、パラメーターと別の配列がある小さな配列を設定できます。

 testparam::text3: 'node stage hiera' arrexmpl::colors: bw: "B&W" rgb: - red - blue - green
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デバッグモードとシンプルモードでコマンドラインからパラメーターの可用性を確認する：

 [root@pmaster /etc]# hiera -d test::text2 DEBUG: Wed Mar 30 13:06:13 -0400 2016: Hiera YAML backend starting DEBUG: Wed Mar 30 13:06:13 -0400 2016: Looking up test::text2 in YAML backend DEBUG: Wed Mar 30 13:06:13 -0400 2016: Looking for data source common DEBUG: Wed Mar 30 13:06:13 -0400 2016: Found test::text2 in common common-hiera [root@pmaster /etc]# hiera testparam::text3 ::fqdn=stage.test.net node stage hiera hiera arrexmpl::colors ::fqdn=stage.test.net {"rgb"=>["red", "blue", "green"], "bw"=>"B&W"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、それらをパラメーターに保存し、テンプレートで使用する必要があります。

/etc/puppet/modules/test1/manifests/params.pp

 class test1::params { # sss $env = $settings::environment $text1 = 'ptestint' $text2 = hiera('test::text2', 'ptestint2') #   'test::text2'.       'ptestint2' $text3 = hiera('testparam::text3', 'ptestint3') $colors = hiera('arrexmpl::colors', 'nohiera') #    arrexmpl::colors if $colors != 'nohiera' { #      $c1 = $colors['bw'] $c2 = $colors['rgb'] } else { $c1 = "lost" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/etc/puppet/modules/test1/manifests/usetmpl.pp

 class test1::usetmpl ( $envname = $test1::params::env, $text1 = $test1::params::text1, $text2 = $test1::params::text2, #     $text3 = $test1::params::text3, $c1 = $test1::params::c1, $c2 = $test1::params::c2 ) inherits test1::params { file { 'puppetenv file': path => '/tmp/puppetenv', ensure => file, content => template('test1/puppetenv.erb'), } file { 'hiera test': path => '/tmp/phiera', ensure => file, content => template('test1/hieratst.erb'), } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/etc/puppet/modules/test1/templates/hieratst.erb

 # Hiera test # Created by puppet Our text1: <%= @text1 %> Our text2: <%= @text2 %> Our text3: <%= @text3 %> Colors: BW = <%= @c1 %> <% if c1 == "lost" %> #    ! Hiera fail ! <% end -%> RGB = <%- c2.each do |colors| -%> #    arrexmpl::colors::rgb: - <%= colors %> <%- end -%>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントで確認します。

 [root@stage ~]# puppet agent --test ... [root@stage /etc/puppet]# cat /tmp/phiera # Hiera test # Created by puppet Our text1: paramtmpl Our text2: common-hiera Our text3: node stage hiera Colors: BW = B&W RGB = - red - blue - green
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例5：R10Kまたはさらに集中化

実際、サーバーのスコアが数万に達すると、それらを環境に分割する方が安全になります。 ペンでこれを行うことができますが、R10Kを使用することをお勧めします。R10Kを使用すると、個人設定に保存されているモジュールを使用して個別の構成を実行できます。 つまり、本質的に、単一の巨大なsite.ppをその構成ツリーに置き換えます。



私はテストを行いません。例として作業構成を使用して、このような設定の条件付きアルゴリズムを提供します。



-サーバーは構成グループに分割され、 / etc / puppet / environmentsの個別のディレクトリに保存されます



たとえば、サーバーグループtest_devopsでレシピをテストします



ヒエラツリー



-git / bitbucketに保存

-マスターサーバーへの変更の適用を更新する傾向がある

-hiera.yamlで追加：階層：

  - %{environment}/%{role}/%{calling_module} - %{environment}/%{role} - %{role} - %{environment}/%{environment}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-パラメータは条件付きでファイルに保存されます

/ etc / puppet / hieradata / test_devops / test_devops.yaml -R10Kの追加ラベルを介したすべてのノード

  classes: - roles::base
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/ etc / puppet / hieradata / test_devops / stage.test.net.yaml for the server plus you need the label for R10K

  classes: - roles::stagesrv::test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

R10Kを介したtest_devopsのモジュールスタートアップの設定



-stage.test.netノードで、/ etc / puppet / puppet.confファイルに行を追加します

 environment = stage_nbc210
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

- / etc / puppet / environments / test_devops / Puppetfile-使用されるすべてのモジュールはここに保存されます。

記録例

 mod 'saz/sudo', '3.0.1' mod 'stdlib', :git => 'git://github.com/puppetlabs/puppetlabs-stdlib.git', :ref => '4.1.0' mod 'test1', :git => 'git://github.com/fake_link/test1.git', :ref => 'master'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらは、次のようなコマンドを使用してコンソールでダウンロード/更新されます

 sudo r10k deploy module test1 -e test_devops
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/ etc / puppet / environment / test_devops / modules / test1-モジュールが落ちた場所



- / etc / puppet / environment / test_devops / dist / profiles / manifests / -モジュールを起動するためのマニフェストツリー。 ファイル名はモジュール名と一致してはなりません 。



ここにruntest1.ppのようなファイルを作成します

  class profiles::runtest1{ class { 'test1': text1 => 'newparam', }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、ノードは表示されなくなりました。 他のノードに他のパラメーターが必要な場合は、runtest2.ppなどを作成できます。追加のレベルがサポートされています。 たとえば、ファイル/etc/puppet/environments/test_devops/dist/profiles/manifests/ver2/runtest3.ppを作成できます

 class profiles::ver2::runtest3 class { 'test1': text1 => 'newparam v2', } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-次に、マニフェスト起動モジュールをノードにバインドする必要があります。

/etc/puppet/environments/test_devops/dist/roles/manifests/init.pp

 class roles { } class roles::base inherits roles { include profiles::base } class roles::private inherits roles { include profiles::private } class roles::public inherits roles { include profiles::public } class roles::stagesrv::test { # <-      Hiera ? include profiles::runtest1 } #          ,   . #      ,  runtest3      # runtest1,        roles::ver2::runtest3, . .   . class roles::ver2::runtest3 inherits roles::stagesrv::test { include profiles::ver2::runtest3 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-実際には、チューニング結果のダンプがありました

 sudo r10k deploy environment test_devops
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、自動実行ノードに適用されるか、puppet agent --testを使用して手動でテストできます



それだけです。 ここまで読んでくれてありがとう。



この記事に含めたいと思う人からのその他のバージョンのアドオンまたはオプション。



クックブックを整理するための完全に異なるアルゴリズム-「モジュール」とレシピでのよりクリーンなRuby-「マニフェスト」があるため、シェフクライアントサーバー/シェフ+ berkshelf /シェフ+ AWS Opsworkの使用経験と比較しません。



追加のドック：

1. Puppetコードのマイクロサンプルによる。

2. Hieraの紹介

3. R10Kの少し