Closed berekuk closed 2 years ago
This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.
🔍 Inspect: https://vercel.com/quantified-uncertainty/metaforecast/GiKJxR9LAWzcNM8QtuLvBDLJ7Hjp
✅ Preview: https://metaforecast-git-vercel-quantified-uncertainty.vercel.app
Name | Link |
---|---|
Latest commit | f64a5c04c3d40fe3a51f6a0dda91e91f24fca83a |
Latest deploy log | https://app.netlify.com/sites/metaforecast/deploys/6255da13f03faa0008590fab |
Deploy Preview | https://deploy-preview-55--metaforecast.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
For Ozzie's benefit:
I worry that Terraform is a bit of overengineering. I'm fine with it and it probably leaves the project in a better position in the long term, but I'd prefer to have the graphql interface up first. thoughts?
I worry that Terraform is a bit of overengineering.
Here are the reasons I did this now:
Also, if you count the number of lines of code in this PR but subtract the number of lines in metaforecast-notes-and-secrets that can be removed, the diff size is probably negative; in a sense, terraform configuration is documentation, and it doesn't get stale since it's used as a source of truth.
I was on the fence about it still, but then Ozzie liked https://github.com/quantified-uncertainty/metaforecast/issues/54 and I considered it to be "just do it" signal :)
This wasn't meant as a strong endorsement, sorry! I wasn't sure, but was showing support for discussing it, not for fully implementing it
I'm really not familiar with Terraform.
However, my impression is that:
Are these three things correct? If so, I wouldn't mind much.
I'm really not familiar with Terraform.
Yes, my priors about this for you and Nuño are why I went with implementation instead of discussion.
Are these three things correct?
Yes, all three are correct.
I'll give a short primer, since I suspect that my original description in this PR can be too terse to parse for someone who is not familiar with Terraform.
Terraform allows you to automate the configuration for any cloud service for which the "provider" exists, and there are providers for everything, including Dominos Pizza.
It's not so much for day-to-day code deployments as for wiring everything together at the higher level, and for reconfiguring the wiring whenever necessary (when we switch from Netlify to Vercel, or change env configuration, or move the database to another provider).
For example, terraform configs from this PR set up a Digital Ocean database and then add its URI to the metaforecast env on Heroku and Vercel. So if you move the DO database you don't have to 1) set it up in DO UI; 2) copy the postgres URI; 3) insert it into Vercel/Netlify env UI; 4) insert it into Heroku UI. Instead, you just add a resource for a new database in terraform config, apply the new config, and you're done (well, if you need to migrate the data then it's a bit more complicated, but still much easier).
Ideally, when/if we migrate everything to terraform, someone could roll up their own metaforecast2.org from scratch with a single command (after they set up API tokens for all cloud services in its tfvars config).
To be clear: this can be merged now even if we don't adopt terraform-centered workflow yet. What do you think about this roadmap?
That sounds fine to me, thanks for the summary there.
Thanks as well. Before merging, could you add the latest commit from #53? E.g., https://deploy-preview-53--metaforecast.netlify.app/dashboards/embed/561472e0d2 works but https://deploy-preview-55--metaforecast.netlify.app/dashboards/embed/561472e0d2 doesn't.
Before merging, could you add the latest commit
I already did, in f64a5c04c3d40fe3a51f6a0dda91e91f24fca83a, but Netlify doesn't redeploy new commits for PRs (another reason to move to Vercel...)
Great, merging
Ok, merged
Minor note: I got rid of NEXT_PUBLIC_SITE_URL
in this PR by replacing it with NEXT_PUBLIC_VERCEL_URL
that Vercel provides automatically (see src/web/utils.ts and vercel docs). I realized just a minute ago that it won't work on Netlify... but it works fine for some reason. Probably because "http://" + req.headers.host;
redirects to https
.
The only place this code is used for now is on /dashboards/view/[id]
page, in getServerSideProps
. It's probably broken for POST requests, but we'll move to Vercel soon enough that it shouldn't be an issue.
This PR addresses #52 and #54.
Terraformed: Vercel; Postgres DB on DO; Heroku.
docs/infra.md
, check it out.On vars and state management:
metaforecast-notes-and-secrets
repo for nowgit pull
a different repo, copy these over tometaforecast/tf
, edit,terraform apply
, copy them back to notes-and-secretsprod.auto.tfvars
quantified-uncertainty
org on TC to check how it works, but I'm lacking the permissions to set up GitHub integration; @NunoSempere, if you're ok with using it, can you approve the request for integration? And I'll send you an invite to the orgOther notes on vars:
vercel_api_token
,digital_ocean_token
,heroku_api_key
) inprod.auto.tfvars
; not a big deal, since Vercel and DO separate tokens by teams; Heroku doesn't have fine-grained permissions, but I don't use Heroku and don't plan to ever use it in the futuremetaforecast_env
terraform variable, which is a single untyped key/value object for now; it'd be better to split it into separate vars for type checkingOn Vercel:
76.76.21.21
A record on@
andcname.vercel-dns.com
CNAME record onwww
.