Comment by exac
17 hours ago
Sorry, there is zero chance I will ever deploy new code by changing a symlink to point to the new directory.
17 hours ago
Sorry, there is zero chance I will ever deploy new code by changing a symlink to point to the new directory.
I don't do devops/sysadmin anymore, so this would have been before the age of k8s for everything. But I once interviewed for a company hiring specifically because their deployment process lasted hours, and rollbacks even longer.
In the interview when they were describing this problem, I asked why the didn't just put all of the new release in a new dir, and use symlinks to roll forward and backwards as needed. They kind of froze and looked at each other and all had the same 'aha' moment. I ended up not being interested in taking the job, but they still made sure to thank me for the idea which I thought was nice.
Not that I'm a genius or anything, it's something I'd done previously for years, and I'm sure I learned it from someone else who'd been doing it for years. It's a very valid deployment mechanism IMO, of course depending on your architecture.
Why? What do you prefer to do instead?
Anything less than an entire new k8s cluster and switching over is just amateur hour obviously
Isn't that the standard way to do that? Why wouldn't you?
why? it works and its super clever. Simple command instead some shit written in JS with docker trash
Ah, the memories of capistrano, complete with zero-downtime unicorn handover
https://github.com/capistrano/capistrano/
Still use php deployer each day and works with symlinks as well. https://deployer.org/
Works pretty well for Nix
Worked pretty well in production systems, serving huge amount of RPS (like ~5-10k/s) running on a LAMP stack monolith in five different geographical regions.
Just git branch (one branch per region because of compliance requirements) -> branch creates "tar.gz" with predefined name -> automated system downloads the new "tar.gz", checks release date, revision, etc. -> new symlink & php (serverles!!!) graceful restart and ka-b00m.
Rollbacks worked by pointing back to the old dir & restart.
Worked like a charm :-)
And for Stow[1] before it, and for its inspiration Depot[2] before even that. It’s an old idea.
[1] https://www.gnu.org/software/stow/
[2] http://ftp.gregor.com/download/dgregor/depot.pdf
I really liked stow. My toy distro back in the day was based on it.
that's how some phone OSes update the system (by having 2 read only fs)
that's how Chrome updates itself, but without the symlink part
No snapshotting at all? Thinking about it.. The filesystem does not support it I suppose.
Android does use snapshots: https://source.android.com/docs/core/ota/virtual_ab
1 reply →
not surprised about the chrome part, but pretty shocked at the phone OS part. I know APFS migration was done in this way, but wouldn't storage considerations for this be massive?
what would be more massive would be phones not booting up because of a botched update. this way you can just switch back to the old partition
Not really, because only the OS core is swapped in this way. Apps and data live in their own partitions/subvolumes, which are mutable and shared between OS versions.
The OS core is deployed as a single unit and is a few GB in size, pretty small when internal storage is into the hundreds of GB.
Then you are locking yourself out of a pretty much ironclad (and extremely cost-effective) way of managing such things.
Nobody's saying you should deploy code with this, but symlinks are a very common filesystem locking method.