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?
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.
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
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)
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.
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?
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
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.
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:
Vagrant now has a ‘vagrant push’ command that can connect to an capistrano or ansible script (via shell cmd) to run your deployment.
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!
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…
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.
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.