00:00:08.179
First of all, I want to say thank you to Andy Moissan, who invited Cameron to become a speaker. If you remember, one of our values, one of our commandments at Pivorak is to help recruit speakers. So, Andrey has been a great speaker, and Cameron has been an active member of the Ruby community for almost 10 years. He worked at Twitter, authored a number of Ruby gems, and still maintains Scuttle. He has spoken at many conferences, including RailsConf and RubyConf. As I know, he got married two years ago; he has a cat and a baby. During this current time, he’s been having wonderful adventures in the kitchen and even bakes pretzels. Today, he promised to show us how, with almost no configuration, you can leverage Kubernetes to deploy your Rails app. So, let's give a warm welcome to Cameron Dutro from California!
00:01:14.950
Cameron, let’s check the audience and launch the poll before you start.
00:01:26.270
Hey everybody, can you all hear me? Yep, okay, awesome! Let me share my screen here. Can everybody see my presentation? Okay, great! Thank you so much for inviting me to speak. It’s quite an honor to present alongside such pillars of the Ruby community, like Jeremy and Lucca, who are legends. I feel like a nobody compared to them, so thank you for having me at the conference.
00:01:42.630
I’ll just wait for this poll to finish up, but my project in comparison to Hanami and Ruby on Rails is a bit different. My project isn't quite finished yet; it’s kind of rough, and I need your help. I’m hoping to get your attention on how we can use Kubernetes to deploy Ruby applications. I do have a lot of the setup working, but it’s a big problem, and half of my job today is to hopefully convince you that helping out with this project is a good idea. I just got the poll results back, and it seems like most people are still deploying their Rails applications on bare metal, directly on a server. Additionally, it appears that 67% of you do not have experience running or deploying on Kubernetes. That’s no problem at all; we’re going to discuss how you can leverage these awesome technologies at your company or for your projects.
00:02:25.230
As mentioned earlier, I just had a baby, which is one reason why my open-source contributions have kind of tapered off a bit. She's a handful! I don’t speak Ukrainian, but I do have my Twitter profile in Cyrillic characters. I’m Cameron Dutro, and I work on the platform engineering team at Lumos Labs. I’ll be there for a little bit longer before moving on to a company owned by Salesforce called Quip. This is kind of my last week at Lumos Labs. Previously, I was at Twitter. This is me with my wife at a Giants game. I live in the San Francisco Bay Area, and I have a cat named Chester. We just had a baby named Ramona, who is about six months old now and growing all the time. I thought I’d include two of my favorite pictures of her because she can be quite the funny little character.
00:03:09.650
Let’s dive into the talk. Based on the questions from the other panelists and the poll, I know that most people—about 95%—are using Rails in some capacity, whether that be at their company or in side projects, or both. We know that Rails is awesome; a lot of people in the Ruby community understand that Rails is easy for beginners. Spinning up a Rails app and running migrations is super easy. It has excellent tools for database interaction in the form of Active Record, and there are a bunch of other tools, like ROM, that make working with databases in Ruby really easy. Rails allows for rapid application prototyping, making it easy to get your application off the ground, and many have demonstrated how quickly they can move with Rails.
00:04:19.230
One of the greatest things about Rails is that there’s a proper place for every file in your application: models, controllers, views, and you can even put additional code in the Lib directory. Furthermore, Rails has numerous generators for plugins that you might want to use, like Devise, and an extensive collection of gems that solve nearly every problem you might encounter in your application. Rails also boasts an amazing community, making it a truly incredible framework—something a lot of us agree on. Some of us have been using Rails for about ten years and still enjoy it immensely. However, there are some significant challenges with Rails that I want to address. When deploying your application, you've worked on your app, enjoyed the process, and then you come to deploy and realize Rails doesn’t provide much help in that area. There aren’t many tutorials about deploying Rails applications; there’s no standard location where every Rails developer knows to deploy to, and although many use Heroku, it carries its own problems.
00:05:28.710
Heroku is great, but it becomes expensive if you want to scale up. You could deploy on a bare metal EC2 instance with Capistrano, but for a beginner, that can be challenging to set up. You could use an EC2 instance with Chef, Puppet, or Ansible, but again, if you're a beginner, these are not easy tools to grasp. Setting up an EC2 instance requires additional configuration and networking considerations that can be overwhelming for a newcomer. A really nice hosted solution might be Beanstalk or Cloud 66, which are easy and smooth to use, but they are not free. There exists a sort of chasm in the Rails deployment story where this process is not well understood.
00:06:49.960
This talk is inspired by episode 403 of the Ruby Rogues podcast titled "Rails Needs Active Deployment," featuring Stefan Vin Tamiya from Germany, who addresses this issue. He shared that in his experience, deployment is something that normal Rails users struggle with; it's a significant pain to set up a deployment system for a Rails application, and there’s not much out there to make it easier. He believes many companies and new developers get lost along the process. Everything else in Rails is made easy, yet that incredibly important last step of deploying your application to production remains complicated.
00:08:09.220
From this, I've determined that there's a lack of tooling and tutorials, as well as a lack of collaboration within the Rails community regarding deployment. There are so many options available, some paid, some free, and as I mentioned, some are hosted solutions, while others are just libraries. However, for most newcomers, unless you're a seasoned DevOps professional, it’s unclear how to proceed and what path to take. This contrasts sharply with the rest of Rails, which champions 'convention over configuration.' For instance, you can readily access the database due to solutions already in place, but when it comes to deployment, you’ll find none built-in, leaving it up to you to figure it all out.
00:09:40.570
I want to outline some solution criteria that I consider important if we’re going to build a deployment tool for Rails applications. First of all, the experience provided by Heroku is just fantastic, so any solution we come up with as a community should be as smooth and easy to use. The solution should also be tightly integrated with Rails, utilizing Rails conventions while possibly adding new standards to make deployment straightforward. For example, using SSL or TLS certificates. Additionally, I believe convention over configuration is one of the greatest aspects of Rails that we ought to adopt for a deployment solution. It should also be open source, just like Rails. A hosted solution could be fine for some, but I believe it should be a tool anyone can use without needing to set up an account; they should be able to just install the gem and be good to go.
00:10:53.190
Moreover, the solution should work in any environment. By this, I mean being able to deploy your code on any cloud service provider—be it DigitalOcean, Linode, or EKS. I envision a tech stack that involves Docker to package your application, deploying it onto Kubernetes, and then some deployment tool or gem to facilitate this process. Today, I’d like to introduce Kuby, which aims to fulfill this vision. Kuby automates many of the painful aspects tied to Kubernetes deployments.
00:11:51.720
Docker is commonly thought of as a containerization format, providing a package around your code, dependencies, and libraries. It ensures that the environment your app runs in is consistent everywhere. You can define your application along with its dependencies in the Dockerfile, which eliminates issues like ‘it works on my machine’ that usually frustrate developers. Images created from a Dockerfile can be pushed to a registry, allowing for easy deployment regardless of the machine or environment, which is the beauty of using Docker.
00:12:22.680
Now, Kubernetes excels because it’s designed for managing those containers, enabling you to handle infrastructure as a series of configuration files. While managing infrastructure through YAML files can be a downside, the power lies in being able to declare how you want your application and services to run and have the tool manage that for you. Kubernetes automatically handles the scaling of resources, restarts containers if they stop, and provides seamless networking and routing between those containers.
00:13:14.260
Utilizing Docker and Kubernetes streamlines the deployment pipeline. Docker lets you package your applications and their dependencies once and run them almost anywhere, thus eliminating many issues around installation. This rapid deployment approach translates into quicker task execution and scaling, and due to its industry standards, Docker is compatible across various platforms and cloud services. All this culminates in a more manageable and efficient application development flow.
00:14:27.230
So let’s now dive a bit into why Kubernetes is essential. Similar to how Ruby is used to execute scripts, Kubernetes runs containers created from Docker images. While you could run applications without Kubernetes, it enhances your deployments by managing them—dealing with scaling, configuration, and networking. Kubernetes is robust, resilient, and allows for scaling up or down according to traffic needs while enabling easier resource management across the board.
00:15:56.540
However, Kubernetes isn’t without its challenges. The configuration files can be overwhelming, especially for beginners. The documentation can be quite dense and complicated, which can pose a significant barrier for those less familiar with the terminology. Additionally, while there’s an increasing number of resources for Kubernetes, there still seems to be a dearth of comprehensive guides for deploying Rails applications specifically.
00:17:25.150
I want to show you an example of how daunting Kubernetes can be for newcomers. I have a configuration for a sample Rails app generated by my tool; it features complex YAML configurations that can overwhelm someone without experience in Kubernetes. Upon first glance, it could easily lead to frustration as you may feel unequipped to manage everything that is required.
00:18:06.650
To address these complexities, I've been working on a project named Kuby— a combination of Kubernetes and Ruby. Kuby is designed to fulfill many of the solutions criteria I discussed earlier. It simplifies the deployment process so Rails developers can leverage Kubernetes without needing extensive configurations. It automatically generates a Dockerfile for you, follows Rails conventions to streamline various setups, manages secrets from your credentials file, and allows you to easily stand up a database.
00:19:41.620
Kuby integrates with tools like Let’s Encrypt for automatic TLS certificate retrieval. All this means that without nearly any configuration, you can stand up a Rails application quickly, just like you would with Heroku, but with the flexibility of deploying it on any provider that supports Kubernetes such as DigitalOcean or Linode.
00:20:25.600
Kuby's extreme ease of use means that you can get started with very little setup. The only thing you need to do is set up a configuration file. For example, you create a Kuby definition file in your Rails app’s config directory, which serves as an initializer. In this block, you detail the Docker configurations—project name, the image’s base operating system, and registry credentials—making it straightforward.
00:21:40.110
You also specify Kubernetes configurations drawn from Kuby's built-in plugins, allowing for a coherent application that can be easily managed. The flexibility provided by Kuby permits simple changes, like switching the Docker base image or changing cloud providers by merely adjusting a few lines of code, ensuring that you aren’t bogged down in complex YAML configuration files.
00:22:58.540
The internal architecture of Kuby is plugin-based with lifecycle events for important actions like before deployment or after configuration. The entire process is managed via Ruby objects, enabling a developer-friendly interface. This simplicity allows you to embed extra functionality into your deployments seamlessly, including features like Redis caching or adding background jobs with tools like Sidekiq.
00:24:11.720
By doing everything in Ruby, it makes the deployment process much smoother for new developers, as they aren’t confined to handling intricate configuration files. My venture into developing Kuby primarily stems from my desire to streamline these processes for Rails developers, enabling them to focus more on building applications rather than wrestling with infrastructure issues.
00:25:50.290
As I mentioned before, I need your help for Kuby to truly thrive. We need several people testing it in diverse environments to ensure it matures. Feedback is crucial to enhance functionality and robustness to make it more widely usable. In conclusion, thank you very much for listening to my presentation and thank you so much for your time.
00:27:01.250
Thank you for that beautiful presentation, Cameron! Kudos for the name of the project; that’s really awesome, and we’re looking forward to the podcast. It would be great to write a similar podcast for Ruby on Rails 101 about Kuby. Now, let’s go to the questions since we don’t have much time left. The first question is, why did you choose to spend your time on Kubernetes instead of Docker Swarm, which gives almost everything you need for deployment? That’s an interesting question.
00:28:22.590
Essentially, I'm not particularly steeped in DevOps, as most of my experience is as an application developer. I haven't used Docker Swarm extensively, but I spoke with a DevOps colleague at Lumos Labs, and they didn't prefer Docker Swarm. As a result, we’ve leaned towards Kubernetes.
00:29:10.990
We don’t have much time for all the questions, so let’s take this last one. When scaling your Rails application, what’s the best way to handle your assets? Should you build them when creating your image or at startup, and how do you address the potential delays and serving them from either Rails or an Nginx container?
00:30:03.100
Currently, my approach is to build the assets into the Docker image where they get served by Rails. While that’s functional, it’s not ideal; I’d love to improve it in the future. I've considered serving them with Nginx through Kubernetes’ ingress feature, which would allow handling assets more effectively,
00:30:50.050
As we wrap up, please remember to visit our GitHub page for Kuby. I really appreciate your support, and I hope you enjoy the after-party. Thank you all for participating in this wonderful event!
