In this post I’ll explain how to run a WordPress site using Azure services for managed MySQL and App Services for a PHP application.
The basic offerings for MySQL and App Services create these resources in a public subnet, so in order to integrate them with your VNETs, you’ll have to use the more expensive options. In this post, we’ll use just that. We’ll create the MySQL database without any public access and integrate the App Services to connect to the SQL database internally.

VNET/subnets

First, we’ll create a VNET with three subnets. When you integrate an App Services in a VNET, the subnet where the App Services will reside must be empty. The same applies for Flex MySQL servers. You can have multiple Apps in the same dedicated subnet. So, you need a dedicated subnet for both App Service and MySQL Flex, but not for MySQL single server. Single MySQL server can share the subnet with other resources.
For MySQL, there are two options. We can use a private endpoint or a VNET integration. We’ll go with a private endpoint first. We don’t need a dedicated subnet for this.
In my case, I’ll create a VNET with 192.168.100.0/22 CIDR and three subnets, 192.168.100.0/24 for some Infra/MySQL stuff, 192.168.101.0/24 for the App Services and 192.168.102.0/24 for Flex MySQL. I’ll use a new resource group called rgWordPress. The VNET will be called vnetWordPress and the subnets, subInfra, subApp and subMySQL respectively.

VM

I will also create a VM in the subInfra subnet. This VM is not needed at all, it will be used to test connectivity. In my case, I’ll spin a new Debian 1CPU, 1GB VM and I’ll install the MySQL client.

sudo apt install default-mysql-client

Managed Single server MySQL

When it comes to MySQL, there are two options: Flexible server and Single server. Look at this link to determine what you want to use. In most of the cases, you’ll use a Flexible server. But there are some limitations in both use cases. For example, a Flexible server can’t use private endpoints. You are limited to VNET integration and Single server can’t be VNET integrated. On top of that, only General Purpose and Memory Optimized servers can have private endpoints. The basic single server can be public only. Flex VNET integrated servers require dedicated and empty subnets. There are other limitations as well, so take a look at the link above.
In my case, I am using a General Purpose server.

Once you create the server, it will be public. As you can see from the Overview for the server, there is a public DNS record.

On the left side/blade, under Security, click on Private endpoint connections and create one.
Name the private link and put it in the same resource group as the other resources.

For the resource type Microsoft.DBforMySQL/servers and you’ll be able to select the newly created MySQL server from the dropdown under Resource.

Finally, choose the virtual network and subnet where you want to put the private link. Do not use the subnet for App Services. In addition, make sure that the integration with the private DNS zone is set to Yes.

If you log to the server that we just built and try to resolve the public DNS for the MySQL server, you’ll see that it resolves as a private IP. That’s because you have a private DNZ zone that takes precedence over the public DNS.

In case, you are still getting the public IP, go to the Private DNS zone and make sure that it’s linked to the actual VNET.

Now you can try to connect to the MySQL database.

mysql -u klimenta@mysqlwordpress-single -h mysqlwordpress-single.mysql.database.azure.com -p

Where -u specifies the username and the -h is the host. These parameters are under Overview on the right side. See the screenshot above.
You might get the following error. ERROR 9002 (28000): SSL connection is required. Please specify SSL options and retry.
In that case, download the SSL certificate and try again.

wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
mysql -u klimenta@mysqlwordpress-single -h mysqlwordpress-single.mysql.database.azure.com -p --ssl-ca=BaltimoreCyberTrustRoot.crt.pem

In case you are wondering, wait, why this cert? – The answer is here.
As you can see, I am able to connect now.

It is also recommended to disable the public access. Go to Connection security under Settings and select Yes for Deny public network access.

App Services

Go to App Services and create one. Make sure you use Premium offering so you can do a VNET integration. The initial parameters are self explaining. Use the defaults for the rest of the screens. You won’t be able to do much with PHP anyway.

Once the app is provisioned, on the left side/blade, go to the Networking menu under Settings. You’ll see that the VNET integration is not configured. Click on the link.

Pretty much, you have to select the VNET and an empty subnet. As you can see, I can only select subApp from the dropdown.

Close the blade and from the App menu, click on SSH under Development Tools on the left. This will open a new tab in your browser with a SSH session.

We have to create the WordPress database now. You can do that from the test server that we used initially or from the actual SSH session. Let’s use the SSH session. It already comes with mysql client preinstalled.

wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
mysql -u klimenta@mysqlwordpress-single -h mysqlwordpress-single.mysql.database.azure.com -p --ssl-ca=BaltimoreCyberTrustRoot.crt.pem

Once in MySQL client, execute these SQL statements.

CREATE DATABASE dbwordpress;
GRANT ALL PRIVILEGES ON dbwordpress.* TO "wordpressuser"@"%" IDENTIFIED BY "SuperSecret";
FLUSH PRIVILEGES;
EXIT

Replace the values with yours for the database name, MySQL host name, username and password.
Now, you can download WordPress and extract it.

cd /home/site/wwwroot
wget -c http://WordPress.org/latest.tar.gz
tar -xzvf latest.tar.gz
mv WordPress/* /home/site/wwwroot/
rm -rf WordPress
rm -rf latest.tar.gz

Once completed, go to the URL for the app. It should be under the Overview. You have to provide the database name (dbwordpress), username (wordpressuser@mysqlwordpress-single), password (SuperSecret) and the database host (mysqlwordpress-single.mysql.database.azure.com).
Most likely you’ll see an error. The easiest way is to disable the SSL requirement for the MySQL database from Connection security under Settings for the database.

If this doesn’t work for you, you’ll have to manually specify the parameters in wp-config.php. You can search this on your own.
Once you are done, specify the values in WordPress install screen and you are all set.

Flex MySQL server

Let’s see how Flex MySQL server works. Go to Azure MySQL but this time provision a flex server.
This is how my setup looks like.

…and this.

A flexible MySQL server can’t have a private endpoint, but it can be VNET integrated, same as the Azure App Services. And if you choose for the flex server to be VNET integrated, you’ll need a dedicated and empty subnet, same as Azure App Services.

Once you provision the flex MySQL server, you’ll be able to manage it the same as a single server with a private endpoint. You can also see the entry in the private DNS zone for a flex server, same as with the single server. A flex server also allows you to have a hot standby HA pair but you can’t use this hot standby as a replica. A HA will double the price and you won’t be able to create replicas. The HA is in a different zone but in a same region and it allows forced and automatic failovers. And if you want to use a read only replica (up to 10), you have to take care of the SQL proxying using ProxySQL, HAProxy or Nginx.
So, if you want some sort of HA for the MySQL, go with the flexible MySQL. You’ll have automatic failover within the region. But if you want to recover from a regional failure, use a single MySQL server with a read replica in another region (flexible MySQL can’t have replica in another region) and when you need to failover, just promote the replica in a standalone server (you’ll also need an Azure App Service in the DR region). The bad thing is that once you promote a replica in a standalone server and the original regions comes back up, you can’t revert the DR MySQL server in a replica again.

Rocky Linux was finally release today (5/1/2021) and I’ve decided to try it in my lab. I’ve downloaded the minimal ISO (Rocky-8.3-x86_64-minimal) and installed it under my vCenter version 6.x.
I chose CentOS 8 as a base OS and after I mounted the ISO, I got an error saying ERROR Verification failed: (0x1A) Security Violation. If this is the case, shut down the guest, go to Settings | VM Options and if you expand Boot Options, change the Firmware from EFI to BIOS. This should do the trick.

What you’ll see next is pretty much the same as any other CentOS 7/8 installation.

NOTE: The current version is not considered for production.
Do the same as you do with any other CentOS install. Partition the hard drive, change the root password, configure the network and add a user.

Once the server is up, you’ll see the login prompt.

Check the kernel version and the release.

uname -a
Linux rocky.andreev.local 4.18.0-240.22.1.el8.x86_64 #1 SMP Mon Apr 12 04:29:16 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/redhat-release
Rocky Linux release 8.3

By default, both the firewall and SELinux are enabled.

systemctl status firewalld
sestatus

You can use dnf, yum or rpm to manage the packages. If you need to change the network settings, use nmtui.
Let’s install WordPress now. As root or using sudo, install Apache, PHP and MariaDB.

dnf install httpd php php-mysqlnd mariadb-server wget php-json

Start the Apache and MariaDB and enable them on both to start on reboot.

systemctl enable httpd --now
systemctl enable mariadb --now

Open port 80 on the firewall for the Apache.

firewall-cmd --permanent --zone=public --add-service=http --permanent
firewall-cmd --reload

Do the initian MariaDB configuration and specify the new root password for the SQL server.

mysql_secure_installation

Log as the SQL root user to MariaDB.

mysql -u root -p

Create the database and the WordPress user.

CREATE DATABASE wordpress;
GRANT ALL ON wordpress.* TO 'wpadmin'@'localhost' IDENTIFIED BY 'supersecret';
FLUSH PRIVILEGES;

Get the latest WordPress release under /tmp, unzip it and copy it where it belongs (root Apache data directory).

cd /tmp
wget https://www.wordpress.org/latest.zip
unzip latest.zip
mv wordpress/* /var/www/html/
chown -R apache:apache /var/www/html

Change the SELinux context for the root Apache data directory.

chcon -t httpd_sys_rw_content_t /var/www/html -R

At this point, you can access your WordPress install at http://your_IP_or_hostname.

I got an invitation to attend an event in NYC for the Alibaba cloud, so I decided to play a little bit with their cloud offering. I was actually surprised to see that they are doing a really good job. While many features are still not there, the ease and simplicity of Alibaba cloud is a plus. If you are familiar with AWS, it won’t take you more than 5 minutes to feel comfortable. The interface, although different is very intuitive. You can get a free trial (a credit card and phone verification are needed) and start playing. Visit this link to start. Once you open an account and verify it, you’ll be presented with a console.
I’ve decided to demonstrate how to start in Alibaba Cloud by building a WordPress site running on two instances behind a load balancer. The database will be a MySQL RDS offering from Alibaba. They still don’t offer NFS filesystem, so I had to create an instance for that. First thing first.

VPC

The ubiquitous VPCs from AWS are named the same in Alibaba and they serve the same purpose. From the top menu choose a region, from the left click on Virtual Private Cloud and then click on Create VPC.

I’ll name my VPC, TestVPC and the CIDR (size of the VPC in terms of available IPs and subnets) is going to be 192.168.0.0/16 (which is default).

If you scroll down, you’ll see that you’ll also have to create a VSwitch. A VSwitch is nothing by a subnet or availability zone (AZ) in AWS terms. My first one will be called VSwitchA in Virginia Zone A and I’ll carve a smaller subnet 192.168.1.0/24 for that.

Let’s create another one, but this time in a different zone. The subnets can’t overlap. On the left side, you’ll see the menu for VSwitches, so click there and then click on Create VSwitch.

Do pretty much the same as previously. Choose the right VPC this time, name the VSwitch, choose the second zone and choose a different subnet. In my case it’s 192.168.2.0/24.

Security Groups

We’ll need several Security Groups. From the top left menu, click on Security Groups and the click on Create Security Group from the top right.

For the Load Balancer, we’ll need a security group that will allow port 80 from everywhere (0.0.0.0/0). For the two instances that will run Apache and PHP, we’ll allow port 22 only from specific addresses and port 80 allowed from the load balancer only. We don’t want the actual instances to be exposed on port 80 on the Internet. For the RDS instance, we’ll create a security group that allows port 3306 (MySQL) from the two instances only. Finally, for the NFS server, we’ll also allow access from the two instances only on port 2049 (TCP).
Here is an example of what I did for the first security group. I choose a custom template, named it sgLoadBalancer, added a description and chose my TestVPC.

You can’t create the rules like you do in AWS, but once you create the security group, you’ll see a pop-up reminding you to create the rules. Click on Create Rules Now.

This is how my rule for HTTP traffic looks like.

Name the second security group sgInstances, but before you create the group copy the security group ID for the first group that you created.

When you add the rules for the 2nd security group for the instances, make sure that you change the Authorization Type parameter to Security Group instead of IPv4 CID Block. This way you can specify that another security group has access to a specific port, not an IP. We don’t know the IP of the load balancer and it probably changes from time to time.

You have to create another rule for the instances. This time for the port 22. I chose to restrict port 22 to my home IP only. This is how those rules actually look like once created.

For the next two security group, copy the security group ID of the newly created group sgInstances.
Create two new security groups, sgRDS and sgNFS. For sgRDS allow port 3306 from the security group ID of sgInstances and for sgNFS allow port 2049 for the same security group ID of sgInstances.
At the end you should have 4 security groups: sgLoadBalancer, sgInstances, sgRDS and sgNFS. These are the rules.

And these security groups should be assigned to these resources.

SSH Keys

Before we start provisioning the servers, let’s create a SSH key pair so we can access them. The menu for the creation of SSH keys is bellow Security Groups.

Click on Create SSH Key Pair in the top right corner. You can import or create your own key pair. I chose to create the key pair.

As a result you’ll get a certificate file (.pem). Keep this file somewhere safe. If you use putty to connect to your instances, you’ll have to convert this file to ppk using puttygen.

NFS instance

From the menu, go to Instances and then from the top right, click Create Instance.

I am going with Pay-As-You-Go model and Random zone. Choose your instance type. The cheapest are under Entry-Level (Shared). I went with 1 CPU and 1GB RAM and 20GB disk on CentOS 7.6 x-64. Looks like 20GB is minimum, I couldn’t choose anything below 20GB for the disk. Click Next: Networking when you are done here.

On the Networking screen, I have these settings. The defaults for the VPC and the zone, click to Assign public IP and click to select a security group. For some reason, I was able to select only one security group, so select sgInstances as a security group.

If you click next, you’ll see the System Configuration page. Specify the key that you’ve selected, name the instance so it shows up properly in the console, add a description if you want and enter the hostname (optional). From here, you can accept the default and next-through all the way to the end. Alibaba will create the instance for you in 1-3 minutes.

After the instance is create, go back to the Security Groups menu and find the sgNFS group. Click on Manage Instances.

From the top right, click on Add Instance and add the nfs instance. This way, we’ll have both sgInstances and sgNFS securty groups attached to the nfs server.
Go back to your instances and you’ll see the instance is up and running. SSH to its public IP and specify the SSH key to log in. Your username is root and the ppk file is your password.

Once you are in, you’ll be greeted with the Alibaba banner.

Now you are ready to install the NFS filesystem that will be used as a shared disk for both WordPress instances. I already have a small tutorial for this, so go to this link and do the server part. You can skip the part for the firewall (last two commands). The firewall is not enabled by default on Alibaba CentOS. SELinux is also disabled. Once you are done, we have to download WordPress and extract it under the nfs share. Then, we we build the webservers we’ll mount this directory and point our webserver there.

cd /nfs
wget https://www.wordpress.org/latest.tar.gz
tar xzvf latest.tar.gz --strip 1

RDS

We’ll use the PaaS offering from Alibaba for our MySQL database. From the menu on the left, click AsparaDB for RDS.

Click Create Instance in the top right corner. This is what I chose for my database. Make sure Pay-As-You-Go is selected and then choose the RDS instance in the same region as your other instances. The engine is MySQL 5.7 with no HA. I chose a small 1 CPU/1GB DB instance with 20GB storage.

Click Buy Now and then Pay Now when you are done. If you go to the console, you won’t see your database. Just wait for a minute or two and it will show up with a status of Creating. After 3-5 mins, once the status changes to Running, click on the database. Let’s assign a security group first. Click on Basic Infomation on the left and then click on Set Whitelist.

Look at the bottom right, where it says Add to Security Group. The names won’t show up, so get your security group ID for sgRDS from the Security Groups menu first. Unlike AWS, you can assign only one security group per DB instance. If you get an error that this operation is not supported, do not assign a security group. Just whitelist the VPC subnet. Click Add a Whitelist Group and add the VPC subnet 192.168.0.0/16.

Now, go to the Accounts menu on the left and click Create Account on the right. I’ve created a superuser called dbmaster.

Again, go to Databases menu on the left and click Create Database on the right. Type the name of the database dbwordpress and click to create a new account. You’ll be back at the accounts menu. This time create a user called wordpress and make it a standard user. It’s kind of kludgy, but now you have to go back to the Databases menu, click Create Database again, fill the name dbwordpress again, but this time you can choose the account that you just created.

Finally, go to the Basic Information menu and choose the menu next to Intranet address. Here you have to create a whitelist group of IPs that can access the database. By default, only 127.0.0.1 is allowed. We have to enter our VPC CIDR.

Once you do that, you’ll see your RDS hostname.

WordPress instances

We’ll create two instances, install Apache + PHP, mount the NFS system and configure the web server. First, create two instances, each in a different zone. Use the section above for the NFS server. Name the servers web1 and web2 and assign the sgInstances security group to both of them. Make sure you choose Pay-As-You-Go model and assign public IPs so you can log in. And choose the SSH key pair that we created. Log to both of the instances.
First, mount the NFS system. Replace the IP with the IP of your NFS server in the mount command.

yum -y install nfs-utils
mount 192.168.1.91:/nfs /var/www/html
echo "192.168.1.91:/nfs       /var/www/html    nfs     defaults 0 0" >> /etc/fstab
chown -R apache:apache /var/www/html

Then, check if you can reach the RDS MySQL server. You should receive some garbage.

yum -y install telnet
telnet rm-2evrh4h3aq9tk800z.mysql.rds.aliyuncs.com 3306
Trying 172.16.1.41...
Connected to rm-2evrh4h3aq9tk800z.mysql.rds.aliyuncs.com.
Escape character is '^]'.
N
5.7.20-log▒F5;I!]:p]H3R[^mysql_native_password

Second, install Apache and all PHP modules on both servers. I’ll install PHP 5.4 because it’s already in the default repo. You should install PHP 7.x, it’s a little bit more work.

yum -y install httpd php php-common php-mysql php-gd php-xml php-mbstring php-mcrypt
systemctl enable httpd
systemctl start httpd

Now, we have to configure the Apache server. It’s a simple change in /etc/httpd/conf/httpd.conf file. You’ll probably want to use virtual hosts, but in interest of keeping this short, I’ll use a single site config. Find the directive that says #ServerName www.example.com:80 and remove the comment.

sed -i '/ServerName www/s/^#//g' /etc/httpd/conf/httpd.conf

Load Balancer

From the menu on the left, click on Server Load Balancer.

Once the screen shows up, click on Create SLB Instance. Then choose the specs. Make sure it is in the same region with your instances and in the same zones (VSWitches). Name the load balancer too, e.g. lbWordPress.

Once it’s ready, click on Add Backend Servers.

From the list of the available servers, choose web1 and web2 in the Default Server Group.

Click on Next: Set Weight and Port button and click OK to accept the defaults. Go back to the load balancer and this time click Configure Listener (above Add Backend Servers).

Choose HTTP traffic, port 80, click Modify next to Advanced and Enable Session Persistence. Click Next.


On this screen click on Default Server Group, type port 80 for the servers and click Next. You can accept the defaults in the next screen or make a change if you like.

Open a browser and go to your load balancer IP. It might take up a minute for the LB to configure so be patient if your browser is just sitting there.

If you used my username and database names, fill out the config page like this.

…and pretty much that’s it.

I’ve decided to play with nginx to see how different is from Apache. The best way to experiment is to have an end goal, e.g. a working WordPress site. I will be using FreeBSD 11.0 and for that I’ve created a public server in AWS cloud. The hostname for my server is test.iandreev.com and I also have 4 different hostnames that point to the same IP (test1, test2, test3 and test4).

Installation

To install nginx, type:

pkg install nginx

Make sure it starts at boot by adding nginx_enable=”YES” in /etc/rc.conf.
To see the version, type:

nginx -v
nginx version: nginx/1.10.2

To see the modules that were installed with the package, type:

nginx -V

You can start and stop the service with the standard service command. When making changes in the config file, use reload, e.g. service nginx reload.
By default, nginx creates the log files under /var/log/nginx. There are two files, access.log and error.log. The config files are under /usr/local/etc/nginx. The main config file is nginx.conf.
Let’s start the nginx.

service nginx start
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.

If everything is OK, you can telnet localhost 80. Type something and hit ENTER and you’ll see a response.

telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
asdf
HTTP/1.1 400 Bad Request
Server: nginx/1.10.2
Date: Sun, 29 Jan 2017 13:56:04 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.10.2</center>
</body>
</html>
Connection closed by foreign host.

Check the nginx process.

ps -waux | grep nginx
root     778   0.0  0.7 29640 6984  -  Is   13:55    0:00.00 nginx: master process /usr/local/sbin/nginx
www      779   0.0  0.7 29640 7452  -  I    13:55    0:00.00 nginx: worker process (nginx)

As you can see the master process runs as root, but then it forks the connections to the www user.

Single host

This is the easiest setup. You don’t have to do anything except the steps above. nginx works right out of the box with the default configuration. Go to http://server_IP_or_hostname and you’ll see the welcome page.

But, this scenario has no real use, so we’ll create two virtual hosts, test1 and test2.

Virtual hosts

First, we’ll create the two directories for the virtual hosts and put some index files there. I use the same root directory as Apache. Make sure that the locations of the virtual hosts are owned by the user www and group www.

cd /usr/local/www
mkdir test1.iandreev.com
mkdir test2.iandreev.com
echo "test1" > test1.iandreev.com/index.htm
echo "test2" > test2.iandreev.com/index.htm
chown -R www:www test*

Now, we have to edit the main config file and tell nginx where to look for these sites.
Go to /usr/local/etc/nginx/ and edit nginx.conf. Change the values for worker_processes from 1 to auto and uncomment gzip on directive. See what worker_processes mean here. By uncommenting gzip directive, you are enabling compression on the pages. To test if your web server serves compressed pages, check this website.
Next, we have to add our two virtual hosts. Scroll all the way down, just before the last accolade “}” and add these lines.

    server {
        access_log /var/log/nginx/test1.iandreev.access.log;
        error_log  /var/log/nginx/test1.iandreev.error.log;
        listen 80;
        server_name     test1.iandreev.com;
        location / {
            root /usr/local/www/test1.iandreev.com;
            index index.htm index.html;
        }
    }
    server {
        access_log /var/log/nginx/test2.iandreev.access.log;
        error_log  /var/log/nginx/test2.iandreev.error.log;
        listen 80;
        server_name test2.iandreev.com;
        location / {
            root /usr/local/www/test2.iandreev.com;
            index index.htm index.html;
        }
    }

Reload the config with:

service nginx reload
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

and make sure everything is OK.
If everything is OK, you should be able to browse to your virtual sites.

If you check one of the error logs, you’ll see an error that favicon.ico is missing for the site. You can ignore this as it’s not an error, it’s just a warning that you don’t have a favicon for your site.

tail test2.iandreev.error.log
2017/01/29 14:18:59 [error] 838#100084: *4 open() "/usr/local/www/test2.iandreev.com/favicon.ico" failed (2: No such file or directory), client: 240.14.17.24, server: test2.iandreev.com, request: "GET /favicon.ico HTTP/1.1", host: "test2.iandreev.com"

You can get a favicon icon from this website or you can generate one from this one.

nginx and PHP

Unlike Apache and the php module, nginx is using PHP-FPM as a proxy to requests PHP dynamic code over FCGI protocol. PHP-FPM comes bundled with PHP, so let’s install php 5.6.

pkg install php56

Add this line in /etc/rc.conf so PHP-FPM starts on boot.

php_fpm_enable="YES"

Create the php.ini file from php.ini-production.

cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini

Now, edit /usr/local/etc/php-fpm.conf and make these changes. Replace listen = 127.0.0.1:9000 with listen = /var/run/php-fpm.sock. In addition, uncomment these three lines.

listen.owner = www
listen.group = www
listen.mode = 0660

Finally, start the php-fpm service.

service php-fpm start
Performing sanity check on php-fpm configuration:
[28-Jan-2017 23:41:31] NOTICE: configuration file /usr/local/etc/php-fpm.conf test is successful

Let’s create a test website that will serve PHP content.

cd /usr/local/www
mkdir test3.iandreev.com
echo "<?php phpinfo(); ?>" > test3.iandreev.com/index.php
chown -R www:www test3.iandreev.com

Add a new virtual host in nginx.

server {
        access_log /var/log/nginx/test3.iandreev.access.log;
        error_log  /var/log/nginx/test3.iandreev.error.log;
        listen       80;
        server_name  test3.iandreev.com;
        root /usr/local/www/test3.iandreev.com;
        index index.php index.html index.htm;
        location / {
            try_files $uri $uri/ =404;
        }
        error_page      500 502 503 504  /50x.html;
        location = /50x.html {
            root /usr/local/www/nginx-dist;
        }
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $request_filename;
                include fastcgi_params;
        }
    }

and reload the config changes.

service nginx reload

Go to your new virtual host, in my case http://test3.iandreev.com and you should see this.

nginx and WordPress

Now that we have PHP support we can create a WordPress site. We’ll use MySQL as a DB backend. Please see my other post on how to install MySQL first.
Once you have the MySQL installed, create the database. Replace the values of wordpress, wpuser and secret to suit your needs.

CREATE DATABASE wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO "wpuser"@"localhost" IDENTIFIED BY "secret";
FLUSH PRIVILEGES;
QUIT;

Install the following php modules, otherwise when you start WordPress you’ll be presented with a blank page.

pkg install php56-extensions php56-mysql php56-mysqli php56-xml php56-hash php56-gd php56-curl php56-tokenizer php56-zlib php56-zip

Download the latest WordPress install. If you don’t have wget, install it first with pkg install wget.

cd /usr/local/www
wget www.wordpress.org/latest.zip --no-check-certificate
unzip latest.zip
mv wordpress test4.iandreev.com
chown -R www:www test4.iandreev.com
rm latest.zip

Add the following in nginx.conf to create the virtual host for the WordPress site.

server {
        access_log /var/log/nginx/test4.iandreev.access.log;
        error_log  /var/log/nginx/test4.iandreev.error.log;
        listen       80;
        server_name  test4.iandreev.com;
        root /usr/local/www/test4.iandreev.com;
        index index.php index.html index.htm;
        location / {
            try_files $uri $uri/ =404;
        }
        error_page      500 502 503 504  /50x.html;
        location = /50x.html {
            root /usr/local/www/nginx-dist;
        }
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $request_filename;
                include fastcgi_params;
        }
    }

Reload the config and restart php-fpm service.

service nginx reload
service php-fpm restart

Go to your website and you’ll be presented with the WordPress install page.

I wanted to run a custom code from a WordPress post and I was looking around. I’ve found a nice plugin but it was running PHP only. It’s not that I needed more, but I stumbled when I tried to combine HTML elements and the PHP script with this plugin. So, at the end I’ve found a much more elegant solution, that pretty much runs any code. All I had to do is to embed the HTML page as an object.

So, let’s say I have a custom code in a PHP page called test.php that’s in the root of my WordPress installation. All is needed is this code in WordPress (use the Text tab, not Visual).

<object data="https://blog.andreev.it/test.php" width="800" height="600"></object>

And this is how my test.php page looks like. I won’t comment the code, but it has an input label and a button. Type a hostname and it will ping it and then render the output as an HTML array.

<!DOCTYPE HTML>
<html>
<head>
<style>
.error {color: #FF0000;}
</style>
</head>
<body>

<?php
// define variables and set to empty values
$hostErr = "";
$host = "";

if ($_SERVER["REQUEST_METHOD"] == "POST") {
  if (empty($_POST["host"])) {
    $host = "Host is required";
  } else {
    $host = test_input($_POST["host"]);
    // only letters and numbers are allowed
    if (!preg_match("/^[a-zA-Z0-9.]*$/",$host)) {
      $hostErr = "Only letters and numbers allowed";
    }
  }
}

function test_input($data) {
  $data = trim($data);
  $data = stripslashes($data);
  $data = htmlspecialchars($data);
  return $data;
}
?>

<h2>Online ping (ICMP) probe</h2>
<p><span class="error">* required field.</span></p>
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>
">
  Host: <input type="text" name="host" value="<?php echo $host;?>">
  <span class="error">* <?php echo $hostErr;?></span>
  <br><br>
  <input type="submit" name="submit" value="Submit">
</form>

<?php
        if(isset($_POST['submit']))
        {
                echo "<h2>Output:</h2>";
                echo $host;
                echo "<br>";
                exec("ping -c 3 $host", $output, $status);
                echo '<pre>';
                print_r($output);
                echo '<pre>';

        }
?>

</body>
</html>

The code in action. Type some host on the internet (e.g www.whatever.com), click the button and see the result.

In this post I’ll describe how to create a fully functional WordPress blog on Amazon AWS. The blog will run on a server that can scale up or down depending on the load. The database will reside on Amazon RDS, not on a separate server. I’ll use both the AWS console and CLI to show how things work. Some of the steps are optional and you may choose more or less resources or redundancy and different type of security. See the following post if you plan to use CLI and you don’t have that configured. Do not execute the CLI commands if you created/deleted something from the console. It won’t work. Also, it won’t work if you just blindly copy and paste the CLI commands. Pretty much all of them are tied with unique ids for the AMIs, security groups, scaling groups…

Security Groups

First, we’ll create two security groups, sgBlogEC2 and sgBlogRDS. The first one will be used for the servers and the second one for the database. The first one will allow ports 22 (ssh) and port 80 (http) from anywhere and the second one will allow port 3306 from sgBlogEC2 only. This means that you can manage any of the VM servers from anywhere, the blog can be accessed from anywhere and the database can be accessed only from the servers.

Go to Compute | EC2.

Then, under NETWORK & SECURITY, click Security Groups.

Click on Create Security Group and fill the blanks. We’ll use the default VPC. Then, click Add Rule and add both rules for port 22 (ssh) and port 80 (http). Click Create when done.

Do the same for the 2nd security group. This time add only port 3306 (MYSQL/Aurora) and for the source specify the Group ID of the first group that you’ve created.

Using CLI, we have to find the default VPC ID first.

aws ec2 describe-vpcs
{
    "Vpcs": [
        {
            "VpcId": "vpc-c2d645a6",
            "InstanceTenancy": "default",
            "State": "available",
            "DhcpOptionsId": "dopt-ca3593af",
            "CidrBlock": "172.31.0.0/16",
            "IsDefault": true
        }
    ]
} 

In my case, the ID is vpc-c2d645a6. Now, we can create the groups.

aws ec2 create-security-group --group-name sgBlogEC2 --description "Security Group for the WordPress servers" \ 
--vpc-id vpc-c2d645a6
aws ec2 create-security-group --group-name sgBlogRDS --description "Security Group for the WordPress database" \ 
--vpc-id vpc-c2d645a6

When you execute these commands, you’ll get the security group ID as an output. Get the GroupId, you’ll need them now. In my case, the GroupIds were sg-37535351 and sg-3b53535d. We have the groups created, but we need the inbound rules.

aws ec2 authorize-security-group-ingress --group-id sg-37535351 --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-37535351 --protocol tcp --port 80 --cidr 0.0.0.0/0

and for the second group

aws ec2 authorize-security-group-ingress --group-id sg-3b53535d --protocol tcp --port 3306 --source-group sg-37535351

Database

WordPress requires a MySQL compatible database to work. We can install the database on the WordPress server, but if we want to use more than one server in a load-balanced configuration, this scenario won’t work. So, we’ll just use a database instance separate from the servers.

From the main AWS menu, go to Database | RDS.

Click on Instances and then Launch DB Instance.

I’ll be using MariaDB, but you can choose Amazon Aurora or MySQL.

On the next screen, Amazon recommends to use Multi-AZ deployment and PIOPS for production databases. The benefit is that if one zone goes down, you’ll still have your database running in the other zone. And the PIOPS is just a faster SSD. I don’t need any of these so I’ll go with the Free Usage Tier option.

On this screen, you have to specify the details for the database, such as the resources (in my case 1CPU, 1GB RAM), 5GB of storage (you’ll probably need 10 or more GB) and the username and password that will have full access to the instance.

In the advanced settings dialog, make sure you choose your default VPC, disable the public access, choose the security group that we created for this database and name the database.

I’ve used the defaults for the backup options.

If you click on View DB Instance and then on the magnifying glass icon, you’ll see that the endpoint is not yet available.

Wait for a couple of minutes until the endpoint shows up. We’ll need this when we install WordPress.

Using CLI, you can accomplish the same.

aws rds create-db-instance \
--db-instance-identifier dbiWordPress \
--db-name dbWordPress \
--allocated-storage 5 \
--db-instance-class db.t2.micro \
--engine MariaDB \
--vpc-security-group-ids sg-3b53535d \
--master-username db_owner \
--master-user-password T0pS3cr3tP4ssw0rd \
--storage-type gp2 \
--no-publicly-accessible \
--no-multi-az

This is what we need when we install WordPress.

Key Pairs

If you already have a SSH key pair that you want to use, you can skip this step. If not, continue reading.

Go to Compute | EC2

Then, under NETWORK & SECURITY, click Key Pairs.

Click on Create Key Pair and enter the name. I used kpWordPressEC2. Save the provided .pem file somewhere. You’ll need this file to access the servers using ssh.

Using AWS CLI, you can create the key pair using the following command.

aws ec2 create-key-pair --key-name kpWordPressEC2 --query "KeyMaterial" --output text > kpWordPress.pem

If you open this file, which is basically a text file, you’ll see something like this.

-----BEGIN RSA PRIVATE KEY-----
EXAMPLEKEYKCAQEAy7WZhaDsrA1W3mRlQtvhwyORRX8gnxgDAfRt/gx42kWXsT4rXE/b5CpSgie/
vBoU7jLxx92pNHoFnByP+Dc21eyyz6CvjTmWA0JwfWiW5/akH7iO5dSrvC7dQkW2duV5QuUdE0QW
Z/aNxMniGQE6XAgfwlnXVBwrerrQo+ZWQeqiUwwMkuEbLeJFLhMCvYURpUMSC1oehm449ilx9X1F
G50TCFeOzfl8dqqCP6GzbPaIjiU19xX/azOR9V+tpUOzEL+wmXnZt3/nHPQ5xvD2OJH67km6SuPW
oPzev/D8V+x4+bHthfSjR9Y7DvQFjfBVwHXigBdtZcU2/wei8D/HYwIDAQABAoIBAGZ1kaEvnrqu
/uler7vgIn5m7lN5LKw4hJLAIW6tUT/fzvtcHK0SkbQCQXuriHmQ2MQyJX/0kn2NfjLV/ufGxbL1
mb5qwMGUnEpJaZD6QSSs3kICLwWUYUiGfc0uiSbmJoap/GTLU0W5Mfcv36PaBUNy5p53V6G7hXb2
bahyWyJNfjLe4M86yd2YK3V2CmK+X/BOsShnJ36+hjrXPPWmV3N9zEmCdJjA+K15DYmhm/tJWSD9
81oGk9TopEp7CkIfatEATyyZiVqoRq6k64iuM9JkA3OzdXzMQexXVJ1TLZVEH0E7bhlY9d8O1ozR
oQs/FiZNAx2iijCWyv0lpjE73+kCgYEA9mZtyhkHkFDpwrSM1APaL8oNAbbjwEy7Z5Mqfql+lIp1
YkriL0DbLXlvRAH+yHPRit2hHOjtUNZh4Axv+cpg09qbUI3+43eEy24B7G/Uh+GTfbjsXsOxQx/x
p9otyVwc7hsQ5TA5PZb+mvkJ5OBEKzet9XcKwONBYELGhnEPe7cCgYEA06Vgov6YHleHui9kHuws
ayav0elc5zkxjF9nfHFJRry21R1trw2Vdpn+9g481URrpzWVOEihvm+xTtmaZlSp//lkq75XDwnU
WA8gkn6O3QE3fq2yN98BURsAKdJfJ5RL1HvGQvTe10HLYYXpJnEkHv+Unl2ajLivWUt5pbBrKbUC
gYBjbO+OZk0sCcpZ29sbzjYjpIddErySIyRX5gV2uNQwAjLdp9PfN295yQ+BxMBXiIycWVQiw0bH
oMo7yykABY7Ozd5wQewBQ4AdSlWSX4nGDtsiFxWiI5sKuAAeOCbTosy1s8w8fxoJ5Tz1sdoxNeGs
Arq6Wv/G16zQuAE9zK9vvwKBgF+09VI/1wJBirsDGz9whVWfFPrTkJNvJZzYt69qezxlsjgFKshy
WBhd4xHZtmCqpBPlAymEjr/TOlbxyARmXMnIOWIAnNXMGB4KGSyl1mzSVAoQ+fqR+cJ3d0dyPl1j
jjb0Ed/NY8frlNDxAVHE8BSkdsx2f6ELEyBKJSRr9snRAoGAMrTwYneXzvTskF/S5Fyu0iOegLDa
NWUH38v/nDCgEpIXD5Hn3qAEcju1IjmbwlvtW+nY2jVhv7UGd8MjwUTNGItdb6nsYqM2asrnF3qS
VRkAKKKYeGjkpUfVTrW0YFjXkfcrR/V+QFL5OndHAKJXjW7a4ejJLncTzmZSpYzwApc=
-----END RSA PRIVATE KEY-----

Follow this article on how to connect to your AWS EC2 instances.

Servers

Now that we have the database ready, we’ll go ahead and create one server that will be used as a template. I’ll use the Amazon Linux AMI, which is based on Red Hat 6.

Go to Compute | EC2

Click on Instances under Instances and then click Launch Instance.

Choose the first choice, Amazon Linux AMI, then choose the type (I’ll use the t2.micro), accept the defaults for the instance.

Specify the amount of storage you want. I used 8GB which is more than enough because the database is not on the servers.

Tag the instance if you want and make sure you select the security group that we created for the servers.

Choose the key pair and launch the instance.

Using AWS CLI, the same thing can be accomplished with:

aws ec2 run-instances --image-id ami-60b6c60a --security-group-ids sg-37535351 --count 1 \ 
--instance-type t2.micro --key-name kpWordPressEC2

We will need the public IP for the server. From the console, click the newly created server and you’ll see the public IP.

Or, type:

aws ec2 describe-instances

and look for “PublicIp” line.

DNS – Route 53

The blog that I will create will reside at blog.andreev.us. We need to create a DNS record that will point this child domain to the IP of the server that we just built. Use your domain management panel to change this. I purchased my domain (andreev.us) through GoDaddy, but I can still delegate the subdomain blog.andreev.us to be managed from Route 53. All you have to do is tell GoDaddy or whatever your domain hosting company is, to look for this subdomain somewhere else. This is how my domain management panel at GoDaddy looks like.

Back to AWS, go to Networking and then click Route 53. Click on Create Hosted Zone. Fill the blanks with your blog’s name and click Create.

You will get your hosted zone and you’ll see your Name Servers. These are the servers that you want to put under your domain management panel if you purchased your domain somewhere else.

You are not finished yet. You just created your zone and got your name servers, but they have no clue where the actual host is. What you have to do now is to create an A record. Click on Create Record Set and put the IP of the server there.

Once you create your A record, wait between 5 mins and 30 mins and make sure that your domain resolves to your IP. The easiest way is to ping. You won’t get a response, which is fine, but you should get the IP.

ping blog.andreev.us
Pinging blog.andreev.us [52.90.209.108] with 32 bytes of data:
Request timed out.

And doing the same thing with AWS CLI.

aws route53 create-hosted-zone --name blog.andreev.us --hosted-zone-config Comment="blog.andreev.us" \ 
--caller-reference 2015-12-09-14:00

If you look at the output, you’ll see your Zone Id that looks like this.

"Id": "/hostedzone/Z3F33MZHA3FTIL",

Now, add the A record with this command.

aws route53 change-resource-record-sets --hosted-zone-id Z3F33MZHA3FTIL --change-batch file://C:\add-record.json

but before running the command create a file called add-record.json and add the following inside. Replace the IP and the domain name with yours.

{
  "Comment": "Adding A record",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "blog.andreev.us",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": "52.90.209.108"
          }
        ]
      }
    }
  ]
}

WordPress installation

Once you have your instance up and running, ssh to it and log as ec2-user. If you are using some other OS flavor, the username ec2-user might not apply. Also, the following steps differ between various Linux/BSD systems. I’ll describe how to install Apache, PHP and WordPress on AWS Linux AMI. The procedure is the same for Red Hat 6 and CentOS 6, but differs for FreeBSD, Fedora, Ubuntu, etc…

First, install the Apache web server and PHP.

sudo yum install httpd php php-zlib php-iconv php-gd php-mbstring php-fileinfo php-curl php-mysql  

Let’s make sure Apache starts on boot.

sudo chkconfig httpd on

We need to make some configuration changes to the web server. Go to the Apache config directory and edit the configuration file httpd.conf.

cd /etc/httpd/conf 
sudo vi httpd.conf

Scroll all the way down (Shift + G) and add the following lines at the very end. My test blog will be called blog.andreev.us and I am creating a virtual web directory for that. You have to replace this with your blog name.

<VirtualHost *:80>
     ServerAdmin klimenta@andreev.us
     DocumentRoot /var/www/blog.andreev.us
     ServerName blog.andreev.us
     ErrorLog logs/blog.andreev.us-error_log
     CustomLog logs/blog.andreev.us-access_log combined 
</VirtualHost>

Let’s download WordPress install file, unzip it and start the web server.

cd /var/www
sudo wget www.wordpress.org/latest.zip
sudo unzip latest.zip
sudo rm latest.zip
sudo mv wordpress blog.andreev.us
sudo chown -R apache:apache blog.andreev.us 
sudo apachectl start

After this, you can access your blog. Go to http://blog.whatever.com or whatever you named your blog and you should see the WordPress page. Fill up the blanks with the values that we got previously. Your DB host name is the endpoint.

Congrats! You have your WordPress blog on AWS now. But, we have a lot of other cool features to implement.

Creating AMI

Now that we have the blog up and running, just create a new post and publish it. The posts and comments are stored in the database, but if you decide to change a theme you have to know that the themes and plugins are stored on the local file system. We plan to run the blog on multiple servers based on a template, so once we create the template, anytime you decide to change your theme, you’ll have to create a new AMI. So, before creating the AMI template, do all of your customization and install all plugins that you intend to use.

Let’s create the template now. The server will reboot when creating a template. Go to the EC2 dashboard, right click on the server, click Image then Create Image.

Enter a name, description and choose the size of the disk.

After a minute, you can see your AMI (template) under IMAGES | AMIs.

When the status is available, you can go ahead and terminate your original instance. We won’t need it, because we’ll go ahead and use auto scaling to create the new servers from the template.

Using AWS CLI you can create a template with:

aws ec2 describe-instances

Get the InstanceId from the output above and create an AMI with:

aws ec2 create-image --instance-id i-f2022a42 --name "Word Press Template" --description "AMI for WordPress Blog" 

Make sure that you’ve deleted the original instance and that your blog is not accessible before going to the next step.

Auto Scaling

Go to EC2 | AUTO SCALING | Launch Configurations. Click on Create Auto Scaling group. If you don’t have a launch configuration, you’ll have to create one. Click on Create launch configuration. When you see a list of a bunch of AMIs, click on My AMIs on the left.

Select the AMI that you’ve created, choose resources (I’ll use t2.micro) and then name your Launch Configuration . Click on Next: Add Storage

Specify the size of the storage for the AMI (I used 8GB which is the default) and choose the security group for the EC2 servers that we created.

Click on Review to check for any errors and then click on Create launch configuration. Select the key pair and create the Launch Configuration. You’ll be immediately redirected to create the Auto Scaling Group. In my case, I just named the group and used all of the available subnets in that region.

Select Use scaling policies to adjust the capacity of this group and change to scale between 1 and 2 or whatever instances you like to have max.

For the Auto Scaling policy, where it says Take the action change 0 to 1, so you’ll be adding/removing 1 instance depending on the load. I also named my policies spIncrease and spDecrease. Click on Add New alarm under Increase Group Size.

Uncheck the notification checkmark if you don’t want to receive notifications (email, pager…) whenever there is a change in the number of instances and put 80 for the threshold. Name the alarm and click on Create Alarm.

Do the same for the Decrease Group Size. This time use less or equal 30 percent as shown below.

Or, this means, whenever the average CPU utilizations of all instance is greater or equal than 80%, add another instance. When the same average CPU utilization is less or equal than 30%, remove one instance. Sudden burst of CPU utilization won’t have any effect, because the utilization has to last 5 minutes. If you have more than 10 instances, you don’t add one or two instances whenever there is a change in the utilization. Instead you add a percentage of the total number of the instances. For example if you have 20 instances, you won’t add one extra instance. It won’t make any difference. You’ll add 20% of the instances, which is four.

OK, click next and if you want to receive notifications when the resources are added or removed, you can configure them here, but I’ll skip this step. Click next and use the tags if you want to and finally click Review and then Create Auto Scaling group. If you go to the EC2 Dashboard, you’ll see that one server already started. That’s because we have specified a minimum of one server.

Using AWS CLI, we can create the launch configuration first. Make sure you specify the ID of your AMI that we created.

aws autoscaling create-launch-configuration --launch-configuration-name lcWordPress --image-id ami-176f267d \ 
--instance-type t2.micro --security-groups sg-37535351

In order to create an auto scaling group, we’ll need to know the subnets. Look for SubnetId.

aws ec2 describe-subnets

Create the auto scaling group.

aws autoscaling create-auto-scaling-group --auto-scaling-group-name asgWordPress --launch-configuration-name \ 
lcWordPress --min-size 1 --max-size 2 --vpc-zone-identifier \ 
"subnet-994e5eb2,subnet-1d40fb20,subnet-fb01cd8d,subnet-3c876164"

Create the scaling policies.

aws autoscaling put-scaling-policy --auto-scaling-group-name asgWordPress --policy-name spIncrease \ 
--scaling-adjustment 1 --adjustment-type ChangeInCapacity
aws autoscaling put-scaling-policy --auto-scaling-group-name asgWordPress --policy-name spDecrease \ 
--scaling-adjustment -1 --adjustment-type ChangeInCapacity

The output of these two commands will be two PolicyARNs. One looks like this.

{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:076270756661:scalingPolicy:d1d03
001-c9a6-4097-bd41-dc1a27ab7286:autoScalingGroupName/asgWordPress:policyName/spD
ecrease"
}

Make sure you get them both, because we’ll need them now when we create the alarm and associate it with the policy.

c:\>aws cloudwatch put-metric-alarm --alarm-name alWordPress-High-CPU-Utilization --metric-name CPUUtilization \ 
--namespace AWS/EC2 --statistic Average --period 600 --threshold 80 \ 
--comparison-operator GreaterThanOrEqualToThreshold --dimensions "Name=AutoScalingGroupName,Value=asgWordPress" \
--evaluation-periods 1 --alarm-actions arn:aws:autoscaling:us-east-1:076270756661:scalingPolicy:830f183a-585d
4b8ea1c26f3c0581021c:autoScalingGroupName/asgWordPress:policyName/spIncrease

where 600 is 5 minutes. See the parameters when we did the same from the console. Do the same for the second policy with the seconds PolicyARN.

CloudWatch

Go to the AWS home page, click on CloudWatch and then look under Alarms.

If the instance is running less than 5 min, the alarms should be under INSUFFICIENT. Click on the label INSUFFICIENT or OK. If you click to Modify one of the alarms, you’ll see the same threshold and actions that we defined before. This is actually where you create new alarms and modify existing ones and change the actions needed.

Testing the scaling

Go to the Auto Scaling Groups menu, click on Scaling Policies, then click on Actions and then click Execute.

Enter any number that’s greater than 80 and wait for 5 minutes. We’ll kick the policy that says, add another instance if the average CPU utilization is greater than 80 and it lasts for more than 5 mins.

After 5 mins, you’ll see another instance showing up. You don’t have to do anything. The instance will remove itself after another 5 mins, because the actual usage is less than 30% (that was the 2nd policy).

Using CLI:

aws autoscaling execute-policy --auto-scaling-group-name asgWordPress --policy-name spIncrease \ 
--metric-value 95 --breach-threshold 80

Elastic Load Balancer

Now that we have a scaling policy working, we can create the Load Balancer.

From the EC2 menu, click on Load Balancers under LOAD BALANCING.
Click on Create Load Balancer and name it. Leave the port 80.

Assign the security group for the servers. NOTE: A proper way would be to create a new security group for the load balancer and then modify the server security group to accept port 80 only from that LB security group, very similar with what we did with the RDS security group.

Skip step 3 and remove index.html under Ping Path on step 4.

You can skip step 5, we don’t need to add the instances yet. Same with step 6, skip. Click Review and Create and then click Create. Once the LB is created, look for the DNS name under the description tab.

Now, we have to associate our Auto Scaling Group with the Load Balancer. Go to the Auto Scaling Group menu, notice how the Load Balancers entry is blank and click Edit to fix it.

Click anywhere on the blank line and our load balancer will show up. Click Save.

Go back to the Load Balancers menu and click on the Instances tab.
Wait for 2-3 minutes and the status should turn into InService. If it says OutOfService, you’ll have to investigate. The easiest way is to ssh to the server and check the log files for the Apache. If you scroll all the way up, you’ll see that we defined the log files for our web site.

ErrorLog logs/blog.andreev.us-error_log
CustomLog logs/blog.andreev.us-access_log combined 

Look at the access log and you’ll see that every 30 seconds there is a hit from the load balancer. If the return code is not 200, which is OK in HTML, then you have to troubleshoot.

And the same thing with AWS CLI.

aws elb create-load-balancer --load-balancer-name lbWordPress \ 
--listeners "Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,InstancePort=80" \ 
--security-groups sg-37535351 --subnets subnet-3c876164 subnet-fb01cd8d subnet-1d40fb20 subnet-994e5eb2

Configure LB health-check.

aws elb configure-health-check --load-balancer-name lbWordPress \ 
--health-check Target=HTTP:80/,Interval=30,UnhealthyThreshold=2,HealthyThreshold=10,Timeout=5

Associate the Auto Scaling Group with the Load Balancer.

aws autoscaling attach-load-balancers --load-balancer-names lbWordPress --auto-scaling-group-name asgWordPress

Final change

Now that everything is up & running, we just have to point the DNS record of blog.andreev.us to point to the load balancer.

Go to Route 53 console, select the domain name, select your A record, click on Yes for the Alias and select the DNS name for the load balancer from the drop down Alias Target.

In one of my previous posts, I’ve explained how to install LAMP on CentOS 6.4. Things changed a little bit in version 7, because of systemd.

Hostname

First, let’s verify that we have a valid hostname and that it resolves properly. Type:

hostname

and make sure you have the FQDN of your server. If not, edit /etc/hostname and enter it there. In my case, it will be master.iandreev.us

cat /etc/hostname
master.iandreev.us

NOTE: Highlighted numbers are what you type. The rest is the response from the server.
Restart the service, so the changes take effect if you changed your hostname.

systemctl restart systemd-hostnamed

Install Apache

Apache can be installed by executing:

yum install httpd

Once installed, go to /etc/httpd/conf and edit httpd.conf. This is the main configuration file for Apache. Change and remove the comment (#) from the following directives, ServerAdmin and ServerName. In my case it looks like this.

ServerAdmin klimenta@iandreev.us
ServerName master.iandreev.us

This command will enable Apache to start on boot.

systemctl enable httpd

This command will start Apache

systemctl start httpd

Now, let’s test Apache from the server. Type the following command and then some text:

telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
asdfd
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN";>
<html><head>
<title>501 Not Implemented</title>
</head><body>
<h1>Not Implemented</h1>
<p>asdfd to / not supported.<br />
</p>
</body></html>
Connection closed by foreign host.

If you see the response like above, you are OK. If not check the log files under /var/log/httpd.
Now, from a browser on another computer, go to your server IP or name, in my case http://master.iandreev.us. Nothing will happen. That’s because there is a firewall enabled.
Check the firewall status.

systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Sun 2015-05-31 13:49:37 UTC; 5h 37min ago
 Main PID: 403 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─403 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

May 31 13:49:36 master.iandreev.us systemd[1]: Starting firewalld - dynamic ....
May 31 13:49:37 master.iandreev.us systemd[1]: Started firewalld - dynamic f....
May 31 13:57:04 master.iandreev.us systemd[1]: Started firewalld - dynamic f....
Hint: Some lines were ellipsized, use -l to show in full.

Let’s poke a hole for Apache. We’ll verify that the public zone is the default first, then add the http service to be allowed, then reload the rules and finally list the allowed services.

firewall-cmd --get-default-zone
public
firewall-cmd --add-service=http --permanent
success
firewall-cmd --reload
success
firewall-cmd --list-services
dhcpv6-client http ssh

You can also check the rules with:

iptables -L -n | grep 80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 ctstate NEW

If you go to your page now, you’ll see something like this.

Apache Virtual hosts

The scenario described above works fine but only if you plan to run one single server. If you want to host different web apps, you’ll have to configure virtual hosts. The module for virtual hosts is enabled by default, so we’ll just have to define the virtual hosts. Go to /etc/httpd/conf.d and create a file called httpd-vhosts.conf.

cd /etc/httpd/conf.d
touch httpd-vhosts.conf

We’ll define two virtual hosts (blog.iandreev.us and mail.iandreev.us). Consider these URLs as two different web applications. Make sure that you have both of these hosts in the DNS so they resolve to the same IP of your server. Apache knows that these hosts are different by analyzing host headers. In my case httpd-vhosts.conf looks like this.

<VirtualHost *:80>
    ServerAdmin klimenta@iandreev.us
    DocumentRoot "/var/www/blog.iandreev.us"
    ServerName blog.iandreev.us
    ErrorLog "/var/log/httpd/blog.iandreev.us-error_log"
    CustomLog "/var/log/httpd/blog.iandreev.us-access_log" common
    <Directory "/var/www/blog.iandreev.us">
        Options All
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
<VirtualHost *:80>
    ServerAdmin klimenta@iandreev.us
    DocumentRoot "/var/www/mail.iandreev.us"
    ServerName mail.iandreev.us
    ErrorLog "/var/log/httpd/mail.iandreev.us-error_log"
    CustomLog "/var/log/httpd/mail.iandreev.us-access_log" common
    <Directory "/var/www/mail.iandreev.us">
        Options All
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

It’s pretty much self-explanatory, you have the server name, the location of log files, the root directories for the servers, admin’s e-mail etc.
Now, let’s create the two web sites. For each web-site I’ll specify a simple text file, just so you can see the difference.

cd /var/www
mkdir blog.iandreev.us mail.iandreev.us
echo "blog.iandreev.us"> blog.iandreev.us/index.html
echo "mail.iandreev.us"> mail.iandreev.us/index.html
chown -R apache:apache blog.iandreev.us/ mail.iandreev.us/
chmod -R 755 blog.iandreev.us/ mail.iandreev.us/
systemctl reload httpd

So, I’ve created two root directories, then created two text files that will be the main page for each site and finally I changed the owner and permissions. At the end, I’ve restarted Apache because we made changes to the configuration file for the virtual hosts.
Now, go to each of these web sites, in my case http://blog.iandreev.us and http://mail.iandreev.us and you’ll see that the main page is different.

SSL virtual hosts

First, we have to install mod_ssl and restart Apache.

yum install mod_ssl
apachectl restart

SSL uses certificates to test the authenticity, so you can buy one or for the purpose of testing, you can generate your own fake certificate authority (CA), request a certificate from the CA and then sign it.
Let’s say that we want another virtual host called https://test.iandreev.us that will run on port 443.
Let’s generate the certificate.

openssl genrsa -out test.iandreev.us.key 1024
openssl req -new -key test.iandreev.us.key -out test.iandreev.us.csr
openssl x509 -req -days 365 -in test.iandreev.us.csr -signkey test.iandreev.us.key -out test.iandreev.us.crt

Fill out the questions asked. The most important thing is “Common Name (eg, your name or your server’s hostname)”. Enter the FQDN of the domain in our case test.iandreev.us. The file with the .crt extension is your server certificate. Copy the certificate file *.crt under /etc/pki/tls/certs directory and copy the key file under /etc/pki/tls/private.
The definition for the SSL virtual hosts have the same structure as regular hosts on port 80, except that you have to specify the certificate path and the key path. Also, you have to specify the port 443, very similar to a regular host.
In our case, it will be.

<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile /etc/pki/tls/certs/test.iandreev.us.crt
        SSLCertificateKeyFile /etc/pki/tls/private/test.iandreev.us.key
        ServerAdmin klimenta@iandreev.us
        DocumentRoot /var/www/test.iandreev.us
        ServerName test.iandreev.us
        ErrorLog logs/test.iandreev.us-error_log combined
        CustomLog logs/test.iandreev.us-access_log combined
</VirtualHost>

See above (firewall-cmd –add-service=https –permanent && firewall-cmd –reload) how to open a firewall port. Replace service=http with service=https and you are all set.

MySQL or MariaDB

We’ll use MariaDB which is a drop-in binary replacement for MySQL.

yum install mariadb-server mariadb
systemctl enable mariadb
systemctl start mariadb
mysql_secure_installation

The first command installs the server and the client, the second line enables the server to start on boot, the third line starts the server and the fourth line configures MySQL/MariaDB for the first time.
Check my previous post. MySQL initial config is exactly the same.
There is no need to allow MySQL/MariaDB outside, so we won’t configure the firewall for MySQL.

PHP

We will install PHP and the MySQL module for PHP using:

yum install php php-mysql php-extensions php-curl php-zlib

Restart Apache after that.

systemctl restart httpd

BTW, you can also use apachectl command to start, stop or reload Apache. The syntax is apachectl stop or apachectl start, etc…
Now, let’s go to one of the virtual hosts that we created earlier and create a small PHP file.

cd /var/www/blog.iandreev.us
echo "<?php phpinfo(); ?>"> index.php

If you go to your web-site now, you’ll see something like this.

Congrats, if you made it, now you have a full LAMP stack installed. To see a working example, we’ll install WordPress. Pretty much all web-apps based on PHP are installed this way. You configure your virtual host, create the database and point your browser to the install or index file. The rest is just simple configuration.

WordPress

Let’s delete our blog directory first.

cd /var/www
rm -Rf blog.iandreev.us

Get the latest WordPress install file.

wget http://www.wordpress.org/latest.zip

The default CentOS doesn’t come up with unzip, so get unzip first and then unpack the archive.

yum install unzip
unzip latest.zip

You’ll see a directory called wordpress. Just rename it so it becomes a root folder for the virtual host.
In my case, I’ll rename the wordpress folder to blog.iandreev.us, because that’s what I have as a DocumentRoot in my config file for the virtual hosts.

mv wordpress blog.iandreev.us
chown -R apache:apache blog.iandreev.us

Let’s create the required database. We’ll specify the database name (wordpress), the user that will have owner rights (wpuser) and its password (secret).

mysql -u root -p

Type your root password and then type the following SQL commands.

CREATE DATABASE wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO "wpuser"@"localhost" IDENTIFIED BY "secret";
FLUSH PRIVILEGES;
QUIT;

Go to http://blog.iandreev.us, choose the default language and when prompted enter the values that you used when you created the database.

Click Submit, then Run Install and you are all set.

First, make sure that you have Apache, PHP and MySQL (MariaDB) installed and properly configured. In order to avoid any problems down the road, make sure that you have the same version of the software. There are some WordPress plugins that allow you to backup/restore the database and the content, but we’ll do this manually.

Let’s say that I want to migrate www.iandreev.com from one server to another. First, change the DNS so the hostname points to the new IP. Create a test HTML file and see that you can actually browse to the new web site. Once completed, stop the Apache web server and MySQL database on the old server. Go to the root folder where your WordPress installation is and open the wp-config.php file. These are the values that you will need.

 
/** The name of the database for WordPress */ 
define('DB_NAME', 'wwwiandreevcom'); 
/** MySQL database username */ 
define('DB_USER', 'username); 
/** MySQL database password */ 
define('DB_PASSWORD', 'password'); 
/** MySQL hostname */ 
define('DB_HOST', 'localhost'); 

Backup this database with:

mysqldump -u <username>  -p <password> databasename > /somewhere/dbname.sql 

Note: Don’t leave a space between “-p” and the password.

Once you have the database backed up, transfer it to the new server using scp or whatever you use to transfer files between servers. In my case I typed this command on the old server.

scp wwwiandreevcom.sql myusername@www.iandreev.com: 

Where wwwiandreevcom.sql is the backup file, myusername is the username that I use on both servers and www.iandreev.com is the new server hostname.

Create the database on the new server and grant necessary rights.

create database wwwiandreevcom; 
grant all privileges on wwwiandreevcom.* to "username"@"localhost" identified by "password"; 
flush privileges; 

Make sure that the database name, username, password and host are the same as on the old server.
Now, restore the database.

mysql -u username -p wwwiandreevcom < wwwiandreevcom.sql 

Where wwwiandreevcom is the database being restored and wwwiandreevcom.sql is the dump file of the database that we transferred from the old server.

There is no need to install WordPress from scratch on the new server, so go back to the old server and compress the WordPress installation folder.

tar czvf zipfile.tgz www.iandreev.com 

Where www.iandreev.com is my WordPress installation directory. Transfer the tarball to the new server.

scp zipfile.tgz myusername@www.iandreev.com: 

Move the file where your new installation will be and unpack it.

tar xvf zipfile.tgz 

Make sure to change the owner to the user that runs Apache if needed. In my case I had to do:

chown -R www:www www.iandreev.com 

That’s it. Go to www.whatever.com and you’ll see your website/blog back in action.
Note: If you receive the following error:

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

Then install the following Apache modules and restart Apache.

pkg install php5-pdo_mysql
apachectl graceful