Kibana 4 package as static html/js

[SleeperSmith]

I've managed to get Kibana 4 to work using just the html/js/css assets. Admittedly there are a few errors here and there (not sure if it's caused by the missing kibana 4 server).

I am wondering if it's possible to release Kibana 4 as just static assets just like Kibana 3? This will give flexibility to let users choose the web server for themselves.

[yang66]

+1

[TinLe]

+1

There are several similar requests like yours. They've all been closed, unfortunately. For our environment, we need it as static html/js also.

Once K4 come out of beta, I might fork it just so I can get static html.

[spalger]

There are certainly pros and cons to having a server that is dedicated to Kibana. For this version though, we have decided to move forward with the Kibana server and it will become a more important part of the project as Kibana 4 matures.

For this reason, I suggest encorporating Kibanas server it into your server rather than try to find ways around it. Using your server as a reverse proxy that transmits requests back to Kibana shouldn't be hard with most modern servers.

Best of luck, and thanks for the feedback!

[SleeperSmith]

Are you saying we should stick to using the server that comes with k4? Or that it's better to use a web server? Because that is exactly what we doing.

All our stuff run on nginx and our monitoring and security are setup around it. Unless k4 server offer something important, it's otherwise just forcing an additional runtime to deal with.

[rashidkpc]

The integrated web server will become a required part of Kibana 4 as we move towards implementing features that can not be fully realized in javascript, for this reason we do not support separating the frontend from the new backend for the purpose of running on a 3rd party web server.

[TinLe]

This is too bad. For reasons of corporate policies and network topology, we go through at least 5 layers of proxies (hardware, software). With yet another embedded web server in K4, we now have to go and make changes to its config in order to make it work within our topology, and most likely will have to each time.

It is much simpler for us to be able to drop in static HTML/js files into the existing, working system.

[SleeperSmith]

Another issue, loosely tied with this, was that only because I pulled K4 html/js from the git repo were I able to hack my way around using K4 on ES 1.3.1 that we currently run. I'm not seeing any major problems.

I mean, I'm absolutely not putting ES 1.4 "beta" into production. (heck, it's not about the beta status, I don't run anything until it's out in the wild for a good few months at least) As it is, K4 html/js + the server absolutely will not work with anything but ES 1.4. Then, not as much people will be able to give you feed backs especially not from production environments that actually matters.

That coupled with the fact that K4 still has a long way to go before it can fully replace K3. To me, the server side functionality is just additional feature that I don't need that is going to delay K4 from finishing beta. IMO, that there is a big con against including a server.

You could configure K4 not to check and you could make the K4 server compatible with older ES versions, but that's just more work than releasing K4 html/js isn't it? I don't know about others, but even an "unsupported" package of html/js dump is welcomed, and that should be pretty easy?

[antong]

I understand that there may be functionality that is difficult or impossible to implement without a web service component. But is there a reason the web service needs be bundled with and tied into a web server implementation? Re-reading the question I get the impression that is at least part of the problem.

Thank you for your work on Kibana!

[damm]

This will likely complicate Authentication and Authorization :(

[SleeperSmith]

@antong At the very moment (K4 M1) doesn't seem like it to me. I pulled and built what's necessary and dumped the HTML/JS component into a web server, and it works fine. (copy paste the network result of /config from a K4 server and dump that as a plain text file.)

As I said, that's the only way I got it working with my ES 1.3.1 cluster.

[antong]

@damm, It definitely does complicate authorization if you consider what everybody probably has been building for auth with Kibana 3. However, looking at this new design, I would not be surprised if some of the features hinted at may actually be related to authentication and authorization. This is of course just me guessing.

@SleeperSmith , yes currently Kibana 4 javascript can work without the web service. However, @rashidkpc has commented that it will not continue to work when new features are added.

[TinLe]

I think it is good to provide some basic services with K4, such as AAA. However, trying to be all things to all people is going the wrong route. There are some fairly complex environment with byzantine requirements. IMHO, it's better to provide the toolsets and let users pick and chose what they need, instead of providing an all-in-one and forcing people to use it.

[Freedom101]

@antong agreed, they could achieve this without a tying it to a web server. It's a big shame ES have decided to go this route. IMV Kibiana loses one of it's key strengths in supporting flexible deployment options. I think a fork seems much more likely as a result which would be a shame.

[iozozturk]

+1

[SleeperSmith]

To be frank, AAA should not be built at kibana level but instead at elasticsearch. Very often kibana isn't the only use, and different AAA mechanism implemented again and again is just wrong.

What would you think if I told you the mysql database needs to be secured with firewall?....

[damm]

That's just normal @SleeperSmith everyone knows mysql should be secured with a firewall.

Just like how you don't deploy Elasticsearch in a public environment, apply iptables or don't have it bind to 0.0.0.0.

[SleeperSmith]

@damm eh no. What I meant is secured ONLY with firewall. Just because it's behind firewall doesn't mean it's secure. You'd deploy sql databases with firewall/vpn AND user/pass AND auth/roles.

Same thing with ElasticSearch. Firewall + reverse proxy auth itself is not good enough.

[damm]

Well you can always buy a license for Elasticsearch Shield once it's released

[sDaniel]

Running and maintaining a NodeJs server may very well be a show stopper for companies which don't use NodeJs already.

[damm]

Stop being funny, that's like what they were saying earlier.

'Package up Kibana 4 as html/js as I don't want to run JRuby'

Fear is a problem here; Fear of the Unknown. Give them a chance before you let the fear win

[Asimov4]

Can we reopen this and consider it seriously?

Migration from kibana 3 to kibana 4 would be made a lot easier if kibana 4 could be served as a static website. I believe a lot of current kibana 3 users would be happy to also have kibana 4 running in their current setup even if that means sacrificing the features that do require a server. That is also a great way for devs to make the case for doubling down on kibana 4 and get funding to invest in rewriting the integration to accommodate the new server setup. It is easier to convince people with a cheap plug and play demo and present the features that are missing and how much it would cost to fully migrate.

I do not advocate for getting rid of the server altogether, I advocate for graceful degradation where features are available or not depending on whether there is a server or not. That is also probably good coding practice as you'd have to clearly segment your features between frontend only and backend powered features.

[damm]

I know there were reports in the early beta that you could use Kibana 4 without. I don't know how it works but the src/public directory is what you want @Asimov4

[SleeperSmith]

@Asimov4 @sDaniel It's not hard to pull the src and just run the grunt/bower and build just the frontend. After that, run the K4 with the backend and just copy out the neccessary backend requests as static files. I'll be doing something similar be posting up something later (maybe).

@damm "fear"? Are you a kid? There's a difference between banging things out in a foreign language for shits and giggles and managing production system that doesn't fit into the existing infrastructure and platform. It's a compromise + additional cost sink. If the functionality that justifies the additional cost, so be it. The problem is that there isn't even any benefit to be realised at this point in time.

[sDaniel]

Lets not get aggressive. I'm using node every day for development. I have no problem recommending Kibana because of it's node.js usage. In fact I just have done that last week and it's no problem for the clients developers which I hadn't expected either, but I know it won't be so easy to convince the devops and management. I know it this has been said before but I'm not sure if it is clear to the Kibana developers how much trouble this is for some companies so I wanted to add my +1. If the version based on node remains the only option I don't mind - it it just means some people wont adapt Kibana that would otherwise.

I've also set up Kibana to run without node for testing (thanks for mentioning this) but that is not a supported option so it is hardly a solution I can recommend to every client as future updates may break this workaround.

[SleeperSmith]

I have just went through the latest release and ran it without the backend server (and it seems to run fine.)

1. Download the 4.0.1: https://download.elasticsearch.org/kibana/kibana/kibana-4.0.1-windows.zip.
2. Extract and grab the content from \src\public
3. root of that public folder, index.js, comment out 86394 ~ 86398
4. save this as a plain text file "config" at root of that public folder next to index.js (Yes with no extension):
   {
   "kibana_index": ".kibana-4",
   "default_app_id": "discover",
   "shard_timeout": 0,
   "plugins": [
   "plugins/dashboard/index",
   "plugins/discover/index",
   "plugins/doc/index",
   "plugins/kibana/index",
   "plugins/markdown_vis/index",
   "plugins/metric_vis/index",
   "plugins/settings/index",
   "plugins/table_vis/index",
   "plugins/vis_types/index",
   "plugins/visualize/index"
   ],
   "elasticsearch": "http://yourelasticsearch.io:9200/" //<- this replace the stuff commented out in step 3
   }

(btw I'm using this with elasticsearch 1.3 Works fine too. Line 83492 of index.js is where you want to fudge it.)

[Asimov4]

Awesome. Thanks for the description.
Kibana 4 does start but I get this exception:
"Courier Fetch Error: unhandled error Error: ElasticsearchIllegalArgumentException[explicit index in multi get is not allowed]"

We have set rest.action.multi.allow_explicit_index: false since we use url based access control for the REST API: http://www.elastic.co/guide/en/elasticsearch/reference/current/url-access-control.html
I believe that will be common for users who need to try Kibana 4 as a static package.

Related to: #1869

[Asimov4]

To make it easier for anyone else who needs to set things up this way, I created a separate repository for a static version of Kibana 4.
Here's the link to the release with only the changes that you have described: https://github.com/kibana-community/kibana4-static/releases/tag/v4.0.1-static
Here's the link to the release that includes a workaround for the issue I mentioned caused by the rest.action.multi.allow_explicit_index: false setting: https://github.com/kibana-community/kibana4-static/releases/tag/v4.0.1-static-disallow_explicit_index

[bradvido]

@Asimov4 awesome!
We also use URL-based access control with rest.action.multi.allow_explicit_index: false and Kibana4 mulit search queries fail.

[koh-osug]

Thanks Asimov. Good Job. Could this become a maintained fork of Kibana 4? I cannot understand the decision to couple Kibana 4 with a node server. This is just painful, an easy deployment within an existing server becomes harder and it increases the operations complexity. For me this move is also forcing people to use a cloud service offer, because they do not want to handle this complexity, which is some way to deny the idea of Open Source using a backdoor.

[school-coder]

Hi Guys,

I am new to Kibana 4. I came across https://github.com/kibana-community/kibana4-static.

Does this feature, "Kibana 4 as static HTML/JS" is supported on going forward? If supported, is there any tutorial ? any compatibility matrix table with ES ??

I found there is no active commits are going on there.

Thanks in advance! :)

[SleeperSmith]

Aaaand after 1.5 years, someone want to point out the "killer feature" this backend server for Kibana 4 brought?

[theactiveactor]

+1 for static version

We just want to reuse the dashboard and UI capabilities of Kibana and integrate that into our dashboard.

[Kranf99]

I'd like to be able to use the visual plugins built for kibana 4.4 inside "kibana static".
(I am stuck with kibana static for whatever reasons).
I had a brief discussion about this subject with Oleg Nenashev and he told me that it could be possible.
...but I am not a java guru.
Could somebody (maybe Asimov4?) do the required "upgrades" on "kibana static" to be able to use the visual plugins from the latest kibana ?
I have a small budget to do that.