2 Building WebLogic Server Images on Docker

This section discusses how to use the Dockerfiles and supporting scripts that Oracle has made available on GitHub to build your own WebLogic Server 12.1.3 Docker images.

Topics include:

Building WebLogic Server Images on Docker
Running an Administration Server Container
Running a Managed Server Container
Additional Considerations When Running WebLogic Server Images in Docker Containers

Building WebLogic Server Images on Docker

Before you begin, choose the installation type you want to use, either the Generic or Developer installer, as described in About WebLogic Server Images on Docker. Then follow these steps:

Download the required WebLogic Server installer and JDK in the dockerfiles/12.1.3 directory.
Change to the /dockerfiles directory and run the buildDockerImage.sh script as root:
```
$ sudo sh buildDockerImage.sh -h
```
Usage: buildDockerImage.sh [-d]

where d: creates image based on the Developer distribution or the Generic distribution if omitted.

Note:

The resulting image will not have a domain pre-configured. Oracle provides a separate Dockerfile and supporting scripts to extend the WebLogic Server install image and create an WebLogic Server domain image.

Samples for WebLogic Server Domain Creation

To give you an idea on how to create a domain from a custom Dockerfile to extend the WebLogic Server install image, Oracle provides some samples for WebLogic Server 12c (12.1.3) for both the Developer and Generic distributions. The samples are in the samples/1213-domain directory.

Sample Domain for WebLogic Server 12c (12.1.3)

This Dockerfile will create an image by extending oracle/weblogic:12.1.3-dev (from the Developer distribution). It will configure a base_domain with the following settings:

JPA 2.1 enabled
JAX-RS 2.0 shared library deployed
Administrator Username: weblogic
Administrator Password: welcome1
Oracle Linux Username: oracle
Oracle Linux Password: welcome1
WebLogic Server Domain Name: base_domain

Write Your Own Oracle WebLogic Server Domain with WLST

The best way to create your own domain, or to extend domains, is by using WLST. The WLST script used to create domains in the Dockerfile container is create-wls-domain.py. This script by default adds JMS resources and a few other settings.

You may want to tune this script with your own setup to create data sources and connection pools, security realms, deploy artifacts, and so on. You can also extend images and override the existing domain, or create a new one with WLST.

For more information about using WLST, refer to Oracle Fusion Middleware Oracle WebLogic Scripting Tool.

Building a Sample Docker Image of a WebLogic Server Domain

To build a sample of a WebLogic Server image with a domain configured, follow these steps:

Make sure you have oracle/weblogic:12.1.3-dev image built as described in Building WebLogic Server Images on Docker. If not, change to the /dockerfiles directory and run the buildDockerImage.sh script as root:
```
$ sudo sh buildDockerImage.sh -d
```
Change to the /samples/1213-domain directory and run the docker build command:
```
$ sudo docker build -t samplewls:12.1.3
```
Verify that you have the image in place by running the docker images command:
```
$ sudo docker images
```

Running an Administration Server Container

When you use the WebLogic Server domain image to start your container, an Administration Server will start running in the container by default. The default Administration Server name is AdminServer, the default port configuration is 8001, and the default Administration Server container name is wlsadmin. When running more than one domain in the same single host, you must change the Administration Server name, port number, and container name.

To start the Administration Server:

Execute the docker run command:
```
$ sudo docker run -d --name=wlsadmin samplewls:12.1.3
```
where samplewls:12.1.3 is the WebLogic Server domain image tag. The samples Dockerfiles define startWebLogic.sh as the default CMD (command).
To obtain the IP address of the Administration Server Container run the docker inspect command:
```
$ sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' wlsadmin
```
Open the Administration Server's web-based console at http:// xxx.xx.x.xx:8001/console.

Note:

If you have multiple WebLogic Server domains running on the same host (i.e., multiple Administration Servers), change the -name parameter (name of the Administration Server container) and the -p parameter (port of the Administration Server).

Running a Managed Server Container

Managed Server containers have a Node Manager and a Managed Server running in it. These Managed Server containers communicate to an Administration Server container by linking (--link command) using the Administration Server container name. The Administration Server container name defaults to wlsadmin.

When there are more than one domain running on the same host, then the Administration Server container name needs to be unique, you need to change the Administration Server container name by using the -name parameter and matching the name given in the -link command of each Managed Server container.

There are three different ways to start a Managed Server container:

Start Node Manager (manually):

$ sudo docker run -d --link wlsadmin:wlsadmin <image-name> startNodeManager.sh

Start Node Manager and create a Machine automatically:

$ sudo docker run -d --link wlsadmin:wlsadmin <image-name>  createMachine.sh

Start Node Manager, create a Machine, and create a Managed Server automatically:
```
$ sudo docker run -d --link wlsadmin:wlsadmin <image-name>  createServer.sh
```

Sample Managed Server Command and Parameters

Here's a sample docker run command for a Managed Server container and a listing of available parameters.

$ sudo docker run -d -link wlsadmin:wlsadmin \
     -p <NM Port>:5556 -p <MS Port>:<MS Port> \
     -name=<Container name> \
     -e MS_HOST=<Host address where Managed Server container runs> \
     -e MS_PORT=<Managed Server port> \
     -e NM_HOST=<Host address where Managed Server container runs> \
     -e NM_PORT=<Node Manager Port (should match the port in the -p)> \
     <image name> \
     <createMachine.sh, startNodeManager.sh, createServer.sh>

Script Variables

The supported scripts have a list of variables that must be properly configured, as defined in Table 2-1.

Table 2-1 Script Variables and Definitions

Variable	Definition
`ADMIN_USERNAME`	Username of the AdminServer `weblogic` user. Default: `weblogic`
`ADMIN_PASSWORD`	Password of `ADMIN_USERNAME`. Defaults to value passed during Dockerfile build. (`welcome1` in the samples)
`ADMIN_URL`	t3 URL of the AdminServer. Default: `t3://wlsadmin:8001`
`CONTAINER_NAME`	Name of the Machine to be created. Default: `node manager_ + hash` of the container
`NM_HOST`	IP address where Node Manager can be reached. Default: IP address of the container
`NM_PORT`	Port of Node Manager. Default: `5556`
`MS_HOST`	IP address where Managed Server can be reached. Default: IP address of the container
`MS_PORT`	Port of Managed Server. Default: `7001`

Examples of Using the Script Variables

The following command will run a Managed Server container:

$ sudo docker run -d -link wlsadmin:wlsadmin -p 5558:5556 --name="wlsnm0" -e NM_HOST="xx.xxx.xx.xxx" -e NM_PORT="5558" samplewls:10.3.6 createMachine.sh

If you want to run "Single-Host" configuration on a remote server (i.e., DevOps machine), you must expose ports and addresses of the Managed Servers, as shown in these examples:

$ sudo docker run -d --link wlsadmin:wlsadmin   -p 7003:7003
-e MS_HOST=xx.xxx.xx.xxx -e MS_PORT=7003 samplewls:12.1.3 createServer.sh

$ sudo docker run -d --link wlsadmin:wlsadmin   -p 7002:7002
-e MS_HOST= xx.xxx.xx.xxx  -e MS_PORT=7002 samplewls:12.1.3 createServer.sh

Note:

You must assign a new, unique listen port when you create an additional Managed Server container on a host OS where a Managed Server container is already running. This prevents multiple Managed Servers running on the same host OS from listening on the same listen port.

If you used the createServer.sh command:

Access the Administration Server console at http://admin-container-ip:8001 /console.
In the Domain Structure tree, expand Environment.
Select Machines to open the Summary of Machines page and verify that you have a Machine registered.
Click your registered Machine in the table, and then use the Node Manager and Servers tabs to verify that your Node Manager and Managed Server are also configured.
Open the Servers page, select the Control tab, and start your server.

Additional Considerations When Running WebLogic Server Images in Docker Containers

This section addresses some additional considerations when running WebLogic Server images in Docker containers.

How IP Addresses Are Handled When a Docker Container Is Restarted

When a Docker container is restarted its IP addresses change, so WebLogic Servers running in the Docker container will now have a new address. Applications, as well as others servers that were communicating with the server before the container restart, will be unable to communicate.

One solution is to configure a DNS server on Docker and configure WebLogic Server domains to use DNS names after a container restart.

How the File System Is Managed in Containers

WebLogic Server configuration files, server logs, file stores, and so on, are all kept in the container file system. When a Docker container is destroyed you will lose your entire file system. There are two alternatives to avoid losing your filesystem, described below and illustrated in :

Maintain a "data-only" container to store your domain file system. (Container1 and DataCont-1 in the figure.)
Use the host file system to store the container's local file system. (Container2 in the figure.)

Note:

Container0 in the figure represents a single WebLogic Server that is stateless. Its only function is to deploy applications and resources and does not need to maintain its file system. If it is destroyed, you can just start a new one from the image.

To minimize the dependency on the file system, Oracle recommends:

Keeping your stores, such as TLog and JMS stores, in the database.
If you use XA Transactions, use XATransactions without TLog write, because this minimizes the writing to the TLog. See "XA Transactions without Transaction TLog Write" in Developing JTA Applications for Oracle WebLogic Server.

Figure 2-1 Managing the File System with Docker Containers

Description of ''Figure 2-1 Managing the File System with Docker Containers''

How Clustered WebLogic Servers Communicate in Containers

Clustered Oracle WebLogic Servers must communicate between themselves and with the Administration Server. Docker containers running on different host machines do not have the necessary visibility and access to communicate directly with other containers. Consequently, the use of WebLogic Server configurations that span multiple hosts operating systems is not supported at this time.

A possible alternative configuration is to run your entire WebLogic Server domain on a single host.

Patching and Upgrading WebLogic Server Images

To patch or upgrade your WebLogic Server images created with the WebLogic Server generic installation image, follow these steps:

Upgrade or patch the image by extending the WebLogic Server install Docker image.
Use the Docker cp (copy) command to copy your domain directory to a destination directory on either the host or a "data-only" container.
Remove the container.
Run the new container from the extended image (with upgrade/patch).
Use the Docker cp command to copy your domain directory back to the upgraded container.

Security Concerns Regarding Docker and Linux Containers

The following security concerns have been raised regarding Docker and Linux containers:

One area of concern is whether it is possible to isolate code running in separate containers from each other. There are no known issues impacting the ability to run WebLogic Server in such an environment at this time.
Another security concern is the source of the Docker images. You should only obtain Docker images from trusted sources and you need to be aware of the frequency of updates and the nature of the controls on Docker Hub.
You should stay current with Docker and Linux technology and remain aware of security issues that are raised in each.
Docker containers default network mode of "Bridge Networking" does not support multicast. Docker containers "Host Networking" supports multicast, but provides less isolation since it uses the host networking stack. Oracle recommends the use of unicast as the WebLogic Server clustering protocol when running in Docker containers.