About the Application Lifecycle with Oracle WebLogic Server for OKE

Learn about deploying and managing applications for a domain that was created with Oracle WebLogic Server for OKE.

A common practice is to create separate Oracle WebLogic Server domains to support development, testing, and production. A traditional development workflow typically includes the following tasks:

1. Update the development domain, including patches, data sources, and applications.
2. Apply the same changes to the test domain. You might use a combination of OPatch, the WebLogic Server administration console, and the WebLogic Scripting Tool (WLST).
3. After testing, apply the same changes to the production domain using the same tools.

Oracle WebLogic Server for OKE promotes a different workflow based on the principles of Continuous Integration and Continuous Delivery (CI/CD).

When you create a Model in Image domain with Oracle WebLogic Server for OKE, all the files required to run the domain in Kubernetes (binaries, patches, configuration, applications, and so on) are stored in the container image for the Model in Image domain. If you want to change the domain, you must update the container image. Any temporary changes you make to the running domain will be lost if you restart the pods in the Kubernetes cluster.

When you create a domain on a Persistent Volume (PV) with Oracle WebLogic Server for OKE, all the binary files required to run the domain in Kubernetes (binaries, patches) are stored in the container image for your PV domain. The domain configuration (applications, and so on) are stored on the persistent volume. If you want to change the binaries, you must update the container image. Any changes you make to the domain configuration using tools such as the WebLogic Server Administration Console, WLST script, and so on, are stored on PV. Therefore, the domain configuration will be persisted if you restart the pods in the Kubernetes cluster.

Oracle WebLogic Server for OKE deploys Jenkins to the Kubernetes cluster along with the domain, and configures a sample project in Jenkins to implement the recommended development workflow. This workflow includes the following tasks:

1. Updating the domain image with applications, resources, libraries, WebLogic patches, and JDK updates.
2. Building a test domain with the updated domain image, and then validating the test domain.
3. Applying the updated domain image to replace the current domain, and then validating the domain.
4. If applying the update domain image to the current running domain fails, then it automatically rolls back to the previous working domain image.

With this approach, you can easily share the latest domain with your entire development team, and also ensure that everyone uses a consistent configuration. You also don't need to manually replicate changes in different environments, such as testing and production.

You can customize the sample Jenkins project to meet your specific CI/CD requirements.