Put cName in version control - #1654
Conversation
18cd765 to
884e265
Compare
JuliaBrigitte
changed the title
|
|
||
| adjustCloudformationParameters(this); | ||
|
|
||
| new GuCname(this, 'DnsRecordForRegistration', { |
There was a problem hiding this comment.
@jorgeazevedo and I did a bit more digging into this yesterday.
The DNS setup for registration is actually a bit more complicated than the setup for report and notification.
We have 2(!) intermediate CNAMEs for registration, rather than 1:
;; ANSWER SECTION:
notifications.guardianapis.com. 3825 IN CNAME registration.notifications.guardianapis.com.
registration.notifications.guardianapis.com. 225 IN CNAME registration.notifications-aws.guardianapis.com.
registration.notifications-aws.guardianapis.com. 60 IN CNAME mobile-no-loadbala-1oljehvjszyof-880073426.eu-west-1.elb.amazonaws.com.
mobile-no-loadbala-1oljehvjszyof-880073426.eu-west-1.elb.amazonaws.com. 60 IN A 63.33.239.23
mobile-no-loadbala-1oljehvjszyof-880073426.eu-west-1.elb.amazonaws.com. 60 IN A 52.214.243.203
mobile-no-loadbala-1oljehvjszyof-880073426.eu-west-1.elb.amazonaws.com. 60 IN A 54.171.19.238
The important part of the current setup in the context of this PR is:
notifications.guardianapis.com (NS1) -> registration.notifications.guardianapis.com (NS1) -> registration.notifications-aws.guardianapis.com (Route53)
This PR is trying to manage a DNS record that looks like this:
notifications.guardianapis.com (NS1) -> registration.notifications-aws.guardianapis.com (Route53)
I.e. we have removed registration.notifications.guardianapis.com from the chain entirely.
IIUC the proposed change will not deploy, because in order to 'take ownership' of an NS1 record1 all properties must match the current state of the record.
Footnotes
-
This is a
CREATEoperation in CloudFormation terms. ↩
There was a problem hiding this comment.
Ultimately, I think we want to end up with:
notifications.guardianapis.com (NS1) -> our GuCDK ALB's domain name
In order to get there we have a few options1, but I would probably suggest:
1st PR (this one!): add 2 GuCname constructs:
notifications.guardianapis.com -> registration.notifications.guardianapis.comregistration.notifications.guardianapis.com -> registration.notifications-aws.guardianapis.com
2nd PR: drop the TTL for the notifications.guardianapis.com -> registration.notifications.guardianapis.com record to 60 seconds.
3rd PR: update notifications.guardianapis.com to point at our GuCDK ALB's domain name (this is the important PR from a user-perspective - it sends all traffic to the new infrastructure).
4th PR: Delete the unused registration.notifications.guardianapis.com -> registration.notifications-aws.guardianapis.com GuCname and remove the legacy template (which includes the unused Route53 record for registration.notifications-aws.guardianapis.com -> legacy ELB's domain name)
Footnotes
-
For example, it's not strictly necessary to 'take ownership' of the
registration.notifications.guardianapis.com -> registration.notifications-aws.guardianapis.comrecord, but doing so allows us to delete the record using a PR / Riff-Raff deployment (rather than by doing it manually in the NS1 console). This reduces risk and improves the audit trail. ↩
There was a problem hiding this comment.
Good spot, thanks. Strangely, it looks like we might have misread the TTL for PROD too as Service Catalogue suggests both records have a 7200 TTL.
There was a problem hiding this comment.
1st PR (this one!): add 2
GuCnameconstructs:
notifications.guardianapis.com -> registration.notifications.guardianapis.comregistration.notifications.guardianapis.com -> registration.notifications-aws.guardianapis.com
I'm not sure we need to take ownership of the middle NS1 record (registration.notifications.guardianapis.com)1 as it cannot be in use by any client due to TLS certificate being used not having a relevant subject alternative name. That is, if a client was to use registration.notifications.guardianapis.com, it'll be getting certificate issues.
Footnotes
-
We should remove it once the migration is complete, but can do that in NS1 directly. ↩
There was a problem hiding this comment.
Summarising an IRL discussion:
We've opted to follow @jacobwinch's suggestion as it provides an audit trail. Therefore the next PR will be to adopt the DNS record:
registration.notifications.guardianapis.com (NS1) -> registration.notifications-aws.guardianapis.com (Route53)
Once notifications.guardianapis.com points to the new load balancer, the registration.notifications.guardianapis.com CNAME can be deleted.
There was a problem hiding this comment.
Therefore the next PR will be to adopt the DNS record:
registration.notifications.guardianapis.com(NS1) ->registration.notifications-aws.guardianapis.com(Route53)
…ing elimination one go between Co-authored-by: Akash <akash1810@users.noreply.github.com>
Co-authored-by: Akash <akash1810@users.noreply.github.com>
c0088a6 to
518b6a1
Compare
3 participants
What does this change?
This PR prepares for migrating traffic to the new GuCDK infrastructure for the registrations service by bringing a CNAME (DNS record) into version control. Up to this point the CNAME has been managed manually via the NS1 console.
See Start managing report's NS1 CNAME via GuCDK for further details.
How to test
Deploy to CODE
Co-authored by: @akash1810