I have mounted /registry:/var/lib/postgresql to postgres:9.3 and 9.4.
Also mounted: create_db.sql:/docker-entrypoint-initdb.d/create_db.sql
I see that this sql file is get executed but nothing has been created inside /var/lib/postgresql (my case /registry) just an empty folder called data and nothing more.
If I try to use initdb then is raised an exception that the data folder is not empty.
Could you past the full Docker run command you use to start your PostgreSQL database?
I believe you need to mount with /registry:/var/lib/postgresql/data.
The empty 鈥渄ata" directory is the mount point directory created when the
Docker-managed /var/lib/postgresql/data directory is mounted.
I also see this issue with the following docker-compose.yml
db:
image: postgres
volumes:
- ./data:/var/lib/postgresql
api:
build: ./api
links:
- db
volumes:
- ./api:/myapp
Is there something I'm missing?
I think you need the data directory as well.
volumes:
- ./data:/var/lib/postgresql/data
Indeed. Because "/var/lib/postgresql/data" is marked as a VOLUME in the
Dockerfile, Docker will always create a new volume there unless it's
explicitly mounted over top of, even if "/var/lib/postgresql" is a volume
above it.
What is the benefit of marking any volumes in the Dockerfile? If this prevents people defining their own mappings?
It doesn't really prevent folks from defining their own mappings, but the
reason to do it is so that in the default case of no volume specified
explicitly, we still get a volume and don't suffer the performance penalty
of running our database storage directly on the CoW filesystem (which in
some cases can be really significant). Additionally, it allows Docker
Compose to work out-of-the-box with proper data persistence, and acts as a
note to the image user that this is where the mutable state of the
container will be.
@tianon - Thanks for the info. It seems there is more I need to learn about using Docker.
Most helpful comment
I think you need the
datadirectory as well.