Stackato Gets Some Sugar
by Troy Topnik

Troy Topnik, October 1, 2012

SugarCRM on Stackato Sugar CRM is industry-leading customer relationship management software. We've had it working well on Stackato since before 1.0 was released, but we've held off on putting it in Stackato's App Store till we could get a smooth install experience.

With the help of the indefatigable Steven Hsu, who's been maintaining the Stackato sample apps on Github, we've got the latest version of SugarCRM Community Edition working quite nicely. With one click you can install Sugar CRM on any Stackato PaaS, and with a few more steps through Sugar's web configuration wizard, you can have your own CRM system up and running.


The SugarCRM developers have put a lot of effort into making sure that Sugar can run in a wide variety of hosting environments. As with other PHP applications, Apache-based shared hosting providers is a pretty standard target platform. To that end, they've developed a really friendly setup wizard that guides an admin through the setup through a web-based install wizard.

Our challenge was to inject some Stackato-specific configuration options into that wizard, specifically to populate the Database Configuration step with the credentials for the MySQL database that Stackato can provision automatically during the deployment. When Steven showed me how easy that was to do, I smacked my wrist (actually my forehead) for not having figured that out when I looked at this months ago.

Simple Stackato configuration

I'm getting a bit ahead of myself here. This post is not just about talking up a new item in the App Store, it's about how straightforward it is to do this with almost any PHP app. So, I'll go over some of the same things I covered in my post about ownCloud, then get into some SugarCRM details. Feel free to cross-reference these snippets with the 'Stackato-Apps/sugarcrm' repo on Github.

First, we need to create a config file for Stackato. Let's look at the first few lines:

name: sugarcrm
  type: php
mem: 256
  ${name}-db: mysql
  ${name}-fs: filesystem 

Nothing terribly unusual here. The default name is set (though you can override this), the framework, the amount of memory to allocate, and the services we intend to use.

The ${name} variable might be new to you if you haven't used Stackato in a while. As of version 2.2 you can use this variable to insert the unique application name to populate other values (not just the one in the config file, it will use the deployed name if you've specified it elsewhere). As used here, these variables make sure the services are unique to the application.

Why the filesystem service?

For reasons which become clear as we continue, we've added a filesystem service so that multiple application instances can share things. This shared filesystem is set up by a bash script called by a post-staging hook:

    # setting up in filesystem
    - sh

The shell script checks for a config.php file, creates a number of directories on the shared filesystem, copies some directories in from the source tree, and creates some symlinks from the application container to the mounted filesystem.

You could deploy Sugar without the filesystem service and all of this copying and linking, but you'd be losing a key benefit to running the app on Stackato in the first place: scalability.

In true "cloud" fashion, application instances in Stackato (and most other PaaS systems) are ephemeral and will disappear if the instance is terminated, restarted, or updated. Also, anything you save to that local filesystem is available to only that app instance. That might be fine if you're only running a single application instance, but not if you've got a pool of them spread across several servers.

The typical way to avoid this limitation is to use the database (which certainly is persistent) to store everything, including sessions and file uploads. Unfortunately, a lot of applications predate this convention, and the filesystem is treated as if it were local and persistent. The filesystem service solves this problem.

When you request a filesystem service for your application (or applications - they're sharable), Stackato mounts it in all the Linux containers for that application. Anything saved there will be available to all application instances and will stick around when the app is restarted or updated. This is obviously necessary for things like files uploaded by users (e.g. image uploads to Drupal) but it can also keep track of sessions, so you don't get logged out if the Router directs your web request to a different app instance in the pool.

So that's all that's required on the Stackato side. Let's look at the config changes on the SugarCRM side.

Six lines

As I mentioned, Sugar has a great web install wizard that guides you through initial configuration. All we have to do is give the user of that wizard some helpful default. Most importantly, we want to pass the database credentials.

In the stackato.yml file, we've asked Stackato for a MySQL database. The credentials for the admin user of that database are provided by environment variables (DATABASE_URL, MYSQL_URL, STACKATO_SERVICES, or VCAP_SERVICES - take your pick). Parsing these in Sugar's install/install_defaults.file file turns out to be trivial. We'll use the DATABASE_URL, which might have a value like:


See why we don't want people to have to enter that in the web wizard manually? The installer can do it for us.

$url_parts = parse_url($_SERVER['DATABASE_URL']);
$db_name = substr( $url_parts{'path'}, 1 ); 

Further down, we use these variables to fill in the relevant values:

      'setup_db_database_name' => $db_name,
      'setup_db_host_name' => $url_parts{'host'},
      'setup_db_admin_user_name' => $url_parts{'user'},
      'setup_db_admin_password' => $url_parts{'pass'}, 

When you deploy this and step through the wizard, these values are presented as the defaults:

Sugar DB Setup Page

php.ini et al

The most crucial file for configuring PHP with Apache in any system is php.ini. Unfortunately, Stackato users without 'sudo' permission in containers (i.e. default users) won't be able to modify this file.

Not a problem. Any additional configuration options you need to set can be added in separate .ini files in the source tree which you then copy into the container's /app/apache/php/ directory in post-staging or pre-running hooks. The sugarcrm.ini file does this to set a few options.

There's always more...

There are a lot more things you can customize with the Sugar/Stackato pairing. I'm sure the Sugar experts in the audience could think of a number of additional tweaks to the system that could get it working even better, so by all means check out the sources and have a go.

For all the rest of us there's now a usable, scalable, and quick way to deploy Sugar CRM Community Edition with one click from the App Store.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

As ActiveState's Technical Product Manager for Stackato, Troy Topnik is responsible for defining and prioritizing the product roadmap to build the best cloud platform for deploying applications. Since joining ActiveState in 2001, he has held roles in Technical Support, Training, and Technical Writing. He believes in documentation-driven development as a pragmatic path to a better user experience.


1 comments for Stackato Gets Some Sugar

Sugar Plug-in for Microsoft Outlook integrates your CRM data with your Outlook client. With a few clicks, Sugar users can sync email, contacts, and calendar information into Sugar modules.