AWS, WordPress, Bitnami, and Ansible – A Journey

In The Beginning…

I’ve been running a number of WordPress sites at AWS, and using the Bitnami AMIs to do so. They make it super easy, just fire up an instance of the AMI, and boom you have a full WordPress environment up and running, with Apache, WordPress, and a database.

When The Palace Becomes a Prison

While everything worked okay at first, over time I’ve grown less and less happy with this setup.

The installation location for all the software components, htdocs directory, database, etc.. are all different from what you’d expect from running a typical Linux server running those applications. The control scripts are completely different, and I often had to read the online manuals to figure out how to do something basic.

You also don’t have any good upgrade path. You can upgrade WordPress itself in-place using the WordPress admin. However if you want to upgrade the stack (Apache, PHP, MySQL, etc…) you are out of luck, because they aren’t installed or managed by the package manager. Bitnami’s advice is to spin up a new EC2 instance, using the new AMI, and then port your whole site, static content, any additional pages, configurations, etc… over, update DNS, terminate the old EC2 instance, and then you’ve “upgraded”.

So a few weeks ago I decided that I wanted to move off of Bitnami entirely. I also wanted to homogenize my EC2 instances’ Linux variants, so I wasn’t switching between yum and apt servers all the time, and I wanted to standardize my user account, ssh keys, etc…

But I also didn’t want to be manually installing WordPress stacks on servers over and over, both immediately for the migration, but also in the future, as I know I will be adding more and more sites to my stable. So

Enter Automation Through Ansible

I setup Ansible playbooks to do things like setup my user account, ssh keys, sudoer rules, and install common utilities I always want available. I then created roles for installing apache, mariadb, php, and other applications, and then a WordPress role that customizes everything to provide a running WordPress environment, including installing any plugins or themes I want, just like Bitnami does, except all in the standard locations, using the standard package manager, and fully upgradable in-place. I also built out roles for servers to run Java applications, and other common (for me) uses.

In The End…

So far this system has been great! It didn’t take long to setup, even though I am FAR from an Ansible expert. It’s been working great, and as I make improvements, tune MariaDB, etc.. those changes can be quickly pushed out to my entire environment of servers. New servers are a breeze to setup, with WordPress being ready for a new site or a site import in just a few minutes.

If there is interest I may make my Ansible setup public (I didn’t write it to be public so there’s few comments, and some personal keys/names I’d need to strip out first). So if you’re interested, let me know! [email protected]

Posted

November 4, 2019

Linux

Devon

Tags:

AWS, cloud, Linux, wordpress

Comments

2 responses to “AWS, WordPress, Bitnami, and Ansible – A Journey”

Andres Morales Arce

July 21, 2021

Hi master….I’m new in this …..I’m new to Ansible, and I’m trying to do a 100% automated installation of wordpress, however I can’t find a way to do the last part of the wordpress installation in a “Silent” way and not have to use the browser, to configure the language, username and password.
I would appreciate if you had information, since I saw that in bitnami this was possible, but I don’t have a luck with Ansible.

Reply
1. Devon
  
  July 21, 2021
  
  Andres,
  
  Personally I don’t automate that part since each site may need a different admin, etc…
  
  However, if you want to script it you can do something like this:
  
  - name: Setup wp-user and wp-password command: curl --silent "http://{{WP_DOMAIN}}/wp-admin/install.php?step=2" --data-urlencode "weblog_title={{WP_DOMAIN}}" --data-urlencode "user_name={{WP_ADMIN_USERNAME}}" --data-urlencode "admin_email={{WP_ADMIN_EMAIL}}" --data-urlencode "admin_password={{WP_ADMIN_PASSWORD}}" --data-urlencode "admin_password2={{WP_ADMIN_PASSWORD}}" --data-urlencode "pw_weak=1" --data-urlencode "blog_public=0"
  
  Source: https://gist.github.com/kraeml/b2527bf22e893675966024da27940f9b
  
  Reply