Restarting JVM servers within containers

Depending on how we are running the containers (locally or through a managed orchestration tool), you need understand how to restart applications, such as the WebSphere Application Server or Liberty Server. Each running Docker container usually runs one foreground process only. When the process ends, the container stops. Here is an example of the processes running in the Transaction server Docker container

[root@txn /]# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  15068  3060 ?        Ss   17:14   0:00 /bin/bash /SETUP/bin/entrypoint.sh
root       173  0.0  0.0  15200  3328 ?        Ss   17:14   0:00 bash
root       214 95.7  6.9 3445684 1146952 ?     Sl   17:15   2:15 /opt/WebSphere/AppServer/java/8.0/bin/java -Dosgi.install.area=/opt/WebSphere/AppServer -Dosgi.configuration.area=/opt/We
root       290  0.0  0.0   7756   740 ?        S    17:15   0:00 tail -F /opt/WebSphere/AppServer/profiles/default/logs/server1/trace.log --pid 214 -n +0
root       430  0.0  0.0  50876  3684 ?        R+   17:18   0:00 ps aux

The pid=1 is running /SETUP/bin/entrypoint.sh since WebSphere Application Server cannot be a foreground process. In some scenarios, after you configure settings or apply any changes directly on the running container, we might need to restart the WebSphere Application Server that is running inside the Transaction server Docker container, or the Liberty servers inside the Search, Store, and Customization Docker containers. To restart the WebSphere Application Server or Liberty server, we cannot use the traditional stop/start scripts. We need to restart the entire container. For example,

docker restart <container_name>

Or, if you use Docker Compose,

docker-compose restart <service>

This is a valid approach for a local Docker environment where our Docker images are not removed from your system. We can restart the containers and you do not lose data or configurations.

However, when you implement advanced Docker orchestration tools (such as Marathon or Kubernetes), the container and its configurations are lost when a container is garbage collected (along with your configurations). Orchestration tools deploy new containers from the base image. Therefore, to properly ensure that you do not lose your configurations or customizations, IBM recommends that you build new base Docker images to include the changes. See Building custom Docker images based on customization packages.