Re: SSH-free PostgreSQL

On Tue, Jul 29, 2014 at 12:17 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Actually, it turns out that our set of things which need shell access
> for 9.4 for most users are fairly limited:
>
> (1) start/stop/restart
> (2) pg_hba.conf changes
> (3) pg_basebackup
> (4) replica promotion
> (5) log access
>
> For Docker at least, (1) could be handled with a container restart.
> Does that make sense?

Yes, these can be handled with `docker start postgres` and `docker
stop postgres` which analogues with `service postgres start` and
`/etc/init.d/postgres stop`, and even a `docker restart postgres`
which does the relevant stop followed by start.

> (2) I think is doable by installing the pgAdmin adminpack. This will
> also provide a postgresql.conf solution for 9.3.

This could be handled with the config file being handled through
--volumes-from or a bind mounted file/folder with -v and then doing a
docker stop and start, or `docker kill -s HUP postgres` to just send
SIGHUP for direct reload.

> (3) I'm thinking of doing this via parameterized (ENV for now) startup
> of a Postgres container. That is, you start up the container, and set
> $ROLE=replica and $MASTER="connection string", and on startup it does a
> basebackup and starts replication. Make sense?

Overall this is a solid idea. While I am not terribly familiar with
postgres replication, couldn't the MASTER string be derived from
--link environment variables on the replica slave? It would at least
have the ip address and port from the ENV. We would also want to make
sure if they provide a ROLE for replica that they also provide the
other necessary parts (like the link if that fulfills the connection
string). There is a similar check in the official wordpress image (to
check for the mysql --link) [1].

> (4) I think the most sensible way to do this is via a pl/sh script, or
> similar.

There are a few possibilities that I see.
(a) startup script that forks, parent process starts postgres
normally with the passed replica slave options (for docker to track)
while child process sleeps and then runs `pg_ctl promote`
(b) make a script for use with nsenter[2] and somehow distribute it to users
(c) wait for `docker exec` (or similar means of officially sharing
the PID namespace of postgres, which is coming)
(d) get pg_ctl working via "remote" socket?

I think the best would be (c) but if it is needed now, we could do (a)
or (b) as a hack until it is ready.

> (5) For now we'll just make the logs output to Docker's stderr. In
> time, we'll want to figure out a way to make this work with CSVlog, but
> that's a problem to solve later.

Sounds good.

> So, comments? Ideas?

Will our new branch start to fulfil the items you have here [3]?
Should we get this merged and pulling to the "official images"? Then
we can work to add the improvements you have outlined.

[1] https://github.com/docker-library/wordpress/blob/docker-3.9.1/docker-entrypoint.sh
[2] https://github.com/jpetazzo/nsenter
[3] https://github.com/infosiftr/postgres/tree/docker

- Joe Ferguson :: joe(at)infosiftr(dot)com
InfoSiftr :: Vice President of Programming