DEV Community: Nick Goko

Provisioning with AWS CloudFormation

Nick Goko — Tue, 16 Jan 2024 10:22:36 +0000

ProvisioningAWS CloudFormation

Create a VPC

Open a text editor and create an empty YAML File called sfid-cfn-vpc.yaml
Copy and paste the sample CloudFormation template below that defines a VPC and save the file.

Resources:
  # Create a VPC
  MainVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

Navigate to CloudFormation console. Choose "Template is ready"
Upload the yaml file you created above.
Name the stack SFID-CFN-VPC
Leave Configure stack options on default.Click Next.
Submit the stack and refresh until the creation is complete on events.
Open you VPC console to check if the VPC was created using AWS CloudFormation.
Now that we created a simple VPC, we need to enable the DNS Options and name the VPC “VPC for SFID CFN
- Add the following to the bottom of the YAML File called sfid-cfn-vpc.yaml and save the file.

      EnableDnsHostnames: 'true'
      EnableDnsSupport: 'true'
      Tags:
      - Key: Name
        Value: VPC for SFID CFN

Select the "SFID-CFN-VPC" stack name in the stack list.
Click on Update button & replace current template. Upload the update template file.
You can leave Parameters since nothing was defined and Click Next.
You can leave Configure stack options default, click Next.
Check the Changes list under the Change set preview; which shows how the changes can affect the running resources, for this case, it won’t affect our template.
Click Submit.
You can click the refresh button a few times until you see in the status UPDATE_COMPLETE.
Navigate to the AWS VPC Console to check the VPC Tag and DNS options enabled using AWS CloudFormation. >[!highlight] >Before the update the VPC didn't have a name just the CIDR block. >Now it has enabled DNS options

Create Internet Gateway

Add the following to the bottom of the YAML File called sfid-cfn-vpc.yaml and save the file.

  # Create and attach InternetGateway
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    DependsOn: MainVPC

  AttachIGW:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MainVPC
      InternetGatewayId: !Ref InternetGateway

Run the same steps you did when you last update the yaml file.

Create First Subnet

Add the following to the bottom of the yaml file. Save the file.

  # Create First Subnet
  FirstSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MainVPC
      CidrBlock: 10.0.10.0/24
      AvailabilityZone: "us-east-2a"
      Tags:
      - Key: Name
        Value: Public Subnet A - SFID

Update the stack with new saved template. Create Additional Subnet Add the following to the the bottom of the YAML file called sfid-cfn-vpc.yaml and save the file.

  # Creating additional subnet
  SecondSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MainVPC
      CidrBlock: 10.0.20.0/24
      AvailabilityZone: "us-east-2b"
      Tags:
      - Key: Name
        Value: Public Subnet B - SFID

Update the stack list. Setting up routing table
Add the following to the bottom the YAML file again

  # Create and Set Public Route Table
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:  !Ref MainVPC
      Tags:
      - Key: Name
        Value: Public Route Table

  PublicRoute:
    Type: 'AWS::EC2::Route'
    DependsOn: AttachIGW
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  # Associate Public Subnets to Public Route Table
  PublicSubnet1RouteTableAssociation:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Ref FirstSubnet
      RouteTableId: !Ref PublicRouteTable

  PublicSubnet2RouteTableAssociation:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Ref SecondSubnet
      RouteTableId: !Ref PublicRouteTable

Update the stack just as you have before.
View the changes.
Navigate to the VPC console and check the public routing table and association with 2 subnets.

Create Security Group

Add the following to the bottom of the YAML file

  # Create Security Group for the following:
  MainSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Security Group for Web Server
      VpcId: !Ref MainVPC
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: 80
        ToPort: 80
        CidrIp: 0.0.0.0/0
      Tags:
      - Key: Name
        Value: Web Server Security Group - SFID

Navigate to security groups on the left side of the screen.
On the last step we are going to add a description to the CloudFormation template and Add outputs.
Add the following to the top of the YAML file.

Description: Introduction to CloudFormation SFID - Virtual Private Cloud (VPC)

Add the following to the bottom of the YAML file.

Outputs:
  MainSubnet:
    Value: !Ref FirstSubnet
    Description: Public Subnet ID with Direct Internet Route

  MainSecurityGroup:
    Value: !Ref MainSecurityGroup
    Description: Security Group ID for the Web Server

Now update the “SFID-CFN-VPC” Stack Name in the Stack List
The changes do not appear on change set preview but description does appear on the template section. Once you submit, refresh the stack & navigate to the output section. Same section you find the Events section >[!summary] Summary Lab 1 >We divided our CloudFormation Template into the following and provided a recap to the CloudFormation Template:- Created a VPC, tagged it by providing a name and sat up the DNS Options >- Created an Internet Gateway and attached it to the VPC >- Created two Subnets in the VPC >- Created a public Route Table and Associated the two subnets >- Created a Security Group which allows Inbound Access on HTTP for Lab 2 >- Added a Description and Outputs to better understands the template.

Now that we laid down for the networking portion for this lab, we will move to our next Lab to set up an EC2 Instance and act as web server using CloudFormation.

Here is the complete yaml file.

Description: Introduction to CloudFormation SFID - Virtual Private Cloud (VPC)
Resources:

  # Create a VPC
  MainVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: 'true'
      EnableDnsSupport: 'true'
      Tags:
      - Key: Name
        Value: VPC for SFID CFN

# Create and attach InternetGateway
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    DependsOn: MainVPC

  AttachIGW:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MainVPC
      InternetGatewayId: !Ref InternetGateway

# Create First Subnet
  FirstSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MainVPC
      CidrBlock: 10.0.10.0/24
      AvailabilityZone: "us-east-2a"
      Tags:
      - Key: Name
        Value: Public Subnet A - SFID

# Creating additional subnet
  SecondSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MainVPC
      CidrBlock: 10.0.20.0/24
      AvailabilityZone: "us-east-2b"
      Tags:
      - Key: Name
        Value: Public Subnet B - SFID

# Create and Set Public Route Table
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:  !Ref MainVPC
      Tags:
      - Key: Name
        Value: Public Route Table

  PublicRoute:
    Type: 'AWS::EC2::Route'
    DependsOn: AttachIGW
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  # Associate Public Subnets to Public Route Table
  PublicSubnet1RouteTableAssociation:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Ref FirstSubnet
      RouteTableId: !Ref PublicRouteTable

  PublicSubnet2RouteTableAssociation:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Ref SecondSubnet
      RouteTableId: !Ref PublicRouteTable

  # Create Security Group for the following:
  MainSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Security Group for Web Server
      VpcId: !Ref MainVPC
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: 80
        ToPort: 80
        CidrIp: 0.0.0.0/0
      Tags:
      - Key: Name
        Value: Web Server Security Group - SFID

Outputs:
  MainSubnet:
    Value: !Ref FirstSubnet
    Description: Public Subnet ID with Direct Internet Route

  MainSecurityGroup:
    Value: !Ref MainSecurityGroup
    Description: Security Group ID for the Web Server

Setting up an EC2 instance

Open a text editor and create an empty YAML file called sfid-cfn-EC2.yaml
Copy and paste the following yaml code and save the file. Note the ImageId is copied from

Resources:
# Create EC2 Linux
  WebServerInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: "ami-0331ebbf81138e4de"
      InstanceType: t3a.micro

Open the AWS CloudFormation Console. Click on Create stack. Upload a template file. Select the yaml file you just created.
Name the stack SFID-CFN-EC2. You can leave Configure stack options default. Submit. Refresh a few times until you see in the status CREATE_COMPLETE
Open the AWS EC2 Console to check the EC2 created using AWS CloudFormation.

Tag and pass User Data to EC2 Instance
Add the following to the bottom of the YAML file called sfid-cfn-EC2.yaml and save the file.

      Tags:
          - Key: Name
            Value: Web Server for IMD
      UserData: 
        Fn::Base64:
          !Sub |
          #!/bin/sh
          yum -y install httpd
          chkconfig httpd on
          systemctl start httpd
          echo '<html><center><text="#252F3E" style="font-family: Amazon Ember"><h1>AWS CloudFormation is Fun !!!</h1>' > /var/www/html/index.html
          echo '<h3><img src="https://d0.awsstatic.com/logos/powered-by-aws.png"></h3></html>' >> /var/www/html/index.html

Select the "SFID-CFN-EC2" stack name in the stack list and update the stack.
You can leave Parameters since nothing was defined and Click Next.
You can leave Configure stack options default, click Next.
Check the Changes list under the Change set preview; which shows how the changes can affect the running resources, for this case, it won’t affect our template. Click Submit.
Navigate to the AWS EC2 Console to check the EC2 Name Tag and access to the Website other characteristics.

Paying attention to the EC2 Instance settings, you will notice that the Instance was launched in the default VPC, using a default Security Group which doesn’t allow traffic to the internet and User Data Script running only during Launch of the instance in our case, this is not the end goal for our lab.

Terminate EC2 instance

Open the AWS CloudFormation Stacks Console
We shall delete the SFID-CFN-EC2 stack Launch EC2 instance in the lab VPC
Now that we have a better understanding on how the AWS CloudFormation Template works and setting needed for a web host to launch with the proper settings Let’s create an EC2 Instance in the proper VPC using CloudFormation
Add the following to the top of the yaml file called sfid-cfn-ec2.ymal

Parameters:
  PublicSubnet:
    Description: Select a Public Subnet created in the "VPC for SFID CFN" Lab (Hint - Search for "SFID")
    Type: 'AWS::EC2::Subnet::Id'
  SecurityGroup:
    Description: Select the Security Group created in the "VPC for SFID CFN" Lab (Hint - Search for "SFID")
    Type: 'AWS::EC2::SecurityGroup::Id'

Add the following to the bottom

      NetworkInterfaces:
        - GroupSet:
            - !Ref SecurityGroup
          AssociatePublicIpAddress: 'true'
          DeviceIndex: '0'
          DeleteOnTermination: 'true'
          SubnetId: !Ref PublicSubnet

Create stack. choose Template is ready. Upload a template file.
Recommend stack name SFID-CFN-EC2
Select any of the Public Subnet A or B created in the "VPC for SFID CFN" Lab (Hint - Search for "SFID")
Select webserver-sg created in the "VPC for SFID CFN" Lab _(Hint - Search for "SFID")
Leave Configure stack options on default. Click Next. Submit. Click refresh until you see the status _CREATE_COMPLETE
When you open the AWS EC2 Console. Check the security and Networking tab on the EC2 console and you will notice that instance was launched based on the information we selected in the "Parameters" prompt. On the last step. You can add add-ons . Add a description to the CloudFormation Template and Add Outputs. Add the following to the top of the YAML file

Description: Introduction to CloudFormation SFID - Elastic Compute Cloud (EC2)

Add the following to the bottom of the YAML file

Outputs:
  PublicDNS:
    Value: !Join 
      - ''
      - - 'http://'
        - !GetAtt 
          - WebServerInstance
          - PublicDnsName
    Description: Web Host Public URL

Update the stack and upload the update yaml file.

[!summary] Lab 2 Summary

This is the complete yaml code for lab2

Description: Introduction to CloudFormation SFID - Elastic Compute Cloud (EC2)

Parameters:
  PublicSubnet:
    Description: Select a Public Subnet created in the "VPC for SFID CFN" Lab (Hint - Search for "SFID")
    Type: 'AWS::EC2::Subnet::Id'
  SecurityGroup:
    Description: Select the Security Group created in the "VPC for SFID CFN" Lab (Hint - Search for "SFID")
    Type: 'AWS::EC2::SecurityGroup::Id'

Resources:
# Create EC2 Linux
  WebServerInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: "ami-0331ebbf81138e4de"
      InstanceType: t3a.micro
      Tags:
          - Key: Name
            Value: Web Server for IMD
      UserData: 
        Fn::Base64:
          !Sub |
          #!/bin/sh
          yum -y install httpd
          chkconfig httpd on
          systemctl start httpd
          echo '<html><center><text="#252F3E" style="font-family: Amazon Ember"><h1>AWS CloudFormation is Fun !!!</h1>' > /var/www/html/index.html
          echo '<h3><img src="https://d0.awsstatic.com/logos/powered-by-aws.png"></h3></html>' >> /var/www/html/index.html
      NetworkInterfaces:
        - GroupSet:
            - !Ref SecurityGroup
          AssociatePublicIpAddress: 'true'
          DeviceIndex: '0'
          DeleteOnTermination: 'true'
          SubnetId: !Ref PublicSubnet

Outputs:
  PublicDNS:
    Value: !Join 
      - ''
      - - 'http://'
        - !GetAtt 
          - WebServerInstance
          - PublicDnsName
    Description: Web Host Public URL

Mastering Conversations with ChatGPT: A Guide to Prominent Prompting Techniques

Nick Goko — Tue, 16 Jan 2024 10:21:36 +0000

Introduction:

In the realm of AI-driven conversations, unlocking the full potential of ChatGPT requires not only knowledge but also effective prompting techniques. In this article, we will delve into three powerful techniques: the Cognitive Verifier pattern, the Infinite Generation pattern, and the Refusal Breaker pattern. Our journey will be enriched with code examples and a personal touch to make these techniques more accessible and educational.

The Cognitive Verifier Pattern: Enhancing Reasoning

Intent and Context: The Cognitive Verifier pattern encourages us to break down complex questions into smaller, more manageable parts. This technique is akin to a detective gathering clues to solve a bigger mystery.
Motivation: Imagine you're exploring quantum physics, a domain full of complexity. You might start with a broad question: "Explain quantum entanglement." This pattern motivates you to subdivide it: "What is quantum entanglement?" "How does it relate to particle physics?" Each answer forms a piece of the puzzle.
Structure and Key Ideas: For instance, let's explore the concept of quantum entanglement. We could begin with:

Prompt: "What is quantum entanglement?"

And then further subdivide:

Prompt: "How does quantum entanglement affect particle behavior?"

By combining the answers to these questions, you construct a comprehensive understanding.

The Infinite Generation Pattern: Continuous Output

Intent and Context: Imagine you're designing a text-based game or generating creative content. The Infinite Generation pattern allows you to maintain a continuous flow of content without repetitive prompts.
Motivation: This technique's motivation is simple: to save time and effort while ensuring a consistent output. You can specify how many outputs you want or even request an infinite stream.
Structure and Key Ideas: Suppose you're developing a story generator. You might start with:

Prompt: "Create a story about an adventurer's quest."

Then, with the Infinite Generation pattern:

Generate output forever, 3 output(s) at a time.

This way, your narrative flows seamlessly.

The Refusal Breaker Pattern: Enhancing Answer Quality

Intent and Context: Occasionally, ChatGPT may not provide a satisfactory answer. The Refusal Breaker pattern addresses this by explaining why and offering alternative phrasings for the question.
Motivation: This pattern aims to enhance the quality of responses. Think of it as a helpful librarian guiding you to the right bookshelf when the desired book isn't on display.
Structure and Key Ideas: For instance, if you inquire about the meaning of life:

User: What is the meaning of life?
ChatGPT: As an AI, I can't provide personal beliefs. Try asking, "What are some philosophical perspectives on life's purpose?"

This pattern empowers you to refine your questions effectively.

Personal Touch and Code Examples:

Imagine you're teaching programming with ChatGPT. You could employ the Cognitive Verifier pattern to explore topics step by step:

Prompt: "Explain Python functions."

And then:

Prompt: "What are the parameters in Python functions?"

Each subdivision helps students grasp complex concepts. Similarly, you can use Infinite Generation to create coding exercises:

Generate output forever, 2 output(s) at a time.

This keeps students engaged with continuous challenges.

The Refusal Breaker pattern, meanwhile, aids in clarifying doubts:

User: How do I fix a syntax error in my Python code?
ChatGPT: To address syntax errors in Python, try asking, "What are common Python syntax mistakes and how to fix them?"

Incorporating these techniques and code examples into your interactions with ChatGPT can make learning and problem-solving more interactive and enjoyable.

Conclusion:

In your journey with ChatGPT, these prompting techniques are like the keys to a treasure trove of knowledge and creativity. Whether you're seeking clarity, continuous content, or refined answers, they empower you to make the most of your conversations. By embracing them, you'll uncover the full potential of ChatGPT as an educational companion and problem-solving partner.

EC2 Auto Scaling

Nick Goko — Tue, 16 Jan 2024 10:18:39 +0000

We start by creating an Amazon Machine Image (AMI) from a web host created with CloudFormation.

Then continue to creating a launch template and setting up the web host within an auto scaling group behind an Application Load Balancer (ALB).

The end result will be an auto scaling group behind a load balancer that scales based on CPU utilization of the hosts.

Prerequisites

Navigate to AWS Console and search for CloudFormation
Create Stack
Under template source select Upload a template file
Upload this EC2-Auto-Scaling-Lab.yaml file then click Next. >[!code]- Read through and use this yaml code to create a EC2-Auto-Scaling-Lab.yaml file

AWSTemplateFormatVersion: 2010-09-09
Description: This CloudFormation template will produce the web host to build your AMI
Parameters:
  AmiID:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Description: The AMI ID - Leave as Default
    Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
  InstanceType:
    Description: Web Host EC2 instance type
    Type: String
    Default: m5.large
    AllowedValues:
      - t2.micro
      - m5.large
  MyVPC:
    Description: Select Your VPC (Most Likely the Default VPC)
    Type: 'AWS::EC2::VPC::Id'
  MyIP:
    Description: Please enter your local IP address followed by a /32 to restrict HTTP(80) access. To find your IP use an internet search phrase "What is my IP".
    Type: String
    AllowedPattern: '^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(32))$'
    ConstraintDescription: Must be a valid IP CIDR range of the form x.x.x.x/32
  PublicSubnet:
    Description: Select a Public Subnet from your VPC that has access to the internet
    Type: 'AWS::EC2::Subnet::Id'

Resources:
  WebhostSecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      VpcId: !Ref MyVPC
      GroupName: !Sub ${AWS::StackName} - Website Security Group
      GroupDescription: Allow Access to the Webhost on Port 80
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          CidrIp: !Ref MyIP
      Tags:
        - Key: Name
          Value: !Sub ${AWS::StackName} - Web Host Security Group
  WebServerInstance:
    Type: 'AWS::EC2::Instance'
    Properties:
      ImageId: !Ref AmiID
      InstanceType: !Ref InstanceType
      Tags:
        - Key: Name
          Value: !Sub ${AWS::StackName}
      NetworkInterfaces:
        - GroupSet:
            - !Ref WebhostSecurityGroup
          AssociatePublicIpAddress: 'true'
          DeviceIndex: '0'
          DeleteOnTermination: 'true'
          SubnetId: !Ref PublicSubnet
      UserData: 
        Fn::Base64:
          !Sub |
          #!/bin/bash -xe
          yum -y update
          yum -y install httpd
          amazon-linux-extras install php7.2
          yum -y install php-mbstring
          yum -y install telnet
          case $(ps -p 1 -o comm | tail -1) in
          systemd) systemctl enable --now httpd ;;
          init) chkconfig httpd on; service httpd start ;;
          *) echo "Error starting httpd (OS not using init or systemd)." 2>&1
          esac
          if [ ! -f /var/www/html/ec2-web-host.tar.gz ]; then
          cd /var/www/html
          wget https://workshop-objects.s3.amazonaws.com/general-id/ec2_auto_scaling/ec2-web-host.tar
          tar xvf ec2-web-host.tar
          fi
          yum -y update
Outputs:
  PublicIP:
    Value: !Join 
      - ''
      - - 'http://'
        - !GetAtt 
          - WebServerInstance
          - PublicIp
    Description: Newly created webhost Public IP
  PublicDNS:
    Value: !Join 
      - ''
      - - 'http://'
        - !GetAtt 
          - WebServerInstance
          - PublicDnsName
    Description: Newly created webhost Public DNS URL

Specify Stack Details
After that you will need to specify stack details. To continue on to the next section you must first:
- Edit you stack name with your initials [Your initials]-EC2-Web-Host
- Leave AmiID to the default
- Under instance type select m5.large to demonstrate real world performance for production workloads. Should you encounter any problem with the m5 instances load the CloudFormation Template again and select t2.micro.
Under MyIp, enter your local address followed by /32. Here is a link to lookup you IP address

Under MyVPC select the default VPC or any VPC you may want.
Under "PublicSubnet" select a subnet within your VPC that has internet access. A public subnet is defined by a subnet having a route to the internet gateway within it's route table. By default, the Default VPC subnets are all public. In the event you want to view all your subnets you can navigate to VPC on your AWS management console and click subnets.
Once you are done entering the details above, click on Next.
Configure Stack Options. You can leave "Tags", "Permissions", and "Advanced options" as default and select Next.
Review [Your Initials]-EC2-Web-Host page, review your settings and click on Create stack to start building your web server.
- Wait till the "Logical ID" "[Your Initials]-EC2-Web-Host" shows a status of "CREATE_COMPLETE".

Once the CloudFormation Stack is complete. Navigate to the EC2 service using you management console.

Select Instances from the left hand menu. On the "Instances" page, select your instance "[Your Initials]-EC2-Web-Host" and copy the "Public IPv4 DNS" address. Paste this address into a new tab on your web browser.

You should be greeted by this web page with the title "EC2 Instance Metadata".

Generate a Custom AMI of the web server.

Now that we have our instance setup to host our website, we will generate a custom machine image for our auto scaling group.

This will create an image of our web host that will be used by our Auto Scaling group to spin up multiple instances based on server load.

In the EC2 Console under Instances, you can create Amazon Machine Images (AMIs) from either running or stopped instances.
Or create an Amazon Machine Image by using your instance name [your initials] - Webserver Right-click your webhost instance under "Image and templates" choose Create image from the context menu.
On the "Create Image" page, put in the Image name [Your Initials]_Auto_Scaling_Webhost and a description. You can leave the Instance volumes as default and then choose Create Image.
It may take a few minutes for the AMI to be created. In the EC2 console under "Images" in the left hand menu select AMIs. You should see the AMI you just created, it may be in a pending state, but after a few moments it will transition to an available state.

We are done with our new Amazon Machine Image for now, we can now move on to setting up our auto scaling security group.

Create a new Security Group for the Auto Scaling Group

A security group provides instance (virtual machine) level protection.

[!article]- A security group controls the traffic that is allowed to reach and leave the resources that it is associated with. For example, after you associate a security group with an EC2 instance, it controls the inbound and outbound traffic for the instance.

Within the console Under "Services" select EC2 or search EC2 in the search bar. On the EC2 page under the "Network & Security" heading in the left-hand menu select Security Groups. You should see other security groups, including the security group for your web server named "[Your Initials]-EC2-Web-Host - Website Security Group". To start the creation of a new security group, click on the Create security group button.

Name your security group [Your Initials] - Auto Scaling SG and you can use the same name for the description as well and make sure you have the correct VPC select. (Most likely the Default VPC unless you setup a new one for this lab)

Under "Inbound rules" we will leave it empty for now. We will be creating a rule later but we need our load balancer security group to exist first.

"Outbound rules" currently allow all traffic out so there is no need for any additional rules. Add rule and select the CIDR range 0.0.0.0/0 setting the destination to allow all ip address to access your instance.

You are now finished with the prerequisites need.

Below is a representation of the end state

Three Main Components to EC2 Auto Scaling on AWS

1. Launch Template: A Launch Template is a feature of EC2 Auto Scaling that allows a way to templatize your launch requests. It enables you to store launch parameters so that you do not have to specify them every time you launch an instance.

2. Auto Scaling Groups: For auto scaling your EC2 instances are organized into groups so that they can be treated as a logical unit for the purposes of scaling and management. When you create a group, you can specify its minimum, maximum, and desired number of EC2 instances.

3. Scaling Policies: A Scaling Policy tells Auto Scaling when and how to scale. Scaling can occur manually, on a schedule, on demand, or you can use Auto Scaling to maintain a specific number of instances.

Auto Scaling is well suited for applications that have unpredictable demand patterns that can experience hourly, daily, or weekly variability in usage. This helps you to manage your cost and eliminate over-provisioning of capacity during times when it is not needed. Auto Scaling can also find an unhealthy instance, terminate that instance, and launch a new one based on the scaling plan.
The number of EC2 instances can be scaled in or out as Auto Scaling responds to the metrics you define when creating these groups
- You can specify the minimum number of instances in each Auto Scaling Group, so that your group never goes below this size. (Even if the instances are determined to be unhealthy)
- You can specify the maximum number of instances in each Auto Scaling Group, so that your group never goes above this size.
- You can specify a desired capacity to specify the number of healthy instances your auto scaling group should have at all times.️

Creating a Launch Template

Select EC2 using your management console
In the left navigation pane, find "Instances" and select Launch Templates.
Now select Create launch template.
You should find yourself on Create launch template" page, starting with the "Launch template name and description": a. Launch template name: [Your Initials]-scaling-template b. Template version description: This is optional c. Auto scaling guidance: Check the box to provide guidance.

"Launch Template Contents" defines the parameters for the instances in the Auto Scaling group:

a. Amazon machine image (AMI): Select "My AMIs" and "Owned by me". In the drop down search by typing your initials and select the custom AMI you just created [Your Initials]Auto_Scaling_Webhost. (The new AMI you just created may already be selected)

b. Instance type_: t2.micro

c. Key pair (Login): Select the Key Pair you created in the past, it is most likely call [Your Initials]-KeyPair. If not here is a guide to create one

d. Networking Settings:

Subnet: Don't include in launch template
Firewall (security groups): Select "Select existing security group" and then select the security group you created in the first part of this lab named [Your Initials] - Auto Scaling SG

e. Configure storage: Leave as default

f. Resource tags: None

g. Advanced Details: IMPORTANT: Select the arrow to expand "Advanced details" and under "Detailed Cloudwatch monitoring" select Enable. Leave everything else as the default.

By enabling CloudWatch Detailed monitoring. CloudWatch will monitor the instances in your auto scaling group in 1-minute intervals. This will allow the auto scaling group to respond quicker to changes in the group.

By default, your instance has basic monitoring in 5-minute intervals for the instances.

Create Auto Scaling Group

Select EC2 using your management console
In the left navigation pane find "Auto Scaling" and Select Auto Scaling Groups.
Click Create an Auto Scaling group.
Give the Auto Scaling group a name: [Your Initials]-Lab-AutoScaling-Group
From the Launch Template drop down choose the launch template named [Your Initials]-scaling-template you created in the previous section and select Next.
Configure settings page, configure the following and select Next: Network:
- VPC: Select your VPC (most likely Default)
- Subnets: Select the subnets where you would like the auto scaling group to use when spinning up the hosts. (If you are using the default VPC, this will most likely be four subnets)

A best practice for your Auto Scaling Group would be to select only private subnets. The instances will be sitting behind a load balancer and will not need public IP addresses.

Specify load balancing and health checks:

a. Load balancing: Attach to a new load balancer

b. Load balancer type: Application Load Balancer

c. Load balancer name: [Your Initials]-Application-Load-Balancer

d. Load balancer scheme: Internet-facing

e. Networking mapping: You should see all the Availability Zones and subnets you selected in the previous step. (If you had multiple subnets per AZ, this were it would let you choose between them)

f. Listeners and routing: Keep the Port as 80 and select Create a target group from the "Default routing (forward to)" dropdown.

g. New target group name: [Your Initials]-Target-Group

- The target group is where your load balancer is going to look for instances to distribute traffic. We are setting our auto scaling group to automatically register instances into this group and it will also be associated to our load balancer.

h. *Health checks & Additional settings*: Leave as default and select **Next**.

Configure the group size and scaling policies below and then select Next a. Group Size: The settings below will keep our group size to one EC2 instance unless a scaling policy is triggered.

- Desired capacity: `1`

- Minimum capacity: `1`

- Maximum Capacity: `5`

b. *Scaling policies*: Select **Target tracking scaling policy**

- Metric type: Average CPU utilization

- Target Value: `25`

![](https://i.imgur.com/lyOp5tZ.png)

We are going to set our target CPU utilization low to speed up the results.

Add Notifications:

You can configure your Auto Scaling Group to send notifications to an endpoint that you choose, such as an email address. You can receive notifications whenever a specified event takes place, including the successful launch of an instance, failed instance launch, instance termination, and failed instance termination.
Add Tags: Add a single tag and then select Next.

a. Select the Add tag button and configure the following:
- Key: Name
- Value: [Your Initials] - Auto Scaling Group
Then select Create Auto Scaling group. You have now created your Auto Scaling Group, target group and load balancer.

a. You will soon see a new instance created by the Auto Scaling group in the EC2 console with the name tag "[Your Initials] - Auto Scaling Group". (You may need to refresh the screen to see the instance)

b. If you select Load Balancers under "Load Balancing" in the left hand menu, you will see your load balancer provisioning.

In the next step we will create an additional security group and update the security settings to allow traffic to flow between the ALB and our web hosts.

Penultimate Things We Must Do before We come to the End Is:

Configuring Security Groups

Creating a Load Balancer Security Group

When our load balancer was provisioned it was setup with the default security group in our VPC. To allow access to the load balancer via the public DNS, we will need to create and attach a security group to allow inbound traffic on port 80 from the internet.

We will also create an outbound rule that allows outgoing traffic from the load balancer to only be sent to hosts within the Auto Scaling Security Group.

On the EC2 page under the "Network & Security" heading in the left-hand menu select Security Groups. You should see other security groups, including the security group for your web server named [Your Initials]-EC2-Web-Host - Website Security Group.

Click on the Create security group button.

Basic details: a. Security group name: [Your Initials]-SG-Load-Balancer b. Description: [Your Initials]-SG-Load-Balancer c. VPC: Select your VPC (Most likely the Default VPC)
Inbound rules:

a. Click on the Add rule button

b. Type: HTTP

c. Source: Custom: [Input your public IP address followed by a /32]

(You can find your local IP by searching What is my IP. )
Outbound rules:

a. Find the "All traffic" rule and click on Delete to remove the rule. (All Outbound rules should now be removed)

b. Click on the Add rule button

c. Type: HTTP

d. Under "Destination" select Custom and in the field select your [Your Initials]-Auto Scaling SG as the "Destination". Hint: start by typing sg

to get the Security Group list.

f. You security group configuration should look similar to the image below. Select Create security group when finished.
Attach your new Load Balancer Security group to your Load Balancer:

a. On the EC2 service page left side menu find "Load Balancing" and select Load Balancers. Select the load balancer you created. Make sure the State is "Active".

b. Under the "Description" tab scroll down to the "Security" section and click on Edit security groups.

c. Select the box to the left of your new load balancer sg named [Your Initials]-SG-Load-Balancer

d. Make sure you also un-select any other security group and then click on the Save button.

Add Inbound Rule to the Auto Scaling Security Group

We will need to setup a rule to only allow traffic from the new Load Balancer Security Group to the Auto Scaling Security Group. This will be one of the layers of protection that will prevent our webhosts from being directly accessed from the internet.

a. On the EC2 service page left side menu under "Network & Security" select Security Groups.

b. Select your Auto Scaling Security Group: [Your Initials] - Auto Scaling SG

c. Select the Inbound Rules tab and click on the Edit inbound rules button and then the Add rule button.

d. From the "Type" drop down select HTTP. Under "Source" select Custom and in the field specify your [Your Initials]-SG-Load-Balancer as the "Source". Hint: start by typing sg to get the Security Group list. Now click on Save rules.
We will now test to make sure your load balancer is working. There is currently only one instance (or target) running in the auto scaling group, but you should be able to access the website.

Return to your the load balancers page by selecting Load Balancers from the left hand menu. Under the "Description" tab copy the DNS name and paste it into a web browser. You should now see the website being loaded from your auto scaling group. Leave this page open, you will need it in the next step.

Testing the AutoScaling Group

Now that you have created your Auto Scaling Group and load balancer, let's test it to ensure that everything is working correctly.

Make sure you are on the website accessed through the Load Balancer DNS address in the previous step.
At the bottom of the front page click on the Start CPU Load Generation link: Once the CPU load goes above 25% for a sustained period the Auto Scaling policy will begin spinning up the instances specified in the launch template to meet demand. (You may have to do this twice if the first time doesn't generate enough load)
In the "Instances" section of the EC2 Console you can watch for the new instances created by Auto Scaling, this might take a couple of minutes. Refresh the EC2 instances page and you should soon see a new instance spinning up automatically. You can select the instance named [Your Initials] - Auto Scaling Group and click on the Monitoring tab below to keep an eye on the "CPU Utilization".
1. You can also see this by going to the Auto Scaling Groups page. https://console.aws.amazon.com/ec2autoscaling Then select your auto scaling group [Your Initials]-Lab-AutoScaling-Group. If you look at the details under the Instance management tab, you can see if new instances are spinning up. You can look at the Instance management tab to see how many instances there are in your group currently. The monitoring tab shows you different metrics like group size, pending instances, total instances, and much more. > Your architecture now looks like this >
Once a number of new instances have successfully started (probably 3 or 4), repeatedly refresh your web-browser on you web host. You should now see the Instance ID, Availability Zone and Private IP change as the load balancer distributes the requests across the Auto Scaling group.

Your have successfully created an EC2 Auto Scaling Group behind an Application Load Balancer.

Breaking a Monolithic Node.js Application into Microservices

Nick Goko — Tue, 16 Jan 2024 10:16:34 +0000

After completing this lab, you should be able to:

Migrate a monolithic Node.js application to run in a Docker container
Refactor a Node.js application from a monolithic design to a microservices architecture
Deploy a containerized Node.js microservices application to Amazon ECS. ### Task 1: Preparing the Development Environment
Create cloud9 environment. AWS Cloud9 is a cloud-based integrated development environment (IDE) that you can use to write, run, and debug code on a browser. It comes pre-packaged with essential tools for popular programming languages, and provides access to the AWS Command Line Interface (AWS CLI) in a terminal session tab. ![[Pasted image 20240111082546.png]]
In the AWS Management Console browser tab, expand All services, and then select Developer Tools > Cloud9.
In the Cloud9-IDE card, choose Open IDE The IDE opens in a new browser tab and displays several tabs, including a Welcome tab.
In the bottom pane of the IDE, enter the following command in the terminal tab

curl -s https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-200-ACACAD-2-91555/16-lab-mod13-guided-1-ECS/s3/lab-files-ms-node-js.tar.gz | tar -zxv

This command retrieves a compressed archive file that contains the lab files. It also extracts the file contents in the AWS Cloud9 ~/environment folder. The command output should like the following example:

![[Pasted image 20240111083015.png]]

The downloaded and extracted files are visible in the Environment window (in the left pane).

You can see the following folders:

1-no-container – Contains the files that are related to the monolithic implementation of the application. This implementation is intended to run directly on a Node.js server.
2-containerized-monolith – Contains the files that are related to the monolithic implementation of the application. This implementation is intended to run in a containerized Docker environment orchestrated by Amazon ECS.
3-containerized-microservices – Contains the files that are related to the microservices implementation of the application. This implementation is intended to run in a containerized Docker environment orchestrated by Amazon ECS.

Keep the AWS Cloud9 IDE tab opened throughout this lab, because you will use it frequently.

Task 2: Running the Application on a Basic Node.js Server

The base Node.js application is a monolithic service that was designed to run directly on a server, without a container.

In this task, you deploy the application to the Node.js server that is installed on the instance running your AWS Cloud9 environment.

You then test the application by using the AWS CLI terminal to invoke its RESTful API methods.

The deployment architecture and request flow are illustrated in the following diagram.

![[Pasted image 20240111083313.png]]

Note: The monolithic implementation of the application uses the Node.js cluster functionality to spawn one worker process per CPU core.

The processes share a single port, and are invoked in a round-robin way by the load balancer that is built into Node.js. This feature increases scalability on servers that have multiple CPU cores.

In this task, you will:

Install the Node.js modules required by the application
Review the application design and code
Run the application

Task 2.1: Installing the Required Node.js Modules

The message board application uses two modules from the Node.js koa framework in its implementation: koa and koa-router. Koa.js is a widely used Node.js web application framework that facilitates building asynchronous server-side JavaScript applications.

In the terminal tab, enter the following commands to install the koa and koa-router modules:

cd ~/environment/1-no-container

npm install koa

npm install koa-router

The modules are downloaded and installed in the 1-no-container/node_modules folder of the AWS Cloud9 ~/environment folder. You can ignore the notice, warnings, and update messages in the output.

Task 2.2: Reviewing the Application Design and Code

The components that implement the monolithic message board application are in the 1-no-container folder. Review them to gain an understanding of the application design and code.

In the Environment window on the left, expand the 1-no-container folder. The components of the application include:
- node_modules folder – This folder was created when you installed the required JavaScript modules in the previous subtask. It contains their source code.
- db.json – A JavaScript Object Notation (JSON) object that simulates the message board database. It contains attributes that represent users, threads, and posts, with corresponding sample values.
- index.js – JavaScript program that is the application's entry point.
- package.json – A JSON object that describes the application, its entry point, and its dependencies.
- package-lock.json – A JSON object that was automatically generated when you installed the required JavaScript modules in the node_modules folder. It is used by the installation utility, npm, to track the modifications that are made to the folder.
- server.js – JavaScript program that defines the application's RESTful API methods, and implements their respective handlers.
Examine the package.json object. In the Environment window, open package.json an editor tab by double-clicking it. Notice the following attributes of the JSON object:
- Lines 2 through 5 – The dependencies attribute defines the JavaScript module dependencies for the application. Note that the koa and koa-router modules that you installed in the previous subtask are listed here.
- Lines 6 through 8 – The scripts attribute declares the index.js program as the entry point to the application. ![[Pasted image 20240111085740.png]]
Examine the db.json object. In the Environment window, open db.json in an editor tab by double-clicking it. Notice the following attributes of the JSON object:
- Lines 2 through 27 – These lines define a users attribute that represents the registered users of the message board. The attribute value is a list of four sample users with the following names: Marcerline Singer, Finn Alberts, Paul Barium, and Jake Storm. ![[Pasted image 20240111085822.png]]
- Lines 29 through 45 – These lines define a threads attribute that represents the current active threads on the message board. The attribute value is a list of three sample threads with the following titles: ![[Pasted image 20240111085959.png]]
  - Did you see the Brazil game?
  - New French bakery opening in the neighborhood tomorrow
  - In search of a new guitar
  - Lines 47 through 78 – These lines define a posts attribute that represents the posted messages on the active threads. The attribute value is a list of six sample message posts. ![[Pasted image 20240111090023.png]]
Review the code for index.js. In the Environment window, open index.js in an editor tab by double-clicking it. Notice the following information:
- Lines 1 through 3 – These lines import the JavaScript modules that the program requires, specifically: cluster, http, and os.
- Line 3 – This line uses the os module to ask about the number of CPU cores that are available on the server.
- Lines 5 through 15 – These lines are run the first time the program is invoked (when the application is started). They create a Leader thread for the cluster and one worker thread for each CPU core that is available on the server.
- Lines 16 through 19 – These lines handle each request to the application by invoking the server.js program in the current worker thread. ![[Pasted image 20240111090107.png]]
Lastly, review the code for server.js. In the Environment window, open server.js in an editor tab by double-clicking it. Use the comments that are provided in the code to facilitate your understanding of the logic. In particular, notice the following information:
- Line 3 – This line imports db.json, the JSON object that simulates the database.
- Lines 6 through 11 – These lines define a generator function that runs for every request. Its purpose is to print a line that contains the HTTP method, resource path URL, and elapsed time for each request that is processed.
- Lines 13 through 47 – These lines define the application's RESTful API methods and their implementation. Specifically, the application can respond to the following RESTful calls.
  - GET /api/users: Returns the collection of users in the database
  - GET /api/users/:userId: Returns the information for the user that is identified by :userId
  - GET /api/threads: Returns the collection of threads in the database
  - GET /api/threads/:threadId: Returns the information for the thread that is identified by :threadId
  - GET /api/posts/in-thread/:threadId: Returns the collection of post messages for the thread that is identified by :threadId
  - GET /api/posts/by-user/:userId: Returns the collection of post messages for the user that is identified by :userId
  - GET /api/: Returns the message API ready to receive requests
  - GET /: Returns the message Ready to receive requests
- Line 52 – This line defines the port number where the application listens for requests
  Task 2.3: Running the Application
  
  In this subtask, you will start the Node.js server and run the message board application. Then, you will test some of its RESTful API methods.
  
  In the terminal tab, start Node.js and the application by entering the following command:

npm start

Once the server is started and the application's entry point, index.js, is run. The first time that index.js is invoked, it creates two cluster threads—Leader and Worker—to process requests.

Next, you will leave the current terminal session active and open a second terminal tab to test the application's RESTful API.

In the bottom pane, open a new terminal tab by choosing (+) and selecting New Terminal. You now have two terminals where you can enter commands.

In the right terminal tab, retrieve the /api/users resource by entering the following command:

curl localhost:3000/api/users

The RESTful invocation returns a JSON object that contains the list of users in the message board database.

![[Pasted image 20240111094123.png]]

Select the left terminal tab. You see an output message from server.js that it processed a GET method request on the resource, which is identified by the path /api/users. The request took 2 milliseconds to process.

![[Pasted image 20240111094352.png]]

Retrieve the information for only the fourth user in database. In the right terminal tab, enter the following command:

curl localhost:3000/api/users/4

A JSON object that contains all the threads in the database is returned

![[Pasted image 20240111094737.png]]

Next, retrieve all the threads that are currently in the database. In the right terminal tab, enter the following command:

curl localhost:3000/api/threads

![[Pasted image 20240111095230.png]]

Lastly, retrieve all the posts for the first thread in the database. In the right terminal tab, enter the following command:

curl localhost:3000/api/posts/in-thread/1

A JSON object that contains all the threads in the database is returned

Lastly, retrieve all the posts for the first thread in the database. In the right terminal tab, enter the following command:

curl localhost:3000/api/posts/in-thread/1

Stop the Node.js server. In the left terminal tab, press CTRL+C to terminate the server process.

You have validated that the application responds properly to GET requests. In the next task, you will containerize the application.

Task 3: Containerizing the Monolith for Amazon ECS

Containers wrap application code in a unit of deployment, which captures a snapshot of the code and its dependencies. They can help ensure that applications deploy quickly, reliably, and consistently, regardless of the deployment environment.

In this task, you will build a container image for the monolithic message board application and push it to Amazon Elastic Container Registry (Amazon ECR). This step prepares the application for deployment to Amazon ECS.

Specifically, you will perform the following steps:

Prepare the application for Docker containerization
Provision a repository
Build and push the Docker image to the repository

Task 3.1: Preparing the Application for Docker Containerization

To put the message board application into a Docker container, the following changes must be made to the application:

Remove the use of the Node.js cluster feature and convert the application to a single-process design. With Docker containers, the goal is to run a single process per container, instead of a cluster of processes.
Create a Dockerfile for the application. This file is basically a build script that contains instructions about how to build a container image for the application.

A container-ready version of the application is provided to you in the 2-containerized-monolith folder of your AWS Cloud9 environment.

Take a few minutes to review the files and understand the changes that were made to prepare the application for containerization.

In the Environment window on the left, expand the 2-containerized-monolith folder, and open the package.json in an editor tab by double-clicking it.

In Line 7, notice that the entry point into the application was changed from index.js to server.js.

The index.js file is no longer in the application folder.

The index.js file contained the initialization logic for the Node.js cluster feature, and you will no longer use that feature.

In the Environment window, expand the 2-containerized-monolith folder, and open the server.js file in an editor tab by double-clicking it.

The only difference from the non-containerized version is the addition of Line 54, which prints the message Worker started when the application is first started.

In the Environment window, expand the 2-containerized-monolith folder, and open the Dockerfile in an editor tab by double-clicking it.

This file contains the instructions about how to build the container image for the application.

![[Pasted image 20240113110142.png]]

Notice the following information:

Line 1 – The base image where the container image will be built. Here, it is alpine-node, which is a Node.js image.
Line 3 – This line sets the working directory of the file system on the image to /srv.
Line 4 – This line adds the contents of the 2-containerized-monolith folder (the application folder) to the current working directory of the image's file system (which is set in the previous line).
Line 5 – This line invokes the npm install command to install all the application's library dependencies that were declared in the package.json file.
Line 7 – This line informs Docker that the container listens on port 3000 when it runs.
Line 8 – This line asks Docker to run the command node server.js, which starts the application when the image is started.

Now that you understand how the container image for the application will be built, you will next examine where to put the image after it is built.

Task 3.2: Provisioning a Repository

Docker container images are intended to be stored in a repository for sharing, version control, and easier management purposes. Amazon ECR makes it easy for developers to store, manage, and deploy Docker container images.

In addition, Amazon ECR is integrated with Amazon ECS, which enables Amazon ECS to pull container images directly for production deployments.

In this subtask, you will create a repository in Amazon ECR to house the Docker container image for the message board application.

In the Your environments browser tab, choose Services, and then select Container > Elastic Container Registry.

The Amazon ECR console opens.

In Create a repository, choose Get Started.

In the Repository name box, enter mb-repo.

Choose Create repository.

A message at the top of the page indicates that the repository was successfully created.

Note: Do not close the window that shows the message. You will use it in the next subtask.

Task 3.3: Building and Pushing the Docker Image

You are now ready to build the container image for the application and push it to the Amazon ECR repository that you created.

One useful feature of the Amazon ECR console is that it provides ready-to-use command templates for building and pushing an image to the new repository. You use these provided AWS CLI commands in the next steps.

Before you can successfully run the next steps, you must upgrade the AWS CLI. To do this, go to the AWS Cloud9 IDE browser tab, and in the left terminal tab, enter the following commands:

pip3 install awscli --upgrade --user
export PATH=$HOME/.local/bin:$PATH

Go back to the Amazon ECR console browser tab, and in the message window at the top of the page, choose View push commands.

The Push commands for mb-repo pop-up window opens. This window lists four AWS CLI commands that are customized for the mb-repo, and they are purposely built to:

Authenticate your Docker client to your Amazon ECR registry
- Build your Docker image
- Tag your Docker image
- Push your Docker image to the repository

The pop-up window offers two versions of the commands: one for macOS/linux, and one for Microsoft Windows.

Make sure that the macOS/Linux tab is selected, because you will run these commands in your AWS Cloud9 environment.

First, you will copy and run the command to log in your Docker client to your registry.

In the pop-up window, locate the first command and then copy the command to the clipboard by choosing the Copy icon.

The command looks like the following example:

$ aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 01234567890.dkr.ecr.us-east-1.amazonaws.com/mb-repo

![[Pasted image 20240113111016.png]]

If the command runs successfully, it returns the message Login Succeeded. You can ignore the displayed warnings.

Next, you will build the Docker image for your application.

Note: When a specific terminal tab is not mentioned in an instruction step, use the left terminal tab.

In the terminal tab, change the directory to the 2-containerized-monolith folder by entering the following command:

cd ~/environment/2-containerized-monolith

Switch to the Amazon ECR console browser tab.

In the Push commands for mb-repo window, locate the second command and copy the command by choosing the Copy icon.

The command looks like the following example:

docker build -t mb-repo .

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste the copied command and run it by pressing ENTER:

![[Pasted image 20240113111259.png]]

The build command produces multiples lines of output as it runs the instructions that are in the application's Dockerfile.

When it is finished, you see the messages Successfully built nnnnnnnnnn and Successfully tagged mb-repo:latest.

Next, you will tag the image with the repository URI so that it can be pushed the repository.

Switch to the Amazon ECR console browser tab.

In the Push commands for mb-repo window, locate the third command and choose the Copy icon.

The command looks like the following example:

docker tag mb-repo:latest 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-repo:latest

![[Pasted image 20240113111610.png]]

The command does not return anything if it completed successfully.

Finally, you will push the container image to the application's repository.

Switch to the Amazon ECR console browser tab.

In the Push commands for mb-repo window, locate the fourth command and copy it.

The command looks like the following example:

docker push 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste and run the copied command:

![[Pasted image 20240113111751.png]]

The command outputs several messages as each layer of the image is pushed to the repository.

Next, you will verify that the image was successfully uploaded.

Switch to the Amazon ECR console browser tab.

Close the Push commands for mb-repo window.

In the Repositories list, choose mb-repo.

In the Images list, you should see the container image that you pushed, which you can identify by the latest tag.

![[Pasted image 20240113111958.png]]

Record the Image URI. In the Images list, locate the Image URI of the latest version of the image, and choose the Copy icon. Paste the value in a text editor. You will use it in a subsequent step.

You have successfully created a container image for the message board application, and you have also pushed it to an Amazon ECR repository.

Task 4: Deploying the Monolith to Amazon ECS

In this task, you deploy the containerized monolithic application to an Amazon ECS runtime environment. Specifically, you use Amazon ECS to create a managed cluster of Amazon Elastic Compute Cloud (Amazon EC2) instances. You will deploy your application container image to this cluster. The cluster is configured as the target group of an Application Load Balancer, which will provide failover and scalability.

The following diagram shows the deployment architecture of the containerized monolithic application. It also displays the resources that you will create in this task.

![[Pasted image 20240111122506.png]]

The steps that you perform in this task are:

Create an Amazon ECS cluster.
Create a task definition for the application container image.
Create the Application Load Balancer.
Deploy the monolithic application as an ECS Service.
Test the containerized monolithic application.

[!caution]

Before you create an Amazon ECS cluster CREATE a separate VPC and Subnet (with the IP block supplied) under the VPC service.Then return to the ECS window and follow the instructions

Task 4.1: Creating an Amazon ECS Cluster

An Amazon ECS cluster is a logical grouping of EC2 instances where you can run tasks or services that represent your containerized application.

In this subtask, you will create an ECS cluster by using the Amazon ECS console. The console's cluster creation wizard enables you to create all the infrastructure components that are needed to create the ECS cluster environment. These components include the virtual private cloud (VPC), subnets, security groups, internet gateway, and AWS Identity and Access Management (IAM) roles.

Go back to the AWS Management Console browser tab, choose Services, and then select Containers > Elastic Container Service.

In the navigation pane, choose Amazon ECS > Clusters.

Important: Verify that the new ECS experience toggle button is set to off. The instructions below assume you are using the older ECS experience.

In the Clusters page, choose Create Cluster.

In the Select cluster template page, select the EC2 Linux + Networking card.

Choose Next step.

In the Configure cluster wizard, configure the following settings.

- Cluster name: mb-ecs-cluster

- Provisioning Model: On-Demand Instance

- EC2 instance type: t2.micro

- Number of instances: 2

- VPC: Create a new VPC

- CIDR block: 10.32.0.0/16

- Subnet 1: 10.32.0.0/24

- Subnet 2: 10.32.1.0/24

- Security group: Create a new security group

- Security group inbound rules: Leave it at the default setting, which allows inbound traffic from all IP addresses on port 80.

Note: The message in the Container instance IAM role section states that you are granting permissions to Amazon ECS to create and use the ecsInstanceRole. This role authorizes the EC2 instances in the cluster to invoke Amazon ECS actions.

Choose Create.

The Launch Status page opens, and shows the tasks that the wizard performs.

Wait until all tasks have a check mark, which indicates that they are complete.

The resources that the wizard creates are listed in the Cluster Resources section.

Choose View Cluster.

The details page for the mb-ecs-cluster opens. The Status field shows a value of ACTIVE.

Choose the ECS Instances tab.

The two EC2 instances for the cluster (which the wizard created) are listed.

Note: It might take a few minutes for the two EC2 instances to show in the list. If you do not see both instances, choose Refresh.

[image]

Choose the Tasks tab.

No tasks are deployed to the cluster yet. You will create one next.

Task 4.2: Creating a Task Definition for the Application Container Image

A task definition is a list of configuration settings for how to run a Docker container on Amazon ECS.

It tells Amazon ECS various kinds of information, such as:

What container image to run
How much CPU and memory the container needs
What ports the container listens to traffic on In this subtask, you will create a task definition for the container image of the message board application.

In the navigation pane of the Amazon ECS console browser tab, choose Task Definitions.

Choose Create new Task Definition.

In the Select launch type compatibility page, choose the EC2 card.

Choose Next step.

The Configure task and container definitions page opens.

In the Task Definition Name box, enter mb-task.

Scroll down to Container Definitions and choose Add container.

The Add container window opens.

Configure the following settings.

Container name: mb-container
Image: Paste the Image URI of the application container image, which you copied to a text editor in a previous step.
Memory Limits: Select Hard limit and enter 256. (This setting defines the maximum amount of memory that the container is allowed to use.)
Port mappings > Container port: 3000 (This setting specifies the port where the container receives requests. You do not need to enter a value in Host port.) The Add container window should look similar to the following example: [image]

Choose Add.

Scroll down and choose Create. You can ignore any warnings.

A message displays, indicating that the task definition was successfully created. Notice that the definition is automatically assigned the version number of 1.

[image]

You now have a task definition that tells Amazon ECS how to deploy your application container across the cluster.

Task 4.3: Creating the Application Load Balancer

Next, you will create the Application Load Balancer that distributes incoming requests to the EC2 instances that run in the ECS cluster. This load balancer resides in the same VPC and uses the same security group as the ECS cluster.

In the Amazon ECS console browser tab, choose Services, and then select Compute > EC2.

In the navigation pane, scroll down and select Load Balancers.

Choose Create load balancer.

The Select load balancer type page opens.

In the Application Load Balancer card, choose Create.

The Application Load Balancer creation wizard opens.

Configure the following settings:
- Load balancer name: mb-load-balancer
- VPC: Select the Amazon ECS cluster VPC ID. This ID be similar to vpc-nnnnnnnnnn (10.32.0.0/16)
- Mappings: Select the first two Availability Zones in the list
  - Security groups:
    - Clear default.
    - Select EC2ContainerService-mb-ecs-cluster-EcsSecurityGroup. (This is the security group of your ECS cluster.)
- Listener HTTP:80
  - Select Create target group: New target group (You want the wizard to create a new target group for the load balancer.) The target group configuration screen opens in a new browser tab.
    - Target group type: Instances
    - Target group name: mb-load-balancer-target-group
    - Leave the protocol settings at their default values of HTTP and 80. The application expects to be accessed through RESTful HTTP requests.
    - VPC: Amazon ECS cluster VPC
    - Expand Advanced health check settings and enter the following settings.
      - Healthy threshold: 2 (This setting tells the load balancer that the target is considered healthy if it receives two consecutive successful health checks from it.)
      - Timeout: 5
      - Interval: 6 (This setting increases the frequency of health checks to once every 6 seconds.)
    - Choose Create target group.
- Return to the Load balancers browser tab
- Under Listener HTTP:80, refresh the target groups list. Select the mb-load-balancer-target-group you just created.
- Scroll to the bottom of the page and choose Create load balancer. A message should indicate that the load balancer was successfully created. Choose Close. The mb-load-balancer is now in the load balancer list.

Wait a few moments, then choose the Refresh icon. The State of the load balancer should change to active.

[image]

To complete the load balancer configuration, you will modify its security group to open the ports that allow internal communication between the load balancer and the instances in the ECS cluster.

In the Description tab at the bottom, scroll down to the Security section.

Next to Security Groups, choose the security group ID link, which should be similar to sg-nnnnnnnnnn.

The details page of the load balancer's security group opens.

To copy the security group ID to the clipboard, go to the Details tab (in the bottom pane), hover your pointer over the security group ID, and choose the Copy icon.

You will use this ID in a subsequent step.

In the bottom pane, select the Inbound rules tab.

The inbound rules for the security group are displayed.

Choose Edit inbound rules.

The Edit inbound rules dialog window opens.

Choose Add rule.

A new line appears in the rules list so that you can add a new rule. It is already preconfigured for a Custom TCP Rule, which is the type that you want to add.

In the new line, add the following configuration.

Port Range: 31000-61000
- Source > Custom: Paste the security group ID from the clipboard. Choose Save rules. The security group's inbound rules list shows the new rule that you added. [image]

Task 4.4: Deploying the Monolith as an ECS Service

You have created all the required Amazon ECS infrastructure components. In this subtask, you will deploy the containerized monolithic application to the cluster as an Amazon ECS service.

An ECS service enables you to simultaneously run and maintain a specified number of task definition instances in an ECS cluster. If one of the tasks fails or stops for any reason, the ECS service scheduler launches another task definition instance to replace it. Thus, it will maintain the desired count of tasks that were specified in the service.

You will now create an ECS service for the message board application's task definition by using the Amazon ECS console.

In the AWS Management Console browser tab, choose Services, and select Containers > Elastic Container Service.

In the navigation pane, choose Task Definitions.

In the Task Definition list, choose the mb-task link.

A page opens with the available revisions of the task definition.

Select mb-task:1 and choose Actions > Create Service.

In Step 1: Configure service, configure these settings.

Launch type: EC2 (You are running the containerized application directly on a cluster of EC2 instances.)
- Service name: mb-ecs-service
- Service type: REPLICA (This setting establishes a scheduling strategy that places and maintains the desired number of tasks across the ECS cluster.)
- Number of tasks: 1 (Normally, to take full advantage of the cluster, you would enter a higher number, depending on the request load that you expect. However, to keep things simple in this exercise, you specify that you want to launch and maintain one task on the cluster at all times.) Choose Next step.

In Step 2: Configure network, configure the following settings.

Load balancer type: Application Load Balancer (You want the tasks in your service to be load balanced by the mb-load-balancer that you set up earlier)
- Service IAM role: Create new role
- Load balancer name: mb-load-balancer
- Container name:port: This field is already populated with the correct container information that is associated with the task definition. Choose Add to load balancer. (This setting will associate the container with one of the load balancer's listeners.)
- Production listener port: 80:HTTP (This setting associates the container with the load balancer listener for HTTP traffic on port 80)
- Target group name: mb-load-balancer-target-group Choose Next step.

In Step 3: Set Auto Scaling (optional), choose Next step. You do not want to configure any additional automatic scaling.

In the Review page, make sure that the settings are correct and choose Create Service.

The Launch Status page opens, and shows the tasks that the wizard performs.

Wait until all tasks display check marks, which indicate that they are complete.

[image]

To open the details page for mb-ecs-service, choose View Service.

The Tasks tab shows that there is now one task that is running the container, with a status of ACTIVATING.

After a few moments, choose Refresh. The task's Last status should show: RUNNING.

[image]

You have successfully deployed the containerized monolith as an ECS service into the cluster.

Task 4.5: Testing the Containerized Monolith

You will now validate your deployment by testing the RESTful API methods of the message board application from a web browser.

First, you will find and record the URL of the load balancer.

In the Amazon ECS console browser tab, choose Services, and select Compute > EC2.

In the navigation pane, scroll down and choose Load Balancers.

The load balancer list shows the mb-load-balancer.

In the Description tab at the bottom, go to DNS name and choose the Copy icon.

Paste the DNS name value into a text editor, and label it Load Balancer DNS Name. You will use this value multiple times in later steps.

Open a new browser tab, paste the DNS name into the address bar, and press ENTER.

The page opens with the message Ready to receive requests. This message is returned by the message board application when no resource path is included in the GET request.

Troubleshooting tip: If you get a server-related HTTP error code, wait a few moments and then try again. It might take a few minutes for the container to register as healthy and begin receiving traffic.

In the browser address bar, add /api to the end of the URL and press ENTER.

[image]

The application should return the message API ready to receive requests.

Test the retrieval of all users in the database. In the browser address bar, add /users to the end of the URL and press ENTER.

[image]

The application returns a JSON object that lists the four users in the database.

Retrieve the information for the first user in the database. In the browser address bar, add /1 to the end of the URL and press Enter.

[image]

The application returns a JSON object that contains the information for Marcerline Singer, who is the first user in the database.

Next, you will retrieve all the threads in the database. In the browser address bar, change the URI after the load balancer DNS name to /api/threads and press ENTER.

The application returns a JSON object that contains the three threads in the database.

Finally, retrieve the posts for the second thread in the database. In the browser address bar, change the URI after the load balancer DNS name to /api/posts/in-thread/2 and press ENTER.

[image]

The application returns a JSON object that contains the posted messages for the second thread in the database. The messages are bakery-related.

Optionally, invoke other resource paths that the application can serve. When you are finished testing, close the application browser tab.

You have now successfully containerized the monolithic message board application and deployed it to an Amazon ECS environment.

Task 5: Refactoring the Monolith

In this task, you will break the containerized monolithic message board application into several interconnected microservices. You will then push each microservice image to an Amazon ECR repository. Each microservice performs a single business capability of the application, and can be scaled independently of the other microservices. The application is divided into the following microservices, which represent the top-level classes of objects that the application's API serves:

Users microservice – A service for all user-related REST paths (/api/users/*)
Threads microservice – A service for all thread-related REST paths (/api/threads/*)
Posts microservice – A service for all post-related REST paths (/api/posts/*)

To expedite the refactoring, a microservices version of the application is provided to you in the 3-containerized-microservices folder of your AWS Cloud9 environment.

The steps that you perform in this task are:

Review the refactored microservices application
Provision an Amazon ECR repository for each microservice
Build and push the images for each microservice #### Task 5.1: Reviewing the Refactored Microservices Application In this subtask, you will Take a few minutes to review the files to help you understand the changes that were made to refactor the application into microservices.

Switch to the AWS Cloud9 IDE browser tab.

In the Environment pane on the left, expand the 3-containerized-microservices folder.

This folder now has three separate subfolders named posts, threads, and users, which represent the three application microservices. Each subfolder contains the implementation files for the corresponding microservice.

Expand the posts, threads, and users subfolders.

[image]

Notice that each subfolder contains a copy of the same application files as those of the containerized monolith application. The db.json, Dockerfile, and package.json files in each subfolder are identical to their containerized monolith counterparts. The server.js file is the only file that changed from the refactoring.

In the users subfolder, open server.js in an editor tab by double-clicking it.

Lines 13 through 20 differ from the containerized monolith version in that the program defines only the API methods and implementations that are related to the users resource paths.

In the Threads subfolder, open server.js in an editor tab by double-clicking it.

Lines 13 through 20 differ from the containerized monolith version in that the program defines only the API methods and implementations that are related to the threads resource paths.

In the posts subfolder, open server.js in an editor tab by double-clicking it.

Lines 13 through 21 differ from the containerized monolith version in that the program defines only the API methods and implementations that are related to the posts resource paths.

In summary, the only change that is required to refactor the application is to split the RESTful API method handlers in the monolithic version of server.js into three separate server.js files. Each individual server.js file contains a relevant subset of the API method handlers.

Task 5.2: Provisioning an Amazon ECR Repository for Each Microservice

Similar to what you did for the containerized monolith version, you will now create an Amazon ECR repository for each application microservice.

You will now create a repository for the Users, Threads, and Posts microservice container images.

To open the Amazon ECR console, go to the AWS Management Console browser tab, choose Services, and then select Containers > Elastic Container Registry.

Choose Create repository.

In Repository name, enter mb-users-repo.

Choose Create repository. A message is displayed at the top of the page indicating that the repository was successfully created.

Repeat the previous steps to create two repositories for the other two microservices, with the following repository information.

Threads repository name: mb-threads-repo
Posts repository name: mb-posts-repo When you have created the repositories for all three microservices, the Repositories list should look like the following example: [image]

Task 5.3: Building and Pushing the Images for Each Microservice

Next, you will build each microservice container image and push it to its corresponding repository. In the following steps, you will use the ready-to-use commands that are provided by the Amazon ECR console to complete the task.

**Building And Pushing the Users microservice**

You will start with the container image for the Users microservice.

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, change the directory to the 3-containerized-microservices/users folder by entering the following command:

cd ~/environment/3-containerized-microservices/users

Switch to the Amazon ECR console browser tab.

In the Repositories list, select mb-users-repo.

At the top of the page, choose View push commands.

The Push commands for mb-users-repo pop-up window opens.

First, you will build the Docker image for the microservice.

In the Push commands for mb-users-repo window, copy the second command to the clipboard by selecting the Copy icon next to it. The command should look like:

docker build -t mb-users-repo .

Note: Make sure to include the period (.) at the end of the command.

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste the copied command and run it by pressing ENTER.

When the command is finished, you should see the messages Successfully built nnnnnnnnnn and Successfully tagged mb-users-repo:latest.

Next, you will tag the image with the repository URI so that it can be pushed the repository.

Switch to the Amazon ECR console browser tab.

In the Push commands for mb-users-repo window, copy the third command to the clipboard by selecting the Copy icon next to it. The command should look like:

docker tag mb-users-repo:latest 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-users- repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste the copied command and run it by pressing ENTER.

The command does not return anything if it completed successfully.

Finally, push the container image to the microservice repository.

Switch to the Amazon ECR console browser tab.

In the Push commands for mb-users-repo window, copy the fourth command to the clipboard by selecting the Copy icon next to it. The command should look like:

docker push 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-users-repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste the copied command and run it by pressing ENTER.

The command outputs several messages as each layer of the image is pushed to the repository.

You will now verify that the image was successfully uploaded.

Switch to the Amazon ECR console browser tab and close the Push commands for mb-users-repo pop-up window.

Choose the Refresh icon.

In the Images list, you see the container image that you pushed identified by the latest tag.

Record the Image URI. In the Images list, locate the Image URI of the latest version of the image and choose the Copy icon next to it.

Paste the value in a text editor and label it as Users Image URI. You will use it in a later step.

**Building And Pushing the Threads microservice**

Next, you will build and push the container image for the Threads microservice.

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, change the directory to the 3-containerized-microservices/threads folder by entering the following command:

cd ~/environment/3-containerized-microservices/threads

Switch to the Amazon ECR console browser tab.

In the navigation pane, choose Repositories and in the Repositories list, select mb-threads-repo.

Choose View push commands.

The Push commands for mb-threads-repo pop-up window opens.

First, you will build the Docker image for the microservice.

In the pop-up window, copy the second command by selecting the Copy icon. The command should look like:

docker build -t mb-threads-repo .

Note: Make sure to include the period (.) at the end of the command.

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste the copied command and run it.

When the command is finished, you see the messages Successfully built nnnnnnnnnn and Successfully tagged mb-threads-repo:latest.

Next, you will tag the image with the repository URI so that it can be pushed the repository.

Switch to the Amazon ECR console browser tab.

In the pop-up window, copy the third command by selecting the Copy icon. The command should look like:

docker tag mb-threads-repo:latest 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-threads-repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste the copied command and run it.

The command does not return anything if it completed successfully.

Finally, you will push the container image to the microservice repository.

Switch to the Amazon ECR console browser tab.

In the pop-up window, copy the fourth command by selecting the Copy icon. The command should look like:

docker push 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-threads-repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the Terminal tab, paste the copied command and run it.

The command outputs several messages as each layer of the image is pushed to the repository.

You will now verify that the image was successfully uploaded.

Switch to the Amazon ECR console browser tab and close the Push commands for mb-threads-repo pop-up window.

Choose the Refresh icon.

In the Images list, you should see the container image that you pushed, which can be identified by the latest tag.

Record the Image URI. In the Images list, go to the Image URI for latest version and choose the Copy icon.

Paste the value in a text editor and label it as Threads Image URI. You will use it in a later step.

**Building And Pushing the Posts microservice**

Lastly, you will build and push the container image for the Posts microservice.

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, change the directory to the 3-containerized-microservices/posts folder by entering the following command:

cd ~/environment/3-containerized-microservices/posts

Switch to the Amazon ECR console browser tab.

In the navigation pane, choose Repositories.

In the Repositories list, select mb-posts-repo.

Choose View push commands.

The Push commands for mb-posts-repo pop-up window opens.

First, you will build the Docker image for the microservice.

In the pop-up window, copy the second command. The command should look like:

docker build -t mb-posts-repo .

Note: Make sure that you include the period (.) at the end of the command.

Switch to the AWS Cloud9 IDE browser tab.

In the terminal tab, paste and run the copied command.

When the command is finished, you see the messages Successfully built nnnnnnnnnn and Successfully tagged mb-posts-repo:latest.

Next, you will tag the image with the repository URI so that it can be pushed the repository.

Switch to the Amazon ECR console browser tab.

In the pop-up window, copy the third command. The command should look like:

docker tag mb-posts-repo:latest 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-posts-repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the Terminal tab, paste and run the copied command.

The command does not return anything if it completed successfully.

Finally, you will push the container image to the microservice repository.

Switch to the Amazon ECR console browser tab.

In the pop-up window, copy the fourth command. The command should look like:

docker push 1234567890.dkr.ecr.us-east-2.amazonaws.com/mb-posts-repo:latest

Switch to the AWS Cloud9 IDE browser tab.

In the Terminal tab, paste and run the copied command.

The command outputs several messages as each layer of the image is pushed to the repository.

You will now verify that the image was successfully uploaded.

Switch to the Amazon ECR console browser tab.

Close the Push commands for mb-posts-repo pop-up window.

Choose the Refresh icon.

In the Images list, you should see the container image that you pushed, which should have the latest tag.

Record the Image URI. In the Images list, copy the Image URI of the latest version of the image.

Paste the value in a text editor and label it as Posts Image URI. You will use it in a later step.

You have successfully built container images for the microservices in your application and pushed them to Amazon ECR.

Task 6: Deploying the Containerized Microservices

In this task, you will deploy the containerized microservices message board application to the same ECS cluster that you used for the containerized monolith. You will also use the same Application Load Balancer from before. However, in this task, you will configure it to route requests to different target groups (one for each microservice container) based on the request URI path.

The following diagram shows the deployment architecture of the containerized microservices application. It also displays the resources that you will create.

The steps that you perform in this task are:

Create a task definition for each microservice.
Configure the Application Load Balancer
Deploy the microservices as ECS services.
Validate the deployment.

Task 6.1: Creating a Task Definition for Each Microservice

Because the microservices in the application are intended to run independently of each other, they each require their own task definition. In this subtask, you will create three task definitions that run the container image of each individual microservice.

**Creating A Task Definition for the Users container**

You will start by creating the task definition for the Users microservice container.

In the navigation pane of the Amazon ECS console, choose Task definitions, and then choose Create new Task Definition.

Note: You may need to expand the menu in the navigation pane to find Task Definitions.

In Step 2: Select launch type compatibility page, select the EC2 card.

Choose Next step.

In Step 2: Configure task and container definitions, configure the following settings:

- Task Definition Name: mb-users-task

- Scroll to the Container Definitions section and choose Add container. In the Add container page, enter these settings.

- Container name: mb-users-container

- Image: Paste the Users Image URI that you copied to a text editor in a previous step.

- Memory Limits: Make sure that Hard limit is selected, and enter 256. (This defines the maximum amount of memory that the container is allowed to use.)

- Port mappings > Container port: 3000 (This specifies the port on which the container receives requests.)

- Choose Add.

Scroll-down and choose Create.

A message indicates that the task definition was successfully created. Notice that the definition is automatically assigned the version number of 1.

**Creating A Task Definition for the Threads container**

Next, you will create the task definition for the Threads microservice container.

In the navigation pane, select Task Definitions and choose Create new Task Definition.

In Step 1: Select launch type compatibility, select the EC2 card.

Choose Next step.

In Step 2: Configure task and container definitions, configure the following settings.

- Task Definition Name: mb-threads-task.

- Scroll to the Container Definitions section and choose Add container. In the Add container page that opens, enter these settings.

- Container name: mb-threads-container

- Image: Paste the Threads Image URI that you copied to a text editor.

- Memory Limits: Make sure that Hard limit is selected, and enter 256.

- Port mappings > Container port: 3000

- Choose Add.

Scroll-down and choose Create.

A message indicates that the task definition was successfully created. The definition is automatically assigned the version number of 1.

**Creating A Task Definition for the Posts container**

Lastly, you will now create the task definition for the Posts microservice container.

In the navigation pane, select Task Definitions and then choose Create new Task Definition.

In Step 1: Select launch type compatibility, select the EC2 card.

Choose Next step.

In Step 2: Configure task and container definitions, configure these settings.

- Task Definition Name: mb-posts-task

- Scroll down to the Container Definitions section and choose Add container. In the Add container page, enter these settings.

- Container name: mb-posts-container

- Image: Paste the Posts Image URI that you copied.

- Memory Limits: Make sure that Hard limit is selected, and enter 256

- Port mappings > Container port: 3000

- Choose Add.

Scroll down and choose Create.

A message indicates that the task definition was successfully created. The definition is automatically assigned the version number of 1.

Task 6.2: Configuring the Application Load Balancer

In this subtask, you will create a new load balancer target group for each microservice so that requests can be routed to their container. You also configure the load balancer listener rule to forward requests to the correct target group, based on the request URI path.

**Creating A Target Group for the Users microservice**

In the Amazon ECS console browser tab, choose Services, and then select Compute > EC2.

In the navigation pane, scroll down and choose Target Groups.

Choose Create target group.

In Step 1: Specify group details, configure the following settings.

- Target group name: mb-lb-users-target-group

- VPC: Select the load balancer VPC ID. It should be similar to vpc-nnnnnnnnnn (10.32.0.0/16).

- Scroll down, expand Advanced health check settings, and enter these settings.

- Healthy threshold: 2 (This setting tells the load balancer that if it receives two consecutive successful health checks from a target, the target is considered healthy)

- Interval: 6 (This increases the frequency of health checks to once every 6 seconds)

Choose Next.

In Step 2: Register targets, choose Create target group.

A window opens with a message that the target group was successfully created.

Close the message window.

The mb-lb-users-target-group appears in the target group list.

**Creating A Target Group for the Threads microservice**

Next, you will create a target group for the Threads microservice.

Choose Create target group and in Step 1: Specify group details, configure these settings.

- Target group name: mb-lb-threads-target-group

- VPC: Select the load balancer VPC ID. It should be similar to vpc-nnnnnnnnnn (10.32.0.0/16)

- In the Advanced health check settings section, enter these settings.

- Healthy threshold: 2

- Interval: 6

Choose Next.

In Step 2: Register targets, choose Create target group.

A window opens with a message that the target group was successfully created.

Close the message window.

The mb-lb-threads-target-group appears in the target group list.

**Creating A Target Group for the Posts microservice**

Lastly, you will create a target group for the Posts microservice.

Choose Create target group and configure these settings.

- Target group name: mb-lb-posts-target-group

- VPC: Select the load balancer VPC ID. It should be similar to vpc-nnnnnnnnnn (10.32.0.0/16).

- In the Advanced health check settings section, enter these settings.

- Healthy threshold: 2

- Interval: 6

Choose Next, and then choose Create target group.

A window opens with a message that the target group was successfully created.

Close the message window.

The mb-lb-posts-target-group appears in the target group list.

Creating Listener Rules for the Load balancers

You have created the target groups for each microservice. You will modify the listener rules for the load balancer. These rules will route traffic to each load balancer, based on the request URI path.

Open the details page for mb-load-balancer by going to the navigation pane and selecting Load Balancers.

In the bottom pane, choose the Listeners tab.

Select the HTTP:80 listener and then from the Actions menu choose Manage rules.

The rules editor opens.

You will now create a new rule to forward a request to the Users target group if the request URI matches the pattern /api/users*.

In the tool bar at the top of the editor, add a new rule by choosing the Add rules (+) icon.

An Insert Rule line appears in the rules list.

Choose Insert Rule.

A rules box appears allowing you to add an IF condition and a THEN action.

Configure the following settings for this rule.

- Add condition: Path

- is > Value: /api/users*

- Add action: Forward to

- Forward to > Target group: mb-lb-users-target-group

The rules box should look like the following example:

[image]

Choose Save.

The rule is added to the list as rule 1.

You will now create a rule to forward a request to the Threads target group if the request URI matches the pattern /api/threads*.

In the line below rule 1, choose Insert Rule.

The rules editor opens.

Configure the following settings for this rule.

- Add condition*: Path*

- is > Value: /api/threads*

- Add action: Forward to**

- Forward to > Target group: mb-lb-threads-target-group

Choose Save.

The rule is added to the list as rule 2.

You will now create a new rule to forward a request to the Posts target group if the request URI matches the pattern /api/posts*.

In the line below rule 2, choose Insert Rule.

In the rules editor, configure these settings:

- Add condition: Path

- is > Value: /api/posts*

- Add action: Forward to

- Forward to > Target group: mb-lb-posts-target-group

Choose Save.

The rule is added to the list as rule 3.

Now, you will create a new rule to forward a request to the Users target group if the request URI matches the patterns of / or /api. You could select any of the application's target groups because their corresponding microservice can handle both types of requests.

In the line below rule 3, choose Insert Rule.

In the rules editor, configure these settings.

- Add condition: Path

- is > Value: /

- or > Value: /api

- Add action: Forward to

- Forward to > Target group: mb-lb-users-target-group

Choose Save.

The rule is added to the list as rule 4.

Lastly, you will change the action for the last (default) rule so that any other request URI returns an error page with the message Invalid request.

In the tool bar at the top, choose the Edit rules (pencil) icon.

The rules editor switches to edit mode.

Scroll to the last rule and choose the Edit Rule (pencil) icon.
In the rules editor, configure these settings.
- Then: Delete the existing Forward to action by choosing the Delete (trashcan) icon.
- Add action: Return fixed response
- Response code: 200
- Response body: Invalid request

The rules editor should look like this example:

[image]

Choose Update.

A message indicates that the rule was successfully updated.

The final listener rules for the load balancer should look like this example:

[image]

To return to the load balancer details page, choose the Back arrow icon (in the top-left area of the window).

You have completed the required changes to the load balancer configuration.

Task 6.3: Deploying the Microservices as ECS Services

In this subtask, you will deploy the three microservices to the cluster as ECS services.

Creating an ECS service for Users

You will now create an ECS service for the Users microservice task definition.

In the Amazon EC2 console browser tab, choose Services, and then select Containers > Elastic Container Service.

In the clusters list, choose mb-ecs-cluster.

In the Services tab, open the Create Service wizard by choosing Create.

In Step 1: Configure service, configure the following settings.

- Launch type: EC2 (You are running the containerized microservice directly on a cluster of EC2 instances.)

- Task Definition > Family: mb-users-task

- Service name: mb-users-ecs-service

- Service type: REPLICA (This setting establishes a scheduling strategy that places and maintains the desired number of tasks across the ECS cluster)

- Number of tasks: 1 (For this exercise, you want to launch and maintain one task on the cluster at all times)

Choose Next step.

In Step 2: Configure network, configure the following settings.

- Load balancer type: Application Load Balancer (You want the tasks in your service to be load balanced by the mb-load-balancer that you set up)

- Service IAM role: ecsServiceRole

- Load balancer name: mb-load-balancer

- Container to load balance: Add to load balancer

- Production listener port: 80:HTTP (You are associating the container with the load balancer listener that listens for HTTP traffic on port 80)

- Target group name: mb-lb-users-target-group

Choose Next step.

In Step 3: Set Auto Scaling (optional), choose Next step. You do not want to configure any additional automatic scaling.

In the Review page, make sure that the settings are correct and choose Create Service.

The Launch Status page opens, and shows the tasks that the wizard performs.

Wait until all tasks display a check mark to indicate that they are complete.

Choose View Service.

The details page for mb-users-ecs-service opens. The Tasks tab shows that there is now one task running the container.

After a few moments, choose the Refresh button.

The task's Last status should show a value of RUNNING.

Creating An ECS Service for Threads

Next, you will create an ECS service for the Threads microservice task definition.

To return to the cluster details page, in the breadcrumb trail at the top of the page, choose mb-ecs-cluster.

In the Services tab, choose Create.

In Step 1: Configure service, configure the following settings.

- Launch type: EC2

- Task Definition > Family: mb-threads-task

- Service name: mb-threads-ecs-service

- Service type: REPLICA

- Number of tasks: 1

Choose Next step.

In Step 2: Configure network, configure the following settings.

- Load balancing > Load balancer type: Application Load Balancer

- Load balancer name: mb-load-balancer

- Container to load balance: Add to load balancer

- Production listener port: 80:HTTP

- Target group name: mb-lb-threads-target-group

Choose Next step.

In Step 3: Set Auto Scaling (optional) page, click Next step.

In the Review page, make sure that the settings are correct and choose Create Service.

The Launch Status page opens and shows the tasks that the wizard performs.

Wait until all tasks display a check mark to indicate that they are complete.

Choose View Service.

The details page for mb-threads-ecs-service opens. The Tasks tab shows that one task is running the container.

After a few moments, choose Refresh. The task's Last status shows a value of RUNNING.

Creating An ECS Service for Posts

Lastly, create an ECS service for the Posts microservice task definition.

Return to the cluster details page for mb-ecs-cluster.

In the Services tab, choose Create.

In Step 1: Configure service, configure the following settings.

- Launch type: EC2

- Task Definition > Family: mb-posts-task

- Service name: mb-posts-ecs-service

- Service type: REPLICA

- Number of tasks: 1

Choose Next step.

In Step 3L Set Auto Scaling (optional), choose Next step.

In the Review page, make sure that settings are correct and choose Create Service.

The Launch Status page opens and shows the tasks that the wizard performs.

Wait until all tasks display a check mark to indicate that they are complete.

Choose View Service.

The details page for mb-posts-ecs-service opens. The Tasks tab shows that one task is running the container.

After a few moments, choose Refresh.

The task's Last status should show a value of RUNNING.

Return to the cluster details page for mb-ecs-cluster.

The three new services that you created are now in the Services list.

[image]

It should only take a few seconds for all your services to start. Double-check that all services and tasks are running and healthy before you proceed.

Task 6.4: Validating the Deployment

You will now test the RESTful API methods of the message board application from a web browser. You will also validate that the microservices-based implementation works correctly.

First, you will shut down the ECS service for the containerized monolith version of the application. You do not want it to serve any requests.

In the Services list, select mb-ecs-service, and choose Update.

The Update Service wizard opens.

For Number of tasks, change the value to 0. (This setting instructs Amazon ECS to not run any tasks for the service.)

Choose Skip to review.

In the Review page, choose Update Service.

The Launch Status page opens with a message that the service has been updated.

Choose View Service.

The details page for mb-ecs-service opens. The Deployments tab shows that the Running count for the service is 0.

Note: If you do not see the change immediately, wait a few seconds and choose Refresh.

[image]

Open a new browser tab, paste the Load Balancer DNS Name that you recorded earlier, and press ENTER.

This action returns the message Ready to receive requests. The application returns this message when no resource path is included in the GET request. Recall from the listener rules configuration that this type of request is sent to the Users microservice.

Add /api to the end of the URL and press ENTER.

The application—specifically, the Users microservice—returns the message API ready to receive requests.

Test the retrieval of all users in the database. Add /users to the end of the URL and press ENTER.

The Users microservice returns a JSON object that lists the four users in the database.

Retrieve the information for the first user in the database. Add /1 to the end of the URL and press ENTER.

The Users microservice returns a JSON object that contains the information for Marcerline Singer, who is the first user in the database.

Next, retrieve all the threads in the database. Change the URI after the load balancer DNS name to /api/threads and press ENTER.

The Threads microservice returns a JSON object that contains all three threads in the database.

Retrieve the posts for the second thread in the database. Change the URI after the load balancer DNS name to /api/posts/in-thread/2 and press ENTER.

The Posts microservice returns a JSON object that contains the posted messages for the second thread (which are bakery-related) in the database.

Finally, test the submission of a request with an invalid URI. Change the URI after the load balancer DNS name to /xyz and press ENTER.

The request is forwarded to default handler in the load balancer's listener rules, which returns the message Invalid request.

You have successfully converted a monolithic Node.js application to a microservices architecture. The original application ran, without containerization, directly on an instance. In contrast, microservices-based application is deployed in a containerized environment that is orchestrated by Amazon ECS.

DEV Community: Nick Goko

Provisioning with AWS CloudFormation

ProvisioningAWS CloudFormation

Mastering Conversations with ChatGPT: A Guide to Prominent Prompting Techniques

EC2 Auto Scaling

Prerequisites

Generate a Custom AMI of the web server.

Create a new Security Group for the Auto Scaling Group

Three Main Components to EC2 Auto Scaling on AWS

Penultimate Things We Must Do before We come to the End Is:

Configuring Security Groups

Add Inbound Rule to the Auto Scaling Security Group

Testing the AutoScaling Group

Breaking a Monolithic Node.js Application into Microservices

Task 2: Running the Application on a Basic Node.js Server

Task 2.1: Installing the Required Node.js Modules

Task 2.2: Reviewing the Application Design and Code

Task 2.3: Running the Application

Task 3: Containerizing the Monolith for Amazon ECS

Task 3.1: Preparing the Application for Docker Containerization

Task 3.2: Provisioning a Repository

Task 3.3: Building and Pushing the Docker Image

Task 4: Deploying the Monolith to Amazon ECS

Task 4.1: Creating an Amazon ECS Cluster

Task 4.2: Creating a Task Definition for the Application Container Image

Task 4.3: Creating the Application Load Balancer

Task 4.4: Deploying the Monolith as an ECS Service

Task 4.5: Testing the Containerized Monolith

Task 5: Refactoring the Monolith

Task 5.2: Provisioning an Amazon ECR Repository for Each Microservice

Task 5.3: Building and Pushing the Images for Each Microservice

Building And Pushing the Users microservice

Building And Pushing the Threads microservice

Building And Pushing the Posts microservice

Task 6: Deploying the Containerized Microservices

Task 6.1: Creating a Task Definition for Each Microservice

Creating A Task Definition for the Users container

Creating A Task Definition for the Threads container

Creating A Task Definition for the Posts container

Task 6.2: Configuring the Application Load Balancer

Creating A Target Group for the Users microservice

Creating A Target Group for the Threads microservice

Creating A Target Group for the Posts microservice

Creating Listener Rules for the Load balancers

Task 6.3: Deploying the Microservices as ECS Services

Creating An ECS Service for Threads

Creating An ECS Service for Posts

Task 6.4: Validating the Deployment

**Building And Pushing the Users microservice**

**Building And Pushing the Threads microservice**

**Building And Pushing the Posts microservice**

**Creating A Task Definition for the Users container**

**Creating A Task Definition for the Threads container**

**Creating A Task Definition for the Posts container**

**Creating A Target Group for the Users microservice**

**Creating A Target Group for the Threads microservice**

**Creating A Target Group for the Posts microservice**