GraalVM integration

If you simply want to run the native image locally, you can use the following command:

This will take 5 or more minutes. Among the output you should see the result of the native image build, for example:

The resulting Docker image is cloudstate-proxy-dev-mode:latest.

This image is a dev mode image, it uses an in memory store, and forms a single cluster by itself. You can also run dockerBuildNoStore and dockerBuildInMemory, dockerBuildCassandra to build a production proxy that has no store, an in memory store or Cassandra store respectively. These will attempt the Kubernetes cluster bootstrap process, so can only be used in Kubernetes with appropriate environment variables set to help them discover other pods in the same deployment.

Substituting publishLocal for publish will push the docker images to a remote Docker registry, to enable this the -Ddocker.registry and -Ddocker.username flags must be specified to the sbt command.

The docker image can be run by running docker run cloudstate-proxy-dev-mode. However, by itself this won’t be useful because the container won’t be able to locate the user function from its container. If running the user function locally and your platform is Linux, then this can be enabled simply by passing the --network=host flag to use the hosts network namespace.

For all other platforms, the simplest way is to run the user function in a docker container, and share the network namespaces between the two containers. The js-shopping-cart sample app docker image can be built by running npm run dockerbuild from the samples/js-shopping-cart directory. Now, to start the images, this should be done in separate windows, or replace -it with -d to detach:

Initially, the Cloudstate container may show errors as it attempts to connect to the shopping-cart user function before it’s started. Once running, you can connect to the proxy on port 9000.

If you wish to build a Native Image outside of a container, eg because you’re using OSX, and you want better performance (since OSX runs Docker in a VM) or you want to run the image locally, then you can follow the following instructions.

Switch to GraalVM 19.2.1 as your current JRE, and add its binaries (in /bin) to $PATH. You MUST do this otherwise you’ll get weird warnings since the GraalVM Substitution mechanism won’t work.

Your java -version should report something like:

Install native-image using gu.

Verify that you’ve added GraalVM correctly by checking that native-image is available as a command.

Download and install clang. Ensure your system is using clang as its c compiler, such as with alternatives on linux. sudo update-alternatives --install /usr/bin/cc cc /usr/bin/clang 100

Switch to GraalVM 19.1.1 as your current JRE, and add its binaries (in /bin) to $PATH. You MUST do this otherwise you’ll get weird warnings since the GraalVM Substitution mechanism won’t work.

Your java -version should report something like:

Also, verify that you’ve added GraalVM correctly by checking that native-image is available as a command.

Then either start creating the binary with the in-memory storage:

or the Cassandra-client based storage binary:

The executable generated is located here: ../cloudstate/proxy/core/target/graalvm-native-image/cloudstate-proxy-core

The binary will have to dynamically link to a SunEC provider, and needs to source it either from the present working dir, or via the java.library.path, this is achieved by passing in the following property when executing the binary: -Djava.library.path=<path-to-JRE>/lib

Example: -Djava.library.path=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/lib

Supplying the runtime configuration, for the simplest experience, you can give it the pre-packaged dev-mode.conf, example: -Dconfig.resource=dev-mode.conf

Full example of running the in-memory storage executable:

Or with the Cassandra client storage: