Using Trellis/Bedrock to manage servers at multiple hosts in the same project

How would you configure Trellis to manage remotes at multiple hosts?

My scenario:

  1. Production and Staging at a managed host (like Cloudways, Kinsta, Pagely, RunCloud, ServerPilot, etc)

  2. Specialty “disposable” roles like Training at a self-managed host (AWS, DigitalOcean, Linode, Vultr, etc)

The fact that different hosts may require different settings/configs in group_vars/<environment>/main.yml, group_vars/<environment>/vault.yml, etc, isn’t a problem, of course, since each environment is only expected to be deployable to one host (in my scenario) so there is no need for uniformity across these files.

However, given that some of these hosts will also require different settings/configs in trellis/ansible.cfg, trellis/roles/deploy/hooks/*.yml, etc, how do we support multiple hosts from the same project?

1 Like

Our docs contain example of site specific deploy hooks. Does that solve your use case?

I think the last problem is if the same site exists on multiple environments and you want the hooks to vary by environment.

Of course you could leverage the env variable as well:

  - '{{ playbook_dir }}/roles/deploy/hooks/build-after.yml'
  - '{{ playbook_dir }}/deploy-hooks/build-after.yml'
  - '{{ playbook_dir }}/deploy-hooks/sites/{{ site }}-build-after.yml'
  - '{{ playbook_dir }}/deploy-hooks/sites/{{ site }}-{{ env }}-build-after.yml'

Oh, of course you could just re-define the deploy_build_after variable in different env group_var files which is probably better than my example above!

By “just re-define the deploy_build_after variable in different env group_var files”, (actually finalize-after, in my case) do you mean that group_vars/**production|staging**/main.yml would have something like :

 - '{{ playbook_dir }}/our-deploy-hooks/managed-finalize-after.yml

…That contains the customized version of finalize-after.yml needed for the managed host, while group_vars/**training|etc**/main.yml would have something like :

 - '{{ playbook_dir }}/roles/deploy/hooks/finalize-after.yml'

…That contains the version shipping with Trellis (since these servers would be built in “vanilla” DigitalOcean)?

Yep that looks correct

Excellent, thanks! Can’t wait to try it this weekend…

Regarding ansible.cfg differences between hosts:

  1. I see ansible.cfg referenced in many files (within Trellis), but I haven’t found one that appears to be associated with specific host environments, such that it can be specified differently for different host environments. Am I missing the key location(s), or are multiple ansible.cfg files not common?

  2. If not multiple ansible.cfg files, is there a way to specify different host environments within the singlular ansible.cfg file?

Barring either of the above, I suppose I could switch ansible.cfg settings in and out as needed (such as the forks and host_key_checking settings required by Kinsta), but setting these to some sort of superset value that is supported at DO as well would be preferable.

ansible.cfg is a per-project config that can override a global one, but it’s not tied to inventory/hosts at all.

If you want to change settings like host key checking per host, that can just be done in the hosts files. See How to build your inventory — Ansible Documentation for some documentation. And here for all the possible settings.

How to set host_key_checking=false in ansible inventory file? - Stack Overflow has some examples.

Thanks for these references! Clearly, I have more ansible sleuthing to do… :slightly_smiling_face:

Meanwhile, if I’m reading this correctly, the following two are equivalent to each other:

  1. host_key_checking = False in the ansible.cfg file (in the trellis directory root)
  2. ansible_ssh_extra_args='-o StrictHostKeyChecking=no' in hosts/servertype

Could that be correct? And if so, why have both specified (as is the case in your Kinsta doc)?

If the above two are indeed equivalent, I should be able to omit Item 1 from ansible.cfg, and simply rely on Item 2 in hosts/servertype… Or am I still missing something?

One is global and would apply to all hosts/inventory. The other is specific to that inventory group (environment) only.

So yes, if you use the second form I’d omit the first one since it might disable host key on other hosts you don’t want to. If our guide has both… we should probably remove the global one.