Model in Image

This sample demonstrates how to use the WebLogic Kubernetes Operator (hereafter “the operator”) to set up a WebLogic Server (WLS) cluster on the Azure Kubernetes Service (AKS) using the model in image domain home source type. After going through the steps, your WLS domain runs on an AKS cluster instance and you can manage your WLS domain by interacting with the operator.

Contents

Prerequisites

This sample assumes the following prerequisite environment.

  • If you don’t have an Azure subscription, create a free account before you begin.
    • It’s recommended that the Azure identity you use to sign in and complete this article has either the Owner role in the current subscription or the Contributor and User Access Administrator roles in the current subscription.
    • If your identity has very limited role assignments, ensure you have Contributor role and User Access Administrator role in the resource group that runs the AKS cluster. This requires asking a privileged user to assign the roles before creating resources in the resource group.
  • Operating System: GNU/Linux, macOS (Intel only, Apple Silicon not supported) WSL2 for Windows 10.
  • Git; use git --version to test if git works. This document was tested with version 2.25.1.
  • Azure CLI; use az --version to test if az works. This document was tested with version 2.58.0.
  • Docker for Desktop. This document was tested with Docker version 20.10.7
  • kubectl; use kubectl version to test if kubectl works. This document was tested with version v1.21.2.
  • Helm, version 3.1 and later; use helm version to check the helm version. This document was tested with version v3.6.2.
  • A Java JDK, Version 8 or 11. Azure recommends Microsoft Build of OpenJDK. Ensure that your JAVA_HOME environment variable is set correctly in the shells in which you run the commands.
  • Ensure that you have the zip/unzip utility installed; use zip/unzip -v to test if zip/unzip works.

Prepare parameters

Set parameters.

# Change these parameters as needed for your own environment
export ORACLE_SSO_EMAIL=<replace with your oracle account email>
export ORACLE_SSO_PASSWORD="<replace with your oracle password.>"

# Used to generate resource names.
export TIMESTAMP=`date +%s`
export ACR_NAME="acr${TIMESTAMP}"
export AKS_CLUSTER_NAME="aks${TIMESTAMP}"
export AKS_PERS_RESOURCE_GROUP="resourcegroup${TIMESTAMP}"
export AKS_PERS_LOCATION=eastus

export WEBLOGIC_USERNAME=weblogic
export WEBLOGIC_PASSWORD=Secret123456
export WEBLOGIC_WDT_PASSWORD=Secret123456

export BASE_DIR=~
Oracle Container Registry

You will need an Oracle account. The following steps will direct you to accept the license agreement for WebLogic Server. Make note of your Oracle Account password and email. This sample pertains to 12.2.1.4, but other versions may work as well.

  • In a web browser, navigate to https://container-registry.oracle.com and log in using the Oracle Single Sign-On authentication service. If you do not already have SSO credentials, at the top of the page, click the Sign In link to create them.
  • The Oracle Container Registry provides a WebLogic 12.2.1.4 General Availability (GA) installation image that is used in this sample.
  • NOTE: General Availability (GA) images are suitable for demonstration and development purposes only where the environments are not available from the public Internet; they are not acceptable for production use. In production, you should always use CPU (patched) images from the OCR or create your images using the WebLogic Image Tool (WIT) with the --recommendedPatches option. For more guidance, see Apply the Latest Patches and Updates in Securing a Production Environment for Oracle WebLogic Server.
  • Ensure that Docker is running. Find and then pull the WebLogic 12.2.1.4 installation image: 
    $ docker login container-registry.oracle.com -u ${ORACLE_SSO_EMAIL} -p ${ORACLE_SSO_PASSWORD}
$ docker pull container-registry.oracle.com/middleware/weblogic:12.2.1.4

If you have problems accessing the Oracle Container Registry, you can build your own images from the Oracle GitHub repository.

Download the WebLogic Kubernetes Operator sample.

Download the WebLogic Kubernetes Operator sample ZIP file. We will use several scripts in this zip file to create a WebLogic domain. This sample was tested with v4.1.8, but should work with the latest release.

$ cd $BASE_DIR
$ mkdir sample-scripts
$ curl -m 120 -fL https://github.com/oracle/weblogic-kubernetes-operator/releases/download/v4.1.8/sample-scripts.zip \
      -o ${BASE_DIR}/sample-scripts/sample-scripts.zip
$ unzip ${BASE_DIR}/sample-scripts/sample-scripts.zip -d ${BASE_DIR}/sample-scripts

Create Resource Group

$ az extension add --name resource-graph
$ az group create --name $AKS_PERS_RESOURCE_GROUP --location $AKS_PERS_LOCATION

Create the AKS cluster

This sample doesn’t enable application routing. If you want to enable application routing, follow Managed nginx Ingress with the application routing add-on in AKS.

Run the following commands to create the AKS cluster instance.

$ az aks create \
   --resource-group $AKS_PERS_RESOURCE_GROUP \
   --name $AKS_CLUSTER_NAME \
   --node-count 2 \
   --generate-ssh-keys \
   --nodepool-name nodepool1 \
   --node-vm-size Standard_DS2_v2 \
   --location $AKS_PERS_LOCATION \
   --enable-managed-identity

Successful output will be a JSON object with the entry "type": "Microsoft.ContainerService/ManagedClusters".

After the deployment finishes, run the following command to connect to the AKS cluster. This command updates your local ~/.kube/config so that subsequent kubectl commands interact with the named AKS cluster.

$ az aks get-credentials --resource-group $AKS_PERS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME

Successful output will look similar to:

Merged "wlsaks1596087429" as current context in /home/username/.kube/config

After your Kubernetes cluster is up and running, run the following commands to make sure kubectl can access the Kubernetes cluster:

$ kubectl get nodes -o wide

Successful output will look like the following.

NAME                                STATUS   ROLES   AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
aks-nodepool1-15679926-vmss000000   Ready    agent   118s   v1.25.6   10.224.0.4    <none>        Ubuntu 22.04.2 LTS   5.15.0-1041-azure   containerd://1.7.1+azure-1
aks-nodepool1-15679926-vmss000001   Ready    agent   2m8s   v1.25.6   10.224.0.5    <none>        Ubuntu 22.04.2 LTS   5.15.0-1041-azure   containerd://1.7.1+azure-1

NOTE: If you run into VM size failure, see Troubleshooting - Virtual Machine size is not supported.

Install WebLogic Kubernetes Operator

The WebLogic Kubernetes Operator is an adapter to integrate WebLogic Server and Kubernetes, allowing Kubernetes to serve as a container infrastructure hosting WLS instances. The operator runs as a Kubernetes Pod and stands ready to perform actions related to running WLS on Kubernetes.

Create a namespace and service account for the operator.

$ kubectl create namespace sample-weblogic-operator-ns

namespace/sample-weblogic-operator-ns created

$ kubectl create serviceaccount -n sample-weblogic-operator-ns sample-weblogic-operator-sa

serviceaccount/sample-weblogic-operator-sa created

Validate the service account was created with this command.

$ kubectl -n sample-weblogic-operator-ns get serviceaccount

NAME                          SECRETS   AGE
default                       1         9m24s
sample-weblogic-operator-sa   1         9m5s

Install the operator. The operator’s Helm chart is located in the kubernetes/charts/weblogic-operator directory. This sample installs the operator using Helm charts from Github. It may take you several minutes to install the operator.

$ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update

Update the repo to get the latest Helm charts. It is a best practice to do this every time before installing a new operator version. In this example, we are using a pinned version, but you may also find success if you use the latest version. In this case, you can omit the --version argument. Be warned that these instructions have only been tested with the exact version shown.

$ helm repo update
$ helm install weblogic-operator weblogic-operator/weblogic-operator \
  --namespace sample-weblogic-operator-ns \
  --version 4.1.8 \
  --set serviceAccount=sample-weblogic-operator-sa \
  --wait

The output will show something similar to the following:

NAME: weblogic-operator
LAST DEPLOYED: Fri Aug 12 14:28:47 2022
NAMESPACE: sample-weblogic-operator-ns
STATUS: deployed
REVISION: 1
TEST SUITE: None

If you wish to use a more recent version of the operator, replace the 4.1.8 in the preceding command with the other version number. To see the list of versions, visit the GitHub releases page.

Verify the operator with the following commands; the status will be Running.

$ helm list -A

NAME                    NAMESPACE                       REVISION        UPDATED                                 STATUS CHART                    APP VERSION
weblogic-operator       sample-weblogic-operator-ns     1               2023-05-15 10:31:05.1890341 +0800 CST   deployeweblogic-operator-4.1.8  4.1.8

$ kubectl get pods -n sample-weblogic-operator-ns

NAME                                         READY   STATUS    RESTARTS   AGE
weblogic-operator-54b5c8df46-g4rcm           1/1     Running   0          86s
weblogic-operator-webhook-6c5885f69f-pd8qw   1/1     Running   0          86s

You can specify the operator image by changing value of --set image. If you run into failures, see Troubleshooting - WebLogic Kubernetes Operator installation failure.

If you have an image built with domain models following Model in Image, you can go to Create WebLogic domain directly.

Create Docker image

Image creation prerequisites

  • The JAVA_HOME environment variable must be set and must reference a valid JDK 8 or 11 installation.

  • Copy the sample to a new directory; for example, use the directory /tmp/mii-sample. In the directory name, mii is short for “model in image”. Model in image is one of three domain home source types supported by the operator. To learn more, see Choose a domain home source type.

    $ mkdir /tmp/mii-sample

    $ cp -r $BASE_DIR/sample-scripts/create-weblogic-domain/wdt-artifacts/* /tmp/mii-sample

    Save the model file directory.

    $ export WDT_MODEL_FILES_PATH=/tmp/mii-sample/wdt-model-files

    NOTE: We will refer to this working copy of the sample as /tmp/mii-sample; however, you can use a different location.

  • Download the latest WebLogic Deploying Tooling (WDT) and WebLogic Image Tool (WIT) installer ZIP files to your ${WDT_MODEL_FILES_PATH} directory. Both WDT and WIT are required to create your Model in Image images.

    $ curl -m 120 -fL https://github.com/oracle/weblogic-deploy-tooling/releases/latest/download/weblogic-deploy.zip \
 -o ${WDT_MODEL_FILES_PATH}/weblogic-deploy.zip

    $ curl -m 120 -fL https://github.com/oracle/weblogic-image-tool/releases/latest/download/imagetool.zip \
  -o ${WDT_MODEL_FILES_PATH}/imagetool.zip

  • Set up the WebLogic Image Tool, run the following commands:

    $ unzip ${WDT_MODEL_FILES_PATH}/imagetool.zip -d ${WDT_MODEL_FILES_PATH}

    $ ${WDT_MODEL_FILES_PATH}/imagetool/bin/imagetool.sh cache deleteEntry --key wdt_latest

    $ ${WDT_MODEL_FILES_PATH}/imagetool/bin/imagetool.sh cache addInstaller \
  --type wdt \
  --version latest \
  --path ${WDT_MODEL_FILES_PATH}/weblogic-deploy.zip

    These steps will install WIT to the ${WDT_MODEL_FILES_PATH}/imagetool directory, plus put a wdt_latest entry in the tool’s cache which points to the WDT ZIP file installer. You will use WIT later in the sample for creating model images.

Image creation - Introduction

The goal of image creation is to demonstrate using the WebLogic Image Tool to create an image tagged as model-in-image:WLS-v1 from files that you will stage to /tmp/mii-sample/wdt-model-files/WLS-v1/. The staged files will contain a web application in a WDT archive, and WDT model configuration for a WebLogic Administration Server called admin-server and a WebLogic cluster called cluster-1.

A “Model in Image” image contains the following elements:

  • A WebLogic Server installation (including operating system and JDK) and a WebLogic Deploy Tooling installation in its /u01/wdt/weblogic-deploy directory.
  • If you have WDT model archive files, then the image must also contain these files in its /u01/wdt/models directory.
  • If you have WDT model YAML file and properties files, then they go in in the same /u01/wdt/models directory. If you do not specify a WDT model YAML file in your /u01/wdt/models directory, then the model YAML file must be supplied dynamically using a Kubernetes ConfigMap that is referenced by your Domain spec.model.configMap field.

We provide an example of using a model ConfigMap later in this sample.

The following sections contain the steps for creating the image model-in-image:WLS-v1.

Understanding your first archive

The sample includes a predefined archive directory in /tmp/mii-sample/archives/archive-v1 that you will use to create an archive ZIP file for the image.

The archive top directory, named wlsdeploy, contains a directory named applications, which includes an ‘exploded’ sample JSP web application in the directory, myapp-v1. Three useful aspects to remember about WDT archives are:

  • A model image can contain multiple WDT archives.
  • WDT archives can contain multiple applications, libraries, and other components.
  • WDT archives have a well defined directory structure, which always has wlsdeploy as the top directory.

The application displays important details about the WebLogic Server instance that it’s running on: namely its domain name, cluster name, and server name, as well as the names of any data sources that are targeted to the server.

Staging a ZIP file of the archive

When you create the image, you will use the files in the staging directory, ${WDT_MODEL_FILES_PATH}/WLS-v1. In preparation, you need it to contain a ZIP file of the WDT application archive.

Run the following commands to create your application archive ZIP file and put it in the expected directory:

# Delete existing archive.zip in case we have an old leftover version
$ rm -f ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip

Create a ZIP file of the archive in the location that we will use when we run the WebLogic Image Tool.

$ cd /tmp/mii-sample/archives/archive-v1
$ zip -r ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip wlsdeploy
Staging model files

In this step, you explore the staged WDT model YAML file and properties in the ${WDT_MODEL_FILES_PATH}/WLS-v1 directory. The model in this directory references the web application in your archive, configures a WebLogic Server Administration Server, and configures a WebLogic cluster. It consists of only two files, model.10.properties, a file with a single property, and, model.10.yaml, a YAML file with your WebLogic configuration.

Here is the WLS model.10.properties:

CLUSTER_SIZE=5

Here is the WLS model.10.yaml:

domainInfo:
    AdminUserName: '@@SECRET:__weblogic-credentials__:username@@'
    AdminPassword: '@@SECRET:__weblogic-credentials__:password@@'
    ServerStartMode: 'prod'

topology:
    Name: '@@ENV:CUSTOM_DOMAIN_NAME@@'
    AdminServerName: 'admin-server'
    Cluster:
        'cluster-1':
            DynamicServers:
                ServerTemplate:  'cluster-1-template'
                ServerNamePrefix: 'managed-server'
                DynamicClusterSize: '@@PROP:CLUSTER_SIZE@@'
                MaxDynamicClusterSize: '@@PROP:CLUSTER_SIZE@@'
                MinDynamicClusterSize: '0'
                CalculatedListenPorts: false
    Server:
        'admin-server':
            ListenPort: 7001
    ServerTemplate:
        'cluster-1-template':
            Cluster: 'cluster-1'
            ListenPort: 8001

appDeployments:
    Application:
        myapp:
            SourcePath: 'wlsdeploy/applications/myapp-v1'
            ModuleType: ear
            Target: 'cluster-1'

The model file:

  • Defines a WebLogic domain with:

    • Cluster cluster-1
    • Administration Server admin-server
    • An EAR application, targeted to cluster-1, located in the WDT archive ZIP file at wlsdeploy/applications/myapp-v1

  • Leverages macros to inject external values:

    • The property file CLUSTER_SIZE property is referenced in the model YAML file DynamicClusterSize and MaxDynamicClusterSize fields using a PROP macro.
    • The model file domain name is injected using a custom environment variable named CUSTOM_DOMAIN_NAME using an ENV macro.
      • You set this environment variable later in this sample using an env field in its Domain.
      • This conveniently provides a simple way to deploy multiple differently named domains using the same model image.
    • The model file administrator user name and password are set using a weblogic-credentials secret macro reference to the WebLogic credential secret.
      • This secret is in turn referenced using the webLogicCredentialsSecret field in the Domain.
      • The weblogic-credentials is a reserved name that always dereferences to the owning Domain actual WebLogic credentials secret name.

A Model in Image image can contain multiple properties files, archive ZIP files, and YAML files but in this sample you use just one of each. For a complete description of Model in Images model file naming conventions, file loading order, and macro syntax, see Model files files in the Model in Image user documentation.

Creating the image with WIT

At this point, you have staged all of the files needed for the image model-in-image:WLS-v1; they include:

  • /tmp/mii-sample/wdt-model-files/weblogic-deploy.zip
  • /tmp/mii-sample/wdt-model-files/WLS-v1/model.10.yaml
  • /tmp/mii-sample/wdt-model-files/WLS-v1/model.10.properties
  • /tmp/mii-sample/wdt-model-files/WLS-v1/archive.zip

If you don’t see the weblogic-deploy.zip file, then you missed a step in the prerequisites.

Now, you use the Image Tool to create an image named model-in-image:WLS-v1 with a FROM clause that references a base WebLogic image. You’ve already set up this tool during the prerequisite steps.

Run the following commands to create the model image and verify that it worked:

$ ${WDT_MODEL_FILES_PATH}/imagetool/bin/imagetool.sh update \
  --tag model-in-image:WLS-v1 \
  --fromImage container-registry.oracle.com/middleware/weblogic:12.2.1.4 \
  --wdtModel      ${WDT_MODEL_FILES_PATH}/WLS-v1/model.10.yaml \
  --wdtVariables  ${WDT_MODEL_FILES_PATH}/WLS-v1/model.10.properties \
  --wdtArchive    ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip \
  --wdtModelOnly \
  --wdtDomainType WLS \
  --chown oracle:root

If you don’t see the imagetool directory, then you missed a step in the prerequisites.

The preceding command runs the WebLogic Image Tool in its Model in Image mode, and does the following:

  • Builds the final image as a layer on the container-registry.oracle.com/middleware/weblogic:12.2.1.4 base image.
  • Copies the WDT ZIP file that’s referenced in the WIT cache into the image.
    • Note that you cached WDT in WIT using the keyword latest when you set up the cache during the sample prerequisites steps.
    • This lets WIT implicitly assume it’s the desired WDT version and removes the need to pass a -wdtVersion flag.
  • Copies the specified WDT model, properties, and application archives to image location /u01/wdt/models.

When the command succeeds, you should see output like the following:

[INFO   ] Build successful. Build time=36s. Image tag=model-in-image:WLS-v1

Verify the image is available in the local Docker server with the following command.

$ docker images | grep WLS-v1

model-in-image          WLS-v1   012d3bfa3536   5 days ago      1.13GB

You may run into a Dockerfile parsing error if your Docker buildkit is enabled, see Troubleshooting - WebLogic Image Tool failure.

Pushing the image to Azure Container Registry

AKS can pull images from any container registry, but the easiest integration is to use Azure Container Registry (ACR). In addition to simplicity, using ACR simplifies high availability and disaster recovery with features such as geo-replication. For more information, see Geo-replication in Azure Container Registry. In this section, we will create a new Azure Container Registry, connect it to our pre-existing AKS cluster and push the image built in the preceding section to it. For complete details, see Azure Container Registry documentation.

Let’s create an instance of ACR in the same resource group we used for AKS. We will use the environment variables used during the steps above. For simplicity, we use the resource group name as the name of the ACR instance.

$ az acr create --resource-group $AKS_PERS_RESOURCE_GROUP --name $ACR_NAME --sku Basic --admin-enabled true

Closely examine the JSON output from this command. Save the value of the loginServer property aside. It will look something like the following.

"loginServer": "contosoresourcegroup1610068510.azurecr.io",

Use this value to sign in to the ACR instance. Note that because you are signing in with the az cli, you do not need a password because your identity is already conveyed by having done az login previously.

$ export LOGIN_SERVER=$(az acr show -n $ACR_NAME --resource-group $AKS_PERS_RESOURCE_GROUP --query "loginServer" -o tsv)

$ az acr login --name $LOGIN_SERVER

Successful output will include Login Succeeded.

Ensure Docker is running on your local machine. Run the following commands to tag and push the image to your ACR.

$ docker tag model-in-image:WLS-v1 $LOGIN_SERVER/model-in-image-aks:1.0

$ docker push $LOGIN_SERVER/model-in-image-aks:1.0

The push refers to repository [contosorgresourcegroup1610068510.azurecr.io/model-in-image-aks]
1.0: digest: sha256:208217afe336053e4c524caeea1a415ccc9cc73b206ee58175d0acc5a3eeddd9 size: 2415

Finally, connect AKS to the ACR. For more details on connecting ACR to an existing AKS, see Configure ACR integration for existing AKS clusters.

$ export ACR_ID=$(az acr show -n $ACR_NAME --resource-group $AKS_PERS_RESOURCE_GROUP --query "id" -o tsv)
$ az aks update --name $AKS_CLUSTER_NAME --resource-group $AKS_PERS_RESOURCE_GROUP --attach-acr $ACR_ID

Successful output will be a JSON object with the entry "type": "Microsoft.ContainerService/ManagedClusters".

If you see an error that seems related to you not being an Owner on this subscription, please refer to the troubleshooting section Cannot attach ACR due to not being Owner of subscription.

Create WebLogic domain

In this section, you will deploy the new image to the namespace sample-domain1-ns, including the following steps:

  • Create a namespace for the WebLogic domain.
  • Upgrade the operator to manage the WebLogic domain namespace.
  • Create a secret containing your WebLogic administrator user name and password.
  • Create a secret containing your Model in Image runtime encryption password:
    • All Model in Image domains must supply a runtime encryption Secret with a password value.
    • The runtime encryption password is used to encrypt configuration that is passed around internally by the operator.
    • The value must be kept private but can be arbitrary; you can optionally supply a different secret value every time you restart the domain.
  • Deploy a domain YAML file that references the new image.
  • Wait for the domain’s pods to start and reach their ready state.
Namespace

Create a namespace that can host one or more domains:

$ kubectl create namespace sample-domain1-ns

Label the domain namespace so that the operator can autodetect and create WebLogic Server pods. Without this step, the operator cannot see the namespace.

$ kubectl label namespace sample-domain1-ns weblogic-operator=enabled
Kubernetes Secrets for WebLogic

First, create the secrets needed by the WLS type model domain. For more on secrets in the context of running domains, see Prepare to run a domain. In this case, you have two secrets.

Run the following kubectl commands to deploy the required secrets:

$ kubectl -n sample-domain1-ns create secret generic \
  sample-domain1-weblogic-credentials \
   --from-literal=username="${WEBLOGIC_USERNAME}" \
   --from-literal=password="${WEBLOGIC_PASSWORD}"

$ kubectl -n sample-domain1-ns label  secret \
  sample-domain1-weblogic-credentials \
  weblogic.domainUID=sample-domain1

$ kubectl -n sample-domain1-ns create secret generic \
  sample-domain1-runtime-encryption-secret \
   --from-literal=password="${WEBLOGIC_WDT_PASSWORD}"

$ kubectl -n sample-domain1-ns label  secret \
  sample-domain1-runtime-encryption-secret \
  weblogic.domainUID=sample-domain1

Some important details about these secrets:

  • Make sure to enclose your values in double quotes and perform the necessary escaping to prevent the shell from modifying the values before the secret values are set.

  • Choosing passwords and user names:

    • Set the variables WEBLOGIC_USERNAME and WEBLOGIC_PASSWORD with a user name and password of your choice. The password should be at least eight characters long and include at least one digit. Remember what you specified. These credentials may be needed again later.
    • Set the variable WEBLOGIC_WDT_PASSWORD with a password of your choice.

  • The WebLogic credentials secret:

    • It is required and must contain username and password fields.
    • It must be referenced by the spec.webLogicCredentialsSecret field in your Domain resource YAML file. For complete details about the Domain resource, see the Domain resource reference.
    • It also must be referenced by macros in the domainInfo.AdminUserName and domainInfo.AdminPassWord fields in your model.10.yaml file.

  • The Model WDT runtime encrytion secret:

    • This is a special secret required by Model in Image.
    • It must contain a password field.
    • It must be referenced using the spec.model.runtimeEncryptionSecret field in your Domain resource YAML file.
    • It must remain the same for as long as the domain is deployed to Kubernetes but can be changed between deployments.
    • It is used to encrypt data as it’s internally passed using log files from the domain’s introspector job and on to its WebLogic Server pods.

  • Deleting and recreating the secrets:

    • You must delete a secret before creating it, otherwise the create command will fail if the secret already exists.
    • This allows you to change the secret when using the kubectl create secret command.

  • You name and label secrets using their associated domainUID for two reasons:

    • To make it obvious which secrets belong to which domains.
    • To make it easier to clean up a domain. Typical cleanup scripts use the weblogic.domainUID label as a convenience for finding all resources associated with a domain.
Domain resource

Now, you create a domain YAML file. Think of the domain YAML file as the way to configure some aspects of your WebLogic domain using Kubernetes. The operator uses the Kubernetes “custom resource” feature to define a Kubernetes resource type called Domain. For more on the Domain Kubernetes resource, see Domain Resource. For more on custom resources see the Kubernetes documentation.

We provide a sample file at $BASE_DIR/sample-scripts/create-weblogic-domain/model-in-image/domain-resources/WLS-LEGACY/mii-initial-d1-WLS-LEGACY-v1.yaml, copy it to a file called /tmp/mii-sample/mii-initial.yaml.

$ cp $BASE_DIR/sample-scripts/create-weblogic-domain/model-in-image/domain-resources/WLS-LEGACY/mii-initial-d1-WLS-LEGACY-v1.yaml /tmp/mii-sample/mii-initial.yaml

Print the image path. Copy the output to your clipboard and paste it to value of spec.image in /tmp/mii-sample/mii-initial.yaml.

echo $LOGIN_SERVER/model-in-image-aks:1.0

Modify the Domain YAML with your values.

Name in YAML file Example value Notes
spec.image $LOGIN_SERVER/model-in-image-aks:1.0 Must be the same as the value to which you pushed the image to by running the command docker push $LOGIN_SERVER/model-in-image-aks:1.0.

Run the following command to create the domain custom resource:

$ kubectl apply -f /tmp/mii-sample/mii-initial.yaml

Successful output will look like:

domain.weblogic.oracle/sample-domain1 created
cluster.weblogic.oracle/sample-domain1-cluster-1 created

Verify the WebLogic Server pods are all running:

$ kubectl get pods -n sample-domain1-ns --watch

Output will look similar to the following.

NAME                                READY   STATUS              RESTARTS   AGE
sample-domain1-introspector-xwpbn   0/1     ContainerCreating   0          0s
sample-domain1-introspector-xwpbn   1/1     Running             0          1s
sample-domain1-introspector-xwpbn   0/1     Completed           0          66s
sample-domain1-introspector-xwpbn   0/1     Terminating         0          67s
sample-domain1-introspector-xwpbn   0/1     Terminating         0          67s
sample-domain1-admin-server         0/1     Pending             0          0s
sample-domain1-admin-server         0/1     Pending             0          0s
sample-domain1-admin-server         0/1     ContainerCreating   0          0s
sample-domain1-admin-server         0/1     Running             0          2s
sample-domain1-admin-server         1/1     Running             0          42s
sample-domain1-managed-server1      0/1     Pending             0          0s
sample-domain1-managed-server1      0/1     Pending             0          0s
sample-domain1-managed-server1      0/1     ContainerCreating   0          0s
sample-domain1-managed-server2      0/1     Pending             0          0s
sample-domain1-managed-server2      0/1     Pending             0          0s
sample-domain1-managed-server2      0/1     ContainerCreating   0          0s
sample-domain1-managed-server2      0/1     Running             0          3s
sample-domain1-managed-server2      1/1     Running             0          40s
sample-domain1-managed-server1      0/1     Running             0          53s
sample-domain1-managed-server1      1/1     Running             0          93s

When the system stabilizes with the following state, it is safe to proceed.

NAME                             READY   STATUS    RESTARTS   AGE
sample-domain1-admin-server      1/1     Running   0          2m
sample-domain1-managed-server1   1/1     Running   0          83s
sample-domain1-managed-server2   1/1     Running   0          83s

It may take you up to 10 minutes to deploy all pods, please wait and make sure everything is ready.

If the system does not reach this state, troubleshoot and resolve the problem before continuing. See Troubleshooting for hints.

Invoke the web application

Create Azure load balancer

Create the Azure public standard load balancer to access the WebLogic Server Administration Console and applications deployed in the cluster.

Use the configuration file in $BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/model-in-image/admin-lb.yaml to create a load balancer service for the Administration Server. If you are choosing not to use the predefined YAML file and instead created a new one with customized values, then substitute the following content with you domain values.

Click here to view YAML content.

Use the configuration file in $BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/model-in-image/cluster-lb.yaml to create a load balancer service for the managed servers. If you are choosing not to use the predefined YAML file and instead created new one with customized values, then substitute the following content with you domain values.

Click here to view YAML content.

Create the load balancer services using the following command:

$ kubectl apply -f $BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/model-in-image/admin-lb.yaml

service/sample-domain1-admin-server-external-lb created

$ kubectl  apply -f $BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/model-in-image/cluster-lb.yaml

service/sample-domain1-cluster-1-external-lb created

Get the external IP addresses of the Administration Server and cluster load balancers (please wait for the external IP addresses to be assigned):

$ kubectl get svc -n sample-domain1-ns --watch

NAME                                      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
sample-domain1-admin-server               ClusterIP      None           <none>           7001/TCP         8m33s
sample-domain1-admin-server-external-lb   LoadBalancer   10.0.184.118   52.191.234.149   7001:30655/TCP   2m30s
sample-domain1-cluster-1-lb               LoadBalancer   10.0.76.7      52.191.235.71    8001:30439/TCP   2m25s
sample-domain1-cluster-cluster-1          ClusterIP      10.0.118.225   <none>           8001/TCP         7m53s
sample-domain1-managed-server1            ClusterIP      None           <none>           8001/TCP         7m53s
sample-domain1-managed-server2            ClusterIP      None           <none>           8001/TCP         7m52s

In the example, the URL to access the Administration Server is: http://52.191.234.149:7001/console. The expected username and password must match the values that you chose during the Kubernetes Secrets for WebLogic step.

IMPORTANT: You must ensure that any Network Security Group rules that govern access to the console allow inbound traffic on port 7001.

If the WLS Administration Console is still not available, use kubectl describe domain to check domain status.

$ kubectl describe domain domain1

Make sure the status of cluster-1 is ServersReady and Available.

Click here to view the example domain status.
Access the application

Access the Administration Console using the admin load balancer IP address.

$ ADMIN_SERVER_IP=$(kubectl -n sample-domain1-ns get svc sample-domain1-admin-server-external-lb -o=jsonpath='{.status.loadBalancer.ingress\[0\].ip}')
$ echo "Administration Console Address: http://${ADMIN_SERVER_IP}:7001/console/"

Access the sample application using the cluster load balancer IP address.

## Access the sample application using the cluster load balancer IP.
$ CLUSTER_IP=$(kubectl -n sample-domain1-ns get svc sample-domain1-cluster-1-lb -o=jsonpath='{.status.loadBalancer.ingress\[0\].ip}')

$ curl http://${CLUSTER_IP}:8001/myapp_war/index.jsp

<html><body><pre>
*****************************************************************

Hello World! This is version 'v1' of the sample JSP web-app.

Welcome to WebLogic Server 'managed-server1'!

  domain UID  = 'sample-domain1'
  domain name = 'domain1'

Found 1 local cluster runtime:
  Cluster 'cluster-1'

Found min threads constraint runtime named 'SampleMinThreads' with configured count: 1

Found max threads constraint runtime named 'SampleMaxThreads' with configured count: 10

Found 0 local data sources:

*****************************************************************
</pre></body></html>

Rolling updates

Naturally, you will want to deploy newer versions of the EAR application, located in the WDT archive ZIP file at wlsdeploy/applications/myapp-v1. To learn how to do this, follow the steps in Update 3.

Database connection

For guidance on how to connect a database to your AKS with WebLogic Server application, see Deploy a Java application with WebLogic Server on an Azure Kubernetes Service (AKS) cluster.

Clean up resources

Run the following commands to clean up resources.

$ az group delete --yes --no-wait --name $AKS_PERS_RESOURCE_GROUP

Troubleshooting

For troubleshooting advice, see Troubleshooting.