PHP applications are supported through Apache and mod_php, and require very little configuration to deploy.
You will need at least two files to deploy a PHP app on Stackato: index.php, and stackato.yml.
The stackato.yml must specify the php as the framework type:
framework:
type: php
For full details on the stackato.yml and all possible options, see Configuration With stackato.yml.
Some applications require the user to specify the APP_URL. Below is an example on how to obtain the correct urls:
$appinfo = getenv("VCAP_APPLICATION");
$appinfo_json = json_decode($appinfo,true);
$admin = $appinfo_json['uris'][0];
Non-HTTP apps that run as a Stackato application under the control of the Health Manager.
To deploy worker applications, you need to use the command key and set the proceses: web key to Null ("~").
name: php-app
framework: php
command: php worker.php
processes:
web: ~
Authentication details for your configured database services can be found in the $_SERVER variable, under DATABASE_URL. Here is an example of getting the correct credentials.
<?php
$url_parts = parse_url($_SERVER['DATABASE_URL']);
$db_name = substr( $url_parts['path'], 1 );
$db_connection_string = $url_parts['host'] . ':' . $url_parts['port'];
// ** MySQL settings from resource descriptor ** //
echo $db_name;
echo $url_parts['user'];
echo $url_parts['pass'];
echo $url_parts['host'];
echo $url_parts['port'];
?>
<?php
$services = getenv("VCAP_SERVICES");
$services_json = json_decode($services,true);
$mysql_config = $services_json["mysql"][0]["credentials"];
// ** MySQL settings from resource descriptor ** //
echo $mysql_config["name"];
echo $mysql_config["user"];
echo $mysql_config["password"];
echo $mysql_config["hostname"];
echo $mysql_config["port"];
);
?>
Additional PHP ini files will be loaded from the $STACKATO_APP_ROOT/apache/php/ directory. Refer to the example below for more information.
If your document root (the location of the main index.php file) is the main application directory, the information stored in stackato.yml and manifest.yml is exposed to the browser. Note that manifest.yml is generated automatically, even when you don't use stackato.yml.
To prevent exposing this information, you can use an .htaccess file in the document root directory with the following rule:
<filesmatch "^(manifest|stackato)\.yml$">
order allow,deny
deny from all
</filesmatch>
Alternatively, move your application into a subdirectory (e.g. move index.php to www/index.php) and explicitly set your document-root in stackato.yml:
framework:
document-root: www
Using the .htaccess file will generate an "HTTP 403 Forbidden" error if a user tries to access the denied files. Changing the document-root will generate an "HTTP 404 Not Found" error instead.
These techniques can be use to hide other files in your application source tree which you do not want exposed to end users.
One of the issues with managing a custom PHP application with multiple instances in Stackato is dealing with user sessions.
Because of Stackato's architecture, a user of your site may not access the same server that started their session for each subsequent HTTP request. Based on traffic at any given moment, the router in Stackato 1.2.6 will direct requests to any DEA associated with your app. This will be improved in a new version of the router.
A simple solution is to store the user session in a shared location on the persistent file system. If your custom PHP application stores sessions in a database, you do not have to worry about this issue.
Add a new filesystem service in stackato.yml file:
services:
session-fs: filesystem
Override the default location for storing session variables by creating a .ini file and putting it in $STACKATO_APP_ROOT/apache/php/.lly located at the top of most PHP files:
hooks:
post-staging:
- mkdir -p "$STACKATO_FILESYSTEM"/sessions
- ln -s "$STACKATO_FILESYSTEM"/sessions "$STACKATO_APP_ROOT"/sessions
- echo "session.save_path = /app/sessions" > "$STACKATO_APP_ROOT"/apache/php/sessions.ini