Resource management (opinions please!)

[tj]

Curious what peoples thoughts are regarding managing things like DNS records, alarms, etc.

One option is individual CLI commands, this would be a little easier to implement, but awkward since the team can't review/audit them, commit them to source control, and requires listing a bunch of resources to see the state of the world.

$ up dns ls
$ up dns add apex.sh blog.apex.sh A 52.0.16.118,52.1.119.170,....
$ up dns add apex.sh ping.apex.sh CNAME ping.netlify.com

The more "correct" approach these days would be more like Terraform infra-as-code style, where the config in your repo is the source of truth, though it may be less familiar/intuitive to some people.

For DNS looking something like the following (for apex.sh zone):

{
  "domain": "apex.sh",
  "dns": {
    "blog.apex.sh": {
      "type": "A",
      "value": [
        "52.0.16.118",
        "52.1.119.170"
      ]
    }
  },
  "ping.apex.sh": {
    "type": "CNAME",
    "value": "ping.netlify.com"
  }
}

Changes would be previewed via up plan which shows what will be updated/created/deleted etc and applied with up apply or similar. Note this is not a replacement for Terraform or CloudFormation, just need to provide enough for people to get apps bootstrapped.

Pros of CRUD style:

• Familiarity due to matching Heroku and friends
• ?

Pros of Terraform style:

• Single source of truth / overview of app just from reading app.json
• Preview changes before applying them
• Easily reviewable via GitHub
• ?

Any opinions?

---

---

What needs implementing for now:

• [x] IAM role(s)
• [x] DNS (explicit)
• [ ] DNS (implicit)
• [x] API Gateway
• [x] ACM
• [x] parameterize tmpl
• [x] outputs
• [x] create stack
• [x] update stack
• [x] delete stack
• [x] plan
• [x] apply
• [x] event streaming
• [x] CLI integration
• [ ] styling / ux

[lukeed]

Why not both? CLI commands read/update central config.

[tj]

Some day maybe, I think I'll start with the config stuff for now, that's more in-line with best practices lately. Secret env vars are probably the one exception I can think of, having those in config is obviously not good haha, might be more but I can't think of any.

[lukeed]

Then yeah, I'd roll with config file first. Not only easier, but supplementing with a CLI later (as opposed to vice versa) is more additive / not breaking.

[stephenmathieson]

Thoughts on something like TFE? It's super nice to have the changes planned/applied by a third party and reviewed by the team. We've had significantly fewer outages after moving stuff from "normal" Terraform to Terraform Enterprise.

[tj]

@stephenmathieson nice! Longer term that definitely makes sense, even running up from the the CLI is gimmicky beyond super small companies, but people like gimmicks haha, sadly, at least it's low barrier to entry I suppose.

Sucks TF isn't very embeddable right now :'(. I'll have to take a closer look at the TF enterprise stuff I only briefly saw it, but that was before it got all hardcore with services all over.

[tj]

needs a bit of polish but pretty much done