はじめに

Ansibleモジュールとsparrowプラグインは、構成管理と展開の自動化の分野で最も単純なタスクを解決するための構成要素です。 Ansibleモジュールは高レベルのスクリプト（YAMLで記述されたプレイブック）で使用され、sparrowプラグインは同様にPerl6で記述されたsparrowdoスクリプトに埋め込まれます。

この記事は、著者の英語からのオリジナルの無料翻訳です。

開発言語のサポート

ansible-モジュールを作成するためのほぼすべての開発言語を選択できます。
デフォルトでは、ansibleはPythonの高度なAPI（ショートカットと呼ばれる）を提供します。 他の言語でモジュールを開発する場合、補助ライブラリ（各言語のネイティブ）を使用して、開発プロセスを簡素化し、ansibleに統合する必要があります。

sparrow -3つの（*）言語のいずれか（Perl5、Bash、またはRuby）から選択できます。 プラグイン開発者向けに、sparrowは、ansibleと同様に、統合されたAPI（3つの言語のいずれかで利用可能）を提供します。これにより、プラグインの開発と雀システムへの統合プロセスが簡素化されます。 このAPIは基本的な機能のみを提供し、Pythonのansible APIほど高度ではありません。

（*）近い将来、Pythonのサポートを追加する計画。

設計

ansible -ansibleモジュール-基本的な問題を解決するための（スクリプト）の場合、スタンドアロンプ​​ログラムブロック。 Ansibleモジュールは、他のAnsibleモジュールに依存したり、呼び出したりすることはできません。

sparrow -sparrowプラグインはansibleモジュールに似ています-基本的な問題を解決するためのスタンドアロンの閉じたコードブロックです。 ただし、スズメは、このレベルの開発で追加の自由度を提供します。 Sparrowプラグインは、一連のスクリプトです。 一部のスクリプトは他のスクリプトを呼び出して、パラメーターを渡します。 このような設計により、タスクを相互に作用するスクリプトに分割できます。 例として、単純なケース-ソフトウェアパッケージのインストールと削除を検討します。 このタスクは1つのコードブロック（スクリプト）として見ることができますが、実装時にはすべてを2つのスクリプトに分割します。1つはパッケージのインストール用、もう1つはアンインストール用です。 3番目のスクリプトを入力することもできます。これは、入力パラメーターを解析し、呼び出しスケジューリング（*）を実行します。 このアプローチについては、記事「 Sparrowプラグインの進化」で詳しく説明しています 。

（*）実際、 package-genericプラグインはこの方法で実装されます。

これがすべての簡単な説明です。

構成管理ツールへの統合

ansible -ansibleモジュールは高レベルの構成スクリプトの一部です-ansible プレイブック 。 ansibleプレイブック-YAMLで記述されたスクリプトで、特定のパラメーターを持つansibleモジュールの呼び出しを宣言します。 このようなansibleの構造は問題と呼ばれます。

sparrow -ansibleモジュールのように、sparrowプラグインは不可欠な部分です
より一般的なシステムは、 Perl6で書かれたsparrowdoスクリプトです。 ansibleのように-sparrowdo-構成管理システムですが、sparrowプラグイン上に構築されています。 Sparrowプラグインは、sparowdoスクリプト内のパラメーターで呼び出されます。

エンドユーザーインターフェース

ansible-既に述べたように、渡されたパラメーターでモジュールの起動を宣言するYAML DSLコードを使用して、ansibleモジュールが呼び出されます。 これは、プレイブックで発生します。 コマンドライン引数として渡されたパラメーターを使用して、コンソールスクリプトでモジュールを起動することができます。

以下は、yumパッケージマネージャー（同じ名前のansibleモジュール）を使用してhttpd Webサーバーをインストールするためのansibleプレイブックコードの例です。

$ cat playbook.yml --- - hosts: webservers tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest 

sparrow -sparrowdoプラグイン内でPerl6 APIを使用してsparrowプラグインが呼び出されます。 プラグインパラメーターはPerl6ハッシュとして渡されます。 コンソールクライアントを使用して、プラグインを「そのまま」実行し、sparrowdoをバイパスすることもできます（ansibleモジュールを実行できるのと同様の方法で）。 これは、プラグインを開発およびデバッグするときに役立ちます。 この起動モードでは、コマンドライン、JSON / YAML、および構成::入力形式を渡すための多くの追加オプションがあります：一般形式

以下は、httpd Webサーバーをインストールするための以前のansibleプレイブックに相当します。 sparrowdoスクリプトには2つのコードバリアント（core-dslおよびプラグインAPI）があります。

 $ cat sparrowfile # core-dsl API  ,     #  ""    #         package-install 'httpd'; # ,       core-dsl #      , #  plugin API #     : task-run 'ensure apache is at the latest version', 'package-generic', %( list => 'httpd' ); 

入力パラメーターの送信と処理

ansible-モジュールの入力パラメーターはkey = value （*）ペアの形式で送信されます。一般に、モジュールを開発するときは、モジュールコードでさらに使用するために、パラメーターを解析してデータを「強調」し、対応する変数に割り当てる必要があります。 さまざまな開発言語について、この問題を解決する多数の「ヘルパー」がいます。

（*）ネストされたデータ構造を転送することは可能です。

また、すでに述べたように、ansibleはansibleドキュメントでショートカットと呼ばれる高レベルのPython APIを提供します。 このAPIを使用すると、入力パラメーターを自動的に解析し、アクセサーを生成し、入力パラメーターのタイプを判別してそれらを確認し、デフォルト値などを判別できます。

以下は、Python ansible APIを使用して入力パラメーターの解析を実装するanibleモジュールです。

 $ cat library/greetings.py from ansible.module_utils.basic import * def main(): fields = { "message": {"default": "Hi!", "type": "str" } } module = ansibleModule(argument_spec=fields) module.params['message'] # some other code here to return results if __name__ == '__main__': main() 

sparrow -sparrowは、プラグインの入力パラメーターを処理するための統合API（すべての開発言語で使用可能）を実装しているため、データを手動で解析する必要はありません。

したがって、プラグインを開発している言語に関係なく、
実際に1行のサポートコードを記述することなく、入力にアクセスするための標準API。

後者が明示的に設定されない場合、パラメータのデフォルト値を決定することもできます。

ansible Python APIの場合のように、組み込みの入力とパラメーターのチェックはありません。

以下は、入力パラメーターを解析するansibleコードに相当するものです。 プラグイン実装の言語としてBash（*）が選択されています

（*）最も高度な開発言語とはかけ離れたところでさえ、入力パラメーターの処理に「入る」ことなく、すずめプラグインを簡単に作成できることを示します。

 #    $ cat story.bash message=$(config message) #    : $ cat story.ini message = Hi! 

次に、同じBashを使用してネストされた入力パラメーターを解析する方法を示します。

 #    sparrowdo  $ cat sparrowfile task-run "run my task", 'foo-plugin', %( foo => { bar => { baz => 'BAZ' } } ); #    Bash #    : $ cat story.bash baz=$(config foo.bar.baz) 

戻り値

ansible -ansibleモジュールは常にJSON文字列として結果を返します。 さらに、JSON自体には特別な構造が必要です。 これについては、ansibleモジュール開発のドキュメントページで詳しく読むことができます。

しかし、ここでは、ansibleモジュールから値を返すプロセスについて注意したいことを示します。

• ansibleモジュールの完了コード（無音を実装するスクリプト）は無視されます

  
  

• モジュールから戻るための唯一の要件は、STDOUTにJSON文字列が存在することです。 応答のJSON構造も特定の要件を満たしている必要があります。

  
  

• したがって、モジュールからの応答で有効な JSONを取得できない場合 、これはエラーと見なされます

  
  

• モジュールによって生成されたSTDOUT / STDERRは、プレイブックの出力に表示されません（*）
  （*）-特定の条件下で、または追加のコードを記述することで、この結論を得ることができますが、ここではデフォルトの動作について説明しています

  
  
• モジュールが値を返すためには、構造のJSONフィールドとして表され、STDOUTに返される必要があります

現在の時刻を返すcurrenttimeモジュールの例を示します。

 $ cat library/currentime.py import datetime import json date = str(datetime.datetime.now()) print json.dumps({ "time" : date }) 

sparrow -ansibleモジュールとは異なり、sparrowプラグインは何でも返すことができます; sparrowはプラグインによって返されるデータを規制しません。 （ただし、次のセクション「出力処理」を参照してください）。

ここでは、スズメの視点からの出力について知ることが重要です。

• プラグイン完了コード（結果、スズメの場合は1つのスクリプトではなく複数のスクリプトを処理できるため）、それは重要です。 ゼロ以外の場合、これはプラグインランタイムエラーとして扱われます。

  
  
• プラグインによって生成されたSTDOUTは単に渡され、結果の出力に表示されます。 ansibleの場合のように、結果の「再パッケージ化」やフィルタリングは行われません。 コンソールから同様のスクリプトを実行したかのように、常に出力がそのまま表示されます。

次に、以前のansibleモジュールに相当するものを指定して、現在の時刻を表示します。 今回は、プラグインを作成するときにPerl5を使用します。これは、すべてのプラグインコードが些細なものであると判明したためです。

 #   $ cat story.pl print scalar localtime; 

出力処理

ansible -ansibleモジュールは常にJSONを返す必要があるため、構造化されたデータ出力を使用して変数に変換し、実際にansibleプレイブックで「より高い」場所で処理するのは非常に簡単です。 これはかなり強力な機能ですが、構成管理システムでのその価値は個人的には議論の余地があります。 実際には、ターゲットサーバーでタスクのリストを実行する時点（*）までに、すべてが確実に静的で決定的なリストの形になっている必要があります。このような既に生成されたリストに分岐とダイナミクスを追加しようとしても、複雑化するだけでなく、収束の一般的な問題の解決策は特定のビューへのサーバー。

（*）ここで、このようなタスクリストまたはリソースの動的な生成に反対するわけではないことを理解することが重要です。ここでは、シェフやスズメの場合のように、命令型アプローチが非常に適切です。 しかし、おそらく、モジュールによって返されたデータがどのようにプレイブックでさらに使用されるかを推論するのに十分なほど理解できるとは思いません。

次に、渡された入力パラメーターを単純に返す単純なモジュールの例を示します。このパラメーターは、プレイブックに「登録」され、コンソールに表示されます。

 $ cat playbook.yml - hosts: localhost tasks: - name: tell me what I say echo: message: "hi there!" register: result - debug: var=result $ cat library/echo.py from ansible.module_utils.basic import * def main(): module = ansibleModule(argument_spec={}) response = {"you_said": module.params['message']} module.exit_json(changed=True, meta=response) if __name__ == '__main__': main() 

スズメ -すでに述べたように、スズメはプラグインがSTDOUTで言っていることを「気にしません」。このデータをさらに使用する方法はありません。 実際、これは完全に真実ではありません。

このデータはこれ以上処理されないという観点から-これは事実ですが、スクリプトの出力を検証できる検証ルールを決定する機会があります。 この種の組み込みテストは、雀プラグインの特徴的な機能です。 検証ルールはOutthentic :: DSL言語構成の形式で記述され、さまざまなテキストチェックを実行できます-異なる正規表現とのテキストマッチング、表現に対応する個々のテキストの処理（いわゆるキャプチャ）など。 これについては、Outthenic :: DSLのドキュメントページで読むことができます。

検証が失敗した場合、（ゼロ以外の終了コードとともに）プラグイン実行エラーとして扱われます。

したがって、この種の「自己テスト」スクリプトを作成すると、構成管理の分野のタスクだけでなく、テスト、監視、監査用のプラグインを作成できます。

上記のすべてのおかげで、以前のansibleモジュールとの類似性を構築することは困難ですが、
スズメでできる「おおまかに似た」ものがあります。 パラメーターをプラグインに渡し、それをSTDOUTに出力し、テストルールを記述して、出力が入力とまったく同じであることを確認します。

 #     sparrowdo $ cat sparrowfile run-task "tell me what I say", "echo", %( message => 'hi there!' ) #      $ cat story.bash echo you said $(config message) 

$ cat story.check
ジェネレータ：config（）-> {message}

インストールプロセス

ansible-多数のansibleがansibleの一部として提供されており、すぐに使用できます。特別な方法でインストールする必要はありません。 また、ユーザーはいわゆるカスタムモジュールを記述し、原則として、それらをバージョン管理システム-Git / Svn（たとえば、githubまたはgitlab）に保存します。 次に、通常のファイル形式のモジュールがマスターサーバー（ターゲットサーバーでansible sshタスクを実行するモジュール）でチェックアウトされます。この場合も、メッセージはバージョン管理システムからの通常のチェックアウトに縮小されます。

したがって、モジュールのエコシステムには2つの大きなサブシステムが含まれます。

• Ansibleメインリポジトリ（ メインansibleリポジトリ ）-ansibleで提供されるモジュール

  
  
• カスタムモジュール

まとめると、ansibleはプッシュベースのデプロイメントスキームを実装しており、ターゲットサーバーにエージェントが存在しない（エージェントレス）と言えます。 ファイルの形式のモジュールは、単にターゲットサーバーにコピーされ、スクリプトの形式で既に起動されています。

以下は、ユーザーモジュールの展開プロセスのグラフィカルな図です。

スズメ -スズメでは、展開プロセスがわずかに異なります。 一般に、同じプッシュベースのスキームが採用されています。 ただし、スズメの場合は、プラグインのインストールに関与するエージェント（またはクライアント）がいます。

したがって、sparrowプラグインは、deb、rpm、CPAN、RubyGemsなどのソフトウェアパッケージ用の古典的な配布システムのように配布されるパッケージ化されたスクリプトに他なりません。

sparrowはプラグインデータインストールマネージャーを提供し、同じマネージャーを使用してプラグインを実行します。 すべてが機能するには、マネージャーをターゲットサーバーにプリインストールする必要があります。

sparrowdoは、中央（マスター）サーバーにあるスクリプトをメタデータにコンパイルします。メタデータはscpを介してJSONファイルの形式でターゲットマシンにコピーされ、マネージャーと同じターゲットマシンにダウンロードし、コピーしたデータを使用して設定をインストールし、最後にsparrowプラグインを起動します。結果は、（ansibleの場合のように）中央サーバーへの応答の形式で返されます。

したがって、ansibleとは異なり、プラグインをインストールすることは単にファイルをターゲットサーバーにコピーするだけではなく、 スズメの場合、コピーされるのはプラグイン自体ではなく、そのメタ情報であり、実際の展開プロセスはメタ情報に従って行われます。

sparrowプラグインは、中央のsparrowプラグインリポジトリsparrowHubでホストされます。 プラグインには、作成者、バージョン、説明、ドキュメントがあります。

ソフトウェアパッケージをインストールするための上記のパッケージジェネリックプラグインのメタファイルは次のようになります。

 { "name" : "package-generic", "version" : "0.2.16", "description": "Generic package manager. Installs packages using OS specific package managers (yum,apt-get)", "url" : "https://github.com/melezhik/package-generic" } 

すずめでは、カスタムプラグインと「コア」プラグインの間に明確な分離はありません。 sparrowHubにロードされたプラグインは、システムのユーザーがすぐに利用できるようになるため、sparrowdoスクリプトで使用できます。

必要に応じて、ユーザーはリモートgitリポジトリにプラグインを配置できます。このようなプラグインはプライベート（プライベート）と呼ばれ、sparrowHubのプラグイン（いわゆるパブリックプラグイン）とともにこれらのプラグインを構成スクリプトで簡単に使用できます

以下は、スズメのプラグイン展開図です。

依存関係

ansible -ansibleでは、モジュールレベルでソフトウェアの依存関係を管理する方法はありません。 最も可能性が高い（私はansibleをよく知っている、私は推測する）これはより高いレベルで起こる-プレイブックで。 したがって、モジュールがライブラリに依存している場合は、たとえば、プレイブックの別の場所で依存関係のインストールを呼び出すなどして、依存関係を解決する必要があります。

sparrow -sparrowは、sparrowプラグインレベルでフルタイムの依存関係管理（*）機能を提供します。 したがって、プラグインがライブラリに依存している場合は、プラグインで依存関係データを直接記述することができ、プラグインマネージャーがそれらを処理します
プラグインのインストール中。 これまでのところ、依存関係管理は、 cpanfileファイルを介したPerl5のCPANモジュールと、 Gemfileファイルを介したRubyのRubyGemsモジュールに制限されています。

（*）-依存関係は制限されていますが、Perl5のCPANおよびRubyのRubyGems

おわりに

ansibleは、特に多数の既製のモジュールがあるため、非常に人気があります。 しかし、私の個人的な意見では、新しいモジュールを開発するプロセスには欠点があり、アーキテクチャ自体はいくつかのタスクに適したソリューションではありません。 個々のスズメの特徴は、ansibleに比べてより魅力的で興味深いと思います。 もちろん、これは私見です:)、私はいくつかのポイントをリストします：

• プレイブックと sparrowdoスクリプト-sparrowdoは、強力で最新のPerl6言語を使用した必須の構成プログラミングオプションを提供します
  ansibleでは、純粋に宣言的なYAMLの機能によって制限されます。

  
  
• スクリプト指向の設計-スクリプト指向のスキームのおかげで、スズメはタスクを個別の断片と各断片の個別のスクリプトに分割することを奨励し、スクリプト自体は互いに渡されたパラメーターを使用して有機的に相互作用します（いわゆるスズメ） モジュールストーリー ）ansibleの場合、通常は1つのモジュール= 1つのスクリプトスキームに制限されます。 もちろん、ansibleの場合、同様のスタイル（モジュール内のいくつかのスクリプト）で記述できますが、もちろん、ansibleは設計上、この種のものには適していません。

したがって、実用的な意味では、多くの場合、問題を解決して日常的なスクリプトを作成するときに、問題をいくつかの部分に分割し、相互に作用する一連のスクリプトを用意します。

• ライフサイクルとモジュールおよびプラグインの管理-すずめプラグインは、構成管理ツール自体からさらに分離され、分離されています。 私が言ったように、sparrowdo なしでsparrowプラグインを使用できます。 事実上、これらはこのシステム（sparrowdo）のフレームワーク外で開発、デバッグ、ホスト、管理され、ブラックボックスとして使用されます。 これにより、新しいプラグインを開発し、sparrowdo内で使用するプロセスがさらに柔軟かつシンプルになります。

  
  

• Bash / Shellスクリプト-sparrowは、通常のbash / shellスクリプトを統合するためのansibleサポートよりも優れています。 後者は返されるデータに制限を課し、デフォルトでSTDOUT / STDERRストリームを出力しないため、通常のbashスクリプトをデバッグしたり、 何が問題なのかを理解することが困難になる場合があります。 スズメは実際にすべてのスクリプト出力を透過的にレポートに変換します。 また、開発者が返されたJSONのレベルでエラーを再定義する、ansibleのスクリプト完了コードを無視する上で重要な役割を果たします。 この場合、Sparrowは単にエラーを生成し、unix / linuxコマンドを実行する対流スタイルで動作します。

  
  

• ソフトウェアAPI-すべてのプラグイン開発言語に統一されたインターフェースを提供します。 これは、サポートされている言語のリストにあるほぼすべての言語が、システムが提供する基本的なAPIに関して「同じ権利を持っている」ことを意味します。 ansibleモジュールはほとんどがpythonで書かれていますが、この言語のサポートが最も完全であるという事実のため（ansible modules python API）

  
  
• テスト機能-sparrowは組み込みのテスト機能を提供します。これにより、このツールを、リストされているものに加えて、監査、監視、テストタスクなどに使用できる汎用自動化ツールと見なすことができます。

PSいつものように、読者の意見と彼の建設的な批判を聞くのは興味深いです。 今回は、従来のアンケートを行っていませんが、記事は膨大であることが判明しました。