Choose an approach
Let’s review what we have discussed and talk about when we might want to use various approaches. We can start by asking ourselves questions like these:
-
Can you make the desired change with a configuration override or Model in Image ConfigMap?
When your domain home source type is Domain in PV or Domain in Image, the operator allows you to inject a number of configuration overrides into your pods before starting any servers in the domain.
When your domain home source type is Model in Image, you can inject model updates before starting any servers in the domain for any type of update, or even while your domain is running for most types of updates. Model in Image runtime model updates are propagated by restarting (rolling) the running WebLogic Servers.
A good example of a change would be changing the settings for a data source. For example, you may wish to have a larger connection pool in your production environment than you do in your development/test environments. You probably also want to have different credentials. You may want to change the service name, and so on. All of these kinds of updates can be made with configuration overrides for Domain in PV and Domain in Image, and with model updates for Model in Image. These are placed in a Kubernetes ConfigMap, meaning that they are outside of the image, so they do not require rebuilding the image. If all of your changes fit into this category, it is probably much better to just use configuration overrides for Domain in PV and Domain in Image, and use model updates for Model in Image.
-
Are you only changing the WebLogic configuration, for example, deploying or updating an application, changing a resource configuration in a way that is not supported by configuration overrides, Model in Image model updates, and such?
If your changes fit into this category, and you have used the “domain-in-image” approach and the image layering model, then you only need to update the top layer of your image. This is relatively easy compared to making changes in lower layers. You could create a new layer with the changes, or you could rebuild/replace the existing top layer with a new one. Which approach you choose depends mainly on whether you need to maintain the same domain encryption keys or not.
-
Do you need to be able to do a rolling restart?
If you need to do a rolling restart with Domain in Image, for example, to maintain the availability of your applications, then you need to make sure that a new domain layer has the same domain encryption keys. You cannot perform a rolling restart of a domain if the new members have a different encryption key.
If you need to do a rolling restart with Model in Image or Domain in PV, the domain encryption keys are not a concern. In Model in Image, the keys are generated by the operator at runtime before the first WebLogic Server pod is started. In Domain in PV, the keys are generated once, the first time the domain is started, and remain in the domain home within the PV.
-
Do you need to mutate something in a lower layer, for example, patch WebLogic, the JDK, or Linux?
If you need to make an update in a lower layer, then you will need to rebuild that layer and all of the layers above it. This means that you will need to rebuild the domain layer. In the case of Domain in Image, you will need to determine if you need to keep the same domain encryption keys.
The following diagram summarizes these concerns in a decision tree for the “domain-in-image” case:
If you are using the “domain-on-PV” or “model-in-image” approach, many of these concerns become moot because you have an effective separation between your domain and the image. There is still the possibility that an update in the image could affect your domain; for example, if you updated the JDK, you may need to update some of your domain scripts to reflect the new JDK path.
However, in this scenario, your environment is much closer to what you are probably used to in a traditional (non-Kubernetes) environment, and you will probably find that all of the practices you used from that pre-Kubernetes environment are directly applicable here too, with just some small modifications. For example, applying a WebLogic patch would now involve building a new image.