Terraforming Cloudflare for DNS records #3391
Conversation
I can do that for you, if that's fine. (I know it exceeds what I usually should do with my "superadmin" rights, but I believe in this case it is fine) |
| proxied = false | ||
| ttl = 1 | ||
| type = "CNAME" | ||
| value = "npmjs.org" |
There was a problem hiding this comment.
Aside: that seems like something that should transfer to GitHub/NPM @MylesBorins
| proxied = false | ||
| ttl = 1 | ||
| type = "CNAME" | ||
| value = "npmjs.org" |
There was a problem hiding this comment.
Is this meant to make packages.nodejs.org point to nphjs.org as I don't see that I just get to the main website when I go to packages.nodejs.org.
But I agree that we should deal with changes in follow on PRs
| proxied = true | ||
| ttl = 1 | ||
| type = "CNAME" | ||
| value = "logs.libuv.org" |
There was a problem hiding this comment.
logs.libuv.org used to point to a server with slurped IRC logs (definitely for libuv channels but I think some Node.js channels as well). I'm not sure who owned it (or even if libuv has a channel on IRC or anywhere else anymore) -- @bnoordhuis @cjihrig do you remember?
Co-authored-by: Moshe Atlow <[email protected]>
|
@nschonni I am not planning to make DNS record changes in this PR because we are only migrating the current state from the Cloudflare UI to Terraform in this PR, and we don't have writing permissions yet in the GitHub Action. I think we can move that discussion to a separate PR. In the meantime, I created a subtask for it on #3270 (comment). Let me know if this approach works for you 👍. |
|
@UlisesGascon my only question is if it would make sense for us to break this into 2 PRs, one to add the records for the iojs.org and s second one for nodejs.org. The idea being that landing the iojs.org one would be lower risk and once we see that all working we land the second. Not sure if it helps but was wonding. |
| ### Local development | ||
|
|
||
| #### IMPORTANT ⚠️ | ||
| If you apply any plan in you local machine, you can trigger changes in the Cloudflare account. So, you must be careful with the changes you are applying in your local environment. In order to review/create changes you are not require to do local development as the github pipeline will generate a plan with the changes. |
There was a problem hiding this comment.
@UlisesGascon I would have thought you would need Cloudflare access for anything you do locally to have an effect?
|
|
||
| #### Requirements | ||
| - Terraform version `Terraform v1.4.5` used to build this infrastructure. [How to install Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) | ||
| - You will need a `TF_API_TOKEN` in you environment with a valid Terraform cloud API Key. [How to create a Terraform cloud API Key](https://www.terraform.io/docs/cloud/users-teams-organizations/api-tokens.html#creating-an-api-token) |
There was a problem hiding this comment.
I guess this is related to my question above. I assume we don't expect anybody to be doing this. Intead there should be a PR and the action which has the TF_API_TOKEN will apply any changes.
|
@mhdawson @nschonni let me know if this can help solve some of the questions from your previous comments General overview
Green path This is the default way (and recommended) when we want to make any changes in Cloudflare once this PR is merged. Any user can create a PR and add/update/remove resources from Cloudflare. Once the PR is merged, the GitHub actions will notify this change directly to Terraform Cloud. Terraform Cloud will apply the changes in Cloudflare. Blue path Any user who has access to Terraform Cloud (can use or generate a token). This token can be used in the same way as the GitHub actions do in the green path. So, even if you don't have access to Cloudflare, when you trigger a new plan directly from Terraform Cloud, it will be applied as Terraform Cloud can authenticate against Cloudflare. This option is quite interesting as it is the best way to import resources. For example, as @nschonni suggested with the firewall rules. Red path As far I know is what we do today, the user has write access to Cloudflare and can make changes via web UI or CLI. This option remains possible even when this PR is merged. Only a few people in the org have this access level, which will be used, for example, to modify Cloudflare settings for items that are not covered with Terraform. Specific concerns
We can split this PR into two separate ones, but currently Terraform cannot apply any changes in Cloudflare as we have a read only token. I think that we can keep this approach (read only tokens) until we feel confident with this jump. I believe that just by keeping these Terraform files in sync with the Cloudflare state, we are already providing value to the org members as now our infrastructure is much more transparent than before and it is easier to propose changes, even if we make manual changes via Cloudflare CLI or web UI. at the end. It will also help us to detect discrepancies between our desired state and the current Cloudflare state
I think it is a good idea to include the rules in this PR. Should I import them in this PR or do we prefer a separate one? |
I think either this PR or another is ok, whichever you prefer. I was just flagging that this PR is set to autoclose that other issue, but I think there are one or 2 more things that might still be needed like the firewall stuff. |
Great point, I just removed the autoclose reference |
|
@UlisesGascon thanks for the nice picture. We might want to include that in the doc somewhere. I probably was not quite clear enough in my questions, but your answer confirms it anway. Generally people should not have the cloudflare token and updates will be through the GitHub action. As more of an exceptional case (doing initial reource imports etc.) people can get a token an use it locally. EDIT: Also seems like we can use a READONLY token for imports that we run locally and that should possibly be the standard approach that we document. In that way people can't accidentally deploy. |
I do think we want to make the jump sooner than later. I'd prefer we make a step of managing some of the DNS entries to start versus waiting longer. I may be making more work, but for example if we added 5 at a time, then if anything when wrong the manual work to fixup would be lower. @richardlau does doing them in smaller batches make any sense to you? |
|
I will close this PR as we will move this initiative to a different repository. Follow up details in nodejs/admin#848. |
Main Changes
main) the changes when changes are done in theterraformfolder.Context
Notes
Cloudflare API Token
The Cloudflare API Token is stored in the Terraform Cloud workspace. The token is used to authenticate the Terraform Cloud agent to the Cloudflare API. The token is stored in the
TF_API_TOKENenvironment variable in the Terraform Cloud workspace.This token currently is in READ ONLY mode so it can not be used to create or update resources in Cloudflare. This is a security measure to prevent accidental changes in the Cloudflare account until we are familiar with Terraform as a team. See: #3370
CI Settings
I need to include a secret
TF_API_TOKENin the github actions settings in this repository. Not sure how to do that as I am not an admin in this repository.Changelog