目次
※この記事は次のブログを翻訳したものになります。
原文：exciting logstash plugin ecosystem changes
Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストール、管理、公開の方法を変更しています。 ユーザやコミュニティからフィードバックをもらいました。 その目的は、プラグインの利用や開発をより簡単にすることです。 このプロジェクトは始まったばかりです。プラグインのコミュニティを探し、 共有するためのワンストップソリューションを提供するこのアイデアを改善していく予定です。 このブログで、この決定を行った理由を説明し、新しいワークフローをと今後のロードマップを説明します。
プラグインがあります！
Logstashは、プラグイン（input、filter、output、codec）が豊富にあります。 これらは、Elasticsearchにより開発されたものと、コミュニティからコントリビュートされたものです。 Logstashの主な特長の1つは、これらのプラグインの有効性と動作を拡張するプラグインを追加するのが簡単なことです。 現在、165以上のプラグインがエコシステムにあり、これらは、2つのプロジェクトに分かれています。
logstash-coreは最もよく使われるプラグインで、Logstashにデフォルトで含まれますlogstash-contribはコミュニティにより開発されたプラグインを含み、別途ダウンロードできます
新プラグインエコシステムの変更
1.5.0では、全てのプラグインは、Logstashコアから分離され、rubygemsを使って個別にパッケージングされます。
rubygemsを選択したのは、依存関係のあるライブラリの配布とパッケージングがパワフルで一般的なものだからです。
さらに、rubygems.orgプラットフォームは配布や探索に影響があります。
また、Logstashにプラグインをインストール、アップデート、削除するのが簡単な基盤も追加しました。
contribプロジェクトは徐々に終了します。全てのプラグインは個別のプロジェクトになります。
プラグインエコシステム変更の理由
多数のプラグインをもっていると、配布と公開に関して難題が出てきます。 私たちが変更するに至った理由は次のようなものです。
- 現在は、プラグインの更新に伴い、Logstashの新バージョンのリリースが必要
- 開発者は、Logstashのリリース間隔とは別に、新バージョンをリリースをしたい
- プラグイン開発者は、外部依存を記述できるようにしたい
- Logstashコアの配布パッケージのダウンロードサイズを小さくし、ユーザは必要なプラグインのみインストール
logstash-contribを1つのリポジトリとして管理するのは難しい
詳細：
ソースコードの場所
Logstashのソースコードは、今後も現在のGitHubのリポジトリのままです。 しかし、プラグインに関するコードやテストコードは含まなくなります。 この分離により、個別のプラグインの改善と同様にコアの改善に集中できます。 これにより、Logstashプロジェクトの全体の品質も向上します。
全プラグインのソースコードは、新しいGitHub organization、logstash-pluginsにて管理します。 各プラグインは個別のリポジトリとして、ここに配置されます。 一見すると、これはメンテナンスが難しくなるように思えます。しかし、テスト、Issue、依存関係を明確にすることができます。 私たちの目的は、テスト、ドキュメント、gemの公開の自動化であり、これを簡単にするためのツールを追加します。
しかし、プラグインの開発者はプラグインのソースコードソースコードをlogstash-pluginsに置く必要はありません。 ー コミュニティで利用可能にするために、rubygems.orgでそれを公開するだけで良いです。
ワークフロー
ここで、新プラグインエコシステムのやりとり/ワークフローについて、いくつかの観点から説明します。
logstashユーザ:
ユーザは、これまでのリリース同様にLogstashのバイナリをダウンロードします。 Logstash 1.5.0は、1.4.2でパッケージされていたプラグインと同等のものが含まれています。 新しいシステムに簡単に移行できるようにです。 そして、ユーザは、最初のデプロイの後に、Logstashプラグインのをインストール、アップグレードできるようになります。
$LS_HOME/bin/pluginスクリプトがプラグイン操作に関連するコマンドになります。
プラグインのインストール
プラグインのほとんどはgemとしてrubygems.orgにアップロードされます。 例えば、もしユーザがApache Kafka outputプラグインをインストールする場合、次のコマンドを実行します。
bin/plugin install logstash-output-kafka
または、ファイルをダウンロード済みの場合は次のコマンドとなります。
bin/plugin install /path/to/logstash-output-kafka-1.0.0.gem
プラグインの削除
bin/plugin uninstall logstash-output-kafka
1つまた全プラグインのアップデート
bin/plugin update
bin/plugin update logstash-output-kafka
プラグインのリストアップ
bin/plugin list
bin/plugin list elasticsearch ( List all plugins containing a name )
bin/plugin list --group output ( list all outputs )
ドキュメント
プラグインが個別に管理されても、全プラグインのドキュメントは1カ所です。
logstash plugin開発者:
プラグイン開発者と作者は、Logstashエコシステムのためにプラグインを公開することができます。 プラグインは、gemやJavaライブラリの依存関係を宣言できます。 より重要なのは、Logstashのリリース間隔に関係なく、プラグインの改善版をリリースできます。
Rubygemsテクノロジはパッケージングシステム、依存関係管理、ホスティングのために選択されてきました。 Rubyのgemを公開することに慣れている開発者は、Logstashプラグインを簡単に公開することができます。 Elasticsearchはこれらの機能に関して開発者を支援するために、ツールを提供、メンテナンスします。
開発およびローカルでのテスト
JRuby 1.7.16がプラグインを開発するための唯一の前提条件です。
プラグインにパッチを提供するのは以前と同様です。
例えば、logstash-output-kafkaにパッチを送るのは次のようになります。
git clone https://github.com/logstash-plugins/logstash-output-kafka.git- 変更
- プラグインをローカルでテスト
bundle installbundle exec rspec- Logstashの他のバージョンもしくはローカルでテストする場合、Gemfileを編集し、 次のように別のロケーションを加えます。
gem "logstash", :github => "elasticsearch/logstash", :ref => "master"
- 新しいPull Requestを
logstash-output-kafkaに対して作成 - コミュニティでコードレビューを受け、Elasticsearchがパッチを受け入れ
バージョン
バージョン情報は、それぞれのプラグインの.gemspecで管理します。
例えば、Apache Kafka outputのgemspecはこちらです。
バージョニングはsemantic versioningのルールに従い、
Logstashのバージョニングとは別に、プラグインの開発者によって管理されます。
Logstash 1.5.0がリリースされると、マイルストーン1のプラグインはバージョン1.0.0となり、マイルストーン2のプラグインはバージョン2.0.0となるでしょう。
公開
開発者が変更を加えプラグインを公開したいと思った時、.gemspecのバージョン番号を変更します。
全テストが成功した時、Elasticsearchはrubygems.orgにプラグインを手動で公開します。
もし、テストが失敗した場合、プラグインは公開されません。
長期的には、プラグインの公開の自動化を行いたいと思っています。
この変更は新しいため、公開の自動化を提供する前に、自動化についてより理解し、プラグインのテスト基盤を改良したいと思っています。
Issue
Issueは、各プラグインのGitHubリポジトリに対してオープンなければなりません。 Logstashコアのリポジトリは、コアのパイプラインや共通的な機能に関連するIssueについて扱います。
ドキュメント
プラグインのドキュメントはソースコード自体から生成されます。 それぞれのプラグインのドキュメントは、そのプラグインのリポジトリに含まれます。 Elasticsearchは elasticsearch.org/guideに全てのプラグインのドキュメントを集め生成できる基盤を提供します。
移行
全ての新しいpull requestとissueはlogstash-plugin organisation配下にある各プラグインのリポジトリに対してオープンする必要があります。
すでにあるPRはどうすれば良いですか？
気にしないでください。すでにあるpull requestは開発者によって移行する必要はありません。 LogstashチームがLogstashコアリポジトリに対してのPRを、個別の関連するプラグインのリポジトリに対してマージします。
git clone … # clone the specific plugin repo
# now apply the patch
curl -s https://github.com/elasticsearch/logstash/pull/XXXX | git am --3way
git push
Note:このプロセスはすでにあるPRに対してgit historyを管理します
GitHub Issue
現在、LogstashリポジトリにオープンされているIssueは、それぞれのプラグインのリポジトリに移行します。 Logstashチームがgithub.com APIを利用してこの処理を自動的に行います。 安心してください。私たちが個別のプラグインに対する既存のIssueを移行します。
今後のロードマップ
これは、最初のステップであり、これらの変更は、ユーザや開発者に対してエコシステムをよりよくするために、 しっかりとした基盤を提供します。
短期的には、開発者のためにpull requestのフィードバックでテスト自動化を提供する基盤を追加していきます。 プラグインリポジトリのブートストラップや管理のためのツールも提供していきます。
長期的には、すべてのLogstashプラグインを探し、公開するためのコミュニティポータルを提供したいと思っています。 このアイデアは、Puppet ForgeやAWS marketplaceのようなものです。
Logstash 1.5.0 Beta 1をリリースし、これは新しいエコシステムを提供します。 ぜひ、試していただき、これらの変更に関して感じたことを教えてください。 あなたのフィードバック(TwitterもしくはGitHub)はとても貴重です！
comments powered by Disqus
See Also by Hugo
- Logstash 2.0.0リリース（日本語訳）
- Logstash 1.5.0 Beta1リリース(日本語訳)
- Release, we have（日本語訳）
- Analyze UIとKibanaのプラグインの作成方法（第2回）
- Logstashを使ったElasticsearchの再インデックス（日本語訳）