copilot-cli
copilot-cli copied to clipboard
aws
Add domain to an existing app
I have created an app with copilot init. I'd like to now add a domain for it instead of using the default http://....eu-north-1.elb.amazonaws.com/ domain.
Hi @wolverian !
Apologies, we don't have support yet to add a domain to an already created application (related #1188) 🙇 Unfortunately, today the only way is by re-creating the application.
The feature request makes a lot of sense, and we definitely would like to support it.
Any news on this? I'm currently in a state where I do can recreate the app but I'm thinking for others that might rely on state of the app in production so it can't be recreated.
Sorry @freddejones. We are still planning on this and will give our update here.
Related: https://github.com/aws/copilot-cli/issues/3293
#3293 is a slightly different proposal, but should help folks achieve similar - if not the same - goals. If #3293 was supported, then the users who did not run copilot app init --domain but want a domain afterwards, can specify the domain per-environment (maybe in their environment manifest).
Finally, just in case we are not all aware - you can already do something add a domain after the facts today by importing your own certificate into the environment: https://aws.github.io/copilot-cli/docs/developing/domain/#use-domain-in-your-existing-validated-certificates. Although you will need to manage your certificate, hence the validation records, and potentially the A records yourselves, hopefully this will be a one-time effort for you.
@iamhopaul123 @efekarakus How are we supposed to do this if we have storage attached such as S3 or RDS? Wouldn't deleting the app delete all the environments and storage?
@jetaggart Does importing certificates per environment work for you?
Finally, just in case we are not all aware - you can already do something add a domain after the facts today by importing your own certificate into the environment: https://aws.github.io/copilot-cli/docs/developing/domain/#use-domain-in-your-existing-validated-certificates. Although you will need to manage your certificate, hence the validation records, and potentially the A records yourselves, hopefully this will be a one-time effort for you.
How are we supposed to do this if we have storage attached such as S3 or RDS? Wouldn't deleting the app delete all the environments and storage?
You could add DeletionPolicy: Retain to these resources before deleting the app. This will result in the resources (S3, RDS, etc.) being retained, while the stack is deleted. After you recreate the app, you do need to associate the retained resource back with the new stacks: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-existing-stack.html.
This is quite some work, so I'd recommend importing certificates over re-creating apps in your case.
@Lou1415926 We're doing research for adoption so not sure. It's a bit scary to import our domain to route 53 solely for copilot then potentially get locked into copilot and "stuck" with one domain due to risk. If copilot initially set up our zones/route53, can we eject to managing route 53 directly and just doing the certificate imports ourselves? One thing we don't understand with the import is how we manage the A record if the IP of the LBs can change at any time?
The second option is indeed not ideal due to the risk/amount of work. It'd definitely be nerve wracking to be tearing down and rebuilding CF stacks in production all for a domain switch.
Is there any idea of when a simpler domain switch option might be available? We're loving everything else but this is definitely a red flag for us for adoption.
I echo the sentiment in this ticket: #5611
One thing we don't understand with the import is how we manage the A record if the IP of the LBs can change at any time?
The A record points to the DNS name of the LB, which does not change throughout its lifetime. So you shouldn't have to change the record unless you've recreated the LB(s).
If copilot initially set up our zones/route53, can we eject to managing route 53 directly and just doing the certificate imports ourselves?
I suppose this refers to after you run copilot app init --domain mydomain.com, whether you can "eject" mydomain.com from Copilot right?
The short answer is there isn't really an "eject" option (as in deleting mydomain.com completely from Copilot's sight), but you might still find what you want ⬇️
After copilot app init --domain mydomain.com, Copilot looks for (instead of create) the route53 hosted zone for "mydomain.com", and then creates the hosted zone for "
After Copilot creates the "
- Create a certificate;
- Create the validation records for the certificate - potentially in the "
.mydomain.com" which is created by Copilot; - Import the certificate in the environment manifest.
In this case, Copilot will assume you are going to manage the aliases used in this environment on your own. If all of your environments import certificates, then effectively Copilot shouldn't try to upsert any records into the hosted zone for "copilot app delete, Copilot however will still try to delete those two hosted zones.
It's a bit scary to import our domain to route 53 solely for copilot
You could create ACM certificates for domains managed outside of route53 I believe! Then you can import the certificates into Copilot environment. You can then create the A records yourself for any aliases that you use. In short, you should be able to keep your domain outside of AWS while using it for Copilot applications by importing certificates.
The A record points to the DNS name of the LB, which does not change throughout its lifetime. So you shouldn't have to change the record unless you've recreated the LB(s).
How does this work for a DNS outside of route 53 which requires IP addresses for A records? I see that route 53 supports this sort of A record but a normal DNS does not afaik, meaning we'd have to specify a specific IP which would cause an outage if it got rotated.
@jetaggart ah apologies, I was thinking about ALIAS records which are unique to AWS services. Does CNAME records work for you?
@Lou1415926 Most likely if the ALB/NLB supports cnames, which I assume it does. Thanks for the recommendations, it may be good to test some of these and put them in the official docs, definitely a rough edge coming in for the first time!