The world likes cloud, cloud, cloud. One of key challenges with cloud is setting up a consistent, reproducible environment that scales to thousands/millions of instances. If there’s even a slight variation in the environment where the instances/apps/services are running then that will reflect on maintenance cost: trouble shooting is more complex because you cannot trust/rely on the environment being the same etc.
Docker image for Oracle Server JRE is now available on Docker Store
Many competing technologies have over the years been developed to address this. Some technologies are making it easier to script OS installation and/or maintain a consistent environment (Puppet is an example of this). Hardware virtualization allows for setting up VMs which provide a (relatively) well defined, and well isolated environment for applications to run in. However, VMs are relatively heavy-weight.
Along came Docker. Docker is actually a few different things, but a couple of the key things people associate with Docker are:
By leveraging and combining all these pieces Docker is providing a well-defined, isolated and manageable “containers” which effectively provide the same general benefits that hardware VMs do, but without the overhead. Specifically, the containers will all be running on/sharing the same Linux kernel instance, which means that they can share a lot of the resources which would otherwise have to be duplicated.
A Docker image is the packaging format from which actual Docker container instances are created. The image includes the application to run, (some part of) the configuration for that application, but also *the dependencies* the application has. For example, a Docker image for a web service would contain the actual web service code, but also any frameworks/libraries it depends on, the Java runtime (JRE), as well as any user space libraries needed for the application.
Remember those thousands/millions of instances mentioned? If you take anything, and multiply it/scale it up to millions of instances you’ll quickly find that streamlining and simplifying the base gets important. The fewer dependencies you have, the fewer things can go wrong. The smaller the base image, the less space it will take up - both the static footprint on disk, but also the dynamic footprint in memory.
A full-fledged/generic Linux distribution typically provides support for all kinds of target applications and use-cases. But what if you know exactly what it is you’re going to run, and don’t need all of that flexibility?
Alpine Linux’s slogan says this:
"Small. Simple. Secure. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.”
We learn from this that Alpine uses a small C library called “musl." This is different from most other Linux distributions, which typically tend to use the GNU C library (aka. “glibc”). Now why would they do that? Let’s look at what the musl web page has to say:
"musl is lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety.”
So what about this busybox thing?
"BusyBox combines tiny versions of many common UNIX utilities into a single small executable.”
All right, so basically Alpine is taking the small C library and combines that with small versions of the Linux/UNIX utilities. That’s handy. Basically, it means that we can take our normal applications and if we run them on Alpine we’ll get all the benefits that come with it.
The JDK code base is very portable, supporting several different operating systems, CPU architectures, and compiler toolchains. However, the JDK source code has not yet been ported to Alpine Linux, or more specifically, the musl C library. That is, it turns out that the thing about Alpine Linux that sticks out/is different from a JDK source code perspective is the C library.
The goal of OpenJDK “Project Portola” is to provide a port of the JDK to Alpine Linux, and in-particular the "musl" C library. The “Call-for-Vote” for the project was sent out on February 22nd, and was approved two weeks later (March 9). The OpenJDK project infrastructure has new been set up, including the (mercurial) code repository/repositories, the mailing list, etc. and the work on getting the necessary code changes integrated will commence shortly.
Does the Oracle Support Team supports running Java SE on Docker Containers?
Yes. Oracle Java SE has been running on all manners of containerization platforms for many years. Oracle Support will assist customers using Docker or other container platforms.
Are there any licensing considerations for Oracle Java SE that are unique to Docker?
No. Docker is a containerization platform and there are no unique or special restrictions in the license for use or redistribution as compared to any operating system, virtualization or packaging format. The Oracle JDK is widely used and adopted in the Docker ecosystem.
Does Oracle provide recommendations for running Oracle Java SE on Docker?
Yes, material is provided on GitHub.
Does Java has any recent changes to support Docker?
Yes. Java 8 update 131 (released April 18th, 2017) includes a number of changes enabling better memory and processor integration between Java and Docker. By default in JDK 8 the thread and memory settings will come from the host OS, but in JDK 9 the JVM will be container-aware. In all cases, thread and memory limits can be explicitly controlled in the command line. More details on the enhancements can be found here:
To get started with the Oracle Server JRE image on Docker, please visit the Docker Store. After you've added it to your personal catalog, you can do:
$ docker pull store/oracle/serverjre