Don’t get me wrong, I love Dropbox. They offer free storage, handy cross-platform sync clients, give out nice t-shirts at conferences, and have delivered a much needed service with a great user experience.

But a little while ago a friend of mine posted a plea to her Facebook feed which went something like this:

OK techie friends – Apparently I can’t have Dropbox installed on my work computer [at a hospital in Canada] because of security concerns that the data are stored on US servers. How are the rest of you dealing with this? Is there other similar software out there without this problem? I need a way to access files from multiple computers, and to share some files easily with coworkers. Argh.

Since I’ve been working on Stackato, and immersed in data governance and ownership issues for the last several months, I duly responded with:

…the hospital is right: potentially confidential patient/research information does not belong on servers within the reach of the USA Patriot Act, where it can be accessed by authorities without notification to the data owner(s). The hospital IT department should set up a self-hosted solution.

When I posted the link, I noticed that one of the solutions listed was a name I had seen before at cloud computing conferences. ownCloud is “a flexible, open source file sync and share solution” – essentially a Dropbox you can run yourself. The software, and the company behind it, aim to address the same data privacy issues at the application level that Stackato does at the platform level. If you have concerns about data security and ownership, or are legally mandated to keep your data private and secure, you should not farm it out to a third party in the cloud.

This looked like a perfect match to me, so I thought I’d try running ownCloud on Stackato.

It was incredibly easy to do. In fact, we had it in the App Store within a few hours, and it makes a perfect “how to” on getting a PHP application running on Stackato and making it available the Stackato App Store.

Running ownCloud on Stackato

Right now, you can install ownCloud on a Stackato VM or on our Sandbox with a couple of clicks, but we’ll start from scratch so we can see how it all works together.

Assuming you already have access to a Stackato PaaS or VM, we’ll start with getting the ownCloud code. I started with the latest stable release available on the ownCloud Install page.

Using Stackato, you can skip a lot of these instructions. In fact, you could just do a ‘stackato push …’ from the top directory of the extracted files, answer the prompts, and it would (sort of) work. However, it would end up using an SQLite database and filesystem which is local to the application instance and ephemeral.

We don’t want that. We want something that will scale, so let’s “Stackato-ize” it.

Setting up the MySQL data service

Stackato can provide a MySQL (or Postgres, or MongoDB, or Redis) database service for any application you push. We need to give the application access to the credentials for that database. You’ll find a file called config.sample.php in the config directory which shows the options you can set. After a bit of searching in the ownCloud mailing lists, I discovered you can use an autoconfig.php instead to set these options in a “headless” install.

Borrowing bits of code from the WordPress and Drupal samples, I came up with something like this:

  <?php
  $services = getenv("VCAP_SERVICES");
  $services_json = json_decode($services,true);
  $mysql_config = $services_json["mysql-5.1"][0]["credentials"];

  $AUTOCONFIG = array(
  "installed" => false,
  "adminlogin" => "admin",
  "adminpass" => "changeme",
  "directory" => "/app/app/data",
  "dbtype" => "mysql",
  "dbname" => $mysql_config["name"],
  "dbuser" => $mysql_config["user"],
  "dbpass" => $mysql_config["password"],
  "dbhost" => $mysql_config["hostname"],
  "dbtableprefix" => "oc_"
  );
  ?>

We parse the VCAP_SERVICES environment variable (a JSON object) for the credentials we need to set up and use the database. The database service will be created when we push the app, and VCAP_SERVICES will be available to the application when it runs. For the moment, I’ve hard-coded the admin username and password.

The “directory” option specifies where all of the user files will be stored. We need to set this up to use Stackato’s persistent filesystem so that multiple application instances all store the files in the same place.

Sharing a file system

Let’s look at the other important config file for this app: stackato.yml. We could set up the services interactively during ‘stackato push …’ but this config file makes the process repeatable. It’s also the only place we can set an important “pre-running” hook:

name: owncloud
framework:
  type: php
  runtime: php
mem: 128M
services:
  owncloud-mysql: mysql
  owncloud-fs: filesystem
/
hooks:
  pre-running:
    - ln -s $STACKATO_FILESYSTEM data

Here we specify the default application name, the framework and runtime, the amount of memory (for each instance), and two services.

In the “hooks” section, we specify commands that will be run before the application is launched. In this case, we’re linking the mount point of the filesystem service to a directory in the application tree called ‘data’. The full path of this link is ‘/app/app/data’ which is what we specified in autoconfig.php earlier.

With these two files, you can push ownCloud to Stackato and scale up the number of application instances as needed. By default, the filesystem service limits each service to only 100MB and you’ll want much more to properly run ownCloud with lots of users. A Stackato administrator (in the micro cloud case, you) can change this default in ~/stackato/etc/vcap/filesystem_gateway.yml.

To the App Store!

That might be all you need, but bear with me, there’s a way we can set up Stackato to install ownCloud with a couple of clicks from the Management Console.

The Stackato App Store pulls applications from a public Git repository and deploys them to Stackato using options specified in a JSON descriptor for the application (similar to the stackato.yml file). The App Store uses the same API as the client for deploying applications, but as there’s very little interaction (usually just one click to install, another to start). This is covered in more detail in Ingy’s App Store post from last week, and in the stackato-app-store documentation. The “Third Party Apps” store file is a good example of the store JSON format and shows a number of applications, including ownCloud.

Bonus points

The autoconfig.php I used for the App Store copy is not quite what I’ve show above. I hate hard-coding usernames and passwords for the initial admin account, but there’s often no other way when you’re pushing a pre-configured app from the app store. I thought for ownCloud I could at least take the Stackato system user name or group name in the same way that database credentials are harvested from VCAP_SERVICES. Please excuse my rudimentary PHP. There are probably more elegant ways to do this:

<?php
$services = getenv("VCAP_SERVICES");
$appinfo = getenv("VCAP_APPLICATION");
$services_json = json_decode($services,true);
$appinfo_json = json_decode($appinfo,true);
$mysql_config = $services_json["mysql-5.1"][0]["credentials"];
if (array_key_exists("users", $appinfo_json))
  $admin = $appinfo_json["users"][0];
else
  $admin = $appinfo_json["group"];

$AUTOCONFIG = array(
"installed" => false,
"adminlogin" => $admin,
"adminpass" => "changeme",
...

Though the password is still hard-coded to “changeme”, at least the username is unique to the person or group deploying the application. If you’re more paranoid, you could re-use the $mysql_config["password"] string for "adminpass".

This might fall into the category of “Stupid Stackato Tricks” but you might find ways to use different environment variables (which can be set in stackato.yml) elsewhere in your application.

Building a Stackato App Store ecosystem

The current ownCloud sample in the App Store is pulled from a Github repo which just contains a copy of the 3.0.2 stable release, but since the store can use a specific branch and commit for the pull, it could instead be pulled from a “stackato’ branch of the canonical ownCloud repo itself.

Doing it this way allows web application authors and maintainers to easily expose a current, stable version of their app to the Stackato App Store. If you’d like us to feature your app in Stackato, send us the details!

<!–

–>

Don’t get me wrong, I love Dropbox. They offer free storage, handy cross-platform sync clients, give out nice t-shirts at conferences, and have delivered a much needed service with a great user experience.

But a little while ago a friend of mine posted a plea to her Facebook feed which went something like this:

OK techie friends – Apparently I can’t have Dropbox installed on my work computer [at a hospital in Canada] because of security concerns that the data are stored on US servers. How are the rest of you dealing with this? Is there other similar software out there without this problem? I need a way to access files from multiple computers, and to share some files easily with coworkers. Argh.

Since I’ve been working on Stackato, and immersed in data governance and ownership issues for the last several months, I duly responded with:

…the hospital is right: potentially confidential patient/research information does not belong on servers within the reach of the USA Patriot Act, where it can be accessed by authorities without notification to the data owner(s). The hospital IT department should set up a self-hosted solution.

When I posted the link, I noticed that one of the solutions listed was a name I had seen before at cloud computing conferences. ownCloud is “a flexible, open source file sync and share solution” – essentially a Dropbox you can run yourself. The software, and the company behind it, aim to address the same data privacy issues at the application level that Stackato does at the platform level. If you have concerns about data security and ownership, or are legally mandated to keep your data private and secure, you should not farm it out to a third party in the cloud.

This looked like a perfect match to me, so I thought I’d try running ownCloud on Stackato.

It was incredibly easy to do. In fact, we had it in the App Store within a few hours, and it makes a perfect “how to” on getting a PHP application running on Stackato and making it available the Stackato App Store.

Running ownCloud on Stackato

Right now, you can install ownCloud on a Stackato VM or on our Sandbox with a couple of clicks, but we’ll start from scratch so we can see how it all works together.

Assuming you already have access to a Stackato PaaS or VM, we’ll start with getting the ownCloud code. I started with the latest stable release available on the ownCloud Install page.

Using Stackato, you can skip a lot of these instructions. In fact, you could just do a ‘stackato push …’ from the top directory of the extracted files, answer the prompts, and it would (sort of) work. However, it would end up using an SQLite database and filesystem which is local to the application instance and ephemeral.

We don’t want that. We want something that will scale, so let’s “Stackato-ize” it.

Setting up the MySQL data service

Stackato can provide a MySQL (or Postgres, or MongoDB, or Redis) database service for any application you push. We need to give the application access to the credentials for that database. You’ll find a file called config.sample.php in the config directory which shows the options you can set. After a bit of searching in the ownCloud mailing lists, I discovered you can use an autoconfig.php instead to set these options in a “headless” install.

Borrowing bits of code from the WordPress and Drupal samples, I came up with something like this:

  <?php
  $services = getenv("VCAP_SERVICES");
  $services_json = json_decode($services,true);
  $mysql_config = $services_json["mysql-5.1"][0]["credentials"];

  $AUTOCONFIG = array(
  "installed" => false,
  "adminlogin" => "admin",
  "adminpass" => "changeme",
  "directory" => "/app/app/data",
  "dbtype" => "mysql",
  "dbname" => $mysql_config["name"],
  "dbuser" => $mysql_config["user"],
  "dbpass" => $mysql_config["password"],
  "dbhost" => $mysql_config["hostname"],
  "dbtableprefix" => "oc_"
  );
  ?>

We parse the VCAP_SERVICES environment variable (a JSON object) for the credentials we need to set up and use the database. The database service will be created when we push the app, and VCAP_SERVICES will be available to the application when it runs. For the moment, I’ve hard-coded the admin username and password.

The “directory” option specifies where all of the user files will be stored. We need to set this up to use Stackato’s persistent filesystem so that multiple application instances all store the files in the same place.

Sharing a file system

Let’s look at the other important config file for this app: stackato.yml. We could set up the services interactively during ‘stackato push …’ but this config file makes the process repeatable. It’s also the only place we can set an important “pre-running” hook:

name: owncloud
framework:
  type: php
  runtime: php
mem: 128M
services:
  owncloud-mysql: mysql
  owncloud-fs: filesystem
/
hooks:
  pre-running:
    - ln -s $STACKATO_FILESYSTEM data

Here we specify the default application name, the framework and runtime, the amount of memory (for each instance), and two services.

In the “hooks” section, we specify commands that will be run before the application is launched. In this case, we’re linking the mount point of the filesystem service to a directory in the application tree called ‘data’. The full path of this link is ‘/app/app/data’ which is what we specified in autoconfig.php earlier.

With these two files, you can push ownCloud to Stackato and scale up the number of application instances as needed. By default, the filesystem service limits each service to only 100MB and you’ll want much more to properly run ownCloud with lots of users. A Stackato administrator (in the micro cloud case, you) can change this default in ~/stackato/etc/vcap/filesystem_gateway.yml.

To the App Store!

That might be all you need, but bear with me, there’s a way we can set up Stackato to install ownCloud with a couple of clicks from the Management Console.

The Stackato App Store pulls applications from a public Git repository and deploys them to Stackato using options specified in a JSON descriptor for the application (similar to the stackato.yml file). The App Store uses the same API as the client for deploying applications, but as there’s very little interaction (usually just one click to install, another to start). This is covered in more detail in Ingy’s App Store post from last week, and in the stackato-app-store documentation. The “Third Party Apps” store file is a good example of the store JSON format and shows a number of applications, including ownCloud.

Bonus points

The autoconfig.php I used for the App Store copy is not quite what I’ve show above. I hate hard-coding usernames and passwords for the initial admin account, but there’s often no other way when you’re pushing a pre-configured app from the app store. I thought for ownCloud I could at least take the Stackato system user name or group name in the same way that database credentials are harvested from VCAP_SERVICES. Please excuse my rudimentary PHP. There are probably more elegant ways to do this:

<?php
$services = getenv("VCAP_SERVICES");
$appinfo = getenv("VCAP_APPLICATION");
$services_json = json_decode($services,true);
$appinfo_json = json_decode($appinfo,true);
$mysql_config = $services_json["mysql-5.1"][0]["credentials"];
if (array_key_exists("users", $appinfo_json))
  $admin = $appinfo_json["users"][0];
else
  $admin = $appinfo_json["group"];

$AUTOCONFIG = array(
"installed" => false,
"adminlogin" => $admin,
"adminpass" => "changeme",
...

Though the password is still hard-coded to “changeme”, at least the username is unique to the person or group deploying the application. If you’re more paranoid, you could re-use the $mysql_config["password"] string for "adminpass".

This might fall into the category of “Stupid Stackato Tricks” but you might find ways to use different environment variables (which can be set in stackato.yml) elsewhere in your application.

Building a Stackato App Store ecosystem

The current ownCloud sample in the App Store is pulled from a Github repo which just contains a copy of the 3.0.2 stable release, but since the store can use a specific branch and commit for the pull, it could instead be pulled from a “stackato’ branch of the canonical ownCloud repo itself.

Doing it this way allows web application authors and maintainers to easily expose a current, stable version of their app to the Stackato App Store. If you’d like us to feature your app in Stackato, send us the details!

<!–

–>

We get asked occasionally about Stackato support for .NET. It’s clearly an important enterprise application platform today, but there are some technical challenges to supporting it on a Linux-based PaaS system.

Stackato, like the Cloud Foundry code base it’s built upon, has a modular design that can be extended to provide application hosting on any operating system – including Windows.

Tier 3′s Iron Foundry project does just that by providing a Windows-based DEA (Droplet Execution Agent) that works with Stackato.

Stackato & Iron Foundry Micro VM combo

The Iron Foundry and Stackato development teams have been working together to ensure smooth integration of our VMs. To add .NET support to a Stackato instance, you need to run a separate Iron Foundry Micro Cloud which handles .NET application hosting (the Iron Foundry DEA) and provides a MS-SQL database service. You can run the VMs side-by-side on the same hypervisor host, or host them separately. You just need to make sure they can see each other (e.g. by running in bridged mode). With the two VMs connected as per the setup instructions, you’re ready to push applications that use the .NET framework.

Get the VMs

To try this pairing out for yourself, you’ll need to download VMs to run on your local hypervisor:

• Stackato VM
• Iron Foundry VM

The Stackato forums and Iron Foundry Forums are there for you if you have any questions. Let us know what you think!

<!–

–>

One thing about Java applications is that you need to generate byte code
to execute it, and every Java developer knows that you should never commit
your byte code to source control because of the size (for pet-clinic, 500KB of sources become 40MB of compiled jars/wars). For this reason, with Stackato demo applications we generally recommend that Java developers do the extra step of compiling the bytecode before deployment.

With the preliminary support of Heroku Buildpacks in Stackato 1.2,
there’s now a way to make compilation happen as part of the app deployment.

So let’s explain both methods of deploying Java to Stackato.

Building it locally

The first way is to build the application before pushing to Stackato. This
method has been available all along in Stackato when using the ‘java_web’ and
‘spring’ frameworks:

1. Install Maven on your local system if you don’t have it

2. Build the application

   mvn clean package

3. Push it to Stackato

   stackato push -n

That’s all.

However, if your application uses a database like pet-clinic does, and if there are maven tests on this database, you will need to set up a local database to pass these tests. You could use the ‘-Dmaven.test.skip‘ argument to skip tests, but this is not recommended.

maven clean package -Dmaven.test.skip=true

It would be nice to run these tests against the actual database we’ll be using. We can do that using the ‘buildpack’ framework.

Using a Java Buildpack

Heroku Buildpack support is new in Stackato 1.2. Heroku introduced this system as a way for users to add custom frameworks to their PaaS. Stackato has other ways of customizing the application environment, but buildpacks have become popular, so we decided to emulate them in the Stackato environment.

In the case of our demo Java application, the Java buildpack allows the application bytecode to be built on Stackato instead of on your local machine. The Java buildpack also includes OpenJDK if you want to run a simple java application.

For the pet-clinic application for example, we need a Java-based server to run the application. To do that, we will use Jetty. Jetty is a light Java application server. It includes a Jetty Runner. The good thing about Jetty is that you can run your Java web application with a simple command just by providing the war file:

java -jar jetty-runner.jar application.war

Advantages of using the buildpack framework?

• You don’t need Maven on your local machine
• The application builds on the PaaS instead of on your machine
• You don’t have to push all the byte code
• You don’t need to set up a special environment for tests.

How does it work with Stackato?

It is really easy! You only need to modify three files.

First, in ‘stackato.yml’ you will need to define the framework type and to
provide the buildpack url. Here is the pet-clinic stackato.yml:

name: pet-clinic
mem: 512M
framework:
    type: buildpack
env:
    BUILDPACK_URL: https://github.com/heroku/heroku-buildpack-java.git
services:
    mysql-spring: mysql

As it is a buildpack application, you also need to create a Procfile in
which you declare how you want your application to be executed. Here is the one
from pet-clinic.

web:    java $JAVA_OPTS -jar target/dependency/jetty-runner.jar --port $PORT target/*.war

And finally, add the jetty dependency in your pom.xml
in order to run your application.

<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.3</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals><goal>copy</goal></goals>
                    <configuration>
                        <artifactItems>
                            <artifactItem>
                                <groupId>org.mortbay.jetty</groupId>
                                <artifactId>jetty-runner</artifactId>
                                <version>7.5.4.v20111024</version>
                                <destFileName>jetty-runner.jar</destFileName>
                            </artifactItem>
                        </artifactItems>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

And that’s it! Target your Stackato server/cluster with the client, login, and push your application.

So there you have it – more ways to get your applications working in Stackato. You choose the one that fits your development style.

<!–

–>

Release of new, more powerful Stackato Private PaaS Solution Coincides with HP Cloud Services Public Beta

I’m pleased to announce that ActiveState and HP Cloud Services have formed an extended partnership, ensuring support for Stackato 1.2 running on HP Cloud Services. Stackato is the application platform for creating a private Platform-as-a-Service (PaaS), and its industry-leading cloud application security, data privacy, and control are now available on the HP Cloud Services infrastructure.

This announcement coincides with the upcoming HP Cloud Services move to public beta. It follows on the heels of the successful launch of Stackato version 1.2, a major upgrade that delivers several new features, including persistent file system services (and associated Drupal compatibility), enhanced app store functionality, integrated debugging support with Komodo IDE, Heroku build-pack support, and configurable user/group permissions and quotas.

HP Cloud Services (HPCS) is based on HP’s world class hardware and software, with key elements of HP Converged Infrastructure combined with a developer-friendly integration of OpenStack™ technology. Available soon in public beta, HPCS offerings include HP Cloud Compute, HP Cloud Object Storage, and the HP Cloud Content Delivery Network.

With this integration, developers and enterprises can quickly and seamlessly create a private PaaS in HP Cloud Services without having to download a virtual machine.

Stackato 1.2 on HPCS infrastructure provides a secure middleware layer to complement HPCS’ unique hybrid delivery solution for private, managed, and public cloud deployments. Stackato’s support for HP Cloud Services gives enterprise developers more options and flexibility when choosing their cloud infrastructure services, while offering all the benefits of a private PaaS to deploy, scale, and manage applications.

“ActiveState enjoys a mutually-beneficial partnership with HPCS,” says Bart Copeland, ActiveState CEO. “Stackato’s support for HP Cloud Services reinforces our vision of delivering ‘cloud control’ to support any underlying infrastructure, benefitting enterprise developers and IT/DevOps with the flexibility and deployment options they demand.”

<!–

–>

Platform-as-a-Service is the future for deploying and managing Internet applications. It promises to provide an environment that abstracts the hard stuff (operating system, web server, programming language environment, databases, etc) and leaves you with the joy of just saying “Run this app, please”. With ActiveState’s Stackato, not only can you do that, but you own the entire PaaS system, and you run it wherever you wish.

How easy is it to install a complete Stackato PaaS? Very. It’s just a download and a few clicks. How about deploying popular applications like Drupal or Bugzilla to your new Stackato PaaS? Even simpler. The Stackato App Store makes them a click away. What if you want to install your favorite apps that are not yet in the store? No problem. You can create your own App Store and it’s amazingly easy to do.

In this article, I(ngy döt Net) will teach you how to do all three of the simple and exciting exercises above. Let’s get started…

Installing Stackato

Stackato can be installed as an enterprise cluster of 1000+ nodes running on Amazon EC2, vSphere, or OpenStack, but it will also run as a single virtual machine (VM) on your laptop. Since deploying Stackato as a single node (we call it Micro Cloud licensing) is completely free of charge (forever), let’s do the the latter.

The first thing you’ll need to do is download a copy of the Stackato VM. This free download is available here. In a nutshell, Stackato is just a VM image that is ready to boot up as a server. It is packed full of all the system software needed to get your apps running immediately. Stackato VM images are prepared for a bunch of different virtualization hypervisors. Since you are on a laptop, you’ll probably want to use VMware Fusion/Player or VirtualBox, which have free versions. Download the Stackato image that matches your hypervisor software.

Note: The Stackato image is 1.2GB, so now is a good time to get a cup of
coffee (or a good night’s sleep), depending on your bandwidth.

Pro Tip: Start the download now, and hopefully it will be done by the
time you finish reading this.

After you unzip the Stackato download, you’ll want to get the image into your hypervisor. For VMware you can just “open” and “play” the .vmx file. For VirtualBox, you’ll need to “import” and “start” the .ovf file (and also adjust the Network Settings). In either case, you should see a Linux VM booting up in a window. Your Stackato is coming to life…

When the Stackato VM has booted, you will see a URL to a unique local domain. Just type that URL into a web browser. This is where the real fun begins. The (now running) Stackato serves up a web based Stackato Management Console (SMC), which you can use to do most of the common Stackato operations (and all the operations discussed here). For instance you can install apps, stop and start and launch them, view their logs, see pretty system graphs, and many many other things that I encourage you to explore on your own.

The first thing the SMC wants you to do is enter your email address and a password. Your email will be your Stackato id. You are now the administrator of this Stackato. That means you have full control of everything. The password you’ve entered, is also now the password of the stackato Unix user, should you want to ssh into the actual Stackato VM. This is a real live server, it’s yours, and you have the keys to the castle, if you want to dive deep. But let’s get back to the fun stuff!

Note: The above process will work on a laptop that is running Mac, Linux or Windows, but with some caveats. For instance, you’ll need sufficient RAM, 64-bit capabilites and some network tweaks on Windows. If you have any problems, see the rich Stackato documentation.

The Stackato App Store

If you look at the left side of your SMC, you’ll see a link to the App Store. Click it! You’ll be presented with a cornucopia of applications written in many programming languages. If you wanted to run all these by setting up your own server, it would likely take you days. With the Stackato app store, it’s just a few clicks.

Try it. Click “Install” on an interesting app. You’ll be prompted with some basic setup info. Usually the defaults are just fine, so click the “Install App” button. In a few seconds your app will be installed. You should now see your “Applications” page. From here you can start your app. Once it is fully started, you’ll see a launch button. This will take you to your brand new running app. Viola!

So what is the App Store exactly? It’s not a store in the sense that you have to buy anything. The App Store is simply a collection of links to software that is ready to run on Stackato. Currently these applications are all hosted as GitHub repositories. In fact, the link to “More Information” on each App Store app, points to the GitHub page for that app. Click it to read the app’s documentation and instructions. If you are a developer, you can clone the repo, change the source code, and push it to your Stackato VM using the Stackato command line interface.

You can think of the Stackato App Store as the rabbit hole to a PaaS wonderland. The folks at ActiveState are adding new apps to the App Store every day. You may just end up using Stackato to host your favorite off-the-shelf apps, but Stackato strives to be the deployment platform of choice for application developers.

Creating Your Own App Store

I’m not certain that I’ve conveyed just how ridiculously simple a Stackato App Store is. I said was a collection of links, but let’s take a closer look.

If you click on “Settings” in the SMC, you’ll see a set of tabs. Click on the Stores tab. You should see a list of URLs hosted by ActiveState. The URLs are links to JSON files. For instance, look at this one. If you understand JSON (which is about as simple as it gets) it’s pretty easy to see what’s going on. These JSON files just contain meta-data about application sources. The App Store fetches this JSON info and presents it to you in a graphical and interactive manner.

With Stackato 1.2, you can change the JSON sources to whatever URLs you want, as long as they return the proper content. In other words, all you need to do is host a static JSON file, and tell the SMC about it. We call this the “App Store 2.0″ and it’s a great example of how open ActiveState is making the entire Stackato platorm.

There are many ways to host static files, but here is a really simple and free way to test it out. Go to the link above, and copy the JSON text, then go to https://gist.github.com and paste it into the text box. Make a small change to the JSON text (possibly change an app desc value) and then click the “Create Public Gist” button. Next, find the “raw” link on the page and click that. Now you’ll have a hosted static raw JSON file on the Internet! Copy the URL to the SMC’s Setting’s list of App Store URLs. That’s everything. If you go into the App Store now, you’ll see your own App Store data.

Conclusion

I started by asserting that PaaS is the future of computer application deployment. Stackato is polishing that future at every level. I hope this gives you a glimpse of the future, and that you try it out today.

<!–

–>

Deploy Drupal where you want

Stackato lets you run Drupal, the popular content management system, on public clouds such as AWS and Rackspace, or on private clouds powered by VMWare, CloudStack or OpenStack. With Stackato, you choose the cloud hosting provider that best fits your organization’s requirements.
 With one ‘stackato push’ command or one click in the Management console, you can make Drupal available on any Stackato PaaS deployment.

Here at ActiveState, we’ve been huge fans of Drupal for years. Both the ActiveState corporate and community sites are powered by Drupal, so it was only natural for us to want to get it working nicely on Stackato.

Scaling Drupal in the Cloud isn't trivial

With Al Jazeera, Time Inc, Turner, World Economic Forum, Stanford University, New York Senate, and NPR all running their extensive web properties on Drupal, we know that Drupal can scale. It’s not easy though – not because Drupal can’t scale, but because replicating multiple instances of Drupal and its software stack in the cloud takes a fair amount of skill and requires a way to share user-contributed files between those instances.

Cloud application instances in Stackato—and in most other PaaS solutions—are ephemeral, and the storage on those instances is ephemeral as well. If the instance is shut down, the data on it goes away. That’s not a very desirable configuration if you are deploying an application such as Drupal that expects (and requires) a persistent file system.

To solve this problem, Stackato offers a file system service that can be shared between application instances. Just like the data and messaging services, this service can be created using the ‘stackato create-service’ command or specified in a YAML config file to automatically set up the service for an application.

You can link this file system to Drupal’s ‘sites/default’ directory, and even specify multiple file system services to share themes and modules between multiple Drupal sites.

Deploying Drupal: Insanely simple with Stackato

Stackato automates deploying, managing, and scaling a Drupal application-appropriate stack and makes it insanely simple to deploy Drupal on your private cloud:
1.    Download the Stackato VM, request access to the AMI, or sign up for the Sandbox.
2.    Go to Github and get ActiveState’s ready-to-run Drupal branch, which is ready to run.
3.    Target Stackato and enter 'stackato push -n' from the ‘drupal’ directory.

Deploying from the App Store is even easier!

Drupal is now featured in the Stackato App Store

Just launch Stackato's Management Console, navigate to the App Store, browse to the Drupal item  and click ‘Install’. You can even import data from existing Drupal deployments using Stackato’s ‘tunnel’ and ‘ssh’ commands.

Why Drupal on a Private PaaS? Manage & Scale multiple web properties with ease

Today’s real-world enterprise maintains more than just a single web property. Stackato enables corporate IT to easily manage and distribute multiple Drupal-powered sites across an enterprise to produce a consistent experience, while centralizing the administration, security, and control of key IT activities.

Stackato can scale Drupal when your organization needs access to elastic capacity to meet traffic surges. An enterprise can easily manage the secure deployment of multiple Drupal instances while securely encapsulating each web property.

Content can be managed locally while web site deployments are coordinated centrally. By deploying a private PaaS, an enterprise can rapidly develop a consistent web experience, easily redistribute it to various web properties, and continue to manage and evolve the underlying IT infrastructure.

For a quick overview of Stackato and a walk-thru deploying Drupal, watch this YouTube video.

Test drive Drupal today on a Stackato Micro Cloud, with on Amazon EC2 or on our Private Stackato Sandbox Service today!
 

<!–

–>

It’s getting harder and harder to give short Stackato demos. We’ve been adding so many cool features that it’s hard to cover everything. With the release of 1.0.6, we needed an updated demo screencast to show off the Management Console and the App Store, but that leaves less time for explaining the core workflow.

So, with this demo I gloss over some things that are covered in previous screencasts. To get the full picture, feel free to supplement the information in the new screencast with some of the previous material:

• Stackato Demo – Micro Cloud to Private PaaS: This is the first screencast we made for a beta version of Stackato. It goes into a lot more detail on the initial setup of the VM and the client, so if you get stuck setting up your own Stackato micro cloud, have a look at this one.
• Komodo IDE and Stackato: Yes, there’s integration with Komodo too! This video shows how to push applications from Komodo IDE and use its Database Explorer to view and modify the automatically provisioned database services.
• Stackato on HP Cloud Services: Though this demo was made to show Stackato running on HPCS, it also deals with a very important part of Stackato’s security model – the use Linux containers (LXC) for isolating the hosted applications. This allows Stackato to offer SSH access into the user’s application containers for running remote commands.

You may get sick of hearing me say “Hi, my name is Troy Topnik” but hopfully there’s enough information here to get you started setting up your own Stackato VM, or taking it for a spin in our developer sandbox. There’s are active forums on the Community site if you run into any difficulties and the #stackato IRC channel on freenode. Come join the discussion.

<!–

–>

Deploying and configuring your own single instance private PaaS on EC2 with Stackato is almost as easy as downloading a micro cloud virtual machine (VM) to your desktop. The ActiveState team has created an Amazon Machine Image (AMI) with Stackato installed that is ready to run on EC2, with a few minor configuration tweaks that even a Newbie to the cloud can figure out. The Stackato AMI is available for free subject to the terms and conditions of the Stackato Micro Cloud License Agreement.

How simple is it?

To get Stackato up and running on EC2, all you need to do is launch an EC2 AMI, configure an IP address and domain name, SSH into the instance, perform a few simple stackato-admin commands, and then launch the Stackato Web Management Console to complete your setup and configuration. Download the Stackato Client and you’ll be able to push your applications directly to the cloud from your desktop.

Getting Access

Before you can get started, you must first have valid AWS credentials so that you can use Amazon’s web services. You can either sign up for a new AWS account or use your existing AWS credentials. If you’re creating a new Amazon account, you will need to provide a credit card to complete the sign-up process. At the end of each month, Amazon will charge your credit card for the cloud-related usage costs associated with your AWS account.

You’ll also need to send an email request to the ActiveState Stackato Support team with your AWS Account Number (shown in the upper-right corner of the AWS “Manage Your Account” page).

Once you have received your email confirmation from ActiveState that you’ve been granted access – you can spin up your own private PaaS on a small EC2 instance in a few quick steps.

1. Launch an AWS Instance of Stackato




2. Associate your Domain Name with your Stackato Instance’s Elastic IP Address




3. Log in to your Stackato Instance with SSH/PuTTY




4. Adding your domain to /etc/hosts




5. Use the “stackato-admin” Command Basics




6. Sign in to the Stackato Web Management Console

Step 1: Launch an AWS Instance of Stackato

The AWS Management Console provides a web interface for Amazon Web Services. You can start and stop EC2 instances, view and perform actions on running instances, set configurations (e.g. security groups, key pairs, and Elastic IPs) and modify them using interactive controls.

Log in using your AWS account name and password. Navigate to the “Amazon EC2 Console Dashboard” and click on the “Launch Instance”. This will launch the “Request Instances Wizard” for you.

From your AWS console, search the Amazon “Private Images” catalog for the latest Stackato AMI using the string “stackato“. Select the Stackato AMI ID.

Choose the Instance Type “(m1.small, 1.7 GB)”. This is the least expensive option and a good one for testing purposes. For a production environment, you will need to deploy a cluster of instances and assign different roles to each of them to spread the workload more efficiently. The Stackato AMI is currently only available for use in the “us-east-1a” EC2 Availability Zone, so select that zone at this point.

Click on “Continue” and accept all the defaults on the Advanced Instance Options for now.

Next, give your AMI a user-friendly name or “key”. This makes it easy to identify later if you deploy more than one instance.

There is a default password for the Stackato AMI. You will be prompted to change it when you launch the Stackato Web Management Console for the first time. Click “Continue” on the “Create Key Pair” page and go directly to “Configure Firewall” to set up a Security Group.

Using the “Create a new rule” drop-down list, select each of the following rules: SSH, HTTP, HTTPS and DNS. This security configuration will allow you to securely shell into your instance using SSH/PuTTY and configure your instance so that it can be accessed using a domain name of your choice.

Review your choices and hit “Launch”. Be patient as it may take a few minutes for Amazon to fulfill your request. When the instance is available it will appear in your AWS Console as a “running instance” with the name you chose earlier.

You have a live Stackato Instance. Now you just have to make it “yours” by mappng your domain name to the instance.

Step 2: Associate your Domain Name with your Stackato Instance’s Elastic IP Address

The Public DNS and your Private IP Address assigned automatically by AWS are ephemeral. They do not persist when an instance is restarted.

To map a DNS entry to Stackato, you need a persistent IP address. Amazon EC2 provides Elastic IP addresses, which do persist through reboots. Any Elastic IP addresses that you associate with your account remain associated with your account until you explicitly release them.

To allocate a new Elastic IP address for use with your PaaS

1. Click Elastic IPs in the Navigation pane. The console displays a list of Elastic IP addresses assigned to your account.
2. Click Allocate New Address.
3. In the confirmation dialog box, ensure the value for EIP used in is set to EC2, and click Yes, Allocate.

To associate the Elastic IP address with an instance

1. Click Instances in the Navigation pane. The console displays a list of instances.
2. Write down the instance ID to associate with the Elastic IP address.
3. Click Elastic IPs in the Navigation pane. The console displays a list of Elastic IP addresses assigned to your account.
4. Select an address and click Associate Address.
5. In the Associate Address dialog box, select the instance from the Instance list box and click Yes, Associate.

For this example, I registered the domain “gorilla-mgmt.com” through Dreamhost.com, so I use Dreamhost’s domain management console to make the DNS changes to point to the AWS instance. In this example, I am using a subdomain called “paas” to associate with the Stackato PaaS running on the AWS instance.

Type in your “AWS Elastic IP” in to the “Value” field of the CNAME Record. You’ll need to add add a “.” at the end and then save your changes. Depending on your domain hosting provider, it may take awhile for this change to take effect.

Step 3: Log in to your Stackato Instance with SSH/PuTTY

You need to tell Stackato about your instance’s “Private IP address” and your chosen domain name.

Log in to your machine via ssh as user “stackato” with default password “stackato”. Note: Do not change the unix user password in this step – it will happen in a later step.

While Secure Shell or “ssh” may sound daunting, it really is just a secure way to log into a remote computer as an authenticated user. If you’re using Linux or Mac OS X, use the ‘ssh’ client that comes with the OS, if you’re using Windows get a copy of PuTTY.

Launch PuTTY from your desktop and type in your AWS Public DNS address in the Host field, then click “Open”.

Click the “Open” button and you’ll be prompted to login to your instance for the first time.

This first time, you’ll login as the user “stackato” using the default password which is also “stackato”. Do not change the password yet, this will be done in a later step.

Step 4: Adding your domain to /etc/hosts

You’ll need to add a line in the ‘/etc/hosts’ file to resolve the domain name added above to localhost via the 127.0.0.1 loopback address.

To make these edits, you’ll need to use a console text editor like “Vim”, which is already installed on your EC2 instance (if you don’t know how to use it, here’s a useful cheatsheet).

To edit the /etc/hosts files, you’ll have to run vim with the “sudo” command – which allows you to run programs and commands with the security privileges of another user (in this case, the superuser, or root):

$ sudo vim /etc/hosts

You’ll need to add one line to the top of the /etc/hosts file, substituting your domain name for the one used in this example.

127.0.0.1 localhost stackato paas.gorilla-mgmt.com api api.paas.gorilla-mgmt.com

When you save the file, you may get an error message such as the following: “unable to resolve host stackato-xxxx”. This message can be ignored.

When you are finished editing your /etc/hosts file should look something like this:

Step 5: Becoming Stackato: the “stackato-admin” command basics

While still logged in with PuTTY to your instance, you’ll need to type in the final configuration using a few stackato-admin commands and then reboot your instance.

The email address used in this step should be the same as for the user who will become the first admin user of the system in Step 6.

The “private instance IP” is the one noted as Private IP Address for your EC2 instance.

From the command line, type in the following stackato-admin commands substituting your domain information :

$ stackato-admin admin grant admin1@gorilla-mgmt.com
$ stackato-admin become all -m 10.110.201.176 -e api.paas.gorilla-mgmt.com -h paas --domain paas.gorilla-mgmt.com

Now reboot so all the changes take effect.

$ sudo reboot

When you do the “reboot” from PuTTY, your session will automatically end and disconnect.

Step 6: Sign in to the Stackato Web Management Console

Direct your browser to https://api.<Fully Qualified Domain Name>/. In this example, you would go to https://api.paas.gorilla-mgmt.com.

This will take you to the initial console setup welcome page. Use the same email address here that was granted admin permission in the previous step. The password that you provide here will also become the stackato system password, replacing the default password that you used to do your first login.

After that, you are ready to deploy apps to Stackato, your own single instance personal Private Paas on EC2!

To learn more about deploying applications to Stackato and navigating the Stackato Web Management console, watch this short YouTube video.

Thinking about setting-up a cluster for to scale for production use? Be sure to contact our sales team to learn how Stackato Enterprise can help your business.

<!–

–>

With this move, Citrix has elevated CloudStack's "open-sourciness," but hasn't changed CloudStack's fundamental operating model: Citrix will continue to offer a commercial CloudStack infrastructure solution, but it will now be built upon a much-more-widely supported open-source framework. The Apache relationship gives CloudStack instant newfound clout with developers, and promises new potential for customers of all shapes and sizes developing cloud services.

At ActiveState, we've long recognized the power of open source to drive innovation within the enterprise. Stackato, the application platform for creating a private PaaS, is based on the open-source Cloud Foundry framework. Stackato already provides full support for the CloudStack infrastructure platform, and today's announcement represents a validation—of open source, of CloudStack, and of Stackato's enterprise-ready model. The CloudStack/Apache marriage offers great opportunities for a broader community of developers and partners to build commercial-grade extensions upon CloudStack. And that can deliver on the promise of enterprise cloud success.

"CloudStack's evolution means greater visibility, flexibility, innovation, and opportunity," says ActiveState CEO Bart Copeland. "It provides greater visibility for both CloudStack and ActiveState's Stackato, more choices for customers, and opportunities for development innovation. I look forward to seeing the exciting ways CloudStack will be extended in the future."

"Stackato's private-PaaS middleware solution complements CloudStack," notes Sheng Liang, CTO of the Citrix Cloud Platforms Group. "And with its open-source heritage, ActiveState bridges two leading open cloud communities—open source Cloudstack at an infrastructure layer, and the open source Cloud Foundry at the PaaS layer."

Since its introduction in 2011, ActiveState's Stackato has supported Citrix Xen and XenServer infrastructure, and by extension, CloudStack. Being part of the market-leading Apache development community will raise CloudStack's visibility, and can only help drive cloud-computing adoption. When Stackato is paired with CloudStack, enterprise customers can deploy an open source-based private cloud with the assurance of enterprise technical support from both Citrix and ActiveState, and the full collaborative support of the Apache open source community. And that's an enterprise model that benefits from the best of both the open source and commercial development worlds.

<!–

–>