Overview

If you are currently using Engine Yard Cloud (EYC) to deploy your Rails application, Engine Yard Kontainers (EYK) can greatly improve auto-scaling for your application, reduce costs, and improve performance without changes to your code. There are two different migration patterns for Rails applications: one for applications that use Chef Recipes and another for those that don’t.

Environment

This guide assumes you have the following:

An Engine Yard account with an EYC Rails deployment.
Your application optionally uses Chef Recipes.

Solution

Migrating from EYC to EYK without Chef Recipes

Deploying applications that do not use EYC’s integrated Chef Recipes only requires you to add a Dockerfile and Procfile to the root directory of your project. The EYK CLI provides a simple method of generating the Dockerfile and Procfile, which is described in detail in the Deploy an Application with Kontainers article.

Migrating from EYC to EYK with Chef Recipes and/or other external resources

Many applications have customized Chef recipes and/or external components, resources, and services as dependencies. For example, you may have a database (e.g. RDMS, NoSQL), key-value stores (e.g. Memcached, Redis), background jobs (e.g. cron jobs, Sidekiq), or 3rd party components (e.g. pdf printers, reporting & analytics engines, logging software).

The first step is to segment your dependencies into two categories: Config and Infrastructure (Infra). These categories are defined as follows.

Configuration resources (“Config”) such as .yml configuration files, environmental variables, and secrets that generally vary between deployment environments (development, test, production, etc). Examples include:

Resource handles to the database, Memcached, and other backing services
Credentials to external services such as Amazon S3 or Twitter
Per-deployment values such as the canonical hostnames

Infrastructure (“Infra”) resources that provide fixed functionality or service for the core application and generally remain independent of the application’s logic. Examples include:

Elasticsearch
Redis
SQL Databases
Firewalls
Daemons and Cron jobs
Log collecting agents, IPS agents
Language stacks such as Ruby, Node, PHP, Java, etc.

To help classify your application’s resources, you can view the full segmentation of all EYC’s Chef recipes and other resources into ‘Config’ vs ‘Infra’. Once everything is categorized, we call this the Full Application Inventory. This inventory helps determine the next step(s) in your migration to a containerized environment.

Note that this segmentation is based on the typical usage of a resource or service in a given environment. Here are some rules of thumb to help guide your segmentation:

Most resources will be ‘Infra’. Your service provider platform is responsible for delivering this on your hosted instance or container.
If a resource or a service requires data persistence during runtime, it should be categorized as ‘Infra’.
If the resource or service can run detached from the core application, it's likely ‘Infra’. However, if it is absolutely required (almost as a runtime dependency) for your application to run, then we classify that as ‘Config’.

Config Resources

If a resource or service is classified as ‘Config’, the primary EYK approach is to leverage the application configuration.

Environment Variables: When you have specific parameters/variables that your application needs at runtime, you can define these as part of the application configuration. Environment Variables can be used for secrets, environment-specific parameters, and other various configuration parameters.

Infra Resources

If a resource or a service is classified as ‘Infra’, there are multiple approaches that can be used to provide the capability in a containerized environment.

Dockerfile: Using a Dockerfile is the most versatile way to enable most ‘Infra’ resources. You configure ‘Infra’ resources in the container image by declaring and installing them through instructions in a docker file. This paradigm is also known as Infrastructure as Code. For example, if your application requires a specific version of Ruby, Node.js, system packages, or special software components like Clamv or Flume, you can specify these in your custom Dockerfile.

If you include a Dockerfile at the root of your project directory, EYK will use that instead of a system-provided version to create your container image. The specified resources should then be available to your application. See how to create a custom Dockerfile.

See this article for more information on how Dockerfiles are used in EYK.

Procfile: The required resource can be incorporated as part of the Procfile so that EYK directs the system to launch independent containers used to execute the resource. Each of these container instances uses the same image defined in the Dockerfile, however they run as independent processes. Some examples include Sidekiq jobs, Daemons, and Cron jobs. For more information, see the article on configuring your Procfile.
Engine Yard Cloud resources: Existing EYC resources can be used from your EYK clusters. See the article on Accessing Resources from External VPCs for more information. EYK application configuration is often used to define named endpoints/URLs for these resources, such as ones you provision in the EYC environment or someplace else. These environment variables can be used to store these configuration parameters in addition to storing secrets.

To summarize, the EYC to EYK application migration process consists of three steps.

Build your Full Application Inventory and identify what recipes, components, and services are needed for your application. This exercise will help you organize the effort for migration
Classify each of these existing elements as either ‘Config’ or ‘Infra’ (remembering that most components fall under ‘Infra’)
Identify one of the five approaches for each element to deliver that capability in your containerized environment

Our support team is available and ready to help with these migrations and provide best practices. Contact them at support@engineyard.com or through the ticketing system. Continue to watch this space as we will be adding specific playbooks to aid detailed planning of your migrations to EYK.

Testing

Once you have tested your application in development or test clusters, you are ready to migrate. If you would like further validation, we can provision an application load balancer so that you can compare and contrast the performance of your existing EYC based application with an EYK hosted application.

For this comparative analysis, you will need to log a ticket for this in our ticketing system and we will reach out to you for any assistance.

Back to top

Migrating from Engine Yard Cloud to Kontainers