Application Container Cloud (ACCS) supports Java EE

This is my personal entry for the ODC appreciation day that was initiated once more by Tim Hall.

Intro

Oracle’s Application Container Cloud Service (ACCS) is a cloud native, container based runtime for applications and microservices implemented with Java, Node.js, Ruby, Python and PHP. It’s simplicity makes it most attractive. All you need to do is bundle and upload your code, and add a .json file to let ACCS know how to start your application.

Since a couple of days ACCS is now supporting Java EE as well – this is great news! Note, that there is still Java Cloud Service JCS, which gives you a fully fledged WebLogic domain. However, JCS is more complex to set up and to deploy to, so ACCS is a good option for those that only want to deploy and run a Java EE module.

ACCS with Java EE

The provisioning, as shown in the following screenshot, is PaaS-worthy, easy enough as with any other ACCS deployment type.

ACCS: Application Container Cloud Service with Java EE

 

ACCS with Java EE, Some Details

Here are some more facts as they are currently known:

  • You can simply upload a .war file. The .json manifest that is required to tell ACCS how to start a Java application is not mandatory for Java EE since the module is running in WebLogic.
  • The current versions used in ACCS when deploying a Java EE module are: WebLogic 12.2.1.2 (which supports Java EE 7), running on Java 8.
  • ACCS with Java EE currently does not support clustering.
  • ACCS does not let you access the WebLogic admin console. This is fine. It’s PaaS!
  • ACCS with Java EE can make use of Java Flight Recorder. In continuous mode, all profiling and event data is captured. If Java Flight Recorder is not in continuous more, then 60 seconds of data is captured. You can download the files and use Java Mission Control to analyze the recordings.
  • The URL syntax to invoke a deployed web module is as follows:

    https://<ACCSName>-<IDDomain>.apaas.<REGION>.oraclecloud.com/<DocRoot>

  • Typically the URL to call a deployed application is shown in the ACCS service console. Note, that the DocRoot -even if required to call the deployment – is not shown.
  • A Java EE deployment is running across 2 instances as default which requires a load balancer to be provisioned by ACCS. Currently OTD is used.
  • If you feel brave enough, just give it a go and deploy the sample app.
  • If you are lost working with ACCS by yourself, then follow this tutorial, explaining how to deploy a Java EE module to ACCS. The instruction mentioned in the tutorial worked OOTB for me.

Possible Improvements

As you know, I usually write about features and showstoppers. A few minor things that should be improved in my opinion:

  • A few minor details are not visible in the console. E.g. the used Java version is not fully displayed.
  • Not sure if it is documented somewhere, but I would love to read more precisely about current restrictions for Java EE in ACCS. Actually I dropped the hint for some colleagues at Oracle to blog about it.

Is it Java EE or EE4J now?

You may have heard that Java EE went to the Eclipse foundation. The new name will be EE4J. Do you have to change all your slide decks and articles? Actually no. For some more details have a look at this article.

Acknowledgement

Many thanks to the team of Abhishek and Sriram for helping to clarify some questions and providing quick and precise feedback!

Purge / Empty / Drain a Kafka Topic in Oracle Event Hub Service (or any other Kafka broker)

I did not find this solution myself, but I am also not sure where I discovered it. Just a note to myself.

Actually it is becomes useful once you enabled client access to your Oracle Event Hub Cloud Service, since the web based console itself does not implement every functionality that is provided by Kafka.

On another thought: what if the Event Hub Console implemented draining a topic in the web console? And maybe it could also display the number of messages stored in topic.

Access Oracle Event Hub Kafka from External Kafka Client or Tool

Access Oracle Event Hub from external Tool or Command-Line Client

Oracle Event Hub provides a managed Kafka PaaS solution. To access it from an on-premises client you have to make sure to enable the ports to Event Hub Zookeeper and the Kafka broker.

Access to Kafka Broker

First lets enable access to Kafka broker. To do so, check the OPC Event Hub service for the connect string.

Create Event Hub Broker Access Rule

Then create a new access rule. Warning: In general you should not allow public access to access your Event Hub service! This is just for demo purposes to make the tool work. In case of doubt create a rule with your own IP address and talk your friendly security officer first of all.

The creation of the rule might take a few seconds:

Create Zookeeper Access Rule

Once the rule for the Kafka broker is created, we need to create a rule for Zookeeper which is using port 2181:

Explore Kafka Tool (or other)

Now lets start our Kafka tool (for demonstration purpose) only, configure the connection details for the Zookeeper IP and port, and then try to connect to Oracle Event Hub Service:

Voila, it is working 🙂 You can explore your topics or even create new ones. Note that  Oracle Event Hub uses a special naming convention for topics.

Oracle Event Hub Cloud Service: What you need to know about Topic Names

There are a number of things related to topics in Oracle Event Hub service that everybody should be aware of:

  • Oracle Event Hub topics created with the web console are automatically prefixed with the OPC ID domain.
  • Event hub topics can be created via the Kafka command-line from any host (assuming you allow the clients to access Event Hub CS). These topics are not prefixed with the OPC ID domain.
  • Topics created with the CLI (without ID domain prefix) are not shown in the service console.

IMHO, this is behaviour is not very useful for various reasons:

  • If you are planning to use Event Hub as a drop in replacement for another Kafka installation you won’t be able to create the proper topic names for already existing topics with the service console.
  • You have to add the ID domain prefix in every client. This is particularly bad e.g. for a Java producer. Hard-coded ID domains will show up sooner or later in the source code.
  • Being forced to use the ID domain prefix in every client might turn out to be a security issue. Did you note that most bloggers blacken their ID domains in screenshots when writing about OPC?

 

Tips and Tricks for Oracle Container Cloud Service (OCCS)

Some days ago I posted a longer getting started with OCCS webcast which should serve as a good introduction if you are new to OCCS. Also I posted about using OCCS with Grafana on Docker for network latency measurements.

In this article I will provide a number of tips and tricks I discovered while exploring  OCCS.

Keep in mind that OCCS is the newest addition in the Oracle Cloud portfolio. Everything I tried was stable so far. Note that this article – like all my other articles actually – reflect my opinion . Maybe some of the items below will help you to get your containers running easier!

This list is not complete yet and I will extend it as I discover new things around OCCS. Drop me a comment below if there is anything you want to be added here. I am curious about your own experiences.

OCCS Tips and Tricks

  • Do you have trouble logging into Oracle Cloud? I recommend to have a look at my other posting and check here.
  • The provisioning of the service (i.e. the underlying machine) seems to depend on the instance size. Small instances are provisioned in the range of several minutes. However in the Europe 2 data center I waited between 2h and 3h until the service was provisioned on a OC3 instance. Let me know if your experience is different e.g. the provisioning is faster in the US.
  • Starting up a container is much quicker than provisioning the underlying service.
  • The container console itself is surprisingly well hidden. It had to look into the tutorial to find it :-(. You can find it here:
  • If you want to start an OCCS container with a docker image that is started with a -d flag from the command-line, don’t worry. OCCS runs all containers as daemons, so you don’t have to provide this flag.
  • If something went wrong and you look for log output of your container, then check under
    Container / Name / View Logs.
  • Sometimes you will experience that containers are “flapping”. This means they are started but run into an error. Then they are started again, etc. Check the logs to find out what is happening and stop the container.– this posting will be continued once I discover more tips and tricks for OCCS.
  • If you run the classic example

    the container will be restarted once it is finished, so technically it will be flapping. It is quite likely that OCCS will support a flag in the future to run special containers only once. Note that this is not the typical enterprise use case anyway but more more a first step of what devops try on the command-line.
  • You can use SSH to connect to the OCCS manager nodes, however you cannot connect to the worker nodes as of now. The manager node is running a very restricted VM environment with some essential tools like vi, cat, rm, cp etc. only. To connect to the master node use the private key that was generated when you set up the service and the following syntax:
  • It would obviously be interesting if OCCS would offer services out of the box for the Oracle supported Docker images from https://github.com/oracle/docker-images.
  • The Container Console is using a self signed root certificate and therefore creating a browser warning. This is nothing severe but Oracle should document a way to install your own X.509 certs to avoid the warning.
  • From 10,000 feet OCCS might look vaguely similar to Kubernetes, but OCCS is not based on Kubernetes. Actually Kubernetes is more complex to set up and to operate. OCCS’ goal is “to provide an easy and powerful way for enterprises to run their containers on our service”.

At the end, your goal should be to be able to run your own Docker image on OCCS. Give it a try!