3 ms·

Asking about non-container systems on HN is mostly going to get you "you're doing it wrong" responses -- HN people are very driven by blog-sexy tooling and arch

Asking about non-container systems on HN is mostly going to get you "you're doing it wrong" responses -- HN people are very driven by blog-sexy tooling and architectures. If you want to deploy fast you need to skip steps and reduce I/O - stateful things are _good_ -- deploying with rsync/ssh and HUPing services is very fast, but people seem to have lost this as an option in a world with Docker. I consult in this space - first 30m on the phone is free - hmu if interested.

nurettin 6y ago
rsync needs constant attention not to send unwanted artifacts. Git based deployments aren't as fast, but much more robust and controllable with pull requests. Edit: of course this is for source code deployments, not binary output.
- marcosdumay 6y ago
  All the binary deploys I created at work run over git. Honestly both of those are non-issues. Rsync is as much set once and forget as git, you'll need to script both and configure it there. And git slowness is a one time per deployment server issue. The one advantage of git is that it will keep an history of your deployments. Of course, CD tools do that too, but git is way more transparent and reusable. The one disadvantage is that it will make your deploy scripts more complex and stateful.
- mattbillenstein 6y ago
  Yeah, with rsync you get both -- like I can deploy source code (python, et al) and stuff with outputs I don't want to track in git (webpack et al). I can essentially invoke whatever build steps I need to once on a build host - then let rsync handle moving all the changed things to my deployment environments.
bpicolo 6y ago
> If you want to deploy fast you need to skip steps and reduce I/O It's perfectly okay to build your artifacts on a stateful host and then put them into a container as a quick to add layer. A whole lot of work has gone into making applications quicker to build via incremental builds that depend on state, and it's worth taking advantage of. People want to make containers the solution to every problem, and I think that's where the philosophy is hurting. It's okay to not have perfectly hermetic build / developer environments if your tooling is better for it.
MichaelMoser123 6y ago
asking the other way round: did you ever have a problem that you don't quite know how to replicate a given setup? for many tasks it saves you time - instead of having to mess with the host environment one can instead create an isolated environment - and give the docker access to the host file system or network. It takes a time to get used to that mode of working (without automated testing it is very hard); but it does have a lot of advantages.
- mattbillenstein 6y ago
  I use other tools - config management and whatnot I do in Saltstack or Ansible, so the VMs are throw-away really, nothing is configured by hand, it's just that they live longer than the lifetime of a single deploy.

nurettin 6y ago

rsync needs constant attention not to send unwanted artifacts. Git based deployments aren't as fast, but much more robust and controllable with pull requests. Edit: of course this is for source code deployments, not binary output.

marcosdumay 6y ago
All the binary deploys I created at work run over git. Honestly both of those are non-issues. Rsync is as much set once and forget as git, you'll need to script both and configure it there. And git slowness is a one time per deployment server issue. The one advantage of git is that it will keep an history of your deployments. Of course, CD tools do that too, but git is way more transparent and reusable. The one disadvantage is that it will make your deploy scripts more complex and stateful.
mattbillenstein 6y ago
Yeah, with rsync you get both -- like I can deploy source code (python, et al) and stuff with outputs I don't want to track in git (webpack et al). I can essentially invoke whatever build steps I need to once on a build host - then let rsync handle moving all the changed things to my deployment environments.

bpicolo 6y ago

> If you want to deploy fast you need to skip steps and reduce I/O It's perfectly okay to build your artifacts on a stateful host and then put them into a container as a quick to add layer. A whole lot of work has gone into making applications quicker to build via incremental builds that depend on state, and it's worth taking advantage of. People want to make containers the solution to every problem, and I think that's where the philosophy is hurting. It's okay to not have perfectly hermetic build / developer environments if your tooling is better for it.

MichaelMoser123 6y ago

asking the other way round: did you ever have a problem that you don't quite know how to replicate a given setup? for many tasks it saves you time - instead of having to mess with the host environment one can instead create an isolated environment - and give the docker access to the host file system or network. It takes a time to get used to that mode of working (without automated testing it is very hard); but it does have a lot of advantages.

mattbillenstein 6y ago
I use other tools - config management and whatnot I do in Saltstack or Ansible, so the VMs are throw-away really, nothing is configured by hand, it's just that they live longer than the lifetime of a single deploy.