# Automatiserte klargjøringen av en server nummer to hos en annen skyleverandør, der brannmuren opprettes før maskinen slik at den blir født bak en, og begge leverandørenes brannmurer er skrevet direkte mot deres REST‑API‑er for å slippe en collection fra tredjepart.

september 2026

**Situasjon.** Det trengtes en maskin til for et applikasjonslag, hos en annen leverandør enn den første, og den første maskinens egen historikk var argumentet for hvordan det skulle gjøres: den var opprettet for hånd, og brannmuren var lagt til etterpå, noe som etterlater et vindu der en fersk vert med en standard passordpolicy kan nås fra internett.

**Oppgave.** Maskinen måtte opprettes fra repoet, og den måtte bli født bak brannmuren sin i stedet for å få en kort tid etterpå.

**Handling.** Rekkefølgen var bærende for designet. Brannmur‑playet kjører før server‑playet, slik at regelsettet finnes før det er noe for det å beskytte; hos den andre leverandøren kjører taggingen før skybrannmuren, fordi en brannmur som retter seg mot tagger, trenger at taggene finnes først. Begge leverandørenes brannmurer er skrevet direkte mot REST‑API‑ene deres gjennom en generisk HTTP‑oppgave i stedet for gjennom en collection fra leverandøren, og det fjerner en avhengighet og versjonsdriften dens, på bekostning av at formen på forespørslene må skrives for hånd. Rollen som oppretter maskinen, tar over en eksisterende maskin i stedet for å duplisere den hvis den allerede finnes, så det er trygt å kjøre på nytt. Den er også dokumentert, i sin egen fil, som den ene rollen i repoet som bruker penger — instanstypen, regionen, spesifikasjonen og den månedlige kostnaden i euro er skrevet ned, fordi et play som fakturerer noen, bør si det der de kommer til å lese det. Det playet er også det som ikke kan øves på den vanlige måten: den generiske HTTP‑oppgaven deklarerer ikke støtte for check mode, så en tørrkjøring hopper over hver oppgave i det. Øvingen gjøres i stedet mot brannmur‑playet, som er gratis og reversibelt.

**Resultat.** En ny vert kan opprettes, eller tas over på nytt, fra repoet, bak en brannmur som allerede finnes, til en kostnad filen oppgir. Det ene en tørrkjøring ikke kan dekke, er navngitt i den samme filen i stedet for å bli liggende som en overraskelse.

---

- Rolle: Ingeniør for infrastrukturautomatisering
- Kategorier: [API‑er og integrasjon](https://engineer.company/nb/categories/api/), [Infrastruktur](https://engineer.company/nb/categories/infrastructure/), [Skytjenester](https://engineer.company/nb/categories/cloud/), [Automatisering og CI/CD](https://engineer.company/nb/categories/automation/), [Sikkerhet](https://engineer.company/nb/categories/security/), [Python](https://engineer.company/nb/categories/python/)
- Tjenester: [Skyinfrastruktur og migrering](https://engineer.company/nb/services/cloud-infrastructure/), [Infrastruktur som kode](https://engineer.company/nb/services/infrastructure-as-code/), [Nettverk og VPN‑oppsett](https://engineer.company/nb/services/networking-vpn/), [Sikkerhet og tilgangsstyring](https://engineer.company/nb/services/security-access/)

<https://engineer.company/nb/portfolio/provisioned-a-second-server-from-code-123/>
