Kibana: Разрешить прокси http/https для установки плагина

@seang-es, сможем ли мы реализовать решение, использующее туннелирование HTTP Connect ?

После обсуждения с @seang-es может показаться, что пользователи защищенных сетей имеют свои собственные прокси-серверы http и просто хотели бы иметь возможность направлять Kibana через эти прокси.

Пользователи хотели бы изменить параметр в kibana.yml, чтобы установить host и port на прокси-сервер.

Мне также нужна настройка аутентификации прокси.
Я с нетерпением жду вашей реализации, которая будет сделана.

Да, вам не нужен CONNECT здесь, просто старые http-прокси.

@seang-es Как это работает с другими установщиками плагинов, такими как bin/plugin в Elasticsearch? Я не вижу вариантов CLI для их установщиков для настройки прокси-сервера с проверкой подлинности? Также, подумав об этом, не следует ли об этом позаботиться на уровне ОС?

После обсуждения с @spalger и @rashidkpc причина, по которой мы не хотим использовать здесь CONNECT, заключается в том, что многие компании не поддерживают его. Итак, предлагаемые варианты:

1. Посмотрите, действительно ли это необходимо нашим пользователям или есть другие обходные пути, которые позволят пользователям выполнить то же самое. @seang-es, не могли бы вы ответить на комментарии @simianhacker , чтобы мы лучше поняли, как клиент обходит это для плагинов Elasticsearch.
2. Перепишите модуль installedPlugins , чтобы использовать модуль узла request вместо wreck.js , поскольку крушение не поддерживает проксирование.
3. Напишите подключаемый модуль http-прокси, который расширяет wreck.js .

Из трех, если это очень нужная функция, мне удобнее реализовать вариант 2.

После дальнейшего обсуждения мы решили не добавлять проксирование http/https для установки плагинов в Kibana. Основная причина этого заключается в том, что Elasticsearch также не поддерживает его, и существует обходной путь для автономной установки с помощью установщика файлов.

Например:

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

_Примечание_: вы должны использовать абсолютные пути

Итак, я удаляю ярлык P1 и закрываю эту проблему.

Я отправил вопрос № 5998, чтобы обновить документацию плагина Kibana, чтобы включить установку файлов из локального каталога.

Одна из причин, приведенных выше для того, чтобы не поддерживать это напрямую, недействительна, потому что команда плагина elasticsearch _does_ поддерживает указание прокси, хотя и через соответствующие свойства системы 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 следует удалить, но нельзя ли оставить его открытым?

Это ломает файлы Dockerfile, которые в противном случае работают корректно за прокси-сервером HTTP.

@stormpython — нелепое объяснение по нескольким причинам:

• Elasticsearch ДЕЙСТВИТЕЛЬНО поддерживает исходящий прокси (я знаю, потому что это единственный способ установить плагины для меня);
• Ни один разумный администратор не разрешит неограниченный исходящий трафик из своего центра обработки данных (серверов), поэтому следует ожидать, что установка плагина будет проходить через исходящий прокси. По сути, если Kibana не может устанавливать плагины через исходящий прокси-сервер, это практически невозможно установить их вообще.
• Предложенный вами обходной путь значительно усложняет администрирование и управление конфигурацией (например, Puppet, Chef). И вносит путаницу: например, я не уверен, вызваны ли мои проблемы с установкой плагина sense (см. проблему 7400 ) установкой из файла (ваш обходной путь) или нет.

Гайз, обсудили или нет, решили или нет, вы должны это еще раз пересмотреть. Только одно решение является правильным (умным), и вы его упустили.

Согласованность между проектами для установки важна, поэтому мы рассмотрим поддержку прокси-сервера в 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 !
Большое Спасибо за это!