Docker, Oracle Images and Cloud

Overview

Oracle is embracing Docker – just like many other companies – as the de-facto standard in Container technologies. It has resulted in the certification of various Oracle products for running in Docker containers and even Oracle supported Docker images are available. Furthermore, Oracle offers 2 Cloud Service around containers: the Container Cloud Service is a generic service that offers a platform for running your containers. Next to that, Oracle offers the Application Container Cloud Service that is targeted to running Java SE, Node.JS, php and python applications. The Application Container Cloud Service is left out-of-scope.

This blog series shows how to get started with WebLogic and Docker – in 3 different Clouds:

• Docker and the Oracle Images
• Create and run a WebLogic Docker Image on a local machine and upload the WebLogic Docker Image into the Docker Hub registry
• WebLogic Docker Container on Oracle Container Cloud Service
• WebLogic Docker Container on Microsoft Azure Container Service
• WebLogic Docker Container on Amazon EC2 Container Service

All cases describe the minimal steps to get a WebLogic container up and running: nothing fancy, very minimalistic, just to get you going.

The approach for the Cloud use cases is similar for all 3 Cloud providers:

• get your container platform up and running (the ‘Container Service’ in the cloud)
• start a WebLogic container from the image that we have first put on Docker Hub

Some findings of the work done can be found at the bottom of this article.

Docker Overview

Even though this article is not intended as a Docker tutorial, below an overview of Docker concepts and terminology. That should be enough to get you moving if you’re new to this whole Docker containers thingies.

Docker container

A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. A Docker container addresses the ‘runs-on-my-machine’ problem: it is a complete package that runs on any machine. In doing so, it also simplifies your CI/CD solution.

Docker container vs virtualization

The biggest difference between Docker containers and virtualization solutions like Oracle VM is that a Docker container does not have a guest OS on board:

The above diagram is best described as ‘where Virtualization offer OS isolation, Docker containers offer process isolation’. That does imply that Virtualization offers better security: the ‘isolution’ is at a lower level in the stack, thus making it less vulnerable.

Docker terminology

Docker made the diagram below, which illustrates the moving parts in a Docker setup:

• Registry: a store for container Images
• Repository: a set of different Docker Images with the same name and a different tag
• Image: a package that defines a Container. It includes everything needed to run a container, including code, a runtime, environment variables, etc
• Container: a running instance of an Image
• Host: a machine running Containers
• Daemon: process on the Host that manages the containers
• Client: client for exchanges commands with the Daemon
• Service: a group of containers that run from the same image
• Swarm: a group of Docker hosts that run as a cluster. The Swarm consists of a number of Nodes and the Docker commands are handled by the Swarm Manager.
• Stack: a group of Services that together are an application

Docker and management

A large scale Docker set-up needs proper management tooling. Popular candidates are:

• Docker Swarm
• Apache Mesos
• DC/OS
• Google Kubernetes

In a cloud set-up, that choice is limited to what the cloud provider has pre-selected for you – the Microsoft Azure approach. Or, the offered Cloud interface may even hide from you the details about what management tooling is implemented: Oracle Container Cloud Service and Amazon EC2 Container Service.

Of course, it is possible to only use the IAAS services from your Cloud provider and build up the whole Cloud Container platform yourself, similar to as if it were in your data center. For this blog series, that is out-of-scope.

Docker in real life

Before heading of quickly to your boss and promise that Docker containers will solve all of his application ‘packaging/deployment/CI/CD’ problems, please read this section. My interpretation: using Docker in a real-life situation is more complicated than it seems at first glance.

Environment

An application in a Docker container is rarely a completely isolated, stand-alone application. Normally, the application has configuration parameters that provide information on the environment that the application is running in. For example, host names, port numbers, DB urls, web service endpoints, user account names, etc. This environment specific information can be passed on to the container using environment variables. Both command-line and file-based entry is possible.

State

Docker containers by nature are stateless: a container starts, does its work for some time, and is then stopped. After the container is stopped, all of its internal state is gone. Obviously, that limits the practical usability of containers very much. The limitations are addressed by ‘data volumes’. A ‘data volume’ enables the container to access a defined part of the file system of the host machine. That enables containers to persist data and also share data between containers. Best practice here is to also use separate, dedicated Data Volume Containers that share the data with other containers

Networking

Spinning up many containers also means that your networking has to be handled adequately: all traffic must be routed to the right container. The topic of Docker container networking is far beyond the scope of this blog. Please refer to the official documentation to get a first understanding: https://docs.docker.com/engine/userguide/networking/.

Security

You still have to do that yourself: Docker only delivers on ‘process isolation’.

Availability

Existing applications may have a high availability / clustering mechanism that doesn’t agree well with containers. For example, an active-passive set-up will not mix with scaling up through many containers. So, if you want to wrap your existing application into containers, you will have to consider this aspect.

Application architecture

Existing applications may not fit nicely into a container. Separation of state and environment data from application logic may prove to be difficult. When development of a new application is started, it is easier to take this into account up front.

Docker and Operating Systems

Containers rely on OS system calls. Therefore, mixing OS for host and container will not work. So,

• Linux host + Linux container = OK
• Windows host + windows container = OK

However, it is possible to run a Linux container on windows. That solution is based on using the MobyLinuxVM on windows, and running a Linux container on top of that Linux VM.

Furthermore, Kubernetes is working on a completely mixed Windows/Linux environment (https://www.mirantis.com/blog/linux-windows-living-together-total-chaos-ok-kubernetes-1-5/).

Also note that the Windows containers implementation is currently (may 2017). E.g. Amazon claims (http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_Windows.html) that they still ‘consider it a beta that should not be used for production environments’. So, if you want to go into that direction, you should first investigate what the current status is!

For the time being, just beware that mixing OS-es of host and container may be complex if not impossible. In the future, this I expect this all to be solved.

To further confuse things: windows containers can be found with 2 isolation modes:

• Windows Server Containers: share the Windows kernel between containers
• Hyper-V Containers: runs each container in a thin VM, thus offering additional isolation (security)

Findings

I don’t intend to give a full-blown comparison of the different Cloud Container solutions that I worked with. But what I found remarkable:

• Making a custom Docker image for WebLogic is easy
• All Cloud solutions were easily accessible
• Using Docker containers for running your current applications may be difficult: your application may not ‘fit into a container’ (is containerizable a word?). For new applications, it is definitely worthwhile to consider the requirement ‘has to fit in a container’
• The Microsoft approach to containers is different from Oracle and Amazon. Microsoft offers the choice between some popular container management solutions, whereas Oracle and Amazon have built their own solution
• The Oracle solution was the only solution where I didn’t have to use a command-line console to get things up-and-running. I think that Oracle has found a good abstraction level for their UI, where all the container concepts like container, image, registry, service, task, etc are available in an intuitive way
• The Amazon solution seems to me to be somewhere in between the Oracle and Microsoft approach. They have abstracted a couple of concepts like cluster, task and service into their UI, but a bit more advanced stuff has to be done using command-line on the EC2 agent machines.
• For development purposes, by application developers with relatively little knowledge of infrastructure stuff, I would recommend looking at the Oracle Container Cloud Service. Mainly because of the clear UI.
• For production purposes, I don’t have an opinion by now. The Microsoft solution has pro’s and con’s. The fact that it uses existing container management software gives you more work (bad) but also more flexibility (good) and if you run into issues, you may find more ‘google-based-support’ (good). I expect the that the Amazon solution will require some scripting and command-line stuff – which may sound bad, but which may also offer flexibility and fit well with the skills of the system administrators that will have to manage the cloud platform. The Oracle solution seems to strike a good balance between platform configurability and ‘easy-to-use’ UI. That seems to best fulfill the Cloud promise of ‘all-you-need-is-a-credit-card-and-a-browser’.
• Note that these findings cover 3 Cloud container offerings. It is not intended to be a complete overview of what is happening in the Docker container eco system. Other platform solutions, like for example Red Hat OpenShift, should also be taken into account when selecting a Docker container platform.
• …. I welcome any of your considerations as a reply to this blog – please look for the reply box somewhere below 😉