如何让kibana零等待时间升级插件（前后端分离的部署）

正如官方文档所自豪宣称的那样。Kibana更多的是一个平台，一个可以让插件独立开发，“独立部署”的可扩展性平台，可以让我们自由的发挥自己的想象力和能力，根据自己的需求往上添加原生Kibana所不提供的功能。你可以开发一个新的app，也可以只部署一个后台服务，也可以是一个隐藏的跳转页面，这些，都有赖于plugin的方式，自由的在kibana上install, update和remove。

问题描述

以上。看起来是比较美好的，但硬币的反面是kibana作为一个单页应用，任何都其他功能都是"/"路径下都一个子path，任何插件的安装（除非是一个纯后台的服务，但我没有测试）都需要和主页面、所有已安装都插件产生联系，即每次插件都变动，都需要将所有的页面和js重新bundle一次。这个捆绑不是简单的捆绑，而是经过优化后的打包操作，相当耗时。重点是，按照目前的方式，optimize(bundle)的过程必须是现场的，即必须在正在运行的kibana服务器上进行，因此在以下情况下你可能会遇到麻烦：

• 你的kibana服务作为一个生产服务，不能停
• 你没有给kibana做双活
• 因为只是一个前端，你给kibana分配的硬件资源很少（单核2G，双核4G）
• 你使用的是6.3之后的版本，kibana已经默认安装了xpack。或者你是之前的版本，自己手动安装了xpack

这时，你若是安装或者更新插件（包括remove插件），都可能会因为optimize过程占用大量的cpu和内存资源，而造成kibana停止服务响应。

这里有一个小tips，如果你开发了多个插件，需要同时更新当时候，安装当时候请使用命令kibana-plugin install --no-optimize file:///path_to_your_file，当全部的插件都安装完了之后，再重启kibana，一次性的执行optimize流程，或者通过bin/kibana --optimize命令触发

Kibana架构简述

如果我们的目标是让kibana零等待时间升级插件，找到解决方案的前提是我们能够了解Kibana的软件架构和部署方式。

首先，我们需要知道的是Kibana是一个基于node的web应用，前端后端都主要使用的javascript。web后端使用的hapi作为web服务器应用程序。并且node无需安装，已经包含在了kibana目录下。（node目录）

以下是kibana的目录，所有的插件都安装在plugins目录，而所有打包后的内容都放在optimize目录。

├── LICENSE.txt
├── NOTICE.txt
├── README.txt
├── bin
├── config
├── data
├── node
├── node_modules
├── optimize
├── package.json
├── plugins
├── src
└── webpackShims

plugins目录(这里，我有两个插件)：

.
├── kibana_auth_plugin
│   ├── index.js
│   ├── node_modules
│   ├── package.json
│   ├── public
│   ├── server
│   └── yarn.lock
└── system_portal
    ├── index.js
    ├── node_modules
    ├── package.json
    ├── public
    ├── server
    └── yarn.lock

每个插件都是类似的目录结构。public目录存放的是前端的页面和js，server目录存放的是后端的js。这里最终要的信息是，插件的开发其实也是一种 前后端分离的架构 。插件安装后后端主程序会调用server目录下的文件，而前端public目录下的文件会被压缩后打包到optimize目录，详见如下。

optimize目录：

├── bundles
│   ├── 176bcca991b07a6ec908fc4d36ac5ae0.svg
│   ├── 45c73723862c6fc5eb3d6961db2d71fb.eot
│   ├── 4b5a84aaf1c9485e060c503a0ff8cadb.woff2
│   ├── 69d89e51f62b6a582c311c35c0f778aa.svg
│   ├── 76a4f23c6be74fd309e0d0fd2c27a5de.svg
│   ├── 7c87870ab40d63cfb8870c1f183f9939.ttf
│   ├── apm.bundle.js
│   ├── apm.entry.js
│   ├── apm.style.css
│   ├── kibana-auth-plugin.bundle.js
│   ├── kibana-auth-plugin.entry.js
│   ├── kibana-auth-plugin.style.css
│   ├── canvas.bundle.js
│   ├── canvas.entry.js
│   ├── canvas.style.css
│   ├── cc17a3dbad9fc4557b4d5d47a38fcc56.svg
│   ├── commons.bundle.js
│   ├── commons.style.css
│   ├── dashboardViewer.bundle.js
│   ├── dashboardViewer.entry.js
│   ├── dashboardViewer.style.css
│   ├── dfb02f8f6d0cedc009ee5887cc68f1f3.woff
│   ├── fa0bbd682c66f1187d48f74b33b5bbd0.svg
│   ├── graph.bundle.js
│   ├── graph.entry.js
│   ├── graph.style.css
│   ├── infra.bundle.js
│   ├── infra.entry.js
│   ├── infra.style.css
│   ├── kibana.bundle.js
│   ├── kibana.entry.js
│   ├── kibana.style.css
│   ├── ml.bundle.js
│   ├── ml.entry.js
│   ├── ml.style.css
│   ├── monitoring.bundle.js
│   ├── monitoring.entry.js
│   ├── monitoring.style.css
│   ├── space_selector.bundle.js
│   ├── space_selector.entry.js
│   ├── space_selector.style.css
│   ├── src
│   ├── stateSessionStorageRedirect.bundle.js
│   ├── stateSessionStorageRedirect.entry.js
│   ├── stateSessionStorageRedirect.style.css
│   ├── status_page.bundle.js
│   ├── status_page.entry.js
│   ├── status_page.style.css
│   ├── system_portal.bundle.js
│   ├── system_portal.entry.js
│   ├── system_portal.style.css
│   ├── timelion.bundle.js
│   ├── timelion.entry.js
│   ├── timelion.style.css
│   ├── vendors.bundle.js
│   └── vendors.style.css

前端浏览器在访问"/"目录的时候会最先获取到kibana.*.js相关的文件。我们看一下 kibana.entry.js, 里面是包含了所有插件的信息的，即，每次插件的变动，这些文件也会跟着跟新

/**
 * Kibana entry file
 *
 * This is programmatically created and updated, do not modify
 *
 * context: ä
  "env": "production",
  "kbnVersion": "6.5.0",
  "buildNum": 18730,
  "plugins": Ä
    "apm",
    "apm_oss",
    "beats_management",
    "kibana_auth_plugin",
    "canvas",
    "cloud",
    "console",
    "console_extensions",
    "dashboard_mode",
    "elasticsearch",
    "graph",
    "grokdebugger",
    "index_management",
    "infra",
    "input_control_vis",
    "inspector_views",
    "kbn_doc_views",
    "kbn_vislib_vis_types",
    "kibana",
    "kuery_autocomplete",
    "license_management",
    "logstash",
    "markdown_vis",
    "metric_vis",
    "metrics",
    "ml",
    "monitoring",
    "notifications",
    "region_map",
    "reporting",
    "rollup",
    "searchprofiler",
    "spaces",
    "state_session_storage_redirect",
    "status_page",
    "system_portal",
    "table_vis",
    "tagcloud",
    "tile_map",
    "tilemap",
    "timelion",
    "vega",
    "watcher",
    "xpack_main"
  Å
å
 */

// import global polyfills before everything else
import 'babel-polyfill';
import 'custom-event-polyfill';
import 'whatwg-fetch';
import 'abortcontroller-polyfill';
import 'childnode-remove-polyfill';

import ä i18n å from 'Ékbn/i18n';
import ä CoreSystem å from '__kibanaCore__'

const injectedMetadata = JSON.parse(document.querySelector('kbn-injected-metadata').getAttribute('data'));
i18n.init(injectedMetadata.legacyMetadata.translations);

new CoreSystem(ä
  injectedMetadata,
  rootDomElement: document.body,
  requireLegacyFiles: () => ä
    require('plugins/kibana/kibana');
  å
å).start()

优化部署的方案（前后端分离的部署）

我们已经初步了解了kibana和kibana plugins的架构。那kibana插件的安装方案是怎么样的呢？ kibana为了简化我们的工作，只需要我们将打包好的源码丢给kibana，然后执行命令：kibana-plugin install file:///path_to_your_file，这样貌似省事，但也把所有的工作都丢给了kibana服务器去完成。 在kibana服务器性能不佳的情况下，这部分工作可能会造成服务中断。因此，我们要代替kibana服务器完成这部分工作，做一个前后端分离的部署。

后端部署

后端部署的速度是极快的，只需要把文件解压缩到具体目录就可以：

`kibana-plugin install --no-optimize file:///path_to_your_file`

这里特别要注意: --no-optimize参数是必须的，这时，插件的安装只是一个解压的过程，不会让kibana服务器去做繁重的optimize工作。

注意，执行这一步之后，不能重启kibana服务器，否则会自动做optimize

前端部署

这里说的前端，主要是指bundle之后的内容。在你的开发环境上，安装插件。当插件安装完成后，把bundles目录整体打包（bundles.zip）。将打包好之后的内容，上传到kibana服务器，删除旧的optimize/bundles目录，把打包好的bundles目录解压到optimize目录下

注意，这里开发环境上的kibana版本，和kibana安装的插件必须是和生产环境上是一致的，否则会造成无法启动或者自动重做optimize

重启kibana服务器

当以上两步完成之后，重启kibana service即可，你会发现，内容已经更新，但是不会触发任何的optimize过程。

参考示例

以下是该过程的一个ansible playbook供大家参考

---

- name: deploy bundles zip
  copy: src=bundles.zip dest={{kibana_home}}/optimize force=yes mode={{file_mask}}

- name: deploy system plugins zip
  copy: src=system_portal-0.0.0.zip dest={{kibana_home}}/ force=yes mode={{file_mask}}

- name: deploy auth zip
  copy: src=kibana_auth_plugin-6.5.0.zip dest={{kibana_home}}/ force=yes mode={{file_mask}}

- name: remove system plugin
  shell: "{{kibana_home}}/bin/kibana-plugin remove system_portal"
  ignore_errors: True

- name: remove auth plugin
  shell: "{{kibana_home}}/bin/kibana-plugin remove kibana_auth_plugin"
  ignore_errors: True

- name: install system plugin
  shell: "{{kibana_home}}/bin/kibana-plugin install --no-optimize file://{{kibana_home}}/system_portal-0.0.0.zip"
  register: install_state

- name: install auth plugin
  shell: "{{kibana_home}}/bin/kibana-plugin install --no-optimize file://{{kibana_home}}/kibana_auth_plugin-6.5.0.zip"
  register: install_state
#  failed_when: "'Extraction complete' in install_state.stdout_lines"

- name: delete old bundls
  file: dest={{kibana_home}}/optimize/bundles state=absent

- name: delete old bundls
  unarchive:
     src: "{{kibana_home}}/optimize/bundles.zip"
     dest: "{{kibana_home}}/optimize/"
     copy: no
     group: "kibana"
     owner: "kibana"
     mode: "{{file_mask}}"

- name: delete zip files
  file: dest={{kibana_home}}/optimize/bundles.zip state=absent

- name: restart kibana
  become: yes
  service: name={{kibana_init_script | basename}} state=restarted enabled=yes