CloudConf 2016

Edit: despite the time passed since I wrote this article it seems that there is still someone that is finding it interesting and entertaining! I’m really happy about it and so, thanks a lot Eric! 😄

Regarding interesting posts let me grab the chance to suggest this one wrote by James Crace of Cloudwards 👌.
Go on and take a look at it, I’ll wait you here don’t worry 😉

…oh there you are, welcome back! Ejoy my post! 😁

Continue reading “CloudConf 2016”

A few (silly) tips about AWS EC2 instances “backup/migration”

EC2 instances are often considered long lasting resources in charge to deliver the Web applications deployed on them.
This is actually a wrong belief as their nature is instrinsically ephemeral and they should be considered reproducible assets in the context of a much larger infrastructure.

Continue reading “A few (silly) tips about AWS EC2 instances “backup/migration””

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)”

Bash quirk in Dockerfile

In my last article I wrote about my initial experience with ECS, Docker and WordPress.

While already practical with the core concepts of Docker, after learning the basics of ECS and creating a working Dockerfile I encountered the need to dive deeper in many aspects of the “platform” and the technology under discussion.

Continue reading “Bash quirk in Dockerfile”

ECS and KISS dockerization of WordPress

ECS (EC2 Container Service) is one of the latest Web services released by Amazon and it is among the cool kids around. Why? Well it let you deploy and administer Docker containers by integrating deeply with the other Web services offered by Amazon. To name a few, ELB (Elastic Load Balancer), Launching Configuration and Auto Scaling Groups (ASG).

At the base of ECS reside two fundamental concepts, tasks and services.

Continue reading “ECS and KISS dockerization of WordPress”

Metaprogramming in OpsWorks recipes

The last time I worked on OpsWorks I needed to implement a recipe to handle the setup and configuration of cron jobs.

Actually I had already written some code to handle this functionality in the past. However, the recipe I ended up with wasn’t particularly flexible.

Continue reading “Metaprogramming in OpsWorks recipes”

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)”

Clean the kitchen, aka refactor cookbooks and recipes

I was planning to continue my series of posts entitled “Wordpress and OpsWorks, Pride and Prejudice”, but today I want to talk about something a little bit less specific. Anyway, for the curious readers, here’s the link with the last post of the aforementioned series.

The subject of this post doesn’t relate in particular to Opsworks or WordPress but it is still connected to these topics as it discusses “something” I found myself in need while working on a new cookbook containing some new recipes.

This something is the wish to refactor and it comes from the fact that the recipes of the new cookbook have a lot in common with the ones of the WordPress one. Just for the record, the purpose of the new recipes is to handle the deploy of another PHP framework (if WordPress can be considered a framework) called PrestaShop.

Anyway, pushed by the will to improve and dry out the structure of my cookbooks and recipes I started to delve more and more into the Chef docs and to study the other open source cookbooks.

Among all the sources I stumbled upon let me report this one as I consider it a great summary of the best practices regarding cookbooks and recipes development.

One of this best practices is to identify the type of the cookbooks you’re writing. This indeed will let you structure them in a more appropriate way and avoid, in many cases, a lot of duplication.

In my case for example, the WordPress and PrestaShop cookbooks can be considered as wrapper cookbooks for a more general one.

This last, i.e. the mysterious general cookbook, can be considered instead like an application cookbook. You can roughly think it like a sort of parent cookbook whose aim is to reduce the possible duplication between his children.

An example of these duplication is the recipe needed to handle the import of a database dump.

In this case the recipe is pretty general as it doesn’t rely on any specific data or behavior concerning the type of the application beeing deployed.

Here it is:

node['deploy'].each do |application, deploy|  
  attributes = deploy['set_db']
  next if deploy['application_type'] != 'php' or deploy['application'] != application
    import_db_dump do
      db deploy['database']
      db_dump attributes['db_dump']

The check I’m doing here (i.e. if deploy['application_type'] != 'php' or or deploy['application'] != application) is something I need in order to ensure that the recipe gets executed only for the current deployed application and not for the others allocated on the same OpsWorks stack. Remember, we’re using OpsWorks to handle all the operations and their related configurations.

The import_db_dump is just a definition I’ve written to add a little bit of magic and hide the details related to the import. Maybe one day I’ll show you those details… ;P

Now the important thing to remember about the recipe is that it resides inside a (general) application cookbook. I called it phpapps. So whenever I need to use the recipe inside a PHP layer defined inside an OpsWorks stack I must remember to specify the correct “path” to the recipe, in this case, phpapps::set_db.

This is really nothing special. The magic here (except from the one related to the import_db_dump definition 😉 ) is that OpsWorks will handle for us all the information we need in our recipe by automatically merge them not only with all the attributes specified inside the JSONs (i.e. the stack and the customs one) but also with the defaults attributes written inside the recipe cookbook.

In this way you can rely on these attributes in order to specialize the recipes.

As stated before this isn’t particularly the case as the recipe doesn’t use any application specific information.

Anyway in another general recipe I’ve written I rely on this feature and it seems to work pretty well.

Next time I’ll maybe describe the particularities of this misterious recipe as it need some tweaks to function properly.

Moreover it strongly relies on the default attributes of the cookbooks. These elements are indeed from my point of view the real cornerstone to properly structure the cookbooks as wrapper and application specific ones.

To the next time! 😉