[wgjordan]

> 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`.

[justinsaccount]

I am asking how one would safely upgrade the service that nginx is proxying to, not how to restart nginx.

[icedchai]

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...

[justinsaccount]

So I need to write some code to keep track of which of A or B is running, then something else to template out a nginx configuration to switch between the two. Then I need to figure out how to upgrade the inactive one, test it, flip the port over in nginx, and flip it back if it breaks.

Or

kubectl apply -f app.yaml

Which is less complex?

[yongjik]

Depends on what's inside app.yaml, no?

At minimum it requires good-enough health checks so that k8s can detect if the new config doesn't work, and automatically rollback, otherwise you're looking at "no downtime except when there's a mistake" situation.

...and to really check that the health check and everything else in your .yaml file actually works, you will probably have to spin up another instance just so that you can verify your config, unless you like debugging broken configs on live. Well, of course you can always fix your mistake and go "kubectl reaplce -f", but that kinda goes against the requirement of "no downtime".

I grant that k8s makes it easier to spin up a new instance for testing.

[icedchai]

I'm pretty sure I could write a shell script to do that, with a bunch of grep/sed hackery in under an hour or two. For a single server, personal project, this is probably the simpler approach for me.

[Aeolun]

sudo apt-get upgrade?

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

[justinsaccount]

The new version fails to restart properly. Your site is now down. You upgraded the package so now you no longer have the old version on disk and can't easily start the previous version.

Let's not pretend that blindly upgrading a package is the same thing as safely rolling out the new version of a service.