Envars, capistrano, and ansible

Couple (probably basic) questions. Been out of WordPress development for a bit, trying to re-hone skills.

  • When I follow the readme on roots/bedrock-ansible (move Vagrantfile to your Bedrock dir, cd your-bedrock.dev, vagrant up, Ansible creates a symlink called .env that links…to itself. Is this the intended behavior (since Bedrock seems to work anyway without the .env file)?
  • I understand it’s possible to use Ansible to provision my staging and production servers using the group_vars provided, but…what if I just wish to create .env files for each environment? Is that possible on vagrant up? Right now, I’m manually creating each .env file, which feels very redundant and pointless, since I can put the data into my group_vars and version it anyway.

Thanks!

Actually scratch that–I see now the .env link is pointing to the virtual machine. Second question still stands, though!

If you just want to generate the .env files, you could do a few things:

  1. Just manually remove the other roles from site.yml
  2. You can add a tag to the env task and just run that one. Like ansible-playbook site.yml --tags "env"

Thanks! I haven’t had time yet to really dig into Ansible, so I wasn’t sure where the .env file was coming from, who was linking it, and how, etc…that task clears things up quite a bit. Good to see the Ansible stuff is as malleable as Capistrano.

I went back and re-read the 12 Factor App series, so I’m understanding more of the design decisions in Bedrock-Ansible, but it’s still a lot of unfamiliar moving parts and I get confused. Still trying to grok the whole workflow.

The only other question I can’t figure the answer to is: when using Roots in conjunction with Bedrock, why is there no default task to deploy compiled assets? I understand why they would stay out of git, but isn’t releasing the built assets part of the deal–especially since they’re necessary for the app to run properly? (Same goes for the Bootstrap fonts.)

Bedrock is theme agnostic, which is why we haven’t got any Roots specific features. It has been done before though.

I think that clicked for me after I posted the question. I came across that gist yesterday and couldn’t figure out why it was necessary to write a separate task in the first place, but I was conflating Roots with Bedrock in my head, since I’ve been using them together this whole time (and they exist in one repo when I work, instead of using submodules or whatever–which should be okay, right?).

So I’m finally understanding, I think, the process. (I feel I’ve been missing a holistic understanding of how all the cogs fit together between Bedrock-Ansible, Roots, &c.)

  1. vagrant up kicks off Ansible (factor #3), which:
  2. Provisions the Vagrant VM
  3. Generates any configuration necessary, and generally gets the development environment up and running.
  4. If instructed, Ansible can also provision staging and production servers.
  5. All this is technically separate from Vagrant; it’s just initiated by the current Vagrantfile, but can be done on its own.
  6. Bedrock contains instructions for dependency management (factor 2) in the form of composer.json.
  7. It also takes care of build, release, run (factor 5) via Capistrano.
  8. Since we’re developing a theme that’s technically part of the app, it doesn’t need its own repo and is not a dependency.

So with the stack here, we can create new server environments quickly with all required software in place, install any necessary dependencies in one step, hack at our theme, and then deploy it (provided our configurations are all properly set up).

Sorry to be longwinded–I just want to make sure I’m understanding the process properly. I’ve spent tons of time tinkering with these tools, so I’m not seeing my speed or productivity increase at all; it helps to know why this design is in place, so I can decide whether it’s worth it for me to keep messing with it.

That seems like a pretty good understanding to me.

And yes it’s perfectly fine and usually expected that your site/project repo will basically be Bedrock + a theme (which may be based on Roots). Most normal setups will be like this.

One of the important distinctions you’ve realized is that Vagrant just creates VM and initiates Ansible. There isn’t really that much to Vagrant itself.

Thanks. I appreciate the 12-factor methodology, even though there are still parts of it I don’t fully understand. I’m mostly a designer/developer for smaller clients, most of whom couldn’t care less how whatever I’m developing gets developed (even if I edit live files via FTP!). But it feels important, even in that context, to stay on top of this sort of thing. So, I’ll keep plugging away at it; I’m sure it’ll be more efficient eventually.

That said, re: Vagrant, I’ve been learning a lot about Docker lately and it seems to adhere more to the 12-factor thing more closely–especially the port binding and stuff. Might be fun to do a Docker fork of Bedrock-Ansible to learn more about how those all work together.

Yeah Docker does a lot of those things well. I just haven’t had a chance to really use it.