Restarting JVM servers within containers
Depending on how you are running your 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, you 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, you cannot use the traditional stop/start scripts. You 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 your Docker images are not removed from your system.
You can restart your 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, it is recommended that you build new base Docker images to include the changes. For more information, see Building a custom Docker image from a deployable package.