6 ms·

> 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

> 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 8y ago
I am asking how one would safely upgrade the service that nginx is proxying to, not how to restart nginx.
- icedchai 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
      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 8y ago
  sudo apt-get upgrade? Lets not make it more difficult than it has to be.
  - justinsaccount 8y ago
    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.

justinsaccount 8y ago

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

icedchai 8y ago
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 8y ago
  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 8y ago
    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 8y ago
    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 8y ago
sudo apt-get upgrade? Lets not make it more difficult than it has to be.
- justinsaccount 8y ago
  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.