ECS is Elastic Container Service. It is a container orchestration service that is used to orchestrate containerized applications.
Participants in the ecosystem
This is the maestro of the system. The Elastic Container Service which conducts the orchestra.
Service/Task — Application container
This is the dockerized application that you want running — to basically use the application.
ECS Agent side car
This ECS Agent would be deployed alongside your application container. This would get instructions from ECS to spawn up or bring down the application container.
Task is where the focus is, atleast for the application owners. So everyone is watching the state of the task. The states of the tasks are named from the perspective of ECS.
This means the infrastructure is being set up in which to run the task. ECS takes care of this part.
Now, ECS has provisioned compute in which to run the tasks, and is waiting for the ECS Container agent to bring up the task.
At this point, the task is started. However, it is not yet ready to be exposed to the rest of the world. ECS has other stuff to do related to the task before the task can be called running. For e.g., registering the target groups.
This means that the application task is actually running, and available to use.
ECS has taken charge of the task and is getting ready to stop the task.
ECS is now deprovisioning the compute that it had provisoned earlier for running the task.
Now, the task has been stopped fully by ECS.
Why is my task stuck in PROVISIONING state?
If your task is stuck in PROVISIONING state for a while, that means ECS was unable to provision compute for the task. For example, this could mean that ECS was unable to bring up EC2 instances to run the task on.
This has happened to me when I had
UserData section in the Auto Scaling Group tied to the Capacity provider for the ECS cluster where I was trying to start the task. This had happened because I was trying to mount FSX into EC2, and FSX did not have the right security group/ subnet configurations.