I was going to write a fairly straightforward post about Stackato's 'dbshell' command, demonstrating how you can use it to access the databases provisioned by Stackato. However, a few days ago Cloud Foundry blogged about Caldecott, demonstrating how to connect to database services on cloudfoundry.com, so the scope of this article has changed a bit.

We were eagerly awaiting news on Caldecott and were watching the Cloud Foundry vcap repo like hawks to see when it would land in the open source project. It turns out we were looking in the wrong place. All the magic is in the client, and I'm happy to report that Stackato is compatible with this new access method without requiring any server-side changes.

Stackato's 'dbshell'

Before I get into this new way of doing things, let's look at Stackato's 'dbshell' command.

To connect to one of your database services running on Stackato, you simply run 'stackato dbshell [appname]'. It opens a database port on the micro cloud or database service VM and returns either the connection credentials or automatically launches a local database client to connect with those credentials.

For example, I have a MySQL database connected to Spring application on my local micro cloud. To get the credentials:

This returns a JSON object with everything I need to connect using an external MySQL client, like the DB Explorer in Komodo IDE.

In fact, this is what Komodo 7 (Beta) does behind the scenes to automatically configure the database connection with "View Database in DB Explorer" in the Stackato interface:

If you want to connect directly with a command-line database client, you can do that too:

$ stackato dbshell ttspring
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 644
Server version: 5.1.41-3ubuntu12.10 (Ubuntu)
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
mysql> show tables;
+---------------------------------------------+
| Tables_in_d8f4cd7772c8e4b90af7bc216310a253d |
+---------------------------------------------+
| current_states |
+---------------------------------------------+
1 row in set (0.00 sec)
mysql>

This is great if you're working with the micro cloud, or if you are connected to a Stackato cluster where the database service VM allows external database connections. But if you are trying to connect to an installation which is more locked down, which doesn't allow you to route directly to the data service VM(s), you can't connect.

The Cloud Foundry team has covered this scenario in their implementation by using TCP over HTTP tunneling, so let's take a look at how they've done that.

Caldecott: VMC's tunnel

Instead of making changes in the VCAP codebase (the server-side parts of the system), Cloud Foundry has bundled a small Ruby Sinatra appplication in the vmc client which is automatically pushed to the targeted system when you run 'vmc tunnel'. The app, in conjunction with the client, creates a tunnel from the data service to the local machine using the Caldecott gem. You can see this app by running 'vmc apps' once the tunnel has been created, and you can even check out the code with 'vmc files' if you want to see how it works.

The good news for Stackato users is that this works just as well on a Stackato PaaS as it does on cloudfoundry.com, you just have to use the vmc client (vmc 0.3.14.beta.4) instead of the stackato client to take advantage of it.

Next steps for Stackato

Obviously, we don't expect Stackato users to keep switching back and forth between 'vmc' and 'stackato' to get their work done. Since we are maintaining API compatibility with Cloud Foundry, we'll be adding an equivalent 'stackato tunnel' command to emulate 'vmc tunnel'. We might implement it slightly differently (perhaps a lightweight Node.js application instead of Sinatra, perhaps offering HTTPS rather than just HTTP), but the goal is to ensure maximum portability and compatibility between Stackato or Cloud Foundry.

Subscribe to ActiveState Blogs by Email

Email Address: *

Thank you for signing up to receive an email notification when we have posted a new blog.

Note: To ensure proper delivery of our emails, take a moment now and add us
(marcom@activestate.com) to your trusted sender list or company white list.

Share this post:

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.