I want to deploy a set of Kibana dashboards in a Docker container. This will include changing some Kibana advanced settings, such as
courier:ignoreFilterIfFieldNotInIndex, from their default values.
I'll be using the "all-in-one" (Elasticsearch, Logstash, Kibana)
sebp/elk Docker image as the base image.
In my Dockerfile, I'll run a shell script that uses
curl to send the contents of a
.ndjson file (exported from my "development" Kibana instance, copied from the build context into the container by a
COPY instruction in the Dockerfile) to the Kibana Import Saved Objects API.
.ndjson file will include an "Advanced Settings [x.y.z]" saved object (type: config, id: x.y.z). The config object in the
.ndjson file will overwrite the existing config in the Docker container.
I will ensure that the Kibana instance from which I export the
.ndjson file is at the same x.y.z version as the Kibana in the Docker container, so that the config saved object has the appropriate x.y.z id.
Does all of the above sound okay?
I'm assuming that, if the id of the config object that I import matches the Kibana instance version x.y.z, then this will work.
But: is that a safe assumption? Is there anything going on "under the hood", beyond the requirement to match that x.y.z value?
In other forum topics, I've read about people using the Kibana API to customize settings in the existing
/api/saved_objects/config/x.y.z, but for my purposes, I think it will be simpler to export all saved objects, including the config object, from my "development" instance, and then import them all into the fresh Kibana instance in the Docker container, overwriting the default config object in that instance.