-
Notifications
You must be signed in to change notification settings - Fork 1.2k
suggestion: add a default include_dir configuration #835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sometimes it can be necessary to be able to customize server config within the image instead of overriding via command line arguments to What do you think @wglambert ? |
Actually, would also be great if it would be possible to interpolate container start-up time environment variable values in config files. This would be useful e.g. in configuring |
Using your suggestion, it is not that hard to extend the image for your own needs. Unfortunately, I don't think this is something we want to add to the image right now. FROM postgres:13
RUN set eux; \
confdir='/docker-postgres-conf.d/'; \
mkdir -p "$confdir"; \
chown postgres:postgres "$confdir"; \
echo "include_dir = '$confdir'" >> /usr/share/postgresql/postgresql.conf.sample $ docker build -t pg .
Sending build context to Docker daemon 11.26kB
Step 1/2 : FROM postgres:13
---> 293e4ed402ba
Step 2/2 : RUN set eux; confdir='/docker-postgres-conf.d/'; mkdir "$confdir"; chown postgres:postgres "$confdir"; echo "include_dir = '$confdir'" >> /usr/share/postgresql/postgresql.conf.sample
---> Running in 01feb0757294
Removing intermediate container 01feb0757294
---> c9083ff81afd
Successfully built c9083ff81afd
Successfully tagged pg:latest
$ cat extra.conf
shared_buffers=256MB
$ docker run -it --rm -e POSTGRES_PASSWORD=12345 --name pg-test -v "$PWD/extra.conf":/docker-postgres-conf.d/extra.conf pg
$ # check via another terminal and shared_buffers is correctly changed from the default Conf files mounted this way or otherwise placed in the configuration directory would need to have proper permissions for the postgres user to read it. |
thx @yosifkit ! It’s indeed not too hard. Especially if we’re already build a custom image (eg: to install 3rd party extensions) Still, I don’t understand why it should not be included in the base image, is it to keep as close as possible to the default Postgres configuration ? Or is it not useful enough ? If you have a bit of time to spare, I would be interested in reading your point of view on the subject I’m just asking out of curiosity, feel free to ignore this and close the issue if it’s not useful to keep this issue around. I won’t be offended ! And if you have time to waste, here is the thought process that led me to open this issue/suggestion : For most project the default Postgres image is enough, and I can make it work by changing the configuration with command line arguments, but it’s not the nicest when you want to read / edit or look at configuration changes over time (because it’s - in my case - included in the docker-compose.yml file which should not, imho, be the place where I configure Postgres. The alternative is, as you mentioned, to build a custom image, either adding an |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
i would really like to have an option to specify an include_dirs, to achieve it i:
it shouldn't be too hard to set in the entrypoint a verification if an include_dirs env var is set, and if path exist enable the include_dirs conf with this path in the original .conf before starting it, base use will still be able to use the current image as it, and advanced use will be able to use it as a base image and include custom .conf to be added |
Hi,
I find it harder than it should be to customize postgresql.conf:
so I suggest to add an
include_dir
configuration in the default postgresql.confin the Dockerfile, where
listen_addresses
is added, something alongmkdir /docker-postgres-conf.d/ && echo 'include_dir=/docker-postgres-conf.d/' >> /usr/share/postgresql/postgresql.conf.sample
I believe this would be really useful, comes with no BC break and low maintenance
what do you think ?
(might be related to #581)
The text was updated successfully, but these errors were encountered: