Kibana: プラグインのインストールにhttp / httpsプロキシを許可する

@ seang-es HTTP Connectトンネリングを使用するソリューションを実装できますか？

@ seang-esと話し合った後、安全なネットワークの背後にいるユーザーは独自のhttpプロキシサーバーを持っており、これらのプロキシを介してKibanaを誘導する機能を望んでいるようです。

ユーザーは、kibana.ymlのオプションを変更して、 hostとportをプロキシサーバーに設定したいと考えています。

プロキシ設定も認証する必要があります。
実装が完了するのを楽しみにしています。

ええ、あなたはここでCONNECTを望んでいません、ただの古いhttpプロキシです

@ seang-esこれはElasticsearchのbin/pluginのような他のプラグインインストーラーとどのように連携しますか？ インストーラーが認証済みプロキシをセットアップするためのCLIオプションが表示されませんか？ また、これを考えた後、これはOSレベルで処理されるべきではありませんか？

@spalgerと@rashidkpcと話し合った後、ここでCONNECTを使用したくない理由は、多くの企業がCONNECTをサポートしていないためです。 提案されたオプションは次のとおりです。

1. これがユーザーによって本当に必要かどうか、またはユーザーが同じことを達成できるようにする他の回避策があるかどうかを確認してください。 @ seang-es、@ simianhackerのコメントに返信して、Elasticsearchプラグインでお客様がこれをどのように回避するかをよりよく理解できるようにしてください。
2. wreckはプロキシをサポートしていないため、 installedPluginsモジュールをwreck.jsの代わりにノードrequest $モジュールを使用するように書き直します。
3. wreck.jsを拡張するhttpプロキシプラグインを作成します。

3つのうち、これが非常に必要な機能である場合、私はオプション2の実装に最も慣れています。

さらに議論した結果、Kibanaでのプラグインインストールにhttp / httpsプロキシを追加しないことにしました。 これの主な理由は、Elasticsearchもそれをサポートしておらず、ファイルインストーラーを使用してオフラインインストールを実行するための回避策があるためです。

例えば：

bin/kibana plugin --install --url file:///home/username/plugin.tar.gz

_注_：絶対パスを使用する必要があります

そこで、 P1ラベルを削除して、この問題を解決します。

ローカルディレクトリからのファイルインストールを含めるようにKibanaプラグインのドキュメントを更新するために、問題＃5998を提出しました。

これを直接サポートしない理由の1つは無効です。これは、elasticsearchのプラグインコマンドが、対応するJavaシステムプロパティを介してではあるが、プロキシの指定をサポートしているためです。
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/modules-plugins.html

bin/plugin -DproxyHost=host_name -DproxyPort=port_number --install mobz/elasticsearch-head

@avallenファイルをダウンロードしてから手動でインストールすることはできますか？

このいわゆる回避策は機能していないようです

$bin/kibana plugin --install --url file:///opt/kibana-4.4.1-linux-x64/marvel-latest.tar.gz
Invalid install option. Please use the format <org>/<plugin>/<version>.

さらに、プロキシやオフラインプラグインのインストールを許可しないと、基本的に組織の90％がこのバージョンを使用できなくなります...

オフラインインストールの正しい方法は次のとおりです。

bin/kibana plugin -i marvel -u file:///tmp/marvel-latest.tar.gz

@stormpython PIラベルを削除する必要がありますが、開いたままにしないでください。

これにより、HTTPプロキシの背後で正しく機能するDockerfileが破損します。

@ stormpython-いくつかの理由でばかげた説明：

• Elasticsearchは発信プロキシをサポートします（プラグインをインストールする唯一の方法であるため、私は知っています）。
• 合理的な管理者は、データセンター（サーバー）からの無制限の送信トラフィックを許可しないため、プラグインのインストールは送信プロキシを経由することを期待する必要があります。 基本的に、Kibanaが発信プロキシを介してプラグインをインストールできない場合、プラグインをまったくインストールできないことになります。
• あなたが提案した回避策は、管理と構成管理を非常に複雑にします（つまり、Puppet、Chef）。 そして、混乱を招きます。たとえば、センスプラグインのインストールの問題（問題7400を参照）がファイルからのインストール（回避策）が原因であるかどうかはわかりません。

Guyzは、話し合ったかどうか、決定したかどうかにかかわらず、これをもう一度再検討する必要があります。 正しい決定（賢い決定）は1つだけであり、あなたはそれを見逃しています。

インストールのためのプロジェクト間の一貫性が重要であるため、Elasticsearchでのプロキシサポートについて検討します。

puppetを使用し、企業ファイアウォールの背後で、 elasticsearchおよびlogstash （ただしkibanaはない）のプラグインをインストールできます。

（1） execインスタンスに環境変数を設定する

exec {
    "$name":
        command     => $command,
        creates     => $creates,
        environment => [ "http_proxy=http://1.2.3.4:3128" ],
        logoutput   => $logoutput,
        onlyif      => $onlyif,
        path        => ["/bin", "/sbin", "/usr/bin", "/usr/sbin"],
        returns     => [0,74],
    ;
}

またはによって

（2）プロキシパラメータをJavaに渡します。

"${bin_plugin} -DproxyHost=1.2.3.4 -DproxyPort=3128 install -b --verbose $name"

プラグインインストールのプロキシサポートを追加するための試行＃7967は次のとおりです

これは＃12753で修正され、6.1でリリースされる予定です。 プラグインコマンドは、 http_proxy 、 https_proxy 、およびno_proxy環境変数を理解します。

素晴らしいニュース@timroes ！
どうもありがとうございました！