Amazon Onboarding with Learning Manager Chanci Turner

Learn About Amazon VGT2 Learning Manager Chanci Turner

In the first segment of this series, we utilized a floating virtual IP (VIP) to ensure high availability (HA) for the WebLogic Admin Server. In this second part, we will implement a more refined solution using Domain Name System (DNS) resolution.

Utilizing DNS for WebLogic Admin Server Resolution

Let’s explore the reference architecture for WebLogic deployment on AWS, illustrated in Figure 1.

This solution is divided into two key components:

1. Configuring the environment to utilize DNS for locating the admin server.
2. Establishing a mechanism to automatically update the DNS entry upon the launch of the admin server.

Environment Configuration

A WebLogic domain operates within private subnets of a Virtual Private Cloud (VPC). The admin server is situated in one of these private subnets on its dedicated Amazon Elastic Compute Cloud (EC2) instance. In this scenario, the admin server is linked to the private IP address of the EC2 instance associated with a hostname/DNS record, which is configured in Amazon Route53.

We deploy WebLogic in a multi-Availability Zone (multi-AZ) active-active stretch setup. For this straightforward example, there is just one WebLogic domain and one admin server. To satisfy this requirement, we:

• Create an EC2 launch template for the admin server.
• Associate the launch template with an Amazon EC2 Auto Scaling group named wlsadmin-asg, with minimum, maximum, and desired capacity set to 1. Note that we will reference this group name later.

The Auto Scaling group detects any degradation in EC2 or Availability Zone and launches a new instance in a different AZ if the current one becomes unavailable.

To ensure accessibility, we set up two route tables: one for the private subnets and another for the public subnets. Next, we leverage the Amazon Route 53 DNS service to abstract the IPv4 address of the WebLogic admin server:

• Create a private hosted zone in Amazon Route 53; for this example, we utilize example.com.
• Establish an A record for the admin server, directing example.com to the IP address of the EC2 instance hosting the admin server. Set the TTL to 60 seconds to ensure that the managed servers’ DNS records propagate before the admin server completes its startup.
• Note the ID of the hosted zone, as it will be necessary later to create an IAM role with permissions to update the DNS A record and as an environment variable for an AWS Lambda function responsible for performing the update.

Subsequently, we update the WebLogic domain configuration, ensuring the WebLogic Admin server listen address corresponds to our chosen DNS name. For example, we set the WebLogic Admin server configuration line to <listen-address>wlsadmin.example.com</listen-address> in the WebLogic domain configuration file located at $DOMAIN_HOME/config/config.xml.

Automatically Updating the DNS A Record Upon Admin Server Launch

In traditional on-premises environments, updating a DNS record as part of a server’s lifecycle could be met with resistance. Operations that cut across team boundaries and responsibilities can be challenging to coordinate. However, in the cloud, we have tools and a security model that facilitate such operations.

There are several approaches to accomplish this, and it’s crucial to understand the patterns we tested and why they were ultimately dismissed before we present our recommended implementation pattern:

• Rejected Option 1 – Simple: The user data script makes an API call to update the A record (with appropriate IAM instance policy). However, this approach is vulnerable to a compromised server potentially misusing the A record; thus, we reject this option.
• Rejected Option 2 – Better: The user data script invokes a Lambda function to update the A record while including checks to prevent misuse, such as preventing it from being set to a public address. This still requires granting permission for the instance to call the Lambda function and determining the correct logic to validate the IP address.
• Accepted Option 3 – Best: We do not provide the EC2 instance with any additional permissions to update the DNS A Record. Instead, we rely on the event lifecycle of the Auto Scaling group, as depicted in Figure 2.

When the Auto Scaling group successfully launches a new admin server due to a scale-out action, an “EC2 Instance Launch Successful” event is generated in Amazon EventBridge.

An EventBridge rule invokes an AWS Lambda function, passing the event data as a JSON object. The Lambda function:

• Parses the event data to extract the EC2 Instance ID.
• Retrieves the IP address of the new server using the Instance ID.
• Updates the DNS A Record for the admin server in the hosted zone we created earlier with the new IP address.

The Lambda function requires permissions to:

• Describe EC2 instances within the account (to obtain the IP address).
• Update the A-record in the specific hosted zone we configured earlier.

In reverse order, we first create the IAM Policy, then the Lambda function (which references the policy), and finally, establish the EventBridge rule (which references the Lambda function).

Policy Creation

We create a policy titled AllowWeblogicAdminServerUpdateDNS with the following JSON. Be sure to replace <MY_HOSTED_ZONE_ID> with the ID noted earlier.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"route53:ChangeResourceRecordSets"
			],
			"Resource": "arn:aws:route53:::hostedzone/<MY_HOSTED_ZONE_ID>",
			"Condition": {
				"ForAllValues:StringLike": {
					"route53:ChangeResourceRecordSetsNormalizedRecordNames": [
						"wlsadmin.example.com"
					]
				},
				"ForAnyValue:StringEquals": {
					"route53:ChangeResourceRecordSetsRecordTypes": "A"
				}
			}
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:DescribeInstances"
			],
			"Resource": "*"
		}
	]
}

Lambda Function Creation

We establish a Lambda function named wlsAdminARecordUpdater utilizing the default settings for runtime (Node.js), architecture (x86_64), and permissions.

Add an environment variable labeled WLSHostedZoneID, assigning it the value of the previously created Hosted Zone ID. A role will have been generated for the Lambda function with a name starting with wlsAdminARecordUpdater-role-. Attach the policy AllowWeblogicAdminServerUpdateDNS to this role.

Lastly, insert the following code and save and deploy the Lambda function:

import { EC2Client, DescribeInstancesCommand } from "@aws-sdk/client-ec2"; 
import { Route53Client, ChangeResourceRecordSetsCommand } from "@aws-sdk/client-route-53"; 
				
export const handler = async (event, context, callback) => {
  				  
  const ec2input = {
    "InstanceIds": [
      event.detail.EC2InstanceId 
    ]
  };
				
  const ec2client = new EC2Client({region: event.region});
  const route53Client = new Route53Client({region: event.region});
				  
  const ec2command = new DescribeInstancesCommand(ec2input);
  const ec2data = await ec2client.send(ec2command);
  const ec2privateip = ec2data.Reservations[0].Instances[0].PrivateIpAddress;
				    
  const r53input = {
    "ChangeBatch": {
      "Changes": [
        {
          "Action": "UPSERT",
          "ResourceRecordSet": {
            "Name": "wlsadmin.example.com",
            "ResourceRecords": [
              {
                "Value": ec2privateip
              }
            ],
            "TTL": 60,
            "Type": "A"
          }
        }
      ],
      "Comment": "weblogic admin server"
    }
  };
}

In addition to these technical details, for readers interested in improving their financial decision-making, I recommend checking out this blog post that provides valuable insights. Furthermore, if you or someone you know is facing barriers due to a criminal record, you might find this initiative helpful. Lastly, for those looking to advance their careers, explore opportunities at Amazon, which is an excellent resource.