diff --git a/knowledge base/cloud computing/aws/ecs.md b/knowledge base/cloud computing/aws/ecs.md index de242b9..aa3d6c4 100644 --- a/knowledge base/cloud computing/aws/ecs.md +++ b/knowledge base/cloud computing/aws/ecs.md @@ -13,6 +13,10 @@ 1. [Docker volumes](#docker-volumes) 1. [Bind mounts](#bind-mounts) 1. [Execute commands in tasks' containers](#execute-commands-in-tasks-containers) +1. [Allow tasks to communicate with each other](#allow-tasks-to-communicate-with-each-other) + 1. [ECS Service Connect](#ecs-service-connect) + 1. [ECS service discovery](#ecs-service-discovery) + 1. [VPC Lattice](#vpc-lattice) 1. [Scrape metrics using Prometheus](#scrape-metrics-using-prometheus) 1. [Troubleshooting](#troubleshooting) 1. [Invalid 'cpu' setting for task](#invalid-cpu-setting-for-task) @@ -565,6 +569,84 @@ Logging options are configured at the ECS cluster level.
The task's role **will** need to have IAM permissions to log the output to S3 and/or CloudWatch should the cluster be configured for the above options. If the options are **not** configured, then the permissions are **not** required. +## Allow tasks to communicate with each other + +Refer [How can I allow the tasks in my Amazon ECS services to communicate with each other?] and +[Interconnect Amazon ECS services]. + +Tasks in a cluster are **not** normally able to communicate with each other.
+Use ECS Service Connect, ECS service discovery or VPC Lattice to allow that. + +### ECS Service Connect + +ECS Service Connect provides ECS clusters with the configuration they need for service discovery, connectivity, and +traffic monitoring. + +Applications can use short names and standard ports to connect to **services** in the same or other clusters.
+This includes connecting across VPCs in the same AWS Region. + +When using Service Connect, ECS dynamically manages DNS entries for each task as they start and stop.
+It does so by running an agent in each task that is configured to discover the names. + +One **must** provide the complete configuration inside **each** service **and** task definition.
+ECS manages changes to this configuration in each service's deployment and ensures that all tasks in a deployment behave +in the same way. + +Service Connect is **not** compatible with ECS' `host` network mode. + +See also [Use Service Connect to connect Amazon ECS services with short names]. + +### ECS service discovery + +Service discovery helps manage HTTP and DNS namespaces for ECS services. + +ECS syncs the list of launched tasks to AWS Cloud Map.
+Cloud Map maintains DNS records that resolve to the internal IP addresses of one or more tasks from registered +services.
+Other services in the **same** VPC can use such DNS records to send traffic directly to containers using their internal +IP addresses. + +This approach provides low latency since traffic travels directly between the containers. + +ECS service discovery is a good fit when using the `awsvpc` network mode, where: + +- Each task is assigned its own, unique IP address. +- That IP address is an `A` record. +- Each service can have a unique security group assigned. + +When using _bridged network_ mode, `A` records are no longer enough for service discovery and one **must** also use a +`SRV` DNS record. This is due to containers sharing the same IP address and having ports mapped randomly.
+`SRV` records can keep track of both IP addresses and port numbers, but requires applications to be appropriately +configured. + +Service discovery supports only the `A` and `SRV` DNS record types.
+DNS records are automatically added or removed as tasks start or stop for ECS services. + +DNS records have a TTL and it might happen that tasks died before this ended.
+One **must** implement extra logic in one's applications, so that they can handle retries and deal with connection +failures when the records are not yet updated. + +See also [Use service discovery to connect Amazon ECS services with DNS names]. + +### VPC Lattice + +Managed application networking service that customers can use to observe, secure, and monitor applications built across +AWS compute services, VPCs, and accounts without having to modify their code. + +VPC Lattice technically replaces the need for Application Load Balancers by leveraging target groups themselves.
+Target groups which are a collection of compute resources, and can refer EC2 instances, IP addresses, Lambda functions, +and Application Load Balancers.
+Listeners are used to forward traffic to specified target groups when the conditions are met.
+ECS also automatically replaces unhealthy tasks. + +ECS tasks can be enabled **as IP targets** in VPC Lattice by associating their services with a VPC Lattice target +group.
+ECS automatically registers tasks to the VPC Lattice target group when they are launched for registered services. + +Deployments _might_ take longer when using VPC Lattice due to the extent of changes required. + +See also [What is Amazon VPC Lattice?] and its [Amazon VPC Lattice pricing]. + ## Scrape metrics using Prometheus Refer [Prometheus service discovery for AWS ECS] and [Scraping Prometheus metrics from applications running in AWS ECS]. @@ -646,6 +728,8 @@ Specify a supported value for the task CPU and memory in your task definition. - [AWS Distro for OpenTelemetry] - [aws-cloudmap-prometheus-sd] - [Scraping Prometheus metrics from applications running in AWS ECS] +- [How can I allow the tasks in my Amazon ECS services to communicate with each other?] +- [Interconnect Amazon ECS services] [`aws ecs execute-command` results in `TargetNotConnectedException` `The execute command failed due to an internal error`]: https://stackoverflow.com/questions/69261159/aws-ecs-execute-command-results-in-targetnotconnectedexception-the-execute