Forem: Paloma Lataliza

Your containerized application with IAC on AWS — Pt.3

Paloma Lataliza — Thu, 23 May 2024 13:24:24 +0000

Hi Folks! This will be the final post in our series on infrastructure and containers. We will utilize Terragrunt and our infrastructure in this section, and at the conclusion, we will have our application operating on Fargate on AWS.

The docker image I’ll be using in this lesson comes from Sonic, an old game that many people associate with their early years. You may use this image or find it on my dockerhub, whichever you would like.

DIRECTORIES

Again, I’ll leave our directory structure here so you can guide yourself:

app
modules
    ├── amazon_vpc
    ├── aws_loadbalancer
    ├── aws_fargate
    ├── aws_roles
    ├── aws_ecs_cluster
    └── aws_targetgroup
    └── aws_certificate_manager

terragrunt
    └── dev
        └── us-east-1
            ├── aws_ecs
            │   ├── cluster
            │   └── service
            ├── aws_loadbalancer
            ├── amazon_vpc
            ├── aws_targetgroup
            ├── aws_roles
            ├── aws_certificate_manager
            └── terragrunt.hcl

TERRAGRUNT

First, let’s look at our terragrunt.hcl, located in us-east-1. It will be used for all common variables in our code, as well as for creating our backend settings and the lock in the dynamodb database.

Typical variables are going to be region, project_name, domain_name, env, host_headers and container_port.

terragrunt.hcl

remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    bucket           = "sonic-iac-series"
    key              = "dev/${path_relative_to_include()}/terraform.tfstate"
    region           = "us-east-1"
    encrypt          = true
    dynamodb_table   = "terraform-state-lock"
  }
}

inputs = {
   region            = "us-east-1"
   project_name      = "sonic-iac"
   env               = "dev"
   domain_name       = "your domain"
   host_headers      = "sonic.your domain"
   container_port    = "8080"

  tags = {
     ambiente        = "dev"
     projeto         = "sonic-iac"
     plataforma      = "aws"
     gerenciado      = "terraform/terragrunt"
   }
}

generate "provider" {
    path      = "provider.tf"
    if_exists = "overwrite"
    contents = <<EOF
provider "aws" {
  profile   = "default"
  region    = "us-east-1"
}
EOF
}

VPC

The first resource to be created will be the VPC, as it will be needed for most of our resources.

terragrunt
    └── dev
        └── us-east-1
             └── amazon_vpc
                 └── terragrunt.hcl

We will use a range of /25, starting with IP 172.35.0.221, to construct our VPC. Four subnets — two public and two private — will be created inside it.

VPC: 172.35.0.128/25
Public Subnet 1: 172.35.0.128/27
Public Subnet 2: 172.35.0.160/27
Private Subnet 1: 172.35.0.192/27
Private Subnet 2: 172.35.0.224/27 These code files will be created within:

terragrunt.hcl

include {
  path = find_in_parent_folders()
}

inputs = {
    vpc_cidr_block              = "172.35.0.128/25"
    public_subnet1_cidr_block   = "172.35.0.128/27"
    public_subnet2_cidr_block   = "172.35.0.160/27"
    private_subnet1_cidr_block  = "172.35.0.192/27"
    private_subnet2_cidr_block  = "172.35.0.224/27"
    availability_zone1 = "us-east-1a"
    availability_zone2 = "us-east-1b"
}
terraform {
  source = "../../../../modules/amazon_vpc"
  extra_arguments "custom_vars" {
    commands = [
        "apply",
        "plan",
        "import",
        "push",
        "refresh"
    ]
  }
}

IAM PERMISSIONS

The next thing to be created will be permissions for our resources.

terragrunt
    └── dev
        └── us-east-1
             └── aws_roles
                 └── terragrunt.hcl

terragrunt.hcl

include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../../../modules/aws_roles"
  extra_arguments "custom_vars" {
    commands = [
        "apply",
        "plan",
        "import",
        "push",
        "refresh"
    ]
  }
}

AWS CERTIFICATE MANAGER

These are the configurations for applying our certificate; we will generate the certificate and use our domain to validate it.

terragrunt
    └── dev
        └── us-east-1
             └── aws_certificate_manager
                 └── terragrunt.hcl

terragrunt.hcl

include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../../../modules/aws_certificate_manager"
  extra_arguments "custom_vars" {
    commands = [
        "apply",
        "plan",
        "import",
        "push",
        "refresh"
    ]
  }
}

AWS LOAD BALANCER

Let’s set up our loadbalancer using Terragrunt now. This will help distribute our traffic and guarantee that our application is highly available.

terragrunt
    └── dev
        └── us-east-1
             └── aws_loadbalancer
                 └── terragrunt.hcl

Our Terragrunt setup looks like this. It’s important to note that in order to increase everything’s dynamic nature, we use dependencies between modules.

terragrunt.hcl

include {
  path = find_in_parent_folders()
}

dependency "vpc" {
  config_path = "../amazon_vpc"
}

dependency "acm" {
  config_path = "../aws_certificate_manager"
}

inputs = {
  vpc_id       = dependency.vpc.outputs.vpc_id
  subnet_id_1  = dependency.vpc.outputs.public_subnet1_id
  subnet_id_2  = dependency.vpc.outputs.public_subnet2_id
  alb_internal = false
  certificate_arn = dependency.acm.outputs.acm_arn
  priority_listener_rule  = "1"
}
terraform {
  source = "../../../../modules/aws_loadbalancer"
  extra_arguments "custom_vars" {
    commands = [
      "apply",
      "plan",
      "import",
      "push",
      "refresh"
    ]
  }
}

AWS TARGET GROUP

Here we will configure our Target Group with Terragrunt, it is super essential for directing traffic to the correct servers for our application.

terragrunt
    └── dev
        └── us-east-1
             └── aws_targetgroup
                 └── terragrunt.hcl

terragrunt.hcl

include {
  path = find_in_parent_folders()
}
dependency "loadbalancer" {
  config_path = "../aws_loadbalancer"
}  
  dependency "vpc" {
  config_path = "../amazon_vpc"
}

dependency "acm" {
  config_path = "../aws_certificate_manager"
}

inputs = {
  vpc_id                  = dependency.vpc.outputs.vpc_id
  subnet_id_1             = dependency.vpc.outputs.public_subnet1_id
  subnet_id_2             = dependency.vpc.outputs.public_subnet2_id
  certificate_arn         = dependency.acm.outputs.acm_arn
  listener_ssl_arn        = dependency.loadbalancer.outputs.listener_ssl_arn
  priority_listener_rule  = "2"
  health_check_path       = "/"
}

terraform {
  source = "../../../../modules/aws_targetgroup"
  extra_arguments "custom_vars" {
    commands = [
      "apply",
      "plan",
      "import",
      "push",
      "refresh"
    ]
  }
}

ECS CLUSTER

In this step we will create our ECS cluster that will host our application.

terragrunt
    └── dev
        └── us-east-1
             └── aws_ecs
                 └── cluster
                       └── terragrunt.hcl

terragrunt.hcl

include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../../../../modules/aws_ecs_cluster"
  extra_arguments "custom_vars" {
    commands = [
        "apply",
        "plan",
        "import",
        "push",
        "refresh"
    ]
  }
}

FARGATE AND ECR

We will construct our fargate service, the repository in the ECR, and a record on our domain as the final configuration file.

terragrunt
    └── dev
        └── us-east-1
             └── aws_ecs
                 └── service
                       └── terragrunt.hcl

terragrunt.hcl

include {
  path = find_in_parent_folders()
}
dependency "loadbalancer" {
  config_path = "../../aws_loadbalancer"
}  
  dependency "vpc" {
  config_path = "../../amazon_vpc"
}
dependency "role" {
  config_path = "../../aws_roles"
}

dependency "targetgroup" {
  config_path = "../../aws_targetgroup"
}

dependency "cluster" {
  config_path = "../cluster"
}

inputs = {
  vpc_id                = dependency.vpc.outputs.vpc_id
  subnet_id_1           = dependency.vpc.outputs.private_subnet1_id
  subnet_id_2           = dependency.vpc.outputs.private_subnet2_id
  alb_dns_name          = dependency.loadbalancer.outputs.alb_dns_name
  sg_alb                = dependency.loadbalancer.outputs.alb_secgrp_id
  target_group_arn      = dependency.targetgroup.outputs.tg_alb_arn
  cluster_arn           = dependency.cluster.outputs.cluster_arn
  ecs_role_arn          = dependency.role.outputs.ecs_role_arn
  instance_count        = "1"
  container_vcpu        = "512"
  container_memory      = "1024"
  aws_account_id        = "your account number"
}

terraform {
  source = "../../../../../modules/aws_fargate"
  extra_arguments "custom_vars" {
    commands = [
        "apply",
        "plan",
        "import",
        "push",
        "refresh"
    ]
  }
}

APPLY

After the entire structure has been created, you must apply terragrunt to all directories that contain terragrunt.hcl in the following order.

terragrunt/dev/us-east-1
terragrunt/dev/us-east-1/amazon_vpc
terragrunt/dev/us-east-1/aws_roles
terragrunt/dev/us-east-1/aws_certificate_manager
terragrunt/dev/us-east-1/aws_loadbalancer
terragrunt/dev/us-east-1/aws_targetgroup
terragrunt/dev/us-east-1/aws_ecs/cluster
terragrunt/dev/us-east-1/aws_ecs/fargate
Use this command on terminal to apply. You need use in each directory

terragrunt apply

or in the root folder use:
terragrunt run-all apply

ECR

Now we have applied all our infrastructure and our ECR repository has been created, we must upload our image for use in our container.

The image must be downloaded from Docker Hub as an initial step. You can use another image if you prefer or your own from your application.

use this command to download my sonic image:
docker pull shescloud/sonic-the-hedgehog

TESTING

I used a domain I had and our application was temporarily hosted at sonic.shescloud.tech.

DESTROY
If you are using it for study, or as a way to complete a test, don’t forget to destroy all resources at the end to avoid unnecessary costs. To delete everything, we will do a process similar to apply, but in the opposite way.

Before deleting everything via terragrunt, you need to access your AWS account, go to the ECR service and delete the image from the repository. After completing this step, you can proceed with destroying each of the repositories.

Now, you must destroy to all directories that contain terragrunt.hcl in the following order.

terragrunt/dev/us-east-1/aws_ecs/fargate
terragrunt/dev/us-east-1/aws_ecs/cluster
terragrunt/dev/us-east-1/aws_targetgroup
terragrunt/dev/us-east-1/aws_loadbalancer
terragrunt/dev/us-east-1/aws_roles
terragrunt/dev/us-east-1/aws_certificate_manager
terragrunt/dev/us-east-1/amazon_vpc
terragrunt/dev/us-east-1

Use this command on terminal to destroy. You need use in each directory

terragrunt destroy

or in the root folder use:
`terragrunt run-all destroy

`

GITHUB

You can check the repository with the code on my github:
https://github.com/shescloud/terraform-terragrunt-fargate

And that’s it folks! I hope you enjoyed it and get a lot out of this code. See u soon!

Your containerized application with IAC on AWS — Pt.2

Paloma Lataliza — Fri, 03 May 2024 18:08:48 +0000

Hi everyone! We’ll see how to create our terraform modules in this blog article. Next, we’ll publish our application to AWS Fargate using the terraform modules we created here and also terragrunt.

TERRAFORM
We will establish our directory structure and our terraform module scripts in this blog article. We will set everything up and utilize terraform in conjunction with Terragrunt in part 3.

DIRECTORIES
Our codes must be organized at the directory level in order to use terraform and terragrunt:

app
modules
    ├── amazon_vpc
    ├── aws_loadbalancer
    ├── aws_fargate
    ├── aws_roles
    ├── aws_ecs_cluster
    └── aws_targetgroup
    └── aws_certificate_manager

terragrunt
    └── dev
        └── us-east-1
            ├── aws_ecs
            │   ├── cluster
            │   └── service
            ├── aws_loadbalancer
            ├── amazon_vpc
            ├── aws_targetgroup
            ├── aws_roles
            ├── aws_certificate_manager
            └── terragrunt.hcl

app: This is our infrastructure’s primary directory.
modules: Each unique AWS resource or service has a subdirectory within this directory. The modules will be inserted here, arranged according to resources like VPC, load balancers, ECS, etc.
Terraform subdirectories: Module-specific Terraform files are located in subdirectories like amazon_vpc and aws_loadbalancer.
Terragrunt: Terragrunt configurations are kept in this directory.
dev: Stands for the configuration of the development environment.
us-east-1: Configurations unique to the AWS region “us-east-1”.
Terragrunt subdirectories: Environment- and region-specific options for individual services may be found in the aws_ecs, aws_loadbalancer, amazon_vpc, etc. folders.
terragrunt.hcl: This is our Terragrunt configuration file, where we will include backend configurations as well as those that apply to all services in the “us-east-1” area of the development environment. -** Modules have three files**: variables.tf, main.tf, and _outputs.tf in each of the subdirectories. Roles will make use of a _data.tf
main.tf: The main.tf file, which defines and configures AWS resources, is the hub of the module.
variables.tf: Allows for module customisation and reuse by defining variables that the module will use.
_outputs.tf: Indicates which module outputs — information — will be accessible to other modules or the Terraform project in its whole.
_data.tf: To consult and look up information on already-existing resources or services, we shall utilize data.

RESOURCES
The following are the AWS resources that we will use:

VPC
SUBNETS
ROUTE TABLE
INTERNET GATEWAY
NAT GATEWAY
ELASTIC IP
ECR
SECURITY GROUP
APPLICATION LOAD BALANCER
FARGATE
ROUTE53
ACM
TERRAFORM MODULES

VPC
Let’s get started with VPC module creation. It will be necessary for each and every one of our apps’ network connections.

modules
 ├── amazon_vpc

main.tf

// Creat VPC
resource "aws_vpc" "vpc" {
  cidr_block           = var.vpc_cidr_block
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-vpc"
    },
    var.tags,
  )
}


// Creat public subnet1 for VPC
resource "aws_subnet" "public_subnet1" {
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = var.public_subnet1_cidr_block
  availability_zone = var.availability_zone1

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-public-subnet1"
    },
    var.tags,
  )
}


// Creat public subnet2 for VPC
resource "aws_subnet" "public_subnet2" {
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = var.public_subnet2_cidr_block
  availability_zone = var.availability_zone2

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-public-subnet2"
    },
    var.tags,
  )
}


// Creat private subnet1 for VPC
resource "aws_subnet" "private_subnet1" {
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = var.private_subnet1_cidr_block
  availability_zone = var.availability_zone1

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-private-subnet1"
    },
    var.tags,
  )
}


// Creat private subnet2 for VPC
resource "aws_subnet" "private_subnet2" {
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = var.private_subnet2_cidr_block
  availability_zone = var.availability_zone2

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-private-subnet2"
    },
    var.tags,
  )
}


// Create Internet gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.vpc.id

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}"
    },
    var.tags,
  )
}


// Creat route IGW VPC default rtb
resource "aws_default_route_table" "vpc_default_rtb" {
  default_route_table_id = aws_vpc.vpc.default_route_table_id

  # Internet gtw route
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-vpc-default-rtb"
    },
    var.tags,
  )
}


// Associate a public subnet1 with VPC
resource "aws_route_table_association" "public_subnet1_rtb_association" {
  subnet_id      = aws_subnet.public_subnet1.id
  route_table_id = aws_default_route_table.vpc_default_rtb.id
}

# Associate public subnet2 with VPC
resource "aws_route_table_association" "public_subnet2_rtb_association" {
  subnet_id      = aws_subnet.public_subnet2.id
  route_table_id = aws_default_route_table.vpc_default_rtb.id
}

# Create custom private route table 1 
resource "aws_route_table" "private_rtb1" {
  vpc_id = aws_vpc.vpc.id

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-rtb1"
    },
    var.tags,
  )
}


// Creat custom private route table 2
resource "aws_route_table" "private_rtb2" {
  vpc_id = aws_vpc.vpc.id

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-rtb2"
    },
    var.tags,
  )
}


// Creat EIP for nat1
resource "aws_eip" "eip1" {
  domain = "vpc"

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-eip1"
    },
    var.tags,
  )
}


// Creat EIP for nat2
resource "aws_eip" "eip2" {
  domain = "vpc"

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-eip2"
    },
    var.tags,
  )
}


// Creat NAT GTW1
resource "aws_nat_gateway" "nat_gtw1" {
  allocation_id = aws_eip.eip1.id
  subnet_id     = aws_subnet.public_subnet1.id

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-nat-gtw1"
    },
    var.tags,
  )
}


// Creat NAT GTW2
resource "aws_nat_gateway" "nat_gtw2" {
  allocation_id = aws_eip.eip2.id
  subnet_id     = aws_subnet.public_subnet2.id

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}-nat-gtw2"
    },
    var.tags,
  )
}


// Configure natgtw route private route table 1
resource "aws_route" "private_rtb1_nat_gtw1" {
  route_table_id         = aws_route_table.private_rtb1.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.nat_gtw1.id
}



// Configure nat gtw route private route table 2
resource "aws_route" "private_rtb2_nat_gtw2" {
  route_table_id         = aws_route_table.private_rtb2.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.nat_gtw2.id
}



// Associate private subnet1 VPC
resource "aws_route_table_association" "private_subnet1_rtb_association" {
  subnet_id      = aws_subnet.private_subnet1.id
  route_table_id = aws_route_table.private_rtb1.id
}



// Associate private subnet2 VPC
resource "aws_route_table_association" "private_subnet2_rtb_association" {
  subnet_id      = aws_subnet.private_subnet2.id
  route_table_id = aws_route_table.private_rtb2.id
}



resource "aws_security_group" "default" {
  name        = "${var.env}-${var.project_name}-sg-vpc"
  description = "Default security group to allow inbound/outbound from the VPC"
  vpc_id      = "${aws_vpc.vpc.id}"

  ingress {
    from_port = "0"
    to_port   = "0"
    protocol  = "-1"
    self      = true
  }

  egress {
    from_port = "0"
    to_port   = "0"
    protocol  = "-1"
    self      = "true"
  }
}

variables.tf

variable "vpc_cidr_block" {
}

variable "public_subnet1_cidr_block" {
}

variable "public_subnet2_cidr_block" {
}

variable "private_subnet1_cidr_block" {
}

variable "private_subnet2_cidr_block" {
}

variable "availability_zone1" {
}

variable "availability_zone2" {
}

variable "project_name" {
}

variable "env" {
}

variable "tags" {
  type = map(string)
}

_outputs.tf

output "vpc_arn" {
  value = aws_vpc.vpc.arn
}

output "vpc_id" {
  value = aws_vpc.vpc.id
}

output "vpc_main_rtb" {
  value = aws_vpc.vpc.main_route_table_id
}

output "vpc_cidr_block" {
  value = aws_vpc.vpc.cidr_block
}


output "public_subnet1_id" {
  value = aws_subnet.public_subnet1.id
}

output "public_subnet1_cidr_block" {
  value = aws_subnet.public_subnet1.cidr_block
}

output "public_subnet1_az" {
  value = aws_subnet.public_subnet1.availability_zone
}

output "public_subnet1_az_id" {
  value = aws_subnet.public_subnet1.availability_zone_id
}


output "public_subnet2_id" {
  value = aws_subnet.public_subnet2.id
}

output "public_subnet2_cidr_block" {
  value = aws_subnet.public_subnet2.cidr_block
}

output "public_subnet2" {
  value = aws_subnet.public_subnet2.availability_zone
}

output "public_subnet2_az_id" {
  value = aws_subnet.public_subnet2.availability_zone_id
}

output "private_subnet1_id" {
  value = aws_subnet.private_subnet1.id
}

output "private_subnet1_cidr_block" {
  value = aws_subnet.private_subnet1.cidr_block
}

output "private_subnet1_az" {
  value = aws_subnet.private_subnet1.availability_zone
}

output "private_subnet1_az_id" {
  value = aws_subnet.private_subnet1.availability_zone_id
}

output "private_subnet2_id" {
  value = aws_subnet.private_subnet2.id
}

output "private_subnet2_cidr_block" {
  value = aws_subnet.private_subnet2.cidr_block
}

output "private_subnet2_az" {
  value = aws_subnet.private_subnet2.availability_zone
}

output "private_subnet2_az_id" {
  value = aws_subnet.public_subnet2.availability_zone_id
}

output "igw_id" {
  value = aws_internet_gateway.igw.id
}

output "default_rtb_id" {
  value = aws_default_route_table.vpc_default_rtb.id
}

IAM PERMISSIONS
We need to create permissions for our services.

modules
 ├── aws_roles

_data.tf

data "aws_iam_policy_document" "ecs_service_role" {
  statement {
    actions = [
      "application-autoscaling:DeleteScalingPolicy",
      "application-autoscaling:DeregisterScalableTarget",
      "application-autoscaling:DescribeScalableTargets",
      "application-autoscaling:DescribeScalingActivities",
      "application-autoscaling:DescribeScalingPolicies",
      "application-autoscaling:PutScalingPolicy",
      "application-autoscaling:RegisterScalableTarget",
      "autoscaling:UpdateAutoScalingGroup",
      "autoscaling:CreateAutoScalingGroup",
      "autoscaling:CreateLaunchConfiguration",
      "autoscaling:DeleteAutoScalingGroup",
      "autoscaling:DeleteLaunchConfiguration",
      "autoscaling:Describe*",
      "ec2:CreateNetworkInterface",
      "ec2:DescribeDhcpOptions",
      "ec2:DescribeNetworkInterfaces",
      "ec2:DeleteNetworkInterface",
      "ec2:DescribeSubnets",
      "ec2:DescribeSecurityGroups",
      "ec2:DescribeVpcs",
      "ec2:AssociateRouteTable",
      "ec2:AttachInternetGateway",
      "ec2:AuthorizeSecurityGroupIngress",
      "ec2:CancelSpotFleetRequests",
      "ec2:CreateInternetGateway",
      "ec2:CreateLaunchTemplate",
      "ec2:CreateRoute",
      "ec2:CreateRouteTable",
      "ec2:CreateSecurityGroup",
      "ec2:CreateSubnet",
      "ec2:CreateVpc",
      "ec2:DeleteLaunchTemplate",
      "ec2:DeleteSubnet",
      "ec2:DeleteVpc",
      "ec2:Describe*",
      "ec2:DetachInternetGateway",
      "ec2:DisassociateRouteTable",
      "ec2:ModifySubnetAttribute",
      "ec2:ModifyVpcAttribute",
      "ec2:RunInstances",
      "ec2:RequestSpotFleet",
      "codebuild:BatchGetBuilds",
      "codebuild:StartBuild",
      "s3:GetObject",
      "s3:GetObjectVersion",
      "s3:GetBucketVersioning",
      "s3:PutObject",
      "s3:PutObjectAcl",
      "s3:ListBucket",
      "es:ESHttpPost",
      "ecr:*",
      "ecs:*",
      "ec2:*",
      "sqs:*",
      "cloudwatch:*",
      "logs:*",
      "iam:PassRole",
      "elasticloadbalancing:Describe*",
      "iam:AttachRolePolicy",
      "iam:CreateRole",
      "iam:GetPolicy",
      "iam:GetPolicyVersion",
      "iam:GetRole",
      "iam:ListAttachedRolePolicies",
      "iam:ListRoles",
      "iam:ListGroups",
      "iam:ListUsers",
      "iam:ListInstanceProfiles",
      "elasticfilesystem:*",
      "secretsmanager:GetSecretValue",
      "ssm:GetParameters",
      "ssm:GetParameter",
      "ssm:GetParametersByPath",
      "kms:Decrypt",
      "dynamodb:GetItem",
      "dynamodb:PutItem",
      "dynamodb:UpdateItem",
      "dynamodb:DeleteItem",
      "dynamodb:Query",
      "dynamodb:Scan",
    ]

    sid       = "1"
    effect    = "Allow"
    resources = ["*"]
  }
}

main.tf

// Creat policy
resource "aws_iam_policy" "ecs_service_policy" {
  name   = "${var.env}-${var.project_name}-policy"
  path   = "/"
  policy = data.aws_iam_policy_document.ecs_service_role.json
}

// Creat IAM Role
resource "aws_iam_role" "ecs_service_role" {
  name                  = "${var.env}-${var.project_name}-role"
  force_detach_policies = "true"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "1",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": [
          "ecs.amazonaws.com",
          "ecs-tasks.amazonaws.com",
          "codebuild.amazonaws.com",
          "codepipeline.amazonaws.com",
          "ecs.application-autoscaling.amazonaws.com",
          "ec2.amazonaws.com",
          "ecr.amazonaws.com"
        ]
      }
    }
  ]
}
EOF

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}"
    },
    var.tags,
  )
}

resource "aws_iam_policy_attachment" "ecs_service_role_atachment_policy" {
  name       = "${var.env}-${var.project_name}-policy-attachment"
  roles      = [aws_iam_role.ecs_service_role.name]
  policy_arn = aws_iam_policy.ecs_service_policy.arn
}

variables.tf

variable "env" {
}

variable "project_name" {
}


variable "tags" {
    type        = map(string)
  default     = {}
}

_outputs.tf

output ecs_role_arn {
    value = aws_iam_role.ecs_service_role.arn
}

AWS CERTIFICATE MANAGER

modules
 ├── aws_certificate_manager

We will also need a domain already configured in a zone hosted on AWS. With the domain created, we will create a valid TLS certificate within our account.

main.tf

// creat the certificate
resource "aws_acm_certificate" "cert" {
  domain_name       = "*.${var.domain_name}"
  validation_method = "DNS"

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}"
    },
    var.tags,
  )
  lifecycle {
    create_before_destroy = true
  }
}


// validation certificate
resource "aws_route53_record" "record_certificate_validation" {
  for_each = {
    for dvo in aws_acm_certificate.cert.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = "Z08676461KWRT5RHNLSKS"
}

variables.tf

variable "env" {
}

variable "domain_name" {
}

variable "project_name" {
}

variable "tags" {
  type    = map(string)
  default = {}
}

_outputs.tf

output "acm_arn" {
  value = aws_acm_certificate.cert.arn
}

AWS LOAD BALANCER
Here, we will create an application load balancer that will handle the balancing of our applications.

modules
 ├── aws_loadbalancer

main.tf

// Creat AWS ALB 
resource "aws_lb" "alb" {
  load_balancer_type         = "application"
  internal                   = var.alb_internal
  name                       = "${var.env}-alb-${var.project_name}"
  subnets                    = ["${var.subnet_id_1}", "${var.subnet_id_2}"]
  drop_invalid_header_fields = var.alb_drop_invalid_header_fields

  security_groups = [
    aws_security_group.alb.id,
  ]

  idle_timeout = 400

  dynamic "access_logs" {
    for_each = compact([var.lb_access_logs_bucket])

    content {
      bucket  = var.lb_access_logs_bucket
      prefix  = var.lb_access_logs_prefix
      enabled = true
    }
  }

  tags = {
    Name = "${var.env}-alb-${var.project_name}"
  }
}



//Creat SG ALB
resource "aws_security_group" "alb" {
  name        = "${var.env}-sg-alb-${var.project_name}"
  description = "SG for ECS ALB"
  vpc_id      = var.vpc_id

  revoke_rules_on_delete = "true"

  ingress {
    description = "TLS from VPC"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]

  }

  ingress {
    description = "HTTP from VPC"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]

  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }


  tags = {
    Name = "${var.env}-alb-${var.project_name}"
  }
}

//Creat default TG - ALB
resource "aws_alb_target_group" "target_group" {
  name        = "${var.env}-tg-default-alb"
  port        = 80
  protocol    = "HTTP"
  target_type = "ip"
  vpc_id      = var.vpc_id

  lifecycle {
    create_before_destroy = true
  }

  tags = merge(
    {
      "Name" = "${var.env}-tg-${var.project_name}"
    },
    var.tags,
  )
}


// Creat HTTPS listener
resource "aws_alb_listener" "listener_ssl" {
  load_balancer_arn = aws_lb.alb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = var.certificate_arn

  default_action {
    target_group_arn = aws_alb_target_group.target_group.arn
    type             = "forward"
  }
  depends_on = [
    aws_alb_target_group.target_group
  ]
}


resource "aws_alb_listener_rule" "ssl_listener_rule" {
  action {
    target_group_arn = aws_alb_target_group.target_group.arn
    type             = "forward"
  }

  condition {
    host_header {
      values = ["default.${var.domain_name}"]
    }
  }

  priority     = var.priority_listener_rule
  listener_arn = aws_alb_listener.listener_ssl.arn

  depends_on = [
    aws_alb_listener.listener_ssl,
    aws_alb_target_group.target_group
  ]
}


// Creat HTTP listener
resource "aws_lb_listener" "listener_http" {
  load_balancer_arn = aws_lb.alb.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type = "redirect"

    redirect {
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }

}

variables.tf

variable "alb" {
  default = true
}

variable "alb_http_listener" {
  default = true
}

variable "alb_sg_allow_test_listener" {
  default = true
}

variable "alb_sg_allow_egress_https_world" {
  default = true
}

variable "alb_only" {
  default = false
}

variable "alb_ssl_policy" {
  default = "ELBSecurityPolicy-2016-08"
  type    = string
}

variable "alb_internal_ssl_policy" {
  default = "ELBSecurityPolicy-TLS-1-2-Ext-2018-06"
  type    = string
}

variable "alb_drop_invalid_header_fields" {
  default = true
  type    = bool
}

variable "lb_access_logs_bucket" {
  type    = string
  default = ""
}

variable "lb_access_logs_prefix" {
  type    = string
  default = ""
}

variable "vpc_id" {
  type    = string
  default = ""
}

variable "subnet_id_1" {
  type    = string
  default = ""
}

variable "subnet_id_2" {
  type    = string
  default = ""
}

variable "project_name" {
  type    = string
  default = ""
}

variable "env" {
  type    = string
  default = ""
}

variable "alb_internal" {
  type    = bool
  default = false
}

variable "certificate_arn" {
  type    = string
  default = ""
}

variable "tags" {
  type    = map(string)
  default = {}
}

variable "priority_listener_rule" {
}

variable "domain_name" {
}

outputs.tf

output "alb_arn" {
  value = aws_lb.alb.arn
}

output "alb_dns_name" {
  value = aws_lb.alb.dns_name
}


output "alb_secgrp_id" {
  value = aws_security_group.alb.id
}


output "alb_arn_suffix" {
  value = trimspace(regex(".*loadbalancer/(.*)", aws_lb.alb.arn)[0])
}

output "listener_ssl_arn" {
  value = aws_alb_listener.listener_ssl.arn
}

AWS TARGET GROUP
Moving forward, let’s look at the codes that will comprise our TG.

modules
 ├── aws_targetgroup

main.tf

//Creat Target Group
resource "aws_alb_target_group" "target_group" {
  name        = "${var.env}-tg-${var.project_name}"
  port        = 80
  protocol    = "HTTP"
  target_type = "ip"
  vpc_id      = var.vpc_id

  health_check {
    matcher             = "200-299"
    path                = var.health_check_path
    port                = var.container_port
    protocol            = "HTTP"
    unhealthy_threshold = 8
    timeout             = 10
  }


  lifecycle {
    create_before_destroy = true
  }

  tags = merge(
    {
      "Name" = "${var.env}-tg-${var.project_name}"
    },
    var.tags,
  )
}



// Creat HTTPS listener rule
resource "aws_alb_listener_rule" "ssl_listener_rule" {
  action {
    target_group_arn = aws_alb_target_group.target_group.arn
    type             = "forward"
  }

  condition {
    host_header {
      values = ["${var.host_headers}"]
    }
  }

  priority     = var.priority_listener_rule
  listener_arn = var.listener_ssl_arn

}

variables.tf

variable "project_name" {
}

variable "env" {
}

variable "certificate_arn" {
}

variable "tags" {
  description = "Mapa de tags para serem aplicadas aos recursos."
  type        = map(string)
  default     = {}
}

variable "vpc_id" {
}

variable "subnet_id_1" {
}

variable "subnet_id_2" {
}

variable "listener_ssl_arn" {
}

variable "priority_listener_rule" {
}

variable "host_headers" {
}

variable "health_check_path" {
}

variable "container_port" {
}

_outputs.tf

output "tg_alb_arn" {
  value = aws_alb_target_group.target_group.arn
}

output "tg_arn_suffix" {
  value = regex(".*:(.*)", aws_alb_target_group.target_group.arn)[0]
}

ECS and ECR
All of the container configurations will be made here. We will build an ECS cluster first, and then a fargate service with all the necessary components. To host our application image, we will construct a repository in ECR in addition to the cluster and service.

ECS CLUSTER
modules
 ├── aws_cluster

main.tf

// Creat ECS cluster ECS 
resource "aws_ecs_cluster" "ecs" {
  name = "${var.env}-${var.project_name}"

  setting {
    name  = "containerInsights"
    value = var.container_insights ? "enabled" : "disabled"
  }

  lifecycle {
    ignore_changes = [
      tags
    ]
  }

}

variables.tf

variable "project_name" {
  type        = string
  default     = ""
}

variable "env" {
  type        = string
  default     = ""
}

variable "container_insights" {
  type        = bool
  default     = false
}

_outputs.tf

output "cluster_name" {
  value = aws_ecs_cluster.ecs.name
}

output "cluster_arn" {
  value = aws_ecs_cluster.ecs.arn
}

FARGATE

modules
 ├── aws_fargate

main.tf

//Creat ECR repositpry
resource "aws_ecr_repository" "ecs_cluster_ecr" {
  name = "${var.env}-${var.project_name}"

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}"
    },
    var.tags,
  )
}

//Creat Route53 record 
resource "aws_route53_record" "record_sonic" {
  zone_id = "Z08676461KWRT5RHNLSKS"
  name    = "${var.host_headers}"
  type    = "CNAME"
  ttl     = 300
  records = [var.alb_dns_name]
}

//Creat Task Definition
resource "aws_ecs_task_definition" "ecs_task_definition" {
  family = "${var.env}-task-def-${var.project_name}"

  container_definitions = <<DEFINITION
[
  {
    "name":  "${var.env}-${var.project_name}" ,
    "image": "${var.aws_account_id}.dkr.ecr.${var.region}.amazonaws.com/${var.env}-${var.project_name}:latest",
    "essential": true,
    "memoryReservation": 64,
    "portMappings": [{
      "containerPort": ${var.container_port}
    }],
    "environment": [
      {
        "name": "ENV_PORT",
        "value": "${var.container_port}"
      },
      {
        "name": "ENVIRONMENT",
        "value": "${var.env}"
      }
    ],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "ecs-${var.env}-${var.project_name}",
        "awslogs-region": "${var.region}",
        "awslogs-create-group": "true",
        "awslogs-stream-prefix": "${var.env}-${var.project_name}"
      }
    }
  }
]

DEFINITION


  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  task_role_arn            = var.ecs_role_arn
  execution_role_arn       = var.ecs_role_arn
  cpu                      = var.container_vcpu
  memory                   = var.container_memory
}


//Creat Fargate Service
resource "aws_ecs_service" "ecs_service" {
  name            = "${var.env}-${var.project_name}-service"
  cluster         = "${var.cluster_arn}"
  task_definition = aws_ecs_task_definition.ecs_task_definition.arn
  desired_count   = var.instance_count
  launch_type     = "FARGATE"

  load_balancer {
    target_group_arn = var.target_group_arn
    container_name   = "${var.env}-${var.project_name}"
    container_port   = var.container_port
  }

  network_configuration {
    security_groups  = [aws_security_group.sg_ecs.id]
    subnets          = ["${var.subnet_id_1}", "${var.subnet_id_2}"]
    assign_public_ip = "false"
  }

  deployment_minimum_healthy_percent = 50
  deployment_maximum_percent         = 400

  tags = merge(
    {
      "Name" = "${var.env}-${var.project_name}"
    },
    var.tags,
  )
}



///Creat SG to ECS
resource "aws_security_group" "sg_ecs" {
  name                   = "${var.env}-sg-ecs-${var.project_name}"
  description            = "SG for ECS"
  vpc_id                 = var.vpc_id
  revoke_rules_on_delete = "true"

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.env}-sg-ecs-${var.project_name}"
  }
}

// SG rule ALB
resource "aws_security_group_rule" "rule_ecs_alb" {
  description              = "from ALB"
  type                     = "ingress"
  from_port                = 0
  to_port                  = 0
  protocol                 = "-1"
  security_group_id        = aws_security_group.sg_ecs.id
  source_security_group_id = var.sg_alb
}

// SG rule ECS
resource "aws_security_group_rule" "in_ecs_nodes" {
  description              = "from ECS"
  type                     = "ingress"
  from_port                = 0
  to_port                  = 0
  protocol                 = "-1"
  security_group_id        = aws_security_group.sg_ecs.id
  source_security_group_id = aws_security_group.sg_ecs.id
}

variables.tf

variable "env" {
}

variable "region" {
}

variable "project_name" {
}

variable "container_port" {
}

variable "instance_count" {
}

variable "container_vcpu" {
}

variable "container_memory" {
}

variable "vpc_id" {
}

variable "subnet_id_1" {
}

variable "subnet_id_2" {
}

variable "aws_account_id" {
}

variable "tags" {
  type    = map(string)
  default = {}
}

variable "ecs_role_arn" {
}

variable "target_group_arn" {
}

variable "sg_alb" {
}

variable "cluster_arn" {
}


variable "host_headers" {
}

variable "alb_dns_name" {
}

_outputs.tf

output "sg_ecs" {
  value = aws_security_group.sg_ecs.id
}

output "service_name" {
  value = aws_ecs_service.ecs_service.name
}

Our modules are ready, and in the next section, we will create the hcl for Terragrunt and also apply our code. See Ya!

Your containerized application with IAC on AWS — Pt.1

Paloma Lataliza — Fri, 03 May 2024 17:09:58 +0000

These days, automation and efficiency are critical in the realm of cloud computing. The administration of your containerized apps may be optimized with AWS Fargate and Infrastructure as Code (IaC). This blog article will walk you through the process of utilizing these potent technologies to increase your applications scalability and efficiency.

FARGATE
Amazon’s container computing service, Fargate, allows you to use AWS containers without the need to manage servers.
I have written a blog article regarding Fargate that you may read here.

INTRODUCTION TO INFRASTRUCTURE AS CODE (IAC)
Infra as code is super important when we think about a stable, scalable and prepared infrastructure for any accident. You may use software development methods like code review and continuous testing, as well as version, reuse and share your configuration by describing your infrastructure in configuration files.

I’ve written a blog article about Terraform and Terragrunt, which we’ll be using in this instance.

CONNECTING AWS TO YOUR COMPUTER
With the help of the AWS CLI, you can easily control AWS services from the terminal on your PC. It allows you to use scripts to automate operations and manage a variety of AWS services.

INSTALLATION OF AWS CLI
windows
Go to the official AWS website and download the MSI installation.

Linux
To download the installation package, use curl. Apply the subsequent command:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.30.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

To confirm if it was installed, run the command:

aws --version

MacOs
Run the installer after downloading it from this link: https://awscli.amazonaws.com/AWSCLIV2-2.0.30.pkg

which aws
aws --version

…………………………………

INSTALLATION OF TERRAFORM AND TERRAGRUNT
TERRAFORM
Linux
First, open your terminal. We’ll use wget or curl to download the latest version of Terraform:

wget https://releases.hashicorp.com/terraform/1.1.0/terraform_1.1.0

Now, if unzip isn’t already installed, let’s install it before unzipping the file:

sudo apt-get install unzip -y
unzip terraform_1.1.0_linux_amd64.zip

In this step, we will move the terraform executable to a directory included in your system PATH, such as /usr/local/bin:

sudo mv terraform /usr/local/bin/

Finally, we’ll check if the installation is legitimate:

terraform -version

Windows

1.Visit the official Terraform website and get the Windows binary that is needed.

Use WinZip, WinRAR or another unzip application, to extract the file.
Put Terraform in the Path System

Click “This Computer” with a right-click, then choose “Properties.”
Select ‘Environment Variables’ after selecting ‘Advanced System Settings’.
Locate the Path variable under ‘System Variables’ and modify it by adding the path of the directory where you unpacked Terraform.

Use the Command Prompt to Confirm Installation:

terraform -version

MacOs
We are going to start installing Homebrew. If you do not yet have Homebrew, you may install it using this command on the terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Here, we will install the terraform using Brew. Without a terminal, run:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Finally, we will check whether everything is well with our installation:

terraform -version

TERRGRUNT
Windows : You can install Terragrunt on Windows by using Chocolatey :.choco install terragrunt

MacOS : You can install Terragrunt on Mac by using Homebrew :.brew install terragrunt

Linux : Most Linux users are able to use Homebrew : brew install terragrunt. Users of Arch Linux can utilize pacman -S terragruntto install it community-terragrunt.

FreeBSD : You can install Terragrunt on FreeBSD by using Pkg :.pkg install terragrunt

……………………………………

Configure AWS CLI
In this blog article, we will create a new user and configure our credentials. This user here belongs to the adm group, but be careful when it is necessary to give permissions to other people who use your account or who are users of your organization. Adopt the concept of least privilege always. You may read more about IAM on my blog post here.

We navigate to IAM -> Users -> Create User. Once the user is created, we will create the credentials. To do this, log in with your credentials and select Security Credentials -> Access Keys -> Create Access Key.

Remember to copy the credentials exactly as they were created.

After creating the credentials, lets open a terminal and set up the AWS CLI. To do this, type the command below and provide your credentials:

aws configure

To test, simply run a command for any service. Here we will try to list the EC2 instances of the account.

aws ec2 describe-instances

If it returns anything like the code below, it means that it worked. If there is no instance, the code below will be returned; if there is an instance, the information from the GIF conformation will be returned.

{
    "Reservations": []
}

……………………………………

Now that the requirements are all up and operational, we can use Terraform and Terragrunt to build our infrastructure.
In part two of this series, let’s see how. See Ya!

AWS Amplify: A Game-Changer for Developers

Paloma Lataliza — Fri, 03 May 2024 17:02:42 +0000

Hi Folks,

Today we’re going to talk a little about Amplify. An AWS tool that I’ve been testing for a few days and that has helped me a lot. I’m sure you’ll love this if you build mobile or web apps or just love technology as much as I do. Together, let’s explore the wonders of AWS Amplify and discover why developers are increasingly turning to it as their toolbox of choice.

Anyhow, what is Amazon Amplify?
Imagine having a toolbox full of everything you need to build, deploy, and maintain your applications. We were able to do this with Amplify and thanks to its seamless interaction with front-end and back-end technologies, it is more than just a platform; It’s a really cool way for people who work as developers to simplify and have an easier time using features like user authentication, data storage, API wizard, and more.

Why AWS Amplify Rocks

Simple Authentication: Are you sick of having to log in and out? With their really unique authentication solutions, which include clever social sign-ins, Amplify has you covered.
Data Storage: Akin to Taking a Cloud Walk Data management and storage are a breeze with Amazon S3 and Amazon DynamoDB.
Talk Nerdy to Me About API Integration: GraphQL and REST APIs without the headache? Sure, please!
Hosting: The Cloud-Based Home of Your Website: Hosting that is scalable, effective, and all around fantastic for your online projects.
Be Adaptable, Scale Up: Amplify expands with you, whether it’s a tiny blog or the upcoming popular social media app.
Feelings in the Community: Have a query? The community has solutions. It resembles a tech family!

Final Thoughts
There you have it, the full splendor of AWS Amplify. It is simultaneously a tech revolution, a game-changer, and a lifesaver. Regardless of your level of experience as a developer, Amplify is absolutely worth checking out.
Although AWS Amplify is fantastic, there is a slight learning curve and you will find that you will need to study a little more to use the features 100%.

AWS Re:Invent 2022

Paloma Lataliza — Fri, 03 May 2024 17:00:47 +0000

O QUE É O RE:INVENT
Todo ano no final de novembro em Las Vegas, a AWS promove um evento incrível, que reúne pessoas do mundo inteiro para anunciar as novas tecnologias ou features AWS, trazer conteúdo técnico com várias palestras, workshops, exposição de parceiros em tech e muitas sessões onde você tem a oportunidade de discutir e aprender muito.

As atividades são separadas por níveis da seguinte forma:

level 100 — Foundational (iniciante)
level 200 — Intermediate (intermediário)
level 300 — Advanced (Avançado)
level 400 — Expert (Especialista)

Você pode participar de duas formas, assistindo o evento de forma online e que é gratuito ou comprar o ingresso para participar de forma presencial em Las Vegas. Você pode se inscrever para o desse ano clicando aqui.

Geralmente o evento ocorre vários dos grandes hoteis cassinos em Las Vegas simultaneamente, como o The Venetian, Caesars Forum, MGM Grand, Wynn, Encore e Mandalay Bay.

MINHA EXPERIÊNCIA

No ano passado eu tive a oportunidade de estar presente e a experiência foi incrível. Muito mais do que as sessões técnicas, tive a oportunidade de estar lado a lado de grandes pessoas da AWS para retirar dúvidas e expor minhas ideias, assim como conheci pessoas fora da curva que vieram de todo canto do mundo o que me proporcionou uma visão macro de como a tecnologia tem influênciado os mais diversos países. Posso dizer que o networking é um ponto muito forte do evento.

O evento é divido por sessões em vários dos grandes hoteis cassino de Vegas, então é preciso se programar bem para conseguir ver as palestras que gostaria. Os tópicos que mais me chamaram atenção foram serverless e containers, e minha grade de talks, workshops, encontros foram voltadas para esse assunto.

Além das pessoas, do conhecimento adquirido, tudo foi super divertido, participei de inúmeros games envolvendo tecnologia, descobri como funciona o serverless expresso (cafezim nosso de cada dia) e ganhei muitos brindes. Foram tantos brindes que precisei até comprar uma mala nova para trazer tanta coisa.

COMUNIDADE

Mais um ponto forte de estar presente no re:Invent é se conectar com as comunidades AWS de todo mundo, abrir portas e abranger ideias que podemos também implementar aqui no Brasil. Participei de jantares e encontros voltados para builders e líderes dos grupos de usuários dos mais diversos países e o intercambio de conhecimento foi sensacional.

SE VOCÊ PRETENDENTE IR AO RE:INVENT ESSE ANO, SE LIGA NESSAS DICAS

Las Vegas fica em meio a um deserto, onde a noite faz muito frio, durante o dia tem um sol absurdo e muitas das vezes você vai colocar o casaco pelo frio e logo depois retira-lo pelo calor. Então considere levar roupas de frio, mas também roupas leves.
O protetor labial, soro fisiologico, hidratante facil e protetor solar vão virar seus melhores amigos. Por causa do tempo seco eu tive muuuuitos problemas com nariz e o soro me ajudou muit, labios e pele extremamente ressacados e muito sol, então leve esses produtinhos para te ajudar a ter uma experiência melhor no evento.
Ainda falando sobre conforto, considere seriamente em ter um tenis ou outro calçado super confortavel, pois por ser um evento que acontece em vários locais simultaneamente, acaba que andamos muitooooo e no final do dia, seus pezinho vão agradecer muuuito.
Considere muito se hospedar em um hotel perto do Venetian, assim você estará relativamente perto dos demais hoteis do evento e os keynotes acontecem nesse hotel, então facilita muito.
Uma dica super importante é assim que receber acesso a plataforma para ver as sessões do evento, já faça sua grade, pois como o volume de pessoas é muito grande, os lugares esgotam muuuito rápido.
Usar o app Events da AWS para conferir as sessões que você marcou, assim como o local delas é muito importante, pois assim você consegue seguir seu planejamento sem muito estresse.
Considere muito ter espaços nas sua agenda para ir a expo do evento e também fazer networking, assim você vai ter uma experiência mais completa
Outra coisa super legal e ter sempre na mão o QR do seu likendin ou redes sociais, assim a gente consegue se conectar de forma mais facil com as pessoas que conhecemos.
Chegue sempre uns 5 minutos antes na sua sessão, o pessoal é super pontual e se você se atrasar eles vão ceder sua vaga para quem está esperando na fila. Isso também é uma dica para caso você queira ver uma sessão que está com os lugares no app esgotados, chegue antes e fique na fila de espera, caso o pessoal não chegue na hora, você conseguirá entrar.
Para ir de um hotel ao outro a AWS fornecem os shuttles, que são onibus que nos levam para os hoteis desejados. É importante checar qual é o ponto de cada shuttle de acordo com o hotel que você pretende ir, as vezes o que tem destino para um hotel determinado fica em um ponto diferente de um outro hotel X.
Curta bastante, interaja, não tenha medo de falar. Eu fiquei super tímida pelo meu inglês e vejo que se tivesse me soltado mais nos primeiros dias, minha experiência teria sido mais fantastica ainda. Ps: Ninguém está ligando se você fala bem ou mal, se erra ou pronuncia errado, o que conta é se comunicar

NOVIDADES QUE ACHEI SUPER INTERESSANTES
AWS Application Composer

O application composer é um serviço que foi lançado pra ajudar a gente a construir de maneira visual aplicações serverless. Ele funciona basicamente com a gente escolhendo os serviços que nossa aplicação vai ter e conectando eles. No final ele gera um template do cloudformation de acordo com a arquitetura que criamos manualmente.

Amazon CodeWhisperer

Uma outra novidade que me deixou super encantada foi o CodeWhisperer, que é um recurso que usa aprendizado de máquina e grandes modelos de linguagem para gerar recomendações ali no nosso editor de texto com base no código que a gente já escreveu e também nos comentários em linguagem natural. O que é super legal também é que ele analisa nosso codigo já batido e nos fala quais são os serviços de nuvem, bibliotecas e frameworks que são mais adequados para o nosso cenário ali.

Ele suporta as linguagens Python, Java e JavaScript C# e TypeScript. Você pode usar ele no Visual Studio Code, JetBrains, Cloud9 e Lambda

Lambda SnapStart

Falando sobre serverless, a AWS anunciou um recurso bem legal no lambda que é basicamente a redução do cold start para funções em Java. O snapStart tá disponível pro Corretto java 11 runtime e ajuda a reduzir até 90% do cold start das funções java. Para entender como ele funciona precisamos analisar o clico de vida do lambda que possui 03 estágios, a inicialização, que é onde rola a treta do cold start, a invocação da função em si e depois o shutdown.

O que rola pra dimunuir o Cold start quando a gente ativa o snapStart, é que o código da função é inicializado antes mesmo dela ser invocada, acontece um snapshot imutável e encriptado da memória e do estado de disco do nosso ambiente de execução inicializado e esse snapshot fica cacheado para as próximas execuções daquela função. Então, nas próximas execuções daquela função, ela vai criar um ambiente de execução novo e esse ambiente vai ser criado a partir do snapshot que tá lá em cache ao invés de inicializar ele totalmente do zero, que era o que rolava antes e com isso acontece a redução drástica do cold start.

Ter participado do AWS re: Invent 2022 foi uma experiência inigualável. O vento foi fantástico e trouxe comigo boas lembranças, bastante conhecimento sobre tecnologia e tendências da computação em nuvem e amizades. E para fechar tudo com chave de ouro teve o re:Play, uma suuuuper festa com música ao vivo, luzes, comida e muita gente animada!

Você já ouviu falar em Kubernetes?

Paloma Lataliza — Fri, 03 May 2024 16:56:15 +0000

O QUE É O KUBERNETES
O kubernetes é um projeto opensource que foi lançado lá em 2014. Ele veio da inspiração de um sistema que o Google usava pra gerencia seus serviços lá na nuvem. O mais legal do kubernetes é que ele gerencia nossos containers (você pode entender mais sobre containers nesse meu artigo aqui) de forma inteligente e eficiente.

Quando a gente usa kubernetes conseguimos gerenciar vários containers ao mesmo tempo e também garantir que eles sempre fiquem disponíveis e escaláveis. Basicamente, dá pra pensar no kubernetes como um sistema de orquestração de containers onde ele coordena e automatiza a implantação e tudo referente aos containers da nossa aplicação em um conjunto de máquinas chamado cluster. Nessa gerencia, ele distribui os nossos containers pelo cluster de acordo com a demanda, os recursos disponíveis, monitora todo o funcionamento deles e quando acontece uma falha ali, ele se recuperar.

VANTAGENS

Correção de falhas: O Kubernetes nos ajuda bastante na correçao de falhas de container porque quando ele ve indentifica que tem algum container que tem algum problema ou não tá funcionando bem ou não responde a verificação de inetgridade que configuramos ele reinicia esses containers, substitui os containers que apresentam problemas, apaga os containers que não estão respondemdo a verificação de integridade e não os deixam up até que eles fiquem funcionais.
Escalabilidade: A escalabilidade é bem importante e faz com que a gente consiga alterar automaticamente o numero de containers que estão sendo executados com base no uso de CPU e outras metricas. Conseguimos tambem fazer essa escala de forma manual por meio de um comando no CLI e dessa forma, conseguimos alterar o nosso numero de containers que estão sendo executados -** Automatização: **A automatizaçao tambem é bem legal no kubernetes, porque a gente fala como vamos querer que nossos containers sejam, estejam. Se quisermos mudar alguma coisa, ele ajuda a gente com isso e faz isso para de forma controlada. Ele pode, por exemplo, criar novos containers, apagar os antigos e transferir recursos dos antigos para os novos automaticamente.
Sistema de armazenamento: O Kubernetes permite montar automaticamente um sistema de armazenamento, como armazenamentos locais, provedores de nuvem pública, etc.
Alocação de containers: Ali no kubernetes, dá pra ter um sistema de alocação de containers em servidores ou nodes de maneira bem mais eficiente. O objetivo é usar ao máximo os recursos disponíveis (como CPU e memória) sem desperdiçar espaço. Por ex: se a gente tem vários containers ali e eles tem requisitos de recursos bem diferentes, o “automatic bin packing” nos ajudará a garantir que esses containers sejam distribuídos nos servidores de uma forma que eles aproveite ao máximo os recursos, enquanto atende às necessidades de cada containers.

Em resumo, o Kubernetes é uma ferramenta bem poderosa e versátil que nos ajuda na gerencia dos nossos containers. Nos próximos posts vamos apronfundar em como ele funciona e subir uma aplicação nele.

continua …

AWS IAM — Identity and Access Management

Paloma Lataliza — Fri, 03 May 2024 16:54:12 +0000

Quando a gente usa a AWS qualquer coisa que fazemos passa pelo IAM, seja quando criamos uma instância EC2, quando adicionamos um objeto no S3 ou quando invokamos um lambda.

O IAM ou Identity and Access Management é um conceito global de gestão de acesso e não foi criado pela AWS, esse acrônimo foi adotado pelo provedor de nuvem para um dos serviços mais importantes, que a cada segundo recebe mais de 400 milhões de chamadas.

E o IAM serve para controlar autenticação e autorização. Autenticação é o processo que a gente se autentica seja com um usuário e senha, com uma chave e logo depois vem a autorização, então apesar de você estar autenticado, será que você tá autorizado, ou tem aquela determinada permissão?

Ele é composto por usuários, grupos, políticas de permissões, roles, MFA, SSO, etc, sendo uma ferramenta bem completa, onde a AWS investe bastante para que a gente consiga fazer toda a gerencia necessária.

Então quando a gente fala de IAM a gente pode pensar nele como um firewall de gestão de acesso, um firewall do presente e por que? Por ser uma ferramenta que ajuda no controle de acessos assim como faz o firewall de rede com determinadas conexões.

MODELO DE POLÍTICA

As políticas do IAM são compostas por alguns elementos e são escritas em Json. Esses elementos que a compõem são o version, sid, statement, action, effect, resource, condition.

O version é uma anotação da versão que vai definir quais são os elementos que irão compor uma política, até o momento isso é imutável e a AWS não tem uma nova versão ainda, então ainda sempre vai ser o mesmo.

O SID é um identificador da política e aí você pode dar um nome, ou algo que ajude a entender o que ela faz.

O statement é um bloco e é nele que a gente vai definir o que a nossa política faz, adicionar as condições, quais vão ser nossas permissões, ações que a gente pode tomar e todas as regras que irão compô-la

O effect dentro de uma política é o switch que diz se você vai ou não permitir aquela determinada ação, então ele vai ser deny ou allow e serão somente esses dois valores.

O resource é o ARN do seu serviço AWS, o ARN é como se fosse um ID daquele serviço, então por exemplo eu tenho um EC2 e pra eu saber qual é um EC2 específico, eu tenho o ARN dele. Então é uma string que a AWS cria pra identificar ali os serviços.

O condition é uma expressão lógica, elementos que vão te ajudar a definir o que você vai fazer com aquela permissão ou negativa, ela pode ser um IP, um usuário, uma TAG, uma condição no sentido literal.

E uma coisa que também é importante falar é que também temos a negativa desses elementos, como ao invés de ter um action, teremos um NOTaction, um NOTresource, NOTcondition, e sempre que não for aquele resource, condition ou action você faz o que o effect diz.

Então, sempre que a gente falar em política do IAM, a gente fala de um documento Json com vários elementos que vão negar ou permitir determinadas ações.

E pode parecer intimidador no início e levar ao pensamento de que é necessário decorar todos esses elementos, juntos com todas as formas de associar um recurso ou não, mas pelo contrário, você não precisa decorar e sim entender o que são esses elementos e aí que entra o pulo do gato, usar uma ferramenta da AWS que é o AWS Policy Gen que irá criar a política para você.

LÓGICA DA AVALIAÇÃO DA POLÍTICA DO IAM

As lógicas de avaliação de política servem para definir um fluxo que o IAM faz para decidir se você está autorizado ou não a realizar determinada ação. É importante falar do implicit deny e saber que tudo que é IAM já começa com esse implicit deny, mas o que é isso? É basicamente falar que tudo no IAM é proibido, exceto o que é liberado. Para gente entender, vamos pensar no seguinte. Você acessa o console e tenta visualizar as instâncias EC2 que a conta possui. Nesse primeiro momento o AWS IAM assume que você não tem acesso a nada, mas aí ele corre lá e analisa as politicas que o seu usuário possui e se alguma politica disser que você tem acesso a algum ou todos os EC2 da conta, ele permite o seu acesso e caso nenhuma que você possui fale nada sobre instâncias EC2, ele assume o implict deny e você não consegue acessar nada ali do painel de EC2.

Então a lógica começa assim, você autenticou e pediu acesso ao EC2, O IAM vai assumir um implict deny nesse primeiro momento e depois passa a analisar as politicas que você tem pra ver se alguma te permite acessar esse recurso. Mas aí, imagina a seguinte situação, o IAM está analisando sua politica nessa sequência encontra um deny, na AWS além do implict deny, a gente tem o explicit deny e esse explicit deny é quando escrevemos um deny em uma política e ao contrario do implicit deny, o explicit sobrepoe um allow. Resumindo, primeiro começa com tudo negado, se tiver um allow ele permite, mas se tiver um deny escrito, ele nega novamente a sua permissão.

ROLES

Quando a gente fala sobre roles ou funções no IAM, podemos pensar que uma role é como um entidade que tem certas permissões definidas e estão ali para direcionar as autorizações que dizem quais ações podem ser feitas ali com os recursos.

O que é bem interessante ao usar as roles é que elas não estão atribuidas a um usuário ou grupo, como geralmente acontece com as permissões. Ao contrário, um usuário (ou até mesmo um serviço da AWS) pode “assumir”essa função quando precisar e depois que terminar o que precisava, “desassumir” e assim as permissões são retiradas.

O uso de roles pode ser válido em situçoes assim:

Quando um usuário precisa de permissões adicionais por um período limitado.
Quando aplicaçoes ou serviços da AWS precisam se comunicar com outros recursos da AWS.
Para permitir que usuários de contas da AWS que são externas possam acessar os recursos em sua própria conta da AWS.

Isso é um jeito bastante seguro e eficaz de conceder permissões temporários, porque você não precisa mexer nos permissões permanentes do usuário. Além disso, as credenciais que o usuário/recurso recebe quando “assume” uma função são temporárias e são criadas automaticamente pela AWS. Então, você não precisa se preocupar em gerenciá-las.

MODELO TRADICIONAL RBAC

O RBAC ou role-based access control émétodo eficiente para determinar as permissões de cada indivíduo em um sistema. Ele funciona da seguinte forma, você dertemina roles, regras e atacha ao recurso, usuário, grupo que você precisa. Esse modelo é mais tradicional, mais comum e mais utilizado no IAM.

Em termos práticos, ao invés de conceder a cada usuário permissões individuais para acessar determinados recursos, o RBAC agrega estas permissões em funções. Dessa forma, os usuários são designados para uma ou mais funções, e assim, adquirem as permissões vinculadas a essa função.

É importante que você aplique o conceito do privilégio mínimo ao usar um RBAC para evitar acidentes.

MODELO ESCALÁVEL ABAC

O modelo ABAC, atribuct-based access control, ou modelo escalável usa uma variedade de atributos, incluindo os atributos do usuário, recurso, ambiente, etc, para decidir quem pode acessar o que.

No ABAC, os atributos são essencialmente qualidades ou características que podem ser utilizadas para estabelecer regras de acesso. Por exemplo, os atributos do usuário podem incluir sua função, departamento ou localização geográfica. Os atributos do recurso podem compreender o tipo de recurso (como um arquivo, um equipamento de rede, etc.) e sua classificação de segurança. Os atributos do ambiente podem englobar o horário, a localização ou a segurança da rede.

Para entender melhor, vamos usar o seguinte cenário. Imagina só que você tem vários lambdas ali e que você precisa dar permissão para alguns usuários. Se você for usar o modelo RBAC, a cada nova função lambda você precisaria adicionar o ARN na política e no modelo ABAC, a gente só cria o lambda com uma TAG e então aqueles usuários que tiverem aquela política, vão conseguir acessar tudo que tiver a TAG que você criou para esses lambdas.

E aí você pode criar a personalização que você necessitar, como TAGS para localização geografica, grupos de usuários, recursos, ambientes, etc.

O AWS IAM é um serviço global que você pode usar para gerenciar o acesso aos serviços e recursos da AWS. O acesso pode ser concedido a usuários, grupos e funções do IAM usando políticas de permissão. Ele é uma ferramenta complexa e que precisa de cuidados ao trabalhar, mas muito essencial e importante

Como é o AWS Community Builders

Paloma Lataliza — Fri, 03 May 2024 16:50:30 +0000

O AWS Community Builders é um programa de comunidade super colaborativo que reúne pessoas apaixonadas por tecnologia, nuvem com foco em AWS. O programa incentiva bastante os membros a compartilhar conhecimento, se conectar à comunidade; ajuda a melhorar as habilidades técnicas, fazer muito networking e nos dá a acesso avários conteúdos técnicos de qualidade.

O tempo do programa é de 1 ano e caso deseje continuar participando, você tem que renovar sua inscrição após o período.

COMO APLICAR?

As inscrições são abertas duas vezes por ano, os candidatos passam por uma seleção e depois são informados se foram ou não aprovados naquele semestre. Para se inscrever você pode acessar o site oficial do programa preencher o formulário. Caso as inscrições já tenham sido encerradas, você pode adicionar seu nome à lista de espera para o próximo semestre e quando reabrir, você recebará um e-mail avisando a reabertura.

O formulário de inscrição no programa consiste em perguntas como, o que você já fez para trazer mais conhecimento para as pessoas? Qual sua área de interesse em tecnologia área? Por que você deseja se inscrever? Quais são seus interesses na AWS e como você vê e espera estar daqui algum tempo. Também é necessário que você envie alguns links de conteúdo que tenha criado, como videos no youtube, blogposts, eventos que organizou, palestras que realizou, projetos no github, conteúdo que tenha publicado nas mídias sociais, etc.

QUEM PODE SE INSCREVER?
Qualquer pessoa pode participar desde que seja maior de idade, seja entusiasta em alguma área de tecnologia , tenha ao menos algum conhecimento sobre cloud/AWS e seja uma pessoa que curte compartilhar conhecimento.

CONTEÚDO
Os níveis elegíveis são:

Nível 100 (Iniciante)
Nível 200 (Intermediário)
Nível 300 (Avançado)
Nível 400 (Expert)

Esses são os níveis do conteúdo que você pode criar. Você pode começar a sua jornada de criação de conteúdo falando para um público mais iniciante (Nível 100) , como por exemplo: “Primeiros Passos Para Iniciar na Nuvem”, “O Que é AWS” e ir seguindo assim. Mas, a cada ano que se passa e você renova sua inscrição, é esperado que os seus conteúdos vão indo para um nível técnico maior.

Então se você tá no terceiro ou quarto ano de programa, não é interessante que as suas publicações sejam do tipo: “O que é o S3” ou “O que é AWS”.

O QUE EU PRECISO FAZER PARA SER ACEITO?
Não existem regras rígidas sobre como ser aceito no programa e o primeiro passo para uma inscrição aprovada é responder com calma todas as perguntas do formulário, revisar as regras do programa e tentar deixar as suas respostas o mais completa e clara possível.

Como explicado algumas vezes anteriormente, você precisa ter um espírito de comunidade, ter um conhecimento técnico na área que desejar entrar e estar sempre criando conteúdo. Então comece participando com mais frequencia das comuinidades da AWS, os AWS User Groups, ajude na organização de eventos, seja palestrante, participe dos foruns, mídias e também dos eventos promovidos pela AWS.

Aposte também na criação de materiais técnicos que possam ajudar as pessoas a entender, ingressar, resolver um problema ou ficar por dentro das tendencias de tecnologia e com foco em AWS. Posso dizer que uma das maiores chaves para ser aceito é a disseminação do seu material.

CATEGORIAS DO AWS COMMUNITY BUILDER
Cada integrante do AWS CB é vinculado a uma categoria atribuida a AWS/cloud computing. Elas são:

Cloud Operations
Containers
Data (Databases, Analytics, BI)
DevTools
Front-End Web and Mobile Development
Game Tech
Machine Learning
Networking and Content Delivery
Security and Identity
Serverless
Storage

Na sua inscrição você pode escolher a que você se sente mais atraído/confortável ou que é a sua área de estudo.

FUI ACEITO, E AGORA?

Agora é só felicidade, mas brincadeiras a parte, é bem interessante participar das call’s promovidas pelos CB’s. Por ser um programa global, você terá contato com pessoas do mundo inteiro, o que é uma oportunidade incrível de networking e discussão tecnológica.

Então aproveite bastente a interação com a comunidade de forma global, fique de olho das possibilidades de mentoria, demonstre vontade de sempre aprender mais e não menos importante, continue criando o seu conteudo e se fortalecendo cada vez mais.

**Ps: Por ser uma comunidade global, o idioma que é falado é o inglês.

QUAIS AS VANTAGENS DE SER UM AWS COMMUNITY BUILDER?

Uma das maiores vantagens do programa é ter acesso a pessoas da AWS na sua categoria, isso pode te ajudar muito no crescimento técnico. Acontecem também varias talks e eventos exclusivos onde não só os CB’s mas também o pessoal da AWS compartilham seus conhecimentos e também ensinam como melhorar a sua criação de conteúdo.

Outra vantagem demaaaais é que quando estão lançando algum beta program a gente tem acesso antecipado, sencional, né?

A gente também ganha alguns brindes incríveis como, crédito de 500 dólares para usar na conta AWS (A cada vez que você renova a sua inscrição, você ganha os créditos novamente). Isso é muito bom para estudar, testar POC’s e novos serviços.

Para incentivar nossos estudos, ganhamos acesso à CloudAcademy durante o período que estamos no programa e além disso uma certificação AWS de qualquer nível.

O reconhecimento que temos é absurdo, isso ajuda muito no meio profissional, além ter a possibilidade ser chamado para palestras em eventos da comunidade e também da AWS em si.

E por último e não menos importante, temos um baita desconto no re:Invent que pode chegar até 50%. E falando em re:Invent, existe a possibilidade (Caso se aplique ao programa All Builders Welcome Grant e seja contemplado) também de ganhar uma bolsa para comparecer ao evento em Las Vegas onde todos os custos são pagos pela AWS, passagem, hotel e ingresso.

MINHA EXPERIÊNCIA

Na minha primeira inscrição selecionei como categoria containers e cá estou no meu meu terceiro ano de programa com a mesma categoria, onde descobri uma paixão. CONTAINERS É VIDA! Posso dizer que ser uma AWS Community Builder foi um dos pilares para meu crescimento técnico. Conheci e tive contato com várias pessoas incríveis, oportunidades que me fizeram evoluir tanto no técnico, quanto em comunidade e também pessoal.

Falando de mimo, uma coisa bem legal também é que a cada renovação eles enviam um SWAG (brinde) adicional para os CB’s, e esses SWAGS são bem maneiros. Se liga só:

Meu SWAG do primeiro ano:

Meu SWAG do segundo ano:

Você pode ver o diretório com todos os AWS Community Builders, se conectar com eles e trocar uma ideia bem legal. Meu coração ficou quentinho quando vi meu nome pela primeira vez lá. Olha eu aqui.

Se você pretende se aplicar e tiver dúvidas, pode me chamar no Twitter que posso te ajudar a revisar sua aplicação ou dar dicas sobre.

É isso! Boa sorte!

Conceitos de Computação: IAAS, SAAS, PAAS. Ques bichos são esses?

Paloma Lataliza — Fri, 03 May 2024 16:46:13 +0000

Docker, containers, conteinerização são assuntos muito presentes no dia de quem trabalha com tecnologia atualmente. Nessa série de blogposts vamos entender o que são essas tecnologias e como usá-las.

O QUE É UM CONTAINER?

Quando a gente fala em container, sempre vem a imagem daqueles blocos de metal gigantes, que transportam as nossas comprinhas da china ou de outros países pra cá, mas olha, um container pode ser muito mais que isso.

Então o que é um container? Antes de responder essa pergunta é necessário entender que quando falamos de container, estamos falando de isolamento. Mas como assim isolamento? Quando subimos um container e esse container está rodando na nossa máquina, não existe nenhuma camada de abstração gigante como um hypervisor e desta forma é como se isolassemos um pedaço ali da nossa máquina e o atribuísse para nosso container.

Com esse isolamento temos processos que são somente desse container, mount points, usuários, redes, etc, e outros container não conseguem enxergar nada que não seja nele próprio. Um ponto legal é que conseguimos fazer isolamento de recurso para quando eu quero dedicar um determinado pedaço do meu cpu, da minha memória, da taxa de I/O de input/output para um container.

Então um container é um bloco isolado, que “virtualiza” as nossas aplicações e compartilha o kernel do sistema operacional.

E como funciona o container, pensando na nossa aplicação, seja ela qual for, caso seja necessário alguma bibliotecas, características do sistema operacional, dependencias, o container encapsula tudo para nosso uso e caso a gente precise de mais alguma coisa, ele utiliza o kernel do nosso sistema operacional hospedeiro. Um container não possui um kernel próprio.

CONTAINERS x VM’s

Uma dúvida muito comum é sobre máquinas virtuais e containers. Mas então, um container é uma máquina virtual pequena? A resposta é não, não tem nada haver com VM, por mais que dê a entender ou seja um pouqinho semelhantes.

A máquina virtual emula todo um sistema operacional e muita das vezes com um hardware também, já o container não, podemos pensar nele como a nossa aplicação

FERRAMENTAS E COMPONENTES FUNDAMENTAIS

Para entender mais sobre o funcionamento de containers, precisamos falar um pouco sobre algumas tecnologias, recursos, ferramentas fundamentais no seu uso. Elas são os namespaces, Cgroups e o Union File System.

NAMESPACES

Para falar sobre container, é importante falar sobre namespaces e para entendermos isso melhor, vamos usar uma analogia. Vamos imaginar que você viva com sua família na sua casa e cada integrante tem o seu próprio quarto. Os namespaces são como os quartos, que são espaços separados/isolados para que cada integrante da sua familia possa ter e guardar seus objetos, viver de forma tranquila sem intereferir no espaço dos demais. Então assim, se você precisa de um travesseiro para dormir, você vai até o seu quarto (namespace) para pegar e não no quarto da sua irmã.

Então, podemos ententer que um namespace é uma forma de isolar e separar vários recursos e processos no Linux. E com essa separação, os processos em um namespace são conseguem afetar ou acessar diretamente recursos em outro namespace. Quando muitas aplicações, serviços, programa estão trabalhando ali ao mesmo tempo os namespaces são super uteis para garantir o isolamento e segurança.

No Linux, existem vários tipos de namespace, cada o objetivo de isolar um componente específico:

PID (Process ID): Não deixa com que processos de um namespace vejam ou interajam com processos de outro namespace.
Network: Aqui os recursos de rede como regras de firewall, tabelas de roteamento e interfaces são isolados também e assim cada namespace tem uma configuração de rede personalizada e independente.
Mount: O isolamento também acontece nos pontos de montagem e assim as modificações em um namespace não afetam outros namespaces.
User: isola os IDs de usuário e grupo para que os processos dentro de um namespace possam ter seus próprios IDs de usuário e grupo sem influenciar os IDs dentro de outros namespaces.
IPC (Inter-process Communication): Nos namespace de comunicação entre processos isolamento acontece na comunicação dos processos de namespace. Assim não dá pra para que processos em vários namespaces se comuniquem diretamente, isolando os recursos de comunicação entre processos.
UTS (UNIX Time-sharing System): Aqui cada namespace pode ter seu próprio nome de host e domínio independente e exclusivo.
Esses namespaces são fundamentais para a criação de ambientes virtuais e contêineres, como Docker e Kubernetes, onde cada contêiner pode ter seu próprio conjunto isolado de recursos e processos, garantindo que os aplicativos e serviços executados em contêineres diferentes não interfiram uns nos outros.

Em resumo, um namespace no Linux é como um “quarto” separado que isola e protege os recursos e processos do sistema, garantindo que cada aplicativo ou serviço possa funcionar de forma independente e segura, sem interferir nos outros.

CGROUPS

Os Cgroups do Linux, uma ferramenta que o kernel tem a seu dispor, possibilitam a regulação e o controle do uso de recursos do sistema. Quando pensamos nos Cgroups, falamos de coisas como a CPU, a memória e a entrada/saída (I/O), todos vitais para a execução de processos ou conjuntos de processos. Com isso, temos uma distribuição de recursos mais justa entre os processos do sistema operacional, evitando que um único processo possa se apropriar de todos os recursos, o que prejudicaria o desempenho de outros programas.

Para compreender melhor vamos usar uma analogia, onde consideremos uma situação em que você está organizando um evento de tecnologia. Nesse evento, ocorrerão diversas palestras sobre tópicos como computação em nuvem, desenvolvimento de software e redes. Cada uma dessas palestras exige recursos específicos — espaços adequados, tempo de apresentação e equipamentos. Os Cgroups atuam como as normas que você, enquanto organizador, implementa para assegurar que cada apresentação obtenha os recursos que necessita sem comprometer as demais.

A seguir, veja alguns exemplos de como os Cgroups são implementados:

Restrição da CPU: Vamos usar uma analogia comum para entender isso. Imagine ter um editor de texto e um jogo pesado rodando ao mesmo tempo no seu computador. O jogo, por ser mais pesado, tende a consumir mais recursos, deixando pouco para o editor de texto, que pode ficar lento ou até travar. Como se fosse um monte de crianças correndo para pegar o último doce, quem for mais rápido leva! Mas usando os Cgroups, podemos equilibrar essa distribuição de processamento, garantindo que todos os aplicativos funcionem sem problemas.
Gerenciamento de Memória: Da mesma forma que controlamos o poder de processamento, também podemos administrar o uso da memória usando os Cgroups. Aqui usamos Cgroups para garantir que cada aplicativo use apenas o que precisa, evitando que o sistema fique sobrecarregado.
Controle de entrada/saída (E/S): Cgroups também permite regular o uso de dispositivos de armazenamento, como SSDs e HDs e com os Cgroups, nós limitamos a taxa de transmissão de dados para que nenhum aplicativo monopolize o acesso aos dispositivos, mantendo o sistema equilibrado e funcionando de maneira eficiente.
Desta forma, os Cgroups podem ser resumidos como um recurso extremamente útil e adaptável, que habilita o controle e a restrição de uso dos recursos do sistema operacional por processos isolados ou conjuntos de processos. Com isso, se consegue um equilíbrio no desempenho das aplicações, otimizando a estabilidade e eficiência do sistema em seu conjunto.

UNION FILE SYSTEM

O Union File System (UFS) representa uma variedade de sistema de arquivos, que deixa a gente combinar varias camadas de arquivos e diretórios em uma visualização unificada. Ele é majoritariamente empregado em tecnologias de contêineres, como Docker, para a administração eficiente e flexível das camadas de arquivos de um contêiner.

Ao lidar com contêineres, o Union File System possibilita que múltiplas camadas sejam fundidas em uma única imagem de contêiner. Cada camada pode carregar informações específicas, como arquivos de configuração ou bibliotecas de software, e pode ser compartilhado entre contêineres distintos para economia de espaço e tempo.

Resumindo, o Union File System funciona como um manual de receitas multicamadas, onde cada camada equivale a um conjunto de arquivos e diretórios. Ele permite a junção dessas camadas de maneira eficaz e versátil, fornecendo uma visualização unificada dos arquivos e facilitando a administração de contêineres.

BENEFICIOS DE USAR CONTAINERS
O uso de containers nas nossas aplicações no dia a dia deixa tudo mais performático e com menos gasto de recurso.

Um dos maiores pontos benéficos do uso de containers é a portabilidade. Se eu uso um container em um servidor e migro ele para um outro com um outro S.O, ele ainda sim vai funcionar de maneira bem performática. Por ser bem menor e mais simples, é bem mais fácil de movimentar do que uma VM.

IAC e Terraform. O que é e porque são tão importantes? Ep.2

Paloma Lataliza — Fri, 03 May 2024 16:38:05 +0000

Conforme vimos no artigo anterior, utilizar infraestrutura como código é fundamental, principalmente quando estamos trabalho com provedores de nuvem. O terraform veio pra ajudar em vários desafios como vimos anteriormente e sua uilização tem trazido mais beneficios do que ferramentas nativas dos cloud providers.

Aqui continuaremos falando sobre o funcionamento e as vantagens do uso do terraform e também do terragrunt.

TERRAFORM

CONTROLE DE ESTADOS
Antes a gente usava as GMUD’s para controlar o estado do nosso ambiente e realizar as atualizações, agora com o terraform conseguimos controlar os estados da infraestrutura garantindo o estado atual a cada iteração. Esses estados são basicamente a nossa gerência de configuração.

Desta maneira eu posso entender qual é o estado do ambiente naquele momento e posteriormente até exportá-lo.

PLANEJAMENTO
No terraform, antes de realizar qualquer alteração, a gente pode ter uma noção de tudo que será criado em nosso ambiente. Podemos simular como aquele ambiente ficará após a execução, ver tudo que será criado, o que será alterado e removido antes de subir. E dessa maneira temos todo o controle de modificações antes de escolher se vamos ou não aplicar esses updates.

ABSTRAÇÃO
Com o uso do terraform a gente consegue ter uma abstração em alto nível. Ao invés de ter um código com valores estático, posso ter variaveis para alterar aquele valor de acordo com a minha necessidade e sem precisar de me preocupar em fazer essa modificação em vários lugares.

Por exemplo, a gerencia de vários ECS na AWS e neste cenário vamos supor que precisamos trocar o valor da memória de duas tasks definitions. Aqui poderíamos ter uma variável chamada taskdef_memoria para a quantidade de memória das minhas tasks definitions e sempre que eu quero mudar esse valor, eu preciso alterar somente nessa variável e não nos vários lugares em que esse recurso poderia estar. Assim o controle fica mais fácil

MODULARIZAÇÃO
Um dos maiores benefícios do é a modularização. A modularização é muito importante pra evitar que a gente tenha uma repetição de código muito grande. Ou seja, eu posso criar um módulo generico para um recurso e utilizar esse módulo para criar esse recurso para diferentes ocasiões. Por exemplo, pegando o caso da criação de um EC2, eu posso usar esse módulo padrão para subir vários EC2 diferentes, em contas diferentes, mudando somente as variáveis que vão personalizar essa instância. Vale lembrar que o terraform faz a organização de módulo a nível de diretório

E a ideia de modularizar, além de evitar a repetição de código, é desacoplar os recursos e trabalhar com eles separadamente. Voltando ali no caso do EC2, para que esse serviço funcione na AWS ele precisa também de outros recurso como rede e segurança e para criar a parte de rede eu posso ter um módulo de VPC (serviço de rede da AWS) em um local diferente de onde está meu módulo de EC2.

Dessa forma tudo fica mais simples e ajuda a não ter interferências quando precisamos ter atualizações paralelas, porque se alguém está modificando o módulo de VPC o de EC2 não será afetado e isso garante também a confiabilidade.

CRIAÇÃO DE NOVOS MÓDULOS E PROVEDORES
Por ser open source, dá super para fazer gerenciamento por API o que faz com que tenhamos a oportunidade de criar um provedor novo ou um módulo novo. Os providers grandes de nuvem investem muito nisso e a gente consegue ver pessoas dessas nuvens trabalhando fortemente nesse desenvolvimento. Em 2021 mesmo, lá no re:Invent a AWS anunciou um novo módulo do terraform, o AFT que permite provisionar e personalizar contas AWS por meio do Terraform usando um pipeline de implantação.

ORGANIZAÇÃO
Quando usamos o terraform, podemos organizar nossos arquivos e códigos em duas maneiras. A primeira é tudo junto em um diretório só e a segunda é em pastas separadas.

Na primeira abordagem podemos criar umarquivo para cada recurso dentro uma pasta e nessa organização a declaração das variáveis é feita em um lugar só, deixando a compreensão mais fácil e a repitação de código menor, mas por outro lado quando quando precisarmos fazer uma atualização, toda a infraestrutura será validada novamente. Ele vai checar se tem alguma atualização em todos os recursos dentro dessa pasta e se estiver alguma coisa não terminada pode quebrar o ambiente, assim como a aplicação da sua atualização pode ser muito demorada por precisar conferir recurso por recurso.

A recomendação para uso desse tipo de organização é quando a equipe é pequena, os recursos a serem criados não são muitos ou você ainda não tem a real noção da infra solicitada.

Na segunda abordagem, a organização acontece a nível de diretório e dessa forma conseguimos criar módulos e definir qual será a ordem de execução a partir de um depends_on. Aqui fica mais fácil de trabalhar e não tem o problema citado anteriormente da atualização de todos os recursos, nos diferentes arquivos, de uma só vez.

Nesse tipo de organização é onde acontece a modularização, por mais que eu tenha que declarar variaveis em todos os modulos, o que pode causar um pouco de duplicidade caso existam variaveis dependentes, o reuso de código é bem possível. Eu posso chamar esse modulo em um lugar e alterar somente o valor das varíaveis de acordo com a minha configuração.

TERRAFORM WORKSPACES
Agora que entendemos como funciona o terraform, precisamos pensar também em uma forma de trabalhar com nossos módulos, arquivos em vários ambientes, como desenvolvimento(DEV), homologação(HML) e produção(PRD).

Quando temos vários ambientes para trabalhar e precisamos usar o mesmo código, o terraform oferece um recurso chamado workspaces que basicamente cria ambientes separados, mas identicos e separa os states de cada um deles.

O uso do workspaces começa a ficar complicado quando temos um ambiente significativamente diferente dos demais, então por exemplo, se meu ambiente de HML é bem diferente de PRD e o pior, estão em contas diferentes, isso começa a dar mais trabalho e precisaríamos começar a fazer algumas gambiarras para tentar contornar o problema, como criar vários arquivos de configuração backend dentro de um código e ter que inicializar o terraform de acordo com o arquivo backend do ambiente a cada update.

Além desse problema, caso tenha algum recurso compartilhado a complexidade de gerencia aumenta, pois os estados também vão ter que ser compartilhados entre as workspaces.

E para mim, o maior problema do workspace é que não tem nada que avise em qual workspace você está e se por algum acaso você esquecer de trocar na hora na execução, você vai subir o ambiente errado sem perceber.

Desses problemas nasceu o terragrunt.

TERRAGRUNT

O terragrunt é uma ferramenta usada para orquestrar a execução do terraform. Ele trabalha a nível de diretório também, então você pode ter uma pasta para seu ambiente de DEV, um para HML e ou para PRD o que deixa mais facil a visualização e a evitar erros de aplicação por ambientes errados, como pode acontecer no workspaces.

O legal do terragrunt é a organização da execução de acordo com as dependencias que temos, então assim, se a gente tem inúmeros recursos que dependem um do outro, como um EC2 que depende de uma VPC, o terragrunt nos ajuda a gerenciar as dependencias pra fazer com que a VPC seja criada antes do EC2.

Com o terragrunt é possível fazer a comunicação de vários provedores de uma só vez. Então se eu tenho uma aplicação que usa containers e um banco de dados, onde os serviços de containers estão na AWS e o banco de dados estão na GCP, eu não preciso me preocupar em fazer a segregação por providers, posso manter tudo no mesmo repositorio pois ele consegue comunicar com os dois ao mesmo tempo mantendo a hierarquia de pastas.

Um outro ponto é que ele pode trabalhar com diferentes versões dos nossos modulos terraform. Se criar uma versão nova tagueando-a, é só informar na url de chamada do modulo essa versão e o terragunt vai trabalhar em cima dela.

CONCLUSÃO
Então o que usar e quando usar? Pra responder essa pergunta você precisa analisar o seu cenário. O uso do terraform é importante para ajudar no controle e gerenciamento da sua infraestrutura, assim como para ajudá-lo a subir todo seu ambiente de forma rápida cada aconteça algum incidente.

Se sua equipe for grande, com um projeto robusto o terraform com terragrunt é uma boa opção. Caso seja somente para subir poucos recursos que não tenham criticidade alta, o terraform dá conta do recado. E se a sua ideia for validar um ambiente antes de subir, criando uma copia testando e depois destruindo, o workspaces pode te ajudar.

REFERENCIAS
Esse blogpost foi inspirado em uma talk da Camilla Gomes no DevOpsDays VIX 2022.

IAC e Terraform. O que é e porque são tão importantes? Ep.1

Paloma Lataliza — Fri, 03 May 2024 16:35:25 +0000

Para falar de IAC ou infraestrutura como código, primeiramente precisamos abordar alguns assuntos e conceitos para entendermos a sua real necessidade. Vamos começar com a gerência de configuração e o movimento DevOps.

GERÊNCIA DE CONFIGURAÇÃO E MOVIMENTO DEVOPS

Existe um conceito super importante que vem lá do ITIL (Information Technology Infrastructure Library) que ajuda a gente entender a importância da utilização de infra como código, a gerência de configuração. A gerência de configuração pode ser resumida em um conjunto de atividades que viabiliza o controle das mudanças que acontecem nas diferentes etapas do nosso software.

E com essa prática a gente consegue identificar e documentar as características do nosso software, controlar as mudanças que vão ocorrer nele, registrar o estado em que ele se encontra, verificar a conformidade de acordo com os requisitos, e com isso a gente tem uma segurança no sentido da quebra do software.

Há um tempo atrás era essencial o preenchimento de uma GMUD (Um documento de gestão de mudanças) e isso era simple quando tínhamos ali um data center e esse data center possuia poucos servidores. Neste cenário o controle era fácil e as GMUD’s eram mais eficiêntes, mas quando temos uma escala grande de máquinas, com mais de 100 servidores, fica inviável, pois ao todo nesses servidores podemos ter uma quantidade de serviços absurda e controle fica super burocrático.

Pra ajudar a contornar essa burocracia o movimento DevOps veio para aproximar os precessos do pessoal de OPS com o pessoal de DEV e embora cada um tenha suas práticas, a necessidadade dessa integração trouxe atualizações na maneira de trabalhar, com versionamento de código, automações e entrega contínua. Com essas atualizações e a melhora na comunicação das equipes, a nuvem trouxe fortemenete a idéia da infraestrutura como código.

IAC

E o que é IAC? IAC como dito anteriormente é a prática de usar código para criar sua infraestrutura em cloud. Antes a gente abria o nosso console do provedor de nuvem e iamos clicando ou selecionando nos serviços e preenchendo os parâmetros para o funcionamento e agora, as boas prática recomenda o uso de infra as code.

Mas porque fazer um código para criar um serviço, sendo que usar o console é mais fácil?

Porque tudo que é manual muitas das vezes não é possível replicar. E quando a equipe que trabalha com essa nuvem é grande, gerenciar e controlar tudo o que foi criado fica mais complexo.

E as vantagens de usar IAC não são somente o controle e gerenciamento, podemos contar com o reuso do código, além da facilidade de criar e destruir ambientes o que nos ajuda quando apagamos algo por acidente ou quando ocorre um incidente como um ataque.

FERRAMENTAS IAC
E quando a gente fala de IAC, pensamos logo em algumas ferramentas que podem nos auxiliar nesta jornada. Cada ferramenta possui suas particularidade e são designadas para cada caso de uso específico e podem ser utilizadas em conjunto. As mais conhecidas são o ansible, chef, terraform e puppet.

ANSIBLE

O Ansible é uma solução de gerenciamento de configuração e automação. Com ele a gente pode projetar e gerenciar o estado que queremos de nosso sistema usando scripts YAML. A simplicidade do Ansible e a falta de necessidade de instalar software adicional no destino são dois de seus benefícios. Uma coisa bem legal do Ansible é o modelo sem agente que depende só da comunicação SSH para os nós gerenciados. Para usar a gente basicamente escreve um script que chamamos de playbook e nele definimos o que deve ser instalado e configurado.

CHEF

O Chef é uma ferramenta que tem um proposito super parecido com o do Ansible, mas ao ivéns de usar YAML, a gente tem o Domain Specific Language (DSL) escrita em Ruby. No Chef existe a necessidade da instalação de um agente no servidor de destino, o que não acontece no Ansible.

PUPPET

O Puppet é uma ferramenta super similiar ao Chef, e as 03 possuem o mesmo propósito de gerenciamento de configuração e definição do estado desejado do sistema. Assim como o Chef, o Puppet usa sua própria linguagem de domínio específico (DSL).

CASO DE USO DESSAS FERRAMENTAS

Vamos pegar um cenário onde temos 10 servidores e queremos instalar um editor de texto neles. Em vez de instalar esse editor de texto manualmente em cada servidor e seguir os procedimentos necessários para o funcionamento dele, você pode usar uma dessas ferramentas para fazer a instalação e configuração em todos os 10.

TERRAFORM

Antes da gente falar sobre o terraform, vamos a uma curiosidade. O termo terraform vem de terraformar no latim, onde é terra é a terra mesmo e formar é moldar, criar. Geralmente é usado na ficção cientifica pra quando cria-se um planeta e o mesmo é habitável como a terra.

E a ideia do terraform é meio que isso também. Para usa-lo precisamos nos conectar a um provedor de nuvem e começar a criar os nossos recursos, a nossa infraestrutura (planetas).

Então, podemos falar que o terraform é uma ferramenta de IAC usada para criar a nossa infraestrutura, ao contrário das ferramentas que citei anteriormente que são focadas mais no servidor pra dentro. O que atrai muita gente para usar o terraform é sintaxe facil, uma comunidade bem ativa(open source) e a documentação dele bem completa.

Porque usar terraform e não uma ferramenta nativa?

Muitas pessoas quando vão começar usar IAC ficam na dúvida se começam a usar o terraform ou a ferramenta nativa do provedor de nuvem, e a resposta pra essa dúvida pode ser esclarecida de acordo com o seu cenário. Mas olha, a utilização do terraform comparado ao uso do cloudformation da AWS pode ser bem mais benéfica, visto que o terraform tem uma curva de aprendizado menor, suporta mais de 250 provedores atualmente. Com isso, conseguimos trabalhar com mais de um provedor usando a mesma ferramenta e acaba que não preciso ficar aprendendo uma ferramenta nova toda vez que vou mudar de cloud, preciso somente ver quais serão as particularidades de chamadas daquela outra cloud.

Desta forma a gente ganha tempo, podendo nos aprofundar em uma ferramenta só e o gerenciamento fica bem mais fácil.

Continua …

Desmistificando o AWS LoadBalancer

Paloma Lataliza — Fri, 03 May 2024 16:32:11 +0000

Você já quebrou a cabeça para compreender a ideia do que é balanceamento de carga da AWS? Se sim, relaxe! Você não está sozinho, isso aconteceu comigo no passado e agora vou te ajudar a entender o que é o AWS LB.

LOAD BALANCER: O QUE É ISSO?
Imagine que você foi em um supermercado fazer suas compras do mês e quando você chega para pagar, repara que tem vários caixas para fazer o seu pagamento. Quando as filas começam a se formar, um funcionário do supermercado orienta os clientes até os caixas disponíveis para garantir um atendimento rápido e eficaz a todos. O load balancer funciona da mesma forma que os checkouts e pagamentos de compras em um caixa de supermercado, ao invés de caixas e clientes a gente tem solicitações e servidores.

Os clientes são como as requisições que são enviadas, o supermercado é como nossa aplicação e os caixas são como os servidores que processam as nossas requisições. Se o fluxo de clientes (requisições) não for bem distribuído, alguns caixas podem ficar completamente sobrecarregados, enquanto outros podem ficar parados, o que deixaria vários clientes nervososos.

De forma mais técnica, o balanceamento de carga (load balancer) distribui o tráfego de rede entre vários servidores, garantindo uma distribuição eficaz de tarefas e evitando servidores sobrecarregados. O objetivo é evitar gargalos, distribuir a carga de trabalho e, assim, aumentar a disponibilidade e confiabilidade do serviço.

AWS LOAD BALANCER
Voltando ali na nossa história do supermercado, o AWS Load Balancer opera de forma semelhante a um gerente de supermercado, identifica o gargalo e atribui funções aos caixas de acordo com a quantidade de produtos e clientes que consegue atender e seu nível de disponibilidade.

Agora que entendemos o que é o LB, podemos citar alguns serviços onde o mesmo é responsável por toda essa distribuição de tráfego. Vale lembrar que ele é compatível e trabalha com diversos serviços e que vou falar somente de alguns aqui:

EC2: Nas instancias do EC2, o AWS LB consegue distribuir o tráfego que chega entre várias, uma ou mais AZ’s.
ECS: Quando a gente fala sobre o ECS, o load balancer tem um papel super importante na distribuição o tráfego entre os containers desse serviço, o que facilita o desenvolvimento e a execução das nossas aplicações que são baseadas em micro-serviços.
EKS: Falando de EKS o AWS load balancer funciona de forma super similar ao que acontece no ECS, o que muda mesmo é só o destino que são os containers do kubernetes.

Dentro da nuvem AWS o load balancer é divido entre 04 tipos e devemos nos atentar quando formos usar, pois cada um tem um uso e necessidades diferentes.
Os tipos são:

Application Load Balancer (ALB)
Network Load Balancer (NLB)
Classic Load Balancer (CLB)
Gateway Load Balancer (GWLB)

APPLICATION LOAD BALANCER (ALB)

O Application Load Balancer é um dos mais utilizados atualmente, pois trabalha ali no de aplicação, sendo exclusivo para tráfego HTTP e HTTPS. Além de balancear a carga, ele examina o conteúdo das solicitações para encaminhá-las aos servidores corretos. Isso faz com que possamos ter o uso de roteamento baseado em conteúdo, permitindo a escolha de servidores com base na natureza da solicitação e outros fatores.

Exemplo:
Imagine que você tenha uma aplicação que oferece você tem diversos serviços, como um chat para o pessoal conversar sobre seus posts, uma loja para vender seus produtos e um blog somente de videos. Usando nesse cenário o ALB, consiguimos fazer a distribuição da nossa carga de trabalho, otimizando-a e assim, consequentemente deixando a experiência do usuário da aplicação melhor. O que acontece é que quando alguém entra em algum desses serviços da sua aplicação, as requisições são enviadas são direcionadas acordo com o serviço acessado. Então, desta forma o ALB envia as requisições do blog para um conjunto de servidores X, as loja para um Y e do chat para um conjuntos de servidores Z.

NETWORK LOAD BALANCER (NLB)

Ao contrário de ALB, o NLB não lida com tráfego que responde a protocolos de níveis mais alto como o HTTP e o HTTPS, ele trabalha ali a camada de conexão de transporte do modelo OSI, tendo atuação nos protocolos TCP/UDP. Quando pensamos em um tráfego mais alto a melhor opção seria esse tipo de balanceador de carga, pois consegue lidar com um fluxo alto e traz um latência extremamente baixa. Os maiores usos do NLB são aplicações que precisam de um alto desempenho e distribuição de tráfego em tempo real.

Exemplo:
Vamos pensar no seguinte cenário, você quer muito ver um filme e percebe que pode ver esse filme em um determinado provedor de streaming. Esse provedor de streaming é super famoso e recebe milhares de pessoas todos os dias para assistem ao filmes em seu catálogo e tudo isso ao mesmo tempo. Para que você consiga ver seu conteúdo sem interrupções e de forma lisa, o NLB entra em cena e faz ali todo o balanceamento da carga entre vários servidores de streaming. Ele é super importante nessa situação, pois a demanda é alta e afinal, tem várias pessoas vendo simultanemente.

CLASSIC LOAD BALANCER (CLB)

O Classic Load Balancer é um balanceador mais antigo e em breve entrará em desuso pois ele funciona nos níveis de aplicativo e rede, mas não conta com recursos mais sofisticados como os encontrados nos ALBs e NLBs. Ele pode ser útil em situações onde temos o tráfego é bem modero, mas ainda sim vale a pena considerar um dos dois balanceadores anteriores.

Exemplo:
Para ilustrarmos esse caso, podemos pensar em uma aplicação web que tenha um trafego baixo, não necessita de roteamento baseado em conteúdo ou de baixa latência. Da mesma forma que os anterioresm, ele distribui a carga entre os servidores dessa aplicação para que não tenhamos gargalos.

GATEWAY LOAD BALANCER (GWLB)

Esse tipo de load balancer é bem novo e foi lançando em 2020. Conforme diz a AWS, ele basicamente combina um gateway de rede com um único ponto de entrada e com a saída para todo o tráfego junto de um balanceador de carga. Essa balanceador distribui o tráfego e dimensiona seus appliances virtuais de acordo com a demanda recebida.

Esse LB é tem a proposta de trabalho voltado para os appliances de rede, que são ferramentas ou softwares redes que podem ser usados para filtragem de dados, otimização de desempenho da rede, detecção e prevenção de intrusões, etc. Um exemplo são os firewalls, WAF’s, IDS/IPS, entre outros.

O Uso dele pode ser recomendado quando a gente tem um tráfego bem alto chegando em nossa rede. Assim, o GWLB distribuirá as solicitações entre as nossas diferentes ferramentas de rede, o que evita a sobrecarga em alguma delas. Outro ponto bem interessante é que ele faz com que essas ferramentas abosrvam as solicitações da maneira que foram enviadas, o que pode ser bem importante quando falamos de segurança e otimização, onde os detalhes do tráfego de rede precisam ser lidos para funcionar corretamente.

Exemplo:
Imagine que sua empresa pensa muito em segurança e configura ali firewalls de ponta e tem também um grande sistemas de prevenção contra invasões para analisar e filtrar o tráfego de rede. Essas ferramentas precisam de um alto nível de segurança e controle, o que pode ser difícil controlar devido ao tamanho e a disponibilidade desses appliances de rede. É aqui que o Gateway Load Balancer entra. Ele faz com que nossas ferramentas funcionem sem sobrecarga, pois distribui igualmente nossas solicitações de entrada entre os nossos appliances rede. Isso faz com a sobrecarga seja eliminada. Se caso algum appliance falhar ou estar sendo atualizado, o GWLB redireciona o tráfego para as outras ferramentas e assim a nossa aplicação continua segura e healty.

VANTAGENS DO USO DE LOAD BALANCERS
Agora que entendemos o que é e vimos os diferentes tipos de balanceadores de carga na AWS, vamos expor e relembrar as maiores vantagens de fazer o uso dessa ferramenta poderosa:

Alta Disponibilidade: Uma das maiores vantagens de usar os balanceadores de carga é o redirecionamento das requisições quando um servidor falha ou fica indisponivel. Desta forma, ele manda o trafego para um que esteja saudável e assim sua aplicação não fica indisponível.
Escalabilidade: Quando a gente tem um fluxo muito alto ali na nossa aplicação o ELB consegue adicionar mais servidores para atender esse fluxo de acorodo com o que é necessário e quando normalizar, esses servidores adicionais serão removidos. É uma funcionalidade essencial para que a aplicação possa continuar disponível após um grande tráfego.
Distribuição do Tráfego Balanceada: Quando é necessário realizar a distribuição de um determinado tráfego, o load balancer faz isso de forma balanceada para que nenhum servidor fique sobrecarregado, o que traz um desempenho melhor pra nossa aplicação.
Flexibilidade: Uma coisa bem interessante é a possibiliade de distribuir o tráfego de conforme a criação de algumas regras, fazendo com que a gente possa direcionar determinados tipos de requisições para servidores específicos.
Integração com Serviços AWS: O LB da AWS é compatível e bem fácil de ser utilizado com outros serviços, como o Auto Scaling, RDS, WAF, EC2, ECS, EKS, Lambda, etc.

CUSTOS
Como a gente sabe, na AWS a gente paga somente pelo o que usamos e a precificação do Elastic Load Balancer depende do tempo, requisições e tipo.

No Application Load Balancer e no Network Load Balancer o preço é definido por hora utilizada e uma métrica composta por novas conexões por segundo, conexões ativas por minuto, bytes processados por hora e avaliações das regras do seu listener por segundo.

A cobrança no Classic Load Balancer é mais simples e composta pela quantidade de GB de dados transferidos por esse LB e também por hora utilizada.

O Gateway Load Balancer possui um modelo de precificação onde temos 02 tipos de cobranças simultâneas. A primeira é igual a que acontece no ALB e no NLB e a segunda é pelo VPC Enpoint desse load balancer.

Você pode simular os custos desses load balancers com a calculadora da AWS clicando aqui.

CONCLUSÃO
Fazer o uso de um load balancer com toda certeza é importante quando falamos de disponibilidade, escalabilidade e desempenho das nossas aplicações nesse provedor. Quando a gente entende como funciona cada tipo, a implementação fica mais fácil e o resultado sempre é recompensador, mas é necessário que as configurações do mesmo sejam feitas de forma adequada para garantir que sua aplicação possa lidar com tráfego esperado, ser consitente e confiável.

É importante lembrar de analisar o seu cenário e escolher do tipo load balancer que mais se adequa a sua aplicaçõe e as suas necessidades.