5 ms·

Why do you think it isn't simple to host? If you yearn for the simple times, no one is stopping you from just spinning up a VPS with Ruby, Passenger, Nginx and

Why do you think it isn't simple to host? If you yearn for the simple times, no one is stopping you from just spinning up a VPS with Ruby, Passenger, Nginx and your favorite database. Of course the larger your project is, the more hassle, but that's not specific to Rails.

berkes 5y ago
I have been doing this for upwards of 10 Ruby projects for over a decade. It is not simple. Python or Node.Js suffer the same issues, though. Compared to dropping a go-binary or rust build somewhere and firing that up, Rails/Ruby (Rack, Sintra, Rails etc) are a mess. In no particular order, the issues I had to deal with in the last three months: * asset pipelines crashed randomly; turned out the ~2GB build VPS had too little memory to run the asset pipeline. * puma and unicorn and phusion cannot be ran and configgured easily on one server. * rbenv builds are hard to manage. * getting the correct gems on your server is a mess. There is bundler, rbenv, vendored, rubygems.org, gem, Gemfile, Gemfile.lock, ruby-version in gemfile, ruby version .ruby-version, all of which can -and will- conflict at some point. Add to that, that a typical Rails app requires at least redis, postgresql/mysql, quite some lib-x headers to build native gems, and imagemagick etc, and you have a very complex setup. This isn't more complex than your typical Django, Laravel or ExpressJs setup. But it is far more complex than deploying a go, rust, or Java bundle.
- jaredcwhite 5y ago
  This hasn't been my experience at all. Deploying Ruby-based projects in recent years is streamlined and repeatable. The term soup you're throwing out there makes me wonder why you're either overthinking this or not streamlining your own processes.
  - berkes 5y ago
    One cause of the problems is that the servers are handling multiple ruby deamons amongst which some Rails apps. I know things get simpler when you keep "one app/thread - one server". But price-wise that doesn't make sense, especially since many common Rails apps hardly run on a the cheapest VPS (a throttled dual-core 500MB server). If you run ten tiny services, ten servers add up quickly. I also host some larger apps on their own server, some loadbalanced over multiple servers. But throwing 10+ ruby services on a VPS is hard. Especially if you don't want to, or cannot constrain their ruby-versions, app-server, etc. It is hard for the exact same reason why setting up a local env may be hard. I recently had to help a co-worker on an old MacOS machine who broke her entire mac-desktop because she installed RVM because somehow that was in the tutorial for getting the app locally. Anything with a runtime is harder than anything without that runtime. This is too obvious, but does warrant some highlighting. Ruby's runtime is one of the hardest of all runtimes because it comes with so many moving parts. Python is a close second, and on Ubuntu (my main driver) probably worse than Ruby, because fing up Node is fine, but fing up Python can render your machine unusable, unrecoverable so without good understanding of all python things.
- TheRealDunkirk 5y ago
  I've been using Rails for 12 years, over at least a couple dozen apps. I use RVM to manage my environments, and use Capistrano to deploy. I've hosted on full servers, on shared servers, and on Heroku. With the exception of the classic bugaboo of getting the older execjs compiled in different environments, I have never had the sort of problems you say you're having trying to keep gems sorted. In fact, I would have said that was one of the stacks' greatest strengths, to keep that sorted out for you. I guess my takeaway is that RVM > rbenv, but I REALLY don't intend to start a flamewar about it. And please don't try to tell us that a real-world Java web application is simpler than, well, anything. ;-)
  - lenkite 5y ago
    What is complex about a real-world Java web-app ? Asking seriously.
  - KronisLV 5y ago
    > And please don't try to tell us that a real-world Java web application is simpler than, well, anything. ;-) Tongue in cheek, but honestly, that's probably debatable. Under the hood, Java apps (at least in my experience) are Eldritch horrors with hundreds of beans/proxies/servlets/God knows what, needless layers upon layers of abstractions and dangerous amounts of reflection and dynamic behavior, all to launch and initialize a web application in a "simple" manner. I've always seen the exact same horror, be it working with Spring Boot, Spring, JavaEE, Struts, or even something like Dropwizard (though it seemed a bit more sane). Only the microframeworks seemed decent in comparison, something like Vert.X (has a different paradigm, though), or Quarkus/Helidon. But when it comes to running them... well, historically they were still a nightmare, if packaged with .war and relying on certain application servers/JDK versions being present. But packaging them as executable .jar files (think Spring Boot) makes them similarly easy to Go, at least as long as you have the JDK version that you need. You just drop the file in a folder and if you have some configuration (which your Go app would also need in one way or another), you can probably launch it. > I have never had the sort of problems you say you're having trying to keep gems sorted. Ruby suffers from the same problem that Python, Node, PHP and other non-statically compiled technologies suffer from - messing around with dependencies. If i develop on Ruby locally against version X.Y.Z, but only X.Y.W is available on the server due to Debian packaging older versions, then i'll run into problems because of the project refusing to build/run. I've also run into situations where building the native stuff (DB drivers in this case) will fail, for example, when libpq-fe.h headers were missing and pg couldn't been installed, so the gem native extension couldn't build. Also, on Windows, Ruby 2.7 downloaded the sqlite gem with 3 different trojans (Win64.Alien.eg, Win64.Alien.ef, Win32.Agent.xahigh) in the extensions (btreeinfo.dll, memstat.dll, memvfs.dll), as picked up by Kaspersky. No idea how that happened, or whether that could have been a false positive, but i didn't appreciate that much either. That said, i have a folder that has about 112 images of all sorts of software breaking in various ways to date, and the number is only so low because i don't screenshot things on my work computer and not even every small instance of something breaking. In my experience, all of the technologies out there are bad in some ways, it's just about identifying and managing these tradeoffs towards whatever is suitable for your circumstances.
- awestroke 5y ago
  I started prebuilding assets in ci or locally and rsyncing to the server. Much faster and avoids the issues with constrained resources on the vps. Also saves me from installing asset-related gems and node modules on the server. Let me know if interested and I'll share my capistrano setup
  - eashman 5y ago
    I would love to see how you’re doing this. Could help a lot with Docker builds as well.
- duffyjp 5y ago
  I've been doing Rails for about 12 years and at our shop we have it down. `cap production deploy` and it's done. Essentially zero downtime for deploys. Some things I'd note-- * Don't use puma or unicorn. Phusion Passenger and Apache is just fine performance-wise and is much more robust IMO. * To avoid ruby version conflicts use .ruby_version as your sole source of versioning. I use this in all my Gemfiles: `ruby File.read('.ruby-version').strip` * RVM isn't as popular as rbenv but it's amazing and you won't run into the issues you mentioned. It integrates with Capistrano and Passenger+Apache really well. * 2GB might be a bit light for a production app even with light load. We start our new VMs at 8GB and then adjust up or down as makes sense. We still do a single Ubuntu LTS VM for each app rather than anything fancy. Once you've added the stuff you need via apt it just works. Our sysops folks use Ansible playbooks that automate everything so there's no mystery when we need to do an OS upgrade or spin up a new VM.

berkes 5y ago

I have been doing this for upwards of 10 Ruby projects for over a decade. It is not simple. Python or Node.Js suffer the same issues, though. Compared to dropping a go-binary or rust build somewhere and firing that up, Rails/Ruby (Rack, Sintra, Rails etc) are a mess. In no particular order, the issues I had to deal with in the last three months: * asset pipelines crashed randomly; turned out the ~2GB build VPS had too little memory to run the asset pipeline. * puma and unicorn and phusion cannot be ran and configgured easily on one server. * rbenv builds are hard to manage. * getting the correct gems on your server is a mess. There is bundler, rbenv, vendored, rubygems.org, gem, Gemfile, Gemfile.lock, ruby-version in gemfile, ruby version .ruby-version, all of which can -and will- conflict at some point. Add to that, that a typical Rails app requires at least redis, postgresql/mysql, quite some lib-x headers to build native gems, and imagemagick etc, and you have a very complex setup. This isn't more complex than your typical Django, Laravel or ExpressJs setup. But it is far more complex than deploying a go, rust, or Java bundle.

jaredcwhite 5y ago
This hasn't been my experience at all. Deploying Ruby-based projects in recent years is streamlined and repeatable. The term soup you're throwing out there makes me wonder why you're either overthinking this or not streamlining your own processes.
- berkes 5y ago
  One cause of the problems is that the servers are handling multiple ruby deamons amongst which some Rails apps. I know things get simpler when you keep "one app/thread - one server". But price-wise that doesn't make sense, especially since many common Rails apps hardly run on a the cheapest VPS (a throttled dual-core 500MB server). If you run ten tiny services, ten servers add up quickly. I also host some larger apps on their own server, some loadbalanced over multiple servers. But throwing 10+ ruby services on a VPS is hard. Especially if you don't want to, or cannot constrain their ruby-versions, app-server, etc. It is hard for the exact same reason why setting up a local env may be hard. I recently had to help a co-worker on an old MacOS machine who broke her entire mac-desktop because she installed RVM because somehow that was in the tutorial for getting the app locally. Anything with a runtime is harder than anything without that runtime. This is too obvious, but does warrant some highlighting. Ruby's runtime is one of the hardest of all runtimes because it comes with so many moving parts. Python is a close second, and on Ubuntu (my main driver) probably worse than Ruby, because fing up Node is fine, but fing up Python can render your machine unusable, unrecoverable so without good understanding of all python things.
TheRealDunkirk 5y ago
I've been using Rails for 12 years, over at least a couple dozen apps. I use RVM to manage my environments, and use Capistrano to deploy. I've hosted on full servers, on shared servers, and on Heroku. With the exception of the classic bugaboo of getting the older execjs compiled in different environments, I have never had the sort of problems you say you're having trying to keep gems sorted. In fact, I would have said that was one of the stacks' greatest strengths, to keep that sorted out for you. I guess my takeaway is that RVM > rbenv, but I REALLY don't intend to start a flamewar about it. And please don't try to tell us that a real-world Java web application is simpler than, well, anything. ;-)
- lenkite 5y ago
  What is complex about a real-world Java web-app ? Asking seriously.
- KronisLV 5y ago
  > And please don't try to tell us that a real-world Java web application is simpler than, well, anything. ;-) Tongue in cheek, but honestly, that's probably debatable. Under the hood, Java apps (at least in my experience) are Eldritch horrors with hundreds of beans/proxies/servlets/God knows what, needless layers upon layers of abstractions and dangerous amounts of reflection and dynamic behavior, all to launch and initialize a web application in a "simple" manner. I've always seen the exact same horror, be it working with Spring Boot, Spring, JavaEE, Struts, or even something like Dropwizard (though it seemed a bit more sane). Only the microframeworks seemed decent in comparison, something like Vert.X (has a different paradigm, though), or Quarkus/Helidon. But when it comes to running them... well, historically they were still a nightmare, if packaged with .war and relying on certain application servers/JDK versions being present. But packaging them as executable .jar files (think Spring Boot) makes them similarly easy to Go, at least as long as you have the JDK version that you need. You just drop the file in a folder and if you have some configuration (which your Go app would also need in one way or another), you can probably launch it. > I have never had the sort of problems you say you're having trying to keep gems sorted. Ruby suffers from the same problem that Python, Node, PHP and other non-statically compiled technologies suffer from - messing around with dependencies. If i develop on Ruby locally against version X.Y.Z, but only X.Y.W is available on the server due to Debian packaging older versions, then i'll run into problems because of the project refusing to build/run. I've also run into situations where building the native stuff (DB drivers in this case) will fail, for example, when libpq-fe.h headers were missing and pg couldn't been installed, so the gem native extension couldn't build. Also, on Windows, Ruby 2.7 downloaded the sqlite gem with 3 different trojans (Win64.Alien.eg, Win64.Alien.ef, Win32.Agent.xahigh) in the extensions (btreeinfo.dll, memstat.dll, memvfs.dll), as picked up by Kaspersky. No idea how that happened, or whether that could have been a false positive, but i didn't appreciate that much either. That said, i have a folder that has about 112 images of all sorts of software breaking in various ways to date, and the number is only so low because i don't screenshot things on my work computer and not even every small instance of something breaking. In my experience, all of the technologies out there are bad in some ways, it's just about identifying and managing these tradeoffs towards whatever is suitable for your circumstances.
awestroke 5y ago
I started prebuilding assets in ci or locally and rsyncing to the server. Much faster and avoids the issues with constrained resources on the vps. Also saves me from installing asset-related gems and node modules on the server. Let me know if interested and I'll share my capistrano setup
- eashman 5y ago
  I would love to see how you’re doing this. Could help a lot with Docker builds as well.
duffyjp 5y ago
I've been doing Rails for about 12 years and at our shop we have it down. `cap production deploy` and it's done. Essentially zero downtime for deploys. Some things I'd note-- * Don't use puma or unicorn. Phusion Passenger and Apache is just fine performance-wise and is much more robust IMO. * To avoid ruby version conflicts use .ruby_version as your sole source of versioning. I use this in all my Gemfiles: `ruby File.read('.ruby-version').strip` * RVM isn't as popular as rbenv but it's amazing and you won't run into the issues you mentioned. It integrates with Capistrano and Passenger+Apache really well. * 2GB might be a bit light for a production app even with light load. We start our new VMs at 8GB and then adjust up or down as makes sense. We still do a single Ubuntu LTS VM for each app rather than anything fancy. Once you've added the stuff you need via apt it just works. Our sysops folks use Ansible playbooks that automate everything so there's no mystery when we need to do an OS upgrade or spin up a new VM.