Get your WordPress development up and running with Bedrock and Bedrock-Ansible

Update 2015-09-08: The people behind Bedrock-Ansible(Roots.io) have done quite a work and changed Bedrock-Ansible into Trellis. It’s not just a name change, for example the project uses Ansible for deployments instead of Capistrano which I’m talking about in this tutorial. I’ll try to create an updated version of this tutorial, meanwhile don’t hesitate to ask me questions or check out roots.io and Trellis docs.

---

Hi and welcome to this article series that will guide you in how to get the Bedrock WordPress-stack up and running together with the “Bedrock-Ansible” server provisioning.

Since Ansible doesn’t have support to be ran on Windows and Bedrock-Ansible isn’t built to run the Ansible parts on the Vagrant machine, you won’t be able to complete this tutorial on Windows. I’d advice you to either use Linux or OS X, we’ll be using the latter one in this specific tutorial but that shouldn’t do much of a difference.

If you do use Windows check out the “Host OS Notes” in the Bedrock-Ansible readme.

What is Bedrock and Bedrock-Ansible?

To quote the creators of Bedrock: “Bedrock is a modern WordPress stack that helps you get started with the best development tools and project structure.”.

In short terms it’s a setup that will give you a virtual machine on your computer that will act as a web server, instead of programs like MAMP or WAMP. This makes your development environment work exactly the same way as your staging and production environments does. Combined with Bedrock-Ansible you’ll get server configuration etc.

Bedrock-Ansible is a separate project that works together with Bedrock and it’s used to setup servers(install nginx, PHP-FPM etc), install WordPress, create admin users, so that you don’t have to do that more than once per project(instead of once per developer).

Requirements

As I mentioned there’s no support for Windows at the moment. the latest requirements can be found on the github repositories for Bedrock and Bedrock-Ansible respectively.

At the moment(2015-03-26) the following programs are part of the setup:

• Git (I use Sourcetree as a git client, any client should work)
• Ruby >= 1.9
• Ansible >= 1.6
• Virtualbox >= 4.3.10
• Vagrant >= 1.5.4
• Vagrant-bindfs >= 0.3.1

Installation

We will create a website called “wordpresscms.se”, start of by installing the programs mentioned above.

Project structure

When all programs in the list above are installed, create a new folder for your project. Inside this folder clone bedrock-ansible into a folder called wordpresscms-ansible:

git clone https://github.com/roots/bedrock-ansible.git wordpresscms-ansible

Then clone bedrock into a folder called wordpresscms-site:

git clone https://github.com/roots/bedrock.git wordpresscms-site

Example folder structure:

/Users/Olaf/Development/wordpresscms.se
/Users/Olaf/Development/wordpresscms.se/wordpresscms-ansible
/Users/Olaf/Development/wordpresscms.se/wordpresscms-site

First-time configuration

Open up the file wordpresscms-ansible/group_vars/development and edit to make it look like the following:

mysql_root_password: devpw # Don't change this if you use the "config.vm.box = 'roots/bedrock'" in your Vagrantfile. The password has already been set in this box.

wordpress_sites:
  - site_name: wordpresscms.dev
    site_hosts:
      - wordpresscms.dev
    local_path: '../wordpresscms-site' # path targeting local project directory (relative to root/Vagrantfile)
    user: vagrant
    group: www-data
    site_install: true
    site_title: WordPress CMS
    admin_user: wordpresscms
    admin_password: wordpresscms
    admin_email: admin@wordpresscms.dev
    system_cron: true
    multisite:
      enabled: false
    env:
      wp_home: http://wordpresscms.dev
      wp_siteurl: http://wordpresscms.dev/wp
      wp_env: development
      db_name: wordpresscms
      db_user: wordpresscms
      db_password: wordpresscms

php_error_reporting: 'E_ALL'
php_display_errors: 'On'
php_display_startup_errors: 'On'
php_track_errors: 'On'
php_mysqlnd_collect_memory_statistics: 'On'
php_opcache_enable: 0

That should be enough to get the development environment up and running with vagrant box running Ubuntu 14.04 and Nginx, MariaDB and PHP-FPM.

Before we start up our new development environment we install vagrant hostsupdater plugin which is a nifty little tool to edit your hosts-file, telling your computer that the url wordpresscms.dev points to your own computer so that it doesn’t try to look it up on the internets.

Do this by opening up your terminal and run this command:

vagrant plugin install vagrant-hostsupdater

Let’s test our new dev environment out by opening the terminal, entering the wordpresscms-ansible folder and typing vagrant up. Depending on your computer os/configuration you might need to type sudo vagrant up.

cd /Users/Olaf/Development/wordpresscms.se/wordpresscms-ansible
vagrant up

You’ll start seeing a lot of commands passing by on the screen as our environment is getting ready with all the programs. If all goes well you should see something like this on your screen:

If you open your browser and visit http://wordpresscms.dev you should see the standard WordPress installation with the 2015 theme:

<!––nextpage––>

A little about Bedrock-Ansibles project structure

Bedrock is a bit different from your standard WordPress installation. Mainly because it moves WordPress core to a sub-folder called wp and creates a folder called app that acts like wp-content.

The reason for this is to not make any changes to the WordPress library, which is fetched as a dependency with the help of Composer. Basically this also means that you should not add any plugins, themes etc manually like you might be used to, instead add them in the composer.json file.

The wordpresscms-ansible folder

This folder contains everything that has to do with provisioning new servers, and the tool that’s used for this is called Ansible. There are a lot of different tools that serve more or less the same purpose and one could argue on which to use for a long time.

First out is a folder called .vagrant, it’s not containing anything you should need to alter. Next folder called group_vars holds information about the sites name, usernames, titles etc. on each of the environments that you have. This is one of the more important folders that you will do changes to.

mysql_root_password: productionpw

wordpress_sites:
  - site_name: example.com
    site_hosts:
      - example.com
      - 192.168.50.5
    user: deploy
    group: www-data
    site_install: true
    site_title: Example Production Site
    admin_user: admin
    admin_password: admin
    admin_email: admin@example.com
    system_cron: true
    multisite:
      enabled: false
    env:
      wp_home: http://example.com
      wp_siteurl: http://example.com/wp
      wp_env: production
      db_name: example_prod
      db_user: example_dbuser
      db_password: example_dbpassword

The next folder is hosts, it stores information about where your server environments can be found. Don’t change the development-file but make sure you change to the correct ip-adress in staging and production.

[web]
192.168.50.5

[staging:children]
web

Library contains third party libraries used by default in bedrock-ansible. At the moment the dotenv environment variable library is what you’ll find here.

The last large folder that you may want to look inside a bit further is called roles. This is where all the programs used on the server have their configurations, templates etc. stored. Each program is listed as a separate folder and cain contain all or some of the following folders:

files/
templates/
tasks/
handlers/
vars/
defaults/
meta/

If you want to learn more about what the different folders are used for and how different ansible tasks invoke them, I recommend reading the ansible documentation on roles.

Below the roles-folder you will find the vars-folder, this only contains one file called sudoer_passwords and define users(with sudoers privileges) that your servers should setup.

.gitignore is a common file used to tell git what files and folders not to check in, like the .vagrant-file which is just used for locally for yourself.

.travis.yml is used for Travis CI-tool and gives basic information about the project so travis can build it.

LICENSE.md and README.md contains what you except them to, the readme is actually pretty extensive and has information that I’ve skipped in this tutorial so make sure to check it out.

At the bottom we have three interesting files, first two are .yml-files that you use to provision your server and the last one is the vagrantfile.

Don’t try to run the secure-root.yml just yet, we want to run the servers main provisining script first, which is the one called site.yml.

Also at the bottom you have the Vagrantfile. You shouldn’t have to make any changes to this vagrantfile since the group_vars are referenced from the vagrantfile. What you might want to do is change the local IP, either if you run multiple projects at once or if you have something already on the default IP-address(192.168.0.50).

To be continued…

This was the first part in getting things up and running with Bedrock-Ansible. I’m hoping to get the other parts finished soon, the next part will be a little bit about the project structure and deployment.

Until then you can find help by reading the readme for bedrock-ansible.