Install the Web Application
[root@centos66 ~]# mkdir /var/www/demoapp
In this directory, you should not put all your application code, but instead create a folder for each release which you do (Please Note: This is just a recommendation, if you are implementing Continuous Integration/Deployment, you can do things differently).
Assuming that you have made a release of the application "demoapp" with version "2.4.2"; create a suitable release directory:
[root@centos66 ~]# mkdir /var/www/demoapp/2.4.2
Transfer your code to to this directory. In the directory you can have multiple folders, e.g., folders for web documents, include classes, tests, documentation, bootstrap data, configurations, and so on. In this example, I will assume that you install the scripts which you want to expose to the web server, in a folder called "html".
The main benefit of creating a new folder for each release, is that it's very easy to go back to a previous release, if a serious problem is found in the latest one. To point out which release which should be active, you can create a named symbolic link, which points to the active release. In this article, we will assume that you create a symbolic link named "current" in the directory /var/www/demoapp, which point's to the currently active release folder, e.g. /var/www/demoapp/2.4.2. See image below. To create the symbolic link, use:
[root@centos66 ~]# ln -sf /var/www/demoapp/2.4.2 /var/www/demoapp/current
Of course, you don't need to store hundreds of old releases on the server, so make it a habit to clean up old releases which you believe you will not go back to. If such a release is really needed, it can be retrieved from the code repository.
In the image below, there is just one script in the html-directory, a Single Entry-Point-script, which will handle all requests for the demo-application.
Different type of IP-addresses
[root@centos66 ~]# /sbin/ifconfig
IP-addresses strating with "192.168", "172.16" through "172.31" as well as "10" are private addresses. These are not accessible from internet. The address "127.0.0.1" is an alias for the server itself, it is only reachable from your own server. All other IP-addresses are accessible from internet. So depending on if your application should be reached from your network only, or all of internet, you need to acquire a suitable IP-address.
Configure the Web Application
The web server config file, in short, tells the server what application to execute on which IP-address, together with rules. A sample configuration file can be fetched from my public Bitbucket repository. In the vlamp directory, you find a file called 001-demoapp.conf, which will be used in this article.
There are explaining comments in the file, so I will just go through the sections briefly. For details, check the Apache Documentation.
Listen, NameVirtualHost - Defines what the web server should listen to. If you have several web applications on the same server, you can use different IP-addresses and ports. Also, the same application can have multiple IP-addresses with different configuration files (adding encryption/authentication when listening on a public interface, for instance).
VirtualHost - Start defining a specific web application Everything outside such a section, is seen as global configuration, for all applications on the web server.
ServerName, ServerAlias - If you have a DNS setup, you can bind the IP-address to a nice domain name,. It's easier to remember "www.araneo.se" than "184.108.40.206". It's not a requirement though, in this article we'll be using IP-numbers only.
DocumentRoot - Tells the web server where the public accessible scripts are located. Use a specific directory for the scripts which need direct access from the web server here, and all other files (include files, data files, configuration, tests) somewhere else! The fewer files exposed to the web server, the better!
ServerTokens, ServerSignature - Controls how much information the web server sends back to the client about itself. This should be restricted, as exploits can be built around specific versions of the web server.
Directory - Set rules regarding the files which are exposed to the web server. Here, you can configure access control, for instance.
Files - Access rules for file names. Can be used to restrict access to files which shouldn't be accessed b y the web server directly (config files, include files) or access to files which shouldn't be there in the first place, but can end up on the server by mistake (database dumps, test bootstrap data).
php_flag, php_value - Set PHP Configuration for the web application. Can be useful to do in the web configuration instead of the php configuration file for the application, for values which are different per-environment (production, testing, UAT, Stage, Development).
LogFormat, CustomLog, ErrorLog - Rules of what to put in the Access/Error Log, and where to store it. For a list of the available parameters, check the Apache Documentation.
In the Part 7 of the article, we will install and configure the MySQL Database, and create an application user.