The AWS ECS docker Exec allows the users to engage in an interactive section with a container in a shell or with a single command.

Bobcares answers to all inquiries, big or small, as part of our AWS Support Service.

Let’s take a look at How Esc Exec works in detail.

 How ECS Exec Functions 

 ECS Exec is a leverage for the AWS system manager and the SSM session manager. It creates a secure channel between the device used to launch the “exec” command and the targeted container.

The SSM agent binaries are bind-mount into the containers. And, The ECS agents are responsible for starting the SSM core agent within the container next to the application code.

AWS manages and summarises this behavior and is fully clear to the user. So the user only needs to know about the application process defined in the Dockerfile.

ECS Exec lets the users interact with the container at its initial release in a single command.

AWS ECS and docker Exec

The Elastic container service or the ecs is a Docker container management system. the aws ecs uses docker to launch containers. The docker is a technology that allows the user to build and manage the applications in a container.

The ecs exec allows the user to connect with the containers and communicate with it. The users can perform internal container activities using the docker.

The aws ecs docker exec forms a well-established container management system. The aws ecs  docker exec allows the users to have direct communication and control over the containers.

Using ECS Exec for Debugging

 The Amazon ECS Exec allows the users to have direct communication with the containers. It avoids the first host container operating system, open bound ports, or the SSH key management interaction.

ECS makes it easier to collect info on tests and troubleshoot the errors immediately. ECS makes this possible by allowing the users to run commands in it.

This will include a shell to the container running on an Amazon EC2 instance or AWS Fargate.

The framework of AWS Ecs Exec

ECS Exec connects with the running container using AWS Systems Manager (SSM) Session Manager. It restricts running commands in a running container using AWS Identity and Access Management (IAM) policies.  

The SSM core agent starts within the container alongside the application code via the Amazon ECS or AWS Fargate.

Using AWS CloudTrail; users can track the container access. It will report each command (and its output) to Amazon S3 or Amazon ‘CloudWatch’ Logs.

Provide the AWS Key Management Service key to encrypt data between the local client and the container with the encryption key.

Use of ECS Exec: considerations

It is critical to be aware of the following when utilizing ECS Exec for this topic.

• AWS Fargate, external instances (ECS Anywhere), Linux containers hosted on Amazon EC2 support ECS Exec.

The following Windows Amazon ECS-optimized AMIs (with the container agent version 1.56 or later)are all supported by ECS EXEC:

• Amazon ECS-optimized Windows Server 2022 Full AMI
• Amazon ECS-optimized Windows Server 2022 Core AMI
• Amazon ECS-optimized Windows Server 2019 Full AMI
• Amazon ECS-optimized Windows Server 2019 Core AMI
• Amazon ECS-optimized Windows Server 20H2 Core AMI

• The AWS Management Console does not support ECS Exec.

•  At first, ECS Exec won’t yet support tasks with an Auto Scaling group.

• Create the interface Amazon VPC endpoints for Systems manager Session manager if Amazon VPL endpoints employ Amazon ECS.

• ECS Exec is not for live tasks. It is only possible to enable new tasks.

• When a user uses ECS Exec, to do commands on a container, the commands are run as the root user. Even If the user ID is set for the container, the SSM agent and its child processes execute as root.

• The default idle timeout for an ECS Exec session is 20 minutes.

• To create the appropriate directories and files, the SSM agent demands that the container file system be able to be written to.

• Using the ‘readonlyRootFilessystem’ task detention limit, or any other way to make the root file systems read-only won’t support it.

Important Considerations 

• All commands available within the container context are visible to the users. Terminating the container main process, the command agent, and eliminating dependencies; could result in orphaned and zombie processes.

• While it is possible to start SSM sessions outside of the execute-command action, the sessions will not be registered and counted against the session limit.Use the IAM policy to restrict access to the ssm:start-session function.

•  ECS Exec uses CPU and memory. When defining the CPU and memory resources in task specification, and make sure to account for this.

• AWS CLI version 1.22.3 or later, or AWS CLI version 2.3.6 or later, is required.

• • When using ‘run-task’ to launch a task on a cluster that employs controllers scaling with non-synchronous placement, it is impossible to assess ecs exec.

Requirements for using ECS Exec

Before using ECS Exec, make sure the completion of actions:

1. Install and set up AWS CLI and install the AWS CLI Session Manager plugin.
2. Depending on whether host tasks are on Amazon EC2 or AWS Fargate, ECS Exec has version demands:
3. • For Amazon EC2, use an Amazon ECS optimized AMI with the agent version of 1.50.2 or higher issued after January 20th, 2021
   • Use the platform version 1.4.0 or higher (Linux) or 1.0.0 (Windows) for AWS Fargate.

Activation and usage

IAM rights

To give containers the rights for communication between the managed SSM agent and the SSM service, the ECS Exec future demands a task IAM role.

To add the SSM permissions use the following policy for the task IAM role:

{

   "Version": "2012-10-17",

   "Statement": [

       {

       "Effect": "Allow",

       "Action": [

     "ssmmessages:CreateControlChannel",

      "ssmmessages:CreateDataChannel",
       "ssmmessages:OpenControlChannel",

       "ssmmessages:OpenDataChannel"

       ],

      "Resource": "*"

    }

  ]

}

ECS For tasks and services 

When using AWS CLI commands ‘Creative service’, ‘Updated-service’, ‘Start-task’, or ‘run-task’, the ECS Exec ability activates. It is for services and standalone tasks by using the ‘enable-execute command’, flag.

To make a new device’s, functionality

Run the following command, to make a new device’s ECS Exec functionality active.

aws ecs create-service \

    --cluster cluster-name \

    --task-definition task-definition-name \

    --enable-execute-command \

    --service-name service-name \

    --desired-count 1

Confirm task preparation using the following command after enabling ECS Exechas. Task, if the lastStatus property of the ‘ExecuteCommandAgent’ is listed as RUNNING and the ‘enableExecuteCommand’ property is set to true.

 

aws ecs describe-tasks \

    --cluster cluster-name \

    --tasks task-id

The following output is an example of the result.

 

{

"tasks": [
 {

  ...

 "containers": [

  {

  ...
managedAgents": [

 {
  "lastStartedAt": "2021-03-01T14:49:44.574000-06:00",

      "name": "ExecuteCommandAgent",

        "lastStatus": "RUNNING"

     }

     ]

     }

      ],

       ...

   "enableExecuteCommand": true,

      ...

  }

  ]
}

Running commands using ECS Exec

Confirm that the ‘ExecuteCommandAgent’ is running. open an interactive shell using the following command.

If the task includes different containers, define the container name ‘–container’ flag. Amazon ECS only supports launching interactive sessions,--interactive flag.

The command given below runs an interactive /bin/sh command against a container. And, The container is named as ‘container-name’ for a task with an id of task-id.

aws ecs execute-command --cluster cluster-name \

    --task task-id \

    --container container-name \

    --interactive \

    --command "/bin/sh"

[Need assistance with similar queries? we are here to help]

Conclusion

To conclude, with the AWS ECS docker Exec, users can have more control over the containers. In addition, the developers can utilize the docker functions combined with the ECS Exec to perform application-level treatments on the container.