aws / containers-roadmap

This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).
https://aws.amazon.com/about-aws/whats-new/containers/
Other
5.22k stars 321 forks source link

[ECS, Fargate]: Support for running Docker-in-Docker containers #1356

Open drissamri opened 3 years ago

drissamri commented 3 years ago

Tell us about your request Currently it is not possible to use Docker-in-Docker on Fargate. We use Fargate to run our Jenkins jobs, and there are a lot of usecases where it is useful to have run Docker inside those jobs.

Which service(s) is this request for? Fargate, ECS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? One of our examples is running Testcontainers inside our unit tests to mock external dependencies like DynamoDB, Queues, Redis, ... and so on.

I was hoping the solution would be an outcome of https://github.com/aws/containers-roadmap/issues/95 but this was recently closed with an alternative way to build containers.

Community Note

antgel commented 2 years ago

Thanks for opening this, I don't believe that #95 should have been closed.

mehtaparas commented 2 years ago

I agree, I don't believe #95 should have been closed. Can we get an update / response on this issue?

For context, I'm interested in this issue because I want to be able to deploy Airbyte on ECS.

boyapatisandeep commented 2 years ago

Any update on this using docker in docker for Fargate ?

mjy90 commented 2 years ago

Any updates? This feature would be fantastically useful for our business.

nabsource commented 1 year ago

This would be a great addition, would it be possible to get an update on this?

aaronsteers commented 1 year ago

I wanted to ask if anyone has tried one of these options, or can speak to whether they would be feasible.

Workaround option 1: leveraging side-car containers

As a workaround to not having docker-in-docker support in ECS, has anyone been successful in declaring a sidecar container in the ECS task definition and executing the bespoke workloads in that way?

Caveats of course are that this only works if the secondary container's image is known ahead of time and the container would presumably need to wait in a holding pattern until it receives some command or workload from the primary container. Logistics of this are non-trivial, but at least in theory it could/should be possible for certain use cases.

Curious if anyone has tried this approach or knows ahead if it would be viable.

Workaround option 2: alternative lighter-weight runtimes

Another alternative would be if certain non-priveleged workloads (meaning workloads that do not needing volume access, etc.) could run on a less-priveleged container runtime that were installed on the Fargate container directly, like runc, podman, or sysbox, etc.).

I don't know if any of these runtimes would be compatible from running within ECS or Fargate. In theory, it seems possible, but I don't know if there are specific limitations of ECS-created containers which would block a tool from being installed and run, even in a non-privileged manner.

AllanOricil commented 1 year ago

Another use case to use it is with Github Actions when jobs run inside containers.

jerryeml commented 1 year ago

looking forward to update this

jaslkaur29 commented 1 year ago

Any update planned on this in the future?

RazvanGherlea commented 1 year ago

Hi All,

Are you saying that if we would like to use the ECS Fargate Service container as self hsoted runner we cannot define a specific container in the ci/cd pipeline like the following example ?

https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#define-image-in-the-gitlab-ciyml-file

Thanks in advance

billyjbryant commented 12 months ago

@RazvanGherlea

Are you saying that if we would like to use the ECS Fargate Service container as self hsoted runner we cannot define a specific container in the ci/cd pipeline like the following example ?

Yes, the issue currently, is that you cannot run Docker in Docker (DinD) on ECS Fargate as the task runs without --privileged mode and will not allow the container launched in your Self Hosted Runner's task to mount or interact with the container's filesystem.

OpenSourceable commented 10 months ago

@billyjbryant Have you considered using Kaniko as suggested here? This repo has some examples: https://github.com/int128/kaniko-action

jesseadams commented 9 months ago

I'm not sure why everyone keeps reading this issue as "needing to build a docker image in ECS Fargate" versus what its actually looking for, which is running a docker container within a running Task in ECS Fargate.

Example: An ECS Fargate task running jenkins/inbound-agent:latest-alpine-jdk21 with a Jenkinsfile that tries to run the following.

node('ecs') {
  stage('Checkout Code') {
    scm_vars = checkout scm
    env.GIT_COMMIT = scm_vars.GIT_COMMIT
  }

  stage('Node Version') {
      docker.image('node:lts-alpine').inside {
          sh 'node -v'
      }
  }
}

Otherwise the jenkins build agent container needs to have EVERYTHING installed on it that you need for all of your pipelines, which is unreasonable.