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!

Oracle Storage Service: Geo Replication – you must set this!

Configuring the Oracle Storage replication policy should be step number zero if you start in the Oracle cloud with any service. I cannot stress this often enough. Many services such as DB as a service or Java Cloud service will not work without it. Even ACCS – a much newer and higher level PaaS service – will not work unless you set this storage policy.

  • For now: go and set the policy. I got into all kind of trouble trying without. Trust me, you won’t have the time for this.
  • To make cloud services such as JCS or ACCS work it is not so much important how you set the replication policy, it it just important that you set it. Functionally of course, there is a big difference if you data will be replicated asynchronously to another data center or not.
  • IMHO this could be improved by Oracle to improve the overall OPC customer experience. There is no reason why there could not be a default value, that makes other PaaS services work correctly.

Oracle Cloud: Set Storage Replication Policy

From the official Documentation

Guidelines for Selecting a Replication Policy
Read these guidelines before selecting a replication policy.

Oracle provides several replication policies. Broadly, they belong to one of the following types:

  • Policies that have no georeplication: These policies specify only the primary data center (DC) that hosts your service instance.All read and write requests go to the primary DC, always. If the primary DC is unavailable, then the requests fail. Such a policy may be adequate if you have standard data-durability requirements and if an occasional failure of read requests (when the primary DC is down) is acceptable.
  • Georeplication policies: These policies specify a primary DC that hosts your service instance as well as a geographically distant, georeplication DC.Write requests that you send to the global namespace URL are routed to the primary DC. Data that you write is replicated automatically, but asynchronously, to the georeplication DC. The primary and secondary DCs are eventually consistent. If the primary DC is unavailable, then write requests fail with the 403 — Forbidden error, but read requests are routed to the georeplication DC. When the primary DC is available again, requests to the global namespace URL are routed to the primary DC. You’ll be billed for the sum of the capacities used in both DCs and for the data transfer from the primary to the georeplication DC. A policy that has a georeplication DC is ideal if you have advanced durability requirements for your data or if read requests must succeed always regardless of the state of the primary DC.

For faster data transfer between your other Oracle Cloud services and Oracle Storage Cloud Service, consider selecting a policy with a primary DC that hosts your other services that use Oracle Storage Cloud Service the most. When selecting the replication policy for your service instance, keep in mind any security, legal, and regulatory requirements that may apply to your data.

DNS Lookup and Ping Times Measurement with Grafana on Oracle Container Cloud Service

Welcome back to a new posting about the Oracle Container Cloud service(OCCS). In my previous OCCS blog posting I went through some details of the brand new OCCS.

In the following webcast I try to measure some key characteristics like DNS lookup and ping times for major industry websites such as cloud.oracle.com, google.com and munzandmore.com. All the measurements are done from probes running in various capitals throughout the world. The important thing to understand is that we not measuring times from the Oracle Cloud to somewhere.

The results actually show that cloud.oracle.com is on a par with google.com and both obviously beat my own domain which is not a big surprise.

Grafana is visualizing the results of these probes. It is running in a Docker container which is running on Oracle Container Cloud Service (OCCS) – the newest addition to the Oracle Cloud.

Enjoy the webcast. Let me know if you have some interesting findings about measurements with Grafana and the worldping plugin or the Oracle Container Cloud service! For sure I will post more about it later.

 

 

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
    docker run hello-world

    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:
    ssh -i privateKey opc@PUBLIC_IP
  • 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!