Dynamisk pull request-env med Azure + Bicep

[seanes]

Motivasjon Vi har p.t. ikke deploy til dev/QA-miljø på PR og derfor ingen god måte å vise eller teste endringer før de er merget til main. Ikke skalerbart med push til samme miljø da endringene kan overskrive hverandre.

Mål Flyktig miljø per pull request for å fasilitere QA av feature / fix o.l., i tillegg til test av deployment av branch.

Specs-ish

• Opprettes ved opened, reopened, synchronize
• Bruker de samme eksterne avhengigheter som https://af.at.altinn.cloud/
• Isolert miljø og deler ikke database (Redis og postgres) med andre miljøer
•  🔪 ENV når PR lukkes / avbrytes (closed)
• URL bør være transparent (og kan enkelt genereres), f.eks. PR-id. https://af.at-${id}.altinn.cloud/?

Acceptance Criteria

• Opprettes ved opened, reopened, synchronize og trigges i første omgang ved dispatch av en Github Action ( Kan utvides med knapp i pr-template f.eks)
• Etter ressurser er lagd, skal URL til preview ligger på https://preview-.af.at.altinn.cloud/
• Kun frontend skal opprettes i første omgang Spørs om vi må lage en ny instans av bff også pga. redirect-url 🤔
  • Kun om det er endringer i frontend-package
  • Behold samme miljøvariabler og secrets
  • Må sørge for å lage en ny open-id-integrasjon ettersom vi må hardkode redirect-url?
  • Betyr at vi må bytte ut hostname i BFF

---

Mulig høyst aktuelt også for dialogporten også.

[arealmaas]

Sendt email til ID-porten nå om neste steg for å kunne lage en klient. Vil specce hva det vil si etterhvert, men vil anta at det raskeste er å lage en node-klient, kjøre den som en jobb ved pull-requests.

[arealmaas]

TODO: Spec open-id-integrasjon.

• Kanskje bash-script eller nodejs-app(?) Må ha muligheter til å lage open-id-integrasjon i CI

[arealmaas]

some thoughts.

• Possibility: Expose button to deploy preview-environment in pull requests. Add button to destroy the preview-environment
• Automatically destroy preview-environment when pull request is closed

[arealmaas]

Ser ut som det kan bli ganske knot å legge tilrette for dette i application gateway. Om vi skulle legge til hostname i application gateway for en pull-request vil denne bli overskrevet om vi skulle deploye til Test igjen ettersom hele application gateway er en stor bicep-modul. Om application gateway hadde kunnet blitt brutt opp hadde problemet vært løst, men det er dessverre ikke tilfellet.

En annen løsning er å lage et eget container app environment i Test som ikke er lukket i et subnet som kun skal bli brukt av flyktige miljøer..

Potensiell spec:

• Lag et åpent "preview"-container app environment i Test.
• Ved ny pull request, deploy bff og frontend i det nye environmentet med parametre som ligger i soak.bicepparam.

[arealmaas]

Thoughts after experimenting with new container app environment:

Set up a new container app environment for ephemeral use in test subscription. https://github.com/digdir/dialogporten-frontend/pull/990 It has it's own issues as we do not have a reverse proxy anymore. I see a couple of possible paths here:

• Support cross-origin requests from FE => BFF. If we do this, we have a working solution in the PR.
• Add a reverse proxy container as a part of the deployment and use that instead of the application gateway. This will require us to add an nginx container per version of bff/frontend that is deployed.
• Create a fat docker-image with both frontend and bff. Add a simple nodejs-server which redirects /api-traffic to the bff and other traffic to frontend.

[arealmaas]

After refinement 20th November, we landed on "putting a pin" in this until we can establish the goals for the ephemeral environments