Access Docker containers in ECS Fargate?

It's a interesting request where the answer is: It's possible, but why?

In many cases the developer choose to build the smallest possible container where the image don't have any shell binary.

For example, the developer decide to build a Go app that has all dependencies linked in the binary. He can build this image using the scratch base (https://hub.docker.com/_/scratch) this will create a docker container with just the binary inside and a pointer to execute this binary.

At the same time there are other projects that use scratch to build other base images like Debian, busybox that will contain shell access and other library dependencies for execution and the container image will be bigger if compared to the previous example.

So, having Ubuntu, Debian and so many container images on Docker, should we use them for workloads? If it's a production workload I would recommend to minimize the container to only the required components that will use less disk space, less bootstrap time as the container image will be smaller to download and the boot time will be faster. Not mentioning that without any shell binary or other component that you app will not use will drastically reduce the chances of remote exploits in your container app.

But where do I run those linux distro images? Probably when you are developing software in your desktop or need to test some desktop app in multiple linux distro versions you can have a series of container images to run tests in all of them without the need to have VM's or physical servers with them. Is that your customer case? building desktop apps where he need to test them? Maybe even if he need to test such apps he probably can run automated scripts to execute commands and get back the results in a log.

If the case is: My customer need visibility of what is happening in the App and debug in case of issues. In this case the recommended approach is to enable app logging (every language provide a logging library and if not, a simple print statement can output the log to stdout or stderr and all those outputs can be captured by Cloudwatch and streamed to Cloudwatch logs to review.

If the concern is memory utilization, temporary files, etc. I would just add an ENVIRONMENT VARIABLE to set the verbosity level of the logs and include the logging statements to output such events in the log for analisys.

Well, there is a lot of aproachs that your customer can adopt and avoid the use of shell in the app.