Summarized using AI

Lightning Talk: How Docker Can Change Rails Deployments

Christopher Rigor • June 04, 2015 • Singapore • Lightning Talk

In this lightning talk at the Red Dot Ruby Conference 2015, Christopher Rigor discusses the transformative impact of Docker on the deployment of Rails applications. Traditionally, Rails deployments utilize Capistrano to manage the release process, which involves manually editing server settings via SSH, managing directories, and restarting servers. Rigor outlines the conventional deployment workflow and identifies the limitations associated with using VMs and Capistrano for Rails applications.

Key Points Discussed:
- Current Deployment Practices: Rigor describes the traditional method of deploying Rails applications using Capistrano, highlighting the hassle of managing SSH access and directories.
- Advantages of Docker: He explains how Docker simplifies the deployment process by encapsulating everything needed to run an application within a container, such as the specific Ruby version required.
- Container Advantages: Rigor suggests that running multiple containers on a VM allows for better resource utilization. Each container can run different applications simultaneously without conflicting.
- Docker Deployments: Instead of creating new directories for each release, Docker enables deploying the application in distinct containers, allowing load balancers to easily switch between them, improving efficiency and reducing downtime.
- Building Docker Images: Rigor demonstrates how to use a Dockerfile to create a Docker image by specifying a base image and including necessary commands, which streamlines the setup process for Rails applications.
- Supportive Tools: He discusses the ecosystem surrounding Docker, including Docker Hub for image storage and Docker Compose for managing multiple containers, making it easier to handle applications at scale.
- Challenges with Docker: Despite its advantages, Rigor points out challenges like logging and file system management that come with using Docker.
- Introduction to Day's Platform: He briefly introduces a platform called Days that supports Docker and offers a Heroku-like deployment mechanism using Git, which automates container management.

In conclusion, Christopher emphasizes the potential of Docker to enhance Rails deployments while acknowledging the challenges that come with this transition. The talk serves as an introduction for developers considering Docker as a solution for deploying Rails applications, highlighting both the triumphs and pitfalls of moving away from traditional deployment strategies.

Lightning Talk: How Docker Can Change Rails Deployments
Christopher Rigor • June 04, 2015 • Singapore • Lightning Talk

How Docker Can Change Rails Deployments by Christopher Rigor

A typical Rails deployment involves using a tool like Capistrano to pull the code from your Git repository, symlink configuration files and restart the app server.

Docker offers improvements to this workflow but it's not all roses. Hear about the triumphs and challenges when moving from Capistrano deployments to Docker.

Red Dot Ruby Conference 2015

00:00:19.199 hi um so i'm going to
00:00:22.880 talk about um
00:00:24.320 how darker can change rails deployments
00:00:26.720 but i wish i could have prepared for how
00:00:28.480 emojis could change rails deployments
00:00:30.880 might have been better
00:00:32.719 so my name is christopher rieger i'm
00:00:35.120 krieger on tutor
00:00:37.200 and i work for
00:00:39.040 engineering i'm the support manager for
00:00:40.960 asia pacific and europe
00:00:43.200 and we make panda balls uh this was in
00:00:45.520 our booth at trailsconf recently
00:00:47.840 and this is our booth baby so
00:00:50.719 so if you want some panda balls you
00:00:52.320 could have some later just approach me
00:00:55.120 so uh
00:00:56.320 how do we currently deploy rails
00:00:57.920 applications um
00:00:59.920 last week i just edited you know ssh
00:01:02.719 manually on my server and edited some
00:01:04.960 code and restarted the server so kind of
00:01:07.760 my face was kind of like this so please
00:01:10.320 don't do that so currently we we
00:01:12.880 we use capacity uh
00:01:14.880 we've used this for a long time now and
00:01:17.520 uh until now we still use this uh when
00:01:20.159 you create a new release
00:01:22.000 um when you want to deploy your code you
00:01:23.759 create a new release and um
00:01:27.119 you you create a new directory and then
00:01:29.439 you point current to that so that's
00:01:31.119 nothing new that stuck up is trying away
00:01:33.439 um
00:01:34.720 and you typically do it on your you know
00:01:36.880 on your server on your own vm
00:01:39.119 so talking about vms this is for example
00:01:41.520 your physical server and then you have
00:01:43.280 your host os and then if you have you
00:01:45.759 know servers on amazon or on um
00:01:50.000 digitalocean you are paying for a vm
00:01:53.280 then someone else could be
00:01:55.040 using the other vm on the same server
00:01:58.000 so uh going you know looking into the vm
00:02:00.719 it has its own linux kernel operating
00:02:02.960 system and then you would put your rails
00:02:04.640 application on it so the current
00:02:07.680 sim link earlier the releases are all
00:02:09.759 inside one vm
00:02:12.800 so another look is you'll have your
00:02:14.560 physical server you'll have your own os
00:02:16.720 and then you'll have your vm which could
00:02:18.239 have
00:02:19.040 its own os
00:02:21.760 okay and then another look at the vm
00:02:24.319 since you have your own linux kernel um
00:02:26.480 and then the kernel has features uh
00:02:30.319 like namespace and control group which
00:02:32.400 actually allows you to
00:02:34.480 build
00:02:35.440 to start containers multiple containers
00:02:38.080 inside a vm
00:02:39.440 so um
00:02:41.040 so this is only for uh
00:02:43.840 i mean talking specifically about linux
00:02:47.200 so then it you know
00:02:49.440 it becomes like this you know you have
00:02:50.959 your physical server your vms and then
00:02:53.200 um your containers on top and then you
00:02:55.840 might be thinking well can i have more
00:02:57.920 containers on top of those containers
00:03:00.159 and then well another containers uh
00:03:03.200 their set of containers so uh you're not
00:03:05.360 the first to think of that so you're
00:03:07.599 still smart
00:03:08.800 so they call it docker reception docker
00:03:10.720 and docker in docker you could do that
00:03:13.120 but
00:03:13.840 i don't see the big use for it so we
00:03:15.440 won't talk about it
00:03:16.959 so uh again on the vm if you want to
00:03:20.080 start um playing with containers you
00:03:22.640 could have just one container inside of
00:03:25.200 em so just um
00:03:28.000 just start with one and what's the
00:03:29.760 advantage of that well you'll have
00:03:31.599 everything
00:03:32.640 inside a container so if for example if
00:03:35.200 you want to use the specific ruby
00:03:36.560 version
00:03:38.879 you could put it on on the container and
00:03:40.640 then
00:03:41.599 i was just talking to sam he said that
00:03:45.200 this course is actually
00:03:47.280 deployed using a container so a docker
00:03:49.200 container so you put everything inside
00:03:51.280 it and then you could uh put it on your
00:03:53.519 vm and what's more
00:03:58.560 what's better is if you want to move it
00:04:00.239 to a different vm you could just like
00:04:02.000 move everything all at once so if you
00:04:04.400 have rails two three in there or
00:04:07.360 we have a customer who was using rails
00:04:09.120 one until maybe a year ago you could
00:04:11.200 maybe just stick it on a vm then just
00:04:12.879 forget about what's whatever is inside
00:04:16.239 so
00:04:17.120 another interesting thing is you could
00:04:18.400 have multiple containers so here you
00:04:20.400 could have you know a java application
00:04:22.079 on the same vm
00:04:24.080 yeah on the same vm but on a different
00:04:25.680 container
00:04:26.960 or any applications really so but we're
00:04:29.360 more interested about rails deployments
00:04:31.199 so what could what you could do is
00:04:34.240 um
00:04:35.040 create a container
00:04:36.720 um with your new code but put it
00:04:40.639 so instead of putting on a super
00:04:42.240 separate directory you put it on a
00:04:43.680 separate container so then
00:04:46.320 your load balancer could just point from
00:04:49.199 the current container to the new one so
00:04:51.199 instead of just updating and updating
00:04:52.960 and updating your current vm you're now
00:04:55.040 creating containers so your unit
00:04:57.840 your unit becomes the container instead
00:04:59.520 of those directories
00:05:01.840 so what does docker look like
00:05:03.759 if you have this docker file
00:05:06.080 you could
00:05:07.680 you could
00:05:09.759 use a base image
00:05:11.600 here we're using ubuntu
00:05:14.800 and then there are also base images with
00:05:16.720 ruby for example so you don't have to
00:05:18.320 install anything you could just say from
00:05:20.400 ruby
00:05:22.000 but then if you have so this is from a
00:05:23.759 spree installation then you could still
00:05:25.680 run apt-get update um
00:05:28.880 on on when building your docker image
00:05:32.320 so here you would see that you would run
00:05:34.320 bundle install which you need when
00:05:35.919 you're running rails application and
00:05:37.440 then your command is real server so to
00:05:39.520 build to build the image you just
00:05:42.080 pass um different run commands and and
00:05:45.919 the cmd um
00:05:48.400 option
00:05:50.479 so uh why use docker uh
00:05:52.960 because they have different they have
00:05:54.880 different um
00:05:56.560 tools around it they have docker hub
00:05:58.479 when you create your image you could
00:06:00.080 save it then retrieve it from from
00:06:02.720 docker hub so it's like github but for
00:06:05.759 your images and then you have other
00:06:07.520 tools like docker machine if you want to
00:06:09.199 provision your vms and docker compose
00:06:11.680 for managing multiple containers
00:06:13.759 but it's not all
00:06:15.440 and it's not all perfect you have to
00:06:17.039 worry about logging so now that you you
00:06:19.680 don't write to your file system where do
00:06:21.360 you log um so this sort of uh problems
00:06:25.199 uh
00:06:27.039 so
00:06:28.880 so uh introducing days it's a platform
00:06:30.960 this uses docker so if you want to try
00:06:33.360 to docker but you find the tools that
00:06:35.680 are not um
00:06:37.759 not enough so what's more important here
00:06:40.319 is it uses a git push days master to
00:06:42.639 deploy which is yes this is based from
00:06:44.800 heroku so there is actually like your
00:06:46.880 private heroku so after you get pushed
00:06:49.599 days master
00:06:51.199 days would
00:06:52.400 just handle the containers for you so if
00:06:54.720 you want to talk more about dockers and
00:06:56.720 days uh have stickers for docker days
00:07:00.479 and for underwater ruby and rubyconf ph
00:07:03.280 so i organized that so talk to me about
00:07:05.520 that later on thank you
00:07:20.240 you
Explore all talks recorded at Red Dot Ruby Conference 2015
+18