The last planned part of Bedrock was Vagrant/Ansible integration. We’ve finally released it here https://github.com/roots/bedrock-ansible
This is an Ansible playbook which will setup a LEMP based Ubuntu server for Bedrock based WordPress sites. It’s still early in development but we want people to try it out and give suggestions and feedback.
Check out the README for more information, but this thread can be the dedicated place for discussion and help.
Looking forward to trying this out with my next project!
It’s possible and intended. That’s why this playbook exists: to provision a (Ubuntu for now) server from nothing. It could happen to be for development, staging, or production.
bedrock-ansible is currently lacking some finesse when it comes to managing production servers. One of the easiest ways is to use Vagrant for dev and prov. I’ll add an example Vagrantfile soon with multi VMs defined (using the Digital Ocean plugin).
Ideally, Ansible itself would probably be used to launch and provision production servers. There’s nothing stopping you from doing this now, we just haven’t built anything in or providing docs/examples of it.
The way I’ve been using it right now is:
Trying this currently - I’ll report back with any issues!
One thing I’m curious about, what’s the reasoning behind using ubuntu/trusty64? I’ve been using Ubuntu 12.04.3 x32 this whole time, just wondering if Trusty64 was better for a Vagrant LEMPstack WordPress setup for some reason or if it’s just preference.
I haven’t got round to conducting any significant performance tests, so it’s more of a preference than anything. 32 bit will probably be quicker thanks to the memory overheads.
One of the reasons the PPAs were kept in tact was to allow the base box to be easily changed, so feel free to test and report back.
Tried to install twice and I’m getting the following issue both times. It seems like it’s unable to install WordPress – was I supposed to have a WordPress install all ready to go or is this supposed to automatically set up WordPress? It seems like it should but I’m not sure if I’m doing something incorrectly. It’s hard to tell from the errors (sorry for the wall of code, just want to give the full output where the errors start):
Cropped stuff before this
TASK: [wordpress-sites | Add WP user to www-data group] ***********************
changed: [default] => (item={'site_install': True, 'admin_user': 'user', 'site_name': 'bansible.dev', 'system_cron': True, 'user': 'vagrant', 'multisite': {'enabled': False}, 'group': 'www-data', 'site_title': 'Bedrock Ansible Test', 'admin_password': 'password', 'env': {'wp_env': 'development', 'db_user': 'bansible_admin', 'db_password': 'root', 'wp_siteurl': 'http://bansible.dev/wp', 'db_name': 'bansible_dev', 'wp_home': 'http://bansible.dev'}, 'site_hosts': ['192.168.50.5', 'bansible.dev'], 'admin_email': 'jb5531@gmail.com'})
TASK: [wordpress-sites | WP installed?] ***************************************
failed: [default] => (item={'site_install': True, 'admin_user': 'user', 'site_name': 'bansible.dev', 'system_cron': True, 'user': 'vagrant', 'multisite': {'enabled': False}, 'group': 'www-data', 'site_title': 'Bedrock Ansible Test', 'admin_password': 'password', 'env': {'wp_env': 'development', 'db_user': 'bansible_admin', 'db_password': 'root', 'wp_siteurl': 'http://bansible.dev/wp', 'db_name': 'bansible_dev', 'wp_home': 'http://bansible.dev'}, 'site_hosts': ['192.168.50.5', 'bansible.dev'], 'admin_email': 'jb5531@gmail.com'}) => {"changed": true, "cmd": ["wp", "core", "is-installed", "--allow-root"], "delta": "0:00:00.248335", "end": "2014-04-24 15:24:39.742968", "item": {"admin_email": "jb5531@gmail.com", "admin_password": "password", "admin_user": "user", "env": {"db_name": "bansible_dev", "db_password": "root", "db_user": "bansible_admin", "wp_env": "development", "wp_home": "http://bansible.dev", "wp_siteurl": "http://bansible.dev/wp"}, "group": "www-data", "multisite": {"enabled": false}, "site_hosts": ["192.168.50.5", "bansible.dev"], "site_install": true, "site_name": "bansible.dev", "site_title": "Bedrock Ansible Test", "system_cron": true, "user": "vagrant"}, "rc": 1, "start": "2014-04-24 15:24:39.494633"}
stderr: Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.
...ignoring
TASK: [wordpress-sites | Install WP] ******************************************
failed: [default] => (item={'item': {'site_install': True, 'admin_user': 'user', 'site_name': 'bansible.dev', 'system_cron': True, 'user': 'vagrant', 'multisite': {'enabled': False}, 'group': 'www-data', 'site_title': 'Bedrock Ansible Test', 'admin_password': 'password', 'env': {'wp_env': 'development', 'db_user': 'bansible_admin', 'db_password': 'root', 'wp_siteurl': 'http://bansible.dev/wp', 'db_name': 'bansible_dev', 'wp_home': 'http://bansible.dev'}, 'site_hosts': ['192.168.50.5', 'bansible.dev'], 'admin_email': 'jb5531@gmail.com'}, u'delta': u'0:00:00.248335', u'cmd': [u'wp', u'core', u'is-installed', u'--allow-root'], u'end': u'2014-04-24 15:24:39.742968', u'stderr': u'Error: This does not seem to be a WordPress install.\nPass --path=`path/to/wordpress` or run `wp core download`.', u'stdout': '', 'invocation': {'module_name': 'command', 'module_args': u'wp core is-installed --allow-root chdir=/srv/www/bansible.dev/current/'}, u'changed': True, u'rc': 1, u'start': u'2014-04-24 15:24:39.494633'}) => {"changed": true, "cmd": ["wp", "core", "install", "--allow-root", "--url=http://bansible.dev", "--title=Bedrock Ansible Test", "--admin_user=user", "--admin_password=password", "--admin_email=jb5531@gmail.com"], "delta": "0:00:00.217433", "end": "2014-04-24 15:24:40.412951", "item": {"changed": true, "cmd": ["wp", "core", "is-installed", "--allow-root"], "delta": "0:00:00.248335", "end": "2014-04-24 15:24:39.742968", "invocation": {"module_args": "wp core is-installed --allow-root chdir=/srv/www/bansible.dev/current/", "module_name": "command"}, "item": {"admin_email": "jb5531@gmail.com", "admin_password": "password", "admin_user": "user", "env": {"db_name": "bansible_dev", "db_password": "root", "db_user": "bansible_admin", "wp_env": "development", "wp_home": "http://bansible.dev", "wp_siteurl": "http://bansible.dev/wp"}, "group": "www-data", "multisite": {"enabled": false}, "site_hosts": ["192.168.50.5", "bansible.dev"], "site_install": true, "site_name": "bansible.dev", "site_title": "Bedrock Ansible Test", "system_cron": true, "user": "vagrant"}, "rc": 1, "start": "2014-04-24 15:24:39.494633", "stderr": "Error: This does not seem to be a WordPress install.\nPass --path=`path/to/wordpress` or run `wp core download`.", "stdout": ""}, "rc": 1, "start": "2014-04-24 15:24:40.195518"}
stderr: Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.
FATAL: all hosts have already failed -- aborting
PLAY RECAP ********************************************************************
to retry, use: --limit @/Users/Jason/site.retry
default : ok=45 changed=32 unreachable=0 failed=1
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.
Reasons to use x64:
http://howtoubuntu.org/how-to-decide-if-you-should-use-32bit-or-64bit-ubuntu
I think you’re the 3rd person to get confused by this so I should probably improve the README. See both these issues for the solution:
Great! I’ll check that out. So the idea is to use Composer to load Bedrock in the local environment as opposed to running Composer on the Vagrant machine through “vagrant ssh”… is that correct?
Actually… Bedrock encourages people to use composer create-project but part of the benefit of having a nice dev environment in a VM is to not worry about installing some newer PHP version or Composer. So ideally, you wouldn’t even install Composer on your local OS. You’d just git clone Bedrock/a fork or download a ZIP of it. Then use the Ansible playbooks for the VM which will install Composer on there.
The playbook also generates your .env file too so you don’t need that part of composer create-project.
This is another thing that I’ll have to clear up at some point in the docs of both projects.
I guess I’m confused and I’ll just have to wait until I see some examples.
How I’m understanding this is that Bedrock needs to (or rather, should) use Composer to install WordPress and Bedrock Vagrant/Ansible needs Wordpress already installed to complete the setup for the VM properly…
I’m trying to figure out how to start up a fresh project using this and I’m stuck.
No wonder you’re confused and it’s my fault! I completely forgot that of course you’d have to use Composer to “install” WP in a local Bedrock project in order for the Ansible playbook to work correctly.
So yeah, for now you still Composer locally and to run composer install first.
What I’ll probably do is add the ability for Ansible to run composer install itself to make it easier.
Here are the steps you’d need right now:
Download/clone/run composer create-project to create a new Bedrock based project. Don’t generate .env if you use Composer.
Run composer install if you didn’t use composer create-project.
Download/clone bedrock-ansible. Either copy Vagrantfileinto the directory created in #1 or keep it anywhere you want, but make sure to adjust the relative paths and the synced folder.
Setup/edit group_vars
Run vagrant up or just vagrant provision if you already ran up.
Awesome! I got it to install correctly – the only thing is that I needed to change system_cron to false in the group_vars/all file. It was true originally. Not sure the implications that will have.
Did that actually cause an error? system_cron: true just sets up a manual cron job on the server instead of using WP’s internal cron. This is needed since by default Bedrock has DISABLE_WP_CRON set to true.
Let us know if you have any suggestions about all this Ansible stuff. It’s hard to anticipate other people’s workflows when it’s only you using it.
The error caused when I had system_cron set to true:
TASK: [wordpress-sites | Setup system cron] ***********************************
fatal: [default] => One or more undefined variables: 'dict object' has no attribute 'item'
FATAL: all hosts have already failed -- aborting
PLAY RECAP ********************************************************************
to retry, use: --limit @/Users/Jason/site.retry
default : ok=47 changed=34 unreachable=1 failed=0
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.
When this happened, I couldn’t load the site at all, so changing system_cron to false allowed it to finish setup. I can now go to the URL and have WordPress load but I haven’t done anything beyond that. Looking into it more this morning.
Bedrock/Ansible seems like it’s on the right track so far. Prior to this I was using puPHPet to set up a vagrant/puppet manifest that I’d then vagrant ssh into to use composer create-project for Bedrock. I’d use Composer to maintain the system on the VM side. I’d set up a new machine entirely for each project.
With Bedrock/Ansible it seems like the better way is to have one VM and just modify the group_vars/all and Vagrantfile (or put the Vagrant file in each project directory specifically) for multiple projects… is that correct?
I’m still pretty new at using Vagrant and the benefit of it always seemed to be able to destroy the VM for a project and just create a new one…but after trying it that way it seems like one VM for multiple is the more efficient route.
I’ll be tinkering around a bit but I hope to have some suggestions soon. Thanks for all of your help and taking the time to build this!
Thanks for that debugging. I just pushed a commit to fix it.
Multiple sites on a VM vs a VM per site is the main thing people always ask about. We made these Ansible playbooks flexible with either in mind.
It depends purely on a person’s workflow though. If you’re working within a company on an internal WP app (or two), it makes sense to keep the VM per project and have the Vagrantfile tied to each project (in their repos).
If you’re a WP dev doing lots of client work and working on a new site every few weeks (or even more often), it makes more sense to keep 1 main VM with all your dev sites on it. So you’d probably just keep the Vagrantfile where it is by default in the ansible project dir.
Just tried running it again with the new changes (verified they are indeed there) and I get the same error.
So I went into the file you changed and made one more change to line 65:
user={{ item.item.user }}
to
user={{ item.user }}
and that seemed to fix it. I’m not entirely sure what I’m doing but it just seems like you missed that line and it was trying to reference something that it couldn’t get to, which should be the vagrant user. Is that correct?
Now I’m getting other issues, like trying to go to my site “testproject.dev” yields the default “Welcome to nginx” screen and when I try to go to testpoject.dev/wp/wp-admin a 404 error.
EDIT: That error with the 404 / default nginx page was with vagrant provision. Trying again now with a destroy and then a fresh up.
Serves me right for using the GitHub editor… just fixed that again, thanks.
Getting the Nginx default page is usually solved by restarting the php-fpm server (sudo service php5-fpm restart)
Doing a fresh vagrant up with the line 65 change I mentioned above does seem to work. The WordPress site loads almost perfectly (see below): no more nginx default screen / 404 screen.
I’m getting the following issues now:
When going through the WordPress admin I’m getting a few errors on the Dashboard 
The default plugins (akismet, hello dolly) that come with WordPress aren’t on the plugins page, not sure if that has to do with the errors above, but I have a suspicion it may.
When doing a vagrant halt and then starting up the machine again with vagrant up, my testproject.dev URL yeilds the nginx default screen and going to testproject.dev/wp or testproject.dev/wp/wp-admin yeilds a 502 Bad Gateway error. Maybe this is reserved to a VM problem on my end. I get a lot of “default: Warning Connction Timeout. Retrying…” followed by lines of “default: Warning: Remote connection disconnect. Retrying…” when starting up my machine. This varies all the time. Sometimes it times out entirely , other times it makes it through.
EDIT: Just saw your above response. Tried sudo service php5-fpm restart and also sudo service nginx restart. Still getting the 502 bad gateway. Now it’s not even showing the default nginx screen.
Probably my VM… I gotta look into this.
Why’s that? I’ve only used Vagrant + Bedrock for one project so far, but to me I’d really feel that I’d want a separate VM for each project. I usually work one project at a time, and when I’m done I archive the project. With the Vagrant route I figure I just keep it all in the repo and if I ever need to work on it again (I seldom do actually), I’d just pull down the repo and be good to go.
Just curious why you would think otherwise 