So many options! #CreateADigitalOceanDroplet without a lot of fuss for #WordPress.
Creating a WordPress droplet on Digital Ocean is not hard. In fact, it is downright easy. That is, the actual creation of it is. Deciding how to create it took me longer than actually doing it, as I found myself creating it, messing up, destroying it, recreating it, and so on. Once out the door, however, it wasn’t all that difficult.
Part of the problem is that there are several tutorials online and even on their site on how to create a droplet. However, the one you need may or may not pop up on the top of the search.
The overall process is to create the droplet, modify the droplet, test the droplet and then snapshot the droplet. This is what we will cover here. Afterwards, we will do the backup and restore of the old site in order to move it.
After a few false starts, I realized that there is a “one-click” install for a WP droplet. This shouldn’t be confused with WordPress’ so-called “10 Minute Install”.
The obvious advantage of the “One-Click Install WordPress on Ubuntu 14.04 with DigitalOcean” is that you get Ubuntu, LAMP and WordPress all installed in one shot. It is tailored just for WP hosting. The downside would be if you wanted to do something really different, say install on nginx instead of Apache.
When you set it up the first time, you’ll probably have to install using the IP address, unless you have a spare hostname or something. This will be changed after the backup and restore process.
Before fooling around with SSH, however, you will probably want to setup a “normal” user and use sudo to do your work online. You will likely want this user to also be part of the adm group (to view Apache logs) and www-data (group that owns /var/www in the droplet).
It will prompt you for a password, password confirmation and some administrative info (the latter of which is optional).
adduser <username> users adduser <username> adm adduser <username> sudo adduser <username> www-data
Now, ssh into your droplet with the user you just created.
ssh <username>@<droplet address>
It will prompt for the password. Then, type:
It will again prompt for the password, and it should at this point display nothing because there are no files in the <username> home directory yet.
Next, ensure you can read the Apache logs with the new user account:
After you verify the account and accessing the droplet using the DNS canonical name are both working, there are additional items you’ll probably want to add. At the end of the tutorial I pointed to, perhaps the most important to work on first is to get ssh working. This is important, for this is how you will do a great deal of your work unless you install a control panel for yourself. It also will help you copy files up to the server, as regular FTP does not work out of the box.
If the DNS is not yet working, you probably should hold off on the ssh keys, however.
Anyhow, I would not do it the way most of the tutorials tell you to do it. The key creation is OK in “” if you are on Linux or Mac OS X, but life seems to work better if command line arguments are used to copy the user key into the user account.
If you haven’t yet created the key for the username yet:
ssh-keygen -t rsa -C "<username>@<droplet canonical name>"
Then, you will copy it to the droplet under the username:
ssh-copy-id <username>@<droplet canonical name>
To copy the key, it will prompt for the password, and copy it to the droplet.
Try logging in, and it should not prompt for a password now.
I’d also get rid of the Apache additional password for wp-admin and install PhpMyAdmin. I would not install ProFTP personally, as there are better ways, but I’ll cover that later.
You should now take a snapshot. I labeled mine “Step 1”, seeing as it was more or less contained in the first tutorial.
Next, you will want to send a test email. Out of the box, the WP droplet does not install the mail utility, but if you run it from the command line, it should tell you to install “mailutils”. Heaving said that, I was still banging my head because some emails were working, but not all.
I ended up following the advice to install exim4 in “WordPress email notifications“, in that I ran:
apt-get --purge autoremove postfix apt-get install exim4-daemon-light mailutils dpkg-reconfigure exim4-config
There are more complete instructions in “Send-only Mail Server with Exim on Debian 6 (Squeeze)“. Ubuntu is based upon Debian, so the instructions are the same, although I noticed that one menu item was missing from the actual install, suggesting a newer verosion of exim.
Be sure to test:
echo "This is a test" | mail -s "Test" email@example.com
At this point, I highly suggest taking a snapshot and watching for 500 errors in the Apache logs.
Moving a droplet can be tricky business, and if you have more than one domain pointing to a domain, it is trickier still. DigitalOcean puts the IP address for the Servername in apache2.conf under the VirtualHost section, .and I don’t think that is correct. Instead, put the canonical name there, and if you have other domains or variations of the canonical name, put them as entries for ServerAlias. In the 24 hours following those changes, I have had only one 500 error caused obviously by a bot (so who knows what it did to trigger it).
You should do “Additional Recommended Steps for New Ubuntu 14.04 Servers“. All of them. Again, be sure to take a snapshot and then test, test and test some more.
Once this has been complete and there are no errors in the logs, you are ready to do a restore. On shared hosting, you may have used FTP to move files around, but by default DO doesn’t allow it. You can, of course, override this, but why bother when there are more secure methods available? In particular, if you manually copy files back and forth, the excellent FileZilla can do “SFTP”.
I also played around with scp, which is a nice utility for manual copies, but I was used to wget, which can be scripted. I found out that you can use rsync to do the same thing on DigitalOcean, however, and I was set!
The exact method you use will, of course, depend upon how you did the backup on the old server.
Again, be sure to snapshot and test, test, test!
At this point, you could even go live, but that doesn’t necessarily mean you are finished. However, this is a good foundation upon which to move forward.