Docker contexts in a multi-project repo

[miketheman]

Hello! Trying out copilot, and it looks like it expects the file structure to be very specific, so I thought I'd capture some experiences here to share.

Examples that cropped up:

1. local git repo with no commits yet (after a git init) provides this question:

Note: Couldn't find a git commit sha to use as an image tag. Are you in a git repository?

Surmountable with user input - nice work! But this has already come after I've initialized an env - should that check come earlier in a development lifecycle, so I've not already deployed some AWS infra by the time I hit this?

---

2. Dockerfile context for build isn't the same as the root of the application
   I'm trying to deploy 2 separate copilot projects from the same git repo - with shared context, leading to this structure:

root
├── docker-compose.yml
├── app.py
├── app1
│  ├── app1.Dockerfile
│  └── copilot
│      └── app
│          └── manifest.yml
└── app2
    ├── app2.Dockerfile
    └── copilot
        └── app
            └── manifest.yml

In this example, I want to share app.py (and other files, etc) to both contexts.

Using docker-compose.yml, from the root, I can set the build context like so:

...
services:
  app1:
    build:
      context: .
      dockerfile: app1/app1.Dockerfile
...

And in app1/app1.Dockerfile I can COPY from the root dir with no modification, and any extra files in app1/ would have to be prefixed in the app1.Dockerfile, since the context starts from the root.

In copilot's manifest.yml, the build context is a similar "simple" context, that will also accept configuration, but since the desired context file is outside of the root of where copilot lives, it can't be injected as far as I know.

Does this make sense? Should I be init`ing copilot from the root as well, and naming the services app1/app2?

---

3. After initing the environment, I cannot remove the environment I just created with copilot env delete - I get:

Are you sure you want to delete environment load from application app1? Yes
✘ Failed to delete environment load from application app1.
✘ delete environment load stack: delete stack app1-load: AccessDenied: User: arn:aws:sts::[REDACTED]:assumed-role/app1-load-EnvManagerRole/1617489726744667000 is not authorized to perform: iam:PassRole on resource: arn:aws:iam::[REDACTED]:role/app1-load-CFNExecutionRole
status code: 403, request id: 0a03c9fd-6fb8-436b-92ec-60144cf2a58e

That seems wrong? I ought to be able to tear down infra I just created? Looking at the generated IAM role, I can see a statement for GetAndPassCopilotRoles (comes from here) - but something else isn't matching? Am I getting caught in some other IAM confusion? I'll keep the env around for more debugging, but I guess I can always use the CFN Console UI to remove the entire stack?

If these are better served as individual GH Issues, happy to move them over! Thanks!!

[miketheman]

Linking this issue as it might be relevant: #1345

[iamhopaul123]

Hello @miketheman. Thank you for reaching out!

1. For Copilot it doesn't need to be a git repo to deploy your services. It's just we tag the image using the commit SHA. For now alternatively you could specify the tag. Also we are currently working on this issue Support deploying without creating a git commit #2139. Please stay tuned for that!

2. Should I be init`ing copilot from the root as well, and naming the services app1/app2?

Yes. You should init from the root and create those two services individually.

3. Not sure what was going on. Are you using the latest Copilot version that we released?

[miketheman]

Hey @iamhopaul123 ! Thanks for the responses!

1. Added my 👍 to subscribe, thanks!
2. I'll try that approach instead. There's some overlap/similarity in each service, so I'm curious to see what that will look like in the manifest.yml
3. I was using copilot 1.4.0. I guess I also didn't see any "you need X IAM permissions to get started with Copilot" anywhere, so the first part "just worked" - is it possible that I need my IAM user to have permissions to delete that aren't expressed in the EnvManagerRole setup?

[iamhopaul123]

Yeah it is possible. #1345 actually lists all the permissions we need (we should definitely do it better in our doc/website). Would you like to give it a shot to include those used permissions? Or if it doesn't work would you mind creating a separate issue so that we can better track for this issue? Thank you!

[miketheman]

Thanks! I'll open another issue with the IAM findings.

[miketheman]

Here's the issue: #2160