The Oracle Application Container Cloud service is relatively simple to be honest. Here is quick post on how a potential application looks like. Although the service supports Java SE and Node.js runtimes, this post will stick to Java specific examples. Let’s take it from the bottom up…
Packaging the ‘final’ deployable artefact
- The JAR file: this is the runnable Java ‘application’ itself
- The manifest.json file: this is another mandatory artefact which contains information on the startup command (e.g. java -jar myapp.jar) as well as other metadata like java version, release details etc.
How does the JAR look like ?
Nothing extraordinary about this. Just bear in mind that your dependent libraries (if any) need to be packaged with your application. This can be done via
- Good old class path: Place your dependent libraries and specify them using java -cp or set them as CLASSPATH environment variable
- Create a Fat JAR: the dependent libraries are pushed into the JAR itself (thereby making it ‘fat’). There are more than ways of achieving this (e.g Maven shade plugin)
In either case, your JAR file needs the manifest.mf file to include the main (bootstrap) class information for the JVM
You can choose from either of two options to deploy your application (ZIP archive) [Details are not dealt with]
- GUI: use the dedicated administrative console for the App Container Cloud service
- Or leverage the REST API
deployment.json – to make things a little easier
Please note that…
- Each node or instance is nothing but a Docker container and that’s where your application will reside and execute within (i.e. the JVM service will be running inside the Docker container)
- Since the applications are dynamically deployed to Docker container, the application deployer/developer is not in control of the port and hostname properties. These are automatically made available to you by the service in the form of (implicit) environment variables – HOSTNAME, PORT. You can read these within you Java logic