Hacker News Reader

Comment by bschwindHN | Hacker News Reader

Running Postgres in a container for development environments is one of the best features of Docker in my opinion. It's really not hard to set up at all.

Install docker and docker-compose, write a simple docker-compose.yml file, and then `docker-compose up -d` in the same directory as the docker-compose.yml file. You now have a full Postgres instance running on your machine at localhost:5432. Stop it with `docker compose down`

DB files are stored in the `pg` folder in the same directory as docker-compose.yml. You can specify this on the `volumes` property.

docker-compose.yml:

    version: '2'
    services:
      pg:
        image: postgres:9.4.10
        ports:
          - "5432:5432"
        volumes:
          - $PWD/pg:/var/lib/postgresql/data/pgdata
        environment:
          - PGDATA=/var/lib/postgresql/data/pgdata
          - POSTGRES_DB=YOUR_DB_NAME_HERE
          - POSTGRES_USER=YOUR_DB_USER_NAME_HERE
          - POSTGRES_PASSWORD=YOUR_DB_PASSWORD_HERE

View on HN

Instead of doing all of that, you could also do it without docker. Simply install postgres via your Linux distro and run e.g.:

    /usr/lib/postgresql/9.5/bin/postgres -D .mydatadir

Sure you can do that, but if your app needs to use other services (Redis, for example) you can easily throw that in the compose file as well, and then it's easy to maintain versions and have every developer be on the same page.

This is especially helpful if some developers use OS X or Windows.

I don't understand the "all of that" phrasing, as if what I just described was a large amount of work.

How many people run webwpps with changing version requirements for their _database_?

Docker is useful for running components of your own code or for isolation, not for managing versions of core applications like a database or a mail server for most people deploying ready-made apps.

Different web apps may use differing DB versions, it happens. I'm merely suggesting docker compose is a fairly simple way to handle this without managing global installations on a dev machine. Keep in mind this is for local development only, I wouldn't use a docker hosted DB in production though you certainly could if you wanted to.

I've tried several different dev environment setups and this approach yields the fewest frustrations and inconsistencies.

Production is a different story but that's not what I'm discussing here.

I'm not trying to beat a dead horse here, but what kind of app runs on a database version 5 but not version 6 (for example)?

I can see an app relying on features not available in older releases, but databases - of all software - have rock-solid backwards compatibility.

I mean yeah, changing DB minor versions probably won't affect anything, perhaps even changing major versions is alright in most cases.

To me, the value is in reducing the number of potential issues a developer can have in their environment and making the build and runtime as consistent as possible. And when the solution is so easy to use, I don't see much of a downside to the docker approach.

My team switched from Vagrant to docker compose for our development environments and since then we've had much more stability and have wasted much less time tending to them.

Running a database in Docker is useful if you think more broadly of containers and orchestration, and think less about nodes and more about the cluster as a pool of resources.

All our "system software" — Postgres, Redis, Memcached, RabbitMQ, Elasticsearch, etc. — run as containers on Kubernetes. Doing so allows us to start new versions without considering the host OS. For example, we can upgrade Postgres to a new release the moment it's out, without having to wait for Debian or Ubuntu or whatever.

It also allows us to run different versions (e.g. a new one for testing in our "staging" environment) concurrently without any concerns about which node is running what. In fact, almost nothing needs to be configured with information about "nodes"; everything is routed to the right place, and the client only needs a name to connect to.

Sometimes we start temporary instances of software, e.g. to experiment with. Bring the container up, do the testing, bring container down; nothing ever got installed on the host OS.

Why would I want to use redis?

My whole point is that I want to simplify my setup, so that I don't need tons of third party servers.

Do you reimplement caching and data storage on every new project? Redis is just one example. Surely in any major project you've made use of a third party server? Maybe not, but tons of projects do and I'm simply describing an easy way to manage those services in a development environment. What's so hard to understand about this?

Reply on news.ycombinator.com