Amazon ECS Concepts: Difference between revisions
| Line 159: | Line 159: | ||
An Amazon ECS '''service''' allows running and maintain a specified number (the "desired count") of simultaneous instances of a [[#Task|task]], created based on a [[#Task_Definition|task definition]], in an ECS [[#Cluster|cluster]]. The service launches and maintains running tasks in the cluster. It detects stopped tasks and starts new ones to maintain the number of tasks specified in the service definition. If the number of tasks exceeds 1, a [[AWS_Elastic_Load_Balancing_Concepts#Load_Balancer|load balancer]] is required to distribute incoming traffic amongst sibling tasks. Unlike a [[#Task_Definition|task definition]], a service only exists within a [[#Cluster|cluster]], and cannot be shared between clusters. From this perspective, a service can be thought of as an instantiation context of a task, specifying the cluster, the VPC, subnet, security group, etc. An AWS ECS service is equivalent with a combination of a [[OpenShift_Concepts#Replication_Controller|Kubernetes replication controller]] and a [[OpenShift_Concepts#Service|Kubernetes service]], though the AWS service does not do the load balancing itself, it delegates it to a load balancer. | An Amazon ECS '''service''' allows running and maintain a specified number (the "desired count") of simultaneous instances of a [[#Task|task]], created based on a [[#Task_Definition|task definition]], in an ECS [[#Cluster|cluster]]. The service launches and maintains running tasks in the cluster. It detects stopped tasks and starts new ones to maintain the number of tasks specified in the service definition. If the number of tasks exceeds 1, a [[AWS_Elastic_Load_Balancing_Concepts#Load_Balancer|load balancer]] is required to distribute incoming traffic amongst sibling tasks. Unlike a [[#Task_Definition|task definition]], a service only exists within a [[#Cluster|cluster]], and cannot be shared between clusters. From this perspective, a service can be thought of as an instantiation context of a task, specifying the cluster, the VPC, subnet, security group, etc. An AWS ECS service is equivalent with a combination of a [[OpenShift_Concepts#Replication_Controller|Kubernetes replication controller]] and a [[OpenShift_Concepts#Service|Kubernetes service]], though the AWS service does not do the load balancing itself, it delegates it to a load balancer. | ||
==Service Type== | ==Service Configuration Elements== | ||
===Service Name=== | |||
===Service Type=== | |||
It ca be REPLICA for a FARGATE launch, or REPLICA or DAEMON an EC2 launch. | It ca be REPLICA for a FARGATE launch, or REPLICA or DAEMON an EC2 launch. | ||
==<span id='Security_Group'></span>Service Security Group== | ===<span id='Security_Group'></span>Service Security Group=== | ||
A security group is created to allow all public traffic to the service only on the container port specified. Security groups and network access can be further refined after the service creation. | A security group is created to allow all public traffic to the service only on the container port specified. Security groups and network access can be further refined after the service creation. | ||
| Line 169: | Line 173: | ||
The name of the security group can be changed at this stage, as well as the port configuration. | The name of the security group can be changed at this stage, as well as the port configuration. | ||
==<span id='Load_Balancer_Type'></span>Service Load Balancing== | ===<span id='Load_Balancer_Type'></span>Service Load Balancing=== | ||
{{Warn|Load balancing settings can only be configured on service creation. If the service is to be exposed as integration endpoint by the API Gateway, it needs a network load balancer.}} | {{Warn|Load balancing settings can only be configured on service creation. If the service is to be exposed as integration endpoint by the API Gateway, it needs a network load balancer.}} | ||
| Line 176: | Line 180: | ||
Each load balancer declared in the service definition refers by name a container declared in a task definition. The value used as "ContainerName" must match the value of the [[#Container_Name|container's name]], as declared in the [[#Task_Definition|task definition]]. | Each load balancer declared in the service definition refers by name a container declared in a task definition. The value used as "ContainerName" must match the value of the [[#Container_Name|container's name]], as declared in the [[#Task_Definition|task definition]]. | ||
==<span id='Service_Discovery'></span>Service Discovery and DNS== | ===<span id='Service_Discovery'></span>Service Discovery and DNS=== | ||
{{Warn|Updating existing services to configure service discovery for the first time or change the current configuration is not supported. Service discovery should be configured when the service is created.}} | {{Warn|Updating existing services to configure service discovery for the first time or change the current configuration is not supported. Service discovery should be configured when the service is created.}} | ||
Revision as of 01:18, 31 March 2019
External
Internal
Overview
Amazon Elastic Container Service (ECS) allows deploying Docker containers on a scalable cluster. Docker images to be deployed typically come from Amazon ECR.
Container
A container, in this context, is a Docker container, concept explained at length here:
Cluster
An Amazon ECS cluster is a regional, logical grouping of tasks and services. If the tasks or services in question use the EC2 launch type, the cluster is also a grouping of container instances. A default cluster is always available, but multiple clusters can be created in an account to keep your resources separate. A cluster cannot span more than one region.
Relationship between a Cluster and a VPC
TODO
Cluster Configuration
Cluster Name
Cluster VPC
See above:
Cluster Subnets
Cluster Operations
Task
An Amazon ECS task is a running instance of a container. A running task listens on ports, generates logs, and hopefully does useful work. The running tasks is generated based on a task definition and is usually started by a service. However, a task can be manually run (Task Definitions -> Actions -> Run Task) after specifying the cluster, the number of tasks, the VPC and the subnet. The Amazon ECS task is equivalent with a Kubernetes pod.
Running Task
A running task is based on a task definition and it has an unique ID (e.g. e822d0018c324c47a2001e8ea6a76d4f). The running task has associated time statistics, such as "Created at" and "Started at". Also, stdout content generated while the task is running is available as Cluster -> <cluster-name> -> Tasks -> <task-id> -> Logs. Every time the task is started, it gets a new Private IP, and if it was configured with one, a new Public IP.
A running task may be started by a service. When a task has been started by a service, the task could be restarted (re-deployed) by navigating in console to the service, selecting the task, selecting the task in question and then "Stop"-ing it. A warning will pop up, saying that the task has been started by a service, but it can be safely stopped: the service will start a replacement. However, this is normally not necessary, the service detects failed tasks and starts new ones automatically.
Consolidate with Deployments.
Stopped Task
Task Definition
An Amazon ECS task definition is a blueprint, or a configuration, for an application, and describes one or more containers through attributes. The task definition is used by a service to start tasks. Task definitions exist outside clusters, and can be shared between clusters. Some task definition attributes are configured at the task level but the majority of attributes are configured per container. The task definition specifies the Docker image, how many containers to use for this task and the resource allocation for each container. To modify the task definition, a new revision must be created and then apply required changes to the task definition.
Revision
A new task revision is created when a task definition is modified. Each revision is identified by a revision number, and they are grouped together under the task definition's family.
Task Definition Configuration Elements
Family
The family is a common name for multiple revisions of the same task definition, where each revision is specified by a revision number. It is referred to as "Task Definition Name" by the AWS Console.
Compatibilities
The launch type used by the task. Currently, "FARGATE" and "EC2" are available as options.
Task Role
The task role is the IAM role that allows the containers in the task permission to call the AWS APIs that are specified in its associated policies on the IAM user's behalf. This is how a task role is created:
Task Execution Role
The task execution role is the IAM role that allows the containers in the task to pull container images, publish container logs to CloudWatch, upgrade the load balancer with the endpoint details of the containers, all on the IAM user's behalf. This is how a task execution role is created:
Network Mode
The Docker networking mode to use for the container in the task. Typically "awsvpc".
Task Memory
Expressed in MB. Also see container memory.
Task CPU
Expressed in millicores. Also see container CPU.
Container Definition
Multiple container definitions can be declared as part of the task definition, and each container definition includes the following elements:
Container Name
The name of the container. Not to be confused with the image. This name will be used by the load balancers declared in the service definition to refer to this container.
Container Image
The name of the image to start a container. This string is passed directly to the Docker daemon. Images in the Docker Hub registry are available by default. Other repositories can also be specified using the <repository-url>/<image>:<tag> or <repository-url>/<image>@<digest> syntax.
Essential Flag
If the container is marked as "essential" and if that container fails or stops for any reason, all other containers that are part of the task are stopped. If the essential parameter of a container is marked as false, then its failure does not affect the rest of the containers in a task. If this parameter is omitted, a container is assumed to be essential. All tasks must have at least one essential container. If you have an application that is composed of multiple containers, you should group containers that are used for a common purpose into components, and separate the different components into multiple task definitions.
Container Memory
Also see task memory.
Container CPU
Also see task cpu.
Container Port Mappings
Container Environment
Container Log Configuration
An "awslogs-stream-prefix" is optional, if nothing is specified, the streams will be named container-name/3ad0d60e-193a-49e4-b004-5599134b067e
Task Definition Operations
Launch Type
EC2 Launch Type
The EC2 launch type allows running a containerized applications on a cluster of Amazon EC2 instances.
Fargate Launch Type
The Fargate launch type allows running a containerized application without the need to provision and manage the backend infrastructure. It only requires registering a task definition. When that is available, Fargate launches the container.
Service
An Amazon ECS service allows running and maintain a specified number (the "desired count") of simultaneous instances of a task, created based on a task definition, in an ECS cluster. The service launches and maintains running tasks in the cluster. It detects stopped tasks and starts new ones to maintain the number of tasks specified in the service definition. If the number of tasks exceeds 1, a load balancer is required to distribute incoming traffic amongst sibling tasks. Unlike a task definition, a service only exists within a cluster, and cannot be shared between clusters. From this perspective, a service can be thought of as an instantiation context of a task, specifying the cluster, the VPC, subnet, security group, etc. An AWS ECS service is equivalent with a combination of a Kubernetes replication controller and a Kubernetes service, though the AWS service does not do the load balancing itself, it delegates it to a load balancer.
Service Configuration Elements
Service Name
Service Type
It ca be REPLICA for a FARGATE launch, or REPLICA or DAEMON an EC2 launch.
Service Security Group
A security group is created to allow all public traffic to the service only on the container port specified. Security groups and network access can be further refined after the service creation.
The name of the security group can be changed at this stage, as well as the port configuration.
Service Load Balancing
Load balancing settings can only be configured on service creation. If the service is to be exposed as integration endpoint by the API Gateway, it needs a network load balancer.
Each load balancer declared in the service definition refers by name a container declared in a task definition. The value used as "ContainerName" must match the value of the container's name, as declared in the task definition.
Service Discovery and DNS
Updating existing services to configure service discovery for the first time or change the current configuration is not supported. Service discovery should be configured when the service is created.
If the service discovery was enabled for a service, the service's private IP address becomes resolvable as a internal DNS name in the namespace that was configured for the service. The DNS name is correctly resolved a newly-allocated IP address, should the backing task be restarted and get a new IP address.
Service Operations
Deployments
Consolidate with Running Tasks.
Rolling Update
A rolling update replaces the current version of the task in the service with a new version. To control the number of your service's tasks in the RUNNING state during a deployment, set the "minimum healthy percent" and "maxium healthy percent" values. This deployment configuration allows for AWS CLI command line redeployments.
Blue/Green Deployment
A blue/green deployment allows to verify a new version of the application before routing production traffic to it. Production traffic can be routed between new and old versions, closely monitor the deployment process, and quickly rollback a deployment if there is an issue.
Choosing a blue/green deployment for an ECS service will configure the service with a deployment controller of type "CODE_DEPLOY" - which means AWS CodeDeploy - and will also automatically create corresponding AWS CodeDeploy application and deployment group with default settings that can be updated later. This configuration is required if an (additional) AWS CodeDeploy deployment group is created for this service.
ECS Networking
CloudFormation
Auto Scaling
TODO