WASdev / ci.docker.websphere-traditional

Dockerfiles for WebSphere Application Server traditional
Apache License 2.0
171 stars 192 forks source link

Server fails initialization on running container after calling configure.sh during build #233

Closed druegamer-protel closed 3 years ago

druegamer-protel commented 3 years ago

I am getting trouble when attempting to run the container after setting up a configured image. When I run a base image, like as follows, the server starts fine:

docker run --name Websphere-Test -p 9043:9043 -p 9443:9443 -d ibmcom/websphere-traditional:latest

However, if I extend the image to setup a configuration as described on the wiki the server fails initialization when starting a container. I am also getting some error during the build process, though I'm not sure if it's related. The Dockerfile looks as follows:

FROM ibmcom/websphere-traditional:latest
ENV ENABLE_BASIC_LOGGING=true
COPY --chown=was:root users.py /work/config/users.py
RUN /work/configure.sh

And my configuration script (users.py) looks as follows:

AdminTask.createUser('[-uid admin -password admin -cn admin -sn admin]')
AdminTask.createUser('[-uid standard -password standard -cn standard -sn standard]')
AdminConfig.save()

And the output of building the image looks as follows:

Sending build context to Docker daemon  19.41MB
Step 1/4 : FROM ibmcom/websphere-traditional:latest
 ---> 57b42bad54c1
Step 2/4 : ENV ENABLE_BASIC_LOGGING=true
 ---> Running in dfd4da376560
Removing intermediate container dfd4da376560
 ---> 615b25f3aea9
Step 3/4 : COPY --chown=was:root users.py /work/config/users.py
 ---> 01107e816b1d
Step 4/4 : RUN /work/configure.sh
 ---> Running in f0a3e1a3cd79
Setting Password
Starting server ...................
ADMU0116I: Tool information is being logged in file
           /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/startServer.log
ADMU0128I: Starting tool with the AppSrv01 profile
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 430
Applying configuration
+ Found config-files under /work/config. Executing...
Stopping server ...................
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.bundledata.2': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.lazy.2': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.manager/.fileTable.6': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.manager/.fileTable.7': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.state.2': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.bundledata.2': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.lazy.2': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.manager/.fileTable.6': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.manager/.fileTable.7': No such file or directory
find: '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/.state.2': No such file or directory
Removing intermediate container f0a3e1a3cd79
 ---> 2712b18dcc9a
Successfully built 2712b18dcc9a
Successfully tagged websphere-test-image:latest

I've found that, in general, if I run the /work/configure.sh script at all in the Dockerfile (even with no config files) than I get those 'find' errors and any container I spawn from the resultant image results in a failed server initialization.

Am I missing a configuration step? Or perhaps this is an environment issue, though I doubt it. I'm running on centos7 using docker version 20.10.2.

scottkurz commented 3 years ago

(EDIT: Updating my suggestion.)

It seems the instructions you followed may require you to supply a was-config.props file via:

COPY --chown=was:root was-config.props /work/config/

before running:

RUN /work/configure.sh

I suppose you could use the simple, "helloworld" sample set from: https://github.com/WASdev/ci.docker.websphere-traditional/blob/master/samples/hello-world/was-config.props if you're not sure what to put there.

Ideally the doc should probably have some guidance on the minimal requirements.

OTHER OBSERVATION

On another note, interestingly enough I tried running without the properties file but running the script individually instead of running "all at once" (and there's only one here I know).

RUN /work/configure.sh /work/config/users.py

and it seemed to work around the problem.

druegamer-protel commented 3 years ago

I appreciate the response! Unfortunately the couple of things you suggested to try didn't resolve my issue.

However, your mention of running it on win10 made me figure I'd try throwing up docker on my win machine. I tried building and running a container in the same manner I tried in my original post, and lo and behold the image was built and the container ran with no issues.

So, I wiped my docker setup on my centos7 machine and rebuilt my image as I did originally (prompting a redownload of the base image), ran a container, and it worked just fine.

My guess is the image download got corrupted which was causing the issue, which is frustrating but happens I suppose. Mostly glad to have figured it out.

Again, appreciate the response @scottkurz. I don't think I would have prompted to even go down that path without it.

scottkurz commented 3 years ago

Ahh... I'd thought I had a newer base image but mine was from May 2020 or so... I guess the issue's been fixed in newer versions. Thanks for the update @druegamer-protel and glad to help.