AWS Elastic Beanstalk is an easy-to-use solution for building web apps and web services with popular application containers such as Java, PHP, Python, Ruby and .NET. You upload your code, and Elastic Beanstalk automatically does the rest. Elastic Beanstalk supports the most common web architectures, application containers, and frameworks.
AWS OpsWorks is a robust end-to-end solution that gives you an easy way to manage applications of nearly any scale and complexity without sacrificing control. You model, customize, and automate the entire application throughout its lifecycle. OpsWorks provides integrated experiences for IT administrators and ops-minded developers who want a high degree of productivity and control over operations
AWS CloudFormation is a building block service that enables customers to provision and manage almost any AWS resource via a domain specific language. You define JSON templates and use them to provision and manage AWS resources, operating systems and application code.
The main concepts of OpsWorks are:
There’s no charge for using OpsWorks. You pay only for AWS resources being used like EC2 instances, RDS databases, etc.
OpsWorks uses Chef to configure the layer’s EC2 instances. Chef turns infrastructure into code. With Chef, you can automate how you build, deploy, and manage your infrastructure. Your infrastructure becomes as versionable, testable, and repeatable as application code. A Chef recipe defines everything that is required to configure part of a system. And a Chef Cookbook is a collection of recipes.
You don’t have to be a MasterChef (oh, :facepalm:) to use AWS OpsWorks. There is a good set of predefined layer blueprints for standard use cases, all of them are open-source, available on opsworks-cookbooks Github repository.
This post focuses on how you can deploy Ruby on Rails applications on AWS OpsWorks. There are fantastic resources on the Internet explaining OpsWorks philosophy and how it works under the hood, so I won’t repeat them here. You’re invited to check the curated references at the end of this post.
Here is a collection of tips and tricks to help you deliver Ruby on Rails applications using AWS OpsWorks. Enjoy!
Log in into your AWS account. Select OpsWorks on AWS console. It can be found under Deployment & Management product family.
Tip Nº1: you can have many stacks as you want. Doing an analogy with Heroku, you can think of a stack as a new Heroku application. A completely new and isolated environment. Talking about environments, a common practice is to have multiple stacks that represent different environments, like staging, production, and so on.
Tip Nº2: when you are creating a stack, you have the option to set a Default SSH key for all future instances within the stack. So, a common practice is to create or import a key pair before creating a new stack. To do that, first go to EC2 dashboard, click on Key Pairs option, and create or import your key pair. By doing so, all layers instances will have it configured and you’ll be able to
ssh those instances.
Tip Nº3: you can customize layer cookbooks using the custom JSON textarea. Chef cookbooks accept parameters in the form of node attributes. You need to check what parameters you can send to each cookbook (use the source, Luke! :). Check below one useful example:
Tip Nº4: the
swapfile_size_mb parameter above is specially useful when deploying Rails applications on EC2 micro instances (free tier) and use a deploy hook (that I’ll share in minutes with you) to precompile your assets (imitating Heroku deploys). The
assets:precompile command eat a lot of memory, causing the instance to run out of memory on every deployment if you don’t increase the swap file size.
Tip Nº5: during the stack configuration you have the option to use custom Chef cookbooks. This is useful when setting node attributes isn’t sufficient. By setting custom cookbooks you can go further and override some files written out by your layer’s recipes, or even build a completely new and customized layer.
Every stack contains one or more layers, each of which represents a stack component, such as a load balancer, application servers, application databases, workers, and so on.
I can’t do a good analogy this time with Heroku. However, you can think of a layer as a custom add-on, or your Heroku Postgres (which is an add-on in fact).
Tip Nº1: currently AWS OpsWorks provides a set of layers for standard use cases such as application servers, database, etc., which you can customize as needed. Also there is a special kind of layer to connect your RDS databases into your stack. This is perfect if you are coming from Heroku. First go to RDS dashboard, create a new RDS Postgres database and then go to OpsWorks, select your stack, add a layer, and select the RDS layer pointing to the recently created database.
Tip Nº2: a typical Rails Application will have three or more layers:
I’m still exploring the best approaches to create a worker layer to run application processes like Sidekiq, or any other. Custom cookbooks are the path to accomplish this. When I found the answer I’ll create another post for that. If you want to help me, send a comment :-).
Tip Nº3: when you create the Rails App Server layer you have the option to select the Ruby version, and other common settings. If you intend to use a load balancer for your App Server instances (which is highly recommended!), first go to EC2 dashboard and create a Load Balancer before creating the Rails App Server layer. A common practice is to name the load balancer with the
stack-name plus the
-lb suffix, resulting in
Tip Nº4: create and attach a security group for your load balancer configuring the inbound and outbound traffic as follows:
Tip Nº5: if you use HTTPS for your application, you must upload the SSL certificate files to AWS IAM. An SSL Certificate allows you to configure the HTTPS/SSL listeners of your load balancer. You may select a previously uploaded certificate, or define a new SSL Certificate. To upload your certificate to AWS, ensure that all your certificate files are in PEM format. Follow the steps below if your certificate was issued by Comodo:
Extract the certificate files to a folder and
cd to that folder:
Convert all certificates and private key:
Create the CAChain:
Finally, upload it to AWS IAM:
Tip Nº6: if you use HTTPS for your application, configure the load balancer health check to use
HTTPS for the ping protocol. Set only a
/ as the ping path.
Tip Nº7: to use a RDS Postgres database layer along with your Rails application, you need to configure and apply a Security Group to your database instance allowing any source IP to access your database. To do that go to EC2 dashboard, select Security Groups option and create a new security group with the following inbound and outbound rules:
Tip Nº8: if you already have a database on Heroku Postgres, and want to migrate all existent data to your RDS Postgres instance, do the following:
Put your Heroku app in maintenance mode:
Capture and download a backup via command line, or using Heroku Postgres interface.
Uncompress it to raw SQL:
And then import into your RDS instance:
Tip Nº9: after creating the Rails App Server layer, you can edit the layer and add additional operational system packages that will be available on all instances. Again, doing an analogy with Heroku you can think this as “something like” Heroku Buildpacks. I want to reinforce the double quotes here. There’s no such a thing like Buildpacks on OpsWorks. This is just an analogy. You probably wrote one Buildpack if you already needed to run a package that is not part of the default set of installed packages.
For instance, if you use the
pg gem, add the
postgresql93-libs packages. Also, don’t forget to add
nodejs package. We will use it to precompile application assets.
We’re almost there. At this point we have configured the software that will run on the server. Now it’s time to create the instances themselves which are the servers that will execute and run the application code.
Tip Nº1: instances can be started manually, or configured to start and stop on a schedule or in response to load patterns.
Tip Nº2: a common practice is to spread your instances over subnets in multiple AZs for higher redundancy.
Adding an app to the stack is the first step to deploy an application to your application servers. An AWS OpsWorks application represents code that you want to run on an application server. The code itself resides in a repository such as a Amazon S3 archive or a Github repository.
With the AWS OpsWorks interface is very easy to register an application. Just click on Apps and on the +add link. From now on just fill the form which is pretty straightforward. Bellow a couple more tips and reminders.
Tip Nº1: when you deploy an application, AWS OpsWorks triggers a deploy event, which runs each layer’s Deploy recipes. Each of the built-in application server layers includes a set of Deploy recipes, which use the data from the stack configuration and deployment JSON to automatically deploy the app’s code from the repository to the layer’s instances. The Deploy recipes also handle related tasks such as restarting services and setting up database connections.
Tip Nº2: you can use a private git repository as application source. You just have to configure the repository ssh key on both sides (in the OpsWorks application configuration and your repository).
Tip Nº3: if you have multiple environments (staging, production, etc.) you can configure to source the application from a specific branch corresponding to the environment name.
Tip Nº4: select RDS as data source type if you are using a RDS database layer.
Tip Nº5: not exactly a tip, but a reminder: you can (and should!) use environment variables to store your secret keys and third party credentials. A common practice is to set at least the
RAILS_ENV env vars.
Tip Nº6: add your application domains or subdomains filling the Domains section. Use the DNS manager of your domain to configure the records. You have the following options:
Arecord pointing it to the specific instance IP address. This is not good because this IP change every time you stop and start the instance.
CNAMErecord pointing to it. Again this is not good, because this address also changes after a full stop/start since the IP address composes the name of instance Public DNS endpoint.
Tip Nº7: if your application uses HTTPS you have to configure the SSL certificates. You just have to enable the SSL switch and fill the textareas with the contents of your purchased certificate files as follows:
-----END CERTIFICATE-----). Comodo issued certificates can do the following:
The SSL certificates of Certification Authorities textarea is optional, used for intermediate CA key or Client Authentication.
Tip Nº1: write your own deploy scripts and use the
aws command line tool to automate the application deployment of your OpsWorks applications. The following command create the deployment of an AWS OpsWorks application:
Just replace the
<app-opsworks-id> with the corresponding values for your stack and application. These ID’s you find viewing the stack and the app respectively.
Tip Nº2: you probably configured a default SSH Key for your instances (tip number 2, under adding stacks). Having a configured SSH key allows you to SSH directly an instance by its IP address or Public DNS. As one example, if you want to manually check the Rails application logs on a running instance:
Tip Nº3: Chef deploy callbacks can help you to automate your deployment scripts. Just create a directory in your app called
deploy and add files named for the appropriate callbacks. For example, here’s how you can handle assets precompilation, expose environment variables during the deployment, and perform common database tasks like running migrations and seeds.
I encourage you to play with AWS OpsWorks. With a very simple interface almost any developer can model and map the components of their applications. Plus you can take advantage and use other services available on AWS Cloud. For example, CloudWatch to monitor your applications and resources, creating custom alarms, or using hundreds of metrics and graphs. Also take a look on RDS databases monitoring options - you will be amazed. Also, there are many other services available. I can’t list all of them here.
And don’t get me wrong: I’m not comparing OpsWorks with Heroku in any way. For me, they are entirely different things. Seriously, I already tested a lot of services out there, and I continue checking every time something new appears on the scene. However, I was not able to find a competitor to beat Heroku ease of use. All analogies in this post are to help “Heroku-only” developers to understand OpsWorks vocabulary and how it works.
The simplicity of OpsWorks makes it a reliable option for delivering your applications. Highly productive, powerful and flexible, supporting any software that you would like to use with scripted installations.
If you are looking for another choice to deliver your applications, definitely it’s time to give AWS OpsWorks a chance.