Dockerizing Postgres Unconference Session
This session will be to discuss the various technical changes required to make PostgreSQL on Docker a seamless experience. Looking here for anyone who is already running Postgres on Docker, or who wants to do so but hit technical obstacles.
Session Attendees: Josh Berkus
- Josh Berkus: shouldn't need SSH, but do need it today. Should be one host, one port, one service.
- Jeff Davis: What about data?
- Josh: ... volume management ...
- Jan Urbanski: "restart" should be "redeploy cluster"
- Josh: volume points from inside container to outside directory
- ... flocker uses ZFS instead of UnionFS ...
- Jeff: What is the advantage of Docker?
- Josh: pg_hba.conf can be in the container (improves or worsens LDAP config??)
- replace Vagrant
- replicate customer environment
- packaging (extensions with dependencies, etc)
- public clouds
- Valentine Gogichasvili: Auditability
- Jan: Distribution, Handoff
- ?: Testing
- Jan: "parity"
- Josh: Node.js "cycle" where project doesn't handle packaging well, so a container is required, so fewer projects deal with packaging
- Greg Smith: flocker good for his use case
- ... so many use cases ...
- Greg: other projects will have similar persistence issues, so we can wait for Docker to solve them
- Josh: CoreOS conference panel first question was about persistence
- Ozgun: Issue of persistence similar to AWS local storage vs. EBS choice
- ... what happens when external storage is not available ...
- Josh: Freeze or EIO
- Ozgun: Logging?
- Jeff: emit_log_hook
- Jan: persistent config settings opposed to docker philosophy of immutability
- Josh: many apps take minutes to find that there's a new master to connect to
- Jan: PGBouncer reload
- Josh: software-defined networking
- Greg: graceful shutdown could take minutes
- Josh: and hard shutdown w/ async replication means data loss
- Alexander Kukushkin: pg_upgrade?
- Josh: ... explains pg_upgrade procedure involving 3 kinds of docker containers ....
- Valentine: Advantages of docker aren't directly related to production.
- Josh: orchestration doesn't strictly require containers, but problem not solved with puppet, e.g. master brought up before replica
- Josh: crystal ball says that in 4 years everyone will be using containers (not necessarily Docker)
- ... whether they want to or not ...
- ... other databases in the same boat (with some theoretical advantages for multi-master) ...
- ... lots of Docker functionality being built in linux
- Jan: nsspawn
- ?: how to distribute patches?
- Josh: new image
- Josh: we should have official images for Docker, CoreOS, etc.
Postgres on Docker Issues
Postgres has a number of activities which still require shell access. Auto.conf elminates one of those, but there are more.
There is currently no good way, short of using pgAdmin + Adminpack, to make changes to pg_hba.conf without ssh access.
We can reload via an SQL command, but not restart.
Remastering etc. is not possible without editing recovery.conf. Alternate solutions: 
PostgreSQL needs to store its data on an external volume, which is generally not managed by Docker. How are people handling this? Flocker? Kubernetes?
Do all the PostgreSQL parts work correctly if we run a container without a full init system, ala CoreOS? Has anyone tried this?
Can we create an improved auto-configuration on startup, if we know that we're running in a container?