[Benjamin_Dobell]

- 1 webserver/proxy, let's say nginx

- 1 simple Rest API server, let's say in flask

Dokku - https://github.com/progrium/dokku

Can't really beat `git push deploy/uat`

- 1 database, let's say PostgreSQL

I just run PostgreSQL on the host and connect to it from the containers. Sure I could containerise PostgreSQL itself but I don't really see the point.

I then run my own Dokku plugin (dokku-graduate: https://github.com/glassechidna/dokku-graduate) for graduating my apps from UAT to production.

[istvan__]

This is exactly the problem here, just run Postgres on the host means that you have a hybrid setup, some of your services dockerized the rest are not. This is not appealing to some people. There are other services mostly in the heavy disk IO space that is not easy to move to Docker. It might be worth to call these out in the documents and save some time to sysadmins figuring this out the hard way. If you want to dockerize your application like a REST api or a simple Java app, that works perfectly and the advantages are obviously there though.

[Benjamin_Dobell]

I have zero problem with a hybrid setup. I'm not running Docker just for the sake of running Docker.

I'm running Docker (specifically Dokku) because it drastically simplifies deploying new builds, and graduating those builds between environments.

I know a large part of this article was that Docker complicates rather than simplifies the situation. I guess if you're trying to be a Docker purist (for no reason) then sure. The same is generally true if you try be a purist of any kind.

[istvan__]

I think the deployment is the weakest point of the Docker ecosystem.

The reason why I am using Docker is the forced honesty on the environment side, if your app runs on your laptop it does not mean it will run on the production boxes. If the Docker container runs on your laptop it gives you higher confidence that it will run on the production infra. No missing JARs, environment variables, misconfigured classpaths, etc.

[gsharma]

If the goal is to simplify deployment process, why not use something like Capistrano or Fabric? You can run 'Cap deploy <dev|prod>'

[IgorPartola]

Fabric is a great tool at first, but the problem is that it's always procedural. Want a deploy script? Write it. No other way around that.

Something that's more declarative is definitely superior. Why? Because it will be shorter and easier to debug. I am not a fan of `git push` as a deployment strategy (because git is a version control tool, not a deployment tool), but it does force you to create and use a system that's by definition declarative. This is why I use dokku for my new projects.

[Benjamin_Dobell]

Because, as mentioned, I already deploy in one line:

    git push deploy/uat

and I didn't have to write a single deployment script to achieve it.

Plus, by using Dokku I get the benefits of containerised apps.

[simplify]

What are the benefits of containerised apps in your case?

[patsplat]

It's useful to "mount" the database to the app process via injected configuration.

Application and database servers are different animals. Not sure why a 'hybrid' approach would be surprising or unappealing.