7 ms·

I second this, we've been running Docker Compose in production for years and love it. It's massively simplified our production environment, and for a company th

I second this, we've been running Docker Compose in production for years and love it. It's massively simplified our production environment, and for a company that only serves 100,000-1,000,000 monthly hits it's the perfect middle ground. We've tried k8s several times and have always ended up going back because we didn't need the complexity. We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks because we don't need the complexity of swarm and v2.4 provides everything we need. Sometimes simple is best. I personally use compose to manage services on my own laptop and homelab as well, it just has the massive advantage of being the greatest common denominator that everyone can pick up in a few days if they're familiar with basic container concepts.

fredthomsen 6y ago
Couldn't agree more. compose is a wonderful tool that lets you avoid the k8s complexity if you don't need it.
deleted 6y ago
[deleted]
simplecto 6y ago
Exactly this here as well. I have helped setup a few successful SMEs with Docker, Compose, and some CI/CD best practices. They are running 7-figure businesses on the backend.
user5994461 6y ago
>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks... Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case. See various workarounds over the years: https://stackoverflow.com/questions/31746182/docker-compose-wait-for-container-x-before-starting-y https://stackoverflow.com/questions/31746182/docker-compose-... Compose v2.4 was released long ago and abandoned by docker. Some features/workarounds that worked in that version were killed in the next versions. It seems to me that you're stuck on that old version unable to upgrade because of that? IMO this is a perfect illustration of how Docker sucked in practice (both the product and the company), the industry naturally converged into trying to get rid of it because there was no other choice.
- nikisweeting 6y ago
  You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested). Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-versioning/#version-2 https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it) I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.
  - user5994461 6y ago
    Problem being, "depends_on" was removed in version 3, with no replacement in sight. I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall). P.S. For readers who don't have context. Make a basic compose file with a webserver and a database. "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.
    - nickjj 6y ago
      > "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database. Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control. But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'ing into your main container to run tests or migrations). For that I wrote a simple Bash script at https://github.com/nickjj/wait-until https://github.com/nickjj/wait-until. IMO a problem like this can't really be solved at the Docker Compose level. But without such a script you can easily end up with failing CI tests because there's a multi-second but varied amount of delay on upping a database for the first time. That script has become a part of all of my CI / deployment pipelines.

fredthomsen 6y ago

Couldn't agree more. compose is a wonderful tool that lets you avoid the k8s complexity if you don't need it.

deleted 6y ago

[deleted]

simplecto 6y ago

Exactly this here as well. I have helped setup a few successful SMEs with Docker, Compose, and some CI/CD best practices. They are running 7-figure businesses on the backend.

user5994461 6y ago

>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks... Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case. See various workarounds over the years: https://stackoverflow.com/questions/31746182/docker-compose-wait-for-container-x-before-starting-y https://stackoverflow.com/questions/31746182/docker-compose-... Compose v2.4 was released long ago and abandoned by docker. Some features/workarounds that worked in that version were killed in the next versions. It seems to me that you're stuck on that old version unable to upgrade because of that? IMO this is a perfect illustration of how Docker sucked in practice (both the product and the company), the industry naturally converged into trying to get rid of it because there was no other choice.

nikisweeting 6y ago
You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested). Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-versioning/#version-2 https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it) I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.
- user5994461 6y ago
  Problem being, "depends_on" was removed in version 3, with no replacement in sight. I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall). P.S. For readers who don't have context. Make a basic compose file with a webserver and a database. "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.
  - nickjj 6y ago
    > "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database. Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control. But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'ing into your main container to run tests or migrations). For that I wrote a simple Bash script at https://github.com/nickjj/wait-until https://github.com/nickjj/wait-until. IMO a problem like this can't really be solved at the Docker Compose level. But without such a script you can easily end up with failing CI tests because there's a multi-second but varied amount of delay on upping a database for the first time. That script has become a part of all of my CI / deployment pipelines.