人形。 パート1：Hieraの概要

この記事は、Puppetを使用して大規模なインフラストラクチャを管理する問題についての私のビジョンを示したい3つの記事の最初の記事です。 最初の部分は、強力な階層編成ツールPuppet Hieraの紹介です。 この記事は、すでにPappetに精通しているが、Hieraにはまだ精通していない人を対象としています。 その中で、この強力なツールと、それが多数のサーバーの管理を容易にする方法についての基本的な知識を提供しようとします。



おそらく、 Puppetを使用して大規模なインフラストラクチャを管理するのは簡単なことではないことをご存じでしょう。 10台のサーバーでPappetが必要ない場合、50の場合、必要に応じてコードを記述できます。500台以上のサーバーの場合は、この場合、作業の最適化を真剣に検討する必要があります。 Pappetが当初は大規模なインフラストラクチャのソリューションを考えていなかったように思われます。少なくともその中の階層は最初は非常にひどくレイアウトされていました。 標準ノードの定義は 、大企業ではまったく適用できません 。 ノードの継承 （およびクラスの継承 ）はPuppetlabsにはまったくお勧めできません。代わりに、HieraやExternal Node Classifier （ENC）などの外部ソースから階層データをロードすることをお勧めします。

最初はENCの概念はHieraとそれほど変わらないという事実にもかかわらず、何らかの理由で、 Puppet DashboardやForemanなどの特定のENC実装があまり好きではありません。 理由を説明します。



1）インフラストラクチャに関するデータは、アプリケーションデータベースのどこかにあります。 アプリケーションがクラッシュした場合にそれらをどのように取得するのですか？ 知りません 推測することはできますが、確かなことはわかりません。

2）強力なENCは、その能力のために拡張が難しく、困難です。 対照的に、Hieraは彼のすべてのデータをテキスト形式で保存します。 テキストデータは、そのような必要が生じた場合、複数のPappetマスター間でgitとr10kを使用して非常に簡単に同期できます。 一般的に、テキスト構成は、昔ながらの音に関係なく、UNIXの方法です。



繰り返しますが、監視およびレポートツールとしてのPuppet DashboardおよびForemanの可能性を拒否しません。 グラフと画像を備えた美しいWebインターフェースが必要ですが、それは表示の手段としてのみであり、インフラストラクチャの構成を変更する手段としてではありません。 また、ForemanはPappet以外にも多くのことができることを知っています（ Red Hat Satellite Server 6およびForemanベースのKatelloプロジェクトが代表的な例です）。 それでもなお、私はHieraインフラストラクチャ全体の構成の保管場所が好きです。



ヒエラとは？ これはRubyライブラリであり、デフォルトでPappetに含まれており、Pappetでのデータの整理に役立ちます。 それなしで行うことは可能ですか？ できます。 マニフェストにすべての数値とパラメーターを書き込むことができますが、その後、開発の特定の段階から完全に恐ろしくなり、何が保存され、何が原因であるかを覚えるのがますます難しくなります。



Hieraを使用するメリットは何ですか？ インフラストラクチャに実際に適用するPappetコードから、インフラストラクチャの特定のパラメーター（ユーザーuid、sshキー、dns設定、あらゆる種類の集中ファイルなど）を分離し始めます。 これにより、ある日、そのようなサーバーまたはサーバーのグループ上の特定のユーザーのどのUIDを見つける必要がある場合、この情報がどこに保存されているかがすぐにわかります。適切なユーザーを探して、UIDの変更が「ここ」につながることを予測してみてください。 もちろん、ヒエラの奇跡を期待するべきではありません。 結局のところ、これはデータを保存および整理するための単なる方法です。



しかし、十分な歌詞は 、ビジネスに取り掛かりましょう 。 Hiera（階層から）は階層で動作します。 そして、/ etc / puppet / hiera.yamlに次の階層を書きました。

:hierarchy: - "%{::environment}/nodes/%{::fqdn}" - "%{::environment}/roles" - "%{::environment}/%{::environment}" - common :backends: - yaml :yaml: :datadir: '/etc/puppet/hiera'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この階層を覚えておいてください、将来的には積極的に使用します。

Hieraにあまり詳しくない人のために説明します。 「/ etc / puppet / hiera」フォルダーをHieraデータストアとして設定します。 このフォルダー内のファイルには、拡張子.yamlとデータ形式YAMLが必要です。 次に、Hieraがフォルダーに表示するファイル名を設定します。 HieraはPappetのコードから呼び出されるため、 ファクトを含め、Pappetと同じ変数を使用できます。 各ノードの組み込みファクトはその環境であり、Hieraで変数％{:: environment}として使用できます。 HieraのノードのFQDNは、予想どおり％{:: fqdn}のように見えます。 したがって、この階層は同様のファイル構造に対応しています。



/ etc / puppet / hiera /

|-common.yaml

|-プロダクション/

| ----- production.yaml

| ----- roles.yaml

| -----ノード/

| -------- prod-node1.yaml

| -------- prod-node2.yaml

|-開発/

| ----- development.yaml

| ----- roles.yaml

| -----ノード/

| -------- dev-node1.yaml

| -------- dev-node2.yaml



hiera.yamlのレベルの順序（ファイル構造ではなく）が重要です。 Hieraは上から下へブラウジングを開始し、それはすべて、Pappetマニフェストで使用するHieraの呼び出し方法に依存します。 3つの方法がありますが、例を挙げて説明します。 上記のhiera.yamlファイルで階層を記述し、次の内容の3つのファイルを作成します。







Hieraはコマンドラインクエリをサポートしています。 実際、操作の原理を理解する最も簡単な方法はコンソールからです。 Hieraはデフォルトでその設定を/etc/hiera.yamlに保持します。 このファイルを/etc/puppet/hiera.yamlへのシンボリックリンクにする必要があります。 その後、簡単な呼び出しを行います。

 [root@testnode]# hiera classes ["common_class1", "common_class2"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリクエストでは環境に関する情報を提供しなかったため、Hieraのfqdnは階層の最下位レベルであるcommon.yamlファイルからデータを取得します。 配列要素は角括弧内に表示されます。 環境に関するデータを提供してみましょう。

 [root@testnode]# hiera classes ::environment=production ["production_class1", "production_class2"] [root@testnode]# hiera classes ::environment=production ::fqdn=testnode ["node_class1", "node_class2"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

production.yamlからのデータは階層内でより高いため、それらはより優先され、common.yamlから受信したデータを上書きします。 同様に、testnode.yamlのデータはproduction.yamlのデータを上書きします。 ただし、上位階層にデータがない場合、論理的な方法でデータは下位階層から取得されます。

 [root@testnode]# hiera common ::environment=production common_value [root@testnode]# hiera production ::environment=production ::fqdn=testnode production_value
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、上記のファイルに従って、配列ではなく文字列が返されます。

このタイプの要求は、 優先順位検索と呼ばれます 。 ご覧のとおり、常に階層内で見つかった最初の値（最も高い優先度を持つ）を返し、その後、基礎となる階層を調べずに終了します。 Pappetでは、標準のhiera（）関数がそれに対応します。 この例では、これはhiera（「クラス」）の呼び出しになります。 Pappetは常にコンテキスト外でHieraを呼び出すため、クエリ行で他の何かを指定する必要はありません。



次のタイプのリクエストは、 Array mergeです。 私たちは見ます：

 [root@testnode]# hiera --array classes ["common_class1", "common_class2"] [root@testnode]# hiera --array classes ::environment=production ["production_class1", "production_class2", "common_class1", "common_class2"] [root@testnode]# hiera --array classes ::environment=production ::fqdn=testnode ["node_class1", "node_class2", "production_class1", "production_class2", "common_class1", "common_class2"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このタイプのクエリは、階層のすべてのレベルを通過し、検出されたすべての値（文字列と配列）を1つの大きな単一配列に収集します。 Pappetの用語では、このクエリはhiera_array（）と呼ばれます。 ただし、このタイプのリクエストはハッシュを収集できません。 パッセージ中にハッシュに遭遇すると、エラーがスローされます。

 [root@testnode]# hiera --array roles /usr/share/ruby/vendor_ruby/hiera/backend/yaml_backend.rb:38:in `block in lookup': Hiera type mismatch: expected Array and got Hash (Exception)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様の状況では、優先順位のルックアップはうまくいき、ハッシュを（中括弧で）返します：

 [root@testnode]# hiera roles {"common_role1"=>{"key1"=>"value1", "key2"=>"value2"}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ハッシュを収集する必要がある場合はどうなりますか？ 3番目のタイプのリクエストを使用します： Hash merge ：

 [root@testnode]# hiera --hash roles {"common_role1"=>{"key1"=>"value1", "key2"=>"value2"}} [root@testnode]# hiera --hash roles ::environment=production {"common_role1"=>{"key1"=>"value1", "key2"=>"value2"}, "production_role1"=>{"key1"=>"value1", "key2"=>"value2"}} [root@testnode]# hiera --hash roles ::environment=production ::fqdn=testnode {"common_role1"=>{"key1"=>"value1", "key2"=>"value2"}, "production_role1"=>{"key1"=>"value1", "key2"=>"value2"}, "node_role1"=>{"key1"=>"value1", "key2"=>"value2"}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この要求は、前の要求と同様に、階層のすべてのレベルを通過し、すべてのハッシュを1つの大きな共通ハッシュに収集します。 配列または文字列を収集しようとすると、エラーが返されると推測するのは簡単です。

 [root@testnode]# hiera --hash classes /usr/share/ruby/vendor_ruby/hiera/backend/yaml_backend.rb:42:in `block in lookup': Hiera type mismatch: expected Hash and got Array (Exception)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Pappetでは、このリクエストはhiera_hash（）と呼ばれます。 同じ階層レベルで、同じハッシュに異なる「キー=>値」のセットがある場合はどうなりますか？ たとえば、共通レベルのユーザーテストにはUID = 100があり、ノードレベルではtestnodeにUID = 200がありますか？ この場合、特定のキーごとに、ハッシュルックアップは優先度ルックアップのように動作します。つまり、より高い優先度値を返します。 詳細についてはこちらをご覧ください 。



さて、クール （ まあ、そうで はない ）ですが、なぜこれがすべて必要なのでしょうか？

Pappetは自動的に （バージョン3.xではこのために何も設定する必要さえありません）彼が使用できるパラメーターをHieraでスキャンします。

そもそも、 Pappetのサイトから少し変更した単純な例です （ちなみに、この例では廃止されたntp :: autoupdateおよびntp :: enableパラメーターを示しています。現在の名前は以下にあります）。 長い間苦しんできたpuppetlabs-ntpモジュールを苦しめます。 Pappetで次のntp設定を表現したいとします：



これを行うには、Hierのcommon.yamlに次の行を追加します。

 classes: - ntp ntp::restrict: - restrict default kod nomodify notrap nopeer noquery - restrict -6 default kod nomodify notrap nopeer noquery - restrict 127.0.0.1 - restrict -6 ::1 ntp::service_ensure: running ntp::service_enable: true ntp::servers: - 0.pool.ntp.org iburst burst - 1.pool.ntp.org iburst burst - 2.pool.ntp.org iburst burst - 3.pool.ntp.org iburst burst
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスが呼び出されたときにクラスに渡されるntpクラス変数の特定の値が、ここに単純にリストされていることが簡単にわかります。 これらの変数は、ntpクラスのヘッダーで宣言されています（ファイルモジュール/ ntp / manifests / init.pp）。 Hieraからクラスにパラメーターを渡すこの方法では、Pappetが目的のスコープ （スコープ）に正しくロードするために、 完全修飾変数名を使用することが絶対に必要です。

あとは、環境のメインPappetマニフェスト（site.pp）に1行追加するだけです。

 hiera_include('classes')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このラインは、そのシンプルさと簡潔さにもかかわらず、舞台裏で多くの作業を行います。 まず、PappetはHieraのすべての（！）階層を調べ、Hieraのクラスの すべてのセクションで宣言されているすべてのクラスを読み込みます。 その後、PappetはHieraのすべての完全修飾変数を調べて、対応するクラスのスコープにロードします。 クラスリストからntpクラスを削除しても、YAMLファイルでこのクラスの変数を削除し忘れると、Pappetは「宣言されたクラスntpを見つけることができません」などのエラーをスローします。 ロードされたクラスがないと、その変数はすべての意味を失います。

ここで、HieraのYAMLファイル内の単語クラス（他のすべての人と同様）には、特別な意味や予約された意味はありません。 クラスの代わりに、production_classes、my_classes、my-％{:: environment}などの他の単語を書くことができます。 はい、後者も同様です。Pappet 変数はHieraセクションとハッシュキーの名前でも使用できます。 文字列変数や配列と同様に、ハッシュ値で変数を使用することはできません。時には残念です！



したがって、Hiera階層のPappetのマニフェストからntpサービスパラメータを効果的に削除しました。 これで、記事の冒頭で説明した階層に従って、これらのntpパラメーターがインフラストラクチャ内のすべてのノードに完全に適用されます。 しかし、環境のより高いレベルまたは特定のサーバーのレベルでこれらのパラメーターを再定義する場合は、必要な階層のレベルで必要な変数の値を指定することで簡単にこれを行うことができます。



実際、HieraからPappetにデータを自動的にインポートするこの方法が唯一の方法ではありません。



前の方法には1つの重大な欠点があります。それはあまりにも自動化されています。 単純な構成でその動作を簡単に予測できる場合、多数のホストの場合、インポートされたクラスのリストに別のクラスを追加した結果を確実に伝えることが常に可能とは限りません。 たとえば、 puppetlabs-apacheモジュールを使用して、特定のApache構成をいくつかのノードに追加できます。 無害なフレーズを含める場合

 classes: - apache
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

production.yamlファイルに追加すると、すべての本番ホストでApacheのインストール、設定、起動が行われます。 さらに、apacheモジュールは、 以前に設定されていた以前の Apache 設定全体を消去します。



これがこのような楽しいデフォルトの動作です！ そのため、ドキュメントを読まなければ、単純な「include apache」は高価になる場合があります。



しかし、何をすべきか？！ YAMLに必要なノードだけにapacheを入力しますか？ どういうわけか、それは完全に中央で取得されていません...

含めたいものと望まないものを選択できるようにするために、Pappetはcreate_resources（）関数を作成しました。 そのアプリケーションは、 ここで美しく説明されています 。

関数create_resources（resource、hash1、hash2） ：リソースリソース Pappetを作成し、入力hash1およびhash2を渡します。 Hash2はオプションですが、指定されている場合、そのキーと値はhash1に追加されます。 hash1とhash2の両方に同じパラメーターが指定されている場合、hash1がより高い優先順位になります。 リソースは、標準のリスト（ Puppet型リファレンスを参照 ）から取得するか、または私たちまたはクラスで事前に宣言（ 定義された型 ）することができます。 標準リソースの例はユーザーリソースで、宣言されたリソースの例はapacheモジュールのapache :: vhostです。 Apacheの例を考えてみてください（ここでは、上記のリンクから良い例をコピーして貼り付けることができます）。



2つのApache仮想ホストの次の構成をHieraに転送するとします。

 apache::vhost { 'foo.example.com': port => '80', docroot => '/var/www/foo.example.com', docroot_owner => 'foo', docroot_group => 'foo', options => ['Indexes','FollowSymLinks','MultiViews'], proxy_pass => [ { 'path' => '/a', 'url' => 'http://backend-a/' } ], } apache::vhost { 'bar.example.com': port => '80, docroot: => '/var/www/bar.example.com', }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Hieraでは、次のようになります。

 apache::vhosts: foo.example.com: port: 80 docroot: /var/www/foo.example.com docroot_owner: foo docroot_group: foo options: - Indexes - FollowSymLinks - MultiViews proxy_pass: - path: '/a' url: 'http://localhost:8080/a' bar.example.com: port: 80 docroot: /var/www/bar.example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Pappetマニフェストに書かれているのは次のとおりです。

 $myvhosts = hiera('apache::vhosts', {}) create_resources('apache::vhost', $myvhosts)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここの最初の行では、Apache :: vhostsセクションから構成全体をダウンロードするようHieraに依頼しました。 情報は、「foo.example.com」と「bar.example.com」の2つのハッシュの形式でロードされました（正確には、2つの名前付きハッシュからなる名前のないハッシュが$ myvhosts変数に分類されました）。 その後、これらのハッシュはapache :: vhostsリソースに順番に転送され、Pappetによって作成されます。



マニフェストからHieraにデータを転送する方法のもう1つの良い例です。 ユーザー管理。 Hieraで次のコードを記述する場合：

そして、site.ppに次のように記述します。

 $node_users = hiera_hash('users') create_resources(user, $users, {})
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、上記のすべてのユーザーが作成されます。 hiera_hashを呼び出すと、users：セクションで宣言されたすべてのユーザーが階層全体から効率的に収集されることに注意してください。 競合がどこかで発生した場合（異なるファイルの異なるユーザーUID）、Hieraは階層の上位レベルで説明されている値を使用します。 論理的です。



また、create_resources（）と定義された型は、Pappetのループの繰り返しを整理する1つの方法です。最初はこの関数がありません（少なくとも将来のパーサーがなければ、まだ使用するのは夢中ですか？）。 ここでは、両方の反復方法について詳しく説明します 。



それがすべてです。 Hieraの基本的な使い方を説明しました。 Pappet、hiera（）、hiera_array（）、hiera_hash（）、hiera_include（）、create_resources（）の標準関数を使用すると、おそらく既に推測したように、多くのことを思いつくことができます。

次の記事では、PappetとHieraを使用したサーバーロールの管理について説明します。