[HN Gopher] Show HN: Docker rollout - Zero Downtime Deployment f...
___________________________________________________________________
Show HN: Docker rollout - Zero Downtime Deployment for Docker-
compose
docker-compose is great for single node docker deployments, but it
doesn't have a feature that would allow zero downtime deployments.
It's not possible to deploy often if your app goes down every time,
and using Kubernetes/Nomad/Swarm on a single node is an overkill.
I created this Docker plugin to be a drop-in replacement for the
restart command in usual docker-compose deployment scripts. It
performs a simple rolling deployment of a single service.
Author : pankarol
Score : 86 points
Date : 2023-02-07 10:23 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| moglito wrote:
| > Using container orchestration tools like Kubernetes or Nomad is
| usually an overkill for projects that will do fine with a single-
| server Docker Compose setup.
|
| Couldn't agree more! Very nice!
| ThePhysicist wrote:
| Docker compose is great, I use it a lot for local development and
| testing of distributed systems. With a few tweaks you can
| simulate almost anything in containers including systemd and low-
| level networking stuff, which e.g. makes simulating an entire
| Ansible based setup trivial.
|
| Too bad Docker doesn't seem to push this much, with a bit of
| extra work this probably could be the deployment platform for 95
| % of all software systems.
| andix wrote:
| Docker compose is also fine for production environments, if you
| are okay with a few minutes downtime during updates and your
| application is just running on one or two machines. Even 90% of
| the enterprise systems I worked with so far were okay with
| those restrictions.
|
| Sooo much simpler than k8s.
| nickcox wrote:
| FWIW ECS supports rolling updated for docker compose
| deployments: https://docs.docker.com/cloud/ecs-
| integration/#rolling-updat...
| fellowniusmonk wrote:
| I don't understand. Is this common usage or some unique setup
| you've discovered?
| bluehatbrit wrote:
| I think the parent comment is saying that it's a shame Docker
| aren't pushing docker-compose more in general, rather than a
| specific use case. Assuming they are, I have to agree.
| Docker-compose is excellent for so many use cases where
| swarm, nomad, or k8s would be too much but straight docker
| isn't enough. Seeing more investment in compose would be
| fantastic.
| francislavoie wrote:
| Awesome! I might use this.
|
| I think this approach should work fine with
| https://github.com/lucaslorentz/caddy-docker-proxy as well.
| josegonzalez wrote:
| Dokku Maintainer here.
|
| This is pretty neat. One of my gripes about docker-compose - and
| a major why I've been hesitant to add support for it - is that
| the updates are not zero-downtime. That makes it much more
| annoying to use for app deploys as you either have to rewrite the
| compose command as a docker command (defeating part of the
| purpose of a compose file) or accept the downtime during a
| deploy. I'll definitely be including this tool (or something like
| it) with Dokku once I actually add compose support.
|
| Combining this with either Caddy Docker Proxy[1] or Traefik[2]
| could be quite nice for a very simple app deployment system.
|
| Would be super awesome for this functionality to land in the
| official `compose` plugin, but for now this is a great way to dip
| your toes into app deployments without too much overhead.
|
| There is a small island of productivity tools around docker-
| compose that would be super nice to build, and it's nice to see
| something like this land :) -
| https://github.com/lucaslorentz/caddy-docker-proxy -
| https://doc.traefik.io/traefik/providers/docker/
| jskrablin wrote:
| What exactly is the problem with short downtime during
| updates/deployments? A lot of people don't care if their
| deployment requires a few seconds of downtime. And most users
| of $randomwebsite don't really care if they need to hit reload
| button every now and then.
| justinsaccount wrote:
| Zero downtime deployments are just a side effect of doing any
| kind of A/B deployment.
|
| The same features can help you avoid longer downtime. I use
| dokku at home to run a little web portal. I have a CHECKS
| file in the repo that has WAIT=1
| TIMEOUT=1 ATTEMPTS=10 / Portal ...
|
| If I try to update to a new version and the site doesn't come
| up at all (or a GET for / doesn't have "Portal" in the
| response), the update is aborted and requests never fail.
| bionsystem wrote:
| I guess if you have great ambitions about "web scale" and
| client retention, a few seconds downtime on your website
| might mean a loss on a significant amount of potentially new
| customer.
|
| As for me, I actually like downtimes. We have data migrations
| to do anyway on most major updates (they are automatic when
| the new container boots but the app is unavailable), which
| can sometimes take hours, and that leaves us notifying our
| customers for updates and gives us time to do some sanity
| checks before handing them over control.
|
| Compose is a great tool for single (and probably few) VM(s)
| deployments. I used to love swarm for slightly bigger ones as
| well since it's a lot easier to manage than kube and can
| easily be tailored to ones need, still sad it's being
| deprecated.
| josegonzalez wrote:
| Dokku is in use in production by a large number of companies.
| Those companies might setup Dokku on a single, large host -
| perhaps collocated somewhere - and not want to have downtime
| for their product(s). Others host a swarm of Dokku
| installations and also want to avoid downtime during
| deployments.
|
| I suspect that "most users" will actually bounce if a site is
| down for more than a few seconds, or at least become
| frustrated with the availability of the site they are
| accessing.
|
| Aside, I'd rather not field support requests from folks about
| how one of the main features Dokku promotes doesn't work when
| they configure it one way or another.
| brightball wrote:
| It depends on the site.
|
| If there are a lot of users and you need to deploy an update
| during the middle of the day, even a little downtime could be
| disruptive.
|
| If you have a global audience then maybe there's no safe
| "after hours" time to deploy.
|
| Zero downtime deployments are fairly critical for a lot of
| Continuous Delivery / Deployment workflow, so more solutions
| the merrier as far as I'm concerned.
| goodpoint wrote:
| Urgh
| m00dy wrote:
| >> as it's not possible to run multiple containers with the same
| name or port mapping.
|
| I think you can :)
| ciconia wrote:
| FWIW I have discovered a simple technique that solves this
| problem without any additional software: I create two or more
| services that are identical in all but name, so instead of a
| `backend` service I'll have `backend1`, `backend2` etc.
|
| When I need to restart the service, I do it in a staggered
| fashion, first stop and restart `backend1`, wait a few seconds,
| then stop and restart `backend2` etc. I put this in a script,
| works without any problem.
| comprev wrote:
| That's known as a blue-green deployment strategy and has been
| around since deployments began
| m00dy wrote:
| This one has downtime right ?
| pankarol wrote:
| If you restart them one at a time, you always have at least
| one instance running.
| whazor wrote:
| Call them 'blue' and 'green', and you have blue-green
| deployments.
| bobbiechen wrote:
| Unlike the sibling comments, I would call this a rolling
| deployment: you are removing an old host and adding a new one
| at the same time when you restart.
|
| In a blue green deployment I would expect to see you add
| backend3 and backend4 with the updated code, and then rename
| services (or redirect traffic in some other way) to them. The
| difference is, if something goes wrong, backend1 and backend2
| are hot standbys and we can revert the change by redirecting
| traffic back to them.
| hu3 wrote:
| Simple and ingenious. I like it!
|
| Do they use separate ports? Is there a load balancer to point
| to both services?
| intelVISA wrote:
| Isn't that functionality already buried somewhere between Docker
| Stack and Docker Swarm?
| skor wrote:
| yeah, and docker swarm on a single node is not overkill at all.
| plus, don't need to install anything. Sure you have just one
| manager but with one node you don't need to worry about quorum,
| if it goes down then that's that.
| arynda wrote:
| any chance you have a link to a good readme on setting up
| single-node docker swarm?
| skibbityboop wrote:
| 1. Install regular old Docker
|
| 2. Type 'docker swarm init'
|
| 3. There is no 3, you're literally finished and now have a
| full-on Swarm node w/ all features.
| szastamasta wrote:
| Yeah, looks like a "poor man" docker swarm. And I would just go
| with swarm. It's very good. And very easy to move to from
| compose. Too bad k8s won the hype battle here.
| pankarol wrote:
| Swarm has some limitations, I outlined them here:
| https://www.reddit.com/r/docker/comments/10w7pfs/comment/j7l...
|
| I've seen docker compose deployments where the only missing
| part was the ability to replace the container without downtime.
| Swarm would also solve this problem, but it won't always be as
| simple as redeploying the stack in swarm mode, especially if
| you rely on `docker-compose run` in your deployment process.
| skor wrote:
| for the case of docker compose run I do this: have a service
| that runs, does something, then terminates and isn't
| restarted (see docs). We do migrations and other one off
| things with that.
| Cardinal7167 wrote:
| Awesome, I was looking for something just like this the other
| day. I'll be checking this out!
| polyrand wrote:
| I did something similar using git hooks (for Heroku-like
| deployments) and curl for health-checking the app [0]. In my
| case, instead of using replicas, I created multiple services in
| the docker-compose.yaml file. The services are the same but with
| different names (e.g: app1 and app2). Then, during deployment I
| can update only app1, run the health checks, then update app2 if
| everything is ok.
|
| [0]: https://ricardoanderegg.com/posts/git-push-deployments-
| docke...
| esotericimpl wrote:
| [dead]
| jcuenod wrote:
| https://dockerswarm.rocks/
| luckylion wrote:
| > Whenever you read here "Docker Swarm" we are actually talking
| about "Docker Swarm mode".
|
| > Not the deprecated product called "Docker Swarm".
|
| "Hey, Bob, what can we do to confuse people?" - "I don't
| know... hey, did you hear about that Perl 6 thing? That worked
| pretty well!"
|
| I like it though, looks much more hands-on than the
| documentation which often feels just short of being useful.
| sgt wrote:
| They need a rebrand... maybe "Docker Flock". Users will flock
| to it and leave Nomad, k8s etc behind.
| GordonS wrote:
| That's a pretty cool name, I like it!
___________________________________________________________________
(page generated 2023-02-07 23:00 UTC)