Don’t install Postgres. Docker pull Postgres

“black sperm whale” by Sho Hatakeyama on Unsplash

Since the advent of Docker, I rarely find my self directly installing development software on my local machine. Be it database servers (i.e Postgres), caching systems (i.e Redis, Memcache) or messaging systems (i.e Kafka) — I almost always try to find or build an appropriate docker image to use during development.

Installing software is hard. And it has nothing to do with your expertise as a developer. We have all seen our fair share of version clashes, esoteric build failure messages and missing dependency errors each time we embarked upon the task of installing a new software to use. We have spent countless hours copy pasting snippets of code from Stack Overflow onto our terminal and running them with the hope that one of them will magically resolve install issues and make the software run. The result is mostly despair, frustration and loss of productivity.

Docker provides a way out of this mess by reducing the task of installing and running software to as little as two commands (docker run and docker pull). In this post we will see this process in action by taking a step by step look at how easy and simple it is to setup a Postgres installation with docker.

Note that this is not a tutorial on docker. If you are curious about the inner workings of docker and all that you can do with it, I encourage you to surf the web as there is plenty of quality material out there on the topic.

This post assumes that you have a valid docker account and a docker daemon running. If you are completely new to docker, I would recommend starting here.

Getting the Postgres Docker Image

To pull down an image for the latest stable release of Postgres, simply run

docker pull postgres

This will pull down the latest stable release Postgres image from the official Postgres docker hub repository. To pull down a version other than the latest stable release, we can provide an appropriate image tag name to the docker pull command above

docker pull postgres:[tag_you_want]

Create a Directory to Serve as the Local Host Mount Point for Postgres Data Files

If we want to persist data generated by the Postgres instance running inside a container beyond the container’s lifecycle, we need to map a local mount point as a data volume to an appropriate path inside the container. Typically I create a volumes folder (we can give the folder any name we like) in my home directory and then create subfolders for each of the applications I need to create data volume mount points for.

mkdir -p $HOME/docker/volumes/postgres

Run the Postgres Container

Starting the Postgres container is as simple as running the docker run command

docker run --rm --name pg-docker -e POSTGRES_PASSWORD=docker -d -p 5432:5432 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data postgres

We have provided several options to the docker run command:

• — rm: Automatically remove the container and it’s associated file system upon exit. In general, if we are running lots of short term containers, it is good practice to to pass rm flag to the docker run command for automatic cleanup and avoid disk space issues. We can always use the v option (described below) to persist data beyond the lifecycle of a container
• — name: An identifying name for the container. We can choose any name we want. Note that two existing (even if they are stopped) containers cannot have the same name. In order to re-use a name, you would either need pass the rm flag to the docker run command or explicitly remove the container by using the command docker rm [container name].
• -e: Expose environment variable of name POSTGRES_PASSWORD with value docker to the container. This environment variable sets the superuser password for PostgreSQL. We can set POSTGRES_PASSWORD to anything we like. I just choose it to be docker for demonstration. There are additional environment variables you can set. These include POSTGRES_USER and POSTGRES_DB. POSTGRES_USER sets the superuser name. If not provided, the superuser name defaults to postgres. POSTGRES_DB sets the name of the default database to setup. If not provided, it defaults to the value of POSTGRES_USER.
• -d: Launches the container in detached mode or in other words, in the background.
• -p: Bind port 5432 on localhost to port 5432 within the container. This option enables applications running out side of the container to be able to connect to the Postgres server running inside the container.
• -v: Mount $HOME/docker/volumes/postgres on the host machine to the container side volume path /var/lib/postgresql/data created inside the container. This ensures that postgres data persists even after the container is removed.

Connect to Postgres

Once the container is up an running, connecting to it from an application is no different than connecting to a Postgres instance running outside a docker container. For example, to connect using psql we can execute

psql -h localhost -U postgres -d postgres

Hopefully this post has demonstrated how easy and straightforward it is to get up and running with Postgres in docker. For most other applications, the process is just as simple. So next time you need to install a piece of software, think docker pull before you reach for brew install, yum install, apt-get install or whatever the command is for your systems package manager :)