Red Green Repeat Adventures of a Spec Driven Junkie

Being Lazy: Installing postgres

Share how to be lazy when installing postgres on a Ubuntu system in Vagrant. I share why it’s important to take this approach and go over line-by-line installing a key part of systems I work with: postgres.

You will learn a way to configure postgres SQL in seven lines, so you can copy it and/or modify it for your needs.

This will take about four minutes to read.

Pieter Bruegel the Elder - The Harvesters source and more information

Introduction

Whenever I installed complicated software that is required for my application and not part of system I work with, I would take the approach:

Setup software now, move onto the next step of solving problem.

The next time I encounter this situation, I have to rethink how I solved the problem or configured a system. Essentially ask:

  • What did I do?
  • How did I do specific things?
  • Why is that way better?

It’s even a worse feeling when I have a “sorta” working system that I want to replicate, yet can’t do it.

I want configure software in the same way each time. Why spend all that energy to solve the same problem over and over? Later when I have to re-think things over again??

Why not spend an extra 20% after solving it the first time to automate the solution for next time?

If I even use the script once more, I will have saved at least 20% of the effort and can move onto solving bigger problems.

Working at Being Lazy

Instead of just “getting it done and moving on”, I ask:

Can I do the work now to be lazy later.

I back track the steps I took to see if I can create a script for what I just did. If a script is possible, setup scripts for the process.

When there are scripts, those can be part of vagrant’s provisioning. when it’s part of vagrant’s provisioning, I can always have it as part of my ‘clean dev’ environment!

When I have to revisit that piece of software again, I would just look at the scripts I have (or even the vagrant box) and just run them.

Voila - all setup!

That’s how much effort I put into “being lazy”.

Automating: postgres

Today, I will describe the script I use to add postgres to my development setup.

Below is the script I have:

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/usr/bin/env bash

echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -

apt-get update

apt-get install -y postgresql libpq-dev

su - postgres -c "createuser vagrant -s"
echo -e "local\tall\tpostgres\t\ttrust\nlocal\tall\tall\t\ttrust\nhost\tall\tall\t127.0.0.1/32\ttrust\nhost\tall\tall\t::1/128\ttrust" > /etc/postgresql/$(ls /etc/postgresql | head)/main/pg_hba.conf

systemctl restart postgresql.service

Configure postgres Repositories

The first two lines sets up postgres repositories into Ubuntu/Debian. The Ubuntu version is fine, I want to install different version of postgres to match production versions or even install multiple versions of postgres at once.

echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -

These are the standard commands to add a new source repository to Debian based systems. These are the specific URLs for postgres’ repository.

lsb_release ?

I use lsb_release as part of the repository detail. It’s a command that gets the “codename” of a Linux distribution.

If you’re curious, I write about lsb_release in more depth here.

Install postgres!

The next lines do the heavy lifting of:

  • updating repository data (remember, we added a new repository just for postgres)
  • actually install postgres
apt-get update

apt-get install -y postgresql libpq-dev

While installing just postgresql would be sufficient, as I’m making a developer machine, I usually need libpq-dev in the application. I save a line by having this here.

Configure local permissions

I always get stuck on postgres’ permission method, especially through a vagrant system as the user is not “me”, or I am “vagrant”.

It doesn’t help that postgres’ user system is a little different. I always have to lookup how to do it. I’m not a database admin, I just need the database to store things for my app.

To solve this, I basically just configure postgres to grant the local vagrant user full access to any database.

su - postgres -c "createuser vagrant -s"
echo -e "local\tall\tpostgres\t\ttrust\nlocal\tall\tall\t\ttrust\nhost\tall\tall\t127.0.0.1/32\ttrust\nhost\tall\tall\t::1/128\ttrust" > /etc/postgresql/$(ls /etc/postgresql | head)/main/pg_hba.conf

The last line it’s creating a minimal version of postgres’ permission file with full access to local users.

Restart and Profit!

After all of this, restart the postgres instance, especially for the permissions to take effect. Otherwise, you’ll just be wondering why your application can’t create database tables.

Conclusion

This is a quick overview of how I setup postgres on every developer system I work with.

I automate it because:

  • I’m not a database admin
  • I hate looking up same things over and over again
  • I like consistency, especially with the database!

Most importantly, I am lazy and I want to get things done. I believe this is a happy medium: spend time now to create a script and being lazy in the future.