I launched my first Amazon instance in the middle of 2014. At the time, I installed the latest web server technology – PHP 5.3 and Apache 2.2. Since technology never stops moving forward, especially software, I figured it was time to move to newer PHP and Apache versions. In my case, I chose PHP 5.6 and Apache 2.4. Here are the steps I followed for the upgrade.
There were two posts that I used as reference for performing the upgrade:
StackOverflow – How to Install Php5.6 in amazon linux
Brian’s Tips and Tricks for Web Developers – Update Your Amazon AMI from PHP5.3 to PHP5.4 or Higher
Both posts served as the basis for the process that I followed below.
Preparing for the upgrade
Upgrading PHP and the web server cannot be completed live. In other words, your web server is going to experience downtime doing the upgrade process. Therefore, make sure that you plan for the downtime and perform the upgrade when traffic is light. In addition, as Brian points out in his post, be sure that you allocate sufficient, dedicated time to complete the upgrade once you start it. You don’t want to step out in the middle of it, leaving your web server down.
Snapshot the EC2 instance
The first thing I did was snapshot the OS and data volumes I was using for the instance. Just in case things went sideways, I wanted to be able to recover the machine state and start over. I followed the Amazon instructions for creating a snapshot.
To complete the snapshots, I did the following:
- Login to the Amazon console
- Stop the EC2 instance
- Go to Snapshots and use ‘Create Snapshot’ for the EBS OS volume and the EBS data volume that I had attached to the instance
- Wait for the snapshots to complete
- Restart the instance
It’s a wise move to make backups of any websites and applications running on the server. These should be stored in a safe place, meaning not on the web server your upgrading. Store them offline, such as on your local computer. I decided to ‘go commando’ and bypass this step as I had recent backups of the websites running on the server.
Next, I made a copy of the vhosts.conf file just in case it got blown away during the upgrade. I wanted to be able to restore it without having to do it from memory. I’d also recommend making a copy of any other config files, like httpd.conf and phpMyAdmin.conf, in case there are customizations in these files that you want to reference later.
And now, it is time to start the upgrade. At this point, you will be taking your web server offline. Here we go.
Remove the old versions
Stop the Apache service
$ sudo service httpd stop
Remove the current (old) version of Apache
$ sudo yum erase httpd httpd-tools apr apr-util
Remove the current (old) version of PHP
$ sudo yum remove php-*
During the removal process, it’s a good idea to copy the names of the packages that were installed prior to installing the new versions, just in case something doesn’t work after the upgrade. Then you can see if it is related to a package that was not installed.
For example, here was a list of packages that were uninstalled from the instance while removing the current (old) version of Apache:
---> Package apr-util-ldap.x86_64 0:1.4.1-4.17.amzn1 will be erased ---> Package mod_perl.x86_64 0:2.0.7-7.27.amzn1 will be erased ---> Package mod_ssl.x86_64 1:2.2.31-1.8.amzn1 will be erased ---> Package mod_wsgi-python26.x86_64 0:3.2-6.11.amzn1 will be erased ---> Package mod_wsgi-python27.x86_64 0:3.2-6.11.amzn1 will be erased ---> Package php.x86_64 0:5.3.29-1.8.amzn1 will be erased ---> Package phpMyAdmin.noarch 0:184.108.40.206-1.el6 will be erased
You’ll need to refer back to the list(s) that you create after the new Apache and PHP versions are installed to make certain all of the previous packages get reinstalled.
Install the new versions
Once the process of uninstalling the old Apache and PHP version have finished, the new Apache and PHP versions can be installed. As it turns out, you only have to install PHP. The latest version of Apache will be installed with it.
$ sudo yum install php56
After the installation completes, you can check the PHP modules installed against the list you saved during the removal process above by running the following:
$ yum list installed | grep php
Before installing any missing modules, I checked the missing modules against the modules that were available in the latest version of PHP by running the following command:
$ yum search php56
I matched up the missing modules between the php56 list and those previously installed and issued the command:
$ sudo yum install php56-gd
You can run the command for each module that needs installed. Alternatively, you can do it once by listing all of the packages that you want to install on the same command line separated by a space.
Restart the services
At this point, you are almost ready to restart the web server. Before issuing the start command, make sure that the values from the old configuration files, especially vhosts.conf and phpMyAdmin.conf, have been moved into the new configuration files. You should also check the values in the httpd.conf file, although you should inspect these values carefully. There have been changes from Apache 2.2 to Apache 2.4, and you’ll want to tune your setting based on the performance of your server running Apache 2.4.
(I’m not going to get into tuning performance on an Apache web server as that is a complex topic that would need to be covered in separate post(s). If you’re in need of guidance on tuning Apache, I’ve included a few links below that helped me.)
Now that you’re configuration files are set, it’s time to restart the services.
$ sudo service httpd start
To be certain that you are running the latest versions, run the following:
$ php -v $ httpd -v
You should see the following output for PHP:
PHP 5.6.28 (cli) (built: Nov 18 2016 01:43:22) Copyright (c) 1997-2016 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
and the following for Apache:
Server version: Apache/2.4.23 (Amazon) Server built: Jul 29 2016 21:42:17
Your websites should be back up and running. If not, it’s most likely related to either missing packages or incorrect configuration values. Be certain you do a thorough check of the packages that were installed prior to the upgrade and after the upgrade. Also make sure to check the values in your configuration files before and after.
In my case, I had additional complications because my server and website data was on a separate disk than the OS files. Upon upgrading, all of the server data was put back on the OS disk. I had to do some housekeeping to move data from the OS disk to my data volume. I also had to reconfigure the symlinks that had been removed as part of the upgrade. Luckily, I had good notes from when I first setup the server that I was able to refer to in order to make sure all of the files got copied over and that the symlinks were setup properly. It was a little extra work, but worth it in case I ever have to upgrade or recreate a server instance. I can easily port my data by just attaching the EBS that has the data on it and setup the appropriate symlinks to the server files and website data.
Things to check, just in case
Before completing my project, there were two other things that I made certain to do based on advice in Brian’s post above.
First, I made sure that I was able to access phpMyAdmin. I had to reinstall it using the following command:
$ sudo yum --enablerepo=epel install phpmyadmin
After the installation was complete, I checked my old phpMyAdmin.conf file. There were some settings that restricted remote access to phpMyAdmin that I had to copy over to make sure that I could still access it from my local PC.
Second, I made sure that auto start was enabled for the web server and mysql. You can run these two commands to enable auto start for each service:
$ sudo /sbin/chkconfig httpd on $ sudo /sbin/chkconfig mysqld on
As Brian recommended, it’s a good idea to reboot the server after enabling auto start to make sure that the services do indeed start automatically.
Reference for Apache 2.4 tuning
Finally, once everything is running normally, you should check the performance of your server. I frequently run the top command to check on memory usage by the web service.
Using the ‘>’ character once top loads will sort the process by memory usage. In my case, I saw some marked improvements in memory usage, so I wanted to adjust the number of spare and maximum number of web services that were running. I referenced the following posts to understand better how to fine tune Apache.
- Apache Performance Tuning – good general guidance with clear explanations for what each of these confusing and nebulous terms do and mean
- Apache – more detailed explanation of the terms and how the values affect performance. There’s also a good discussion of the different MPMs you can use in Apache: Prefork, Worker, and Event MPM
- 5 Tips to Boost the Performance of Your Apache Web Server – Good generalized recommendations, not as detailed as the first two links
Dislcaimer: These steps applied to my specific situation and setup. I am not an Amazon EC2 expert, nor do I work for Amazon. I documented these for my own personal use in case I need to reference these instructions later to remember and recreate what I did. You are more than welcome to reference these steps, but keep in mind that they may or may not work for you depending on the specifics of your setup. What I’m trying to say, in not so many words, is that I’m more than happy to entertain questions, and I will do may best to offer assistance, but I cannot guarantee timely and accurate responses.
Hey Gregg, thanks for posting your experience, it gave me some ideas for what to do with mine. One thing I would add (if that’s ok) is that I definitely had to add php56-mysqlnd (yum install php56-mysqlnd) to mine to get connected to my database. I’m sure many many others will as well.
Hi Chris – thanks for the input. I don’t recall having to do that in my case, but it’s been a while since I performed the upgrade. And as I mentioned, everyone’s setup probably has some special setup items that they need to be mindful of (kind of like people). Happy to hear that you were able to resolve yours and that it all worked out.
Pingback: 2021 - Year in review for the blog - Gregg Borodaty