terraform {
    required_version = ">= 1.0.0"
    required_providers {
        digitalocean = {
            source = "digitalocean/digitalocean"
            version = ">= 2.0"
        }
        cloudflare = {
            source = "cloudflare/cloudflare"
            version = "~> 4.0"
        }
    }
}

# DigitalOcean provider
provider "digitalocean" {
    token = var.digitalocean_token
}

# Cloudflare provider
provider "cloudflare" {
    email = var.cloudflare_email
    api_key = var.cloudflare_api_key
}

resource "cloudflare_record" "main_app" {
    zone_id = var.cloudflare_zone_id
    name = "example.com"
    content = digitalocean_reserved_ip.main_ip.ip_address
    type = "A"
    proxied = true
}

resource "cloudflare_record" "www_cname" {
    zone_id = var.cloudflare_zone_id
    name = "www"
    type = "CNAME"
    content = "example.com"
    proxied = true
}

rules {
    action = "redirect"
    action_parameters {
        from_value {
            status_code = 301
            target_url {
                expression = "concat(\"https://example.com\", http.request.uri.path)"
            }
            preserve_query_string = true
        }
    }
    expression  = "(starts_with(http.host, \"www.\"))"
    description = "Redirect www to non-www"
    enabled = true
}

[`always_use_https = "on"`](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/always-use-https/):

> Always Use HTTPS redirects all your visitor requests from http to https, for all subdomains and hosts in your application.

Good stuff.

Now, about that `ruleset`. It works but I'm not confident that it's the ideal solution. I feel like the API should have a "Redirect Rules" surface, because that's a thing in the console. But apparently here you can only use Page Redirects or raw rulesets. Please comment if you know what it should be.

Anyway, this does a `302` redirect from `www` to the bare TLD, and I'm not concerned about preserving paths or query strings, because it takes user effort to turn a valid url into a non-working `www` url. I just don't care about that rare scenario when someone manually edits a path-bearing URL to add a www, and sends it to someone else without checking it. Their path will get stripped. Sucks for them.

### DigitalOcean project

I have a dedicated project that I'm creating these resources in. Without this, the resources would be created in the default project.

### The Reserved IP Address

This `digitalocean_reserved_ip` is what worked for me. I tried getting `digitalocean_reserved_ip_assignment` to work, but it always deregistered the reserved IP from the live droplet before the replacement droplet was provisioned. This was unacceptable because it created a period of downtime lasting _minutes_. Completely unacceptable.

### SSH Key

This SSH key is for letting me ssh into the droplet.

### Resource-Based Invalidation

When I change the html files _or_ the initialization script (see below), I want it to trigger a replacement of the droplet. By default, terraform doesn't recreate a droplet if its user_data or remote-exec blocks change. Weird, I know. So this is a way of hacking around it.

We hash all the files and use the resulting hash to invalidate.

Here is `generate_hash.sh`:

### The droplet

# Trigger recreation on changes to input files.
user_data = "# inputs_hash: ${data.external.hashes.result.inputs_hash}"

lifecycle {
    create_before_destroy = true
}

connection {
    type = "ssh"
    user = "root"
    private_key = file("~/.ssh/mykey")
    host = self.ipv4_address
    timeout = "5m"
}
provisioner "remote-exec" {
    inline = [
        "mkdir -p /tmp/html",
    ]
}
provisioner "file" {
    source = "${path.module}/../web/dist/"
    destination = "/tmp/html"
}
provisioner "remote-exec" {
    script = "setup/main-server-init.sh"
}

The `user_data` block now only has the invalidation hash. It doesn't have any cloud-init scripts, because I'm handling that in a custom script (`setup/main-server-init.sh`) in the `remote-exec` provisioner block.

`lifecycle.create_before_destroy` is critical to getting a zero-downtime deploy. This way, when you run `terraform apply`, your current droplet will continue to serve requests while your new droplet is building. And only after it's ready does the Reserved IP switch over to the new droplet. So, an instant cutover.

Here is `main-server-init.sh`:

Not perfect, but it's what I have.


# Improvements

I'd like to separate the html files from the nginx init script, so that I can update the deployed files without recreating the whole droplet. It's safe enough.

The DigitalOcean droplet no longer shows its graphs in the console. [This](https://docs.digitalocean.com/products/monitoring/how-to/install-agent/) is how you get it working, but `ufw` is probably misconfigured.

It could use a health check to make sure nginx started properly.

That's it!