Supported tags and respective
Where to get help:
the WASdev community
Where to file issues:
the IBM WASdev Community
Published image artifact details:
(image metadata, transfer size, etc)
Supported Docker versions:
the latest release (down to 1.6 on a best-effort basis)
The images in this repository contain IBM WebSphere Application Server Liberty for Developers and the IBM Java Runtime Environment. See the license section below for restrictions relating to the use of this image. For more information about WebSphere Application Server Liberty, see the WASdev site.
There are multiple images available in this repository. The image with the tag
beta contains the contents of the install archive for the latest monthly beta. The other images are all based on the latest generally available fix pack.
kernel image contains just the Liberty kernel and no additional runtime features. This image can be used as the basis for custom built images that contain only the features required for a specific application. For example, the following Dockerfile starts with this image, copies in the
server.xml that lists the features required by the application, and then uses the
installUtility command to download those features from the online repository.
FROM websphere-liberty:kernel COPY server.xml /config/ RUN installUtility install --acceptLicense defaultServer
webProfile6 image contains the features required for Java EE6 Web Profile compliance. It also pulls in additional features to bring the contents in to line with the features available for download by using the runtime JAR, most notably the features required for OSGi applications.
webProfile7 image contains the features required for Java EE7 Web Profile compliance. The
javaee7 image extends this image and adds the features required for Java EE7 Full Platform compliance. The
javaee7 image is also tagged with
javaee7 images all also contain a common set of features that are expected to be of use for a typical production scenario. These features are:
The images are designed to support a number of different usage patterns. The following examples are based on the Java EE7 Liberty application deployment sample and assume that DefaultServletEngine.zip has been extracted to
/tmp and the
server.xml updated to accept HTTP connections from outside of the container by adding the following element inside the
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
Each image contains a default server configuration that specifies the corresponding features and exposes ports 9080 and 9443 for HTTP and HTTPS respectively. A .WAR file can therefore be mounted in the
dropinsdirectory of this server and run. The following example starts a container in the background running a .WAR file from the host file system with the HTTP and HTTPS ports mapped to 80 and 443 respectively.
$ docker run -d -p 80:9080 -p 443:9443 \ -v /tmp/DefaultServletEngine/dropins/Sample1.war:/config/dropins/Sample1.war \ websphere-liberty:webProfile7
When the server is started, you can browse to http://localhost/Sample1/SimpleServlet on the Docker host.
Note: If you are using the boot2docker virtual machine on OS X or Windows, you need to get the IP of the virtual host by using the command
boot2docker ipinstead of by using localhost.
For greater flexibility over configuration, it is possible to mount an entire server configuration directory from the host and then specify the server name as a parameter to the run command. Note: This particular example server configuration provides only HTTP access.
$ docker run -d -p 80:9080 \ -v /tmp/DefaultServletEngine:/config \ websphere-liberty:webProfile7
You can also build an application layer on top of this image by using either the default server configuration or a new server configuration. In this example, we have copied the
/tmp/DefaultServletEngine/dropinsto the same directory as the following Dockerfile.
FROM websphere-liberty:webProfile7 ADD Sample1.war /config/dropins/
This can then be built and run as follows:
$ docker build -t app . $ docker run -d -p 80:9080 -p 443:9443 app
You can mount a data volume container that contains the application and the server configuration on to the image. This has the benefit that it has no dependency on files from the host but still allows the application container to be easily re-mounted on a newer version of the application server image. This example assumes that you have copied the
/tmp/DefaultServletEnginedirectory in to the same directory as the Dockerfile.
Build and run the data volume container:
FROM websphere-liberty:webProfile7 ADD DefaultServletEngine /config
$ docker build -t app-image . $ docker run -d -v /config \ --name app app-image true
Run the WebSphere Liberty image with the volumes from the data volume container mounted:
$ docker run -d -p 80:9080 \ --volumes-from app websphere-liberty:webProfile7
Using IBM JRE Class data sharing
The IBM JRE provides a feature Class data sharing which offers transparent and dynamic sharing of data between multiple Java Virtual Machines running on the same host by using shared memory backed by a file. When running the Liberty Docker image, it looks for the file at
/opt/ibm/wlp/output/.classCache. To benefit from Class data sharing, this location needs to be shared between containers either through the host or a data volume container.
Taking the application image from example 3 above, containers can share the host file location (containing the shared cache)
/tmp/websphere-liberty/classCache as follows:
docker run -d -p 80:9080 -p 443:9443 \ -v /tmp/websphere-liberty/classCache:/opt/ibm/wlp/output/.classCache app
Or, create a named data volume container that exposes a volume at the location of the shared file:
docker run -e LICENSE=accept -v /opt/ibm/wlp/output/.classCache \ --name classcache websphere-liberty true
Then, run the WebSphere Liberty image with the volumes from the data volume container classcache mounted as follows:
docker run -d -p 80:9080 -p 443:9443 --volumes-from classcache app
Running WebSphere Liberty in read-only mode
Liberty writes to two different directories when running:
/logs. In order to run the Liberty image in read-only mode these may be mounted as temporary file systems. If using the provided image, the keystore will be generated on initial start up in the server configuration. This means that the server configuration directory either needs to be read-write or the keystore will need to be built into the image. In the example command
/config is mounted as a read-write volume.
docker run -d -p 80:9080 -p 443:9443 \ --tmpfs /opt/ibm/wlp/output --tmpfs /logs -v /config --read-only \ websphere-liberty:javaee7
The base Ubuntu image does not include additional language packs. To use an alternative locale, build your own image that installs the required language pack and then sets the
LANG environment variable. For example, the following Dockerfile starts with the
websphere-liberty:webProfile7 image, installs the Portuguese language pack, and sets Brazilian Portuguese as the default locale:
FROM websphere-liberty:webProfile7 RUN apt-get update \ && apt-get install -y language-pack-pt-base \ && rm -rf /var/lib/apt/lists/* ENV LANG pt_BR.UTF-8
The Dockerfiles and associated scripts are licensed under the Apache License 2.0.
Licenses for the products installed within the images are as follows:
- IBM JRE (International License Agreement for Non-Warranted Programs)
- IBM WebSphere Application Server in the non-beta images (International License Agreement for Non-Warranted Programs)
- IBM WebSphere Application Server Liberty Beta in the
betaimage (International License Agreement for Early Release of Programs)
Note: These licenses do not permit further distribution and that the terms for WebSphere Application Server in the non-beta images restrict usage to a developer machine or build server only, or subject to a maximum 2 gigabyte heap usage across all instances. Instructions are available to enable entitled customers to upgrade the Docker Hub image for production use or build their own production licensed image.
If you plan on using the default port of 9080 you should specify the defaultHttpEndpoint in the config. If you don't do this it will create a new endpoint and both endpoints will compete for port 9080. If the default endpoint wins, it will bind port 9080 on localhost ONLY and you won't be able to connect. e.g.
[INFO ] CWWKO0219I: TCP Channel defaultHttpEndpoint has been started and is now listening for requests on host localhost (IPv4: 127.0.0.1) port 9080.
[ERROR ] CWWKO0221E: TCP Channel httpEndpoint-136 initialization did not succeed. The socket bind did not succeed for host * and port 9080. The port might already be in use.
Instead of doing this as suggested in the docs above:
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
Do this instead:
<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="-1"/>
Or use a different port.
How can I get version 220.127.116.11 or 18.104.22.168 in Docker?
How to deploy an ear file?
We had to remove the keystore section in server.xml for our cacerts client ssl certificates to work.
Error looked like this
[ERROR ] CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN CN=xxxxxxx was sent from the target host. The signer might need to be added to local trust store /opt/ibm/wlp/output/defaultServer/resources/security/key.jks, located in SSL configuration alias defaultSSLConfig. The extended error message from the SSL handshake exception is: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by xxxxxx is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
The answer was staring me in the face the whole time - as the article says you need to have this in your server.xml (specifically host="*" ). You just need to change this in the server.xml in the DefaultServletEngine.zip file.
<httpEndpoint host="*" httpPort="9080" httpsPort="-1"/>
I can't get the second option to work (the one where you mount the entire server directory). I get ERR_CONNECTION_RESET when I try from localhost, and ERR_CONNECTION_REFUSED when I try from a remote host.
If I run it without the -d, I can see in the console output that the server starts OK and the application deploys, I just can't see it in the browser.
This is the exact configuration we need in our development environments so I would like to get this working if possible...:-) Any tips?
@icordoba - the first and second options given in the usage section don't require you to rebuild an image when the application changes. If you use the (free) WebSphere Developer Tools they also have support working directly with an application inside a running container.
is it possible to update the app deployed in a Docker Liberty to avoid having to re-build the full image every time the application changes? Thanks.
For the benefit of others, @adityai's issue was not having host="*" in server.xml so the server was not accepting requests from outside of the container.
@cleue - it was a temporary issue with the repository. Now resolved.