45

I like the idea of modularizing an applications into containers (db, fronted, backed...) However, according to Docker docs "Compose is great for development, testing, and staging environments". The sentence tells nothing about production environment. Thus, I am confused here.

Is it better to use Dockerfile to build production image from scratch and install all LAMP stack (etc.) there? Or is it better to build production environment with docker-compose.yml? Is there any reason (overhead, linking etc.) that Docker doesn't explicitly say that Compose is great for production?

Jens Piegsa
  • 7,399
  • 5
  • 58
  • 106
Lukasz Dynowski
  • 11,169
  • 9
  • 81
  • 124

2 Answers2

57

Really you need to define "production" in your case.
Compose simply starts and stops multiple containers with a single command. It doesn't add anything to the mix you couldn't do with regular docker commands.

If "production" is a single docker host, with all instances and relationships defined, then compose can do that.
But if instead you want multiple hosts and dynamic scaling across the cluster then you are really looking at swarm or another option.

Chris Sainty
  • 9,086
  • 1
  • 26
  • 31
14

Just to extend what @ChrisSainty already mentioned, compose is just an orchestration tool, you can use your own images built with your own Dockerfiles with your compose settings in a single host. But note that it is possible to compose against a swarm cluster as it exposes the same API as a single Docker host.

In my opinion it is an easy way to implement a microservice architecture using containers to tailor services with high efficient availability. In addition to that I recommend checking this official documentation on good practices on using compose in production environments.

Rogério Peixoto
  • 2,176
  • 2
  • 23
  • 31