Getting CloudTools to Work with Grails 1.1.1

Dietrich Kappe, Tuesday, December 22, 2009 @ 4:46 pm

photo credit: °Florian

Yes, Cloud Foundry has been acquired by Spring Source and seems to be morphing into a for-pay service, and there hasn't been a new build packaged on the Cloud Tools project page since January of 2009, but if you dig in the SVN repo, you see there's a bit of activity. Before I try building from source, I wanted to see how hard it would be to get 0.6 Grails plugin working with a Grails 1.1.1 app.

Well, harder than I thought. There's a real lack of documentation around cloudtools for one, and the radio silence on the project page over the last few months hasn't helped. Fortunately, Don over at AlterThought has put together a nice post that covers most of the pitfalls and problems with the CloudTools Grails Plugin. A few things they don't address and I thought I'd throw in here:

1. The CloudTools scripts expect the plugin to be located in the Grails project directory.

That isn't the case anymore. The plugins have moved to ~/.grails/1.1.1/projects/<your-project-name>/plugins/. The one script that barfs on this is ~/.grails/1.1.1/projects/<your-project-name>/plugins/cloud-tools-0.6/scripts/CloudToolsDeploy.groovy which tries to determine the plugin dir through a process that just won't work anymore. Edit the file and replace all the pluginHome cruft with a single line:

pluginHome = "${cloudToolsPluginDir}"
 

That's it.

2. The CloudTools deployment ignores your production configuration and just deploys development.

If your development data source is configured to create-drop, you'll be very disappointed that your database is constantly getting nuked. So, ignore the production environment and just use development! (This will need to be fixed, of course.)

3. When deploying, you need to have a local db running with the same login info/credentials as your production.

What a huge pain. I only discovered this after shutting down my local development mysql instance. Not so good for automated build and deploy. Again, needs to be fixed.

4. Using EBS is pretty dead simple.

Using EBS to persist mysql tables is rather trivial. Just tack on a withNewEbsVolume method call the first time through, then a withExistingEbsVolume, some the first time:

clusterSpec = new ClusterSpec()
                .tomcats(1)
                .topology("SingleInstanceTopology")
                .instanceType(EC2InstanceType.SMALL)
                .slaves(0)
                .withNewEbsVolume(20, "/dev/sdq")
 

CloudTools will create a volume, format it and mount it, populate the db tables to it. Next you find the volume id with something like ElasticFox and edit your config file to look like this:

clusterSpec = new ClusterSpec()
                .tomcats(1)
                .topology("SingleInstanceTopology")
                .instanceType(EC2InstanceType.SMALL)
                .slaves(0)
                .withExistingEbsVolume("vol-1234", "/dev/sdq")
 

Obviously replace vol-1234 with your actual volume id.

OK, that's it. With this configuration, I'm able to get a Grails app up in a matter of minutes with a persistent mysql db.

Next time: building from source.

Related posts:

1. Making Vaadin, PureMVC and Grails Work Together
2. Grails and Google App Engine: Birthing Pains
3. Grails and JSONP: How Easy is That?
4. Ruby on Rails with Windows – How I made it work
5. Grails: Delegating to GORM Persistence in Java

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment