13 ms·

foreach serviceX.servers as server { ssh user@ip "cd service-x-project-dir && git pull && ./deploy.sh && service serviceX reload" } there u go. As for SDN, why

by ki_ 4y ago

foreach serviceX.servers as server { ssh user@ip "cd service-x-project-dir && git pull && ./deploy.sh && service serviceX reload" } there u go. As for SDN, why do u even need that? Some simple scripts that manage your server count and their configurations over ssh is all u need.

ok123456 4y ago
This also works.
arinlen 4y ago
> foreach serviceX.servers as server { ssh user@ip "cd service-x-project-dir && git pull && ./deploy.sh && service serviceX reload" } Do you honestly think this sort of thing, hand-waving included, is a better alternative to $ kubectl apply -k <kustomize script> I mean, what are your plans to react to one of your serviceX crapping out? How do you know? How do you recover? How do you roll back? Do you expect to throw more of your ad hoc shell scripts to the mix? Your example is as good as presenting your deployment strategy as $ load ""
- ki_ 4y ago
  Software is not really random. Mostly, they all fail or none of them fail. But in case only 1 server has a problem. You'd just use a script that removes that server from your load balancer so you can inspect it, fix it, etc.. I dont do rollbacks. If you deploy code that bugs out, you already failed. Because clearly the coders & reviewers did NOT understand the code. Proper testing helps also. And if doom day comes, just deploy a previous commit. It's pretty much the same as what u do with kubernetes. That being said. Kubernetes is indeed much easier for this. It all comes down to: "do you actually know what you are doing?". If you know what you are doing, all these problems dont happen. If you feel it's important to be able to spin up new servers from scratch every time you deploy. i guess kubernetes is great for that. it's not for me. As for being able to know what is happening, i do understand that can be impossible sometimes in large companies. Too many developers, too much code. Still, it shouldnt be used as an execuse for breaking the live servers.
  - arinlen 4y ago
    > Software is not really random. Software fails in unforeseen ways, as the goal is for it to not fail but fails anyway. I'm not sure what point you tried to make > Mostly, they all fail or none of them fail. No, not really. There is a reason why one of the very basic deployment techniques is to add health checks for each and every service, run a blue-green deployment, and only switch to the new deployment when each and every single health check points to a successful deployment. The pseudo-code example fails to even do the most basic checks. Hell, even Ansible supports those.

by ki_ 4y ago

ok123456 4y ago

This also works.

arinlen 4y ago

> foreach serviceX.servers as server { ssh user@ip "cd service-x-project-dir && git pull && ./deploy.sh && service serviceX reload" } Do you honestly think this sort of thing, hand-waving included, is a better alternative to $ kubectl apply -k <kustomize script> I mean, what are your plans to react to one of your serviceX crapping out? How do you know? How do you recover? How do you roll back? Do you expect to throw more of your ad hoc shell scripts to the mix? Your example is as good as presenting your deployment strategy as $ load ""

ki_ 4y ago
Software is not really random. Mostly, they all fail or none of them fail. But in case only 1 server has a problem. You'd just use a script that removes that server from your load balancer so you can inspect it, fix it, etc.. I dont do rollbacks. If you deploy code that bugs out, you already failed. Because clearly the coders & reviewers did NOT understand the code. Proper testing helps also. And if doom day comes, just deploy a previous commit. It's pretty much the same as what u do with kubernetes. That being said. Kubernetes is indeed much easier for this. It all comes down to: "do you actually know what you are doing?". If you know what you are doing, all these problems dont happen. If you feel it's important to be able to spin up new servers from scratch every time you deploy. i guess kubernetes is great for that. it's not for me. As for being able to know what is happening, i do understand that can be impossible sometimes in large companies. Too many developers, too much code. Still, it shouldnt be used as an execuse for breaking the live servers.
- arinlen 4y ago
  > Software is not really random. Software fails in unforeseen ways, as the goal is for it to not fail but fails anyway. I'm not sure what point you tried to make > Mostly, they all fail or none of them fail. No, not really. There is a reason why one of the very basic deployment techniques is to add health checks for each and every service, run a blue-green deployment, and only switch to the new deployment when each and every single health check points to a successful deployment. The pseudo-code example fails to even do the most basic checks. Hell, even Ansible supports those.