AWS certified developer associate hints ECS, ECR, Fargate, Cloud formation, Beanstalk, SAM (part V)

Amazon ECS

EC2 Launch Type:

  • Launch docker containers on aws = launch ecs tasks on ECS cluster
  • EC2 Launch type: you must provision and maintain the infra
  • Each EC2 instance must run ECS Agent to register in the ECS Cluster

Fargate:

  • You do not provision EC2 instances
  • It’s all severless
  • You just create task definition
  • AWS just runs ECS Tasks for you based on CPU/RAM we need

IAM Roles for ECS:

  • EC2 instance profile (EC2 launch type only)
  • ECS Task role (valid for both)

Data volumes:

  • Mount EFS system onto ECS tasks work for both EC2 and Fargate launch types
  • Tasks running in any AZ with share same data
  • Fargate + EFS = Serverless

ECS Service Auto Scaling

Amazon ECS Auto Scaling uses AWS application auto scaling:

  • ECS service average CPU
  • ECS service average memory utilization RAM
  • ALB request count per target
  • Target Tracking - scale based on target value for a specific CloudWatch metric
  • Step Scaling - scaling based on a specific CloudWatch Alarm
  • Scheduled Scaling - scale based on a specific date/time

EC2 Launch type - auto scaling EC2 instances

  • Accommodate ECS services scaling by adding underlying EC2 instances
  • Auto Scaling Group Scaling (based on CPU)
  • EC2 cluster capacity provider (automatically scale infra for your ECS tasks)

ECS Rolling update

  • Minimum healthy and maximum healthy percent

Amazon ECS - Task Definition

Task definition are metadata in JSON.

Task definition contains:

  • Image name
  • Port binding for container and host
  • Memory and CPU required
  • Env variables
  • Networking information
  • IAM role
  • Logging configuration

Amazon ECS - load balancing (EC2 launch type)

  • We get a dynamic host port mapping if you define only the container port in the task definition (container port = 80, host port = 0)
  • ALB finds correct dynamic port of a container
  • You must allow on the EC2 instance security group any port from the ALB’s security group

Amazon ECS - load balancing (Fargate)

  • Each task has a unique private IP
  • Only define the container port (host port is not applicable)
  • ENI is created for each
  • One IAM Role per Task Definition

Amazon ECS - Env variables

  • Hardcode
  • SSM parameter store
  • Secure manager
  • S3 bulk env variable

Amazon ECS - Data volumes (Bind Mounts)

  • Share data between multiple containers in the same task definition
  • Works for both EC2 launch type and Fargate
  • EC2 lauch type tasks - using EC2 instance storage
  • Fagraste tasks - using ephemeral storage (20-200 GiB)

ECS Taks Placement only EC2 launch type

When Amazon ECS places tasks, it uses the following process to select container instances:

  • identify the instances that satisfy the CPU, memory and port requirements in the task definition
  • Identify task placement constrains
  • Identify task placement strategy
  • Select the instance

Task pacement Strategies

  • Binpack, places tasks based on the least available amount of CPU or memory (cost saving)
  • Random
  • Spread (instance id or AZ)

Task placement Constraints

  • Distinct instance
  • MemberOf (cluster query language)

Amazon ECR - Elastic container registry

  • Store and manage docker images on AWS
  • Private and public
  • Fully integrated with ECS
  • Protected by IAM
  • Support vulnerability scanning , versioning, tags, image lifecycle
  • Login to docker aws ecr get-login-password —region region | docker login --username AWS — password-stdin aws_acc_id.dkr.ecr.region.amazonaws.com
  • Pull/push docker pull aws_acc_id.dkr.ecr.region.amazonaws.com/demo:latest

AWS Copilot

  • CLI tool to build, release and operate production ready containerized apps
  • Run your apps on AppRunner, ECS and Fargate
  • Helps you focus on building apps rather than setting the infra
  • Provision the infra
  • Automated deployment with one command using CodePipeline
  • Deploy to multiple env
  • Troubleshooting, logs

Amazon EKS

  • Amazon elastic kubernetes service
  • Launch managed Kubernetes cluster on AWS
  • Alternative to ECS
  • EKS supports EC2 if you want tot deploy worker nodes and Fargate to deploy server

Node Types:

  • Managed node groups
  • Self managed nodes
  • AWS Fargate

Amazon EKS - data volumes:

  • Need to specify StorageClass manifest on your EKS cluster
  • Leverages a Container Storage Intefaces (CSI) complaint driver

AWS CloudFormation

Benefints:

  • Infrastructure as code
  • No resources are created manually
  • Can be versioned using git
  • Changes to infra are reviewed as code

Productivity:

  • Ability to create and destroy your infrastructure
  • Automated generation of diagram for your templates
  • Declarative programming

Cloudformation building blocks

  • Resources: AWS resources (MANDATORY)
  • Parameters: dynamic inputs
  • Mappings: static variables for your template
  • Outputs: references for created resources
  • Conditionals: list of conditions to do a resource creation
  • Metadata

CloudFormation parameters

We use parameters for everything that is suppose to change in the future.

Types:

  • String
  • Number
  • Comma delimited list
  • List
  • AWS Parameter

To reference the parameter you need to use Fn::Ref or !Ref.

It’s possible to reference what’s defined in parameter declaration block and also resources from template.

Also it’s possible to use pseudo parameters, like AWS::AccountId, AWS::Region.

CloudFormation Mappings

  • Fixed variables in your CloudFormation template
  • Useful to different from different env (stage, dev), or regions
Mapping:
  Mapping0:
    Key0:
      Name: value
    Key1:
      Name: value

To access the mapping we need to use function Fn::FindInMap or !FindInMap [MapName, TopLevelKey, SecondLevelKey].

CloudFormation Outputs

Output value that we can import in another section, you need to export them first.

Enable cross stack collaboration, it’s not possible to delete the stack if the output is used in other template.

Outputs:
  StackSSHSecGroup
    Description: Stack ssh
    Value: !Ref CreatedSSHSecrityGroup
  Export:
    Name: SSHSecGroup

To use it in another template we use function Fn::ImportValue or !ImportValue.

SecurityGroup:
    !ImportValue: SSHSecGroup

CloudFormation Conditions

Conditions allow to create, or not create resources based on value.

Conditions:
  CreateProd: !Equals [!Ref EnvType, prod]
  Fn::And
  Fn::Equals
  Fn::If
  Fn::Not
  Fn::Or

Resources:
  MountPoint:
    Type: AWS::EC2::VolumeAttachment
    Condition:: CreateProd

CloudFomration important functions

  • Fn::Ref - reference params and resources
  • Fn::GetAtt - gives a list of all attributes of a resource
  • Fn::FindInMap - find in mapping
  • Fn::ImportValue - import value that being exported from another template
  • Fn::Join - join value with a delimiter
  • Fn::Sub - substitute

CloudFomration rollback

  • If stack creation fails, default = rollback, but there is an option to disable rollback
  • Rollback is done to the previous working state

CloudFormation notification

Can be done to SNS topic and from it to Email, Lambda and so on.

Possible to enable SNS notification and filter them by lambda function after that send to another SNS notification queue.

CloudFormation ChangeSets, Nested Stacks & StackSet

ChangeSets - gives a way to understand what changes will happen without executing the change.

NestedStack - stacks as a part of other stack, update and isolate repeated patterns and call them from other stacks.

Cross Stacks are using imports and exports, nested stacks are being reused.

StackSet - create update or delete stack through different accounts and organizations with a single operation, if you update it, all the regions/accounts/instances will be updateda.

CloudFormation Drift

If something is deleted from CloudFormation resources manually (from other services) it’s possible to detect drift, by checking in CloudFormation configuration (stack actions => view drift).

It show the different between our old configuration and changes.

CloudFormation Stack Policies

Gives a way to prevent CloudFormation resources updates.

By default it’s possible to change everything.

Amazon Elastic beanstalk

Elastic beanstalk overview:

  • Elastic beanstalk is a developer centric view of deploying an application on AWS
  • It uses all the components like EC2, ASG, ELB, RDS
  • Managed service, automatically handles capacity provisioning, load balancing, scaling, application health monitoring, instance configuration
  • We still have full control over the configuration
  • Beanstalk is free but we pay for the underlying instances

Elastic beanstalk components

  • Application: collection of beanstalk components (environments , versions, configurations)
  • Application version: an iteration of your application code
  • Environment: collection of AWS resources running an application version

Supported languages

  • Go
  • Java
  • .net
  • Nodes
  • Php
  • Python
  • Ruby
  • Packer builder
  • Single docker container
  • Multi-docker container
  • Preconfigured Docker
  • Custom platform

Elastic Beanstalk deployment modes

  • Single instance
  • High availability with load balancer

Beanstalk deployment options for Updates

  • All at once - fastest, but instances aren’t available to serve traffic for a bit
  • Rolling: update a few instances at the time, and then move onto the next bucket once the first bucket is healthy
  • Rolling with additional batches:like rolling but spins up new instances to move the batch
  • Immutable: spins up the new instances in a new ASG, deploys version to these instances, and then swap all the instances when everything is healthy
  • Blue green: create a new environment and switch over when ready
  • Traffic splitting: canary deployment

Elastic Beanstalk CLI

Deployment process:

  • Describe dependencies
  • Package code as zip and describe dependencies
  • Upload zip file or create a new app version using CLI and then deploy
  • Elastic beanstalk will deploy the zip on each EC2 instance, resolve dependencies and start application

Beanstalk lifecycle policy

  • Elastic beanstalk can store at most 1000 application versions
  • If you don’t remove old versions you won’t be able to deploy anymore
  • To phase out old application versions use a lifecycle policy (based on time or space)
  • Versions that are currently used won’t be deleted
  • Option not to delete the source bundle in S3 to prevent data loss

Elastic beanstalk extensions

  • A zip file containing our code must be deployed to Elastic Beanstalk
  • All the parameters set in UI can be configured with code using files
  • In the .ebextensions/ directory in the root of source code
  • YAML or JSON
  • .config extensions
  • Able to modify some defaults settings using option_settings
  • Ability to add resources such as RDS, ElastiCache, DynamoDB
  • Resources ranged by .ebextensions deleted if the environment goes away

Elastic Beanstalk Cloning

  • Clone an environment with the exact same configurations
  • Useful for deploying a “test” version of your application
  • All resources and configuration are preserved
  • After cloning possible to edit

Elastic Beanstalk Migration

Load balancer:

  • After creating an Elastic beanstalk environment, you cannot change the Elastic Load balancer type only config
  • create a new env with same configuration except LB
  • deploy app to the new env
  • shift traffic using AWS Route 53

RDS:

  • RDS can be provisioned with Beanstalk, which is great for dev/test,
  • this is not great for prod as the database lifecycle is tied to the Beanstalk env lifecycle
  • To migrate we need to create a snapshot of RDS
  • Go to the RDS and protect it from deletion
  • Create a new Beanstalk env without RDS, point your application existing RDS
  • Perform route 53 CNAME swap
  • Terminate the old env
  • Delete cloud formation stack manually

Elastic Beanstalk Single Docker

Run your application as a single docker container.

Either provide:

  • Dockerfile: Elastic Beanstalk will build and run the Docker container

Or:

  • Dockerrun.aws.json(v1): Describe where already build Docker image is
  • Image, ports, volumes, logging
  • Beanstalk in Single Docker container does not use ECS

Elastic Beanstalk Multi Docker container

  • Multi docker helps run multiple containers per EC2 instance in EB
  • This will create for you ECS cluster, EC2 isntances, configured to use the ECS cluster, Load Balancer
  • Requires a config Dockerrun.aws.json(v2) at the root of source code
  • Dockerrun.aws.json is used to generate the ECS task definition
  • Your Docker images must be pre-build and stored n ECR for example

Elastic beanstalk and HTTPS

  • idea: load the SSL certification onto the load balancer
  • Can be done from the console (EB console, load balancer configuration)
  • Can be done from the code: .ebextensions/securelisterer-alb.config
  • SSL certificate can be provisioned using ACS or CLI
  • Must configure a security group rule to allow incoming port 443
  • Configure your instance to redirect HTTP to HTTPS
  • Or configure the application load balancer
  • Make sure health checks are not redirected

Web server vs Worker environment

  • If you application performs tasks that are long to complete, offload these tasks to a dedicated work environment
  • Decoupling your application into two tiers is common
  • Example: Processing a video, zip
  • You can define periodic tasks in file cron.yaml

AWS SAM Framework

  • Framework for developing and deploying server less applications
  • All the configurations is YAML code
  • Generate complex CloudFormation from simple SAM YAML file
  • Support anything from CloudFormation
  • Only two commands to deploy to AWS
  • SAM can use CodeDeploy to deploy Lambda functions

SAM example

Transform header indicates it’s a SAM template:

  • Transform: ‘AWS::Serverless-2016-10-31’

Write Code:

  • AWS::Serverless::Function
  • AWS::Serverless::Api
  • AWS::Serverless:SimpleTable

Package and deploy:

aws cloudformation package / sam package
aws cloudformation deploy / sam deploy

SAM Policy Templates

  • List of templates to apply permissions to your Lambda Functions
  • Important examples: S3ReadPloicy, SQSPollerPolicy, DynamoDBCrudPolicy
  • SAM policy becomes IAM role

SAM CodeDeploy

  • SAM framework natively uses CodeDeploy to update Lambda functions
  • Traffic Shifting feature
  • Pre and Post traffic hooks feature to validate deployment
  • Easy & automated rollback using CloudWatch Alarams

SAM Local capabilities

Locally start an API Gateway endpoint:

  • sam local start-api
  • Starts a local HTTP server that hosts all your functions
  • Change to functions are automatically reloaded

Generate AWS events for lambda functions:

  • sam local generate-event
  • Generate sample payloads for events sources
  • S3, API Gateway, SNS, Kinesis, DynamoDB

Serverless application repository

  • Managed repository for server less applications
  • The applications are packaged using SAM
  • Build and publish applications that can be re-used by organizations