copilot-cli: Create TaskDefinition: Container.image repository should not be null or empty
I’m creating two different environments in the same AWS account and wanting to create a service in this new environment that is creating an image from docker files that are being used in another env. However, when I deploy I’m getting this error Create TaskDefinition: Container.image repository should not be null or empty
.
I was a bit confounded as to why it was giving me this error. However, when I looked into the parameters in the new environment compared to the preexisting environment I noticed this difference:
Preexisting: ContainerImage: 601068425913.dkr.ecr.us-east-1.amazonaws.com/connector/worker@sha256:e9d51e6250e3454ab51d0468d47b5bfae55985552d1e46d2d149ae33f5e5259c
New: ContainerImage: @sha256:e206fc32e605ee6b46502a7ae3be0df4ed10b76eba96c98d8c64ae762c2c71b0
So this error message makes sense to me now, but it begs the question. Why doesn’t the new environment contain the correct ContainerImage
value?
I’ve got a manifest for two different services that are being used in both the preexisting and new env.
Another thing I noticed is that in the second service to the new env it doesn’t have this issue and it the ContainerImage
value contains the full value as per the preexisting env for the other service above.
I’m having another issue with deploying this service related to the service being able to access the secrets in SSM. I’m not sure if these issues are related?
I’m not sure what you’ll need to help debug this issue.
This is the command I used to setup the new environment in the same account as the preexisting environment: AWS_PROFILE=stg AWS_REGION=us-east-1 copilot env init
I set it up without any issue.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 42 (21 by maintainers)
Thank you for providing these info - super helpful!
Just to make sure, the
prod
account andstg
account are two different AWS accounts right? This is what I understood from reading the conversation above, please correct me if I’m wrong!Giving that my understanding above ⬆️ is correct -
The expected set up would be that only one of the accounts has
connector
app. For example, suppose you want your application to be set up in thestg
AWS account, then the expected output would be:It seems to me that you have unintentionally set up two separate applications - one
connector
instg
account, and anotherconnector
inprod
account. They may be named the same, but they are in fact two separate set of infrastructure 😦 I.E.This is likely the root cause of some of the issues you’ve been seeing so far.
The expected set up that I’ve described above would have been achieved by:
We can figure out a path forward together - but before that, I am happy to explain more on the credential model or the analysis above if you have questions!