In the last couple of years, we have seen a lot of development in the devops field. It\u2019s becoming much easier for developers to provision servers and deploy their applications on those servers just with a couple of key strokes. Since the start of the SaaS and PaaS products (even before we knew them as that), we have seen a vast number of companies and communities try to make our lives easier by developing smart tools that will fit into our workflow seamlessly.<\/p>\n
As a side effect, or perhaps intentionally, we\u2019ve also seen the open-source community create tools to not just make the workflow easier but to cut costs and enable us to make great software without thinking about the costs of the hardware.<\/p>\n
Amazon with its huge selection of web services (AWS<\/a>) and the like have made our lives much easier when it comes to incorporating infrastructure and tools in the cloud. Then there are Chef<\/a> and Puppet<\/a> that made provisioning servers a breeze. Then came containerization in the form of Docker<\/a>, although some would argue that containers, or at least the idea around them, existed well before Docker came along.<\/p>\n The newest addition to this collection of tools is Deis<\/a>. This lightweight application platform deploys and scales Twelve-Factor<\/a> apps as Docker containers<\/a> across a cluster of CoreOS<\/a> machines. Deis will wrap a release of your application in a Docker container and deploy it to one (or multiple) machines running on CoreOS.<\/p>\n After that, you will be able to scale, manage, limit, and do much more to your application. Also, because Deis is an application platform, you as an administrator can change and customize the platform itself. It\u2019s basically having your own, self-hosted Heroku<\/a>. The folks at Engine Yard<\/a>, and all the contributors that created Deis, have done a marvelous job.<\/p>\n To get some things straight from the start, this tutorial will be about running a Rails application on Deis. If you haven\u2019t seen the concepts and architecture that powers Deis, I recommend checking out the Understanding Deis<\/a> page. If you do not have Deis installed and would like to follow this tutorial as you read, you can head over to the installation guide<\/a>.<\/p>\n To run Deis smoothly, you\u2019ll need a cluster of servers, three at minimum. Although Deis comes with Vagrantfiles that can provision and install the platform on virtual machines, I strongly recommend using servers in the cloud if you don\u2019t have a very powerful computer. I tried using Vagrant on my MacBook Air 2013, and let\u2019s just say it didn\u2019t go well. For this tutorial, I used AWS, but the documentation has instructions<\/a> on installing Deis on any of the most popular cloud providers.<\/p>\n Before we start, there\u2019s a bit to know about deploying applications on Deis. Any applications or service that can be run inside a Docker container can be deployed to Deis. In order to be scaled horizontally, applications must follow Heroku\u2019s Twelve-Factor methodology<\/a> and store state in external backing services.<\/p>\n This means that data should be written to a database, images should not be persisted to the local filesystem (they should be uploaded to a cloud provider), dependencies should be isolated, logging should be enabled, and so on. By complying to these 12 factors, you can easily scale your application inside Deis on demand.<\/p>\n On the bright side, most modern applications are stateless, have proper logging, and have nicely isolated external services and dependencies. This makes them horizontally scalable inside Deis.<\/p>\n The application that we\u2019ll be using for this tutorial is a sample made by Michael Hartl<\/a>, for his book Ruby On Rails Tutorial (3rd ed)<\/em>. It\u2019s basically a minimal Twitter clone, where users can register, follow other users, and post microposts. Users can also change their profile settings and view their profiles and the profiles of other users on the application.<\/p>\n Deis as a PaaS allows multiple ways of deploying an application.<\/p>\n The first is using buildpacks. These pieces of software are basically scripts that prepare your code for execution by the Deis controller. Buildpacks are useful if you\u2019re interested in following Heroku\u2019s best practices for building applications or if you\u2019re deploying an application that already runs on Heroku. This can make the transition from Heroku to Deis seamless.<\/p>\n Deployment is very easy, just like on Heroku. From the project directory, we need to register a new application on Deis. This is done by running:<\/p>\n You will see an output similar to this:<\/p>\n Note that the URL and the application name might be different in your case. When you run the After creating the application on Deis, the next thing to do is to deploy the application by Git push:<\/p>\n A small disclaimer: Parts of the output have been omitted to save up some space. Also, note that your output might be different. Nevertheless, let\u2019s analyze the output we received from the deploy.<\/p>\n First, we can see that we pushed our code to a git repository. Then, Deis recognized our application as a Rails app and used a buildpack for Ruby on Rails applications. It created our bundle by fetching the required gems for our app from RubyGems<\/a> (the output is omitted to save space).<\/p>\n After it completes the bundle, it changes the The next step is booting the server. Since the sample application does not have a This is where it gets interesting. In the next step, Deis containerizes our application with Docker. The Docker image that it creates is based off of deis\/slugrunner<\/a>. Slugrunner takes a gzipped tarball of a \u201ccompiled\u201d application via stdin or from a URL, letting you run a command in that application environment or start a process defined in the application Procfile.<\/p>\n If you take a look at the logs above, you\u2019ll notice that At the end of the output, we get an informative message with the URL where the application resides, with some other informative links in addition. But if we point our browser to the URL, we\u2019ll get an error. Why, what\u2019s going on?<\/p>\n With the last step, we deployed the application. Although the deploy went smooth, the application is still not working. How can we debug this?<\/p>\n Just like with Heroku, viewing the logs on Deis is really easy. In the application directory, you can run: This will send the last 100 lines of the logs of the application to STDOUT. In the logs, you\u2019ll notice the following lines:<\/p>\n This tells us that Deis tried to boot the application, but it\u2019s missing the Or, in our case, we need to run:<\/p>\n But since we don\u2019t have a database running, we don\u2019t know the database url. Let\u2019s spin up a database instance for this application.<\/p>\n There\u2019s a slight problem with this. At the moment of writing this tutorial, Deis does not have an addon\/plugin system like Heroku\u2019s Add-ons<\/a>. This means that we can use any \u201cdatabase as a service\u201d provider. Another approach is using the official Postgres Docker image<\/a> and deploying it to a Amazon EC2 instance. There\u2019s a plethora of options, but for this blog post we will take a very simple (or lazy, if you will) approach.<\/p>\n We will use Heroku\u2019s Postgres platform<\/a>. The Postgres platform allows us to create a Postgres database with literally two clicks.<\/p>\n When a new database is created, we can grab the database URL from the settings page and add it as an environment variable to our Deis-hosted application:<\/p>\n The whole flow looks just like adding the Postgres plugin to a Heroku application. After the environment variable has been set, you can simply run:<\/p>\n This will execute the migrations, and our application is ready to be used! Head over to Another option supported by Deis is deployment via a Dockerfile. This is a powerful way to define a portable execution environment built on a base OS of your choosing.<\/p>\n A Dockerfile automates the steps for the creation of a Docker image. However, Dockerfiles must conform to some Deis rules:<\/p>\n Since our sample application does not have a Dockerfile that we can use, we need to create one. If you do not know how to build a Dockerfile for your Rails application, check out these two posts:<\/p>\n For this Rails application we will use the following Dockerfile:<\/p>\n The Dockerfile is quite simple; the base image is After that, the Dockerfile will create the If we commit our Dockerfile to the repository and push it to Deis, you\u2019ll notice that Deis will pick up the Dockerfile, and it will not use the Rails buildpack to deploy the application. Instead, Deis will use all of the instructions from the Dockerfile.<\/p>\n This is a neat feature of Deis, because Dockerfiles provide more flexibility to the deployment itself. As you can see, you can do pretty much anything to the base operating system, by changing configurations, exposing ports, installing additional packages, and running any command.<\/p>\n A third option for deploying Rails applications in Deis is using a Docker image. As the documentation states, this is useful for integrating Deis into Docker-based CI\/CD pipelines. This means that you can build the image locally and ship the image wherever you want. Deis can pull the image from both public and private registries.<\/p>\n Let\u2019s build an image using the Dockerfile from the last step. The command to build an image from a Dockerfile is:<\/p>\n In our case, we can run it as:<\/p>\n When Docker finishes building the image, we can push it to DockerHub<\/a> or a private registry:<\/p>\n Since the hard work with the Dockerfile is already done and the image is pushed to DockerHub, we can just ask Deis to pull the image from the registry and deploy it:<\/p>\n Deis makes configuring your applications quite easy. One way that I already mentioned is to set environment variables.<\/p>\n From the command line, you can see all the available commands for modifying environment variables:<\/p>\n When we were attaching the database as a backing service, we used the following command:<\/p>\n As you can see above, Deis even allows you to download all of the environment variables in a Using a custom domain for a Deis app is very easy. You can use the Next, you need to head over to your DNS registrar and set up a CNAME for the new domain to the old one. For example, if the old subdomain for the application was Deis is a super powerful platform, and it\u2019s super configurable. You can do backups and data restores, configure the load balancers, view the logs, monitor the platform with external tools, add SSL to the platform, and so much more. If you want to dig deeper in Deis and see all its customizability and power, I recommend reading the very detailed and helpful documentation<\/a>.<\/p>\nEnter Deis<\/h2>\n
Preparing for Deis<\/h3>\n
Preparing for the application<\/h3>\n
Deploying a Ruby Application on Deis<\/h2>\n
deis create<\/pre>\n
Creating Application... done, created aerial-nonesuch\r\nGit remote deis added\r\nremote available at ssh:\/\/git@deis.mydomain.com:2222\/aerial-nonesuch.git<\/pre>\n
deis create<\/code> command, Deis will not only register a new application, but it will also add a new git remote to your repo with the name deis<\/code>. This is the remote where we will push our code to be deployed. It\u2019s just like Heroku, where the Heroku toolbelt adds a new remote called heroku<\/code>.<\/p>\nsample_app_rails_4 git:(master) git push deis master\r\nCounting objects: 948, done.\r\nDelta compression using up to 4 threads.\r\nCompressing objects: 100% (484\/484), done.\r\nWriting objects: 100% (948\/948), 429.01 KiB | 0 bytes\/s, done.\r\nTotal 948 (delta 428), reused 941 (delta 424)\r\n-----> Ruby app detected\r\n-----> Compiling Ruby\/Rails\r\n-----> Using Ruby version: ruby-2.0.0\r\n-----> Installing dependencies using bundler 1.9.7\r\n Running: bundle install --without development:test --path vendor\/bundle --binstubs vendor\/bundle\/bin -j4 --deployment\r\n Fetching gem metadata from https:\/\/rubygems.org\/...........\r\n Fetching version metadata from https:\/\/rubygems.org\/...\r\n Fetching dependency metadata from https:\/\/rubygems.org\/..\r\n * gems omitted *\r\n Bundle complete! 28 Gemfile dependencies, 51 gems now installed.\r\n Gems in the groups development and test were not installed.\r\n Bundled gems are installed into .\/vendor\/bundle.\r\n Bundle completed (29.38s)\r\n Cleaning up the bundler cache.\r\n-----> Writing config\/database.yml to read from DATABASE_URL\r\n Detected manifest file, assuming assets were compiled locally\r\n\r\n ###### WARNING:\r\n No Procfile detected, using the default web server (webrick)\r\n https:\/\/devcenter.heroku.com\/articles\/ruby-default-web-server\r\n\r\n-----> Discovering process types\r\n Default process types for Ruby -> rake, console, web, worker\r\n-----> Compiled slug size is 26M\r\n\r\n-----> Building Docker image\r\nremote: Sending build context to Docker daemon 28.13 MB\r\nStep 0 : FROM deis\/slugrunner\r\n# Executing 3 build triggers\r\nTrigger 0, RUN mkdir -p \/app\r\nStep 0 : RUN mkdir -p \/app\r\n ---> Using cache\r\nTrigger 1, WORKDIR \/app\r\nStep 0 : WORKDIR \/app\r\n ---> Using cache\r\nTrigger 2, ADD slug.tgz \/app\r\nStep 0 : ADD slug.tgz \/app\r\n ---> 3da1998b04a2\r\nRemoving intermediate container 3286b3de2ee2\r\nStep 1 : ENV GIT_SHA 0f9caa12bf8315633b6ff366e638d29f349c8ee2\r\n ---> Running in 3eb69115c0d9\r\n ---> 475d97558564\r\nRemoving intermediate container 3eb69115c0d9\r\nSuccessfully built 475d97558564\r\n-----> Pushing image to private registry\r\n\r\n-----> Launching...\r\n done, sample:v2 deployed to Deis\r\n\r\n http:\/\/sample.mydomain.com\r\n\r\n To learn more, use `deis help` or visit http:\/\/deis.io\r\n\r\nTo ssh:\/\/git@deis.mydomain.com:2222\/sample.git\r\n * [new branch] master -> master<\/pre>\n
DATABASE_URL<\/code> variable in the config\/database.yml<\/code> file. It basically expects our application to have a database set up. If you haven\u2019t noticed, we still haven\u2019t mentioned anything about a database. We will look into this in a moment.<\/p>\nProcfile<\/code>, it boots our application using Webrick<\/a> by default. If we wanted to boot our application using a different server, we could have added a Procfile<\/code> with the commands needed to boot our app on that particular server.<\/p>\nslugrunner<\/code> first creates the \/app<\/code> path and changes the working directory to it. Then it adds the slug.tgz<\/code> file to \/app<\/code>. With each step, it creates an intermediate container, which it removes at the end. When the container build is finished, slugrunner<\/code> boots up the application.<\/p>\nDebugging and Attaching a Database<\/h2>\n
deis logs -n 100<\/code><\/p>\nsample[web.1]: => Booting WEBrick\r\nsample[web.1]: => Rails 4.0.8 application starting in production on http:\/\/0.0.0.0:5000\r\nsample[web.1]: => Run `rails server -h` for more startup options\r\nsample[web.1]: => Ctrl-C to shutdown server\r\nsample[web.1]: Exiting\r\nsample[web.1]: (erb):9:in `rescue in <main>': Invalid DATABASE_URL (RuntimeError)<\/pre>\n
DATABASE_URL<\/code> environment variable which crashes the application. This means that we just need to add an additional configuration to our Deis application. Adding a new environment variable is done via:<\/p>\ndeis config:set ENV_VAR_NAME=value<\/pre>\n
deis config:set DATABASE_URL=\"some-url-here\"<\/pre>\n
deis config:set DATABASE_URL=\"postgres:\/\/username:password@ec2.compute-1.amazonaws.com:some-port\/dbname\"<\/pre>\n
deis run \"rake db:migrate\"<\/pre>\n
http:\/\/sample.<your-domain-here>.com<\/code> to see the application deployed to your Deis cluster.<\/p>\nDeploying the application using a Dockerfile<\/h3>\n
\n
\n
FROM ruby:2.0\r\n\r\n# Install apt based dependencies required to run Rails as \r\n# well as RubyGems. As the Ruby image itself is based on a \r\n# Debian image, we use apt-get to install those.\r\nRUN apt-get update && apt-get install -y \\ \r\n build-essential \\ \r\n nodejs\r\n\r\n# Configure the main working directory. This is the base \r\n# directory used in any further RUN, COPY, and ENTRYPOINT \r\n# commands.\r\nRUN mkdir -p \/app \r\nWORKDIR \/app\r\n\r\n# Copy the Gemfile as well as the Gemfile.lock and install \r\n# the RubyGems. This is a separate step so the dependencies \r\n# will be cached unless changes to one of those two files \r\n# are made.\r\nCOPY Gemfile Gemfile.lock .\/ \r\nRUN gem install bundler && bundle install --without development test --jobs 20 --retry 5\r\n\r\n# Set environment to production\r\nENV RAILS_ENV production \r\nENV RACK_ENV production\r\n\r\n# Copy the main application.\r\nCOPY . .\/\r\n\r\n# Copy config\/database.yml.prod to config\/database.yml\r\nCOPY config\/database.yml.prod config\/database.yml\r\n\r\n# Precompile Rails assets\r\nRUN bundle exec rake assets:precompile\r\n\r\n# Expose port 3000 to the Docker host, so we can access it \r\n# from the outside.\r\nEXPOSE 3000\r\n\r\n# The main command to run when the container starts. Also \r\n# tell the Rails dev server to bind to all interfaces by \r\n# default.\r\nENTRYPOINT [\"bundle\", \"exec\", \"rails\", \"server\", \"-e\", \"production\"]<\/pre>\n
ruby:2.0<\/code>. Next, we install the build-essential<\/code> package, which is a reference for all the packages needed to compile a Debian package. Then, we install a JavaScript runtime: nodejs<\/code>.<\/p>\n\/app<\/code> directory which will be the home of our application and will change the working directory to it. Then the Gemfile and the Gemfile.lock files are copied, and the bundle is installed. The whole source code is copied to the image, the 3000 port is exposed, and the Rails server is booted.<\/p>\nDeploying the application using a Docker image<\/h3>\n
docker build -t <your-username>\/<image-name> .<\/pre>\n
docker build -t <your-username>\/sample-rails-application .<\/pre>\n
docker push <your-username>\/sample-rails-application<\/pre>\n
deis pull <your-username>\/sample-rails-application:latest<\/pre>\n
Configuring the Application<\/h2>\n
deis help config\r\n\r\nValid commands for config:\r\n\r\nconfig:list list environment variables for an app\r\nconfig:set set environment variables for an app\r\nconfig:unset unset environment variables for an app\r\nconfig:pull extract environment variables to .env\r\nconfig:push set environment variables from .env\r\n\r\nUse 'deis help [command]' to learn more.<\/pre>\n
deis config:set DATABASE_URL=\"some-url-here\"<\/pre>\n
.env<\/code> file, so you can start the application locally with the same configuration.<\/p>\nUse a custom domain<\/h3>\n
deis domains<\/code> command to configure custom domains for an application. Adding a custom domain is done via:<\/p>\ndeis domains:add new-domain.com<\/pre>\n
sample.your-domain.com<\/code>, you need make new-domain.com<\/code> be a CNAME to sample.your-domain.com<\/code>.<\/p>\nConclusion<\/h2>\n