- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
Tara Gibbs, August 13, 2013
We’ve had Drupal available in Stackato’s App Store for a long time now. That deployment of the app is great for demos, or to get up and running quickly with a CMS, but a more in-depth Drupal workflow involves working with customized sources, doing local testing and debugging, and maintaining plugins in the local source tree.
With that in mind, here’s your handy, dandy guide to working with Drupal 7 on Stackato.
As with any app you want to run on Stackato, you’ll need to create a stackato.yml file so that Stackato knows what kind of resources and services to allocate.
Let’s start with this stackato.yml for a Drupal 7 install:
name: drupal instances: 1 framework: php mem: 256M services: dev-db: mysql dev-fs: filesystem # prod-db: mysql # prod-fs: filesystem
This file tells Stackato to create a PHP app called ‘drupal’ that runs on a single instance. It allocates 256MB of memory, and binds the app to a MySQL service and a filesystem service (the production services are commented out for the time being, but we can switch those later).
The reason for the MySQL binding is pretty obvious; Drupal requires a database to work. I’ve also added the filesystem service so that we can use it for the /site/default/files directory. This is where uploaded files are kept, and by using the filesystem service for this directory, we solve two problems:
- Files that are uploaded via Drupal and saved in the application container (i.e. not on a filesystem service) are ephemeral. Next time the app is updated, they’ll disappear.
- If you save user-uploaded files to the filesystem service, you can scale up your Drupal app instances and not have to worry about syncing uploaded files across different nodes. They’ll all be in one place, no matter which instance of your app a user connects to during the file upload.
Setting up the filesystem service handle the /sites/default/files directory requires running some commands after the app has been staged, so we’ll need a setup script to run as part of the deployment process.
#!/bin/bash if [ -d $STACKATO_FILESYSTEM ] then echo "Found a persistent filesystem at: " echo $STACKATO_FILESYSTEM if ! [ -d $STACKATO_FILESYSTEM/files ] then echo "No Drupal files in $STACKATO_FILESYSTEM." echo "Creating directory and symlinking..." mkdir -p $STACKATO_FILESYSTEM/files ln -s $STACKATO_FILESYSTEM/files sites/default/files echo "Finished moving and symlinking" else echo "Persistent Drupal files found. Symlinking..." ln -s $STACKATO_FILESYSTEM/files sites/default/files echo "Finished deleting and symlinking" fi else echo "No persistent filesystem found, using ephemeral disk." echo "Warning: user content will be lost on restart." fi
This script checks if the filesystem service has been successfully bound. If the /files directory doesn’t exist on the filesystem service, it creates it. Then it symlinks the directory to /sites/default/files.
Now that we have a script to run after the app is staged, we need to add it to our stackato.yml file as a pre-running hook.
name: drupal instances: 1 framework: php mem: 256M services: dev-db: mysql dev-fs: filesystem # prod-db: mysql # prod-fs: filesystem hooks: pre-running: - sh stackato-setup.sh
You may also have noticed that there are two sets of services; dev and prod. You can easily switch between development and production databases with a quick edit of the stackato.yml file and a stackato update.
On your first deployment, you’ll need to go through the standard Drupal setup. To get the database credentials for your bound MySQL service, you run the following command:
stackato service <servicename>
Where <servicename> is will be either ‘dev-db’ or ‘prod-db’ depending on which database you want to connect to.
That’s it! That’s all there is to getting Drupal up and running on Stackato. And yes, this works for Drupal 8 as well!
Subscribe to ActiveState Blogs by Email