Public | Automated Build

Last pushed: 10 days ago
Short Description
The PostgreSQL object-relational database system provides reliability and data integrity.
Full Description

Supported tags

  • 10.0, latest
  • 9.6
  • 9.5
  • 9.4
  • 9.3

About this image

This docker uses a custom ubuntu:trusty image as a base.

How to use this image

Start PostgreSQL

Run your docker, assuming you named your postgresql docker pg as we did above:

$ docker run --rm --name="pg" xcgd/postgresql

To run a specific version:

$ docker run --rm --name="pg95" xcgd/postgresql:9.5


This image ships data volumes for persistence. By default, they will be bound to docker vfs and thus removed along with the container.

You'd rather want to bind volumes to your local file system. This image comes with a facility where initdb is executed only if an empty data volume is found. Otherwise it is just mounted and used.

Let's pretend your persistent data is located under /opt/instance1/dbdata/ on your host machine, you can use it with:

$ docker run --name="pg" -v /opt/instance1/dbdata:/var/lib/postgresql -d xcgd/postgresql

Security Notes

You'll note that we did not open ports to the outside world on the PostgreSQL container. This is for security reasons, NEVER RUN your PostgreSQL container with ports open to the outside world... Just link other containers (single host) or use an ambassador pattern (cluster).

This is really important to understand. PostgreSQL is configured to trust everyone so better keep it firewalled. And before yelling madness please consider this: If someone gains access to your host and is able to launch a container and open a port for himself he's got your data anyway... he’s on your machine. So keep that port closed and secure your host. Your database is as safe as your host is, no more.

Docker Pull Command
Source Repository

Comments (6)
3 years ago

Our containers don't provide a ssh or even a tty. Thus, the container cannot be compromised unless running a docker exec as root from the host, which is another real concern.

If a motivated individual figures out a breach from the dockerized application itself and finds a way to execute some code, he will have to gain root access that way, get the etcd server address and run etcdctl or something similar with a crafted client certificate.

Nonetheless, security is a real topic and we are glad to discuss and debate the matter anytime. If you find a way to compromise a whole cluster, please report to our tracker.

Last remark: the last image comes with an updated confd version compatible with a consul backend if you don't want to use etcd at all ;)

3 years ago

I menat: one single compromised container.

3 years ago

nice. :+1:

however, the problem I see with ectd is that a compromised system has easyest acces to all configuration data ("the brain") wihtout difficulties... Not that much, that it is accessed from the outside world... (if I understood you right, that is what you meant?)

By "hidden", I meant hidden in some lower diff-levels in the fs layers, because even a ubuntu trusted, I have hard time explaining that it's over a GB. But maybe I actually missed something. ;)

3 years ago


Thanks again for your clever comments. You are perfectly right that we could work on improving the base image size, which is a naive full ubuntu:trusty, shiping loads of unnecessary stuff by default. Switching to a light debian-based image is in the roadmap.

Concerning our xcgd/ubuntu4base image, this is a trusted build like any other we provide, that is without any hidden stuff ;) Both confd and etcdctl clients are enclosed as binary for clustering and automated configuration purpose in our own hosting platform running CoreOS. Providing a secure/private etcd service is pretty easy so I wouldn't worry about built-in ACL (in our case, a nginx front prevents any companion like curl to write in our private etcd registry)

3 years ago

Maybe you might use: instead and disable / remove curl and similar companions (iirc statically linked and compiled, so I bet there is at least no write method available)...

3 years ago

I'm would bet, integrating etcdctl on the base image isn't quite a good idea (etcd cluster got no ACL). Additionally, it seems that your ubuntu4base has builtin (hidden) sins, as both of your images (postgresql and odoo) are more than a GB in size.. Please consider squashing the Docker commits, maybe combined with some OS cleanup of unnecessary stuff...