Hacker News new | ask | show | jobs
by falcolas 2817 days ago
You can just drop it in a conf.d folder created by the package install and it would work just fine.

Also we're talking simple projects, and simple projects are typically not distributed; typically don't need to be distributed.

That said, supporting multiple backends with different load balancing algorithms is also pretty simple to write as well.

1 comments

Ok, great... I have a bunch of simple projects like that, one web instance running on a single host.

How do I safely upgrade it without downtime? Ensuring that the new version starts up properly and can receive traffic before sending it requests and stopping the old one?

With k8s: kubectl set image deployment/my-deployment mycontainer=myimage:1.9.1 (or just use kubectl apply -f)

With your nginx config: ????

That moves the goalposts a bit. We've gone from a simple service to a fleet of highly available services on multiple hosts with zero downtime requirements.

At which point, sure, use Kubernetes.

No.. I didn't move the goalposts at all.

Still A single service on a single machine, how do I safely upgrade it?

A rolling deployment in k8s does work the same way on a single host with minikube as it does on a 1000 node cluster, but I'm still just asking about the single host case.

> Still A single service on a single machine, how do I safely upgrade it?

Depending on your OS-package's provided init script (here Ubuntu), it's as simple as `service nginx reload`, (`service nginx upgrade` if upgrading nginx itself).

Or skip the init script entirely with `/usr/sbin/nginx -s reload`.

I am asking how one would safely upgrade the service that nginx is proxying to, not how to restart nginx.
You could do "blue-green" deployments with port numbers... service rev A is on port 1001, service rev B is on port 1002... deploy new rev... change nginx config to point to 1002... roll back, you repoint to 1001...
sudo apt-get upgrade?

Lets not make it more difficult than it has to be.