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