3 ms·

To update an app container to a new version I just run Ansible again: - docker_container: image: foo/bar:latest state: started rest

To update an app container to a new version I just run Ansible again: - docker_container: image: foo/bar:latest state: started restart_policy: always pull: yes This pulls the new version and restarts the container. The downtime is probably a second maximum. It's small enough that it is not worth the trouble of a rolling release or whatnot. It's a personal project after all, no one will complain for getting a 502 once a month :) I do not use docker-compose as I never felt the need to and I read on multiple occasions that it's meant for development only.

ngrilly 8y ago
Thanks for answering! That's obviously a lot easier as is :-) I have some projects that run on a single machine, but serve multiple requests per second, and it happens we deploy multiple times per day, so we can't afford a 1 second downtime (users would notice).
leandot 8y ago
Many services do not tolerate any downtimes, imagine you are processing money and you kill the process in the middle, it can be quite the pain to recover.
- nicolaslem 8y ago
  The article and my comments are about personal side projects, not about running a business. For me this means cutting down on complexity: 80% of the features for 20% of the work. Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully. I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.
  - ngrilly 8y ago
    You may have side projects which are for a small business or a non-profit, and yet requires being able to sustain multiple requests per second on a single machine. In such a setup, zero downtime deployments are necessary. Some (most) application are being able to gracefully terminate, but it doesn't solve the issue. You still need some mechanism to start the new version, wait for it to be reader, switch the new traffic to the new version, and then gracefully shutdown the old version.
  - leandot 8y ago
    Those are fair points for side projects that have no visitors, but at least for me a side project can also have quite some traffic and then even a little timeout may not be an option. Plus you get a ton of goodies by relying on k8s (or similar) - ability to do an easy rollout, rollback, blue-green deployments, partial rollout, ability to replace multiple containers together if frontend and backend containers must be in sync (a pod) etc. Just my 2 cents.

ngrilly 8y ago

Thanks for answering! That's obviously a lot easier as is :-) I have some projects that run on a single machine, but serve multiple requests per second, and it happens we deploy multiple times per day, so we can't afford a 1 second downtime (users would notice).

leandot 8y ago

Many services do not tolerate any downtimes, imagine you are processing money and you kill the process in the middle, it can be quite the pain to recover.

nicolaslem 8y ago
The article and my comments are about personal side projects, not about running a business. For me this means cutting down on complexity: 80% of the features for 20% of the work. Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully. I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.
- ngrilly 8y ago
  You may have side projects which are for a small business or a non-profit, and yet requires being able to sustain multiple requests per second on a single machine. In such a setup, zero downtime deployments are necessary. Some (most) application are being able to gracefully terminate, but it doesn't solve the issue. You still need some mechanism to start the new version, wait for it to be reader, switch the new traffic to the new version, and then gracefully shutdown the old version.
- leandot 8y ago
  Those are fair points for side projects that have no visitors, but at least for me a side project can also have quite some traffic and then even a little timeout may not be an option. Plus you get a ton of goodies by relying on k8s (or similar) - ability to do an easy rollout, rollback, blue-green deployments, partial rollout, ability to replace multiple containers together if frontend and backend containers must be in sync (a pod) etc. Just my 2 cents.