Roots Discourse

Your thoughts on rebuilding droplets with 16.04

trellis
#1

I’ve deployed a few projects with Trellis now and it has vastly improved my workflow and confidence level when making changes to existing sites. I’m even slowly migrating a few key clients from older, vanilla WordPress setups to Trellis.

So looking into the future I see that Trellis recently bumped their Ubuntu version to 16.04. This is a piece of site maintenance I hadn’t given much thought to so far, so I’m looking for opinions from the community. Do you plan to rebuild your droplets with 16.04 for older projects?

The process seems pretty straight forward, though requiring some downtime for the site:

  1. Back up database and uploads from live site
  2. Merge Trellis changes into existing project from latest Trellis version (in my case mostly just copying stuff from all the wordpress_sites.yml, vault.yml, and hosts files)
  3. Test everything in a staging droplet
  4. (downtime) Rebuild the live droplet with 16.04, reprovision with Trellis, deploy, import database and uploads.

Like I said, pretty straight forward, but time consuming and requiring a small amount of downtime.
So what do you plan to do? Are you going to rebuild your 14.04 boxes with 16.04? If not, why not?

Thanks for your time.

1 Like
#2

I’m actually in the process of rebuilding the https://roots.io server.

Yes you should ideally use Ubuntu 16.04 because it’s required to get HTTP2 working.

Keep in mind you don’t actually need any down time. We just spin up another droplet and use our local hosts file to fake DNS. Then once the server is ready, you switch the DNS over to the new server.

You could also take advantage of DO’s floating IP feature to just point it to a new server (I think, never used it).

1 Like
Failure to establish connection when provisioning via ansible-playbook server.yml
#3

Faking DNS makes sense, but doesn’t it prevent Let’s Encrypt from working? Or do you just launch without https and reprovision once DNS propagates to get the new cert?

#4

I actually updated my site (https://cfxdesign.com) on the night of the bump. Been meaning to write a walkthrough but here are my notes from that night:

  1. Backup your original site’s database and uploads directory.
  2. Create a new droplet running Ubuntu Xenial 16.04.1x64
  3. Edit your zone file and point a new subdomain to the new droplet, e.g. xenial.mydomain.com.
  4. Now create a new environment. For this I copied group_vars/production to group_vars/xenial and hosts/production to hosts/xenial. In my group_vars/xenial I changed the site host URL to reflect my new subdomain and in hosts/xenial I edited the IPs to reflect my new droplet’s IP.
  5. Provision your new Xenial droplet.
  6. Deploy to your new Xenial droplet.
  7. You’ll now need to copy over your db backup and uploads dir. To push uploads you can use this playbook (Pushing or pulling uploads with Trellis) and to copy your db you can use rsync -avz along with wp-cli to import and change the URLs in your db (there may be a playbook for this out there).
  8. Verify that xenial.mydomain.com is working.
  9. Now we’ll pull a little switcheroo and make our Xenial install our main install. Edit your Xenial wordpress_sites.yml site host back to your original domain, mydomain.com and delete your SSL certs on the Xenial droplet (like this Let’s Encrypt issue when adding new domain to multisite)
  10. Change the URLs on your Xenial droplet db to your original URL with wp search-replace '//xenial.mydomain.com' '//mydomain.com'
  11. Point your DNS @ record to the xenial droplet’s IP.
  12. Run ansible-playbook server.yml -e env=xenial --tags "wordpress"
  13. Run ansible-playbook server.yml -e env=xenial --tags "letsencrypt"
  14. Now you can remove the subdomain A records from your DNS config and delete your original, outdated droplet running Trusty 14.04.
  15. You can and should rename your original environment and your new environment (production -> production_old and xenial -> production). The only deploy variable that will be affected by this is your database name. Unless you specified it, your db_name is set to <site name>_<env> when you provision your server. You can either change the db name on your server or in your wordpress_sites.yml. Now your deploys work just as before.
  16. Profit.

Total down time was just the few minutes it took to generate the new SSL certs (although it’s highly recommended to ensure you haven’t reached your SSL certificate limit before embarking on this whole thing).

6 Likes
#5

Good point. In our case we still have a paid certificate that we’re using so that’s not an issue.

Trouble Re-provisioning Live Production Server - non-zero return code during Letsencrypt task
#6

Okay so I did this yesterday with one of my droplets and it went pretty smoothly. The hardest part was making sure I migrated my configs properly, and adjusted them for the changes in Trellis (like the new vault users).

I spun up two new droplets, one for staging 16.04 and one for the new production environment; deployed to new staging, confirmed everything worked, deployed to new production, and deleted old production once I was sure DNS had propagated.

I went with the “small amount of downtime” approach. Basically I updated DNS and then just tried reprovisioning once every 2 minutes or so until LetsEncrypt got the updated record and was willing to issue the cert. At this point my company’s ISP hadn’t even gotten the updated DNS so it’s possible the Internet didn’t even notice the outage.

All in all the process was detailed but not complex or difficult. Thinking about what it would take to upgrade the OS on my old shared hosting servers gives me ulcers. The relative ease here was a huge relief.

Thanks, Trellis team!

1 Like
#7

Awesome!

We’ve re-created roots.io 2 or 3 times now and it’s honestly the best part about using a tool like Trellis. You gain a huge amount of confidence trust when you know your server is basically disposable and you can re-create it identically if needed.

Just copy over uploads + database and that’s it (if they are on the local server even).

2 Likes
#8

I think the few minutes downtime could be avoided by copying over the production cert and key to xenial, or is there anything preventing this? Often thought of it, never tried…

#9

Not sure, try it out! I suspect the different IPs might be a problem but I could be wrong.