Monthly Archives: February 2017

Getting Started with Oracle Container Cloud Service

February 8, 2017containers, couchbasecloud, containers, oraclearungupta

Oracle Container Cloud Service is Oracle’s entry into the the world of managed container service. There are plenty of existing options:

Docker for AWS or Azure
Amazon Elastic Container Service
Google Container Engine
Azure Container Service
DC/OS by Mesosphere
OpenShift by Red Hat

This blog will explain how to get started with Oracle Container Cloud Service. A comparison of different managed services is started at Managed Container Service.

Before we jump into all the details, let’s try to clarify a couple of things about this offering from Oracle.

First, a bit about the name. “Oracle Cloud Container Service” seems more natural and intuitive since its a Container Service in Oracle Cloud. Wonder why is it called “Oracle Container Cloud Service”? Is it because “Oracle Container” is Oracle’s container orchestration framework and its a Cloud Service? Could that mean other orchestration frameworks be offered as a service as well?

Second, don’t confuse it with Oracle Application Container Cloud Service that allows to build cloud-native 12-factor applications using polyglot platform. Now, that confuses me further. Can the Container Service not be used to build 12-factor apps? Are cloud-native and containers mutually exclusive?

Anyway, this is causing more confusion than clarification Let’s move on!

One last thing before we dig in. Many thanks to Bruno Borges (@brunoborges) for pushing the buttons for cloud service activation. I don’t know the normal time for the free trial to be activated otherwise. And a much bigger thank to Mike Raab (@mikeraab) for helping me understand the details of Container Service.

Let’s get started!

Get a Free Trial for Oracle Cloud. It takes a few days for the trial to be activated. The trial time bombs after 30 days so make sure you’ve time planned for evaluation. Each free trial comes with 6 OC3 nodes. OC3 is one of the compute node types available on Oracle Cloud. OC3 particularly is 1 OCPU (think vCPU on Amazon Web Services) and 7.5 GB RAM.
Once the account is activated, you get an email as shown:The important piece of information is username, temporary password, identity domain and My Services URL. The My Account URL link is only for account administration.
Click on My Service URL, login using the values from email:
You get an opportunity to change your password afterwards
Oracle Cloud dashboard shows up after logging in:A default set of services and their status is shown. The dashboard can also be customized by clicking on Customize Dashboard button on the top right.
Getting to Oracle Container Cloud Service Console is a bit non-intuitive but you get it once you know it. Select Container Cloud Service tab, click on top-right corner and select Open Service Console:Or you can directly click on the link for Oracle Container Cloud Service Console in the welcome email. Service console looks like:
Click on Create Service:Oracle Container Container Service Instance Details provide more details about each of the field.What is a worker node? We’ll talk about it a bit later. But essentially this is where the container runs. We are asking for only one worker node.
Its worth noting different capacities for the worker node:

Confirm all the settings:

and click on Create> to start the service creation.

Wait for about 30 minutes for the service to be created. After that the Service Console looks like:

oracle-cloud-container-service-console-with-service

Wait, we asked for one worker node and how come two OCPUs are being consumed.Each Oracle Container Cloud Service has at least two nodes – a manager node and one or more worker nodes. Manager node is responsible for administration of all the workers and and orchestrate containers on different worker nodes. Worker nodes can be organized in different resource pools to meet different workflow needs.

And, so ~30 minutes are spent provisioning two nodes and installing container service components on each node. This is also evident in the service logs shown in Service Create and Delete History shown in the main Console page:

Activity Submitted

Activity Started

Started operation to create service [couchbase] in identity domain [arungupta].

Creating service [couchbase] resources [couchbase-occs-mgr-1,couchbase-occs-wkr-1].

Completed creating service [couchbase] in domain [arungupta].

Started operation to establish security on VMs for component [MANAGER].

Completed operation to establish security on VMs for component [MANAGER]

Started operation to establish security on VMs for component [WORKER].

Completed operation to establish security on VMs for component [WORKER]

Started operation to check provisioning status on the VMs for [MANAGER]

Started operation to check provisioning status on the VMs for [WORKER]

Provisioning Succeeded on all hosts for component [WORKER]

Provisioning Succeeded on all hosts for component [MANAGER]

Provisioning of [MANAGER] succeeded.

Provisioning of [WORKER] succeeded.

Provisioning of all components completed.

Started service reachability check operation for [MANAGER].

Started service reachability check operation for [WORKER].

Reachability Succeeded on all hosts for component [MANAGER]

Successfully completed service reachability check for [MANAGER]

Successfully completed service reachability check for [WORKER]

Reachability Succeeded on all hosts for component [WORKER]

Service reachability check of [WORKER] succeeded.

Service reachability check of all components completed.

Service reachability check of [MANAGER] succeeded.

Activity Ended

Activity Ended

Activity Submitted

Activity Started

Started operation to create service [couchbase] in identity domain [arungupta].

Creating service [couchbase] resources [couchbase-occs-mgr-1,couchbase-occs-wkr-1].

Completed creating service [couchbase] in domain [arungupta].

Started operation to establish security on VMs for component [MANAGER].

Completed operation to establish security on VMs for component [MANAGER]

Started operation to establish security on VMs for component [WORKER].

Completed operation to establish security on VMs for component [WORKER]

Started operation to check provisioning status on the VMs for [MANAGER]

Started operation to check provisioning status on the VMs for [WORKER]

Provisioning Succeeded on all hosts for component [WORKER]

Provisioning Succeeded on all hosts for component [MANAGER]

Provisioning of [MANAGER] succeeded.

Provisioning of [WORKER] succeeded.

Provisioning of all components completed.

Started service reachability check operation for [MANAGER].

Started service reachability check operation for [WORKER].

Reachability Succeeded on all hosts for component [MANAGER]

Successfully completed service reachability check for [MANAGER]

Successfully completed service reachability check for [WORKER]

Reachability Succeeded on all hosts for component [WORKER]

Service reachability check of [WORKER] succeeded.

Service reachability check of all components completed.

Service reachability check of [MANAGER] succeeded.

Activity Ended

No timestamp in the activity feels a bit too clean.

One main question that I kept wondering all along is “when am I ready to deploy the containers?“. Apparently, not yet!A couple of more steps so hang in there …
In your service, click on the top-right icon to select another menu:

Select Container Console. So, now you are transitioning from Oracle Container Cloud Service Console to Container Console. Make sure to use the right terminology otherwise it gets confusing fast.
This attempts to open Container Console but prompts the usual warning
Just click on Proceed link. In a typical production setup, this will setup correctly using certificates and so this warning would not happen.
This brings up a login screen:
Use the username and password specified during service creation earlier. Click on Login to see Container Console:

Are we there yet?

Yes, now is the time to deploy containers. But we’ll cover that in a subsequent blog!

Just to recap on what is needed to get started with Oracle Container Cloud Service …

Register for Oracle Cloud trial
Login to main Oracle Cloud Dashboard
Create a Oracle Container Cloud Service Instance
Oracle Container Cloud Service Instance Console
Container Console

All the steps need to be done once but a console inside a console inside a dashboard feels like Inception. The good thing is that the IP address of Container Console is a public IP address served by Oracle Cloud and can be used from anywhere.

Oracle Container Cloud Service Docs have lot more details about building and deploying applications using this Console.

In the next blog, we’ll see what it takes to run a Couchbase container using this console? Possibly a cluster of Couchbase across multiple hosts?

Want to learn more about running Couchbase in containers?

Couchbase on Containers
Couchbase Forums
Couchbase Developer Portal
@couchhasedev and @couchbase

Source: https://blog.couchbase.com/2017/february/getting-started-oracle-container-cloud-service

Microservice using Docker stack deploy – WildFly, Java EE and Couchbase

February 3, 2017containers, couchbase, wildflycouchbase, javaee, microservice, wildflyarungupta

There is plenty of material on microservices, just google it! I gave a presentation on refactoring monolith to microservices at Devoxx Belgium a couple of years back and it has good reviews:

This blog will show how Docker simplifies creation and shutting down of a microservice.

All code used in this blog is at github.com/arun-gupta/couchbase-javaee.

Microservice Definition using Compose

Docker 1.13 introduced a v3 of Docker Compose. The changes in the syntax are minimal but the key difference is addition of deploy attribute. This attribute allows to specify replicas, rolling update and restart policy for the container.

Our microservice will start a WldFly application server with a Java EE application pre-deployed. This application will talk to a Couchbase database to CRUD application data.

Here is the Compose definition:

version: '3'
services:
  web:
    image: arungupta/couchbase-javaee:travel
    environment:
      - COUCHBASE_URI=db
    ports:
      - 8080:8080
      - 9990:9990
    depends_on:
      - db
  db:
    image: arungupta/couchbase:travel
    ports:
      - 8091:8091
      - 8092:8092 
      - 8093:8093 
      - 11210:11210

version: '3'

services:

web:

image: arungupta/couchbase-javaee:travel

environment:

- COUCHBASE_URI=db

ports:

- 8080:8080

- 9990:9990

depends_on:

- db

db:

image: arungupta/couchbase:travel

ports:

- 8091:8091

- 8092:8092

- 8093:8093

- 11210:11210

In this Compose file:

Two services in this Compose are defined by the name db and web attributes
Image name for each service defined using image attribute
The arungupta/couchbase:travel image starts Couchbase server, configures it using Couchbase REST API, and loads travel-sample bucket with ~32k JSON documents.
The arungupta/couchbase-javaee:travel image starts WildFly and deploys application WAR file built from https://github.com/arun-gupta/couchbase-javaee. Clone that project if you want to build your own image.
envrionment attribute defines environment variables accessible by the application deployed in WildFly. COUCHBASE_URI refers to the database service. This is used in the application code as shown at https://github.com/arun-gupta/couchbase-javaee/blob/master/src/main/java/org/couchbase/sample/javaee/Database.java.
Port forwarding is achieved using ports attribute
depends_on attribute in Compose definition file ensures the container start up order. But application-level start up needs to be ensured by the applications running inside container. In our case, WildFly starts up rather quickly but takes a few seconds for the database to start up. This means the Java EE application deployed in WildFly is not able to communicate with the database. This outlines a best practice when building micro services applications: you must code defensively and ensure in your application initialization that the micro services you depend on have started, without assuming startup order. This is shown in the database initialization code at https://github.com/arun-gupta/couchbase-javaee/blob/master/src/main/java/org/couchbase/sample/javaee/Database.java. It performs the following checks:
1. Bucket exists
2. Query service of Couchbase is up and running
3. Sample bucket is fully loaded

This application can be started using docker-compose up -d command on a single host. Or a cluster of Docker engines in swarm-mode using docker stack deploy command.

Setup Docker Swarm-mode

Initialize Swarm mode using the following command:

docker swarm init

docker swarm init

This starts a Swarm Manager. By default, manager node are also worker but can be configured to be manager-only.

Find some information about this one-node cluster using the command docker info command:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 17
Server Version: 1.13.0
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: active
 NodeID: 92mydh0e09ba5hx3wtmcmvktz
 Is Manager: true
 ClusterID: v68ikyaff7rdxpaw1j0c9i60s
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 192.168.65.2
 Manager Addresses:
  192.168.65.2:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.5-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.952 GiB
Name: moby
ID: SGCM:KDRD:G3M7:PZHN:J4RL:VFFR:G2SR:EKD5:JV4J:RL3X:LF7T:XF6V
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 31
 Goroutines: 124
 System Time: 2017-01-27T08:25:58.032295342Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Username: arungupta
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Containers: 0

Running: 0

Paused: 0

Stopped: 0

Images: 17

Server Version: 1.13.0

Storage Driver: overlay2

Backing Filesystem: extfs

Supports d_type: true

Native Overlay Diff: true

Logging Driver: json-file

Cgroup Driver: cgroupfs

Plugins:

Volume: local

Network: bridge host ipvlan macvlan null overlay

Swarm: active

NodeID: 92mydh0e09ba5hx3wtmcmvktz

Is Manager: true

ClusterID: v68ikyaff7rdxpaw1j0c9i60s

Managers: 1

Nodes: 1

Orchestration:

Task History Retention Limit: 5

Raft:

Snapshot Interval: 10000

Number of Old Snapshots to Retain: 0

Heartbeat Tick: 1

Election Tick: 3

Dispatcher:

Heartbeat Period: 5 seconds

CA Configuration:

Expiry Duration: 3 months

Node Address: 192.168.65.2

Manager Addresses:

192.168.65.2:2377

Runtimes: runc

Default Runtime: runc

Init Binary: docker-init

containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e

runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e

init version: 949e6fa

Security Options:

seccomp

Profile: default

Kernel Version: 4.9.5-moby

Operating System: Alpine Linux v3.5

OSType: linux

Architecture: x86_64

CPUs: 4

Total Memory: 1.952 GiB

Name: moby

ID: SGCM:KDRD:G3M7:PZHN:J4RL:VFFR:G2SR:EKD5:JV4J:RL3X:LF7T:XF6V

Docker Root Dir: /var/lib/docker

Debug Mode (client): false

Debug Mode (server): true

File Descriptors: 31

Goroutines: 124

System Time: 2017-01-27T08:25:58.032295342Z

EventsListeners: 1

No Proxy: *.local, 169.254/16

Username: arungupta

Registry: https://index.docker.io/v1/

Experimental: true

Insecure Registries:

127.0.0.0/8

Live Restore Enabled: false

This cluster has 1 node, and that is manager.

Alternatively, a multi-host cluster can be easily setup using Docker for AWS.

Deploy Microservice

The microservice can be started as:

docker stack deploy --compose-file=docker-compose.yml webapp

docker stack deploy --compose-file=docker-compose.yml webapp

This shows the output:

Creating network webapp_default
Creating service webapp_web
Creating service webapp_db

Creating network webapp_default

Creating service webapp_web

Creating service webapp_db

WildFly and Couchbase services are started on this node. Each service has a single container. If the Swarm mode is enabled on multiple nodes then the containers will be distributed across multiple nodes.

A new overlay network is created. This allows multiple containers on different hosts to communicate with each other.

Verify that the WildFly and Couchbase services are running using docker service ls:

ID            NAME        MODE        REPLICAS  IMAGE
a9pkiziw3vgw  webapp_db   replicated  1/1       arungupta/couchbase:travel
hr5s6ue54kwj  webapp_web  replicated  1/1       arungupta/couchbase-javaee:travel

ID NAME MODE REPLICAS IMAGE

a9pkiziw3vgw webapp_db replicated 1/1 arungupta/couchbase:travel

hr5s6ue54kwj webapp_web replicated 1/1 arungupta/couchbase-javaee:travel

Logs for the service can be seen using docker service logs -f webapp_web:

webapp_web.1.wby0b04t7bap@moby    | =========================================================================
webapp_web.1.wby0b04t7bap@moby    |
webapp_web.1.wby0b04t7bap@moby    |   JBoss Bootstrap Environment
webapp_web.1.wby0b04t7bap@moby    |
webapp_web.1.wby0b04t7bap@moby    |   JBOSS_HOME: /opt/jboss/wildfly
webapp_web.1.wby0b04t7bap@moby    |
webapp_web.1.wby0b04t7bap@moby    |   JAVA: /usr/lib/jvm/java/bin/java
webapp_web.1.wby0b04t7bap@moby    |
webapp_web.1.wby0b04t7bap@moby    |   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
webapp_web.1.wby0b04t7bap@moby    |
webapp_web.1.wby0b04t7bap@moby    | =========================================================================

. . .

webapp_web.1.wby0b04t7bap@moby    | 23:14:15,811 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 34) WFLYSRV0010: Deployed "airlines.war" (runtime-name : "airlines.war")
webapp_web.1.wby0b04t7bap@moby    | 23:14:16,076 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
webapp_web.1.wby0b04t7bap@moby    | 23:14:16,077 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
webapp_web.1.wby0b04t7bap@moby    | 23:14:16,077 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 98623ms - Started 443 of 691 services (404 services are lazy, passive or on-demand)

webapp_web.1.wby0b04t7bap@moby | =========================================================================