 Hi. So, I'm going to talk about how Docker can change Rails deployments, but I wish I could have prepared for how emojis could change Rails deployments. Might have been better. So, my name is Christopher Ergiger. I'm Krigor on Twitter, and I work for Engineered. I'm the support manager for Asia Pacific in Europe, and we make panda balls. This was in our booth at Rails Conf recently, and this is our booth, baby. So, if you want some panda balls, you could have some later. Just approach me. So, how do we currently deploy Rails applications? Last week, I just edited, you know, SSH manually on my server and edited some code and restarted the server. So, kind of, my face was kind of like this. So, please don't do that. So, currently, we use Capistrano. We used this for a long time now, and until now, we still use this. When you create a new release, when you want to deploy your code, you create a new release, and you create a new directory, and then you point current to that. So, that's nothing new. That's the Capistrano way. And you typically do it on your, you know, on your server, on your own VM. So, talking about VMs, this is, for example, your physical server, and then you have your host OS. And then, if you have, you know, servers on Amazon or on digital ocean, you are paying for a VM, then someone else could be using the other VM on the same server. So, going, you know, looking into the VM, it has its own Linux kernel operating system, and then you would put your Rails application on it. So, the current same link earlier, the releases are all inside one VM. So, another look is, you'll have your physical server, you'll have your own OS, and then you'll have your VM, which could have its own OS. Okay, and then another look at the VM, since you have your own Linux kernel, and then the kernel has features like namespace and control group, which actually allows you to build, to start containers, multiple containers inside a VM. So, this is only for, I mean, talking specifically about Linux. So, then it, you know, it becomes like this, you know, you have your physical server, your VMs, and then your containers on top. Then you might be thinking, well, can I have more containers on top of those containers? And then, well, another look at the containers, your set of containers. So, you're not the first to think of that. So, you're still smart. So, they call it Docker reception, Docker in Docker in Docker. You could do that, but I don't see the big use for it, so we won't talk about it. So, again, under VM, if you want to start playing with containers, you could have just one container inside the VM. So, just start with one. And what's the advantage of that? Well, you'll have everything inside a container. So, if, for example, if you want to use a specific Ruby version, you could put it on the container. And then I was just talking to Sam, he said that this course is actually deployed using a container, so a Docker container. So, you put everything inside it and then you could put it on your VM. And what's better is if you want to move it to a different VM, you could just, like, move everything all at once. So, if you have Rails 2.3 in there, or we have a customer who was using Rails 1 until maybe a year ago, you could maybe just stick it on a VM, then just forget about whatever is inside. So, another interesting thing is you could have multiple containers. So, here you could have, you know, a Java application on the same VM. Yeah, on the same VM, but on a different container. Or any applications, really. So, but we're more interested about Rails deployments. So, what you could do is create a container with your new code, but put it, so, instead of putting on a separate directory, you put it on a separate container. So, then your load balancer could just point from the current container to the new one. So, instead of just updating and updating your current VM, you're now creating containers. So, your unit becomes the container instead of those directories. So, what does Docker look like? If you have this Docker file, you could use a base image. Here we're using Ubuntu. And then there are also base images with Ruby, for example, so you don't have to install anything. You could just say from Ruby. But then if you have, so this is from a spree installation, then you could still run up get update on when building your Docker image. So, here you would see that you would run bundle install, which you need when you're running Rails application. And then your command is Rails server. So, to build the image, you just pass different run commands and the same thing. So, you can also use the CMD option. So, why use Docker? Because they have different tools around it. They have Docker Hub. When you create your image, you could save it and retrieve it from Docker Hub. So, it's like GitHub, but for your images. And then you have other tools like Docker machine if you want to provision your VMs and it's not all perfect. You have to worry about logging. So, now that you don't write your file system, where do you log? So, these sort of problems. So, introducing days is a platform that uses Docker. So, if you want to try Docker, but you find the tools that are not enough. So, what's more important here is it uses Git push days master to deploy, which is, yes, this is based from Heroku. So, it's actually like your private Heroku. So, after you Git push days master, days would just handle the containers for you. So, if you want to talk more about duckers and days, have stickers for ducker days. And for underwater Ruby, and RubyConf.ph, so I organized that. So, talk to me about that later on. Thank you.