Re: SSH-free PostgreSQL

On 07/29/2014 12:55 PM, Joseph Ferguson wrote:
> 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.

Awesome!

>> (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.

PostgreSQL has pg_reload_conf() already as a command, so reloading taken
care of. And changing this stuff over port 5432 seems more elegant than
working via volumes. Also, pgAdmin has a nice GUI for it.

>
>> (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].

Well, we could do that if we wanted to always assume that the --link was
called "master", which isn't a bad idea.

That does beg the question of how we could remaster (switch to a
different master), though, since --links are not changeable once the
docker has been started up.

>> (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.

That seems very complicated. Maybe it would be easier if we used a
trigger file instead of "pg_ctl promote"?

>> (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

I'll check it out.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com