You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently without workarounds the only way to access containers on ECS EC2 is with privilege and credentials to SSH onto the Container Instance, as well as user-level access to the Docker daemon to docker exec a container directly. On Fargate, such container-level exec access is currently not supported. Sometimes, it’s difficult to get a full picture of an application from the CloudWatch logs alone. There are times when direct container access is necessary.
We’re planning on adding an ECS exec capability, which will make it possible to gain immediate access to containers running as part of ECS EC2 and Fargate tasks.
ECS Exec Solution Proposal
In order to support exec functionality for ECS, we’ll use the SSM Agent and its session management capabilities.
We plan on bind-mountng an SSM Agent and its dependencies https://github.com/aws/amazon-ssm-agent into the container at container start. A customer’s execute-command session will be directly linked to their container. We’ll also mount the SSM Agent logs from inside the container to a unique directory on the EC2 host.
In this scenario, the ECS Agent takes on the same supervisor role over its owned containers that the init (systemd, upstart) process does on the host, watching over the SSM Agent and its dependent processes. This responsibility includes starting up the process using docker exec and ensuring that this startup is successful; watching over the process while it’s expected to be running, restarting on failure; stopping the process when required.
So what happens to my container?
If I enable this feature on my task/service, all containers launched in that task/service will have the SSM Agent dependencies directory /exec-deps (subject to change) mounted at startup, as well as the log directory /var/log/ecs/execAgent// (subject to change) mount added to the host.
An ECS exec command from my laptop would establish a session-manager session directly inside my container.
The text was updated successfully, but these errors were encountered:
Containers Roadmap link: aws/containers-roadmap#187
Presently without workarounds the only way to access containers on ECS EC2 is with privilege and credentials to SSH onto the Container Instance, as well as user-level access to the Docker daemon to docker exec a container directly. On Fargate, such container-level exec access is currently not supported. Sometimes, it’s difficult to get a full picture of an application from the CloudWatch logs alone. There are times when direct container access is necessary.
We’re planning on adding an ECS exec capability, which will make it possible to gain immediate access to containers running as part of ECS EC2 and Fargate tasks.
ECS Exec Solution Proposal
In order to support exec functionality for ECS, we’ll use the SSM Agent and its session management capabilities.
We plan on bind-mountng an SSM Agent and its dependencies https://github.com/aws/amazon-ssm-agent into the container at container start. A customer’s execute-command session will be directly linked to their container. We’ll also mount the SSM Agent logs from inside the container to a unique directory on the EC2 host.
In this scenario, the ECS Agent takes on the same supervisor role over its owned containers that the init (systemd, upstart) process does on the host, watching over the SSM Agent and its dependent processes. This responsibility includes starting up the process using docker exec and ensuring that this startup is successful; watching over the process while it’s expected to be running, restarting on failure; stopping the process when required.
So what happens to my container?
If I enable this feature on my task/service, all containers launched in that task/service will have the SSM Agent dependencies directory /exec-deps (subject to change) mounted at startup, as well as the log directory /var/log/ecs/execAgent// (subject to change) mount added to the host.
An ECS exec command from my laptop would establish a session-manager session directly inside my container.
The text was updated successfully, but these errors were encountered: