Database Server Role Design Considerations (Take Two)

Stephen Gallagher sgallagh at redhat.com
Mon Dec 15 15:42:42 UTC 2014




On Mon, 2014-12-15 at 08:11 -0600, Bruno Wolff III wrote:
> On Mon, Dec 15, 2014 at 09:07:45 -0500,
>   Stephen Gallagher <sgallagh at redhat.com> wrote:
> >     3. We run multiple database services in individual containers on
> >        the system. Each of these services is provided by a rolekit
> >        instance and is a full, isolated copy of the PostgreSQL
> >        processes. Each of these databases will need to operate on a
> >        separate port (or the same port on separate interfaces, etc.)
> 
> Note that using domain sockets provides a nice authentication option 
> (using the userid of the peer) for other services using the same machine, 
> that you don't get with a normal network port. If possible it may be 
> desirable to make the domain sockets visible outside of the container 
> as well as the network ports. (This assumes that you are expecting some 
> services that consume the database service running on the same machine. 
> that might be a bad assumption for the database server role.)

Yeah, the domain socket idea could be really useful in some cases, but I
think in the infrastructure database server case, it's probably a bit of
a distraction. The expectation here is that the database server will
likely be standalone and serving out to other applications on different
machines. (At least, that's my expectation).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20141215/4469995e/attachment.sig>


More information about the server mailing list