Search
Ruby on Rails
Ten Years of Rails Deployment
Edit
#deployment
#capistrano
#ruby-on-rails
#puma
#docker
#continuous-integration-ci
Summarized using AI

Ten Years of Rails Deployment

Christopher Rigor • January 30, 2019 • Earth

Summary of "Ten Years of Rails Deployment"

In this talk at Rails Pacific 2014, Christopher Rigor discusses the evolution of Rails deployment over the last decade. The presentation highlights various deployment strategies, tools, and server technologies, moving from the early days of Rails to contemporary practices. Rigor emphasizes the significance of understanding deployment fundamentals while being introduced to innovative tools and technologies that streamline the deployment process.

Key Points Discussed:

  • Early Deployment Methods:
    • Initially, Ruby web applications utilized mod Ruby, CGI, fast CGI, and WEBrick; none fully met production needs due to performance or architectural limitations.
    • Mongrel emerged as a viable solution, providing better performance, but required complex configurations.
  • Introduction of Passenger:
    • Passenger simplified deployment, allowing developers to manage Ruby applications with ease, and it became the recommended standard.
  • Growth of App Servers:
    • Rigor discusses the release of various app servers, such as Thin, Unicorn, and Puma, highlighting their individual benefits, including better multi-threading and zero downtime deployments.
  • Deployment Simplification:
    • Rigor stresses the importance of Capistrano in streamlining deployment processes, but encourages developers to understand its workings rather than rely solely on it.
  • Configuration Management Tools:
    • The use of tools like Ansible and Chef is mentioned, emphasizing their capabilities in automating server setup and deployment configurations.
  • Containerization with Docker:
    • Docker is presented as a modern solution for deployment, allowing multiple OS-based environments and isolating applications at the container level.
  • Future Considerations:
    • Rigor speculates on emerging technologies and methodologies for deployment, mentioning platforms like Mumia for distributed application management and deployment speed improvements.

Significant Examples and Anecdotes:

  • Rigor shares a humorous yet insightful anecdote about a developer at a bank who must use USB drives to deploy applications due to strict access controls. This emphasizes the importance of deployment processes and security in different environments.

Conclusion and Takeaways:

  • Understanding the fundamentals of deployment is crucial for Ruby on Rails developers.
  • The evolution of deployment tools over the past decade has made the process simpler, but developers should be familiar with their inner workings.
  • Emerging technologies like Docker are paving the way for future deployment strategies.
  • Continuous adaptation and learning of tools and practices are necessary to keep up with the rapidly evolving landscape of web application deployment.

Ten Years of Rails Deployment
Christopher Rigor • January 30, 2019 • Earth

Rails Pacific 2014

00:00:14.519 Hello, Taiwan! I'm excited to be here to give a talk about ten years of Rails deployment. First of all, I'd like to thank the organizers for inviting me to this conference. It has been amazing so far, and I heard there's barbecue and beer tonight, so I'm looking forward to that as well.
00:00:41.000 So, who here has used Capistrano to deploy their applications? Thank you! Almost everyone. My talk is almost done now. Just kidding! I'm actually going to do a demo, but not using Capistrano. I'll show a simpler way to demonstrate deployment.
00:01:09.360 Let me go to my terminal. I wasn't sure if I'll have internet access, but I decided to show you how we might deploy an application. I looked at real-specific.com, and I thought I could deploy something to their servers. Organizers, could I have the password? Maybe one, two, three, four. Okay, let me try this. I think I'm in. Have you guys updated your bash?
00:02:35.959 Okay, I know HTML, so don't do this. Just saying. Whoa! I think I just hacked into Source Hack. That PNG has to be closed properly. So, here's the site. Let's see if it works. Yeah, don't try this at home. We should not be evil.
00:03:27.000 Now, let's go back to my presentation. I've shown you what I believe are the basics of deployment: you need to get your code to the server, which is the first step. Before Rails, when I was doing web development, I used CPanel. I'm not sure if you've heard of that, but it was terrible. You would upload your code using a web-based interface.
00:04:30.240 I eventually moved on to FTP, but I didn't realize it wasn't secure. Thankfully, that's no longer the case; the problem is already solved. We're using a version control system while developing, so we should use that to get our code to the server.
00:05:20.080 Ten years ago, in July 2004, Rails 0.5 was released. This year marks the 10th anniversary of Rails, and back then, we had a few options for deploying Ruby web applications. We had mod Ruby, CGI, and FastCGI. Mod Ruby is an Apache module, so you could only use it with the Apache web server.
00:06:31.920 You could run your Ruby code inside the Apache process with just a few lines of config, allowing you to serve Ruby requests easily. However, it had issues; for example, you couldn't run multiple apps on the same server because there was only one Ruby interpreter for each Apache process.
00:07:55.839 CGI was a standard to run dynamic pages, and it was used by languages like Perl and PHP. However, the problem was that the app was reloaded on every request, causing significant slowdowns. FastCGI was an improvement in which the process remains running, eliminating the overhead of starting the application on every request. This was the most viable option in 2004.
00:09:09.960 Rails was extracted from a live application, Basecamp, which had used FastCGI for a long time. Webrick was another server you may be familiar with; it's not really used in production but can handle small loads. I found a post from 2003 by a guy named David discussing memory consumption with mod Ruby. He noted that it consumed 30 to 35 MB per Apache process for a small web app.
00:10:08.600 Someone else commented that their processes used only 8 to 10 MB, which seems quite different. In 2006, the major development was the release of Mongrel, a separate app server. Unlike CGI and FastCGI, which were built into the web server, Mongrel ran as a separate process and was much faster.
00:11:04.040 However, Rails was not thread-safe at that time, and the typical setup was to run multiple Mongrels for concurrency. Users had to write their own configurations, which added complexity. In 2008, Thin emerged as a separate app server that used an event machine, offering some performance improvements.
00:12:18.120 Then came the announcement of mod Rails, which became Passenger. It aimed for the simplicity of deployment similar to PHP. Passengers allowed you to start a cluster of Mongrels without manual monitoring and configuration, effectively becoming the new standard for Rails deployment.
00:13:29.199 However, shared hosting presented challenges; oftentimes, it didn't work well with Rails due to the way FastCGI was set up. The passenger solved many of these problems, making deployment much easier and ensuring that Rails could function more effectively in shared hosting environments.
00:14:47.360 In 2009, Unicorn was released—a standalone app server similar to Mongrel but more powerful. It grouped multiple workers and introduced zero downtime deployment, allowing you to start new workers before shutting down old ones.
00:15:32.560 The infrastructure surrounding these app servers has improved, and as a result, deploying applications has evolved significantly. Even though Passenger was the initial solution, Unicorn provided better deployment flexibility.
00:16:38.480 In 2011, Puma was released, supporting multiple threads per worker, enabling you to run more concurrent requests with lower memory consumption compared to multiple processes. Various setups have emerged using either threads or processes, depending on specific application needs and resource constraints.
00:17:48.760 As new developments continued in the app server ecosystem, Passenger 4 was released with major improvements. Similar improvements were seen in Puma 2, with the ability to run multiple workers and threads efficiently.
00:18:42.480 After 2013, the landscape of deployment options has continued to grow, with additional considerations for thread safety and application performance. Various app servers have emerged as viable alternatives for different setups based on the application footprint and requirements.
00:20:11.919 I previously touched on JRuby. It's worth noting that JRuby deployments can leverage JVM capabilities, allowing us to use Java app servers. Containers, which have gained traction with technologies like Docker, allow for flexible deployments, enabling isolated environments for applications.
00:21:00.840 These containers improve deployment practices by allowing code and dependencies to reside in separate environments while enabling quick rollbacks and upgrades. Accessing different tools, like Ansible for automation, can streamline deployment processes, making them easier to manage and adapt over time.
00:23:00.599 Let's discuss Capistrano briefly. While I'll not dive into details on how it works, it's essential to understand what it's doing. At its core, deployment generally revolves around transferring code to the server and restarting the application. If you know these basics, you can use various tools to facilitate deployments.
00:24:04.760 I’ve encountered developers who can't access remote servers due to security policies, which complicates deployment processes. For instance, I learned about one developer who had to hand over code on a USB drive for security reviews before deploying, emphasizing the importance of understanding your deployment pipeline.
00:25:31.120 When deploying, you also need to ensure Ruby and other prerequisites are in place. Setting up servers can often involve package and dependency management. Therefore, having clarity on how your server is set up is critical, especially if you encounter further complications.
00:26:28.160 Among the current trends, Docker brings exciting developments for application deployments. It allows for the use of containers that isolate application dependencies, providing an advantage when upgrading the Ruby environment without affecting other running applications.
00:27:25.680 This style of deployment can help mitigate issues that arise during upgrades, allowing rollback to previous versions seamlessly. It's important to remember and evaluate various deployment setups as technology continues to evolve.
00:28:31.160 For more complex scenarios, solutions like M Mia are available that cater to unique bottlenecks in deployment across expansive server environments. These solutions innovate with technologies to connect to multiple servers efficiently and swiftly.
00:29:35.480 As we look to the future, understanding the various configurations and options for deployment can greatly enhance the flexibility and speed of delivering applications into production.
00:30:19.440 Thank you for attending my talk on ten years of Rails deployment.
Christopher Rigor
@crigor
Explore all talks recorded at Rails Pacific 2014
+2