You’ve built a Rails app. You want to host it at Digital Ocean, or Linode, or Amazon Web Services.
Shouldn’t this be simple?
So many decisions.
“Deploying Ruby on Rails is easy,” according to the Rails “deploy” page, which presents at least ten ways to run Rails in production. You need to choose one.
The “easiest” setup is:
Phusion Passenger… a module for Nginx and Apache that automatically manages the back end.
But we already have a decision to make: Nginx, or Apache? Is it important?
For “high-end deployments”, which “need more fine-grained control”, the recommendation is different:
… a front-end server like nginx and Apache combined with a proxy relay like HAProxy to a cluster of Unicorns.
Who wouldn’t want to delegate their task to “a cluster of Unicorns?” But what's a “high-end” deployment? Do you have one? “Fine-grained control” of what? Do you need all of these tools?
To save time, you click on the “easiest” option, Phusion Passenger. Up pops a list of enterprise pricing plans. Uh oh. Do you need a credit card, or is the free option good enough?
Choosing “open source” brings up no less than six download options: Which should you choose? Clicking a download option brings up three “integration modes”: Which should you choose?
The choices keep on coming. RVM, rbenv, or chruby? Monit or Upstart? MySQL or PostgreSQL? Then someone brings up Amazon Web Services, and you’re in real trouble.
Have you ever tried setting up something on AWS? There are a billion buttons and settings and new, invented words I don't understand.
You can try to research every decision. Every web server, every tiered architecture, every content-delivery network, every storage service and hosting platform. You can search docs and blogs and recipes, and weigh the significance of every line in every config file. This might be fun for a while, but it will eventually end in mortal terror, when you look up from your huge pile of browser tabs and realize that you’ve been reading for days and your fingernails are longer than you remember and your app is still not deployed and your boss is giving you that nervous smile. It takes years of experience and study to learn every facet of “DevOps”, and you don’t have that kind of time.
Or maybe you’ll grab a recipe instead, and run through the steps as quickly as possible, praying that it will just work and you can get back to your actual job.
You’ll find that many recipes no longer work. Many blog posts are old, and many tools are obsolete. Terms of service have changed, platforms have been upgraded or discontinued. The Capistrano 2 walkthroughs don’t work with Capistrano 3. Recipes written before Rails 4.1 don’t cover the new
secrets.yml file. And so on.
When a recipe does break, you might have no idea how to fix it. Step-by-step walkthroughs are like packaged tours: As long you’re following the guide down the path, all is well. But once you lose sight of the group, you find yourself staggering through foreign alleyways, frantically riffling through guidebooks, trying to translate cryptic phrases like
mkmf.rb can't find header files for ruby at /usr/lib/ruby/include/ruby.h
As you struggle, you’ll ask yourself over and over: Is my problem really this complicated, or did I just choose the wrong tools?
Deployment shouldn’t be a big deal.
Wouldn’t it be great if you could just ship your Rails apps and make it look easy?
If someone asked you to “throw this up on AWS, and try it out this afternoon”, and you knew exactly what to do next and could get it done within the hour?
If a proposal to “automate this server configuration and set up an autoscaling web tier” was routine for you, something you might finish in one afternoon?
If your clients and your boss came to you for answers to the important questions: Do we need a full-time ops engineer to support this app? Do we know what to do if traffic triples overnight? Can you be sure that we won’t lose data?
If you didn’t need to convince “IT” to try out something new because you controlled your personal infrastructure?
If, instead of struggling to maintain a fragile, temporary lash-up of third-party APIs and platform-specific recipes, you could use stable, open-source, vendor-independent Linux tools to solve most deployment problems?
Your personal deployment toolkit.
The secret to becoming a full-stack developer is to sharpen your focus. You don’t need to qualify for a second job in Operations. You don’t need techniques which only make sense at the scale of Netflix, Square, or Shopify. You need to manage your applications, the ones which are practical to operate on your own.
My goal is to show you a small collection of tools and techniques that you could use to deploy, automate, and operate most of your Rails applications. By concentrating on the common cases, taking advantage of established standards and defaults, and ruthlessly eliminating every distraction that we can, we’ll construct a cloud server automation toolkit with as few moving parts as possible, but no fewer.
By keeping your toolkit small, versatile, and free, you’ll get more experience with fewer tools, have an easier time reading, repairing, and customizing your server configurations, and be able to think about the strategy of app deployment instead of being mired in the tactics.