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)

Most upvoted comments

Thank you for providing these info - super helpful!

Just to make sure, the prod account and stg 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 the stg AWS account, then the expected output would be:

$ AWS_PROFILE=stg AWS_REGION=us-east-1 copilot app ls
connector

$ AWS_PROFILE=stg AWS_REGION=us-east-1 copilot app show
About

  Name     connector
  Version  v1.0.0 (latest available: v1.0.2)
  URI      airdemo.link

Environments

  Name     AccountID     Region
  ----     ---------     ------
  stg      601068425913  us-east-1
  sandbox  601068425913  us-east-1
  prod     613445503623  us-east-1    # <--- This environment is created in the prod account.

Workloads

  Name    Type                       Environments
  ----    ----                       ------------
  web     Load Balanced Web Service  stg, prod # <--- In addition to `stg`, `web` is also deployed in `prod` environment in the other account.
  worker  Backend Service            prod      # <--- `worker` is also deployed in `prod` environment in the other account.

Pipelines

  Name
  ----
  pipeline-connector-connector

$ AWS_PROFILE=prod AWS_REGION=us-east-1 copilot app ls
// Nothing.

$ AWS_PROFILE=prod AWS_REGION=us-east-1 copilot app show
// No app.

It seems to me that you have unintentionally set up two separate applications - one connector in stg account, and another connector in prod account. They may be named the same, but they are in fact two separate set of infrastructure 😦 I.E.

If you’ve run copilot app init with different profiles that refer to different accounts, perhaps you’ve unintentionally created an application in your account A, and an application in your account B.

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:

$ export AWS_PROFILE=stg # `stg` is the default profile in this session.
$ export AWS_REGION=us-east-1

$ copilot app init # Create the app in `stg` account.

$ copilot env init
Name: prod

Which credentials would you like to use to create prod? 
> Enter temporary credentials 
> [profile default] 
> [profile stg] 
> [profile prod] # Selected this; create the env `prod` in `prod` account.
> [profile sandbox]

$ copilot svc init --name web

$ copilot svc deploy --name web --env stg

$ copilot svc deploy --name web --env prod # `web` will be deployed in the `prod` account. 

$ copilot svc init --name worker

$ copilot svc deploy --name worker --env prod # `worker` will be deployed in the `prod` account.

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!

Lou1415926 on Apr 26, 2022