Running Spring-Boot Microservices on Oracle Container Cloud

Spring-Boot in Oracle Container Cloud Service

After looking into how to run a Spring-Boot based Microservice application on Oracle’s Application Container Cloud service, this post will concentrate on Oracle Container Cloud Service. In short, Oracle Container Cloud Service is Oracle’s enterprise-grade container infrastructure solution. It provides features to compose, deploy, orchestrate and manage Docker container-based applications. In contrast to Oracle Application Container Cloud Service customers can completely control containers deployed within this infrastructure. Therefore, this service provides the highest amount of flexibility for container-based applications. On the other hand, it does not relieve customers of tasks like Oracle Application Container Cloud Service.

Within this post, we are going to deploy a Spring-Boot application implementing the architecture presented in the figure below. It uses Eureka as service registry. Microservice 2 uses a Feign Client implementation to call Microservice 1. To run all three services on Oracle Container Cloud Service, they were packaged as FAT-JARs, added to Docker Containers and uploaded to Docker Hub. If you require more details on this process, feel free to ask further questions within the comments section below or on twitter.

Application Architecture


Oracle Container Cloud Service Stacks

Although each Microservice provides a complete business functionality within its bounded context, one most likely needs a combination of multiple Microservices in order to provide a complete application for a specific business domain. As container orchestration solution, Oracle Container Cloud Service provides features to run multiple Microservices in an ordered fashion. This feature is called Stacks. In general, a Stack is a configuration describing which and how a set of Microservices shall be executed by the underlying infrastructure. Instead of creating a proprietary solution, Oracle decided to use Docker’s Docker Compose tooling as basis for its container orchestration and added a simple visual editor. In order to create a new Stack one has to select the Stacks menu item. Within the overview one can see all existing Stacks, including Oracle’s Stack examples. On the top right corner click the New Stack button.

Stacks Overview


Within stack editor view all available service definitions are displayed on the right side. Each of these services can be added to the Stack by dragging it from the list to the stack editor on the left. Afterwards each service can be extended with stack specific configuration.

Stack Editor


Alternatively, one can open Advanced Editor to provide a YAML-based Docker Compose configuration. In the case one already has a running Docker Compose configuration file it can just be pasted into the editor. If validation is passed, it is saved as Stack. Afterwards Oracle Container Cloud Service automatically creates all services described within the configuration.

Advanced Stack Editor


Back on the stack editor added services can be examined. By hovering over each service its configuration is displayed. In order to amend a service one has to access the service configuration dialogue by clicking on the cogwheel symbol. Within the upcoming editor dialogue most service characteristics can be changed. Available options are well known from Docker command line and work as expected. Like stack editor, service editor provides an advanced mode to develop and use a custom YAML Docker Run configuration. Additionally, Oracle Container Cloud Service provides a feature to add a Health Check Service to each service configuration. Within the configuration, a health check endpoint for the application running within the Docker container can be provided. By adding an endpoint platform capabilities to monitor running containers is extended.

Service Editor


Demystifying YAML Stack Configuration

Within our example, we used the following docker-compose.yml for our Spring-Boot based Microservice Stack:

version: 2
    image: 'cwiesbaum/doag-service-registry:latest'
      - '8761:8761/tcp'

  image: 'cwiesbaum/doag-person-data-service:latest'
    - '8080:8080/tcp'
    - >-
      EUREKA_REGISTRY=http://{{hostip_for_interface .HostIPs
  hostname: '{{hostip_for_interface .HostIPs "eth0"}}'

  image: 'cwiesbaum/doag-person-activity-log-service:latest'
    - '8081:8081/tcp'
    - >-
      EUREKA_REGISTRY=http://{{hostip_for_interface .HostIPs
  hostname: '{{hostip_for_interface .HostIPs "eth0"}}'

As one can see all three service definitions are based on container images residing in my public Docker Hub Repository. On deployment Oracle Container Cloud Service pulls all images from the docker repository and runs them on its docker infrastructure. It is not restricted to images from the official Docker Hub Registry, any Docker registry can be added under the Registries menu item. If required, login credentials can be added.

In addition to specifying source images, each service can be configured using docker-compose.yml syntax. As one can see within the example, port mappings were specified for each service. Furthermore, configuration was added to person-data-srv and person-activity-log-srv using environment variables. The environment variable EUREKA_REGISTRY is accessed within service implementations to register with the service-registry service. As our Stack is running within a dynamic cloud infrastructure, one does not know on which host services will be executed. Therefore, hostname and IP have to be retrieved on start up. For this purpose, Oracle Container Cloud Service provides a templating mechanism. Before executing a configuration, it is searched for instructions in double curly brackets. In our configuration above {{hostip_for_interface .HostIPs „eth0“}} was used as template instruction. It consists of three parts:

  • hostip_for_interface – Operation extracting a specific IP out of a IP address list
  • .HostIPs – Predefined variable containing all host IP addresses
  • “eth0” – Interface name to extract from IP address list

A full description of all functions and predefined variables can be found within the service documentation.

Finally, the same template instruction was used to set container hostnames for each service. If not specified otherwise, Docker Compose uses the first few characters of a container’s hash value as hostname. Unfortunately, this can lead to problems when trying to implement inter service communication.

Using this configuration it is possible to successfully deploy our Spring-Boot based Microservice Stack.

Deployed Stack



Within this blog post we presented Oracle Container Cloud Service, Oracle’s solution for enterprise-grade container infrastructure. In general, it provides powerful features to compose, deploy, orchestrate and manage Docker container-based applications. Within our example, we could deploy a Spring-Boot based microservice application as Stack into Oracle Container Cloud Service. Stacks are basically Docker Compose configurations and a well know tool for customers familiar with Docker. Overall, Oracle Container Cloud Service provides a flexible and user friendly container orchestration infrastructure on which modern Microservice applications can be operated.


Oracle Container Cloud Service documentation –

Oracle Container Cloud Service Stacks –

Template Functions and Arguments –

Template Functions and Arguments Reference –

Docker Compose –