All for custom configurations in docker image

Elastic Stack Beats
1

The current docker image ships with a default configuration file that filebeat uses and with auto-reloading disabled. When using this in practice most folks are going to need a custom configuration file. The completely turn the filebeat.full.yaml file into one that has environment variables that can be overriden for every option is not reasonable.

Rolling a custom docker image built-off the elastic one just for the purpose of overriding a configuration file is overkill.

To workaround this in Kubernetes I'm starting filebeat manually and passing it the location of files that I mounted in via a config map volume.

spec:
  containers:
  - name: filebeat
    image: docker.elastic.co/beats/filebeat:6.0.0-alpha2
    command: ["filebeat"]
    args: ["-e", "-c", "/etc/filebeat/filebeat.yaml"]
    resources:
      limits:
        cpu: 50m
        memory: 50Mi
    securityContext:
      privileged: true
      runAsUser: 0
    env:
      - name: ELASTICSEARCH_URL
        value: http://es-k8s-logging:9200
    volumeMounts:
    - name: config-volume
      mountPath: /etc/filebeat
  terminationGracePeriodSeconds: 30
  volumes:
  - name: config-volume
    configMap:
      name: filebeat-config

If anyone has a better suggestion on how to do this, it would be much appreciated. Another alternative is the default filebeat configuration file is removed from the image. This way everyone gets defaults but can mount in their own without needing to manually invoke the filebeat command.

2

I'm currently working on moving conf to a modules.d layout (https://github.com/elastic/beats/pull/4537), partially motivated by this use case.

Once that gets merged we should be able to mount a config map to configure the desired modules, while keeping default filebeat.yml untouched. Let me know what do you think about it.

Of course this would also require to have elasticsearch env variables in the config, but I think that's something we could do.

As for your setup, this is what I have been doing so far, not great, but it works fine :slight_smile:

3

Let me know what do you think about it.

I think that will work as long as the default config has the environment variables. I subscribed to the issue.

As for your setup, this is what I have been doing so far, not great, but it works fine :slight_smile:

Thanks, yeah it's totally doable right now, but to make the coupling of know what cmd/entrypoint to use would be great.

Thank you.

4

Well, it's somewhat unfortunate, but have you considered to enable auto-reloading from CLI by passing -E "filebeat.config.prospectors={reload.enabled:true, reload.period: 10s, path='/etc/filebeat.d/*.yml'}"?

5

Yes, but since that still requires overriding the CMD entrypoint from the docker image, I didn't see much benefit of it over the current approach. The goal is to avoid specifying a command entry with arguments. Unless I'm missing a benefit?

6

I thought one of the problems is also having to pass a customized filebeat.yml.
Passing/overwriting additional settings in filebeat.yml in the args section maybe does not require you to provide a customized filebeat.yml configuration. But there is no real benefit to it, especially if you already provide a customized filebeat.yml.

7

Well due to the nature of the filebeat configuration files, it is difficult for me to envision getting away without providing one.

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.