Docker, Swarm and Weave – Running a Containerized WebLogic 12c Domain on Multiple Hosts

About

Blog

Privacy Policy

SiteMap

In some of the previous posts, it is explained how to create Docker images and run WebLogic server inside Docker containers, and how to use the power of WLST scripts and 12c Dynamic clusters to easily scale WebLogic domains by simply starting more Docker containers with a simple parameter telling the Managed server where to connect to the Admin Server. However, even if new Docker tools like Swarm allow the remote management of docker containers spread across multiple docker hosts, the communication between the containers themselves is not working out-of-the-box and must be treated separately. This communication is vital in a WebLogic domain, where all the server instances belonging to the same cluster must be able to connect to each other for features like cluster health (heartbeats), session replication, JNDI replication etc.

This post describes how to set up a multi-host WebLogic 12c domain that can be scaled by starting new Docker containers on a preferred host from a centralized docker client , using Swarm to orchestrate clustered containers. The testcase will consider two virtual machines running Oracle Linux. Each WebLogic server will run inside its own container. All containers will be grouped within a Swarm cluster and orchestrated from a centralized client, managing containers on remote hosts. Since Docker only allows communication between containers and the local docker host by default, a bridge between the hosts will be setup that will replace the default ‘docker0’ interface. This will allow containers on different hosts to be connected.

The domain will initially run on two hosts, that in this case are two virtual machines running OL6, each with a Docker installation in place, and are connected via a bridged interface. The setup of such a virtual machine is described here .

dockervm1 192.168.56.103

dockervm2 192.168.56.104

Also, the firewall rules between the nodes have been disabled — “iptables -F”

Apart from docker , the setup also requires installing swarm and weave on each of the hosts.

– To install swarm:

docker run -ti –name=buildswarm golang bash [root@dockervm1 ~]# get -u github.com/docker/swarm [root@dockervm1 ~]# exit [root@dockervm1 ~]# docker cp buildswarm:/go/bin/swarm . [root@dockervm1 ~]# . /swarm -v swarm version 0.0.1

The swarm executable can be then copied to the second host.

– To install weave:

sudo wget -O /usr/local/bin/weave \ https://github.com/weaveworks/weave/releases/download/latest_release/weave sudo chmod a+x /usr/local/bin/weave

sudo wget -O /usr/local/bin/weave \ https://github.com/weaveworks/weave/releases/download/latest_release/weave

sudo chmod a+x /usr/local/bin/weave

Since weave runs inside a docker container as well, weave images will be automatically downloaded later, when starting up the weave containers.

By default docker containers will only be able to connect to other containers running on the same docker hosts via the implicit ‘docker0’ bridged interface. In order to allow containers running on different hosts to communicate, a new bridge is defined. Weave is very useful in hiding the network setup complexities, by running just a few straightforward commands.

First, the weave birdge must be created on each of the dockervm1 and dockervm2 hosts:

[root@dockervm1 ~]# weave create-bridge [root@dockervm2 ~]# weave create-bridge

[root@dockervm1 ~]# weave create-bridge

[root@dockervm2 ~]# weave create-bridge

and an IP address is assigned to it:

[root@dockervm1 ~] ip addr add dev weave 10.2.0.1/16 [root@dockervm2 ~] ip addr add dev weave 10.2.0.2/16

[root@dockervm1 ~] ip addr add dev weave 10.2.0.1/16

[root@dockervm2 ~] ip addr add dev weave 10.2.0.2/16

To have the bridge start automatically at boot time, the “ifcfg-weave” script is created on each hosts under /etc/sysconfig/network-scripts with the below content. Only the IP address should be specific to the node.

DEVICE=weave TYPE=Bridge BOOTPROTO=static BROADCAST=0.0.0.0 IPADDR=10.2.0.1 NETMASK=255.255.0.0 NETWORK=10.2.0.0 ONBOOT=yes USERCTL=no IPV6INIT=no MTU=1500

In order to replace the default “docker0” bridge, the docker daemon will be started with the following parameters:

The below parameters must be added to the DOCKER_OPTS in /etc/default/docker (or /etc/sysconfig/docker ):

dockervm1 : DOCKER_OPTS=”-H tcp://0.0.0.0:4253 -H unix:///var/run/docker.sock –bridge=weave –fixed-cidr=10.2.1.0/24 –label node=dockervm1″

dockervm2 : DOCKER_OPTS=”-H tcp://0.0.0.0:4253 -H unix:///var/run/docker.sock –bridge=weave –fixed-cidr=10.2.2.0/24 –label node=dockervm2″

The docker daemon requires a restart: service docker restart

Once docker is restarted on both hosts, the weave router can be started as well:

[root@dockervm1 ~]# weave launch [root@dockervm1 ~]# weave connect 192.168.56.104 [root@dockervm2 ~]# weave launch [root@dockervm2 ~]# weave connect 192.168.56.103

[root@dockervm1 ~]# weave launch [root@dockervm1 ~]# weave connect 192.168.56.104

[root@dockervm2 ~]# weave launch [root@dockervm2 ~]# weave connect 192.168.56.103

That will start a weave docker container on each of the hosts and the hosts should be reachable from one another on the weave bridged interface:

Once the weave network is set up to allow containers from different hosts to connect to each other, the swarm cluster needs to be configured so that containers can be orchestrated from a centralized docker client, connecting to docker daemons from the various hosts of the topology.

The containers cluster will be controlled from the dockervm1 host (although it can run on any other machine having docker and swarm installed).

First a swarm cluster is created:

[root@dockervm1 docker]# ./swarm create 118ec52290539937f2df5369e734887c

Once the token is returned, each node will join this cluster, advertising it’s address. Incoming connections on port 4253 have been enabled by setting up the -H tcp://0.0.0.0:4253 parameter of the docker daemon.

[root@dockervm1 docker]# ./swarm join token://118ec52290539937f2df5369e734887c –addr “192.168.56.103:4253” [root@dockervm2 docker]# ./swarm join token://118ec52290539937f2df5369e734887c –addr “192.168.56.104:4253”

[root@dockervm1 docker]# ./swarm join token://118ec52290539937f2df5369e734887c –addr “192.168.56.103:4253”

[root@dockervm2 docker]# ./swarm join token://118ec52290539937f2df5369e734887c –addr “192.168.56.104:4253”

The nodes that have joined the cluster can be then verified by the token:

[root@dockervm1 docker]# ./swarm l token://118ec52290539937f2df5369e734887c 192.168.56.103:4253 192.168.56.104:4253

Once all the nodes are confirmed, the service to manage the cluster is started:

[root@dockervm1 docker]# ./swarm manage token://118ec52290539937f2df5369e734887c –strategy spread INFO[0000] Listening for HTTP addr=127.0.0.1:2375 proto=tcp

Basically, on the dockervm1 machine a docker service is accessible at 127.0.0.1:2375 that acts as a interface for docker clients across the cluster. After setting the DOCKER_HOST environment variable to 127.0.0.1:2375 the swarm cluster can be managed just as any other single docker host, and docker info will reveal the resources in the cluster:

One container is already running on each node: weave

The setup is finally complete and the WebLogic domain can be started by firing up the containers based on the radudobrinescu/wls12c:1.0 docker image. Each container will be started on a node of choice by specifying the environment variable “constraint”, indicating the label that has been on the docker deamon on each hosts.

To start the Administration Server:

docker run -itd -e constraint:node==dockervm1 -e SERVER_TYPE=AdminServer –name AdminServer -p 192.168.56.103:7001:7001 radudobrinescu/wls12c:1.0 bash -c “/oracle/fmwhome/wlst_custom/startWLS12c.sh && /bin/bash”

This will run the container in the background, to check the log file docker attach AdminServer. In about a minute, the server is up and running and the administration console is available by the exposed port 7001 on host dockervm1 , where the AdminServer container has been started:

Before starting the managed servers, the IP address of the container running the Administration server must be identified. The ip address will be used as a value for the ADMIN_HOSTNAME environment variable passed to the managed servers containers, to allow the managed servers to connect to the administration server.

[root@dockervm1 ~]# docker inspect AdminServer |grep IPAddress “IPAddress”: “10.2.1.6”,

To start the first managed server in the cluster, on the dockervm1 host:

docker run -itd -e constraint:node==dockervm1 -e SERVER_TYPE=ManagedServer -e ADMIN_HOSTNAME=10.2.1.6 -p 7101:7101 –name ManagedServer1 radudobrinescu/wls12c:1.0 bash -c “/oracle/fmwhome/wlst_custom/startWLS12c.sh && /bin/bash”

Starting the second server instance, this time on the dockervm2 host:

docker run -itd -e constraint:node==dockervm2 -e SERVER_TYPE=ManagedServer -e ADMIN_HOSTNAME=10.2.1.6 -p 7102:7102 –name ManagedServer2 radudobrinescu/wls12c:1.0 bash -c “/oracle/fmwhome/wlst_custom/startWLS12c.sh && /bin/bash”

So, checking the most recently started 3 containers, the weblogic containers are listed, and the names include the node each container is running on:

After a couple of minutes, the Weblogic instances are up and running, and can be viewed in the servers summary page of the administration console:

To check the functionality of the cluster, a demo application is being deployed and targeted to the Dynamic_Cluster. First, the application is accessed with the browser on the Docker-MS-1 managed server:

To verify that the communication between the nodes of the cluster is running, the session replication is verified in the cluster monitoring page:

There is one primary session on server Docker-MS-1, and a secondary session on Docker-MS-2.

Once a new session is started on the second node as well…

A primary session now exists on Docker-MS-2 as well, with the replica on Docker-MS-1:

The WebLogic domain can now be further scaled to additional hardware, with little effort. This setup can be especially useful in load testing scenarios.

Share

Email

Tweet

Pocket

← Oracle Officially Supports WebLogic 12.1.3 on Docker Containers

WebLogic Smart Dashboard and Monitoring – A Valuable Help for WebLogic Administrators →

Pingback: Summary of Fusion Middleware 12.2.1 New Features - Oracle Middleware Blog

Tobias January 4, 2016 at 10:59 pm Have you tried Docker 1.9 with the new cross host container networking? I’m thinking it will be simpler. Reply ↓ Radu Dobrinescu Post author January 5, 2016 at 8:02 am Hi Tobias and thanks for the comment. I have not tried it yet, since this solution was not available at the time this post was written. However there will be a new article where the same cross host setup will be built with Docker 1.9, Docker Machine and Swarm. Reply ↓

Have you tried Docker 1.9 with the new cross host container networking? I’m thinking it will be simpler.

Radu Dobrinescu Post author January 5, 2016 at 8:02 am Hi Tobias and thanks for the comment. I have not tried it yet, since this solution was not available at the time this post was written. However there will be a new article where the same cross host setup will be built with Docker 1.9, Docker Machine and Swarm. Reply ↓

Hi Tobias and thanks for the comment. I have not tried it yet, since this solution was not available at the time this post was written. However there will be a new article where the same cross host setup will be built with Docker 1.9, Docker Machine and Swarm.

Your email address will not be published.

Comment

Name

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.

Dealing with Stuck Threads in WebLogic

Unable to start WLST: "Could Not Find or Load Main Class weblogic.WLST"

Setting up Watches and Notifications in Weblogic Server

How To Improve Weblogic Servers Startup Time

What's new in Oracle Weblogic Server 12c

WebLogic 12c Enterprise Deployment Architecture in the Amazon Cloud

WebLogic AdminServer startup and shutdown scripts

Cannot connect to Node Manager. : Access to domain for user 'weblogic' denied

Report File System Usage Across All Hosts with EM Cloud Control 12c

Node Manager as Linux service and Weblogic server autorestart