This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
Tips of applying changes to WCS v9 runtime environment
Qiu Bin Duan 3100026AMD | 0 Comments | 3,732 Views
The way of applying changes(code or configuration) in WebSphere Commerce runtime environment becomes quite different in v9 after we dockernized all the servers. Due to the nature of docker or orchestration tools, your changes may get lost. Therefore, we need to choose the right approach to apply the changes based on differences scenarios, this doc aims at providing some guidelines.
The first question to ask is that, is this temporary change or permanent change ? Are we going to deploy it to production environment or lower environments(dev, qa etc).
Assuming that we are going to make temporary changes in lower environment before move them to production environment, typical scenarios include:
All of above requires the updates to either the application or the JVM in a running container. Let us firstly take a look at the changes to the application, basically, it involves copying files from your local Docker host into the running containers, there are 2 methods: 1. By using 'docker cp' command, 2. By using a Docker volume driver to mount the local file into the target Docker container.
For the details of the procedure, there is a guide in the Knowledge Center.
Regarding the changes to the WAS/Liberty JVM in a running container, they could be basically divides into 3 categories:
After the changes, it normally requires JVM restart. 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 more details, check this link
Now, let us talk about other scenario which is to apply permanent changes(code or configuration) to the production environment. Assuming we have verified the changes in lower environment and decided to move them. The right way is to build custom Docker images that include your custom code or custom configurations, and then share and deploy the new images. You could check out below knowledge center doc:
To build your custom images, it requires to create a dockerfile for each type of Docker image. In the dockerfile, you could include the custom code package or the configuration changes. We highly recommend you check out the tutorial to choose the best approach.
Above tutorial covers 3 approaches of including the customization logic.
Now with the custom images ready, they could be deployed to your production runtime environment. In case you are using Kubernetes or IBM Cloud Private, you may find below article interesting
Or if you happen to use DC/OS platform, please check this out.