De siste årene har det vært gjort en betydelig innsats for å forbedre observerbarhet i Nais. Først frontend observerbarhet med Faro, og så helhetlig sporing på tvers av applikasjoner med OpenTelemetry Tracing. Alt sammen har integret sømløst med Grafana, som er Nais sitt fortrukne observerbarhetverktøy.

Det har i lengre tid vært mulig for teamene i Nav å sende applikasjonslogger til Grafana i GCP, dette er nå mulig for applikasjoner i FSS fra og med i dag! Dette gir deg som utvikler en helhetlig oversikt over hva som skjer i applikasjonen din, og gjør det enklere å feilsøke og forstå hva som skjer i systemet uansett om applikasjonen din kjører i GCP eller FSS.

Hva skjer videre?

Dette er første skritt i retning for å samle all observerbarhet for applikasjoner på Nais under ett tak i Grafana. Etter hvert kommer logging til Grafana Loki å bli satt som standard for alle applikasjoner. Vi kommer tilbake med mer informasjon om dette og eksakte datoer snart.

I en mellom-periode vil det være mulig å sende logger til både Grafana og Elastic for å sikre en smidig overgang før vi gradvis faser ut Elastic og Kibana fra Nais-plattformen.

Hva må du gjøre?

Du kan allerede i dag ta i bruk den nye loggfunksjonaliteten i Nais. For å gjøre dette må du oppdatere konfigurasjonen til din applikasjon på følgende måte. Hvis du i overgangsperioden ønsker å sende logger til både Grafana og Elastic, må du oppdatere konfigurasjonen din til å sende logger begge steder.

Hvorfor gjør vi dette?

Vi har valgt å gjøre denne endringen for å gi deg som utvikler en bedre opplevelse når det kommer til observerbarhet. Ved å samle all observerbarhet i Grafana, kan vi tilby en mer helhetlig løsning som er enklere å bruke og gir deg bedre innsikt i hva som skjer i applikasjonen din og systemet som helhet på tvers av logger, tracing og metrics.

I tillegg vil dette gjøre det enklere for oss å vedlikeholde og utvikle nye funksjoner i Nais, da vi kan fokusere på én plattform i stedet for flere.

Hva med secure logs?

Secure logs vil bli erstattet med en ny løsning som heter Team logs. Dette vil gi deg den samme muligheten til å sende logger som ikke skal være tilgjenglig for andre team. Denne løsningen baserer seg på Google Cloud Logging og vil gi deg bedre kontroll over hvem som har tilgang til loggene.

Google Cloud Logging er en del av Google Cloud Platform og bor i hvert enkelt team sitt Google Cloud prosjekt og gir deg muligheten til å lagre, søke og analysere loggene dine på en enkel måte. Dette er samme sted som mange av audit loggene fra Nais også blir lagret.

Jeg vil vite mer!

Vi kommer til å sette opp flere informasjonsmøter og workshops for å hjelpe deg med å ta i bruk den nye loggfunksjonaliteten i Nais. Vi vil også oppdatere dokumentasjonen vår for å gjøre det enklere for deg å komme i gang.

Det er fortsatt en del applikasjoner som bruker Postgres 12 i GCP. Vi minner om at Postgres 12 egentlig hadde End-of-Life 21. november 2024, og det er anbefalt å oppgradere til nyere versjoner.

Vi har også fått varsel fra Google om at bruk av Postgres-versjoner som har passert End-of-Life vil ble vesentlig dyrere fra 1. mai. Kjappe overslag antyder omtrent $115 ekstra i måneden per CPU.

Vi anbefaler alle team om å oppgradere Postgres jevnlig, for å unngå å havne alt for langt på etterskudd. Nyeste major versjon av Postgres er 17.

For å oppgradere kan man velge en av disse tilnærmingene:

• Gjøre en enkel in-place oppgradering: https://docs.nais.io/persistence/postgres/how-to/upgrade-postgres/, eller
• Gjøre en migrering til ny instans: https://docs.nais.io/persistence/postgres/how-to/migrate-to-new-instance/

Vi har i dag lansert støtte for å kunne deploye endringer i Application/Naisjob uten å bygge et nytt Docker image. 🎉

Frem til i dag har det vært nødvendig å bygge et nytt Docker image hvis du skal deploye endringer i Application/Naisjob, fordi spec’en krever et image og du har ikke det gamle lett tilgjengelig. Vi har nå gjort endringer som gjør at du ikke trenger å ha image i Application/Naisjob i det hele tatt.

Hvis du deployer en Application/Naisjob uten at image er satt, så vil vi finne det forrige imaget du deployet og bruke det. Dette forutsetter at du har gjort en deploy tidligere med WORKLOAD_IMAGE-variabelen satt (se nedenfor).

Hvis du ikke trenger denne muligheten er det ikke nødvendig å gjøre noen endringer.

For at dette skal fungere er det noen endringer du må gjøre i workflowen din:

1. Fjern image fra Application/Naisjob spec’en din.
2. Sørg for at checkout steget i workflowen din henter hele historikken, slik at vi kan slå fast hva som har endret seg siden sist.
3. Legg til et nytt steg som sjekker om det er endringer i spec’en din, f.eks. ved hjelp av nais/what-changed-action.
4. Legg til en if: steps.changed-files.outputs.changed != 'only-inputs' på byggesteget ditt, slik at det kun bygges hvis det er endringer.
5. Sett variabelen WORKLOAD_IMAGE til output fra byggesteget i kallet til nais/deploy.

Se eksempelet i dokumentasjonen vår for hvordan du kan gjøre dette: Build and deploy with GitHub Actions.

Fra og med 20. mars vil Nais rotere tilkoblingshemmelighetene til Valkey og OpenSearch instansene. Servicebrukeren som k8s clusterene til Nais bruker for å tillate tilkobling til Aiven sine Valkey og OpenSearch instanser, vil få sin hemmelighet (til Aiven ressursen) rotert senest hver andre uke. De roteres inn/ut av bruk ettersom relevante Aiven ressurser legges til/fjernes i Nais Application spec, samt tilhørende ReplicaSets i k8s.

Les mer om OpenSearch i Nais docen her. Les mer om Valkey i Nais docen her.

Vi ser at vi ikke har fått til det vi ønsket med spa-deploy, og for å lette byrden på teamet velger vi å sanere og rydde bort denne Github actionen. Dette vil ikke påvirke tjenestene som allerede bruker action, og ingressene som har blir opprettet vil ikke bli ryddet bort. Vi fjerner kun selve Github action, så hvis du er et av de 10 teamene som bruker den, må dere gjøre en liten migrering vekk fra spa-deploy, over til cdn-upload.

- uses: nais/deploy/actions/spa-deploy/v2@master
  with:
    team: security-champion-admin
    app: playbook
    environment: prod
    source: build
    ingress: https://sikkerhet.nav.no

må endres til

- name: Upload static files to CDN
  uses: nais/deploy/actions/cdn-upload/v2@master
  with:
    team: security-champion-admin
    source: build
    destination: playbook/prod

destination er kombinasjon av app og environment.

Fra og med 1. april vil vi kreve at applikasjoner og jobber på Nais bruker images som kommer fra teamets eget repository i Google Artifact Registry/GAR. De fleste gjør allerede dette, så for de er det ingen endring.

Det er to hovedgrunner til at dette nå blir håndhevet:

1. Vi kan da være sikre på at det er en autorisert Nais-bruker eller repository som har lastet det opp. Med audit logg.
2. Teamets repository ligger nærmere clusteret, og støtter Image Streaming som gjør at oppstartstid ved f.eks autoskalering eller plattform-vedlikehold er rask.

Den enkleste måten å sikre at imagene havner riktig sted er å bruke Nais’ github actions i workflowet sitt. Da trenger man ikke ha et aktivt forhold til hvor imaget ligger lagret, og alt går av seg selv.

Console vil fra nå og frem til 1. april gi en advarsel om dette.

Les mer om image repositories i Nais-dokumentasjonen.

Token Exchange as a Service (Texas )

De fleste applikasjoner som trenger autentisering må i dag forholde seg til mange detaljer rundt OAuth og JWTer. For å gjøre det lett å gjøre rett så har vi nå laget en tjeneste som abstraherer vekk alt dette bak et enkelt HTTP API.

Tjenesten er en sidecar som kjører sammen med appen din og er kun tilgjengelig i kjøretid på Nais. APIet har tre endepunkt som tilgjengeliggjøres som miljøvariabler:

• NAIS_TOKEN_ENDPOINT lar deg hente et maskin-til-maskin token
• NAIS_TOKEN_EXCHANGE_ENDPOINT lar deg bytte inn et token med sluttbrukerkontekst mot et nytt on-behalf-of-token
• NAIS_TOKEN_INTROSPECTION_ENDPOINT validerer et token og returnerer tilhørende claims som JSON

Kodeeksemplene under illustrerer enkel bruk av APIet via curl.

curl $NAIS_TOKEN_ENDPOINT \
  -X POST \
  -d 'target=api://<cluster>.<namespace>.<app>/.default' \
  -d 'identity_provider=azuread'

{
    "access_token": "eyJra...",
    "expires_in": 3599,
    "token_type": "Bearer"
}

curl $NAIS_TOKEN_INTROPECTION_ENDPOINT \
  -X POST \
  -d 'token=eyJra...'

{
    "active": true,
    "aud": "client-id",
    "exp": 1732193127,
    "iat": 1732189527,
    ...
}

curl $NAIS_TOKEN_EXCHANGE_ENDPOINT \
  -X POST \
  -d 'target=<cluster>:<namespace>:<application>' \
  -d 'identity_provider=tokenx' \
  -d 'user_token=eyJra...'

{
    "access_token": "eyJra...",
    "expires_in": 3599,
    "token_type": "Bearer"
}

Fordeler med Texas:

• Agnostisk til programmeringsspråk og rammeverk (gitt at det kan snakke HTTP)
• Innebygget best practices — caching av tokens og validering av det viktigste
• Ingen kodeavhengigheter — du slipper å dra inn ekstern kode som må gjennomgås og vedlikeholdes. Dette reduserer antall potensielle kilder til sårbarheter.
• Du slipper å forholde deg til hemmeligheter i applikasjonskoden

Texas er foreløpig i beta for et utvalg identity providere. Yihaa!

Les mer og kom-i-gang i dokumentasjonen