You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .ci/Dockerfile
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
# NOTE: This Dockerfile is ONLY used to run certain tasks in CI. It is not used to run Kibana or as a distributable.
2
2
# If you're looking for the Kibana Docker image distributable, please see: src/dev/build/tasks/os_packages/docker_generator/templates/dockerfile.template.ts
From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way
10
+
From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way
11
11
to visualize and analyze data.
12
12
13
13
From a developer perspective, Kibana is a platform that provides a set of tools to build not only the UI you see in Kibana today, but
14
-
a wide variety of applications that can be used to explore, visualize, and act upon data in Elasticsearch. The platform provides developers the ability
15
-
to build applications, or inject extra functionality into
14
+
a wide variety of applications that can be used to explore, visualize, and act upon data in Elasticsearch. The platform provides developers the ability
15
+
to build applications, or inject extra functionality into
16
16
already existing applications. Did you know that almost everything you see in the
17
17
Kibana UI is built inside a plugin? If you removed all plugins from Kibana, you'd be left with an empty navigation menu, and a set of
18
18
developer tools. The Kibana platform is a blank canvas, just waiting for a developer to come along and create something!
Plugins have access to three kinds of public services:
25
25
26
26
- Platform services provided by `core` (<DocLinkid="kibPlatformIntro"section="core-services"text="Core services"/>)
27
27
- Platform services provided by plugins (<DocLinkid="kibPlatformIntro"section="platform-plugins"text="Platform plugins"/>)
28
-
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
28
+
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
29
29
30
30
The first two items are what make up "Platform services".
31
31
@@ -37,9 +37,9 @@ clear, and we haven't done a great job of sticking to it. For example, notificat
37
37
Today it looks something like this.
38
38
39
39
40
-
40
+
41
41
<DocAccordionbuttonContent="A bit of history">
42
-
When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental
42
+
When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental
43
43
code needed to build plugins inside core.
44
44
45
45
In reality, we ended up with many platform-like services living outside of core, with no (short term) intention of moving them. We highly encourage plugin developers to use
@@ -54,7 +54,7 @@ In reality, our plugin model ended up being used like micro-services. Plugins ar
54
54
they desire, without the need to build a plugin.
55
55
56
56
Another side effect of having many small plugins is that common code often ends up extracted into another plugin. Use case specific utilities are exported,
57
-
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
57
+
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
58
58
every publically exposed service", but in today's world, that wouldn't be a very accurate picture.
59
59
60
60
We recognize the need to better clarify the relationship between core functionality, platform-like plugin functionality, and functionality exposed by other plugins.
@@ -69,19 +69,19 @@ We will continue to focus on adding clarity around these types of services and w
69
69
### Core services
70
70
71
71
Sometimes referred to just as Core, Core services provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
72
-
routing, application registration, and notifications. The Core platform is not a plugin itself, although
72
+
routing, application registration, notifications and <DocLinkid="kibCoreLogging"text="logging"/>. The Core platform is not a plugin itself, although
73
73
there are some plugins that provide platform functionality. We call these <DocLinkid="kibPlatformIntro"section="platform-plugins"text="Platform plugins"/>.
74
74
75
75
### Platform plugins
76
76
77
-
Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
77
+
Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
78
78
<DocLinkid="kibDataPlugin"text="data"/> plugin. There is no official way to tell if a plugin is a platform plugin or not.
79
79
Platform plugins are _usually_ plugins that are managed by the Platform Group, but we are starting to see some exceptions.
80
80
81
81
## Plugins
82
82
83
-
Plugins are code that is written to extend and customize Kibana. Plugin's don't have to be part of the Kibana repo, though the Kibana
84
-
repo does contain many plugins! Plugins add customizations by
83
+
Plugins are code that is written to extend and customize Kibana. Plugin's don't have to be part of the Kibana repo, though the Kibana
84
+
repo does contain many plugins! Plugins add customizations by
85
85
using <DocLinkid="kibPlatformIntro"section="extension-points"text="extension points"/> provided by <DocLinkid="kibPlatformIntro"section="platform-services"text="platform services"/>.
86
86
Sometimes people confuse the term "plugin" and "application". While often there is a 1:1 relationship between a plugin and an application, it is not always the case.
87
87
A plugin may register many applications, or none.
@@ -97,7 +97,7 @@ adding it to core's application <DocLink id="kibPlatformIntro" section="registry
97
97
98
98
### Public plugin API
99
99
100
-
A plugin's public API consists of everything exported from a plugin's <DocLinkid="kibPlatformIntro"section="plugin-lifecycle"text="start or setup lifecycle methods"/>,
100
+
A plugin's public API consists of everything exported from a plugin's <DocLinkid="kibPlatformIntro"section="plugin-lifecycle"text="start or setup lifecycle methods"/>,
101
101
as well as from the top level `index.ts` files that exist in the three "scope" folders:
102
102
103
103
- common/index.ts
@@ -113,18 +113,18 @@ Core, and plugins, expose different features at different parts of their lifecyc
113
113
specifically-named functions on the service definition.
114
114
115
115
Kibana has three lifecycles: setup, start, and stop. Each plugin’s setup function is called sequentially while Kibana is setting up
116
-
on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
116
+
on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
117
117
The stop functions are called sequentially while Kibana is gracefully shutting down the server or when the browser tab or window is being closed.
118
118
119
119
The table below explains how each lifecycle relates to the state of Kibana.
120
120
121
121
| lifecycle | purpose | server | browser |
122
122
| ---------- | ------ | ------- | ----- |
123
123
| setup | perform "registration" work to setup environment for runtime |configure REST API endpoint, register saved object types, etc. | configure application routes in SPA, register custom UI elements in extension points, etc. |
124
-
| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.|
124
+
| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.|
125
125
| stop | cleanup runtime | dispose of active handles before the server shutdown. | store session data in the LocalStorage when the user navigates away from Kibana, etc. |
126
126
127
-
Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types
127
+
Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types
128
128
of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.
129
129
130
130
## Extension points
@@ -141,4 +141,4 @@ plugins to customize the Kibana experience. Examples of extension points are:
141
141
142
142
## Follow up material
143
143
144
-
Learn how to build your own plugin by following <DocLinkid="kibDevTutorialBuildAPlugin" />
144
+
Learn how to build your own plugin by following <DocLinkid="kibDevTutorialBuildAPlugin" />
0 commit comments