Copilot-cli: [Feature] More control over DNS Names Generated

Created on 24 Jul 2020  ·  14Comments  ·  Source: aws/copilot-cli

Today, there are a few limitations with our DNS tooling.

The first is that the name of the DNS name generated is always fixed as {service}.{environment}.{application}.customer-domain. I can imagine that folks will want to have control over how their production URLs are constructed, so we should figure out a way to let folks do that.

The second, and I'm not sure if this is as big of a deal, is that every environment gets a DNS name. It may be that some customers only want to enable DNS for certain environments.

The third is, HTTP should redirect to HTTPS.

The fourth is discoverability. Right now customers probably don't know that they can use DNS with their apps because it's a hidden flag. We should detect if a customer has any hosted zones and perhaps prompt them if they'd like to use one of the DNS names.

aresvc typenhancement

Most helpful comment

Implementation Plan

  • [x] Add http.alias field to the manifest. If

    • ${domain-name} or *.${domain-name}: specify domain alias like this in the field and we'll handle everything.

    • if it is using domain other than the one specified when creating the app see here, then users should import the validated cert on env init.

    • http.path will be supported for domain, so that users can use the same domain alias for multiple services with different paths.

  • [x] Update the app CFN templates

    • [x] app.yaml to add permission to do route53:ChangeResourceRecordSets in the root domain hosted zone

    • [x] Versioning templates

  • [x] Update cert validator lambda to include more alternative subject names by default
  • [x] Add custom domain lambda that writes alias records to the hosted zone
  • [x] Update env controller to add alias info to the env stack parameter
  • [x] Update the CFN template

    • [x] env template for custom resources update and adding new alias parameter

    • [x] svc template for custom resources update and listener rule changes

  • [x] app upgrade
  • [ ] Update env init allowing users to import certificates for the other domain.
  • [x] Redirect HTTP to HTTPS

All 14 comments

My 2 cents -

The first is that the name of the DNS name generated is always fixed as {service}.{environment}.{application}.customer-domain. I can imagine that folks will want to have control over how their production URLs are constructed, so we should figure out a way to let folks do that.

Yes, it'd be great to be able to customize it. However, couldn't this be achieved today with an additional CNAME pointing to the generated DNS name today? Then there'd be SSL to consider as well. Either building all of this into the tool, or at the very least providing a guide in the wiki of how to set up the CF resources needed, are two possible ways forward.

The second, and I'm not sure if this is as big of a deal, is that every environment gets a DNS name. It may be that some customers only want to enable DNS for certain environments.

I personally don't mind this.

The third is, HTTP should redirect to HTTPS.

+1, though most developers should be able to build this logic into their apps (though it'd be even better if copilot handled it for me).

Thanks so much for your feedback @jonchase !

Yea, I think your point about folks being able to manage CNAMEs themselves. I think the minimum that we need to do is at least update the TLS Certs that we generate to work for *.{domain-name}.

The CNAME + TLS solution would cover almost every case that I run into. I really could care less about the underlying actual DNS. Honestly, this was going to be my route anyway because most of the time I end up putting CloudFront in front of the ALB.

An additional customer ask is being able to use domain names that are not part of the application account

I need a few things personally:

  • Ability to use a domain name that is bought on another account. Technically it is possible to verify an external domain name in Amazon Certificate Manager. Once I have verified it in ACM then Copilot should be able to utilize it from that point forward
  • Ability to host a website on the bare domain as well as on a subdomain, for example mydomain.com and dev.mydomain.com
  • Ability to specify the domain per environment as well as per application. Ideally I would have one application and service, but it has different domains in different environments. Right now an application can only have one domain which is then used for all environments with an automatic subdomain.

Here is manual on how to add custom domain for deployed application manually:

a. Issue SSL certificate via ACM for your your.route53.managed.domain
b. Bind this certificate to ALB HTTPS listener in EC2→Load Balancers (you will need to create HTTPS listener if you didn't use --domain option to copilot app init)
c. In that same listener add one more rule “send all requests from your.route53.managed.domain to the same target group”
d. Create A-record for this domain in Route53 and point into app load balancer (with empty subdomain if it points to domain itself). ALB can be chosen from dropdown list.

+1 on adding some support for custom domains into copilot itself.

Implementation Plan

  • [x] Add http.alias field to the manifest. If

    • ${domain-name} or *.${domain-name}: specify domain alias like this in the field and we'll handle everything.

    • if it is using domain other than the one specified when creating the app see here, then users should import the validated cert on env init.

    • http.path will be supported for domain, so that users can use the same domain alias for multiple services with different paths.

  • [x] Update the app CFN templates

    • [x] app.yaml to add permission to do route53:ChangeResourceRecordSets in the root domain hosted zone

    • [x] Versioning templates

  • [x] Update cert validator lambda to include more alternative subject names by default
  • [x] Add custom domain lambda that writes alias records to the hosted zone
  • [x] Update env controller to add alias info to the env stack parameter
  • [x] Update the CFN template

    • [x] env template for custom resources update and adding new alias parameter

    • [x] svc template for custom resources update and listener rule changes

  • [x] app upgrade
  • [ ] Update env init allowing users to import certificates for the other domain.
  • [x] Redirect HTTP to HTTPS

I noticed certificates created by copilot do not have tags. Was this intentional? Can we add tags to certificates that are created?

Hello @gautam-nutalapati. That's not intentional. We should do a fix on that. Thank you for surfacing the issue!

Hello @gautam-nutalapati the cert tag issue has been fixed in https://github.com/aws/copilot-cli/pull/2265/files#diff-0c85101ebece17b53b497213cb7bfcf41132194396502875690b23e0fbb3a971R125-R134. It will be included in our next release!

Is the support of custom domain names through aliases scheduled for v1.8.0? This looks very exciting!

Is the support of custom domain names through aliases scheduled for v1.8.0? This looks very exciting!

Yess! I believe so. Please stay tuned!

Hi folks! We're super excited to say that this is now resolved in v1.8.0 🥳 https://github.com/aws/copilot-cli/releases/tag/v1.8.0!

Once you create an app with a domain: copilot app init --domain example.com, then in the manifest files for Load Balanced Web Services you can now add an alias field under http to use your domain or subdomains:

environments:
  prod:
     http:
       api: api.example.com

This is amazing, thank you!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jaybauson picture jaybauson  ·  3Comments

iamhopaul123 picture iamhopaul123  ·  3Comments

aidansteele picture aidansteele  ·  3Comments

kohidave picture kohidave  ·  4Comments

camilosantana picture camilosantana  ·  3Comments