Customizing Kibana advanced settings in a Docker container?

[GrahamHannington]

Background to my question

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.

That .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.

My question

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.

[dosant (Anton Dosov)]

There is actually a way to override default ui settings from configuration:
For example, in your kibana.yml:

uiSettings:
  overrides:
    "courier:ignoreFilterIfFieldNotInIndex": true

I think this is what you are looking for.

FYI There is an open issue and I am checking with the team, why this wasn't documented Setting advanced settings in the kibana.yml · Issue #14395 · elastic/kibana · GitHub

[GrahamHannington]

In my original post, I wrote:

@GrahamHannington

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.

I was wrong, naive. I've immediately hit a counterexample use case: upgrading to a new version of the Elastic Stack.

I have a Dockerfile and corresponding artifacts, including a shell script and exported .ndjson file. I can build an image, and use that image with the docker run command to deploy a container with my dashboards, and with sample data already ingested. This includes overwriting the default Kibana config object with the imported object that has the same id, with custom settings.

This works. So far, so good.

Next, I want to upgrade to a later version of the Elastic Stack.

Something I didn't mention in my original post: my development Elastic Stack is also a Docker container based on the sebp/elk image. Previously, to upgrade my development environment, I stopped and removed the existing Docker container, started a new container based on a later version of the sebp/elk image, and then performed a series of manual steps that I have now automated in a Dockerfile. (In case anyone is wondering: yes, I've read the docs for upgrading in situ.)

I want to create a new development environment using my Dockerfile, by building a new image based on a later sebp/elk image.

Problem: simply importing the existing config object in my .ndjson file no longer works in this case. My .ndjson file has a config object with the id 7.11.2, but the new container will be running Elastic Stack 7.13.2, and so its Kibana will have a config object with that id. The imported config with the old id will be ignored. At least, I think so. Does Kibana only refer to the config object with the id that matches the Kibana version? Or, does Kibana concatenate all config objects, in some order? Either way, is this behavior publicly documented? If so, could someone please point me to those docs?

Some solutions:

1. In the Dockerfile (before Kibana starts), edit kibana.yml, as mentioned by @dosant (thanks, Anton!). If I did this, then I would want to also remove the old config object from my .ndjson file, so it didn't get imported. (Or, no longer simply use the Kibana UI to export all saved objects from my development space, but create a scripted API request that specifically excludes config objects.)
2. Use the Kibana update object API to set values in the in the new config object, as an alternative to editing kibana.yml. Updating the config object appeals to me because all of the custom advanced settings would be in one place, in the config object; especially if I decided, during development, to customize other settings, or revert custom values to their defaults. Again, I'd want to avoid importing the old config object.
3. Before using the Kibana API to import the .ndjson file, edit the id of the config object to match the current Kibana version. The problem I have with this approach is overwriting the config object for the new version, which might have new or different settings. This seems like an avoidable risk to me.

(These actions, such as "edit", would be performed programmatically, by the Dockerfile or a shell script driven by the Dockerfile, not manually.)

Thoughts, recommendations?