ECS

5.2. Running and Orchestrating Containers with ECS and Fargate

5.2.1. Introduction

• Amazon Elastic Container Service (ECS):

  • A highly scalable and fast container management service.

  • Offers a management plane to orchestrate containers in a cluster.

  • Essential capabilities: run, stop, and manage containers.

  • Enhances development processes and reduces operations/ liabilities.

• Fargate Launch Type:

  • Users do not need to manage the underlying infrastructure.

  • Focuses on specifying the container image and workload capabilities (memory or virtual CPUs required).

• AWS IAM Integration:

  • Fine-grained permissions can be defined based on requirements.

  • Eliminates concerns regarding user management (passwords, etc.).

  • Enables compliance through isolation.

• CloudWatch Integration:

  • Provides metrics and logs for monitoring applications.

• Focus on Fargate: ECS is a battle-tested service preferred for critical core infrastructure handling high-volume requests (microservice APIs).

5.2.2. Understanding the Key Terms of ECS

• Key terms are vital to comprehending ECS internals.

• Main Concepts:

  • Containers

  • Tasks and Task Definitions

  • Services

  • Clusters

5.2.2.1. Containers: Lightweight and Portable Packages That Actually Run Your Applications

• Docker: Core building blocks of a container service.

• Containers:

  • Lightweight environments for applications.

  • Consolidate necessary information (libraries, languages) for execution on any system.

  • Multiple containers can run on a single machine, maintaining intra-container communication while ensuring host security.

• Challenges in Management:

  • As applications and containers grow, orchestration issues arise (deployment, scaling, etc.).

  • ECS provides a management plane simplifying these tasks to let developers focus on application development.

5.2.2.2. Task Definition - The Blueprint to Run Your Containers

• Task Definition: Blueprint for launching multiple containers, including:

  • Launch Type: EC2, Fargate, or External.

  • Roles: Two roles needed:

  1. Task Execution Role: Allows permissions needed to start containers.

  2. Task Role: Grants permissions to applications within containers (e.g., DynamoDB queries).

  • Container Image: Docker image stored in a container registry.

  • vCPU & Memory Allocation: Compute resources assigned depend on launch type.

  • Environment Variables: Key-value pairs for injecting parameters.

  • Secrets: Securely inject sensitive data from AWS Secrets Manager or Systems Manager Parameter Store.

  • Logging Configuration: Specify log drivers and their destinations (Fargate supports limited options compared to EC2).

  • Exposed Ports: Map inbound traffic ports between ECS and container images.

5.2.2.3. Task - A Containerized Application That Is Deployed to Run on EC2 or Fargate

• Task: Execution of a task definition; comprises multiple containers on the same host.

  • Defined using Docker Compose format for specifying container image, environment variables, etc.

  • Remains active until manually stopped or it exits.

5.2.2.4. Service - Managing a Group of Tasks

• Service: Long-running process managing a group of tasks, ensuring a desired number remain operational.

  • Automatically replaces unhealthy tasks.

5.2.2.5. Clusters - A Logical Grouping of Container Instances

• Cluster: Logical grouping of tasks/services running on registered infrastructure:

  • Can be on AWS Fargate, EC2 instances you manage, or on-premises servers.

5.2.3. Launch Types - The Way in Which Tasks Are Run and Managed

• Options for running containers in ECS:

5.2.3.1. EC2 - Using Your Own Instances to Run Tasks within a Cluster

• Deploy EC2 instances to run containers.

• Full control over underlying infrastructure.

• Suitable for high and consistent CPU/memory workloads.

5.2.3.2. Fargate - Run Tasks without Having to Manage the Underlying Infrastructure

• Serverless, pay-as-you-go option.

• Specify task details while ECS provisions compute resources automatically.

• Recommended for workloads with low overhead and occasional bursts.

5.2.3.3. External - Orchestrating Your On-Premises Containers

• Allows remote registration for on-premise containers within ECS orchestration capabilities.

5.2.4. Task Scheduling - Running Your Tasks

• Task Scheduling: Assigning tasks to container instances within a cluster using ECS's dynamic scheduling algorithm.

5.2.4.1. How Your Task Passes through Different States in Its Lifecycle

• ECS Task Lifecycle States:

  1. Provisioning: Attaching Elastic Network Interface (ENI)

  2. Pending: Waiting for task resources availability.

  3. Activating: Final steps before running state.

  4. Running: The task is running successfully.

  5. Deactivating: Final steps before stopping.

  6. Stopping: Gracefully shutting down containers with SIGTERM; forced shutdown with SIGKILL if timeout exceeds.

  7. Deprovisioning: Final transition steps to stopped state.

  8. Stopped: Task has been successfully stopped.

5.2.4.2. Running Tasks on a Regular Schedule

• Tasks can be scheduled using EventBridge events.

5.2.4.3. Running Standalone Tasks on Demand

• Standalone tasks can be triggered manually for testing/development, with defined parameters on launch.

5.2.5. Persisting Your Images at the Elastic Container Registry

• Elastic Container Registry (ECR): Fully-managed registry for hosting and sharing container images.

• Integrates with ECS, EKS, and AWS Lambda.

• No upfront costs; pay per usage for data and transfer to the internet.

5.2.6. Creating Our First ECS Service That Runs a Node.js Application in Fargate

• Steps:

  1. Initialize a new container registry in ECR.

  2. Set up and package a Node.js application into a Docker image, push it to ECR.

  3. Create a new ECS cluster.

  4. Set up a new task definition referencing the ECR image.

  5. Launch the Serverless service orchestrating containers and monitoring health.

  6. Expose tasks via an Application Load Balancer and create a target group.

  7. Send an HTTP GET request to the application to verify functionality.

5.2.6.1. A New ECR Repository for Our Image

• Create a private ECR repository for images.

• Push commands provided for interacting with the repository.

5.2.6.2. Building and Pushing an Image with a Simple Node.js Application

• Steps include installing NPM, creating a directory for the project, initializing Node.js, and developing a minimal application.

• Complete Dockerfile provided for building the image.

5.2.6.3. Creating a Cluster

• An ECS cluster logically groups tasks/services.

• Default settings can be used for VPC configuration.

5.2.6.4. Setting up a Task Definition

• Task definitions detail the launch of the container, include configurations for environment, compute settings, etc.

5.2.6.5. Establishing and Launching a New Service

• Create a service to ensure the desired number of tasks are continuously running, implementing a rule for incoming traffic from the Internet via a security group.

5.2.7. Securing Your Tasks and Clusters

• Shared Responsibility Model:

  • Security in the Cloud: Customer is responsible for data, OS, networks.

  • Security of the Cloud: AWS secures the underlying infrastructure.

• Best Practices for Security:

  1. Use ECR for a secure container image registry.

  2. Employ IAM roles to control ECS resource access with minimal permissions.

  3. Utilize Security Groups to define allowed incoming traffic.

  4. Encrypt data both in transit and at rest with TLS and AWS features.

5.2.8. Deploying Updated Task Definitions

• Deployment Strategies:

  • Rolling updates where ECS allows for a certain number of healthy tasks during update.

• Example:

  • Desired count: 3 containers, Minimum percentage: 100%, Maximum percentage: 150%.

5.2.8.1. Speeding Up Deployments by Fine-Tuning Different Settings

• Deployment timing can be optimized by adjusting settings within ECS and load balancer.

5.2.9. Monitoring Key Metrics of Your Tasks and Clusters with CloudWatch

• Key Metrics:

  1. Task/cluster status events.

  2. Resource utilization (CPU, memory, network).

  3. Network traffic.

5.2.10. Automatically Scaling Your Containers Based on Traffic Demands

• Multiple scaling options including step, target tracking and scheduled policies.

5.2.10.1. Step Scaling Policies

• Definitions and thresholds related to CPU and memory utilization for cluster adjustments.

5.2.10.2. Target Tracking Scaling Policies

• Target tracking is the favored policy by AWS, with CloudWatch managing alarms for necessary scaling actions.

5.2.10.3. Scheduled Scaling Policies

• Adjust the desired task count based on known load patterns throughout the day.

5.2.11. Leveraging AWS Cloud Map

• Service discovery can become complex; AWS Cloud Map provides a managed solution.

  • Client-Based Discovery: Clients connect to service registry.

  • Server-Based Discovery: Clients use a load balancer.

5.2.12. The Endless Use Cases of Container Services

• ECS is integral for enterprises, supports many applications and migration strategies.

5.2.12.1. Migrating Existing On-Premise Applications to the Cloud

• Reasons for migration include:
  1. Existing software in production generally remains stable.
  2. Monolithic applications can be containerized more easily.
  3. Cloud independence of containerized applications.

5.2.12.2. A Story of Moving to the Cloud and Switching Database Solutions

• Detailed migration phases from on-premise Java application transition to AWS.

  1. Data copied to DynamoDB.

  2. Application containerization, testing on ECS.

  3. Removal of on-premise storage.

  4. DNS switch for live traffic.

5.2.13. Be Aware of Incurring Costs

• Costs are associated with underlying resources needed to run containers, despite ECS itself being free.

  • AWS free tier limits and charges for various services outlined.

5.2.29. Tips & Tricks for the Real World

• Practical reminders for effective ECS usage, including optimal setup and security practices for services.

5.2.30. Final Words

• ECS is a critical service with wide adoption; foundational knowledge in container orchestration is essential for engineering roles and overall understanding.