ECS and KISS dockerization of WordPress (Part 2)

‘Two article ago’ I wrote about my initial experience with Docker and ECS, the container service, built on top of EC2, offered by Amazon. Here it is if you want to take a look.

Today I want to continue in that direction describing the configuration of containers (or better container) I choose to serve the application selected as guinea pig to try ECS. Just as a reminder, the app was an almost standard WordPress blog with a custom theme and a few plugins.

Continue reading “ECS and KISS dockerization of WordPress (Part 2)”

WordPress and OpsWorks, “Pride and Prejudice” (Part 4)

4th part of the serie titled “Wordpress and OpsWorks“ (here you can find the 1st, 2nd and 3rd part).

Despite the title, this time I’m not going to talk about an aspect of OpsWorks specifically related to WordPress, since I’ll be presenting a brute force way to modify the default attributes merging behavior of OpsWorks.

Continue reading “WordPress and OpsWorks, “Pride and Prejudice” (Part 4)”

WordPress and OpsWorks, “Pride and Prejudice” (Part 3)

I know, this third part of the series regarding WordPress and OpsWorks comes a little bit late. 

Between this article and the previous one of the series I wrote a lot of other gems spanning many different topics.
But now I’m here to continue right from where I stopped 😉

Before we begin, here’s the first and the second article.

Now, just to wrap up, last time I tried to explain a quirk about the compilation and the convergence phase of a chef node.

To present it I relied on a recipe I wrote to “set up” the database during the deploy of a WP (WordPress) application.

Everyone accustomed with WP development knows that, due the characteristics of WP itself, it is very often difficult to keep everything updated and working as expected.

Many functionalities depend not only on the code but also on the state of the database where most of the configurations are stored. The problem with WP is that there isn’t a recognized and out-of-the-box standard that can be followed to handle the aformentioned database state.

No Rails-like migrations, sorry.

A simple (but bad) way to solve this problem is to push, together with the code, a dump of the database directly inside the repository of the project. In this way it’s state can also be tracked and most of all restored (imported) whenever needed.
Obviously this solution doesn’t fit the case in which there are sensitive information that can’t be simply shared between all the project contributors.

Anyway, assuming this is not the case, if you plan to deploy a WP project through OpsWorks you may end up with the need to automatically import a dump just during a deploy.

This is exactly the purpose of the recipe taken as an example in the last article of this series.

But hey, as L.T. says, “Talk is cheap. Show me the code”. So, here it is:

script 'load_database' do
  only_if { File.file?(db_path) and'Load PrestaShop database...') }
  interpreter 'bash'
  user 'root'
  code <<-MIKA
    mysql -h #{deploy['database']['host']} -u #{deploy['database']['username']} #{deploy['database']['password'].blank? ? '' : "-p#{deploy['database']['password']}"} #{deploy['database']['database']} < #{db_path};

What I do here is simply to rely on the script resource to invoke the mysql Command Line Interface (CLI) and tell it to import the dump located at the path stored inside the db_path variable inside the proper database.
This is done by relying on the bash interpreter and by using all the info that OpsWorks gives us through a JSON object (one per deployed application) embedded inside the deploy attribute of the JSON associated with the deploy event.

  "deploy" : {
    "app1" : {
      "database" : {
        "database" : "...",
        "host" : "...",
        "username" : "...",
        "password" : "...",
    "app2" : {

The overmentioned info are picked up by OpsWorks (and underline, Chef) right from the app configuration that can be accessed from the OpsWorks dashboard.

The complete list of the deploy attributes can be found right here.

As a side note and as already stated in the previous article, the import of the database gets triggered only if the the dump is actually present and if a proper flag (i.e. “import_database”) is present inside the overmentioned JSON.

Next time I will talk about…well…I don’t know! There are really many things to talk about OpsWorks (and WP) so just stay tuned! 😉


ThreeWP Broadcast: S3 support

If you have a WordPress Multisite (or WordPress Network) with the ThreeWP Broadcast plugin and you would like to move your assets on Amazon S3 you certanly have to deal with with one annoying problem.

The problem is, whenever you broadcast a new blog entry on other sites, the copy_attachment() method doesn’t work, no attachments are copied on the broadcasted posts.

This gist has a solution:

With this little hack S3 hosted images are broadcasted correctly.

WordPress and OpsWorks, “Pride and Prejudice” (Part 2)

Here we are for Part 2 🙂

In my last post about WP and OpsWorks I tried to explain the general setup for the recipes that I’ve developed to automate the deploy of WP applications through OpsWorks. If you missed it here’s the link.

Today I’m gonna talk about a particular problem that I encountered while writing the recipe that currently handles the database importation.

Continue reading “WordPress and OpsWorks, “Pride and Prejudice” (Part 2)”

WordPress and OpsWorks, “Pride and Prejudice”

Disclaimer: this is not a comprensive tutorial nor a step by step guide on how to set up a WordPress site through Amazon OpsWorks.

I’m reporting only my personal experience and a few tips (borrowed form my colleagues) on how to write some recipes and how to use them to manage and deploy a WordPress website via OpsWorks.

But don’t despair, this may become the first article of a series dedicated to WordPress and OpsWorks.

Ok, let’s begin.

Continue reading “WordPress and OpsWorks, “Pride and Prejudice””