Report this

What is the reason for this report?

Automating the Deployment of a Scalable WordPress Site

Published on April 13, 2015
Automating the Deployment of a Scalable WordPress Site

Introduction

In this guide, we will create and deploy a scalable WordPress instance consisting of a MySQL database server, a GlusterFS distributed filesystem, Nginx web servers, and an Nginx load balancer. By using user-data and Droplet meta-data, we will automate the deployment of our site. Finally, we will provide a Ruby script which will automate this entire process and ease the creation of scalable Wordpress sites. Through this tutorial, you will learn about the power and flexibility of user-data and Droplet meta-data in deploying services on DigitalOcean.

Step One — Planning our Deployment

The deployment we create in this tutorial will consist of a single MySQL database server, multiple GlusterFS servers in a cluster, multiple Nginx web servers, and a single Nginx load balancer.

WordPress Deployment

Before we begin we should know:

  • What size Droplet we will use for our MySQL server
  • How many GlusterFS nodes we will create
  • What size our GlusterFS nodes will be
  • How many web server nodes we will need
  • What size Droplets we will use for our web servers
  • What size Droplet we will use for our load balancer
  • The domain name we will use for our new site

We can add additional nodes or scale up the nodes we created if we need to later. Once we have decided on these details, we can begin deploying our site.

Step Two — Deploying MySQL

We will begin by deploying our MySQL server. To do this, we will create a default Ubuntu 14.04 x64 Droplet using the following user-data.

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PUBLIC_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
export PRIVATE_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get -y install mysql-server;
mysqladmin -u root create wordpress;
mysqladmin -u root password "mysql_password";
sed -i.bak "s/127.0.0.1/$PRIVATE_IP/g" /etc/mysql/my.cnf;
service mysql restart;
mysql -uroot -pmysql_password -e "CREATE USER 'wordpress'@'%' IDENTIFIED BY 'mysql_password'";
mysql -uroot -pmysql_password -e "GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'%'";

This user-data script will perform the following functions on our new Droplet:

First, we export a variable which tells apt-get that we are running in non-interactive mode to prevent it from prompting for any input when it installs packages.

export DEBIAN_FRONTEND=noninteractive;

Next, we use Droplet meta-data to get the Droplet’s public and private IP addresses and assign them to variables:

export PUBLIC_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
export PRIVATE_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
Note: Droplet Meta-Data is not available in NYC1, NYC2, and AMS1 at this time.

We then use apt to install the MySQL server.

apt-get update;
apt-get -y install mysql-server;

Now we need to create a new database called wordpress.

mysqladmin -u root create wordpress;

Then we set a password for our MySQL root user.

mysqladmin -u root password "mysql_password";

Because our MySQL server will be accepting queries from our web servers, we need to have it listen on the private IP address rather than only on localhost. To do this, we will use sed to update the MySQL configuration file by doing a find and replace and then restart the service.

sed -i.bak "s/127.0.0.1/$PRIVATE_IP/g" /etc/mysql/my.cnf;
service mysql restart;

Finally, we will create a new MySQL user called wordpress and give it permission to access the wordpress database.

mysql -uroot -pmysql_password -e "CREATE USER 'wordpress'@'%' IDENTIFIED BY 'mysql_password'";
mysql -uroot -pmysql_password -e "GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'%'";

By deploying our new Droplet with this user-data script, we will have a configured MySQL server listening on its private IP address and with our configured database and user without ever logging in via SSH or the console.

Step Three — Deploying GlusterFS

Before deploying our GlusterFS cluster, we need to decide how many nodes we will deploy. There are two variables that will go into this decision. First, we need to decide how much space we need and then we need to decide on a replica setting to use. The replica setting tells GlusterFS how many copies of any file to store. For example, a replica setting of 2 will mean that every file is duplicated on at least 2 servers. This will cut our available storage in half since we are keeping two copies of each file but will provide improved redundancy. The number of GlusterFS nodes we create must be a multiple of our replica setting. For a cluster with a replica setting of 2, we will need to create our nodes in a multiple of 2 (so 2, 4, 6, or 8 nodes would be acceptable).

For this example, we will deploy a 4 node GlusterFS cluster using a replica setting of 2.

For our first 3 nodes, we will use the following user-data script:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
apt-get update;
apt-get install -y python-software-properties;
add-apt-repository -y ppa:gluster/glusterfs-3.5;
apt-get update;
apt-get install -y glusterfs-server;

Again, we first set the DEBIAN_FRONTEND variable so apt knows that we are running in non-interactive mode:

export DEBIAN_FRONTEND=noninteractive;

We then update our apt database and install python-software-properties, which is needed to add the PPA for GlusterFS.

apt-get update;
apt-get install -y python-software-properties;

Next we will add the GlusterFS PPA so we can grab our deb packages.

add-apt-repository -y ppa:gluster/glusterfs-3.5;

Then we will update our apt database again and install glusterfs-server.

apt-get install -y glusterfs-server;

For our first three nodes, this is all we need to do. Make a note of the private IP addresses assigned to each of these new Droplets as we will need them when creating our final GlusterFS node and creating our volume.

For our final node, we will use the following user-data script:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get install -y python-software-properties;
add-apt-repository -y ppa:gluster/glusterfs-3.5;
apt-get update;
apt-get install -y glusterfs-server;
sleep 30;
gluster peer probe node1_private_ip;
gluster peer probe node2_private_ip;
gluster peer probe node3_private_ip;
gluster volume create file_store replica 2 transport tcp node1_private_ip:/gluster node2_private_ip:/gluster node3_private_ip:/gluster $PRIVATE_IP:/gluster force;
gluster volume start file_store;
Note: If you do not want to enable replication you should not include the "replica" setting in your "volume create" command.

The first section of this user-data script is pretty similar to the one we used on the other GlusterFS nodes, though we are assigning our new Droplet’s private IP to the $PRIVATE_IP variable. Once glusterfs-server is installed, though, we do some additional work.

First, our script will wait 30 seconds for the new glusterfs-server to start up and be available.

sleep 30

Then we probe the three GlusterFS Droplets we created earlier in order to add all four to a cluster.

gluster peer probe node1_private_ip;
gluster peer probe node2_private_ip;
gluster peer probe node3_private_ip;

Next we will create our GlusterFS volume named “file_store” with a replica setting of 2 and including all four of our nodes. Since we wont know the IP address of our newest node yet we will use the $PRIVATE_IP variable for it.

gluster volume create file_store replica 2 transport tcp node1_private_ip:/gluster node2_private_ip:/gluster node3_private_ip:/gluster $PRIVATE_IP:/gluster force;

Finally, we will start the new volume to make it accessible from our clients:

gluster volume start file_store;

We now have a distributed filesystem where we can keep our WordPress files that will be accessible to all our web server nodes.

Step Four — Deploying Nginx Web Servers

Now that we have a database server and a distributed filesystem all set, we can deploy our web servers. We will use the following user-data script to deploy our first Nginx web server node and configure our WordPress installation inside our GlusterFS volume.

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get -y install nginx glusterfs-client php5-fpm php5-mysql;
sed -i s/\;cgi\.fix_pathinfo\=1/cgi\.fix_pathinfo\=0/g /etc/php5/fpm/php.ini;
mkdir /gluster;
mount -t glusterfs gluter_node_private_ip:/file_store /gluster;
echo "gluster_node_private_ip:/file_store /gluster glusterfs defaults,_netdev 0 0" >> /etc/fstab;
mkdir /gluster/www;
wget https://raw.githubusercontent.com/ryanpq/do-wpc/master/default -O /etc/nginx/sites-enabled/default;
service nginx restart;
# Get Wordpress Files
wget https://wordpress.org/latest.tar.gz -O /root/wp.tar.gz;
tar -zxf /root/wp.tar.gz -C /root/;
cp -Rf /root/wordpress/* /gluster/www/.;
cp /gluster/www/wp-config-sample.php /gluster/www/wp-config.php;
sed -i "s/'DB_NAME', 'database_name_here'/'DB_NAME', 'wordpress'/g" /gluster/www/wp-config.php;
sed -i "s/'DB_USER', 'username_here'/'DB_USER', 'wordpress'/g" /gluster/www/wp-config.php;
sed -i "s/'DB_PASSWORD', 'password_here'/'DB_PASSWORD', 'mysql_password'/g" /gluster/www/wp-config.php;
sed -i "s/'DB_HOST', 'localhost'/'DB_HOST', 'mysql_private_ip'/g" /gluster/www/wp-config.php;
chown -Rf www-data:www-data /gluster/www;

This script is a bit more complicated than our previous ones, so let’s break it down step by step.

First, we will again set the DEBIAN_FRONTEND variable as we have in our previous scripts and populate our $PRIVATE_IP variable.

export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)

Next, we will update our apt database and install Nginx, the glusterfs client, and the php libraries we will need.

apt-get update;
apt-get -y install nginx glusterfs-client php5-fpm php5-mysql;

Then we will use sed’s find and replace functionality to update our php.ini file and set the cgi.fixpathinfo variable to 0.

sed -i s/\;cgi\.fix_pathinfo\=1/cgi\.fix_pathinfo\=0/g /etc/php5/fpm/php.ini;

Now we’ll create a folder called /gluster in the root of our disk image and mount our GlusterFS volume there. Then we will create an fstab entry so our GlusterFS volume is automatically mounted when the Droplet boots.

mkdir /gluster;
mount -t glusterfs gluter_node_private_ip:/file_store /gluster;
echo "gluster_node_private_ip:/file_store /gluster glusterfs defaults,_netdev 0 0" >> /etc/fstab;

Then we will create a folder called www in our GlusterFS volume. This folder will act as our web root.

mkdir /gluster/www;

Next we will pull a new Nginx configuration file from a remote server. This file will set our web root to /gluster/www and ensure Nginx is configured to use PHP. You can view this configuration file here. Once we have replaced our Nginx configuration file we will restart the service for this change to take effect.

wget https://raw.githubusercontent.com/ryanpq/do-wpc/master/default -O /etc/nginx/sites-enabled/default;
service nginx restart;

Now we will grab a copy of the latest version of WordPress, extract it and copy its contents to our new web root.

wget https://wordpress.org/latest.tar.gz -O /root/wp.tar.gz;
tar -zxf /root/wp.tar.gz -C /root/;
cp -Rf /root/wordpress/* /gluster/www/.;

Next, we will copy the sample WordPress configuration file to wp-config.php.

cp /gluster/www/wp-config-sample.php /gluster/www/wp-config.php;

And update its variables to match our new environment, again using sed’s find and replace function.

sed -i "s/'DB_NAME', 'database_name_here'/'DB_NAME', 'wordpress'/g" /gluster/www/wp-config.php;
sed -i "s/'DB_USER', 'username_here'/'DB_USER', 'wordpress'/g" /gluster/www/wp-config.php;
sed -i "s/'DB_PASSWORD', 'password_here'/'DB_PASSWORD', 'mysql_password'/g" /gluster/www/wp-config.php;
sed -i "s/'DB_HOST', 'localhost'/'DB_HOST', 'mysql_private_ip'/g" /gluster/www/wp-config.php;

And finally, we will make sure that the files in our web root are owned by the user www-data which our Nginx process will be running as.

chown -Rf www-data:www-data /gluster/www;

We now have our first web server node all set up and ready to receive requests.

Since each of our web server nodes shares the same GlusterFS volume for storage, there are fewer steps for each additional node we create. For additional nodes we will use the following user-data script:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get -y install nginx glusterfs-client php5-fpm php5-mysql;
sed -i s/\;cgi\.fix_pathinfo\=1/cgi\.fix_pathinfo\=0/g /etc/php5/fpm/php.ini;
mkdir /gluster;
mount -t glusterfs gluster_node_private_ip:/file_store /gluster;
echo "gluster_node_private_ip:/file_store /gluster glusterfs defaults,_netdev 0 0" >> /etc/fstab;
mkdir /gluster/www;
wget https://raw.githubusercontent.com/ryanpq/do-wpc/master/default -O /etc/nginx/sites-enabled/default;
service nginx restart;

For our additional web nodes we will still be installing the same packages, mounting our GlusterFS volume and replacing our Nginx configuration file but we will not need to do any setup of our WordPress instance since we did this when creating our first node.

Step Five — Deploying Our Load Balancer

The final step in this deployment is to create our load balancer. We will be using another Nginx server for this purpose. To set up this node we will use the following user-data script:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
apt-get update;
apt-get -y install nginx;
lbconf="
server {
	listen 80 default_server;
	listen [::]:80 default_server ipv6only=on;

	root /usr/share/nginx/html;
	index index.php index.html index.htm;

	location / {
	  proxy_pass  http://backend;
	  include proxy_params;
	}

}

upstream backend  {
	ip_hash;
	server web_node_1_private_ip
	server web_node_2_private_ip
}
"
echo $lbconf > /etc/nginx/sites-enabled/default;
service nginx restart;

For our load balancer’s user-data script, we will be building our Nginx configuration directly in the script. We start off much as we did with our other Droplets by ensuring that apt knows we are running in non-interactive mode.

export DEBIAN_FRONTEND=noninteractive;

Then we will install Nginx:

apt-get update;
apt-get -y install nginx;

Next we will create our new Nginx configuration in a variable called lbconf. Adding an entry for each of our web servers in the upstream backend section.

lbconf="
server {
	listen 80 default_server;
	listen [::]:80 default_server ipv6only=on;

	root /usr/share/nginx/html;
	index index.php index.html index.htm;

	location / {
	  proxy_pass  http://backend;
	  include proxy_params;
	}

}

upstream backend  {
	ip_hash;
	server web_node_1_private_ip
	server web_node_2_private_ip
}
"

We will then write the lbconf variable to our Nginx configuration file, replacing its current content.

echo $lbconf > /etc/nginx/sites-enabled/default;

And finally, we’ll restart Nginx for this configuration to take effect.

service nginx restart;

Step Six — Setting Up DNS

Now, before we access our new WordPress site via the browser, we should set up a DNS entry for it. We will do this via the control panel.

In the DigitalOcean control panel, click on DNS. In the Add Domain form, enter your domain name and select your load balancer Droplet from the drop-down menu, then click Create Domain.

In order to use the www subdomain for your site you will need to create another record in this new domain.

Click Add Record and choose the CNAME record type. In the name field enter www and in the hostname field enter @. This will direct requests for the www subdomain to the same location as your main domain (your load balancer Droplet).

Step Seven — Configuring WordPress

Now that we have launched all our Droplets and configured our domain, we can access our new WordPress site by visiting our newly configured domain in a web browser.

Configure Wordpress

We will be prompted here to create a user account and give our new site a name. Once we have done this our deployment is complete and we can begin using the new site.

Step Eight — Automating the Process

Now that we can create our WordPress deployment without ever needing to ssh into a Droplet, we can take things a step further and automate this process using the DigitalOcean API.

A sample Ruby script has been created based on this tutorial which will prompt the user to provide the relevant details and then automatically deploy a new scablable WordPress instance. You can find this script on GitHub.

Conclusion

We now have a scalable WordPress deployment but there are additional steps we can take to ensure our new site is secure and stable.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products

About the author

Ryan Quinn
Ryan Quinn
Author
See author profile

Software Engineer @ DigitalOcean.

Still looking for an answer?

Was this helpful?
Leave a comment...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Dear Ryan,

this looks like a great tutorial. I haven’t tried it yet but it sounds very promissing.

I have a couple questions:

  • I want to use this for a scallable Woocommerce site. Is this appropriate or is it more written for a read-only Wordpress Site?

  • How many Digital Ocean Droplets do I need? Whats the minimum setup and do I have to actively do something to scale it or does it scale automatically?

Thanks!

This is exactly what I’ve been looking for! Great write up!

What size would you use for each droplet?

Wow thanks for that tutorial :)

How does the load balancer decide to which server route the traffic ? Is it based on just load of the nginx servers or on the location of the visitor ? (Noob question)

Thanks :)

Great article, thanks for sharing. I put something just like this together and added OpenVPN for secure communication between the droplets.

Hi Ryan,

I got one wordpress site running at shared hosting company here in Brazil. We are planning to improve our website’s performance and i found your article interesting.

Recently i have made some tests with the LON1, which had a great response.

Our site got 20gb+ in media upload, like photo galleries and is growing every weekend, as the database and queries.

Is this plan indicated to our case? Which locations seems better to Brazil?

We would like to have a staging environment too.

Thanks in advance,

Guilherme

Hey Ryan,

that looks really amazing! currently I´m run the following configuration on a droplet:

Percona DB (MySQL) (Looking for MariaDB? Try this) HHVM (Default PHP Parser) PHP-FPM (Backup PHP Parser) Nginx Varnish (Running by default) Memcached and APC Clean WordPress Install (Latest Version) WP-CLI

I followed this manual: https://github.com/zach-adams/hgv-deploy-full

I have two questions:

  1. Is there any chance you can merge these advanced features into your automation script to get the cluster even faster?

  2. And to add TomCat + lucee ? (which I use to build super fast REST-Services companions for Wordpress)…

https://registry.hub.docker.com/u/chapmandu/lucee-docker/dockerfile/

Really would appreciate if anyone could assist with that…

Best, Mario

Hi there.

Just wondering how to run the automatic script installer (https://github.com/ryanpq/do-wpc) that will setup the instance for me? Is it run in a current droplet, or my computers command line?

Thanks :)

Thats ok, I figured it out :)

I cannot say for certain if installing ServerPilot after the fact would affect this configuration. Currently this setup does all it’s communications (aside from public requests to the load balancer) on the private network interface so locking down the public interface would be advisable on the other nodes. I would expect that using ServerPilot to attempt to deploy any apps to the servers in this setup would likely cause problems.

I recommend dropping an email to ServerPilot at support [at] serverpilot.io and linking them to this tutorial to see if they can provide some clarification on whether installing SP would be advisable.

Whats the best way to configure SSL termination?

Hi Ryan,

Thanks for the tutorial. Really useful!

I have run into a problem to do with the necessary nginx configuration for URL rewriting (for pretty permalinks such as /%postname%/) and for custom 404 pages.

A few resources I’ve found online seem to provide working solutions for the posters involved. However, no game with my setup. I have a feeling it is because the load balance server does not actually hold the files - could this be the case? I cannot seem to get it to work.

Is there any special nginx configuration needed to reference custom 404 pages that are stored within the file_store volume and not on the load balance droplet itself?

Again, thank you for the tutorial and I appreciate you reading this.

Cheers,

Joe (on behalf of Lee)

Hello

I am trying to setup a cluster in which I can have wordpress Installed with glusterFS so that The master node will be running the actual copy of wordpress and other two nodes will have its replica. Also I want to setup the Master slave Mysql setup. I have installed Mysql server, GlusterFS server, nginx server on three droplets and fourth one have Nginx Load balancer Installed. The problem is that I am not able to create a GlusterFS volume, below are the errors I am getting during building that FS.

command used : gluster volume create file_store replica 2 transport tcp master.com:/gluster slave1.com:/gluster slave2.com:/gluster slave3.com:/gluster force;

gluster volume create file_store replica 2 transport tcp master.com:/gluster slave1.com:/gluster slave2.com:/gluster force;

gluster volume create file_store replica 2 transport tcp master.com:/gluster slave1.com:/gluster force;

I tried these commands and also tried Private IP in place of hostname and also tried doing it by removing force in the end.

Here is the error which I got.

Wrong brick and use <hostname> etc etc or “operation failed”

Please help me resolve the issue. I have been developing it by using you tutorial

https://www.digitalocean.com/community/tutorials/automating-the-deployment-of-a-scalable-wordpress-site

I have followed all the steps as they are in doc but not worked for me. I am stuck at GlusterFS now.

Please Help.

Thanks

Hello and great work

can i start with this configuration as a startup :

1x MySQL server 1 GB 2x GlusterFS nodes 512MB in each node 2x Nginx web nodes 512MB in each node 1x Nginx load balance 512MB

I’m confuse with VPS. now keep using SHARE hosting -_-

Replying to devprolabs

This is a fairly complex configuration. If you’re coming from shared hosting and just looking to get a WordPress site up and running, this option is much easier to get set up.

I am running a couple of servers on amazon and also here on digitalocean and would like to transition all of them here and this looks like a very good way to do that, what I am thinking is a couple of things;

  1. is there a good way to add a master - slave setup for mysql
  2. is there a easy way to add a cache server in the mix or set it up with the load balancer
  3. and this should be easy to adapt to run more than one wordpress site, I host a dozen or so.

my setup would be

1 x mysql 2GB or 2 x 2GB in master slave 4 x GlusterFS 1GB 2 x nginx web 1GB 1 x nginx LB 1GB

to begin with

with kind regards Halldor

Hi Ryan; Good and fresh one; may i ask you quick question: What would you suggest for: Back up ( file & MySQL ) with a easy way for recovering WordPress in cash of crash

Case of need to upgrade from a server size to much bigger ( eg : a 1 g memory to more ) in this configuration

And for HTTPS

Thanks for feedback

I’m having a little trouble with starting the setup process. When I create the droplet, do I select the ‘User Data’ checkbox and paste in the user-data script in the tutorial? Since I don’t know the IP addresses at this point, it doesn’t seem like the assignments to the variables in the script would work, so it’s kind of confusing. I tried setting it up without this and entered the commands one by one in the console for the droplet, but the mysql server failed to restart after line 10 of Step Two.

Also, when setting up the droplets, are there any other settings/boxes I need to select, like ‘Private Networking’? Thanks!

do i have to put in an ssh key in the create_cluster.rb file for this to work? i keep getting an error when I try to run it saying that:

/var/lib/gems/2.1.0/gems/droplet_kit-1.2.3/lib/droplet_kit/mappings/error_mapping.rb:16:in ‘fail_with’: are invalid key identifiers for Droplet creation. (DropletKit::FailedCreate)

I have 2 ssh keys in my account’s security section, but I don’t see the id number anywhere, just the name, fingerprint and public SSH key.

Ok, I have the cluster set up and loaded my wordpress files through the WP Clone plugin in the wordpress dashboard. However, when I view the site, the content and media aren’t loading at all. Am I missing something? The cluster version of the site is here: http://45.55.147.255/

I’m unable to make automount work, after I power off and reboot glusterfs client that also is the nginx server nothing happen I have to mount it manually using Ubuntu 14.04 64bits Glusterfs 3.5

I think this configuration is what I’ll need in the future. However, is there a nice ‘starting’ point that I can implement which will allow the adoption of this model? For instance, can I simply start out with a web server and MariaDB server (2 servers)? Storage will be on the web server. Then, when growth is needed, separate into the file cluster model and implement another web server and load balancer?

Would this be doable or would it add a lot of complexity into things since it will require separating the storage from the web server after the fact?

Have you thought about creating a NGINX setup script for wordpress, like the one you have here: https://github.com/digitalocean/do_user_scripts/blob/master/CentOS-7/cms/wordpress.sh

I know there are a few workarounds, but it would be nice to have Apache/Nginx setup scripts on there.

Awesome tutorial. Thanks Ryan. I was thinking of using part of this tutorial to create webservers located in different regions with a load balancer sending users to their neareast webservers. But it looks like private IPs are only accessible in the same region. Any recommendation on how to build such a configuration? Thanks.

Does this require the use of digital oceans DNS? I’d prefer to leave the dns somewhere else if possible. I have a word press site that gets tons of hist for a 2 week period shortly after the first of the year every year and I’m looking for ideas to scale out vs scale up.

This comment has been deleted

Tremendous work Ryan.

Can you please share some detail how i can install ssl certificate on my wordpress website which is hosted in dedicated server.

And what if the DB server is down?

Hello Ryan

this is a very great tutorial. Great Thanks!!!

But i have 2 questions:

  1. do you have the same tutorial for Joomla 3.5 and php7?
  2. If i use the glusterfs nodes with a 10GB SSD for the core, and a 100GB SSD as storage, and later i add a second SDD. How to do?

I’d like to have a crack at this as I use the Roots.io system for wordpress. Bit of a newbie so i apologise now…

Where the hell am I running these commands? On the droplets themselves or through the API on my Mac?

Hi, Is there a 1-click script that I can use to deploy these servers? If not, do I have to create all the droplets first, or does the creation of droplets happen from an existing droplet’s console? Sorry to ask silly questions. Sam

Creative CommonsThis work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International License.
Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Get started for free

Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

*This promotional offer applies to new accounts only.