First, is all of this really necessary to run this app under Liberty? 

Manual deployment of Web Administration Tool in WebSphere Liberty Profile

Next, I'm working on a Dockerfile to replicate these steps, and while I have it at least kind-of working (I haven't run in a location that can actually reach any of our directory servers yet), there are some errors logged and unexpected requirements I'd like to ask about.

(And, of course, it would be great if IBM could provide a Docker image for this and own the setup to make sure it's correct & optimal!)

Attaching my current Dockerfile. 

Some notes and observations and questions:

1. The provided server.xml only uses 3 features, but the installation of the custom portlet one requires 2 others, which themselves install newer features than the ones server.xml uses.

CWWKF1011E: The feature com.ibm.websphere.appserver.portlet-2.1 depends on com.ibm.websphere.appserver.jsp-2.3 which is not installed.
CWWKF1011E: The feature com.ibm.websphere.appserver.portlet-2.1 depends on com.ibm.websphere.appserver.webCache-1.0 which is not installed.

2. Upon starting a container, the following error is logged, but the application seems to be working otherwise. Is JAXB actually needed?

[ERROR   ] CWWKE0702E: Could not resolve module: com.ibm.ws.portletcontainer [107]
Unresolved requirement: Import-Package: javax.xml.bind

3. Upon hitting the application in a browser, the following is logged

[err] Can't load log handler "com.ibm.ldap.utils.TDSFileHandler"
[err] java.lang.ClassNotFoundException: com.ibm.ldap.utils.TDSFileHandler

Despite using the provided jvm.options that does point to the IDSLogging.jar file that I confirm is in the expected location in the running container.

4. I haven't yet tried to containerize the SSL setup instructions. Would welcome some guidance on that.

5. I could also use some guidance on how to externalize the application's settings so we don't lose like the admin login and configured LDAP servers when new containers spin up.

------------------------------
Doug Breaux
Kyndryl
------------------------------

Attachment(s)

Dockerfile.txt   1 KB 1 version

On item 5, well, that's fun. It looks the servers you add get put in:

/opt/ibm/wlp/usr/servers/defaultServer/apps/IDSWebApp.war/WEB-INF/classes/IDSConfig/IDSServersConfig/IDSServersInfo.xml

Could mount that as a volume. I wonder if you have to start with a valid seed file ...

What else under .../IDSConfig would have to be externalized?

Hopefully not any additional locations?

I worked around the logging warning by adding a custom logging.properties to my image, with: 

handlers= java.util.logging.ConsoleHandler

Which is what I want in a container anyway.

Although I'd still like to know why the TDS logger isn't found. And what additional logging benefit might available with that logger.

Hi Doug,

It looks like you are trying to containerize the ISVD 10.0.3 Web Admin Tool. Just to let you know that a Web Admin Tool Container available. Please refer: https://www.ibm.com/docs/en/svd/10.0.3?topic=images-verify-directory-web-administration-tool 

I'd also suggest you to open a case with IBM so that the support/dev teams can review your observations and questions and respond to you.

-Ram.

------------------------------
Ramamohan Reddy
------------------------------

Thank you! Yes, that's what I wanted but could not find.

Noting that your link added the period on the end, which doesn't work. This does:

https://www.ibm.com/docs/en/svd/10.0.3?topic=images-verify-directory-web-administration-tool 

------------------------------
Doug Breaux
Software Engineer
Kyndryl
------------------------------

I have fixed the link my update as well. Thanks.

- Ram.

A few observations:

Persistence

The Web Administration Tool container is stateless and does not store any persistent data.

But presumably what we'd really need to "persist" is the server configuration and like admin password. Which looks like we can put in YAML config file and/or environment variables. Which is a good thing we can use both, because some of the data would be valid for like a k8s ConfigMap, but some should be instead a Secret. 

Next, this requires a license key, which I didn't have to specify when manually copying the jar and artifacts from the idstools location on our installation. I'm trying to find the appropriate key ...

Next, I don't so far see a way to specify the admin password. It's not in https://www.ibm.com/docs/en/svd/10.0.3?topic=specification-verify-directory-web-administration-tool 

The Web Admin Image link points to https://www.ibm.com/docs/en/svd/10.0.3?topic=configuration-format, but that describes elements that appear to only be valid for the ISVD server itself, not for the Web Admin tool.

------------------------------
Doug Breaux
Software Engineer
Kyndryl
------------------------------