4 ms·

If you're only containerizing a Ruby application and nginx, I don't really see how containers are much better than old school Capistrano-style rsync deployment.

by wrs 11y ago

If you're only containerizing a Ruby application and nginx, I don't really see how containers are much better than old school Capistrano-style rsync deployment. (How often does your nginx version change, after all?) At the cost of an awful lot of additional tooling and somewhat unstable infrastructure. For our simple Ruby workers, we just use Puppet to set up app server VMs with Ruby and nginx. Deployment consists of updating the Ruby code directory. It's pretty much cloud provider independent, as long as your provider can make a Linux VM, and it works fine, just like it did in 2010. :)

MaxGabriel 11y ago
There's also the version of Ruby to consider. Switching to a tool like rbenv can require changing existing scripts (and iirc it felt like it was always more for development), and Ubuntu has removed tools like ruby-switch in Ubuntu 14.
tra3 11y ago
I find this attitude interesting. By the same reasoning why are .debs better than building from source, and the ultimate - horse drawn buggies vs automobiles. I've seen containerized applications described as "statically linked apps", it's one blob with dependencies included. I'm moving in that direction (vs cap-style deployments) because it guarantees that all machines are identical (from QA to staging, to production). Spinning up additional machines becomes trivial.
- wrs 11y ago
  Containers add their own considerable complexity to the stack. If the dependencies are complicated enough, or you need fast scaling/reconfiguration on the fly, then containers can certainly be a net positive. But if you're adding Docker, Compose, DCHQ, and whatever else to your stack just so you can put Nginx and some Ruby code in a container, I'm questioning whether that ends up being a net benefit over Puppet/Chef + rsync.
  - tra3 11y ago
    I hear you. I like the idea of "deploying" a pre-built image. Capistrano "just-in-time" deployments (particularly deployment time "bundle") seem a little non-deterministic. Docker is certainly non-trivial though, but I think (I hope), it's a net win. Time will show. In my mind, it certainly parallels the binary package (debian) vs build-on-demand package (arch? OS X brew) approach. Both seem to work, but I certainly prefer the debs.
    - brady8 11y ago
      That's where Ansible + Capistrano can work together nicely. No need to change your application or deviate significantly from a "vanilla" Ubuntu install - just add your nginx, Passenger configs to Ansible, build the server, and then deploy with Capistrano.

by wrs 11y ago

MaxGabriel 11y ago

There's also the version of Ruby to consider. Switching to a tool like rbenv can require changing existing scripts (and iirc it felt like it was always more for development), and Ubuntu has removed tools like ruby-switch in Ubuntu 14.

tra3 11y ago

I find this attitude interesting. By the same reasoning why are .debs better than building from source, and the ultimate - horse drawn buggies vs automobiles. I've seen containerized applications described as "statically linked apps", it's one blob with dependencies included. I'm moving in that direction (vs cap-style deployments) because it guarantees that all machines are identical (from QA to staging, to production). Spinning up additional machines becomes trivial.

wrs 11y ago
Containers add their own considerable complexity to the stack. If the dependencies are complicated enough, or you need fast scaling/reconfiguration on the fly, then containers can certainly be a net positive. But if you're adding Docker, Compose, DCHQ, and whatever else to your stack just so you can put Nginx and some Ruby code in a container, I'm questioning whether that ends up being a net benefit over Puppet/Chef + rsync.
- tra3 11y ago
  I hear you. I like the idea of "deploying" a pre-built image. Capistrano "just-in-time" deployments (particularly deployment time "bundle") seem a little non-deterministic. Docker is certainly non-trivial though, but I think (I hope), it's a net win. Time will show. In my mind, it certainly parallels the binary package (debian) vs build-on-demand package (arch? OS X brew) approach. Both seem to work, but I certainly prefer the debs.
  - brady8 11y ago
    That's where Ansible + Capistrano can work together nicely. No need to change your application or deviate significantly from a "vanilla" Ubuntu install - just add your nginx, Passenger configs to Ansible, build the server, and then deploy with Capistrano.