Only staging site detected?

trellis
1

Stumbled thru the new setup with letsencrypt and got it working fine on a staging site. Was about to do the same thing for a production site and came to the conclusion at this point we can only do SSL once per trellis instance. No biggie.

I rolled back staging to http, and that’s fine. I setup production for https, provisioned, and then deployed. But it didn’t work:

Here’s the command I ran:

./deploy.sh production www.mydomain.com

And here’s the error I got:

TASK [Ensure site is valid] ****************************************************
fatal: [45.33.23.36]: FAILED! => {“changed”: false, “failed”: true, “msg”: “Site www.mydomain.com is not valid. Available sites to deploy: stg.mydomain.com”}

The wordpress_sites.yml is setup identical to the staging one, except the key is www.mydomain.com. This is the exact setup I usually use, but it’s not working now. I did a debug print in the yaml file for the {{ wordpress_sites }} before “Ensure site is valid” task. It only printed the stg.mydomain.com dict. It wasn’t an array of site keys.

1 Like
2

I think you’re running into the issue described here, which arises when your hosts/staging and hosts/production list the same IP. See that link for options to resolve the issue. There are some Trellis “validations” in development that will catch and warn about this, among other things.

I think it would “just work” if staging and production were on separate servers/IPs. I haven’t tried or looked into it, but it could probably also work with both on the same server. I wouldn’t recommend having both on the same server, but there are some discourse threads you could find on the topic (requires some adjustments).

3 Likes
3

Ah! They both do have the same IP. And I did notice the deploy.sh script no longer has the -I switch.

These aren’t the intended setup, but haven’t had the need to separate the servers yet.

Thanks for the quick answer, going to try this tomorrow!

4

If ever you want to use options like -i with deploy, you can use the regular ansible-playbook command. The deploy.sh is just for convenience in shortening the command, but you’re right that it doesn’t accommodate -i.

So, although I’d recommend option 1 from the other link, if you choose “Option 2 - Adjust your commands”, you could do this:

ansible-playbook deploy.yml -i hosts/production -e "env=production site=www.mydomain.com"
2 Likes
5

Yeah I’ll do option 1 just to make it clear in the future why I had it setup that way. After your explanation, the -i switch just made me realize that was the change in the setup that caused it stop working.

Thanks again!

1 Like