"Bring your own vnet" for Application Gateway on AKS offer

[galiacheng]

Current aks offer covers "Bring your own VNET" for AKS cluster by bringing existing AKS cluster, while it does not support "Bring your own VNET" for Application Gateway, this PR is to support VNET customization for Application Gateway.

Contents

• Requirements
• VNET scenarios that the offer will support after this PR is merged
• Test cases
• How to validate private access

Requirements

For quick start and quick validation

1. Run WLS on AKS and enable Application Gateway in new VNET that defined by aks offer, and expose the WLS cluster with public frontend IP.
2. Run WLS on AKS and enable Application Gateway in new VNET that defined by aks offer, and expose the WLS cluster with private frontend IP.

For enterprise workload migration/POC

4. Run WLS on AKS and enable Application Gateway in pre-defined VNET(s), and expose the WLS cluster with public frontend IP.
5. Run WLS on AKS and enable Application Gateway in pre-defined VNET(s), and expose the WLS cluster with private frontend IP.

Current offer supports R1, this pr will enable R2-R4.

VNET scenarios that the offer will support after this PR merged

Note: custom T3 is disabled from UI definition, customer is able to enable custom T3 with advanced deployment using the templates, so the diagrams include T3/T3s access to WebLogic Server.

AKS and Application Gateway are in the same VNET:

AKS and Application Gateway are in different VNET:

Test cases

1. New AKS and Application Gateway within new VNET that deployed by offer, expose WLS cluster with public IP address.
2. New AKS within new VNET that deployed by offer and Application Gateway within an existing VNET, expose WLS cluster with public IP address.
3. Existing AKS and Application Gateway within new VNET that deployed by offer, expose WLS cluster with public IP address.
4. Existing AKS and Application Gateway within the same VNET with AKS, expose WLS cluster with public IP address.
   • Deploy AKS cluster from Azure portal
   • In the VNET of AKS cluster, create a subnet(/24) for Application Gateway
   • Deploy the offer, select the existing AKS cluster, for Application Gateway, select the subnet inside the VNET of AKS cluster
5. Existing AKS and Application Gateway within different VNET of AKS, expose WLS cluster with public IP address.
   • Deploy AKS cluster from Azure portal
   • Deploy a VNET(/24) from Azure portal, and create a subnet(/24) for Application Gateway
   • Deploy the offer, select the existing AKS cluster, for Application Gateway, select above subnet
6. New AKS and Application Gateway within new VNET that deployed by offer, expose WLS cluster with private IP address.
7. New AKS within new VNET that deployed by offer and Application Gateway within an existing VNET, expose WLS cluster with private IP address.
8. Existing AKS and Application Gateway within new VNET that deployed by offer, expose WLS cluster with private IP address.
9. Existing AKS and Application Gateway within the same VNET with AKS, expose WLS cluster with private IP address.
10. Existing AKS and Application Gateway within different VNET of AKS, expose WLS cluster with private IP address.

Validating private access

The following steps are to validate the WLS cluster accessibility that is exposed to internal network using private IP. If you expose the cluster via public IP, just test it from your browser, need not follow the steps.

Deploy offer and enable application gateway with private frontend IP:

• Networking
  • Connect to Azure Application Gateway: Yes
  • Configure frontend IP with private IP address: Checked

Get deployment output: clusterExternalUrl (e.g. http://10.3.0.4/), the application url is ${clusterExternalUrl}testwebapp/ (e.g. http://10.3.0.4/testwebapp/)

There are two approaches to access the application: using kubectl exec or a jump box. You can choose one of them to test the feature.

Validate cluster accessibility from Admin Pod

• Connect AKS from terminal: az aks get-credentials --resource-group haiche-private-vnet-5 --name wlsonaks1ea3ptpccopio4
• Get admin pod:

$ kubectl get pod -n sample-domain1-ns
NAME                             READY   STATUS    RESTARTS   AGE
sample-domain1-admin-server      1/1     Running   0          16h
sample-domain1-managed-server1   1/1     Running   0          16h
sample-domain1-managed-server2   1/1     Running   0          16h

• Run kubectl exec to curl the application: kubectl exec -it <admin-pod-name> -n <wls-namespace> -- /bin/bash -c "${applicationUrl}"

 $ kubectl exec -it sample-domain1-admin-server -n sample-domain1-ns -- /bin/bash -c "curl http://10.3.0.4/testwebapp/"
<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

    <link rel="stylesheet" href="/testwebapp/res/styles.css;jsessionid=WLki_K2IHVkmUjOYaVh_AzCPAchlRqXVA_byQNir0Zo2KF_qCXBe!1626444911" type="text/css">
    <title>Test WebApp</title>
  </head>
  <body>


    <li>InetAddress: sample-domain1-managed-server2/10.244.1.8
    <li>InetAddress.hostname: sample-domain1-managed-server2

  </body>
</html>

Admin Pod and Application Gateway are in the same VNET (VNET peering), should be able to access Application Gateway Url.

Access WLS cluster with jump box

• Create a resource group from Azure Portal, with name e.g. haiche-jump-box
• Create a ubuntu machine from Azure portal
  • Basics
    • Region: in the same region with AKS
  • Networking, keep default values
• Create network peer between VNET of UBUNTU machine and Application Gateway
  • Get the VNET name of Application Gateway from the resource group that provisioned by the offer, the VNET name starts with wlsaks-vnet, e.g. wlsaks-vnet12345678
  • Open the VNET of UBUNTU machine in jump box resource group, and create network peering
    • Peer link name: input a name
    • Remote Peer link name: input a name
    • Virtual Network: select the VNET of Application Gateway that got in previous step, e.g. wlsaks-vnet12345678
    • Add
• After the peering is completed, the peer status should be connected.
• Restart UBUNTU machine to make peering available
• SSH to UBUNTU machine and curl the application url, e.g.

weblogic@testwlsaks:~$ curl http://10.3.0.4/testwebapp/ -v
*   Trying 10.3.0.4:80...
* TCP_NODELAY set
* Connected to 10.3.0.4 (10.3.0.4) port 80 (#0)
> GET /testwebapp/ HTTP/1.1
> Host: 10.3.0.4
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 02 Jun 2022 06:37:22 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 486
< Connection: keep-alive
< X-ORACLE-DMS-ECID: 425f30d6-02e1-439b-8402-57b7f051a685-00011b28
< X-ORACLE-DMS-RID: 0
< Set-Cookie: JSESSIONID=TggjIgsSP8X0NyWXgAUkCPQiaX71uFmksz9fYj9Amlyf00VD1u9k!-823443147; path=/; HttpOnly
<
<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

    <link rel="stylesheet" href="/testwebapp/res/styles.css;jsessionid=TggjIgsSP8X0NyWXgAUkCPQiaX71uFmksz9fYj9Amlyf00VD1u9k!-823443147" type="text/css">
    <title>Test WebApp</title>
  </head>
  <body>


    <li>InetAddress: sample-domain1-managed-server1/10.244.0.9
    <li>InetAddress.hostname: sample-domain1-managed-server1

  </body>
</html>
* Connection #0 to host 10.3.0.4 left intact

[galiacheng]

Offer for testing: https://portal.azure.com/#create/microsoft_javaeeonazure_test.20210525-arm-oraclelinux-wls-on-aks-preview20210525-arm-oraclelinux-wls-on-aks

[galiacheng]

Successful workflow: https://github.com/galiacheng/weblogic-azure/actions/runs/2427220946

[edburns]

I am not going to hold up the commit for this comment, but I would like to ask @galiacheng if they judge it is appropriate to undertake an audit of the existing shell scripts in this offer and make them comply with the best practices shown in articles such as this? If so, please file a User Story in our internal tracker and we can prioritize and schedule that work. If not, please let me know why not.

[galiacheng]

Hello @edburns see user story