Registering and updating WebSphere Application Server Liberty servers in containers
You can register WebSphere® Application Server Liberty servers that are running inside containers with WebSphere Automation, and update the images when vulnerabilities are detected.
About this task
When the server in question is running inside a container, the process for registering and updating the server is different than when the server is not inside a container. Instructions are presented for registering a WebSphere Application Server Liberty server in a built image, and for updating the image to resolve vulnerabilities.
Steps for configuring and deploying an image for registration
Steps for updating an image to resolve vulnerabilities
(Optional) Create the project structure
- Create a directory for the WebSphere Application Server Liberty server
image.
mkdir <project-name> cd <project-name>
For example,
mkdir wsdemo cd wsdemo
- Create the server.xml file for the configuration for the WebSphere Application Server Liberty server.
touch server.xml
- Create the file for the usage metering certificate for the target WebSphere Automation instance.
touch wsacert.pem
- Create the
Dockerfile
for building the image:touch Dockerfile
Copy the WebSphere Automation configuration
- Log in to WebSphere Automation.
For more information, see Accessing the WebSphere Automation UI.
- Open the Server management page.
- Click Register server.
- In the Register server pane, select WebSphere Libertyand click Next.
- Click Copy to clipboard for the usage metering certificate. Click Next.
- In the image project directory, open the wsacert.pem file that you created and paste in the text that you copied. Save the changes to the wsacert.pem file.
- Click Copy to clipboard for the server.xml file. Click Done.
- In the image project directory, open the server.xml file that you created and paste the text that you copied. Save the changes to the server.xml file.
Create the keystore
The WebSphere Application Server Liberty server configuration in the server.xml file contains a keyStore element that references a key.p12 file. Run the following command to create this key.p12 file and import the certificate that was copied into the wsacert.pem file.
keytool -alias wsa-usage-metering -import -trustcacerts -file wsacert.pem -keystore key.p12 -storetype PKCS12 -storepass changeMe -noprompt
Alternately, WebSphere Automation can now create the keystore file for you.
Edit the Dockerfile
FROM websphere-liberty:<liberty-version>-kernel-java8-ibmjava
# Add config
COPY --chown=1001:0 server.xml /config/
COPY --chown=1001:0 key.p12 /opt/ibm/wlp/usr/servers/defaultServer/resources/security/
# Default setting for the verbose option
ARG VERBOSE=false
# This script will add the requested XML snippets, grow image to be fit-for-purpose and apply interim fixes
RUN configure.sh
The <liberty-version>
variable is
the version of WebSphere Application Server Liberty that you want to use as the base for
the image, for example, 23.0.0.5
. Using older version numbers as the base for the
image might cause vulnerabilities to be detected on the server when it is registered with WebSphere Automation. The server.xml and
key.p12 files that you created are copied into the image when it is built.Build and publish the image
Build the image, tag it, and push it to a container repository.
-
Build and tag the image.
docker build -t <project-name>/<image-name>:<image-version> .
For example,
docker build -t wsademo/liberty-demo-image:23.0.0.5 .
An image is generated in the local container registry. For the example, the local container registry is called
wsademo/liberty-demo-image
and the is23.0.0.5
. -
Run the following command to push the image to a private container registry. You can tag it with the registry hostname and port by using the
<registry-hostname>
and<registry-port>
parameters. Use the relevant values for the private container registry.docker tag <project-name>/<image-name>:<image-version> <registry-hostname>:<registry-port>/<project-name>/<image-name>:<image-version>
For example,
docker tag wsademo/liberty-demo-image:23.0.0.5 <registry-hostname>:<registry-port>/wsademo/liberty-demo-image:23.0.0.5
-
Push the image to the container registry, replacing
<registry-hostname>
and<registry-port>
with the relevant values for the target container registry.The container registry that the image is pushed to must be accessible from the orchestration environment that is being used to run the Liberty container.
docker push <registry-hostname>:<registry-port>/<project-name>/<image-name>:<image-version>
For example,
docker push <registry-hostname>:<registry-port>/wsademo/liberty-demo-image:23.0.0.5
(Optional) Install a Liberty operator
- In the Red Hat OpenShift Container Platform console, expand Operators in the navigation menu and click OperatorHub.
- Type
liberty
into the Filter field, then click select a Liberty operator. - In the pane, click Install.
- On the Install Operator page, accept the defaults, and click Install.
- Confirm that the operator is installed.
(Optional) Deploy the WebSphere Application Server Liberty image
- Log in to the Red Hat OpenShift Container Platform console.
- In the Red Hat OpenShift Container Platform console, expand Operators in the navigation menu and click Installed Operators.
- In the Project menu, select the namespace where WebSphere Automation is deployed, then select a Liberty operator from the list.
- On the Operator details page, click Create instance in the Liberty application tile.
- In the Name field, enter the value for the
<project-name>
variable (for example,wsademo
). In the Application Image field, enter the details of the image, in the following format:<registry-hostname>:<registry-port>/<project-name>/<image-name>:<image-tag>
For example,
<registry-hostname>:<registry-port>/wsademo/liberty-demo-image:23.0.0.5
- Expand the Environment Variables section and click Add Environment Variable.
- In the Name field, type
CONTAINER_HOST
. In the Value field, type the value for<project-name>
(for example,wsademo
).Note: The CONTAINER_HOST environment variable specifies the hostname that is reported by the usage metering component when it registers the WebSphere Application Server Liberty server with WebSphere Automation. If this environment variable is not set, a unique hostname is generated for each instance of the container that is running, causing them to appear as separate servers in WebSphere Automation. - Click Create.
- The instance is created and appears in the Red Hat OpenShift Container Platform console.
- To confirm that the pod for the application is started, expand Workloads
in the navigation menu and click Pods. Find the
<project-name>
pod (for example,wsademo
) in the list of pods and confirm that it has a status of Running.
Confirm that the server is registered with WebSphere Automation
To confirm that the WebSphere Application Server Liberty server is registered with WebSphere Automation, log in to the WebSphere Automation UI and view the server inventory.
Updating a WebSphere Application Server Liberty image
The process of updating servers that are running in a container is different than the process of updating servers that are running in a virtual machine (VM) or a physical server. When the server is running in container, modify the definition of the image in the Dockerfile, rebuild the image, and deploy the updated image to the runtime environment.
- To apply fixes, modify the definition of the image in the Dockerfile.
Use one of the following methods to modify the definition of the image in the Dockerfile.
- Use a later version of WebSphere Application Server Liberty that includes the needed
fix as the base for your image.
To use a later version, modify the
FROM
command in the Dockerfile to use a higher value for<liberty-version>
than previously used.FROM websphere-liberty:<liberty-version>-kernel-java8-ibmjava
- Download an interim fix and build it into the image.
Add a
COPY
command (after the existingCOPY
commands) to copy the interim fix into the image.# Add interim fixes COPY --chown=1001:0 <interim-fix-filename>.jar /opt/ibm/fixes/
- Use a later version of WebSphere Application Server Liberty that includes the needed
fix as the base for your image.
- Follow the instructions for Build and publish the image.
Update the value for the image version.
- (Optional) Modify the operator with the new version of the image. This step is required only if
you are not using your own pre-existing Liberty image.
- In the Red Hat OpenShift Container Platform console, expand Operators in the navigation menu and click Installed Operators.
- Select the namespace where the Liberty image is deployed, then select the associated operator from the list.
- In the application tab, click the
<project name>
(for example,wsademo
). - In the details page, click the YAML tab.
- Edit the operator YAML file and change the value of the
spec.applicationImage parameter
to:
<registry-hostname>:<registry-port>/<project-name>/<image-name>:<new-image-tag>
For example,
<registry-hostname>:<registry-port>/wsademo/liberty-demo-image:<new-image-tag>
- Verify that the new instance of the
<project-name>
(for example,wsademo
) pod is created.You can see the new instance in the Red Hat OpenShift Container Platform console by expanding Workloads in the navigation menu and click Pods. If it is not immediately visible, it is possible that it is not yet created. After the status of the new instance of the image is Running, the previous instance is deleted.
- Confirm that the WebSphere Application Server Liberty server is updated in the WebSphere Automation UI, and that any vulnerabilities are resolved.