00:00:11.650
Hey, we're about to begin. It's good to see that the room is not overbooked, so no one's getting dragged in. Welcome to the Engine Yard sponsored talk: 'Deep Dive into Docker Containers for Rails Developers.' That's quite a mouthful.
00:00:25.880
Let’s take a look at the title, 'Deep Dive.' It relates to me and my wife scuba diving in the Philippines, where we are advanced open water certified. The underwater scenery is beautiful, and as you dive deeper, it becomes even more stunning. In this talk, we're going to discuss Docker containers.
00:00:45.440
Who among you has used Docker before? It's good to see more than half of you have. Now, who among us has used another container but not Docker? Okay, we have a couple. This is not an introductory Docker talk, but we will look into container internals specifically for Rails developers.
00:01:06.289
What are containers made of? I have to be specific that this talk is for Rails developers. A few years back, I heard that Phoenix was gaining popularity, and I was concerned there would be a lot of jokes about it. You have probably heard a lot of jokes already, right? Some guests are organizers, and people have moved on to other languages or frameworks, which is fine. However, we are here to declare that we still use Rails, and many still do!
00:01:39.189
This talk is sponsored by Engine Yard, where I work. We are celebrating our 10th anniversary this year. Please join us tonight for a party at 7:00 p.m. We also have a booth tomorrow and on Thursday. Engine Yard provides a great way to run your Rails applications, allowing easy scaling from one to hundreds of servers. We have a decade of Ruby on Rails optimizations on top of AWS, and we offer top-notch 24/7 support.
00:02:15.499
But let’s get into the talk. These are the topics we’re going to cover: the reasons for using containers, what containers are made of, and how to run containers in production. There are many uses for containers, but our focus will be specifically on deploying your Rails apps in a container.
00:02:53.930
I remember when I started with Ruby in 2006; one of the most popular deployment tools back then was Capistrano, and we still use the Capistrano way of doing things at Engine Yard. We have deployed numerous Rails applications using Capistrano successfully. However, I want to discuss why you should consider putting your Rails app in a container.
00:03:32.390
With the traditional channel, you SSH into a server, perform a Git clone, install the gems, compile your assets, and possibly run migrations. This process works well, and we have big apps that use this approach. However, a small issue arises when GitHub goes down: no one would be able to deploy. This isn’t a complaint against GitHub; it's a great service. However, when they experience downtime, many of our customers face deployment issues.
00:04:31.690
This exemplifies a small reason why you should adopt containers. Let's consider what's involved when using a container. You still need to install Ruby, install packages, copy code, and install gems. It’s somewhat similar to Capistrano, albeit not a silver bullet to eliminate these steps. However, once you have that container, your server only needs to know how to run that container, regardless of what’s inside.
00:05:52.050
You can run your container with other containers. For example, if you have another Rails app or even something like Redis or a database, it can all run on the same server. Though our DBAs recommend against running databases in containers, it is technically possible. The key is ensuring your host knows how to run whatever is inside the container, enabling easy scaling.
00:06:59.610
Containers start faster and allow for running any code, which makes the deployment process quicker. Your developers can release updates faster, allowing you to focus on your business problems. But what exactly are containers? There are a few explanations I often hear during discussions about containers.
00:07:42.780
First, they are often described as lightweight VMs. Many don’t favor this description since technically, a container is not a virtual machine. In a VM, you may run a different OS from the host, but a container is inherently limited to the OS of the host. However, I find the 'lightweight VM' description suitable because a container can encapsulate everything you need, such as including Ruby and necessary packages.
00:08:57.110
Another way to describe containers is 'features on steroids.' For example, having a dedicated directory can effectively serve as your new root. By changing the routes, you can achieve sophisticated results. I have an Ubuntu 17.04 setup, where the directory structures are similar to those on your Linux machines. Here’s a quick demonstration of running within different subdirectories and checking the root structure in them.
00:10:21.580
As I navigate through various subdirectories, you will see that although they share the same kernel, different routes allow for unique configurations. It’s all about utilizing namespaces and control groups, which are kernel features that create an environment that makes your processes think they are isolated.
00:11:37.920
Namespaces, for example, help with process isolation, so when a process runs inside a namespace, it perceives it’s on a separate system. Similarly, other container runtimes, such as LXC, have been popular, providing many advantages while utilizing these namespaces behind the scenes.
00:12:26.490
As I work within an Ubuntu 17.04 environment, you'll notice that I can view and manage the processes running inside that environment without affecting host processes. Creating a namespace allows processes to exist separately, and it's crucial that containers cannot interfere with host processes for security reasons.
00:13:59.670
Next, let’s talk about mounted namespaces. When you create a mounted namespace, you inherit all the mount points of your host. However, if you make changes, those do not affect the host system. This is important because if a container has access to the host's disk, it could potentially corrupt it, which would cause issues for all containers running on that host.
00:15:44.670
We also have user namespaces, a relatively new feature added to Docker, which prevents users inside the container from running with root privileges on the host. This adds an extra layer of security since running as root inside a container could lead to vulnerabilities regarding host system control.
00:16:53.070
Now, let's examine the network namespace. In the context of a container, you will utilize separate networking interfaces, creating a bridge on the host to facilitate networking. These namespaces help to maintain isolated communication protocols between containers, thus avoiding potential security breaches or data mishaps.
00:18:21.600
Let’s take a look at Cgroups. Cgroups are crucial for limiting resource usage such as memory and CPU for each container. They were developed to restrict maximum workloads for processes and prevent resource exhaustion. For today's purposes, I will demonstrate setting a memory limit for a Rails app.
00:19:31.650
As we go about creating namespaces, we’ll generate Cgroups to set those limits. I will configure my Rails applications to define how many resources it can utilize, providing a secure and efficient framework for operations. As I increase the resource limit, you’ll see how various processes can initiate within that controlled environment.
00:20:51.000
In conclusion, while containers allow you to run many processes as isolated units, security measures must be implemented to safeguard your applications. Utilizing multiple security layers, ranging from AppArmor to controlling user capabilities, ensures a strong defense against potential threats in production.
00:22:33.030
Additionally, the use of seccomp allows for the filtering of system calls for enhanced security. It’s essential to research what to restrict and clarify system calls based on the security understanding built on years of experience.
00:23:24.090
Lastly, if you're considering running containers in production, I encourage you to use container runtimes such as Docker or Rocket. They will handle the orchestration of namespaces and Cgroups efficiently. However, having a robust orchestration system like Kubernetes is invaluable, especially for managing multi-container deployments.
00:24:09.700
In essence, while it’s exciting to explore namespaces and Cgroups, it’s vital to utilize established container runtimes rather than attempting to orchestrate these independently. The safety, reliability, and efficiency gained from using well-documented container technologies significantly outweigh the manual configuration.
00:25:43.000
By adapting to these modern container orchestrations, you will streamline your deployment processes, enhance your team’s productivity, and utilize a proven structure for your applications. So, in closing, consider deploying your Rails applications within a containerized environment.
00:27:11.000
Containers have matured significantly over the years, with multiple organizations leveraging them. However, running databases in containers is still in early discussions and should be approached with caution until they are further standardized.