Roots Discourse

To deploy a second site

Hi, I’m trying to deploy a second site to a second domain at a Digital Ocean droplet.

The first step is to add second host to hosts/production:

[web]
abralaboca.net
e451.net

[production:children]
web

Then, I should setup server running ansible-playbook -i hosts/production server.yml --ask-become-pass

Is it right?

But, when I did it, I got an error. This is the terminal output:

TASK: [common | Update Apt] *************************************************** 
failed: [abralaboca.net] => {"failed": true}
msg: Failed to lock apt for exclusive operation
ok: [e451.net]

Then, if I try to deploy abralaboca.net, playbook try to deploy to the wrong server:

TASK: [deploy | Move project subtree into root folder] ************************ 
failed: [e451.net] => {"changed": true, "cmd": "mv /srv/www/abralaboca.net/releases/20151108120127//* /srv/www/abralaboca.net/releases/20151108120127", "delta": "0:00:00.027012", "end": "2015-11-08 12:01:44.563527", "rc": 1, "start": "2015-11-08 12:01:44.536515", "warnings": []}

Any clue will be appreciated

I’m guessing you are trying to host the two domains on a single DO droplet. If you’re actually trying to host the domains on separate droplets, disregard this entire reply.

The hosts/production file should have only one entry per droplet (i.e., per VPS). When your droplet will have multiple sites/domains, you must use a single generic entry for the droplet in your hosts/production file. The simplest is to use the droplet IP.

[web]
your.server.ip.here

[production:children]
web

After making that change, you will need to run server.yml. The playbook will connect to that single IP and loop over the sites listed in wordpress_sites, setting up WordPress for each site. Then the server will be ready for you to deploy the new site using deploy.yml.

2 Likes

Thank you again!

I did it. I got an error at deploy (I did a rollback command and deploy again with same results):

TASK: [deploy | Move project subtree into root folder] ************************ 
failed: [188.226.213.77] => {"changed": true, "cmd": "mv /srv/www/abralaboca.net/releases/20151108172720//* /srv/www/abralaboca.net/releases/20151108172720", "delta": "0:00:00.009846", "end": "2015-11-08 17:27:34.717080", "rc": 1, "start": "2015-11-08 17:27:34.707234", "warnings": []}
stderr: mv: ‘/srv/www/abralaboca.net/releases/20151108172720//CHANGELOG.md’ and ‘/srv/www/abralaboca.net/releases/20151108172720/CHANGELOG.md’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//CONTRIBUTING.md’ and ‘/srv/www/abralaboca.net/releases/20151108172720/CONTRIBUTING.md’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//DEPLOY_UNFINISHED’ and ‘/srv/www/abralaboca.net/releases/20151108172720/DEPLOY_UNFINISHED’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//LICENSE.md’ and ‘/srv/www/abralaboca.net/releases/20151108172720/LICENSE.md’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//README.md’ and ‘/srv/www/abralaboca.net/releases/20151108172720/README.md’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//composer.json’ and ‘/srv/www/abralaboca.net/releases/20151108172720/composer.json’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//composer.lock’ and ‘/srv/www/abralaboca.net/releases/20151108172720/composer.lock’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//config’ and ‘/srv/www/abralaboca.net/releases/20151108172720/config’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//ruleset.xml’ and ‘/srv/www/abralaboca.net/releases/20151108172720/ruleset.xml’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//vendor’ and ‘/srv/www/abralaboca.net/releases/20151108172720/vendor’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//web’ and ‘/srv/www/abralaboca.net/releases/20151108172720/web’ are the same file
mv: ‘/srv/www/abralaboca.net/releases/20151108172720//wp-cli.yml’ and ‘/srv/www/abralaboca.net/releases/20151108172720/wp-cli.yml’ are the same file

PLAY RECAP ******************************************************************** 
           to retry, use: --limit @/Users/aitor/deploy.retry

188.226.213.77             : ok=8    changed=2    unreachable=0    failed=1

Could you tell us what your wordpress_sites has for subtree_path? I’m guessing you have something like this:

subtree_path: /

If that’s what you have, and you haven’t adjusted your project structure to be like the example project, you can just comment out subtree_path for both your sites, then redeploy. It is commented out by default.

Trellis has some checks in place to handle trouble with subtree_path, but I think it probably doesn’t currently handle the scenario of subtree_path: /, which may cause the problem you’re having.

1 Like

It works! :smiley:

http://abralaboca.net/

In fact, I had nothing at subtree_path. I deleted “site” from previous configuration and it was empty. Commenting line, everything works.

A final related question: If I want to deploy one of the sites to prodution to another server, outside my DO droplet, how should be the hosts/production file?

Thanks a lot.

Goal. Site-1 on server-1, site-2 on server-2.

Trellis defaults. The Trellis default is to put all sites for an environment (e.g., all sites listed in group_vars/production/wordpress_sites.yml) on all servers listed in the hosts file (aka “inventory file”) for that environment (e.g., hosts/production). As discussed above, you can easily put multiple sites on a single server just by adding multiple sites to the wordpress_sites list. If you happen to list multiple server IPs in hosts/production, that would be a step toward setting up some kind of load-balancing, where all sites are being served from all servers (oversimplification).

Those Trellis defaults don’t accommodate the scenario you asked about: “site-1 on server-1 and site-2 on server-2”. Some customization would be required. I’ll list some options that come to mind and others can critique or expand on them. UNTESTED.

Option 1: Use a second Trellis project

Attitude: “For this project, I can’t spend much time tinkering. I’ll choose the most hassle-free approach to my goal, even if it is not particularly DRY.”

You could just leave your first Trellis project for site-1 on server-1, then create another Trellis project (separate code, etc.) for site-2 on server-2. I think that is perfectly respectable and will be reasonably easy to maintain.

Option 2: Add the two IPs to your hosts file but only deploy one site to each (bad hack)

Attitude: “I’m willing to tinker, but this time I’ll go with a shortcut instead of understanding. I’ve got a hack that appears to work and I’m unconcerned about unintended consequences that may bite me in the future.”

I discourage this approach, but it might work. You could stick with a single Trellis project but add the IPs for server-1 and server-2 to your hosts/production and run server.yml. That would provision the two servers so they are ready to receive a deployment of either site. Then, only deploy site-1 to server-1 and only deploy site-2 to server-2. I wouldn’t do this. I mentioned it only to provide a little more perspective on what the various hosts files and playbook files are doing.

Option 3: Use Ansible’s host_vars

Attitude: “I’m willing to tinker and I’m committed to understanding and finding an appropriate implementation for my slightly different use-case. I understand this will be more work to apply updates from the Trellis upstream to my customized fork, but I’m comfortable with having my fingers in the code.”

To achieve “site-1 on server-1 and site-2 on server-2” you need the wordpress_sites list to differ per server/host. You can use Ansible’s host_vars in two steps.

Step 1. Adjust hosts/production

[web]
site-1 ansible_ssh_host=site.1.server.ip
site-2 ansible_ssh_host=site.2.server.ip

[production:children]
web

Step 2. Add a new host_vars directory at Trellis root (e.g., next to group_vars directory):

host_vars/
  site-1.yml
  site-2.yml

Those two .yml files are copies of wordpress_sites, each with only the site info for the given site. You could also structure it with directories per site if you want:

host_vars/
  site-1/
    wordpress_sites.yml
  site-2
    wordpress_sites.yml

Once you have that set up, you don’t need to change your ansible-playbook commands at all. Things should work as normal. You may want to edit group_vars/production/wordpress_sites.yml with a note to yourself that wordpress_sites values are actually being drawn from the host_vars files.

UNTESTED. Would love to hear if it works for you.

EDIT. The host_vars in option 3 above makes no distinction between environments (e.g., staging vs. production). Perhaps there’s an easy way to address this next level of complexity, but I haven’t explored it yet.

7 Likes

Thanks for this ordered and explained list of options. I think, I should stay at a low level of complexity. So, option 1 seems more fit to my knowledge level (really I’m not a developer. I’m old school designer). Option 3 seems interesting, flexible, and not WET, but I can get in troubles easily. Maybe later, with a little more consolidated knowledge.

Thank you again for all the help.

2 Likes