Sunday, November 2, 2014

Running WebSphere Application Server (full profile) in a Docker container

This article describes how to run WebSphere Application Server in a Docker container. We are going to use the developer version to create a full profile, but the instructions can easily be adapted to a regular WebSphere version (provided you have an appropriate license). To create the Docker image, download IBM Installation Manager for Linux x86_64 and use the following Dockerfile, after replacing the -userName and -userPassword arguments with your IBM ID:

FROM centos:centos6

RUN yum install -q -y unzip

ADD agent.installer.linux.gtk.x86_64_*.zip /tmp/

 unzip -qd /tmp/im /tmp/agent.installer.linux.gtk.x86_64_*.zip && \
 /tmp/im/installc \
   -acceptLicense \
   -showProgress \
   -installationDirectory /usr/lib/im \
   -dataLocation /var/im && \
 rm -rf /tmp/agent.installer.linux.gtk.x86_64_*.zip /tmp/im

 /usr/lib/im/eclipse/tools/imutilsc saveCredential \
   -url \
   -userName \
   -userPassword mypassword \
   -secureStorageFile /root/credentials && \
 /usr/lib/im/eclipse/tools/imcl install \ \
   -repositories \
   -acceptLicense \
   -showProgress \
   -secureStorageFile /root/credentials \
   -sharedResourcesDirectory /var/cache/im \
   -preferences \
   -installationDirectory /usr/lib/was && \
 rm /root/credentials

RUN useradd --system -s /sbin/nologin -d /var/was was

 hostname=$(hostname) && \
 /usr/lib/was/bin/ -create \
   -templatePath /usr/lib/was/profileTemplates/default \
   -profileName default \
   -profilePath /var/was \
   -cellName test -nodeName node1 -serverName server1 \
   -hostName $hostname && \
 echo -n $hostname > /var/was/.hostname && \
 chown -R was:was /var/was

USER was

RUN echo -en '#!/bin/bash\n\
set -e\n\
old_hostname=$(cat /var/was/.hostname)\n\
if [ $old_hostname != $hostname ]; then\n\
  echo "Updating configuration with new hostname..."\n\
  sed -i -e "s/\"$old_hostname\"/\"$hostname\"/" $node_dir/serverindex.xml\n\
  echo $hostname > /var/was/.hostname\n\
if [ ! -e $launch_script ] ||\n\
   [ $node_dir/servers/server1/server.xml -nt $launch_script ]; then\n\
  echo "Generating launch script..."\n\
  /var/was/bin/ server1 -script $launch_script\n\
' > /var/was/bin/ && chmod a+x /var/was/bin/

# Speed up the first start of a new container
RUN /var/was/bin/

RUN echo -en '#!/bin/bash\n\
set -e\n\
echo "Starting server..."\n\
exec /var/was/bin/\n\
' > /var/was/bin/ && chmod a+x /var/was/bin/

CMD ["/var/was/bin/"]

Note that by executing this Dockerfile you accept the license agreement for IBM Installation Manager and WebSphere Application Server for Developers.

Here are some more details about the Dockerfile:

  • Only IBM Installation Manager needs to be downloaded before creating the image. The product itself (WebSphere Application Server for Developers 8.5.5) is downloaded by Installation Manager during image creation. Note that this may take a while. The preserveDownloadedArtifacts=false preference instructs Installation Manager to remove the downloaded packages. This reduces the size of the image.

  • The Dockerfile creates a default application server profile that is configured to run as a non-root user. The HTTP port is 9080 and the URL of the admin console is http://...:9060/ibm/console. New containers should be created with the following options: -p 9060:9060 -p 9080:9080.

    To see the WebSphere server logs, use the following command (requires Docker 1.3):

    docker exec container_id tail -F /var/was/logs/server1/SystemOut.log
  • Docker assigns a new hostname to every newly created container. This is a problem because the serverindex.xml file in the configuration of the WebSphere profile contains the hostname. That is to say that WebSphere implicitly assumes that the hostname is static and not expected to change after the profile has been created. To overcome this problem the Dockerfile adds a script called to the image. That script is executed before the server is started and (among other things) updates the hostnames in serverindex.xml when necessary.

  • Docker expects the RUN command to run the server process in the foreground (instead of allowing it to detach) and to gracefully stop the server when receiving a TERM signal. WebSphere's command doesn't meet these requirements. This issue is solved by using the -script option, which tells to generate a launch script instead of starting the server. This launch script has the desired properties and is used by the RUN command. This has an additional benefit: the command itself takes a significant amount of time (it's a Java process that reads the configuration and then starts a separate process for the actual WebSphere server) and skipping it reduces the startup time.

    There is however a problem with this approach. The content of the launch script generated by depends on the server configuration, in particular the JVM settings specified in server.xml. When they change, the launch script needs to be regenerated. This can be easily detected and the script added by the Dockerfile is designed to take care of this.

    The RUN command is a script that first runs and then executes the launch script. In addition to that, is also executed once during the image creation. This will speed up the first start of a new container created from that image, not only because the launch script will already exist, but also because the very first execution of the script typically takes much longer to complete.