[HN Gopher] Abusing Terraform to Upload Static Websites to S3
       ___________________________________________________________________
        
       Abusing Terraform to Upload Static Websites to S3
        
       Author : grschafer
       Score  : 38 points
       Date   : 2021-10-06 18:10 UTC (4 hours ago)
        
 (HTM) web link (www.tangramvision.com)
 (TXT) w3m dump (www.tangramvision.com)
        
       | k__ wrote:
       | Interesting. I do this on a regular basis with Pulumi and
       | Cloudflare Workers KV.
        
       | simonw wrote:
       | Love this. It's pretty obviously the wrong tool for the job, but
       | I learned a ton about Terraform from reading about how they got
       | it to do this.
        
       | nanis wrote:
       | As fun as it is to do this stuff, it is better to think about
       | what a unit of deployment is first. Conceptually, it is important
       | to separate the stuff that changes rarely (e.g., bucket name, the
       | CNAME etc) from the stuff that changes at each deployment (web
       | site content).
       | 
       | The role of terraform (or any other infrastructure component) is
       | to make sure the place where you put the web site content exists
       | (and the correct wiring exists) before you try to put the web
       | site content there.
       | 
       | Having a layer of indirection between your infra code and the
       | actual deployment interface helps. At its most basic, you can use
       | terragrunt for this to invoke `aws s3 sync`[1].
       | 
       | [1]:
       | https://docs.aws.amazon.com/cli/latest/reference/s3/sync.htm...
        
       | jftuga wrote:
       | I created a repo that use Terraform to create:
       | 
       | AWS CloudFront website
       | 
       | ACM certificate
       | 
       | Route53 DNS entries
       | 
       | S3 bucket
       | 
       | ___
       | 
       | It also creates a default index.html file and will make:
       | 
       | www.example.com/something automatically redirect to
       | www.example.com/something/index.html
       | 
       | S3 bucket permissions are private and only accessible by the
       | CloudFront distribution via an OAI.
       | 
       | After purchasing a new domain in Route53, you have have a new
       | website up and running in about 5 minutes.
       | 
       | ___
       | 
       | https://github.com/jftuga/terraform_cloudfront_builder
        
       | [deleted]
        
       | tobilg wrote:
       | Or use https://github.com/tobilg/serverless-aws-static-websites
       | with the Serverless framework
        
       | mulmboy wrote:
       | AWS CDK makes this much easier - including automatically
       | invalidating the cloudfront distribution
       | https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws...
        
       | gizdan wrote:
       | Uuh, don't? Data inside S3 buckets have a different lifecycle
       | from anything that you'd otherwise be doing in Terraform.
        
         | derefr wrote:
         | Not necessarily. Consider a design where each bucket is
         | immutable for its entire lifetime. (Think: domain squatting
         | "This domain is for sale" pages. Or domains that only exist to
         | serve a redirect. Or, say, example.com. Or the Web 1.0 category
         | of "per-subdomain, immutable, _fixed format_ , non-interactive,
         | user-generated content" sites, e.g. YTMND.)
         | 
         | For such setups, it could be easier to think of an object-
         | storage _bucket_ as, itself, a fully-static resource, even a
         | _content-addressable_ resource -- where the _bucket name_
         | contains an asset-pipeline fingerprint hash of the content of
         | the bucket. In such cases, whether the bucket _exists_ is the
         | same as asking whether the content is deployed.
         | 
         | Then, rather than relying on S3-or-equivalent's own HTTP
         | hosting (which requires that your CNAME also be the name of the
         | bucket), you'd give the bucket a well-known "symbolic link"
         | name by either configuring your own load-balancer with a
         | hostname = bucket-content-address mapping (think k8s Ingress
         | resources for this); or by configuring a third-party like
         | Cloudflare to route the subdomain to a Worker that in turn
         | makes requests to the specific bucket, passing the actual
         | internal hostname. In the latter case, the per-subdomain Worker
         | script would also be part of the Terraform deployment.
        
       ___________________________________________________________________
       (page generated 2021-10-06 23:01 UTC)