Your thoughts on rebuilding droplets with 16.04

trellis
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