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:
|
1 2 3 4 5 6 7 8 |
FROM websphere-liberty:webProfile7 RUN mkdir -p /config/configDropins/overrides/ \ && echo '<server>\ <featuremanager><feature>adminCenter-1.0</feature></featuremanager>\ <quickstartsecurity userName="wsadmin" userPassword="wsadmin"></quickstartsecurity>\ <remotefileaccess><writedir>${server.config.dir}</writedir></remotefileaccess>\ </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:
|
1 2 3 |
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:
|
1 |
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 /ferret!
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.