Copilot-cli: copilot init doesn't ask to use existing infrastructure

[h5aaimtron]

I'm part of the group evaluating copilot for UCLA and I've had some issues in getting up and running. I'm going to describe what I did, what happened, and what I expected in hopes of getting clarification.

First I ran

copilot app init

I provided an app name, cf stack was successfully created, all good so far. Next I ran:

copilot init

I was prompted for the underlying services (web app) as a load balanced web service, however; when it came time to provision infrastructure, it did not ask me if I wanted to use the existing vpc and subnets. Instead, it elected to create it's own. So I rolledback/deleted all the stacks and ssm metadata to start clean.

I ran:

copilot app init

No problems. I ran:

copilot init

I filled out the questions, but this time I elected not to deploy. Upon not deploying, I got a pleasant message about how I can deploy later with 2 optional commands. I tried the first and it prompted me on using existing infrastructure which is what I expected the first time.

In an attempt to maybe break this out further I tried a different approach from a clean slate:

copilot app init (no problems)
copilot env init (Could not execute cloudformation as the executionrole with the desired name was already created)

So that is where I'm at currently. I don't know if my expectations not matching the goals or if I found a problematic flow. Any help/guidance would be greatly appreciated.

[iamhopaul123]

Hello @h5aaimtron, copilot init is the shorthand version for copilot app init, and potentially copilot env init, copilot svc init, and copilot svc deploy, which is usually the entry point for using copilot to deploy an example app which doesn't require any advanced usage. In your case I think the last attempt which is copilot app init and copilot env init should be expected. However, you might need to do an IAM role cleaning before: could you try to delete the executionrole and environment manager role created by copilot and run those two commands again?

[bvtujo]

In addition to what @iamhopaul123 said, typically this happens when infra is deleted without using copilot app delete. When you delete an environment by destroying CF stacks and wiping SSM parameters, you run the risk of not deleting the IAM roles (appname-envname-EnvManagerRole and appname-envname-CFNExecutionRole) which are set up for the environment. The reason they're not covered by deleting the env stack is subtle: we need to retain them after environment deletion in case they were used to create the CF stacks for any transient copilot tasks via task run; otherwise the task stacks will be un-deletable.

To prevent this issue from happening in the future, you can initialize apps with custom infra by the following sequence of commands:

copilot app init --domain mydomain.net appname
copilot env init -n test

copilot svc init
copilot svc deploy -e test

copilot init is generally intended to be a simple entrypoint for most workloads, and makes some choices about the environment that those services will be deployed to. Under the hood, it runs the commands I listed above. You can mimic everything it does with those four commands, with more customization.

@SharePointOscar

[h5aaimtron]

@iamhopaul123 I was able to run the last two commands after cleaning up the iam roles produced in previous attempts. That did successfully create the app meta data, roles, and provision the cluster. Thanks for the help.

@bvtujo does the --domain switch trigger additional calls to a dns service/route 53?

[bvtujo]

@h5aaimtron short answer is yes; if you initialize your app with a domain, copilot sets up a hosted zone for the application in the default account (.myapp.domain.com), then a hosted for each environment (.prod.myapp.domain.com). We automagically provision an SSL cert from ACM on your behalf too.

You can check out some of the permissions that have worked for other folks at #1345.

Once you do this, your load balanced web services will be available on https endpoints like:

https://frontend.test.myapp.domain.com
https://api.prod.myapp.domain.com

You can override this URL by creating a custom DNS record in the hosted zone that copilot creates, pointing the service-specific endpoint to simply myapp.domain.com; our customers have had a discussion about this behavior over on #1188

The domain has to be owned by the account you're using to run app init, however, but if you're able to clear that hurdle, Copilot automatically does cross-account and cross-region domain delegation to link together all of your environments into these kinds of endpoints.

That was way more than you asked for. Hope it helps!

[h5aaimtron]

@bvtujo would this also work with a managed zone in R53 where the org controls the root? They're looking to setup an app specific zone so that app teams can provision something like app.env.a.b.c.it.ucla.edu within their instance of route 53?

[bvtujo]

I think so! You can provide a domain like a.b.c.it.ucla.edu and as long as the hosted zone for that subdomain exists in the default account, you should see new endpoints pop up at svc.env.app.a.b.c.it.ucla.edu.