Home > ServerTemplates > v13.5 LTS > ST > PHP App Server (v13.5 LTS)

MindTouch
Copyright (c) 2006-2014 MindTouch Inc.
http://mindtouch.com

This file and accompanying files are licensed under the MindTouch Master Subscription Agreement (MSA).

At any time, you shall not, directly or indirectly: (i) sublicense, resell, rent, lease, distribute, market, commercialize or otherwise transfer rights or usage to: (a) the Software, (b) any modified version or derivative work of the Software created by you or for you, or (c) MindTouch Open Source (which includes all non-supported versions of MindTouch-developed software), for any purpose including timesharing or service bureau purposes; (ii) remove or alter any copyright, trademark or proprietary notice in the Software; (iii) transfer, use or export the Software in violation of any applicable laws or regulations of any government or governmental agency; (iv) use or run on any of your hardware, or have deployed for use, any production version of MindTouch Open Source; (v) use any of the Support Services, Error corrections, Updates or Upgrades, for the MindTouch Open Source software or for any Server for which Support Services are not then purchased as provided hereunder; or (vi) reverse engineer, decompile or modify any encrypted or encoded portion of the Software.

A complete copy of the MSA is available at http://www.mindtouch.com/msa

PHP App Server (v13.5 LTS)

 

Table of Contents    

Long Term Support

Stable, tested ServerTemplate assets

   ►   Overview

 


 

Description

Configures a dedicated PHP application server with Apache. The ServerTemplate contains scripts and inputs that allow an application server to connect to various load balancing solutions such as Amazon's Elastic Load Balancing (ELB), Rackspace's Cloud Load Balancers (CLB), or a server launched with RightScale's 'Load Balancer with HAProxy' ServerTemplate. 

The ServerTemplate supports multiple clouds and is commonly used as part of a three-tier website architecture. It also includes iptables management for clouds that do not support cloud-level firewall services like security groups.

Note: For a complete list of the ServerTemplate's features and support, view the detailed description under its Info tab.

Software Application Versions

  • Apache v2.2
  • PHP v5.3
  • MySQL Client (5.1 or 5.5)

Technical Overview

Retrieval of Application Code

The ServerTemplate contains scripts that support the retrieval of application code from the following locations:

  • ROS Container (*.zip, *.tgz)
  • SVN Repository
  • Git Repository
  • FTP Server
  • Specified URL (http://www.example.com/myapp.zip)
  • rsync

 

The application code will be placed on the local instance in a location that is based upon the values specified for the following inputs. 

  • Project App root - text: /home/webapps   (default)
  • Application Name - text: myapp


In the example above, the root directory for the application code will be stored in: /home/webapps/myapp

Security and Firewall Permissions

In a typical web architecture, application servers need to securely connect to both the database and a load balancing service. The diagrams and scenario below will explain how an application server will connect to the different tiers.

Network Level

In all clouds, regardless of whether they support security groups or not, Iptables is used to set IP-specific port permissions, which provides better firewall permission control than only using security groups because access permissions are IP-specific (not group-specific). 

For example, the database server will only listen for requests from servers defined in its Iptables configuration file. Remember, in most cloud infrastructures, you typically cannot control what private IP address is assigned to an instance. (e.g. EC2, instances are randomly assigned a private IP address at launch time.)

Before an application (e.g. PHP) can perform an action on a database (e.g. create a new record), the application server(s) must first be granted access at the network-level before it can successfully make an application-level request.

diag-app_security_netlevel-v1.png

Application Level

Once the database server has updated its permissions to allow access between the application and database tiers, the application will be able to connect the database using the required information. For example, the application will locate the "master" database server using the 'Database Master FQDN' input (e.g. master-db.example.com). The application will access the database, which is defined by the 'Database Schema Name' input by using the username and password of a database user that has database access privileges, which is specified by the 'Database Application Username' and 'Database Application Password' inputs.

diag-IPTables_permissions_App-v2.png

Example

The following scenario will explain how iptables and tags are used to configure secure firewall permissions in the cloud.

  1. A master database server (Master-DB) is operational and is configured to accept inbound requests from a set of application servers. Below is an example screenshot of the master database server's security group permissions.
    screen-SecGrp_DB-v1.png
  2. Connectivity between an application server and the Master-DB server is established by using tags. When an application server is launched, the 'db::request_appserver_allow' (boot) script makes a request to all database servers to accept its requests. It's also worth noting that each database server (e.g. master and slave) with the 'database:active=true' tag will update its iptables configuration file to allow access to the designated application servers so that if the "slave" database server is promoted to become the new "master" database server, the application servers will already be allowed to connect to it to enable faster database promotions. If the application server has the appropriate tag ('appserver:active=true') in the same deployment, a script is run on a database server, which updates its iptables to allow connections on TCP port 3306 over the private network from the application server's private IP address. The database server will have an audit entry for the 'completed: db::do_appservers_allow' script that confirms the modification to its firewall permissions. In the example below, both application servers are granted access to the database server. 
    screen-Audit_AllowApp-v1.png

    The Master-DB server will automatically look for other application servers within its deployment that have the appropriate "app" server tag and update its iptables accordingly so that as the pool of application servers change over time, each application server will have access to the Master-DB server. By default, the 'db::do_appservers_allow' script is periodically executed every 15 minutes to make sure that all application servers can connect to the Master-DB server. You can see the default setting in the database ServerTemplate's 'Reconverge List' input. 
    screen-DB_Reconverge_List-v1.png
  3. Connectivity between an application server and a load balancer server is also established by using tags. If you are using dedicated load balancer servers launched with the 'Load Balancer with HAProxy' ServerTemplate, application servers are configured to periodically allow access to properly tagged load balancer servers so that incoming requests can be successfully sent to a validated application server. For example, if you're using HAProxy for load balancing, the application servers use the 'Reconverge List' input to periodically run the the 'app::do_loadbalancers_allow' script, which allows access to all servers in the same deployment with the 'loadbalancer:default=lb' tag. By default, the application servers will listen on TCP port 8000 for requests from the private IP address of each load balancer server. If the private IP address is not undisclosed, the public IP address will be used instead. In the screenshot below, an application server is updating its iptables to allow ingress communication from the two load balancer servers in the deployment.
    screen-Audit_AllowLB-v1.png
  4. Application servers are either added to the load balancing pool automatically or manually. Note: The Health Check ('Health Check URI' input) must be successful before an application server is added to the HAProxy load balancing pool.
    • Automatically
      1. Load balancer and application servers will connect to each other automatically at boot time. The following boot scripts establish connectivity for their respective servers. For load balancers, the 'lb::do_attach_all' boot script. For app, 'lb::do_attach_request' boot script. 
      2. During a reconverge the load balancer servers will run the 'lb::do_attach_all' script every 15 minutes and connect to any serviceable application servers.
    • Manually
      • Run the 'lb::do_attach_request' operational script on an application server.
      • Run the 'lb::do_attach_all' operational script on a load balancer server.

 

If you need to open other ports on an application server besides the default TCP ports (8000), you must create the appropriate rules using the "Firewall" inputs, as described in the Base ServerTemplate for Linux (Chef) (v13.5 LTS) - Runbook documentation.

Note: For more information about iptables, refer to the Linux supporting documentation for this tool.

You must to post a comment.
Last Modified
09:56, 28 Jul 2014

Tags

Classifications

This page has no classifications.

Announcements

None

Glossary | 用語용어 Site Map | Site Help Community Corporate Site Get Support Dashboard Login
Doc Feedback Product Feedback Resources MultiCloud Marketplace Forums

Dashboard Status


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.