Content Management in the Cloud

A content management systems (CMS) such as Wordpress, Drupal, or Joomla can make the business of building and maintaining your website much easier. In much the same way as a CMS can take away the hassles of dealing with code, Engine Yard can take away the hassles of running your own infrastructure.

Combining the two approaches, then, allows us to focus directly on the site we want to build, ignoring (for the most part) the details of implementation and hosting.

Most of the popular CMS systems were written before the era of cloud hosting. As a result, there are some issues that need to be addressed if you want to deploy these apps to the cloud. While the specifics will depend on your application, the good news is that these issues tend to fall into several well known areas.

Scalability

Engine Yard’s specialities are reliability, performance, security, and scalability. To get the most out of the platform, you have to use an environment that’s right for your application.

For production environments, this generally means one or more application instances (app instance) running your code along with one or more database instances. You might also want to run a few utility instances if you’ve got any background tasks that need to run.

Utilizing a minimum of two app instances and two database instances ensures optimal uptime, since application-tier failovers can be done automatically. And with a properly replicated database, a former database replica can be promoted to a master, all without any perceptable downtime for your end users.

It’s also possible to run a single combined app and database instance. But scaling this application (vertically or horizontally) will require downtime, as the instance needs to be imaged and reprovisioned at a larger or small size. This makes it better suited to development or staging environments.

Shared Storage

If your users will be modifying the content of your site (uploading images, making administrative changes, etc.) you’ll want to ensure that this content is available to all of your app instances at any given time.

In the case of administrative changes, it’s usually possible to make them locally, commit them to your repository, and subsequently deploy the updated code to all app instances. We call this the “frozen state” approach, because we’re modifying file system state and then committing this back to the repository.

User-submitted uploads (e.g. avatar images) present a unique challenge when horizontal scalability becomes a factor: the images are not present at deploy time, but still need to be available to all app instances, current and future. As individual instances are ephemeral, their local disks are not the best (nor safest) choice for this use.

If an image is uploaded to instance A, a subsequent request to instance B will need to have access to the file. The only way we can do this is with some sort of shared storage. NFS is one way to approach this problem, but this is yet another piece of infrastructure to manage. And besides, if your application is expecting files on your NFS mount to behave like a POSIX file system, you may be in for some surprises.

An external storage solution like Amazon S3 (or any similar cloud storage system) is the recommended approach. Using one of these cloud storage systems provides a common content repository that is available to all instances. This carries the additional benefit of being able to handle as much traffic as you can throw at it—and then some!

You still can’t mount a cloud storage system locally and expect it to behave like a POSIX file system though, so some adaptation at the application-level may be necessary. Fortunately, many CMSs have plugins or extensions that adapt your app to store your media in this fashion. And if that’s not possible, our support team can help.

Deploying your code

To deploy your code to an Engine Yard environment you will need to commit it to a Git repository, like the sort that GitHub provides. You may already be using GitHub to manage your code. But if you’re not, it’s super easy to get started. GitHub offers free accounts (though these have to be public) and the advantages of having a versioned copy of your code can go far beyond just being able to deploy on Engine Yard.

If you are new to GitHub and need assistance, GitHub’s help page is a great resource. Once you have your code online at GitHub you can use this page as a guide to get your environment up and running.

Configuration Variables

There are certain facts about your environment that your CMS will need to know, such as the database credentials and hostname. Generally these settings are stored in a specific config file, such as the wp-config.php file for Wordpress.

Because instances are disposable, the database hostname may change over time. So you’ll need a way to make your code aware of these dynamic values.

In cases where the configuration file is a .php file (e.g. wp-config.php) you can bring in the values via environment variables. Not all CMS systems use PHP files for their configuration though. Some use XML or YAML files (e.g. Magento). In these cases, the best way to configure your app is with a custom Chef recipe). You can create a template file and have Chef fill in the correct values at deploy time before moving the resulting file into place.

The Web Server

Engine Yard uses the NGINX web server. NGINX is like the Apache httpd server, but it’s configuration is slightly different.

As many CMSs expect Apache httpd, you may have to make some adjustments, like working around the fact that NGINX does not use .htaccess files. Fortunately, many off-the-shelf apps have plugins or extensions available that automatically make the adjustments for NGINX. There are even online tools to convert .htaccess files to NGINX rules. And as always, you can reach out to our support team for assistance.

Once you know what adjustments will be required for your specific situation you can use this page as a guide to get them implemented.

Conclusion

If reliability, performance, security, and scalability are key features you’re looking for in a hosting solution, Engine Yard’s platform may be right for you. Some steps may be needed to adapt your application to the cloud, but once the initial work has been done you can reap the rewards of an automated configuration processes.

While it may take a little bit of work now, leveraging the power of Engine Yard to manage your CMS in the cloud can have significant payoffs down the road. Our support staff is here to assist with any of the scaling, storage, or configuration tweaks you may need to make. Alternately, if you’d like to avoid this work entirely, our professional services team can help make the configuration and migration a smooth and painless process for you.

If you want to take a deeper dive into the differences between traditional hosting and cloud hosting, don’t forget to check out Noah Slater’s series on legacy apps.

P.S. Are you currently running a CMS? Have you deployed to a cloud host before? What were your experiences? Let us know by leaving a comment