The content of the WebSphere Liberty Docker images currently match the runtime install zips that we make available for download from WASdev.net. One consequence of this is that none of them contain the admin center. Adding it is very simple though as the following Dockerfile shows:
RUN mkdir -p /config/configDropins/overrides/ \
&& echo '<server>\
<quickstartsecurity userName="wsadmin" userPassword="wsadmin"></quickstartsecurity>\
</server>' > /config/configDropins/overrides/adminCenter.xml \
&& installUtility install --acceptLicense defaultServer
This Dockerfile adds a snippet of server XML under the configDropins directory that adds the
adminCenter-1.0 feature. It then uses
installUtility to install that feature. The admin center requires a user registry to be defined for authentication and here we use the
quickStartSecurity stanza to define a wsadmin user. We’ll come back to
remoteFileAccess in a moment.
We can then build and run this image as follows:
docker build -t admin .
docker run --name admin -dP admin
docker logs --tail=all -f admin
Once the server has started you should then be able to access
/adminCenter on the HTTPS port return by
docker port admin 9443 using the credentials defined in the Dockerfile.
If you then click on the Explore icon in the toolbox you’ll find information about any applications that are (or are not) deployed to the server, the server configuration, and server-level metrics. The last of these may be of particular interest when trying to determine suitable resource constraints for a container.
In a single-server, it’s not currently possible to deploy an application via the admin center. For a simple application you could just place it in the
dropins directory but, for argument’s sake, let’s say that we need to provide some extra configuration. I’m going to assume that you have ferret-1.2.war in the current directory. We then copy the file in to the container:
docker cp ferret-1.2.war admin:/config/apps
In the admin center, we then navigate to Configure > server.xml, click Add child under the Server element, select Application and click Add. Fill in the location as ferret-1.2.war and the context root as ferret then click Save. It is the
remoteFileAccess stanza that we added to the server configuration that allows us to edit the server configuration on the fly.
If you return to the applications tab you should see the application deployed and you can now access the ferret application at
Obviously modifying the server configuration in a running container is at odds with the idea of an immutable server but it may still be of use at development time or for making non-functional updates e.g. to the trace enabled for a server.