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
Just a simple ZIP file with the following contents
- 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
Deployment
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
This is an optional file which contains ‘deployment’ specific information required by the service. It includes information such as no. of instances or nodes, required memory per instance, custom environment variables (key-value pairs), external service (other cloud services) binding information. Such a pre-defined can be useful while using the REST API where you just point to it instead of specifying all the individual deployment metadata in your REST HTTP request
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
Cheers !
