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.