J'essaie de pousser ma première image Docker vers ECR. J'ai suivi les étapes fournies par AWS et les choses semblent se dérouler en douceur jusqu'à la poussée finale, ce qui est immédiatement à la sortie. Plus précisément, je passe mes informations d'identification AWS ECR à Docker et je fais un message "Connexion succédé". Je tague ensuite l'image qui fonctionne également. En poussant vers le repo ECR, je ne reçois aucun message d'erreur, juste ce qui suit:
The push refers to repository [xxxxxxxxxxx.dkr.ecr.ca-central-1.amazonaws.com/reponame] 714c1b96dd83: Retrying in 1 second d2cdc77dd068: Retrying in 1 second 30aad807caf5: Retrying in 1 second 0559774c4ea2: Retrying in 1 second 285b8616682f: Retrying in 1 second 4aeea0ec2b15: Waiting 1b1312f842d8: Waiting c310009e0ef3: Waiting a48777e566d3: Waiting 2a0c9f28029a: Waiting EOF
Il essaie un tas de fois puis sort sans message. Une idée de ce qui ne va pas?
14 Réponses :
J'ai compris mon problème. Je n'utilisais pas les informations d'identification correctes. J'avais un compte AWS personnel comme mes informations par défaut et j'avais besoin d'ajouter mon profil de travail à mes informations d'identification.
modifier
Si vous avez plusieurs profils AWS, vous pouvez mentionner le nom de profil au Docker Connex
Avait la même erreur, mais mon problème était que l'utilisateur n'avait pas les autorisations correctes.
Dans mon cas, le compte AWS a une autorisation ECR définie à * (tout). Mais je fais toujours face au problème
Enfin, j'ai compris le problème. Il y a 2 choses. L'un est la connexion AWS et l'autre est la connexion ECR. Pour Pull, nous devons faire les deux pour la source et pour PUSH, nous devons faire les deux pour le compte cible. Cela a résolu le problème. La partie la plus décevante est l'endroit où AWS CLI ne dit pas qu'il s'agit d'un problème d'authentification.
J'utilisais la connexion AWS SSO et mon compte par défaut ne correspondait pas à celui où mon ECR était situé.
Ouais, ma confusion est venue, donc dans le port, je crée un référentiel comme: Harbor.mydomain.com/org, puis poussez mon image qui sera sous ... / org / image, et cela fonctionne. Dans AWS, vous ne configurez pas ... / org séparément, vous devez faire ... / org / nom d'image comme nom du référentiel. Cloudtrain, suggéré par Alena en dessous de cette réponse l'a résolu magnifiquement.
Merci, c'était un excellent indice pour résoudre mon problème de réessayer. Le rôle que j'utilisais n'a pas eu suffisamment d'autorisations.
Je dois ajouter pour quiconque rencontre ce problème. Allez à IAM et assurez-vous d'avoir des autorisations. Je ne veux pas dire combien de temps j'ai perdu avant de comprendre cela.
Votre réponse pourrait être améliorée avec des informations de support supplémentaires. Veuillez modifier pour ajouter plus de détails, tels que des citations ou de la documentation, afin que d'autres puissent confirmer que votre réponse est correcte. Vous pouvez trouver plus d'informations sur la façon d'écrire de bonnes réponses dans le centre d'aide .
Pouvez-vous s'il vous plaît élaborer? J'ai le même problème. Dans mon cas, le compte AWS a une autorisation ECR définie à * (tout). Mais je suis toujours confronté au problème.
Enfin, j'ai compris le problème. Il y a 2 choses. L'un est la connexion AWS et l'autre est la connexion ECR. Pour Pull, nous devons faire les deux pour la source et pour PUSH, nous devons faire les deux pour le compte cible. Cela a résolu le problème. La partie la plus décevante est l'endroit où AWS CLI ne dit pas que c'est un problème d'authentification
@ven pouvez-vous s'il vous plaît en élaborer plus concernant la connexion AWS et la connexion ECR?
Pour moi, j'ai dû supprimer la pile et redéployer la pile. Ensuite, j'ai pu pousser l'image Docker vers ECR.
Assurez-vous également que vous avez configuré une stratégie correcte pour votre utilisateur - par exemple, AmazonEC2ContainerRegistryfullAccess.
Dans mon cas, il était lié au MFA (multi-facteurs-authentification). J'ai dû créer un jeton de session. La connexion Docker semblait réussir, mais la poussée ne fonctionne pas.
Le script suivant fait tout pour vous et crée un profil AWS "MFA" utilisé pour se connecter: get_mfa_credentials.py
Après l'exécution, vous pouvez vous connecter avec:
aws ecr get-login-password --region <YOUR_REGION> --profile mfa | docker login --username AWS --password-stdin <Your_REPO>
vous obtiendrez le même comportement si vous oubliez de créer un repo ECR avant de pousser.
Utilisez Cloudtrail pour obtenir une indication ce qui ne va pas.
Je me sens immédiatement stupide, mais au moins je peux maintenant pousser l'image XD
J'ai également pu me connecter au registre, mais la poussée de l'image serait juste un temps mort.
La solution pour moi était d'ajouter Amazonec2ContainerRegistryfullaccess
à mon utilisateur IAM.
Après avoir ajouté cette autorisation à mon compte d'utilisateur IAM, je pouvais très bien push docker au registre ECS.
Si quelqu'un est toujours coincé avec le problème. Je recommande fortement de regarder cette courte vidéo https://www.youtube.com/watch? v = 89ZEXAZEF80 & AB_CHANNEL = IdenticalCloud
Voici les étapes que j'ai prises pour résoudre le problème (si vous préférez ne pas regarder la vidéo):
Dans mon cas, le référentiel que je voulais pousser n'existait pas (par exemple, j'ai essayé de pousser vers my-app / backend: dernier
mais seulement le my-app / Le référentiel CMS
existe). Assurez-vous donc que votre référentiel existe dans la console ECR AWS dans la bonne région. L'erreur retournée de AWS CLI (EOF) n'a pas aidé du tout.
Vérifiez vos autorisations AWS. En plus de AmazonEC2ContainerRegistryfullAccess
, les actions ci-dessous doivent être accordées pour la ressource correcte. En particulier Check "ARN: AWS: ECR: $ {Region}: $ {account_id}: Repository / {$ registry_name}"
pièce.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:BatchCheckLayerAvailability", "ecr:CompleteLayerUpload", "ecr:DescribeImages", "ecr:DescribeRepositories", "ecr:GetDownloadUrlForLayer", "ecr:InitiateLayerUpload", "ecr:ListImages", "ecr:PutImage", "ecr:UploadLayerPart" ], "Resource": "arn:aws:ecr:${REGION}:${ACCOUNT_ID}:repository/{$REGISTRY_NAME}" }, { "Effect": "Allow", "Action": "ecr:GetAuthorizationToken", "Resource": "*" } ] }
Giving AmazOnec2ContainerRegistryFullAccess
annulera la nécessité des autorisations supplémentaires répertoriées ici, car son effet est à permettre
l'action "ECR: *"
sur la ressource "*"
.
Veuillez vérifier les journaux des événements de trail cloud, c'est là que tous les problèmes d'API sont clairement mis en évidence.
Dans mon cas, c'était parce que j'avais un -
dans mon nom d'image et donc il lancait L'erreur suivante dans les journaux de traces de cloud
docker tag nginx:latest 516583196897.dkr.ecr.ap-south-1.amazonaws.com/myimage:latest docker push 516583196897.dkr.ecr.ap-south-1.amazonaws.com/myimage:latest
Veuillez noter le -
dans le nom de l'image.
Correction du nom de l'image Pour supprimer le -
résolu le problème pour moi.
"The repository with name 'myimage-nginx' does not exist in the registry with id '516583196897'
Dans mon cas, je créais le dépôt dans us-east-2
et tentais de pousser à us-east-1
, donc Docker n'a pas pu le trouver.
Assurez-vous que le nom de votre registre est le même nom que vos images . Image: Dernier 756839881602.dkr.ecr.us-East-1.amazonaws.com/image:llast
Dans ce cas, mon nom de registre est Image
Et mon nom d'image est Image
également. Cela a fonctionné pour moi.
Pour ceux qui ont essayé la solution ci-dessus, et cela n'a pas fonctionné, assurez-vous que le nom de l'image que vous poussez est le même que le nom du référentiel.