Deploying to Staging on DigitalOcean with Ansible

I’ve been doing development locally with bedrock-ansible, which is working very well for me. I’ve started playing with DigitalOcean droplets for staging and possibly production environments for finished work. Now I’ve read the readme for the bedrock-ansible project and if I understand it correctly, I should be able to spin up a new droplet on DO (I do that manually) running Ubuntu 14.04. Then I would apt-get install ansible to get ansible running on the server. Where I go from here is where I get hazy. At this point, would I just have to edit the group_vars/staging and hosts/staging file to point at my droplet’s IP and hostname and set the variables and then just run ansible-playbook -i hosts/staging site.yml. Is that it? I feel like I’m missing something. Maybe I’m just not understanding the directions. Once I do this and setup the Capistrano stuff, I would be all set to use Capistrano to push the work from my dev install locally to the staging one? Sorry if these questions seem basic, but I’m trying to wrap my head around how to do this stuff in the easiest ways possible.

1 Like

You got most of it correct.

But you don’t need to install Ansible on any remote servers. It’s always run from your local machine.

General process is outlined here: https://github.com/roots/bedrock-ansible#stagingproductionremote-servers.

Then you run Capistrano run your local/dev machine as well. Like Ansible it just runs SSH commands onto your remote servers.

OK, time for an alternate path, I think. The issue is that my main dev machine is a Windows box. The local development works fine; I was able to use the script that was suggested on the b-a github page to get everything working fine within Windows. However, when I do a vagrant ssh into the Vagrant VM and try to run ansible to push to my staging environment, it fails because every file is marked as executable, and Ansible does not like this. I tried a chmod -x on the scripts, but because it’s linked to a Windows folder outside the VM, it can’t. I don’t know if there’s anything else I could try.

@romero2k I’m not running windows, so I’m kinda guessing here.

Running Ansible within Vagrant VM. I wonder if it would help (and not break stuff?) to adjust the mount_options to ["dmode=775,fmode=664"] (for config.vm.synced_folder in Vagrantfile) as described here. This would mark synced files as not executable. Let us know if this works, because maybe these options should replace the ['dmode=776', 'fmode=775'] that bedrock-ansible has used from its beginning (?).

Or, maybe switch the vagrant sync folder to use rsync, with rsync__args like these to mark synced files as not executable.

Running Ansible within remote staging server. I’ve never tried your original approach of installing ansible on a DigitalOcean droplet and running the playbook with a local ansible_connection (vs. ssh connection to a remote), but it seems it could work. The steps you described sounded right. If you run into trouble, you could check out concepts at Running ansible playbook in localhost and in the shell script you probably used in your Vagrant VM.

2 Likes

Unfortunately, changing the mount options did not work for me. And Windows doesn’t have an rsync executable and it looks like they only make one that works with MinGW. I guess I will have to be content with using b-a for local development and having to do some legwork to get it done on the server side for staging/production.

Hi @romero2k I was wondering if you ran into directory length problems on your vagrant/ansible install.

It would be very helpfull if you could briefly describe the steps that you took to setup your local dev machine.

For deployment I don’t use ansible so that would not be a problem.

This is the problem that I’m running into:

Thanks

I was able to add

config.vm.synced_folder ".", "/vagrant", mount_options: ['dmode=776', 'fmode=664']

in the if Vagrant::Util::Platform.windows? block and that worked for me.

That didn’t change anything for me. I’ve just had to settle on this not working for me.