aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.6k stars 3.9k forks source link

asset staging: do not recurse into the output directory #3899

Open jeshan opened 5 years ago

jeshan commented 5 years ago

:bug: Bug Report

What is the problem?

I have hit a corner case with the code related to copy directories. It's going in recursively until Node can no longer handle such long file names.

https://github.com/aws/aws-cdk/blob/16eb65867b79798779bf98a0316b1a05915720f1/packages/%40aws-cdk/assets/lib/fs/copy.ts#L7-L18

The offending snippet is when I had a docker asset declared as follows:

        new DockerImageAsset(this, 'app-image-asset', {
            directory: '.',
            repositoryName: 'my-repo/app',
        });

Running cdk deploy showed me this error:

Error: ENAMETOOLONG: name too long, mkdir 'cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.03918990104d8973acd2ad0abe022844192fcce618cf74f7734a7077f4111d1f'
    at Object.mkdirSync (fs.js:750:3)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:39:16)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)

(Declaring the directory as its full path did not work neither.) This is quite a serious issue for me, personally.

A possible solution is to exclude cdk.out. I think it's reasonable to assume that cdk.out name is reserved for this project.

As a temporary workaround for me, I've edited the code so that it looks like the following:

    const exclude = options.exclude || ['cdk.out'];

Another possible solution is to avoid recursion if we've already seen the directory in question.

Apparently, it's an issue where the docker build context is the same path as the cdk project. That said, I'm not sure if the above is enough to reproduce the issue. When I comment the code to create the docker asset, the issue disappears (probably more of a symptom rather than the cause). I've checked if symlinks are the issue (apparently, it's not)

Environment

rhboyd commented 5 years ago

This usually happens when you try to build an image from within a directory you want included in the image as well. It creates a recursive path that never ends.

joezhou888 commented 5 years ago

I had the same problem.

The only way to make it work is: Project -App Directory -Env Directory

jeshan commented 5 years ago

Thanks Joe. @rhboyd , we could make the exclude directory list an option in cdk.json. What do you think?

eladb commented 5 years ago

This is a bug. It makes sense that when we copy assets into the output directory, we won't descend into the same directory as we copy.

askulkarni2 commented 4 years ago

Saw this issue for a similar use case while using the aws-s3-assets module. I was trying to zip up my cdk project into s3 and use it to bootstrap CodeCommit. Excluding cdk.out seems to work.

const asset = new Asset(this, 'CodeAsset', {
      path: path.join(__dirname, '../'),
      exclude: [
        'node_modules',
        '.git',
        'cdk.out'
      ]
    });
BinaryShrub commented 4 years ago

I added cdk* to .dockerignore to get it working:

// Create Fargate Service
const fargateService = new ecs_patterns.NetworkLoadBalancedFargateService(
  this,
  'sample-app',
  {
    cluster,
    taskImageOptions: {
      image: ecs.ContainerImage.fromAsset('./') // blows up without cdk.out in .dockerignore
    }
  }
)
victorL91 commented 3 years ago

I bumped into this issue again. It may be stupid but I solved it by making sure that the version of aws-cdk on my machine was the same as on the package.json. I was not bootstrapping it the correct way.

wdolek commented 3 years ago

I added cdk* to .dockerignore to get it working:

Don't forget to check your cdk.json, it should contain:

{
  "context": {
    "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true
  }
}

Otherwise .dockerignore is ignored 🤷

mikeshi80 commented 3 years ago

I added cdk* to .dockerignore to get it working:

Don't forget to check your cdk.json, it should contain:

{
  "context": {
    "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true
  }
}

Otherwise .dockerignore is ignored

You saved me!!!

bashleigh commented 3 years ago

I added cdk* to .dockerignore to get it working:

Don't forget to check your cdk.json, it should contain:

{
  "context": {
    "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true
  }
}

Otherwise .dockerignore is ignored 🤷

Mine seems to ignore my .dockerignore file anyway. Could be because I've changed to context dir but I have also tried adding the .dockerignore file to the root of my context

const lith = new lambda.DockerImageFunction(this, `${name}lith`, {
      code: lambda.DockerImageCode.fromImageAsset(path.join(__dirname, '../../../../'), { // root of monolith 
        file: 'packages/deployment-service/Dockerfile', // location of Dockerfile
        ignoreMode: IgnoreMode.DOCKER,
        exclude: [
          'cdk.out',
        ],
      }),
      vpc,
    })

Tried both ~/.dockerfile and ~/packages/deployment-service/.dockerfile. Not sure what else to try!

Edit

Ok so after some investigation: .dockerignore needs to be at the root of the monorepo in my case, in other words: at ../../../../. However I still have a related issue which I'm debugging

another edit

Figured it out. Paths are specified from the asset path. So I needed to be more specific however I'd prefer it if my dockerignore file excluded the cdk dir globally as I specified but hey ho

exclude: [
  'packages/deployment-service/cdk',
],
stevemer commented 2 years ago

Re: "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true,

It looks like this is no longer necessary.

jsii.errors.JSIIError: Unsupported feature flag '@aws-cdk/aws-ecr-assets:dockerIgnoreSupport'. This flag existed on CDKv1 but has been removed in CDKv2. CDK will now behave as the same as when the flag is enabled.
corymhall commented 2 years ago

It looks like this was fixed in https://github.com/aws/aws-cdk/pull/16034. Let us know if anyone is still seeing this issue.

github-actions[bot] commented 2 years ago

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

wallacepreston commented 11 months ago

I'm still seeing this issue. I get this when adding the flag, alright. But I still get the ENAMETOOLONG: name too long error about the cdk.out dir

Re: "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true,

It looks like this is no longer necessary.

jsii.errors.JSIIError: Unsupported feature flag '@aws-cdk/aws-ecr-assets:dockerIgnoreSupport'. This flag existed on CDKv1 but has been removed in CDKv2. CDK will now behave as the same as when the flag is enabled.
abury commented 10 months ago

Seeing this issue pop up again in random repos :(

Figured it out thanks to @bashleigh 's detailed comment! I ignored the entire cdk folder at the root and all was well

austinschrader commented 9 months ago

Seeing this issue pop up again in random repos :(

Figured it out thanks to @bashleigh 's detailed comment! I ignored the entire cdk folder at the root and all was well

Could you share how you ignored the entire cdk folder at the root? .dockerignore doesn't seem to work as the flag @aws-cdk/aws-ecr-assets:dockerIgnoreSupport was deprecated in cdk v2

github-actions[bot] commented 8 months ago

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

robertIanClarkson commented 7 months ago

I am experimenting with polylith monorepo with components, bases, projects that looks similar to this...

├── .dockerignore << add */**/cdk.out
├── bases
│   └── ts
│       └── some-base-pkg
│           └── src
├── components
│   └── ts
│       └── some-component-pkg
│           └── src
└── projects
    └── ts
        └── some-project-pkg << running cdk deploy
            └── Dockerfile
            └── cdk.json
            └── src
            └── bin
                └── cdk-app.ts << cdk code

My cdk-app.ts includes some code like this

const asset = new cdk.aws_ecr_assets.DockerImageAsset(this, "some-id", {
  directory: "/my/project/root,
  file: "projects/ts/some-project-pkg/Dockerfile"
})

what worked for me was added */**/cdk.out to my root .dockerignore. Hope this helps someone!