Chapter 10. Applications

10.1. Introduction to Applications

When a new application is created, a URL with name of the application and the name of the domain is registered in DNS. A copy of the application code is checked out locally into a folder with the same name as the application. Note that different types of applications may require different folder structures. Application components are run on gears.
With each new application that is created with the client tools, a remote Git repository is populated with the selected cartridge, which is then cloned to the current directory on the local machine. The host name and IP address of the application are also added to the list of known hosts in the ~/.ssh/known_hosts directory.
The following table describes each component that makes up an OpenShift Online application.

Table 10.1. Application Components

Component Description
Domain The domain provides a unique group identifier for all the applications of a specific user. The domain is not directly related to DNS; instead, it is appended to the application name to form a final application URL of the form http://App_Name-domain.example.com
Application Name The name of the application is selected by a user. The final URL to access the application is of the form http://App_Name-domain.example.com
Alias DNS names can be provided for the application by registering an alias with OpenShift Online and pointing the DNS entry to the OpenShift Online servers.
Git repository A Git repository is used to modify application code locally. After the code is applied, the git push command is required to deploy the revised code.
OpenShift Online provides dedicated /var/tmp and /tmp directories for each user application. The /var/tmp directory is a symbolic link to /tmp. Each /tmp directory is completely isolated from the /tmp directories of all other applications. Files that are untouched for any period of ten days are automatically deleted from these directories.

10.1.1. Application Life Cycle

The following table describes the general life cycle of most OpenShift Online applications.

Table 10.2. Application Life Cycle

Process Description
Code Develop the application code with the desired language and tools. Continuously push the application code to the applications remote Git source code repository.
Build OpenShift Online supports various build mechanisms, whether it is a simple script, a personal Jenkins continuous integration server, or an external build system.
Deploy Every application is composed of cartridges that simplify server maintenance and configuration. OpenShift Online supports various technologies to provision the required services automatically.
Manage OpenShift Online allows real-time monitoring, debugging, and tuning of applications. Applications are scaled automatically depending on web traffic.

10.1.2. Scalable Applications

Applications can be created as either scalable or not scalable. Scalable applications feature the load-balancing proxy (HAProxy) gear, which is contained on the same gear as the web framework cartridge. The load-balancing proxy provides horizontal scaling by cloning the gears containing the framework cartridge and application data onto mulitiple gears.
Scalable applications are set to scale automatically by default. However, you can scale an application manually. See Section 11.6, “Scaling an Application Manually” for more information.
How Auto-scaling Works
Each application created on OpenShift Online must have one web framework cartridge defined upon creation. For example, a PHP cartridge. When an application is defined as scalable, a second cartridge, the HAProxy cartridge, is added to the application. The HAProxy cartridge listens to all incoming web-page requests to an application and passes them to the web cartridge, following the defined guidelines for load monitoring.
When the number of web-page requests to an application increases, the HAProxy informs OpenShift Online when an overload of requests is detected. A copy of the existing web cartridge and application data is then cloned to a separate gear. In such a case, the web cartridge has now been scaled up two times. This process is repeated as more web-page requests are detected by the HAProxy cartridge, and each time a copy of the web cartridge is created on a separate gear, the application scale factor increases by one.
When the application (by default) reaches three copies of the web framework cartridge, the HAProxy load-balancer disables routing to the framework cartridge located on the same gear. This gives the HAProxy cartridge full gear resource usage, which continues to route requests to the framework cartridges located on separate gears. Routing to the framework cartridge located with the HAProxy cartridge is enabled again once the application is scaled down.
Cartridges on Gears in a Scaling Application

Figure 10.1. Cartridges on Gears in a Scaling Application