5 ms·

yeah but stuff like that is hard and not solved with compose, you can update your compose but that would result in downtime, so you can either do a/b (blue/gree

by merb 5y ago

yeah but stuff like that is hard and not solved with compose, you can update your compose but that would result in downtime, so you can either do a/b (blue/green) deploys or you somehow reload the content inside the container?! everything that needs special tooling.

aprdm 5y ago
You can have a compose with multiple backend services and an nginx load balancer in it proxing back to it each one, then down/up each each backend service individually when upgrades for example..
- ta988 5y ago
  Which may force you to handle two versions of databases schemes instead of a single migration. This adds complexity and sometimes 1min of down time is more acceptable than that additional work.
  - aprdm 5y ago
    Yeah for sure, but I feel that's a software design problem and not directly related to using docker compose or not, you could have this same issue regardless of how you go about deploying it.
- rualca 5y ago
  > You can have a compose with multiple backend services and an nginx load balancer in it proxing back to it each one, then down/up each each backend service individually when upgrades for example.. Things are way simpler with Docker Swarm. You just run a single ingress controller as a separate stack and route all traffic internally. If you use Traefik as your ingress controller, all you need to do is set labels in your docker compose files and everything just works. There is absolutely no reason or excuse to use docker compose in anything resembling production.
  - simongray 5y ago
    > There is absolutely no reason or excuse to use docker compose in anything resembling production. I work at a university where I make an app meant for maybe a couple of concurrent researchers. Am I seriously supposed to set up Docker Swarm for this or is it OK with you if I run my little setup using Docker-compose on the tiny server that the university has provisioned for me? Seriously, why do so many people on HN have to act like the entire world of software developers is busy making the next Facebook? I'm sure many (most?) people are making tiny things meant for tiny audiences.
    - croon 5y ago
      > Seriously, why do so many people on HN have to act like the entire world of software developers is busy making the next Facebook? I'm sure many (most?) people are making tiny things meant for tiny audiences. I agree generally, but playing devil's advocate for GP, what I think they meant is that swarm can be run on a single node with little downside/complexity and a lot of upside from docker compose. See for example: https://jarredkenny.com/single-node-docker-swarm/ https://jarredkenny.com/single-node-docker-swarm/ https://devopstuto-docker.readthedocs.io/en/latest/docker_swarm/articles/2018/01__2018_10_17/01__2018_10_17.html https://devopstuto-docker.readthedocs.io/en/latest/docker_sw...
      - simongray 5y ago
        Thanks for the links. I was not aware that it could be run on a single node. Still, the benefits are unclear to me. I guess I will research it some more.
        rualca 5y ago
        > Still, the benefits are unclear to me. Manage deployments as stacks, which support history and backtrack deployments. Blue-green deployments. Frankly, it boggles the mind how people put to production devtools that are barely managed to be secure when deployed locally, when alternatives are both simpler to deploy and more capable.

by merb 5y ago

aprdm 5y ago

You can have a compose with multiple backend services and an nginx load balancer in it proxing back to it each one, then down/up each each backend service individually when upgrades for example..

ta988 5y ago
Which may force you to handle two versions of databases schemes instead of a single migration. This adds complexity and sometimes 1min of down time is more acceptable than that additional work.
- aprdm 5y ago
  Yeah for sure, but I feel that's a software design problem and not directly related to using docker compose or not, you could have this same issue regardless of how you go about deploying it.
rualca 5y ago
> You can have a compose with multiple backend services and an nginx load balancer in it proxing back to it each one, then down/up each each backend service individually when upgrades for example.. Things are way simpler with Docker Swarm. You just run a single ingress controller as a separate stack and route all traffic internally. If you use Traefik as your ingress controller, all you need to do is set labels in your docker compose files and everything just works. There is absolutely no reason or excuse to use docker compose in anything resembling production.
- simongray 5y ago
  > There is absolutely no reason or excuse to use docker compose in anything resembling production. I work at a university where I make an app meant for maybe a couple of concurrent researchers. Am I seriously supposed to set up Docker Swarm for this or is it OK with you if I run my little setup using Docker-compose on the tiny server that the university has provisioned for me? Seriously, why do so many people on HN have to act like the entire world of software developers is busy making the next Facebook? I'm sure many (most?) people are making tiny things meant for tiny audiences.
  - croon 5y ago
    > Seriously, why do so many people on HN have to act like the entire world of software developers is busy making the next Facebook? I'm sure many (most?) people are making tiny things meant for tiny audiences. I agree generally, but playing devil's advocate for GP, what I think they meant is that swarm can be run on a single node with little downside/complexity and a lot of upside from docker compose. See for example: https://jarredkenny.com/single-node-docker-swarm/ https://jarredkenny.com/single-node-docker-swarm/ https://devopstuto-docker.readthedocs.io/en/latest/docker_swarm/articles/2018/01__2018_10_17/01__2018_10_17.html https://devopstuto-docker.readthedocs.io/en/latest/docker_sw...
    - simongray 5y ago
      Thanks for the links. I was not aware that it could be run on a single node. Still, the benefits are unclear to me. I guess I will research it some more.
      - rualca 5y ago
        > Still, the benefits are unclear to me. Manage deployments as stacks, which support history and backtrack deployments. Blue-green deployments. Frankly, it boggles the mind how people put to production devtools that are barely managed to be secure when deployed locally, when alternatives are both simpler to deploy and more capable.