Preparing the application

Your application must have a class with a main method that the Java runtime will execute to startup the ActorSystem. We used Akka Microkernel, which provides this main class, but you can easily write your own main class or use akka.Main.

The binaries—classes, dependencies, configuration, start scripts—of the application should be packed in an archive file to be transferred to GCE. We used the Akka sbt plugin (dist) and a few command lines to create this archive:

We started other instances without external IP address, which means that ssh must be done via n0001.

Deploy the application with a persistent disk

In the large cluster tests we placed the application binaries on a persistent disk that was shared among the instances. This worked fine, but is inconvenient when trying out different changes, because a persistent disk can only be attached in write mode to one instance, and meanwhile it cannot be attached to other instances. Therefore we recommend to store the application binaries in Cloud Storage instead, which will be explained later. Anyway, it is a good exercise to understand how to use persistent disks.

To start the application we used bash scripts defining JVM parameters and main class. We used a slightly different script for the seed nodes, but if you only need to run one ActorSystem per instance that should not be necessary.

Note that the host name (e.g. n0017) assigned when starting the instance should be used in the akka.remote.netty.tcp.hostname and akka.cluster.seed-nodes configuration settings. From a start script the host name can be retrieved with $(hostname).

This start script is executed when the instance is booted by passing in a startup script when creating the instance. The startup scripts looks like this:

Note how it mounts the persistent disk and in the end call the start script for the application. This startup script is specified when creating the instance with the metadata_from_file=startup-script argument.

Deploy the application using cloud storage

The approach with the persistent disk is inconvenient when trying out different changes, because a persistent disk can only be attached in write mode to one instance, and meanwhile it cannot be attached to other instances. Therefore we recommend using following approach to store the application binaries in Cloud Storage instead.

For this you need to install another command line tool, called gsutil.

If you start the instances without external IP address it cannot access Cloud Storage. This problem is solved by installing a Squid proxy on one of the instances and use that proxy from the other instances as explained in the documentation.

Conclusion

It is not hard to see that Google Compute Engine is developed by top notch devops engineers.

The command line tools, gcutil and gsutil, are excellent for automating the startup and operation of a cluster with ordinary scripts. The excellent documentation makes it easy to understand how to use the tools. Running Akka on Google Compute Engine is a breeze. Try it out!

Have a Question?

From the blog

The Typesafe crew is thrilled to share that Scala Days SF was just fantastic. A big thanks to all who attended. We were wowed by our awesome keynoters, speakers and volunteer staff, and it was great to feel the excitement and energy at the beautiful Fort Mason.

After an inspiring Scala Days (the next one is in Amsterdam), it's great to be able to shine some light on technologies dedicated to improving the workday of Scala developers. We recently talked about eight hot technologies that perhaps you didn’t know were built in Scala, and in the spirit of that we’re happy to highlight Takipi, a company that's making life for commercial Scala apps better. Branching out from Java, Takipi now helps Scala developers understand when and why their code breaks in production. For more details, we asked Josh Dreyfuss, who recently joined the Takipi team, to take us through it all. -Oliver White, Typesafe, Inc.