-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(cdk-pipelines): Docker rate limit, guidance needed or auth mechanism #11774
Comments
maybe this is helpful: |
@rix0rrr I know you guys are probably busy with the conference this week, but I can't deploy code due to this problem... From the output, looks like you are logging in with an here's further info: CDK Code: /**
* Build an image with the entire monorepo to work with
*/
const dockerImage = new DockerImageAsset(this, baseId("DockerImage"), {
directory: ".",
file: `./docker/ci.Dockerfile`,
})
const image = ecs.ContainerImage.fromDockerImageAsset(dockerImage) Terminal / Codebuild Output: [Container] 2020/11/30 17:43:08 Running command cdk-assets --path "assembly-PipelineStack-Pre/PipelineStackPreService574433AC.assets.json" --verbose publish "c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36:433775104113-us-east-1"
--
28 | verbose: Loaded manifest from assembly-PipelineStack-Pre/PipelineStackPreService574433AC.assets.json: 2 assets found
29 | verbose: Applied selection: 1 assets selected.
30 | info : [0%] start: Publishing c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36:433775104113-us-east-1
31 | verbose: Assume arn:aws:iam::433775104113:role/cdk-hnb659fds-image-publishing-role-433775104113-us-east-1
32 | verbose: [0%] check: Check 433775104113.dkr.ecr.us-east-1.amazonaws.com/cdk-hnb659fds-container-assets-433775104113-us-east-1:c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36
33 | verbose: [0%] debug: docker login --username AWS --password-stdin https://433775104113.dkr.ecr.us-east-1.amazonaws.com
34 | verbose: [0%] debug: docker inspect cdkasset-c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36
35 | verbose: [0%] build: Building Docker image at /codebuild/output/src177682768/src/asset.c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36
36 | verbose: [0%] debug: docker build --tag cdkasset-c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36 --file ./docker/ci.Dockerfile .
37 | Sending build context to Docker daemon 1.198MB
38 |
39 | Step 1/9 : FROM node:14-alpine AS build
40 | toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
41 | error : [100%] fail: docker build --tag cdkasset-c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36 --file ./docker/ci.Dockerfile . exited with error code 1: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
42 | Failure: Error: docker build --tag cdkasset-c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36 --file ./docker/ci.Dockerfile . exited with error code 1: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
43 | at ChildProcess.<anonymous> (/usr/local/lib/node_modules/cdk-assets/lib/private/shell.js:46:24)
44 | at Object.onceWrapper (events.js:422:26)
45 | at ChildProcess.emit (events.js:315:20)
46 | at ChildProcess.EventEmitter.emit (domain.js:482:12)
47 | at maybeClose (internal/child_process.js:1021:16)
48 | at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
49 |
50 | [Container] 2020/11/30 17:43:09 Command did not exit successfully cdk-assets --path "assembly-PipelineStack-Pre/PipelineStackPreService574433AC.assets.json" --verbose publish "c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36:433775104113-us-east-1" exit status 1
51 | [Container] 2020/11/30 17:43:09 Phase complete: BUILD State: FAILED
52 | [Container] 2020/11/30 17:43:09 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: cdk-assets --path "assembly-PipelineStack-Pre/PipelineStackPreService574433AC.assets.json" --verbose publish "c1dd1c8474c338cb046b5097f5c51b8d8b00b1c1c54618aa198354cebe8d7a36:433775104113-us-east-1". Reason: exit status 1
53 | [Container] 2020/11/30 17:43:09 Entering phase POST_BUILD |
Same problem for us, this is a big issue. |
@JorisLimousinKaizen @arkon Not a fix, but have you tried the workaround in the thread @erudisch mentioned? |
Haven't tried it no, it has been working again since a few days, not sure if it has been fixed though. EDIT: Got rate-limited again. :( |
Just got the following answer from the AWS support in case it helps, will try it myself soon: From reading your correspondence I understand that you are currently facing an issue in your CDK pipelines, where builds are failing with the following error: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit This is a known issue that occurs now that DockerHub have introduced pull rate limiting. To resolve the error that you receive when throttling happens, you must configure CodeBuild to authenticate the layer pulls using your DockerHub account credentials. Full steps to resolve this issue can be found at the following knowledge center article [1]. However, to summarize;
If you have any follow-up questions or concerns, please feel free to contact me, I'm happy to help. Please note, my working hours are 9AM -5PM Monday - Friday, Irish Standard Time as I am based in Dublin, Ireland. [1] How do I resolve the “error pulling image configuration: toomanyrequests” error when I use Docker images in CodeBuild? - https://aws.amazon.com/premiumsupport/knowledge-center/codebuild-docker-pull-image-error |
Until we have a proper solution for this, you can try the ECR Mirror construct we have developed here: https://github.com/awslabs/aws-delivlib#ecr-mirror |
one workaround is to use base images from Amazon ECR Public Gallery (https://gallery.ecr.aws/) or create your own public ECR repository and push your images to that. In my case, I switched from docker hub base image -- FROM golang:1.14.13
++ FROM public.ecr.aws/bitnami/golang:1.14.13 |
Duplicate of #10999 |
I also had this issue and resolved it for me as follow in order to get nodejs constructs to work without going to docker each time, but to use aws's own library: #11296 (comment) So if you just need to build your lambda/lambdalayer constructs for nodej, then hopefully that reply will help. |
Currently, `cdk-assets` does a single `docker login` with credentials fetched from ECR's `getAuthorizationToken` API. This enables access to (typically) the assets in the environment's ECR repo (`*--container-assets-*`). A pain point for users today is throttling when using images from other sources, especially from DockerHub when using unauthenticated calls. This change introduces a new configuration file at a well-known location (and overridable via the CDK_DOCKER_CREDS_FILE environment variable), which allows specifying per-domain login credentials via either the default ECR auth tokens or via a secret in SecretsManager. If the credentials file is present, a Docker credential helper (docker-credential-cdk-assets) will be set up for each of the configured domains, and used for the `docker build` commands to enable fetching images from both DockerHub or configured ECR repos. Then the "normal" credentials will be assumed for the final publishing step. For backwards compatibility, if no credentials file is present, the existing `docker login` will be done prior to the build step as usual. This PR will be shortly followed by a corresponding PR for the cdk pipelines library to enable users to specify registries and credentials to be fed into this credentials file during various stages of the pipeline (e.g., build/synth, self-update, and asset publishing). related #10999 related #11774
Currently, `cdk-assets` does a single `docker login` with credentials fetched from ECR's `getAuthorizationToken` API. This enables access to (typically) the assets in the environment's ECR repo (`*--container-assets-*`). A pain point for users today is throttling when using images from other sources, especially from DockerHub when using unauthenticated calls. This change introduces a new configuration file at a well-known location (and overridable via the CDK_DOCKER_CREDS_FILE environment variable), which allows specifying per-domain login credentials via either the default ECR auth tokens or via a secret in SecretsManager. If the credentials file is present, a Docker credential helper (docker-credential-cdk-assets) will be set up for each of the configured domains, and used for the `docker build` commands to enable fetching images from both DockerHub or configured ECR repos. Then the "normal" credentials will be assumed for the final publishing step. For backwards compatibility, if no credentials file is present, the existing `docker login` will be done prior to the build step as usual. This PR will be shortly followed by a corresponding PR for the cdk pipelines library to enable users to specify registries and credentials to be fed into this credentials file during various stages of the pipeline (e.g., build/synth, self-update, and asset publishing). related #10999 related #11774
Currently, `cdk-assets` does a single `docker login` with credentials fetched from ECR's `getAuthorizationToken` API. This enables access to (typically) the assets in the environment's ECR repo (`*--container-assets-*`). A pain point for users today is throttling when using images from other sources, especially from DockerHub when using unauthenticated calls. This change introduces a new configuration file at a well-known location (and overridable via the CDK_DOCKER_CREDS_FILE environment variable), which allows specifying per-domain login credentials via either the default ECR auth tokens or via a secret in SecretsManager. If the credentials file is present, a Docker credential helper (docker-credential-cdk-assets) will be set up for each of the configured domains, and used for the `docker build` commands to enable fetching images from both DockerHub or configured ECR repos. Then the "normal" credentials will be assumed for the final publishing step. For backwards compatibility, if no credentials file is present, the existing `docker login` will be done prior to the build step as usual. This PR will be shortly followed by a corresponding PR for the cdk pipelines library to enable users to specify registries and credentials to be fed into this credentials file during various stages of the pipeline (e.g., build/synth, self-update, and asset publishing). related #10999 related #11774
Currently, `cdk-assets` does a single `docker login` with credentials fetched from ECR's `getAuthorizationToken` API. This enables access to (typically) the assets in the environment's ECR repo (`*--container-assets-*`). A pain point for users today is throttling when using images from other sources, especially from DockerHub when using unauthenticated calls. This change introduces a new configuration file at a well-known location (and overridable via the CDK_DOCKER_CREDS_FILE environment variable), which allows specifying per-domain login credentials via either the default ECR auth tokens or via a secret in SecretsManager. If the credentials file is present, a Docker credential helper (docker-credential-cdk-assets) will be set up for each of the configured domains, and used for the `docker build` commands to enable fetching images from both DockerHub or configured ECR repos. Then the "normal" credentials will be assumed for the final publishing step. For backwards compatibility, if no credentials file is present, the existing `docker login` will be done prior to the build step as usual. This PR will be shortly followed by a corresponding PR for the cdk pipelines library to enable users to specify registries and credentials to be fed into this credentials file during various stages of the pipeline (e.g., build/synth, self-update, and asset publishing). Two refactorings here: - Moved obtainEcrCredentials from docker.ts to docker-credentials-ts. - Moved DefaultAwsClient from bin/publish.ts to lib/aws.ts related #10999 related #11774 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
I would try this, but I actually got rate limited on an AWS image that's being hosted on Docker Hub that's vital to the CDK build process. Why are the AWS images for CDK hosted on Docker Hub and not ECR? It seems a little odd if people are going to have to worry about rate limits when building. |
Introduce a new set of properties to the pipeline constructs to enable users to specify Docker registries -- and associated credentials for each -- to be used during the pipeline build/synth, self-mutate, and asset publishing stages. These APIs enable the user to specify a Docker registry (e.g., DockerHub, ECR) and either secrets or use role credentials to authenticate to each registry, as well as specify which step(s) of the pipeline need these credentials. DRAFT -- Posting just the basic API for feedback while I finish up tests and final implementation. Any and all feedback welcome! fixes #10999 fixes #11774
Introduce a new set of properties to the pipeline constructs to enable users to specify Docker registries -- and associated credentials for each -- to be used during the pipeline build/synth, self-mutate, and asset publishing stages. These APIs enable the user to specify a Docker registry (e.g., DockerHub, ECR) and either secrets or use role credentials to authenticate to each registry, as well as specify which step(s) of the pipeline need these credentials. fixes #10999 fixes #11774
Introduce a new set of properties to the pipeline constructs to enable users to specify Docker registries -- and associated credentials for each -- to be used during the pipeline build/synth, self-mutate, and asset publishing stages. These APIs enable the user to specify a Docker registry (e.g., DockerHub, ECR) and either secrets or use role credentials to authenticate to each registry, as well as specify which step(s) of the pipeline need these credentials. fixes #10999 fixes #11774 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Introduce a new set of properties to the pipeline constructs to enable users to specify Docker registries -- and associated credentials for each -- to be used during the pipeline build/synth, self-mutate, and asset publishing stages. These APIs enable the user to specify a Docker registry (e.g., DockerHub, ECR) and either secrets or use role credentials to authenticate to each registry, as well as specify which step(s) of the pipeline need these credentials. fixes aws#10999 fixes aws#11774 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Currently, `cdk-assets` does a single `docker login` with credentials fetched from ECR's `getAuthorizationToken` API. This enables access to (typically) the assets in the environment's ECR repo (`*--container-assets-*`). A pain point for users today is throttling when using images from other sources, especially from DockerHub when using unauthenticated calls. This change introduces a new configuration file at a well-known location (and overridable via the CDK_DOCKER_CREDS_FILE environment variable), which allows specifying per-domain login credentials via either the default ECR auth tokens or via a secret in SecretsManager. If the credentials file is present, a Docker credential helper (docker-credential-cdk-assets) will be set up for each of the configured domains, and used for the `docker build` commands to enable fetching images from both DockerHub or configured ECR repos. Then the "normal" credentials will be assumed for the final publishing step. For backwards compatibility, if no credentials file is present, the existing `docker login` will be done prior to the build step as usual. This PR will be shortly followed by a corresponding PR for the cdk pipelines library to enable users to specify registries and credentials to be fed into this credentials file during various stages of the pipeline (e.g., build/synth, self-update, and asset publishing). Two refactorings here: - Moved obtainEcrCredentials from docker.ts to docker-credentials-ts. - Moved DefaultAwsClient from bin/publish.ts to lib/aws.ts related aws#10999 related aws#11774 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Introduce a new set of properties to the pipeline constructs to enable users to specify Docker registries -- and associated credentials for each -- to be used during the pipeline build/synth, self-mutate, and asset publishing stages. These APIs enable the user to specify a Docker registry (e.g., DockerHub, ECR) and either secrets or use role credentials to authenticate to each registry, as well as specify which step(s) of the pipeline need these credentials. fixes aws#10999 fixes aws#11774 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Currently can't deploy because of a rate limiting issue with Docker. You may have seen this in other issues, but the problem here is I have not hit this limit myself (only this single deploy) so for some reason, I believe Docker is flagging all of Codebuild as one "anonymous" source.
Anyway, we need a way to authenticate when using
DockerImageAsset
from@aws-cdk/aws-ecr-assets
or other guidance on how to circumvent thisError message:
Proposed Solution
We need a way to authenticate to associate our accounts with the pull instead of anon.
The text was updated successfully, but these errors were encountered: