Bedrock-Ansible Workflow

I’m trying to fully understand the best / what’s required setup for working with bedrock-ansible. I work on a few sites at once but I don’t have varying environments so multiple VM’s aren’t needed. I also use Bedrock for all my sites so here are my questions:

The setup instructions always refer to the bedrock folder. Do I have to keep a separate empty bedrock project in addition to my other projects?

Do I have to configure settings for each project in the vagrant file?

For example, these following settings:

  • config.vm.box = 'roots/bedrock'
  • config.vm.network :private_network, ip: '192.168.50.5'
  • config.vm.hostname = 'example.dev'
  • bedrock_path = '../example.dev'

Can I use a remote host in the group_vars/environment file? I use Amazon RDS for development.

Thanks!

bedrock folder just means your project path/folder (aka the WP site project). Maybe we should change that language as I could see it might be confusing.

The Vagrantfile is only set up to for a single shared directory (or 1 site). While the Ansible part automatically handles multiple site, right now you’d have to manually define some array/hash of sites in your Vagrantfile and loop over those to create multiple shared directories. (Someone had an example of this once but I can’t find it).

For RDS you’ll probably want to remove the MariaDB role first. But yeah, you can put whatever you want for the DB variables.

Thanks for the tips. Assuming I stick with 1 VM for each site would the following be the correct structure?

project_1_folder/

  • » bedrock-ansible/ (with edited vagrantfile / environments)
  • » project_1.dev (git cloned bedrock project)

project_2_folder/

  • » bedrock-ansible/ (with edited vagrantfile / environments)
  • » project_2.dev (git cloned bedrock project)

With that structure in mind, would that would be repeated for each project? Also, on the topic of SCM, would you track the entire project (in this case project_folder) or would you track them separately?

If your Ansible setup is going to be the same (besides WP sites) between projects, I’d highly recommend keeping it separate so you can keep them all in sync easily.

But there isn’t anything wrong with that setup except for duplication. If the Ansible playbook is specific to a site, it’s fine to include it in the same repo. We’re actually doing that for the new roots.io site

Sorry, to keep this going. I want to be sure I understand this. Ultimately I’d like to contribute to the README to help anyone else with this question.

If my previous example is duplication and you’re recommending keeping them in sync I’d like to do that.

Would this be your recommended setup?

general_dev_folder/

  • » bedrock-ansible/ (with edited vagrantfile / environments)
  • » project_1.dev/ (bedrock project)
  • » project_2.dev/ (bedrock project)
  • » project_3.dev/ (bedrock project)

If that’s the route to go, isn’t that multiple sites running on 1 VM? Wouldn’t that require what you referred to as an "array/hash" or can I setup multiple WP sites just by editing this config.hostsupdater.aliases = %w(site2.dev)

1 Like

So this is as far as I’m getting in steps. Any tips to get me the rest of the way would be much appreciated!

  1. Cloned Bedrock-Ansible
  2. Cloned Bedrock to example.dev/
  3. Uncommented & edited the following in vagrantfileconfig.hostsupdater.aliases = %w(test.dev)
  4. Cloned Bedrock to test.dev/
  5. Ran vagrant up

Running that I get the following error: Composer could not find a composer.json file in /srv/www/test.dev/current

Reading previous threads it looks like it’s not syncing correctly. What other edits / additions do I need to make to make that happen?

For reference the folder structure appears as this:

dev/
-» bedrock-ansible
-» example.dev
-» test.dev

1 Like

In your Vagrantfile, notice the commands config.vm.synced_folder and config.bindfs.bind_folder. These commands are probably only syncing example.dev right now. You could add code to repeat these commands to also sync test.dev.

I gave that a try, but no luck.

Here’s the vagrantfile. It’s a bit hacked to try and get this to work .

The only issue I can see if you’re re-using a mount for both sites:

config.vm.synced_folder bedrock_path, '/vagrant-nfs', type: 'nfs'
config.bindfs.bind_folder '/vagrant-nfs', bedrock_path_server, u: 'vagrant', g: 'www-data'
 
config.vm.synced_folder '../test.dev', '/vagrant-nfs', type: 'nfs'
config.bindfs.bind_folder '/vagrant-nfs', bedrock_path_server_test, u: 'vagrant', g: 'www-data'

Try:

config.vm.synced_folder '../example.dev', '/example.dev-nfs', type: 'nfs'
config.bindfs.bind_folder '/example.dev-nfs', bedrock_path_server, u: 'vagrant', g: 'www-data'
 
config.vm.synced_folder '../test.dev', '/test.dev-nfs', type: 'nfs'
config.bindfs.bind_folder '/test.dev-nfs', bedrock_path_server_test, u: 'vagrant', g: 'www-data'

That works! Kind of…

Only it binds the folders and does exactly what it needs to do but there is one issue with setting up multiple DBs.

If I add two sites (example.dev and test.dev) to my group_vars/development file with the same db_name it does set the up but the second site shows an error because there’s already a site with the same DB.

Changing the second sites DB name (e.x. test_dev) I get the error during vagrant up saying Error: Can’t select database

Is there a separate place I need to a define that second database?

The first problem makes sense. You should be using separate databases.

Where exactly does that Error: Can’t select database error show up? Or when?

What you’ve done is enough to define them but something is going wrong. You should verify a few things:

  1. Were both databases created?
  2. Look in the .env files generated in shared/ for each site to see if they contain the correct db info.

This might just be a bug on our end. It would help to re-create the Vagrant box too. Not sure if you did that after the first attempt in the same db.

@emaildano I’ve opened a PR here: https://github.com/roots/bedrock-ansible/pull/101

This simplifies the Vagrantfile to read group_vars/development to automatically set up all your sites. Should be much better once it’s done.

I just wanna chime in and say that I would appreciate an updated README to better explain the best practice workflow.

I often feel dumb asking stuff as I’m not used to working like this at all. An “explain it like I’m 5” approach for the README would be great for me, but also for alot of others I would think. Would probably lead to less nooby questions here, so if/when you sort this @emaildano I’d really appreciate a write up :slight_smile:

3 Likes

I’m welcome to suggestions on what’s missing or improvements. Better docs will be coming at some point beyond just the README but it’s also a little difficult for me to “explain it like I’m 5” because I made it with myself in mind.

2 Likes

I’ve already changed my process from bedrock-ansible generic to address needs to use CentOS on my hosts and traded out capistrano for going all ansible. But just to put some other thoughts out there towards simplification / best-practice ideas that relate to this thread:

  1. Vagrant now has a ‘vagrant push’ command that can connect to an capistrano or ansible script (via shell cmd) to run your deployment.
  2. If you’re on Windows and do your code repo checkin/out outside your VM with a sync’d folder to map your site folder into /srv/www path, the combination of vagrant rsync-auto and vagrant rysnc-back plugin is good. It mitigates the risk that you use WP in any way to modify files (such as adding a plugin) and don’t sync the changes back. Next time you do an rsync-auto you would lose your plugin.

Right now I have one VM with multiple WP environments within it. I’m exploring how I might tweak that so that my code repo could contain all needed parts for vagrant up to work on local dev, but vagrant push will handle ansible script for single site to go to prod (assuming SSH validation of your role allows).

Of course, I’m not expecting the main developers to focus on READMEs. I think Roots benefits more if you guys focus on progressing the project. I’m not complaining in any way by the way, I’m super happy to be able to use this great platform you’ve created and that you share your hard work free of charge!

1 Like

It works! There was an error connecting to the second DB on the first run but trying vagrant reload fixed the problem.

Maybe that could be solved with reordering the Ansible tasks? Just an idea.


In a previous comment I mentioned using RDS instead of MariaDB. On my current dev environment I use both remote DBs and local ones for testing, so I’d like to keep MariaDB in there.

Keeping every thing the same and using my RDS credentials (which have been verified to be correct) I’m was getting an error. The issue with using a remote DB is that the default login_user and login_password may conflict with the desired remote one.

mysql_root_password is a variable already in the group_vars/ files so I added a new one… mysql_root_user then added that new var to the following files tasks…

  • roles/mariadb/tasks/main.yml
  • roles/wordpress-sites/tasks/database.yml

Making those changes, it successfully connects to the remote DB, BUT now we have altered the MariaDB settings.

I’m not sure how to make both work at the same time but I’m currently working on a pull request to make MariaDB the default, with the remote DB option.

1 Like

Hey Everyone,

As of my previous issue with connecting to remote DBs and keeping the MariaDB features intact, the pull request #109 allows this now with one exception.

Using a remote DB, you must define the Ansible config option db_create: false. The creation of a remote DB isn’t currently supported because Bedrock-Ansible currently assumes your admin DB login is root

Setting db_create: false you can still define an existing remote DB to use. This fits into my current workflow anyway, so I’m happy.

I will continue to explore options on creating a remote DB so this can become a complete solution!

Tip: Check the full list of options here. I overlooked these for the ones defined in the group_vars file thinking those were it. Seeing the full list helped me understand this whole bit.

2 Likes