Skip to content

kleivane/immutable-webapp-starterpack

Folders and files

NameName
Last commit message
Last commit date
May 6, 2020
May 6, 2020
May 6, 2020
May 6, 2020
May 6, 2020
May 6, 2020
May 6, 2020
May 6, 2020
May 6, 2020
May 7, 2020
May 6, 2020
Jun 8, 2020
May 6, 2020
May 6, 2020

Repository files navigation

Immutable-webapp

En implementasjon av stukturen fra https://immutablewebapps.org/ .

Slides

Bli kjent

Om appen

Lokal oppstart

  • Kjør opp appen med npm install && npm run start
  • Generer en index.html med node src-index/main.js
  • Gjør deg kjent med hvor de forskjellige inputene og env-variablene i appen kommer fra

Min første immutable webapp

Felles mål her er en immutable webapp med to S3-buckets og et CDN foran som hoster index.html og kildekode.

Nyttige lenker:

Testmiljø med buckets

Opprett to buckets med terraform som skal bli der vi server asset og host. Start i terraform/test/main.tf. Husk at S3-bucketnavn må være unike innenfor en region!

Anbefalt terraform-output for begge buckets:

  • bucket_domain_name - denne lenken kan du bruke til å aksessere filene du har lastet opp
  • id - navnet på bucketen du har opprettet

Når begge bucket er oppprettet uten mer oppsett, og du kan gå inn i konsollen på web og manuelt laste opp en tilfeldig fil. Den vil ikke tilgjengelig på internett via bucket_domain_name/filnavn, ettersom default-policyen er at bucket er private. Vi kan konfigurere public tilgang ved å bruke acl-parameteret på en bucket eller en bucket policy. Sistnevnte er anbefalt av AWS ettersom bucketacl er et eldre og skjørere konsept.

Opprett bucketpolicies for begge bøttene ved å bruke aws_s3_bucket_policy. I policy-atributtet kan du bruke en templatefile med fila policy/public_bucket.json.tpl. Denne trenger en variabel bucket_arn. Bruk atributtet fra bucketen for å sende inn rett arn.

Se policy.md for en forklaring på innholdet i policyen.

Bruke AWS-cliet til opplasting av filer

Bygg assets lokalt med npm run build og bruk aws-cliet til å laste opp alt innholdet i build-mappen til asset-bucketen under navnet assets/id. Velg en tilfeldig id for testen, senere skal vi bruke githash! Test at fila blir tilgjengelig i browseren på <bucket_domain_name>/assets/id/main.js og sett rett cachcontrol-headers.

aws s3 cp <LocalPath> <S3Uri>

Se AWS-cli-docs for aws s3 cp

Tips

  • bruk følgende S3-uri s3://bucket-name/assets/1/
  • --recursive laster opp hele mappen
  • --cache-control public,max-age=31536000,immutable setter cache-controls-headerne til alltid lagre som beskrevet i https://immutablewebapps.org/

Gjør endringer i sha og url i src-index/main.js for å peke på bucket og fila du har lastet opp over. Bygg index.html (node src-index/main.js) og bruk aws s3 cp igjen for å kopiere index.html til host-bucket. Husk rett headers

Om du nå går på <bucket_domain_name>/index.html bør du se en kjørende applikasjon.

Tips

  • Bruk index.html både som localPath og s3://bucket-host-name/index.html som S3Uri ettersom vi kun laster opp en fil
  • --cache-control no-store setter cache-controls-headerne til aldri lagre som beskrevet i https://immutablewebapps.org/

Autodeploy av assets med Github Actions

Nå skal vi la Github Actions overta bygging av assets og opplasting til assets-bucketen under unike versjonsnavn. For enkelhets skyld er versjonsnavnet her assets/sha/. Vi skal bruke de samme kommandoene som over, men la det utførest av github.

  • I .github/workflows/nodejs.yml er det starten på en workflow. Fullfør denne slik at bygg og kopier filer til assets-bucketen skjer på hver push.
  • I run-delen av en githubaction kan man hente ut commit med ${{github.sha}}, se docs. Tilsvarende kan den hentes ut i src-index/main.js som process.env.GITHUB_SHA`

Det finnes en githook som linter yml-filer for å slippe unna enkelte yml-feil i workflow-definisjonen. Om du ønsker å ta den i bruk kan du kjøre kommandoen git config core.hooksPath .githooks

Autodeploy til host

  • Utvid .github/workflows/nodejs.yml til også å generere og laste opp index.html i host-bucketen. Sjekk ut tilgjengelige variable for node i docs.

CDN

AWS CloudFront er Amazon sin CDN-provider, se terraform-docs. Om du gjør dette for første gang anbefaler jeg at du starter med et cloudfront-domene og heller endrer til eget domene i neste steg.

For å mappe terraform-input til rett verdier, anbefaler jeg å se i aws-konsollen på CloudFront og velge "Create a distribution". En gotcha som er fin å vite om, dersom du ikke setter verdier i ttl-atributtene til terraform vil dette gjøre at CloudFront velger å bruker cachecontrol-headers fra origin, tilsvarende Use Origin Cache Headers fra AWS-console'en.

Figuren bakerst i slidesettet gir en slags oversikt av hvordan CloudFront passer inn som server for både host og assets - men dette var også den vanskeligste delen av oppgaven å beskrive! Så vær så snill å stikk innom Tine eller andre om det ikke gir mening.

Test ut endringer i App.jsx og deploy ny versjon av assets og index for å sjekke caching og endringer.

  • OBS: Nå kan du bruke domain_name outputen fra cloudfront som erstatning for my-url i src-index/main.js
Tips

  • du trenger en origin pr. s3 bucket
  • enabled, restrictions, viewer_certificate kan være default
  • default_root_object er index.html
  • default_cache_behavior og ordered_cache_behavior kan ha like configparameter, men default må peke på host-bucket og ordered_cache_behavior på assets. Path assets/* matcher url-strukturen fra index.html

Løsningsforslag i repoet frem til hit ligger under https://github.com/kleivane/immutable-webapp/tree/master/terraform/test-1 .

Alternativer videre (bruk rekkefølgen som står eller plukk selv om du ønsker noe spesielt)

Cirka frem til punktet "Lag et eget domene" kan du finne et løsningsforslag i repoet https://github.com/kleivane/immutable-webapp/ under mappene terraform/test, terraform/prod og terraform/common.

  • Lag et prodmiljø
  • La terraform opprette en iam-bruker som bruker av github med rettigheter kun til opplasting i buckets. Rettighetssimulatoren for iam kan hjelpe litt
  • Ta i bruk remote backend i S3
  • Trekk ut til en felles terraform-modul
  • Trekk ut bygging av index.html til en lambda
    • Lambdaen trenger kildekode i egen bucket
    • La tagging i github lambda-x.y.z trigge bygging og release av ny kildekode
    • Provisjoner lambda med terraform pr miljø og send inn versjon av kildekoden som skal brukes
  • Lag et eget domene i Route 53 slik at du har en egen url
    • Lag sertifikat fra certification manager
    • Legg inn alias og sertifikat (viewer_certificate) i cloudfront. Merk av ssl_support_method = sni-only for å unngå ekstra kostnader!
    • Opprett alias i route53 med en ny record
    • Alias record typically have a type of A or AAAA, but they work like a CNAME record
  • Ta i bruk https://github.com/nektos/act for kjøring av github-actions lokalt
  • Skriv tester! https://terratest.gruntwork.io/
  • Trekk ut prodmiljø i en egen AWS-account
  • Rull ut dockercontaineren fra https://github.com/kleivane/static-json
  • Test ut workspaces for terraform-endringer
  • Bruk moduler fra https://github.com/cloudposse/, feks https://github.com/cloudposse/terraform-aws-cloudfront-cdn
  • Flytt cachecontrol fra hver enkelt fil til lambda@edge
  • Bruk en annen skyprovider

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published