-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Website: update DNS infrastructure #156
Comments
I don't know what the route53 tools are like for sharing, but cloudflare supports organisational accounts (and does everything we would need + some extra goodies) for free, which our one day ops team might find useful. I'm sure the same can be achieved with route53, but I'm not sure how difficult it might be? |
Sounds good to me @nastevens, thanks for opening up this issue. I agree with @ryankurte, it would be nice not to have a single point of failure/put all the burden on you whenever we need to make changes. |
Another option would be to transfer ownership of the domain to the Rust organization itself, and manage our DNS through whatever process |
Sounds like we're on a similar page - I had been thinking AWS only because that's what I'm familiar with and knew how to set up an organizational account. I didn't know that Cloudflare had an offering that would fit the bill - I'll definitely take a look at what that offers before starting the AWS stuff. And yeah, I'd like to have other people able to make changes without having to get involved. Best case scenario I'd like to get to a point where at least one other person would have complete-enough control that the only thing they'd have to do is start paying the bills to keep the sites up. There again I'll take a look at how Cloudflare would handle that - I already know that AWS is able to give permissions to organizational accounts that would allow an admin in that account to basically "break free" of the parent, at which point it can be billed separately. |
The other consideration for later on is that we could automate/terraform our records to have a gh repo as the authoritative source for config and support PR changes, but, it's probably too much work for right now and we can do that with basically any provider. Maybe a job for the ops team further down the line. |
@nastevens any news on this? |
@japaric Sorry, I had a family emergency last week and wasn't able to get to this. Hopefully I can get to it this week. |
@nastevens Totally understandable. Thanks for taking the time to work on this. ❤️ |
Sorry again for the huge delays. I have created the AWS infrastructure listed above in a new AWS account and have it managed with the Terraform here: https://github.com/nastevens/rust-embedded-provisioning. Once we're happy with the layout, I can move the repo into the You can test out the existing domains with
Note that the nameservers are different per TLD due to the way that AWS balances DNS requests - the specific nameserver for a domain is automatically assigned when you create the zone. Note that there is a little bit of magic going on the for the Once someone has had a chance to double-check my work, I will flip the switch to use the new infrastructure. |
My DNS-foo is weak and I just heard about terraform recently but this looks reasonable to me. @ryankurte and @jamesmunns could you also take a look? |
The terraform looks good to me! Haven't tried executing it, but given the records seem right I'd be happy with a swap over. The only questions I still have are around AWS billing / pricing / management. Particularly who owns the management account (maybe we could use a rust-embedded-ops@rust-lang.org address or something to pin everything on @japaric?, it just has to not be on one of the domains we're managing with it). |
I also don't know terraform, but a quick skim over the linked repo makes sense to me. Do we want to go ahead and add a |
Right now that'd be @nastevens.
We can ask the Rust team to create e-mail aliases for us but does it have to be Would it make sense to instead turn the e-mail of each member of the future ops team into a manager of the AWS account? (If that's possible; I don't exactly recall how AWS management works) @nastevens I think this is ready to go. We should create a formal ops team that manages the new repo shortly after the new infra is in place. Any volunteers? We can make you a collaborator of the repo before the ops team is formed. |
I'm happy to be on the ops team too ^_^ |
All sounds good. @japaric I won't be able to join the meeting today, but I will plan to cut everything over this afternoon. If I did it right, we shouldn't even notice 😄 |
DNS records are propagating and so far everything looks good. Might take up to 48 hours before all the caches are cleared, so we'll want to keep an eye on things. http://embedonomicon.rust-embedded.org is a new DNS entry so it should work right out of the gate and looks good from my end. One issue I've noticed so far is that http://embedonomicon.rust-embedded.com doesn't get picked up by GitHub pages, which only allows a single custom domain. We can get around this by setting up an HTTP redirect for that domain - I'll get that taken care of. Please let me know if anyone notices any other issues. |
I pushed the redirect changes, now everything looks to be in good shape. Here's the full list of domains to check: |
The http-versions look good to me, but there is a problem with invalid ssl/tls certificates for a few of them. But as this is not a dns-issue it might be better handled in a new issue. |
@nastevens awesome, thanks! I'm going to close this as done. https and other issues should be reported to https://github.com/nastevens/rust-embedded-provisioning |
Currently rust-embedded.org (and redirect sites rust-embedded.com and areweembeddedyet.com) have DNS managed directly by 1and1.com's DNS tools. Those tools are frankly garbage, and don't allow even basic things like multiple IP addresses on an A record.
I am planning to move DNS management to AWS Route 53 and implement the following proposed layout for
rust-embedded.org
:@
->A
record pointed to Github apex IP addresses (https://help.github.com/articles/setting-up-an-apex-domain/)www
->CNAME
pointed torust-embedded.org
, which will automatically redirect to https://github.com/rust-embedded/rust-embedded-wwwembedonomicon
->CNAME
pointed torust-embedded.org
, which will automatically redirect to https://github.com/rust-embedded/embedonomiconbook
->A
/AAAA
records pointed at @jamesmunns's server at 46.101.143.249/2a03:b0c0:3:d0:0:0:cb7:5001rust-embedded.com
will redirect all subdomains to their equivalent atrust-embedded.org
.areweembeddedyet.com
redirects to the main page for the apex domain andwww
, but doesn't redirect any of the subdomains (book, embedonomicon).Comments welcome - I will set up the AWS records first so we can try them out before cutting over the registrar to use those addresses.
CC @jamesmunns @ryankurte
Refer to rust-embedded/embedonomicon#12
The text was updated successfully, but these errors were encountered: