Visit the Portal https://aka.ms/publicportal.
In the search box, without pressing enter, type “weblogic” without the quotes.
In the section of suggested results labeled Marketplace, select Oracle WebLogic Server on Azure Kubernetes Service.
Select Create.
In Resource group select Create new. In the dialog that appears, enter the next number to the sequence number you entered in setup.sh, followed by the date in mmdd syntax, followed by a brief identifier, such as ol or wls. For example, if you entered ejb01, you would enter ejb020317wls.
In Region enter West Europe.
Leave Username for WebLogic Administrator with the default value.
For Password for WebLogic Administrator and following password fields use javaLandMar2022.
Read warning box. This is why we had you create the UAMI and assign it the necessary roles.
Select the +Add control.
In the sidebar, select the UAMI created by script. It should be something like ejb010317u.
In the sidebar, select Add. This should dismiss the sidebar and cause the warning box to disappear.
If the UAMI you created is not appearing, sign out of the Portal, sign back in and try again.
On Optional Basic Configuration select No and examine the options. Note you can specify Java JVM options here.
Select Yes to close the Optional Basic Configuration.
Scroll down and note the hyperlinks in the Report issues, get help, and share feedback section. The links will open in a new tab. We especially encourage you to take the survey about Java EE usage. this will help us create better Java EE on Azure offers.
Select Next: Configure AKS cluster.
Explore the options available, but do not select any of the following.
In Image selection leave the values at the defaults.
In Username for Oracle Single Sign-On authentication and the corresponding password field, use the values provided by the instructor in the Etherpad.
In Is the specified SSO account associated with an active Oracle support contract?, select No.
IMPORTANT This offer really should only be used with an active Oracle support contract. Without a support contract, you are running software that has not been patched against the latest security vulnerabilities, including the infamous Log4shell. For complete details see the Oracle documentation.
Thankfully, for this workshop, we are also deploying Azure App Gateway, and the offer sets up OWASP rules to protect against some of the vulnerabilities.
In the Select desired combination of WebLogic… drop down, leave the default, but explore the other available options.
In the Java EE Application section, ensure Yes is selected.
Select the Browse button.
In the Storage accounts browser, select the storage account
created by the workflow you ran previously. It will be something
like wlsdsa19251229631.
In the Containers section, select the storage container
created by the workflow you ran previously. It will be something
like wlsdcon19251229631.
In the Container, select cargo-tracker.war. This also was generated by the workflow you ran previously.
Select Select.
Leave the remaining values at their defaults.
Select Next: TLS/SSL configuration.
This tab lets you configure end-to-end TLS connections. Explore the values, but leave it set at No.
Select Next: Networking.
Leave Standard Load Balancer service at No, but feel free to explore the documentation link.
In Application Gateway Ingress Controller select Yes.
The offer provides several ways to upload the certificates necessary to enable App Gateway integration. Select Generate a self-signed front-end certificate.
For Service Principal refer to the output from the setup.sh
script you ran at the beginning of the workshop. Find the value
for SERVICE_PRINCIPAL. Copy it to the clipboard. Be extremely
careful to get the whole value.
To verify you have it all, you can enter the following command in the Cloud Shell.
echo <paste> | base64 -d and press enter.
If you see valid JSON, you have captured the entire base64 string to the clipboard. Save the decoded value in your text file, in case you need it later.
Paste this value into the Service Principal and Confirm password fields.
Ensure Enable cookie based affinity is checked.
Leave the remaining values at their defaults.
Select Next: DNS configuration.
This tab lets you connect a DNS zone to your WLS on AKS. Explore the values, but leave it set at No.
Select Next: Database.
For Connect to database? select Yes.
For the Choose database type select Azure Database for PostgreSQL.
For JNDI name enter jdbc/CargoTrackerDB.
For Datasource Connection String enter jdbc:postgresql://<dbName>.postgres.database.azure.com:5432/postgres, where <dbName> is the value you captured above for database name. This will be something like wlsdb19251229631.
For Global transactions protocol Select EmulateTwoPhaseCommit.
For Database username enter weblogic. This value was set as a secret in setup.sh.
For Database Password enter Secret123!. This value was set as a secret in setup.sh. Make sure to get the exclamation point.
Select Next: Review + create.
DO NOT Select Create. At this point, we will use a GitHub Actions workflow to do the same thing that would happen if you deployed the offer as you have configured it here.
Visit your fork of https://github.com/edburns/javaland-javaee.
Select Actions.
Select Setup WLS on AKS.
Select Run workflow.
Select Run workflow.
Instructor will walk you through
.github/workflows/setupWlsAks.yml, which you have in your
repo. Briefly, this workflow uses the repository secrets you
created earlier to do the following.
Use the Bicep infrastructure as code that stands behind the Portal offer from the preceding section to build an ARM template.
Build up parameters that happen to represent the values you previously filled out in the Portal.
Build cargotracker and upload it to storage. Strictly speaking, this step is not necessary since the storage account already has the cargotracker war.
Deploy the offer. This eventually invokes the Azure support in WebLogic Kubernetes Operator.
Note The resource group name will be prefixed by wlsd-aks.
Self-guided. How to find resource groups in the Portal.
Visit the Portal.
Select Resource groups.
In the filter, enter the first three characters of the prefix
you used in setup.sh.
Select your resource group.
Self-guided. How to find outputs in a resource group.
In the pane under the Resource group name, in the Settings section, select Deployments.
Select the bottom most deployment in the list.
In the left pane, select Outputs.
Self-guided. Examine the outputs.
Execute shellCmdtoConnectAks to connect to the cluster in the Cloud Shell.
Take note of the name of the value of the --resource-group
option to the command. You will need this later. This really
should be in the outputs. You are welcome to fix
this.
Execute shellCmdtoOutputWlsDomainYaml to output a YAML
description of the WebLogic domain to the file domain.yml.
Examine the domain.yml file with help from the Oracle
documentation.
This is actually a Kubernetes Custom Resource Definition (CRD).
The complete reference of this CRD is generated live by Oracle.
See the reference documentation for complete
details.
For complete documentation about CRD, see the Kubernetes
site.
Execute shellCmdtoOutputWlsVersionsandPatches to output a text description of the runtime to a file version.info.
Examine the version.info. Look at the version of Servlet Container. If it is 4.0, know that your instructor lead the team that developed the specification and wrote some of the code in the implementation running now.
Obtain the URL of the cargotracker by looking at the value of the output clusterExternalUrl.
Visit the Cargo Tracker main URL.
Take note of the version number at the bottom of the page. It should be something like 2.1-SNAPSHOT 2022-03-02 23:08:32.
Visit your fork of https://github.com/edburns/javaland-javaee.
Select Actions.
Select Update Cargo Tracker to WLS on AKS.
Select Run workflow.
Use the correct region.
Leave weblogic image path at the default value.
For Specify resource group of aks cluster use the value you captured in the preceding step.
For storage account and container, use the values gathered above.
For the ACR related parameters, use the following steps to get them directly from the deployed ACR.
In a new portal tab, find the resource group containing the AKS cluster.
In the navigation pane for the resource group, select Overview.
In the Settings section, select Access keys.
Save aside the Login server. This value is the Specify ACR server of uploading image in the workflow.
Save aside the Registry name. This value is the Specify ACR server user name in the workflow.
Save aside the Password. This value is the AZURE_ACR_PASSWORD GitHub Actions repository secret.
In the Cloud Shell, type gh --repo <your github name>/javaland-javaee secret set AZURE_ACR_PASSWORD -b and paste the saved value.
Ensure there is no space after -b. Press enter.
Leave the remaining values at their defaults.
Select Run workflow.
The Cargo Tracker main URL is the clusterExternalUrl obtained in
the preceding step, followed by /cargo-tracker/.
Go to the Cargo Tracker main URL.
a. On the main page, select Public Tracking Interface in new window.
Enter ABC123 and select Track!
Observe what the next expected activity is.
b. On the main page, select Administration Interface, then, in the left navigation column select Live in a new window. This opens up a map view.
c. On the main page, select Mobile Event Logger. This opens up in a new, small, window.
d. Drop down the menu and select ABC123. Select Next.
e. Select the Location using the information in the next expected activity. Select Next.
f. Select the Event Type using the information in the next expected activity. Select Next.
g. Select the Voyage using the information in the next expected activity. Select Next.
h. Set the Completion Date a few days in the future. Select Next.
i. Review the information and verify it matches the next expected activity. If not, go back and fix it. If so, select Submit.
j. Back on the Public Tracking Interface select Tracking then enter ABC123 and select Track. Observe that a different. next expected activity is listed.
k. If desired, go back to Mobile Event Logger and continue performing the next activity.
You must remove the deployment to avoid consuming more Azure resources than your pass allows.
In Cloud Shell, enter az aks delete --no-wait --name <your cluster name> --resource-group <your resource group>.
In the Portal, find <your resource group> and select Delete resource group.
Copy past the name of the resource group and select Delete.