10 ms·

I haven't heard of using docker compose for production development, only local development. In production I normally see people building production images and s

I haven't heard of using docker compose for production development, only local development. In production I normally see people building production images and spinning up them up in their cloud with Terraform and whatever other infrastructure they need, especially for databases where your local MySQL container isn't going to be configured or provisioned like an AWS RDS instance. What do you hand a docker-compose file off to in production? Swarm? When would you choose this path over a separate system to provision your production resources (like Terraform)?

namdnay 5y ago
Same here, docker compose is a great little tool for local development. You can get your apps up and running with their respective elasticsearches and localstacks etc, then attach to process if needed to debug For anything more serious, Terraform makes much more sense IMHO
ensignavenger 5y ago
Docker Swarm is one option, but Docker Desktop has the ability to deploy from a Compose file directly to AWS. There are additional tools for other platforms. See https://aws.amazon.com/blogs/containers/deploy-applications-on-amazon-ecs-using-docker-compose/ https://aws.amazon.com/blogs/containers/deploy-applications-... for example.
cs02rm0 5y ago
I don't think you would in prod, unless you were happy with it all running on one host. Shame really, I find compose simple and neat and k8s+terraform an unsettling mess.
- 411111111111111 5y ago
  Docker swarm deploys to multiple hosts and there is also kompose for k8s. I haven't used either of them in production though
- walleeee 5y ago
  The single host model is really pretty common Personal or small/medium business sites, research software, free web utilities What's considered lean in startupland can get pretty beefy compared to the shoestring a lot of projects are compelled by necessity to get by on Compose can be great if you just need a web server and maybe a database and background worker and you don't have anybody suing you or losing millions for the occasional maintenance hour
  - cs02rm0 5y ago
    Totally agree, wasn't slating the idea at all, simplicity wins out nearly every time for me. It is an argument I've lost with managers more times than I've won though.
- PeterisP 5y ago
  A single powerful host can run a quite large business; you might put two identical instances of that host behind a loadbalancer to reduce downtime due failures or upgrades/deployments, and for a single pair of hosts complex orchestration is IMHO overkill, you can just manually run the deploy on one host, wait for it to start working properly, and then upgrade the other.
- ransom1538 5y ago
  "I don't think you would in prod, unless you were happy with it all running on one host." 1) create a VM, set it up with docker compose to auto start -- have it reference code on a network drive. 2) take a an image of 1) 3) create a load balancer, balancing that image. GCP load balancers/instance groups even a way to rollout images. That is %80 of k8s right there (endpoint, scaling, containers, rollouts).
- yjftsjthsd-h 5y ago
  ...am I the only one having ansible deploy compose across machines?
  - lehoule 5y ago
    Oh man I’m currently looking into doing exactly that. Can you elaborate a little bit on how it works?
symlinkk 5y ago
Why would you NOT choose this path? Local and prod are the same with this method, that’s a big advantage.
osrec 5y ago
We use docker compose in production, but have our own custom tooling based around it. K8s was a little too complex and docker swarm a little too simple. Rolling our own solution was a last resort, but it worked out well in the end - more control, deeper understanding and no nasty surprises in behaviour while scaling etc.
- dariusj18 5y ago
  I found that Hashicorp Nomad fit really well in between k8s and swarm for power to complexity. I ended up not being able to use it because they hadn't implemented the networking stuff that they eventually got, but it's pretty cool stuff.
  - vergessenmir 5y ago
    I second this. Nomad is a nice middle. Like the post above I've built tools to fill that gap. What I don't understand sometimes is why there aren't many more orchestration tools in the ecosystem. Some tools emerge; work and then somewhere along the line get kubernetes feature envy and never quite get there. My home setup is now k3s.
nickjj 5y ago
OP here. A lot of my clients are happily using Docker Compose in production. Some even run a million dollar / year businesses on a single $40 / month server. It doesn't get handed off to Swarm or another service, it's literally docker-compose up --remove-orphans -d with a few lines of shell scripting to do things like pull the new image beforehand. You can still use Terraform to set up your infrastructure, Docker Compose ends up being something you run on your server once it's been provisioned. Whether or not you decide to use a managed database service is up to you, both scenarios work. The blog post and video even cover how you can use a local DB in development but a managed DB in production using the same docker-compose.yml file, in the end all you have to do is configure 1 environment variable to configure your database at the app level with any web framework.
- merb 5y ago
  how do you handle no downtime deployments? how do you backup data? I rather would use kompose+kustomize to convert it to k8s and than use k3s with ingress-nginx with hostPath and backup local volumes with velero.
  - mamcx 5y ago
    You don't always need "no downtime deployments", few minutes are tolerated in many environments (I work in enterprise software, where it could be days!). Backups? You only need backups or the Db, and that have zero impact in the use of docker or not* *ie: I know what very complex setups the micro-service crow use for serve their smalls-size disruptive app. I still think cron + pg_dump + rsync is more than enough...
    - merb 5y ago
      well I'm asking because I have a docker-compose file and I use kustomize+kompose on it, because volume backup is a thing and the file comes from an upstream vendor and we can actually miss a few minutes/hours/days of uptime, but since the databases also use compose and sadly in a way that I can't remove it (migrate.sh script that makes use of compose commands), else I can use my kustomize+kompose setup which basically replaces the kustomize+kompose with a custom init container that I built, however everytime they change their shell scripts I need to fix my stuff... but they say that I should just backup my whole volume/vm via lvm snapshots or via vmware whatever. which I find a little bit akward and I do not want to backup my data with disk snapshots. another way would be to natively backup stuff via compose, but they use many databases and it's way harder than just use velero.
zmmmmm 5y ago
> What do you hand a docker-compose file off to in production Why hand it off to anything? > When would you choose this path over a separate system to provision your production resources When you have a simple system with modest availability requirements and you don't like unnecessary complexity.
pricechild 5y ago
It's currently in preview, but https://docs.microsoft.com/en-us/azure/app-service/quickstart-multi-container https://docs.microsoft.com/en-us/azure/app-service/quickstar... doesn't look bad.
tingletech 5y ago
AWS elastic beanstalk supports docker compose files
qudat 5y ago
For side projects I generally run docker-compose via docker-machine. One VM with all my images. Works great!
wpietri 5y ago
Terraform and docker-compose can work well together. Terraform to describe the AWS infrastructure, and docker-compose to say what's running on a given VM.
- rualca 5y ago
  Why would you bother using terraform+docker compose in AWS if you already get containerized solutions out-of-the-box with ECS, which is supported as first class citizen with CloudFormation/CDK?
  - DoryMinh 5y ago
    May be he doesn't want to use CloudFormation? It's easier to switch to any other platform and why switching Cloudformation when everything is doing well with Terraform>
    - wpietri 5y ago
      Exactly. My first choice will always be platform-agnostic tooling.
roofwellhams 5y ago
What if you want a simple app on prod? I need to use that crappy ngnix let's encrypt docker to get ssl. Plus I need my app in my self contained docker. So I got 2 Dockers: app and letsencrypt. I'm always having a hard time to deploy that. I'm happy to have 1 machine for this.
cies 5y ago
> In production I normally see people building production images and spinning up them up in their cloud with Terraform and whatever other infrastructure they need I see a stark difference between infra management tool (like Terraform), and deploy tooling. Infra I prefer to describe "declarative", and Terraform helps a lot with that. Deplyments are "imperative" in nature to me: turn on maintenance page, remove cluster X, spin up cluster Y, run migrations, etc. So I find Terraform a bad fit for deployment tooling (please explain if you disagree, I'd like to learn).
KurtMueller 5y ago
The recent update to `docker-compose`, now called `docker compose`, has contexts that let you us the up command to deploy to services like Azure Container Instances or Elastic Container Services. https://docs.docker.com/cloud/aci-compose-features/ https://docs.docker.com/cloud/aci-compose-features/ https://docs.docker.com/cloud/ecs-compose-features/ https://docs.docker.com/cloud/ecs-compose-features/ I haven't (successfully) used ACI to deploy my compose app. I'm hoping somebody else on this thread might have.
- watermelon0 5y ago
  I have played around with docker compose + ECS and it works great for simple use cases. However, I prefer (at least for my needs) AWS CDK because it also supports pushing of the image to remote registry, and spawning other AWS resources, such as databases.
JeremyNT 5y ago
We deploy lots of small apps for internal usage, and we deploy those with docker compose. If your app fits on a single VM, and you don't have k8s, this is incredibly straightforward. It's even "easier" to just use kubernetes to deploy something - but that's if you already have kubernetes! As my org is adopting k8s we are favoring that over docker-compose where applicable, but there's a huge complexity gap between docker-compose and this isn't an overnight transition. I guess you could view docker-compose as a much more accessible stopgap as your team learns how to run the more complex orchestration strategies, or a preferred solution if you have a small number of VMs you want to explicitly configure to run specific services on (where you don't need the scheduler etc).

namdnay 5y ago

Same here, docker compose is a great little tool for local development. You can get your apps up and running with their respective elasticsearches and localstacks etc, then attach to process if needed to debug For anything more serious, Terraform makes much more sense IMHO

ensignavenger 5y ago

Docker Swarm is one option, but Docker Desktop has the ability to deploy from a Compose file directly to AWS. There are additional tools for other platforms. See https://aws.amazon.com/blogs/containers/deploy-applications-on-amazon-ecs-using-docker-compose/ https://aws.amazon.com/blogs/containers/deploy-applications-... for example.

cs02rm0 5y ago

I don't think you would in prod, unless you were happy with it all running on one host. Shame really, I find compose simple and neat and k8s+terraform an unsettling mess.

411111111111111 5y ago
Docker swarm deploys to multiple hosts and there is also kompose for k8s. I haven't used either of them in production though
walleeee 5y ago
The single host model is really pretty common Personal or small/medium business sites, research software, free web utilities What's considered lean in startupland can get pretty beefy compared to the shoestring a lot of projects are compelled by necessity to get by on Compose can be great if you just need a web server and maybe a database and background worker and you don't have anybody suing you or losing millions for the occasional maintenance hour
- cs02rm0 5y ago
  Totally agree, wasn't slating the idea at all, simplicity wins out nearly every time for me. It is an argument I've lost with managers more times than I've won though.
PeterisP 5y ago
A single powerful host can run a quite large business; you might put two identical instances of that host behind a loadbalancer to reduce downtime due failures or upgrades/deployments, and for a single pair of hosts complex orchestration is IMHO overkill, you can just manually run the deploy on one host, wait for it to start working properly, and then upgrade the other.
ransom1538 5y ago
"I don't think you would in prod, unless you were happy with it all running on one host." 1) create a VM, set it up with docker compose to auto start -- have it reference code on a network drive. 2) take a an image of 1) 3) create a load balancer, balancing that image. GCP load balancers/instance groups even a way to rollout images. That is %80 of k8s right there (endpoint, scaling, containers, rollouts).
yjftsjthsd-h 5y ago
...am I the only one having ansible deploy compose across machines?
- lehoule 5y ago
  Oh man I’m currently looking into doing exactly that. Can you elaborate a little bit on how it works?

symlinkk 5y ago

Why would you NOT choose this path? Local and prod are the same with this method, that’s a big advantage.

osrec 5y ago

We use docker compose in production, but have our own custom tooling based around it. K8s was a little too complex and docker swarm a little too simple. Rolling our own solution was a last resort, but it worked out well in the end - more control, deeper understanding and no nasty surprises in behaviour while scaling etc.

dariusj18 5y ago
I found that Hashicorp Nomad fit really well in between k8s and swarm for power to complexity. I ended up not being able to use it because they hadn't implemented the networking stuff that they eventually got, but it's pretty cool stuff.
- vergessenmir 5y ago
  I second this. Nomad is a nice middle. Like the post above I've built tools to fill that gap. What I don't understand sometimes is why there aren't many more orchestration tools in the ecosystem. Some tools emerge; work and then somewhere along the line get kubernetes feature envy and never quite get there. My home setup is now k3s.

nickjj 5y ago

OP here. A lot of my clients are happily using Docker Compose in production. Some even run a million dollar / year businesses on a single $40 / month server. It doesn't get handed off to Swarm or another service, it's literally docker-compose up --remove-orphans -d with a few lines of shell scripting to do things like pull the new image beforehand. You can still use Terraform to set up your infrastructure, Docker Compose ends up being something you run on your server once it's been provisioned. Whether or not you decide to use a managed database service is up to you, both scenarios work. The blog post and video even cover how you can use a local DB in development but a managed DB in production using the same docker-compose.yml file, in the end all you have to do is configure 1 environment variable to configure your database at the app level with any web framework.

merb 5y ago
how do you handle no downtime deployments? how do you backup data? I rather would use kompose+kustomize to convert it to k8s and than use k3s with ingress-nginx with hostPath and backup local volumes with velero.
- mamcx 5y ago
  You don't always need "no downtime deployments", few minutes are tolerated in many environments (I work in enterprise software, where it could be days!). Backups? You only need backups or the Db, and that have zero impact in the use of docker or not* *ie: I know what very complex setups the micro-service crow use for serve their smalls-size disruptive app. I still think cron + pg_dump + rsync is more than enough...
  - merb 5y ago
    well I'm asking because I have a docker-compose file and I use kustomize+kompose on it, because volume backup is a thing and the file comes from an upstream vendor and we can actually miss a few minutes/hours/days of uptime, but since the databases also use compose and sadly in a way that I can't remove it (migrate.sh script that makes use of compose commands), else I can use my kustomize+kompose setup which basically replaces the kustomize+kompose with a custom init container that I built, however everytime they change their shell scripts I need to fix my stuff... but they say that I should just backup my whole volume/vm via lvm snapshots or via vmware whatever. which I find a little bit akward and I do not want to backup my data with disk snapshots. another way would be to natively backup stuff via compose, but they use many databases and it's way harder than just use velero.

zmmmmm 5y ago

> What do you hand a docker-compose file off to in production Why hand it off to anything? > When would you choose this path over a separate system to provision your production resources When you have a simple system with modest availability requirements and you don't like unnecessary complexity.

pricechild 5y ago

It's currently in preview, but https://docs.microsoft.com/en-us/azure/app-service/quickstart-multi-container https://docs.microsoft.com/en-us/azure/app-service/quickstar... doesn't look bad.

tingletech 5y ago

AWS elastic beanstalk supports docker compose files

qudat 5y ago

For side projects I generally run docker-compose via docker-machine. One VM with all my images. Works great!

wpietri 5y ago

Terraform and docker-compose can work well together. Terraform to describe the AWS infrastructure, and docker-compose to say what's running on a given VM.

rualca 5y ago
Why would you bother using terraform+docker compose in AWS if you already get containerized solutions out-of-the-box with ECS, which is supported as first class citizen with CloudFormation/CDK?
- DoryMinh 5y ago
  May be he doesn't want to use CloudFormation? It's easier to switch to any other platform and why switching Cloudformation when everything is doing well with Terraform>
  - wpietri 5y ago
    Exactly. My first choice will always be platform-agnostic tooling.

roofwellhams 5y ago

What if you want a simple app on prod? I need to use that crappy ngnix let's encrypt docker to get ssl. Plus I need my app in my self contained docker. So I got 2 Dockers: app and letsencrypt. I'm always having a hard time to deploy that. I'm happy to have 1 machine for this.

cies 5y ago

> In production I normally see people building production images and spinning up them up in their cloud with Terraform and whatever other infrastructure they need I see a stark difference between infra management tool (like Terraform), and deploy tooling. Infra I prefer to describe "declarative", and Terraform helps a lot with that. Deplyments are "imperative" in nature to me: turn on maintenance page, remove cluster X, spin up cluster Y, run migrations, etc. So I find Terraform a bad fit for deployment tooling (please explain if you disagree, I'd like to learn).

KurtMueller 5y ago

The recent update to `docker-compose`, now called `docker compose`, has contexts that let you us the up command to deploy to services like Azure Container Instances or Elastic Container Services. https://docs.docker.com/cloud/aci-compose-features/ https://docs.docker.com/cloud/aci-compose-features/ https://docs.docker.com/cloud/ecs-compose-features/ https://docs.docker.com/cloud/ecs-compose-features/ I haven't (successfully) used ACI to deploy my compose app. I'm hoping somebody else on this thread might have.

watermelon0 5y ago
I have played around with docker compose + ECS and it works great for simple use cases. However, I prefer (at least for my needs) AWS CDK because it also supports pushing of the image to remote registry, and spawning other AWS resources, such as databases.

JeremyNT 5y ago

We deploy lots of small apps for internal usage, and we deploy those with docker compose. If your app fits on a single VM, and you don't have k8s, this is incredibly straightforward. It's even "easier" to just use kubernetes to deploy something - but that's if you already have kubernetes! As my org is adopting k8s we are favoring that over docker-compose where applicable, but there's a huge complexity gap between docker-compose and this isn't an overnight transition. I guess you could view docker-compose as a much more accessible stopgap as your team learns how to run the more complex orchestration strategies, or a preferred solution if you have a small number of VMs you want to explicitly configure to run specific services on (where you don't need the scheduler etc).