# All for custom configurations in docker image
**URL:** https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983
**Category:** Beats
**Tags:** filebeat
**Created:** [June 27, 2017, 2:46pm UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983 "2017-06-27T14:46:29Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@djschny](https://discuss.elastic.co/u/djschny)
#### Post date: [June 27, 2017, 2:46pm UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/1 "2017-06-27T14:46:30Z")
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.
---
### Author:  [@exekias](https://discuss.elastic.co/u/exekias)
#### Post date: [June 27, 2017, 3:10pm UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/2 "2017-06-27T15:10:15Z")
I'm currently working on moving conf to a `modules.d` layout ([https://github.com/elastic/beats/pull/4537](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 🙂
---
### Author:  [@djschny](https://discuss.elastic.co/u/djschny)
#### Post date: [June 27, 2017, 4:36pm UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/3 "2017-06-27T16:36:08Z")
> 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 🙂
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.
---
### Author:  [@steffens](https://discuss.elastic.co/u/steffens)
#### Post date: [June 28, 2017, 10:04am UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/4 "2017-06-28T10:04:41Z")
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'}"`?
---
### Author:  [@djschny](https://discuss.elastic.co/u/djschny)
#### Post date: [June 28, 2017, 11:41am UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/5 "2017-06-28T11:41:08Z")
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?
---
### Author:  [@steffens](https://discuss.elastic.co/u/steffens)
#### Post date: [June 29, 2017, 11:51am UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/6 "2017-06-29T11:51:33Z")
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.
---
### Author:  [@djschny](https://discuss.elastic.co/u/djschny)
#### Post date: [June 29, 2017, 12:30pm UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/7 "2017-06-29T12:30:43Z")
Well due to the nature of the filebeat configuration files, it is difficult for me to envision getting away without providing one.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 27, 2017, 12:30pm UTC](https://discuss.elastic.co/t/all-for-custom-configurations-in-docker-image/90983/8 "2017-07-27T12:30:49Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.