In this tutorial series, we are setting up a highly available WordPress web site from scratch.
Part 1 – Introduction, Considerations, and Architecture
Part 2 – Setting Up the VPSes
Part 3 – Setting Up MariaDB Multi-Master Replication
Part 4 – File Replication and Setting Up DRBD
Part 5 – Setting Up OCFS2
Part 6 – Round-Robin DNS, Let’s Encrypt, & Conclusion
Configuring Round-Robin DNS
Our final step is to setup round-robin DNS. This should be straightforward with whatever DNS provider you’re using. If your DNS provider’s interface doesn’t specifically have a RRDNS setting, you can usually just enter multiple A records. In this case, I entered the following records:
www.lowend.party in A 1.1.1.1 www.lowend.party in A 2.2.2.2
Configuring Let’s Encrypt
We’re going to exploit our shared storage to make setting up Let’s Encrypt with certbot a snap. First install these packages on both nodes:
apt-get install certbot python-certbot-nginx
Now we’ll move our nginx and letsencrypt configurations to the shared storage. Stop nginx on both nodes:
# systemctl stop nginx
On web1, move the config directories to /web:
mv /etc/nginx /web mv /etc/letsencrypt /web
And link on web1:
ln -s /web/nginx /etc/nginx ln -s /web/letsencrypt /etc/letsencrypt
On web2, replace the existing configs with links:
rm -rf /etc/letsencrypt rm -rf /etc/nginx ln -s /web/nginx /etc/nginx ln -s /web/letsencrypt /etc/letsencrypt
And then start nginx on both nodes:
systemctl start nginx
Now we can run Let’s Encrypt’s certbot as usual. On web1:
# certbot --authenticator webroot --installer nginx Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer nginx Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): raindog308@raindog308.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: a - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: n Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: www.lowend.party - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel): 1 Obtaining a new certificate Performing the following challenges: http-01 challenge for www.lowend.party Input the webroot for www.lowend.party: (Enter 'c' to cancel): /web/www.lowend.party Waiting for verification... Cleaning up challenges Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/www.lowend.party Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/www.lowend.party - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://www.lowend.party <snip>
And you’re done! Because both /etc/letsencrypt and /etc/nginx are immediately visible on both nodes, you’ve setup Let’s Encrypt on both nodes.
You can play with shutting down nginx on one node and loading the site in your browser, then restarting it and shutting down the other node and reloading. When the browser can’t connect to the IP it was using previously, you may see a 2-3 second pause and then the site will load from the other node.
When the certbot renew job fires (run systemctl show certbot.timer to see details), Let’s Encrypt can talk to either nodes to validate because they’re both serving the same filesystem for web content.
Adding More Sites
This configuration is fully enabled for more WordPress sites if you want to add more domains. All you need to do is use /web as your web root. Nginx configuration will be identical on both nodes (since it’s on shared storage). We’ve configured MariaDB to replicate all databases, so any new databases will be automatically picked up and replicated.
Wrapping Up
I hope you’ve enjoyed this tutorial, which has taken you from bare metal nodes to a highly-available, fully-replicated WordPress web site.
Related Posts:
- Merry Christmas from LowEndBox! - December 25, 2024
- We are Social Butterflies!Check Us Out Wherever You Browse, View, or Tap! - December 23, 2024
- Let’s Celebrate the Winter Solstice with Awesome Deals and a Free Bonus Code for RackNerd’s Giveaway! - December 22, 2024
It will be great add another part with in details to host multiple sites.
Just a small remark: The way you set this up, certbot-renew will be fired only on vps1 (web1) because you generated certificate there (crontab-entry has been auto-created). I recommend to check vps1-crontab, copy the certbot-renew entry and paste it into vps2-crontab (with slightly shifted execution time, so that it does not fire at both vps1 & vps2 at the same time)…
And one more thing: that round-robin dns entry is not very reliable. With so many caching dn-servers (and dns-caching clients) there is high chance client gets the same IP reply, no matter how many times it asks for it. You could partially eliminate this by setting short TTL-value (short caching time), but then it puts higher load on authorised dn-servers…
This was a great tutorial I wanted to know how to do this a loong time ago. Specially the DNS round robin thingy.