Nais Sites - CRD for SPA

[Kyrremann]

Beskrivelse / Essensen

I dag tilbyr vi deploy av SPA via en Github Action, for de få som bruker denne løsningen så funker det bra. Problemet er at den har en hardkodet tabell av ingresser for tenants, som må manuelt vedlikeholdes.

Det action gjør er å først opprette to k8s-ressurser på runneren (ingress og service), så laster den opp assets med cdn-upload, før den bruker nais/deploy for å deploye de to ressursene den opprettet.
For å opprette ingress-ressursen trenger den å vite hvilke adresser en tenant støtter, og hva ingressClassen her. Den har heller ikke støtte for root-domener da vi ikke ønsker at noen ved et uhell skal ta over nav.no. Dette skaper problemer for nais.io og leesah.io, dette har blitt løst ved at man manuelt kan sette ingress, og ingressClass.

Hvis vi flytter SPA-biten ut til en egen enkel CRD, så kan vi la hver enkel operator avgjøre hvilke domener som er godkjent, og hvilke ingressClass de skal ha. Det blir også enklere å vedlikeholde en liste med ekstra domener.

Ved å ha en operator i clusteret vil vi automatisk ha validering på om et domene+path er tatt i bruk, som vil være en sikring av tjenesten vår.

Etterpå kan vi da fjerne den gamle actionen, og la brukerne laste opp assets med cdn-upload som vanlig, og nais/deploy med den nye crd-filen.

Investeringsvilje

2 uker

Mulig løsning i grove trekk

• Lage en operator som har støtte for en enkel CRD som tar i mot et domene.
  • Operatoren må validere domene mot ingresser som finnes i clusteret, og finne ut hvilken ingressClass den skal bruke selv.
• Dokumentere bruk av ny CRD
• Støtte for konfigurasjon av ekstradomener via Fasit

Ikke-mål

• Slette SPA action (holder med en annonsering, så kan man lage en reminder for noen uker senere)

Eventuell annen relevant informasjon

For at SPA-ingresser skal fungere for flest mulig tjenester så bør vi bytte Nginx-config til

rewrite ^(.*)/(.*)\.(.*)$ /team/path/$1/$2.$3 break;
rewrite ^/$ /team/path/index.html break;            
rewrite ^/(.*)$ /team/path/$1/index.html break;

Shapers

• Kyrre Havik

[Reasonable-Solutions]

I like this initiative because I do not believe that using github actions as an interface is a good idea, less github actions, less problem.
@jhrv is this an archetype, so to speak?

Hvis vi flytter SPA-biten ut til en egen enkel CRD,

This is actually any content, like an MPA, that needs a URL, so there's maybe a distinction that can be made in the naming here.
otoh, Bucket-content-urlrator doesn't really roll of the tongue.

[Kyrremann]

Godt poeng! Er nok mange dokumentasjonssider som kunne hatt nytte av dette, så de slapp å lage sine egne apper.

[jhrv]

Syns dette er en god idé, og jeg sitter igjen med noen spørsmål:

• Tenker vi fortsette med nginx og ingress + service, eller kunne man brukt Google CDN direkte? Kan fremdeles være en CRD for å holde på tilstanden
• Gir dette mening å presentere som en tredje workload type, ved siden av apps og job? Eller er det bare CDN med en URL? Er det noen meningsfulle forskjeller på det vi kaller SPA (men som kanskje bør hete noe annet?) og bare vanlig CDN?
• Ref punkt over, synes det er fint at vi med dette kan vise teamene tydeligere hva de har "kjørende" av ting og tang.
• Det er noe med sammenhengen av miljøene og URLene som er litt utydelig og lite intuitiv i dag som kanskje kan/bør adresseres. F.eks om du vil knytte et område i CDN til URL med domene X, må du velge miljø Y. Kunne vi gjort det smartere? Eller må vi bare tilby en mapping-tabell de kan slå opp i?

Bucket-content-urlrator doesn't really roll of the tongue.

Helt uenig, kjempebra navn

[Kyrremann]

1. Vi kan bruke CDN direkte (ved å legge til host/path rules), usikker på hva vi faktisk sparer på å blande oss inn i den enkle syncen som Nais Console gjør for å rulle ut CDNer. Ved å ha ingressene i clusteret får vi som nevnt automatisk sjekk av like ingresser, selv om kanskje eventen er litt skjult.
2. Høres ut som en god idé å få det inn som en ny workload, eller i det minste synliggjøre mulighetene man har med dette. For å gjøre det ryddig så tror jeg at det å skille mellom CDN og det andre (SPA) vil gjøre det enklere for brukerne våre. CDN er der du lagrer statiske filer, mens det andre er en egendefinert ingress. Og nå som jeg skriver det så kan det hende at alt vi trenger er en workloads > how to > Custom ingress for CDN.
3. enig!
4. Dette blir vel det samme som når du velger et domene for en "vanlig" app, vi har tabellen i dokumentasjonen som sier hvilke domener er tilgjengelig i hvilket cluster. Eneste forskjellen er at vi har kun et miljø for CDN, og lar de selv bestemme path.

Hva med å stjele navnet til Github pages, Nais pages?
Geocities -> Naiscities?
Googles sites -> Nais sites?

[jhrv]

Dette blir vel det samme som når du velger et domene for en "vanlig" app

Godt poeng. Er akkurat like rart :)

Liker Nais pages.

Men sliter litt med distinksjonen/konseptet, for om du laster opp en statisk webside uten spa-deploy i dag, og peker på den URLen du havner på så får du jo opp sida like fint. Så blir ikke da Nais pages akkurat det samme, bare med en litt finere URL?

[Kyrremann]

Men sliter litt med distinksjonen/konseptet, for om du laster opp en statisk webside uten spa-deploy i dag, og peker på den URLen du havner på så får du jo opp sida like fint. Så blir ikke da Nais pages akkurat det samme, bare med en litt finere URL?

Er egentlig bare det som er distinksjonen, med Nais pages kan du få en egendefinert domene.

[jhrv]

jepp, så tenker derfor man kan argumentere for at dette bare er NAIS CDN sånn konseptuelt, men at vi gjør det mulig med en kjekkere URL.

[Kyrremann]

PS: For å få nåværende oppsett til å fungere med test-nais har jeg manuelt lagt inn alle tenants og adresser.

[Kyrremann]

Eksperimentert litt videre med Leesah som bruker AstroJS.
Docusaurus lager en faktisk SPA hvor alt blir styrt fra hvilke adresse du er på, hvor du trenger en kjapp redirect via root html for å komme dit du skal. Astro derimot lager bare statiske filer som gjør at dagens Ingress-config ikke funker.

Dagens oppsett:

rewrite ^(.*)/$ /security-champion-admin/playbook/prod/index.html break;
rewrite ^/(.*)$ /security-champion-admin/playbook/prod/$1 break;

Det som strengt tatt skjer for Docusaurus er at du går til en adresse, så finnes ikke den og du skulle fått en 404, men den sender deg til root, som gjør at SPA som ligger på root sender deg til riktig side.

Oppsett for AstroJS:

rewrite ^(.*)/(.*)\.(.*)$ /leesah-quiz/docs/$1/$2.$3 break;
rewrite ^/$ /leesah-quiz/docs/index.html break;            
rewrite ^/(.*)$ /leesah-quiz/docs/$1/index.html break;

Her sender vi root til root, spesifikke adresser dit de skal, og alt som bare er "kataloger" til riktig katalog med index.html lagt til.

Neste steg er å sjekke om vi kan bruke samme oppsett for SPA, eller om vi trenger en måte å skille disse to.

[Kyrremann]

Testet Docosaurus med oppsettet for AstroJS og det virker til å funke fint, så ved å bytte kan vi treffe begge type sider.

[frodesundby]

Slik jeg forstår det, så er det vi har i dag mulighet for å laste opp statisk innhold til et CDN med et cdn-upload-action. På toppen av det så har vi noe vi kaller spa-deploy, som egentlig er CDN med url, eller Bucket-content-urlrator som Carl kaller det.
I dag er det i overkant av 100 som bruker cdn-upload og rundt 15 som bruker spa-deploy, men integrasjonen i plattformen forøvrig er så som så, så det er lurt å tenke litt mer helhetlig på hvordan vi vil gjøre hva.
Next.js- eller SvelteKit-apper har behov ut over at statisk innhold lastes opp til CDN som vi antakeligvis også burde ha et bedre tilbud til.
Tror det er lurt om vi kartlegger hvilke behov teamene har for å deploye sånne type frontender, og se det i sammneheng med CDN-tilbudet vi allerede har, slik at vi klarer å sy sammen et godt og helhetlig tilbud for frontendapplikasjoner.

Legger denne saken tilbake i draft for denne perioden, men ønsker den tilbake som initiativ til en senere periode etter at vi har snakket sammen og kartlagt litt mer hvor vi vil og hva vi vil ha.

[jhrv]

+1 ☝

Tenker det er bra å rydde litt i begrepsbruken og, for dette er mer "GitHub pages"-aktig funksjonalitet enn noe som har med SPA å gjøre. Det vi tilbyr her trenger ikke være en SPA og kan være kilde til en del forvirring. Så lurt å få det bort.

Det vi kaller spa-deploy er samme som vi tilbyr rundt CDN, men med mulighet til å styre URLen til et domene som vi tilbyr inne i clusterene.

Noen tanker:

$ nais cdn upload --src=./build # standard cdn-upload oppførsel
$ nais cdn upload --src=./build --url=myapp.domain.tld/foo # dagens spa-deploy

Dette kunne/burde da kanskje vært styrt via Nais API som så hadde sørget for å implementere de riktige ressursene i riktig cluster + validering ?

[Kyrremann]

Fordelen med å ha det som en CRD er at CRDen vet hvor den er, så brukeren slipper å spesifisere miljø, og vi kan enklere unngå at ingresser overlapper, da vi har alle ingresser allerede definert i miljøet.

[jhrv]

Jeg tror vi kan gjøre det enda enklere. For selv med CRD må de jo angi hvilket miljø den CRDen skal deployes til, og det som står inni CRDen må matche - og dette er noe de må passe på.

Om vi gjør dette via API kan de slippe det, og vi kan verifisere at domenet fins i tenanten et eller annet sted, også sørger vi for å legge det i riktig miljø for de.

[mortenlj]

Ulempen med at brukerne våre skal gjøre dette via API er at de ikke lenger kan deploye noe som ligger i git via github actions. Vi optimaliserer for at de skal deploye fra utviklernes egne maskiner. Det er i mine øyne helt bakvendt i forhold til alt annet vi gjør.

Fordelen med å ha det som en CRD er at måten man deployer en SPA er akkurat lik måten man deployer en Application eller en Naisjob: Man deployer en ressurs inn i et cluster. Det er verdi i å gjøre ting likt.

[Starefossen]

Sammen med en SPA CRD så må vi også se på hvordan vi gjør ruting / rewriting. Det vi gjør med nginx ingress lever egentlig litt på nåde og burde vært erstattet med noe litt mer produksjonsklart. Fordelen m ed å ha dette som en ordentlig CRD er vi kan endre den bakenforliggende implementasjonen uten at alle applikasjonene trenger å redeploye slik de må i dag (det har f.eks. skjedd sist vi gjorde endringer i ingress class). Ingress behandles ikke som et stabilt API fra vår side i dag.

[Reasonable-Solutions]

Noen tanker:

$ nais cdn upload --src=./build # standard cdn-upload oppførsel.
$ nais cdn upload --src=./build --url=myapp.domain.tld/foo # dagens spa-deploy

nb. deploying from developer machines puts us by default at SLSA level 1 (at best!), which is the lowest level after 0 which is "None". https://slsa.dev/spec/v1.0/levels
SLSA Level 2. Requires hosted build platforms.
From a NAIS as a product perspective and given the space we operate in offering a high slsa level by default is a good thing (tm).

Det er verdi i å gjøre ting likt.

Det er verdi i å gjøre ting (s)likt. too! XD

[Kyrremann]

Man setter egentlig dette bare opp en gang per domene/side, så hvis vi ikke ønsker å administere dette via clusteret, så kan vi jo ha det som clickOps i Nais Console, hvor man går til buckets, også er det en knapp for å legge til et domene.

Personlig syns jeg det er rart å flytte dette inn i Nais API, tror ikke vi tjener så mye på å utvide ansvaret. Nais API er blitt ganske svær!

[jhrv]

Ser jeg trenger tydeliggjøre litt hva jeg mente med kommentaren min, da tre kommentarer baserer seg på feil antagelser.

Først og fremst. Forslaget med pseudo-kode med Nais CLI betyr ikke at dette kun kan kjøres fra utviklermaskiner. CLIet er vel så mye ment å kunne brukes fra Github actions (eller andre CI verktøy).

- uses: nais/setup@v1   
- run: nais cdn upload ...

Når jeg snakker om Nais API i dette tilfellet, mener jeg ikke nødvendigvis at det ikke skal lages en CRD i tilleggg i clusteret. Det er mer en implementasjonsdetalj. Det kan være CRD, eller det kan være API eller en helt annen komponent som holder styr på det. Poenget med å la dette gå via APIet er at da slipper utviklerene å ha et aktivt forhold til hvilke domener bor i hvilke clustere.
Dette unødvendige detaljer når det du vil er å dytte noen filer til CDN og knytte et domene til det.

@Reasonable-Solutions forslaget var ikke begrenset til utviklermaskiner. Det sagt, vi ønsker fremdeles at utviklere skal kunne bygge og deploye fra egen maskiner