Clever Geek Handbook

パペット開発キットを使用したパペット用モジュールの開発

約1か月前、私は「テーブル上の」パペット用モジュールを作成する（つまり、内部インフラストラクチャ用）か、それをユニバーサルにするか、ソースを開いてパペットフォージで公開するかを選択しました 。 もちろん、2〜3学年をすばやくスケッチして落ち着かせる方が速くて簡単ですが、モジュールの公開中に得た経験は貴重であり、共有したいと思います。 RuNetには、Puppet Development Kit（以降PDK ）の使用に関する情報がないため、これは一種のチュートリアルと考えることができます。







についての記事は何ですか



モジュール（または2つ）を開発する過程で、モジュールの開発と保守の両方を大幅に促進するPDKを発見しました。 すなわち：









すべての興味 猫をお願いします！







例として



読み取りプロセス中に何を意味するのかを見て、感じたい場合は、言及されている2つのモジュールの一方（または両方）、 clickhouseとxmlsimpleを開くことができます。 どちらも、記事に記載されているPDKおよびその他のツールを使用して開発されました。







内容





PDKとは



公式文書から：







クラス、定義済みのタイプ、タスクを含む完全なモジュールを作成し、作業をテストして検証します。 PDKは、完全なモジュール構造、クラスのテンプレート、定義されたタイプ、タスク、およびテストインフラストラクチャを提供します。 さまざまなオペレーティングシステムおよび複数のPuppetバージョンに対してモジュールを検証およびテストできます。

私の無料翻訳で：







クラス、タイプ、タスク、およびテストを含む完全なモジュールを作成して、モジュールの動作を検証できます。 PDKは、上記のすべての完全な構造とテンプレートを提供します。 このツールを使用すると、さまざまなバージョンのパペット、および異なるオペレーティングシステムでモジュールの動作を確認できます。

いいですね？ まあ、それは本当にそうです。 オープンソース用にすぐに書くことが決定されたモジュールの作業を開始した瞬間まで、私はこのツールを疑わなかったので、PDKを使用するために内部インフラストラクチャ全体を移転するつもりです。







それをどのように置くか、そしてどのツールとコマンドが含まれているかを説明します。







設置



公式インストールページ 。 このリンクを使用すると、ホストにPDKをインストールする正しい方法を見つけることがほぼ保証されます。 何らかの理由で運が良くなく、OSがそこにない場合は、次の形式のラウンドアバウトが常にあります。 







 gem install pdk


実際、PDKは単なる宝石であり、そのように設定されています。







PDKコンテンツ



一般に、PDKはモジュール開発を促進するための宝石のセットにすぎません。 次のツールが含まれています。







実用性 説明
metadata-json-lint 一致するパペットスタイルガイドのmetadata.jsonをチェックします
pdk コマンドラインからモジュールとその内容（クラス、タイプなど）を生成およびテストするためのツール
操り人形 Puppet言語スタイルガイドのパペットコードをチェックします
パペット構文 マニフェストの構文を確認する
puppetlabs_spec_helper パペットコードのスペックテスト用のRakeクラス、メソッド、およびタスクを提供します
rspec-puppet マニフェストをリソースディレクトリにコンパイルするときにパペットの動作をテストします（？）
rspec-puppet-facts ユーザー指定のパペットファクトでrspec-puppetを実行できます


モジュールを作成する



PDKがインストールされたので、いろいろ試してみてください。 最も単純なpdk help



コマンドpdk help



、使用可能なコマンドpdk help



表示します。 他のすべてのモジュールがあるフォルダーにいるとします。 次に、新しいものを作成しましょう。 







 $ pdk new module --template-url=https://github.com/puppetlabs/pdk-templates.git *** We need to create the metadata.json file for this module, so we're going to ask you 5 questions. *** [Q 1/5] If you have a name for your module, add it here. --> dummy [Q 2/5] If you have a Puppet Forge username, add it here. --> felixoid [Q 3/5] Who wrote this module? --> Mikhail f. Shiryaev [Q 4/5] What license does this module code fall under? --> MIT [Q 5/5] What operating systems does this module support? --> RedHat based Linux, Debian based Linux, Windows Metadata will be generated based on this information, continue? Yes pdk (INFO): Module 'dummy' generated at path '/tmp/dummy', from template 'https://github.com/puppetlabs/pdk-templates.git'.


ユーティリティは、metadata.jsonファイルに入力するように質問します。出力には、示されているとおり、gitのテンプレートからコンパイルされたモジュールファイルと補助ファイルが含まれています。







小さな発言-temliteは、最近修正されたいくつかの重大なバグを含め、非常に頻繁に変更されます。 したがって、インストールされているPDKのデフォルトではなく、最新バージョンを使用することをお勧めします。 --template-url



に、マイナス面があります： --template-url



引数を使用すると、PDKはこのパラメーターを~.pdk/cache/answers.json



に追加し、 pdk



コマンドの実行が遅れると判断して、それらをダウンロードしようとします。 したがって、 answers.json



からこのパラメーターを削除するか、モジュールを作成してmetadata.json



変更するときに使用しないでください。







PDKを使用して実行できるその他の手順を見ていきましょう。







新しいクラス 



 $ pdk new class dummy::class pdk (INFO): Creating '/tmp/dummy/manifests/class.pp' from template. pdk (INFO): Creating '/tmp/dummy/spec/classes/class_spec.rb' from template. $ cat manifests/class.pp # A description of what this class does # # @summary A short summary of the purpose of this class # # @example # include dummy::class class dummy::class { } $ cat spec/classes/class_spec.rb require 'spec_helper' describe 'dummy::class' do on_supported_os.each do |os, os_facts| context "on #{os}" do let(:facts) { os_facts } it { is_expected.to compile } end end end


このコマンドは、2つのファイルを作成します。クラスのマニフェストと、テスト用の仕様ファイルです。 ドキュメントのタグについては、後で詳しく説明します。







新しいdefined_type 



 $ pdk new defined_type type pdk (INFO): Creating '/tmp/dummy/manifests/type.pp' from template. pdk (INFO): Creating '/tmp/dummy/spec/defines/type_spec.rb' from template.


すべて同じ：リソースタイプと仕様ファイルのマニフェスト。







新しいプロバイダーとタスク



PDKは新しいプロバイダーやタスクを作成することもできますが、私はそれらと密接に連携していなかったため、必要に応じてこのトピックをより深く研究することをお勧めします。







パペット文字列を使用したドキュメントの生成



puppet strings



PDKツールキットの一部でpuppet strings



ない理由はよくわかりませんが、これは一見したところです。 開発中にヤードのタグを正しく設定した場合、ユーザーにドキュメントを提供する主な方法は2つあります。









魔法ではないようですが、出力には命令のあるモジュールがあります。 プラスは、たとえば@param



タグを使用して各パラメーターを記述しなくても、出力はクラスとタイプ/関数であり、パラメーターの最小限の記述はタイプとデフォルト値であるということです。 私の謙虚な意見では、これでさえも何もないよりはましであり、モジュールの使用がより魅力的になります。







もちろん、これはすべて自動化でき、CIステージとして追加できます。 それは完璧なオプションです。 私の手はまだ到達していませんが、未処理品にほこりがたまっています。 突然誰かがこのトピックについて何か言いたいことがあれば-私は感謝します。 考えとして：少なくとも、puppet-stringsの実行後にREFERENCE.mdが変更されるかどうかを確認するチェックを追加します。 もしそうなら、テストが失敗したと考えてください。







テンプレートのカスタマイズ



テンプレートのドキュメントは、 pdk-templatesリポジトリにあります。 つまり、モジュールのルートディレクトリにある.sync.yml



ファイルを使用してすべてを構成し、 pdk update



コマンドを使用して変更を適用します。 このファイルの各パラメーターは、モジュールのディレクトリにある別のファイルの名前であり、何らかの方法で変更する必要があります。 各テンプレートのパラメーターのほとんどは、「タッチ」で選択する必要があり、多くの場合、試行錯誤によってソースコードを確認しました。 ここでのドキュメントは、遅れることがあります。 残念ながら、あなた自身のリポジトリからの例へのリンクを提供することを除いて、言うことはほとんどありません。







上記の例から.sync.yml



を使用して変更したいくつかのパラメーターを非常に.sync.yml



に説明します。









さまざまなCIの実行



ここではすべてが非常に簡単です。 PDKを使用してモジュールを生成した直後に、appveyor、travis、gitlab-ciで検証が開始されます。 テストを実行するには、すぐにすべての準備が整い、チューニングに.sync.yml



同じ.sync.yml



使用されます。 特に好みはないので、何もお勧めしません。 より便利なものを使用してください。







ボーナス：クラス、型、関数の単体テストを作成します



この点は、私が説明しようと思っていた主要な資料の枠組みをかなり超えていますが、私には非常に役立つようです。







そのため、マニフェストとライブラリを備えたモジュールがあり、その中にクラス、型、および関数が含まれています（タスクとプロバイダーも忘れませんが、この部分には専門知識がありません）。 変更を目的とするコードが存在するため、明らかに、テストでオーバーレイして2つのことを確認することをお勧めします。









Puppetlabsは、 puppet-rspecと呼ばれるrspecフレームワークの拡張機能を提供します。 クラス 、 型、および関数をテストするためのドキュメントへのリンク。 よく見るために怠closelyにならないでください、他のセクションがあります。







ルビーを知らなくても、使い始めるのは非常に簡単です。 上記のように、 pdk new <thing>



を使用してクラスまたはタイプが作成された場合、 *_spec.rb



ファイルもすでに存在します。 したがって、 dummy::class



ます。 テストするには、次の内容のspec/classes/class_spec.rb



ファイルを作成する必要があります。 







 require 'spec_helper' describe 'dummy::class' do on_supported_os.each do |os, os_facts| context "on #{os}" do let(:facts) { os_facts } it { is_expected.to compile } end end end


モジュールのルートディレクトリからpdk test unit



を実行して確認できます。







それが私たちが必要とするほとんどすべてです。 これで、適切な条件で必要なis_expected



でclass_spec.rb



を補うことができます。 たとえば、クラスに特定のパラメーターを持つfile {'/file/path': }



リソースが含まれていることを確認するには、次のようにします。 







 it do is_expected.to contain_file('/file/path').with( 'ensure' => 'file', 'mode' => '0644' ) end


let(:params) { {'param1' => 'value'} }



を使用してクラスパラメーターを設定できます。 context 'some description' {}



の選択したセクション内に各パラメーターを配置するit



で、さまざまな入力条件でテストを実行できます。 リソース間の依存関係とクラス間の依存関係の両方をチェックできます。たとえば、クラス宣言にinherits



が含まれていると想定される場合、 is_expected.to contain_class('parent_class_name')



チェックを追加できます。 異なるOSで動作を確認する必要がありますか？ 可能性もあります。必要な事実を別のコンテキストで単に示します。 







 context 'with Debian' do let(:facts) do { os: { architecture: 'amd64', distro: { codename: 'stretch', id: 'Debian', release: { full: '9.6', major: '9', minor: '6', }, }, family: 'Debian', name: 'Debian', release: { full: '9.6', major: '9', minor: '6', }, selinux: { enabled: false, }, }, osfamily: 'Debian', } end it { is_expected.to something } end


一般に、テストを作成する過程でなんとか気付く限り、このフレームワークを使用すると、必要なほぼすべてのものをチェックできます。 また、テストの存在は、いくつかのパラメーターが子クラスからモジュールのトップクラスに移動したときに役立ちました。リファクタリングは何も破壊せず、モジュール全体の動作は変わらないことを示しました。







出力の代わりに



記事の一般的なイントネーションから既に理解できたように、PDKのおかげでPuppetがモジュールとマニフェストを簡単に操作できるようになったことに大いに勇気づけられます。 定期的なアクションは自動化され、テンプレートは可能な限り使用され、一般的なCIの構成はボックスから利用できます。 それは一種のオーバーヘッドのように思えるかもしれません、そして、使用は期待された果物をもたらさないかもしれませんが、それは間違いなく価値があります。 PDKを使用しない場合と使用する場合のモジュールの開発方法を比較すると、私にとっては次のようになります。







なしの開発 あごひげ PDK PDK開発


自分自身や同僚の生活を楽にしてください。 潜在的な質問に喜んでお答えします。







霧化が私たちと共にありますように！







More articles:


All Articles