This is an example application which can be run on CloudFoundry using the PHP Build Pack.
This is an out-of-the-box implementation of Drupal. It's an example of how common PHP applications can easily be run on CloudFoundry.
- Clone the app (i.e. this repo).
git clone https://github.com/dmikusa-pivotal/cf-ex-drupal.git cf-ex-drupal
cd cf-ex-drupal
- If you don't have one already, create a MySQL service. With Pivotal Web Services, the following command will create a free MySQL database through ClearDb. Any MySQL provider should work.
cf create-service cleardb spark my-test-mysql-db
-
Edit the manifest.yml file. Change the
host
attribute to something unique. Then underservices:
changep-mysql-db
to the name of your MySQL service. This is the name of the service that will be bound to your application and thus used by Drupal. -
Edit
sites/default/settings.php
and change thedrupal_hash_salt
. This should be uniqe for every installation. Optionally edit any other settings, however you do not need to edit the database configuration. The file included with this example will automatically pull that information fromVCAP_SERVICES
. -
Push it to CloudFoundry.
cf push
- On your first push, you'll need to access the install script. It'll be
http://<your-host-name>.cfapps.io/install.php
. Follow instructions there to complete the install. After it's done, you'll be all set.
When you push the application here's what happens.
- The local bits are pushed to your target. This is small, five files around 25k. It includes the changes we made and a build pack extension for Drupal.
- The server downloads the PHP Build Pack and runs it. This installs HTTPD and PHP.
- The build pack sees the extension that we pushed and runs it. The extension downloads the stock Drupal file from their server, unzips it and installs it into the
htdocs
directory. It then copies the rest of the files that we pushed and replaces the default Drupal files with them. In this case, it's just thesites/default/settings.php
file. - At this point, the build pack is done and CF runs our droplet.
-
I include a custom list of HTTPD modules. These are the same as the default, but I've added
mod_access_compat
, which is necessary because Drupal's.htaccess
file still uses HTTPD 2.2 config. -
I add the PHP extensions that are needed by Drupal.
-
I add a custom build pack extension, which downloads Drupal on the remote server. This is not strictly necessary, but it saves me from having to upload a lot of files on each push. The version of Drupal that will be installed is here.
-
I include a copy of the default settings from the standard Drupal install. This is modified to pull the database configuration from the
VCAP_SERVICES
environment variable, which is populated with information from services that are bound to the app. Since we bind a MySQL service to our app in the instructions above, we search for that and automatically configure it for use with Drupal.
Please read the following before using Drupal in production on CloudFoundry.
- Drupal is designed to write to the local file system. This does not work well with CloudFoundry, as an application's local storage on CloudFoundry is ephemeral. In other words, Drupal will write things to the local disk and they will eventually disappear.
You can work around this in some cases, like with media, by using a storage service like Amazon S3 or CloudFront. However there may be other cases where Drupal or Drupal plugins try to write to the disk, so test your installation carefully.
- This is not an issue with Drupal specifically, but PHP stores session information to the local disk. As mentioned previously, the local disk for an application on CloudFoundry is ephemeral, so it is possible for you to lose session and session data. If you need reliable session storage, look at storing session data in an SQL database or with a NoSQL service.