Bedrock-ansible vs. bedrock-capistrano deploys

bedrock
1

Hello,

Once again thanks for all the great work you’re putting into Bedrock.

I’ve noticed that there were quite a lot of changes coming from the latest commits to the bedrock framework. I can see that now there are two separate projects that can be used to deploy a bedrock application, e.i.: bedrock-ansible and bedrock-capistrano.

I have a couple of questions regarding these. First, I assume that when deploying with bedrock-ansible, no software has to be installed on remote hosts, as Ansible will ssh into the servers and run the tasks (as opposite to Capistrano which has to be installed on remotes). Am I right?

Second, I schemed through some tasks in the bedrock-ansible deploy routine. Am I right to think that the Ansible task:

  • name: Ensure shared sources are present

found in deploy/tasks/main.yml takes care of syncing the uploads folder between the environments while in case of bedrock-capistrano uploads are not taken care of ?

Third, what are the main advantages/disadvantages of using one deploy method over another?

1 Like
2

You’re correct that Ansible does not require anything to be installed on the remote servers, but that’s actually the exact same as Capistrano.

They both work just by executing remote SSH commands. Both are completely local. Both have the exception of needing Git at a minimum on the remote host (and maybe Node/npm if you want to compile assets on there).

Regarding “shared sources”: no, Ansible doesn’t “sync” them between environments. Ansible deploys are basically the exact same as Capistrano.

That task just makes sure that shared/uploads (for example) exists in shared/ before trying to symlink it to the current release.

There’s two main advantages to using Ansible:

  1. If you already use bedrock-ansible then there should be no reason to use Capistrano. Since the deploy configuration is already taken care of once you’ve configured your WP sites. And you don’t need to install any other tools locally (Ruby, Capistrano, etc).

  2. This is just a continuation of the above. Even if you don’t use bedrock-ansible, it may be easier for people to use Ansible for deploys rather than Capistrano/Ruby. Configuring and modifying YAML might be easier for some people than Ruby if they don’t know.

1 Like
3

@swalkinshaw, thank you a lot for detailed explanation.

As far as I remember, in the previous version of Bedrock’s README, capistrano-wpcli was recommended for automating syncing the uploads folder between environments, or maybe it was recommended by one of the Roots Discourse users.

However, this would require installing Capistrano locall even if deploying with Ansible.

Would there be a way to set up tasks that would sync uploads, could that be considered in future Bedrocc-ansible releases?

4

capistrano-wpcli is a pretty simple wrapper for WP CLI. It wouldn’t be hard to duplicate its functionality into Ansible deploys. I won’t be doing this by default you you can just edit the default tasks/main.yml.

The wp command already exists on a bedrock-ansible provisioned server since it installs WP CLI.

You could just ask some tasks to do the uploads/DB syncing or even potentially just use the pre_build_commands_local option.

5

I will try to extend/add a task to get Ansible to sync uplods. The same goes for syncing databases.
I was only wondering - I started using Bedrock version release from before ansible deploy tasks were added.
If I just bring my local bedrock-ansible up to date, will it be necessary to provision the servers again, or all other configuration has not been change so as to require re-provisioning ?

6

@luqo33 In the case that you want to sync an “uploads” folder from your local machine to the remote server on each deploy, bedrock-ansible already supports that. You can add your “uploads” local path to project_local_files by modifying this example.

You could modify the paths and add something like this to group_vars/<environment>

project_local_files:
  - name: sync uploads directory
    src: ../example.com/web/app/uploads/
    dest: ../../shared/uploads

project_local_files is used in the “Copy project local files” task, which runs rsync, which will only copy files that aren’t already on the server. So, you won’t even have to copy up everything every time. This task uses the synchronize module and you may want to check out its available options for finer grained control.

2 Likes
7

@fullyint, Thanks so much for these directions. I only heard about Ansible, but I can already see that it is such a versatile tool.

8

You will most likely need to re-provision. A lot changed with the addition of deploys. Especially things to do with users and permissions.

9

@swalkinshaw, well this might be a trivial question, but is re-provisioning completely safe for projects that are currently on remote servers and were started with the “previous version” of bedrock-ansible?

10

It depends on the changes but I can’t say for sure either way off the top of my head. We don’t design bedrock-ansible to be “backwards compatible”.

The best way to be safe would just be re-creating your server with the latest version. As long as your server is fully Ansible managed, this should be quick and safe with minimal downtime. The only things you’d need to backup transfer would be uploads and your database.

11

@swalkinshaw, I have two projects that I started with the previous version of bedrock and bedrock-ansible. I’m not worried about downtime as this is only a testing server. It would be worse if there were tasks that e.g. replaced databases, changed folder structure of projects, etc. I’ve provisioned this testing server with previous bedrock-ansible and have kept two bedrock projects so far, nothing else.

But yes, I will backup uploads the the database before provisioning again. Thanks!