Passenger-Rails with Ruby 1.9 App Server (v13.5 LTS)

Software Application Versions

• Apache 2.2
• Ruby 1.9
• Phusion Passenger 3.0
• MySQL Client 5.5

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.

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.

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.
   
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. 
   
   
   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. 
   
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.
   
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.