Selvhostet utviklingsmiljø

I forbindelse med flytting og ferieavvikling har jeg måtte stue vekk min faste kraftige arbeidsstasjon. Substituttet for denne arbeidsstasjonen har blitt en lettvekter av en bærbar maskin som bedre assosieres med sofa, studier og surfing. Begrensningene tydeliggjøres ytterligere i møte med nødvendigheter som WSL, Docker, VSCode (les Electron), og to-tre-eller-fjorten nettleserfaner med dokumentasjon åpen.

Loddet minne gjør samtidig oppgradering vanskelig, og innkjøp av ny er heller uforsvarlig for et midlertidig problem.

Alternativene 🔗

Heldigvis finnes det flere muligheter basert på SSH å velge mellom som løser mitt problem. Blant annet:

• Utvikling gjennom SSH på en ekstern server på skyplattform, enten cloud eller dedikert.
  • Hetzner tilbyr eksempelvis dedikerte servere til leie fra rimelige €40 per måned (6C/12T, 64 GB minne, 512 GB NVMe SSD).
• GitHub CodeSpaces som tilbyr devcontainere hostet på eksterne virtuelle maskiner. Tjenesten starter på $0.18 per time for 2-kjerner. Lagringsplass koster etter forbruk.
  • Dette kan være et rimelig alternativ for noen med lite brukstid, og som samtidig godtar tid knyttet til opp- og nedkjøring av server mellom bruk. For en hyppig og sporadisk bruker kan derimot dette alternativet fort bli kostbart.
• VSCode Server som er VScode i nettleser hostet eksternt. VSCode Server kan hostes enten lokalt med egen hardware eller gjennom et beta-testing program. Dette er Microsofts visjon for utviklermiljø som knytter trådene mellom produktet VSCode, GitHub og Azure.
  • En hindring som utelukker dette alternativet for min del er mangelen på støtte for devcontainere (per 7. juli 2022). Kanskje er dette løst allerede ved utgangen av året? 🤔

OBS: om du trenger fysisk testing mot hardware er SSH kanskje utelukket.

Kriterier 🔗

• Helst være så rimelig så mulig.
• Raskt og enkelt å koble til og fra.
• Akseptabel ytelse og responstid ved utvikling.
• Kunne utvikle på flere prosjekter parallelt og unngå konflikter knyttet til port-allokasjon.
• Integrasjon med VSCode (løst via Remote-SSH).

Løsningen 🔗

Etter å ha vurdert de foreslåtte alternativene ble løsningen for min å del å kombinere bakteppet til GitHub Codespaces med egen hardware. På denne måten kan jeg bruke den kraftige arbeidsstasjonen som min egen server gjennom SSH. Dette er på ingen måte en revolusjonerende løsning, men samtidig er jeg imponert over hvor enkelt dette lar seg gjøre med dagens verktøy. Løsningen i korte trekk:

• En hypervisor som håndterer virtuelle maskiner.
• En VPN-løsning som åpner for kommunikasjon på tvers av lokale nettverk.
• Bærbar maskin med SSH-tilgang til hypervisor og VMer gjennom VPN.
• VSCode innstallert på bærbar maskin med Remote-SSH.

La meg videre presentere løsningen i nærmere detalj.

Hypervisor 🔗

På serveren (tidligere arbeidsstasjon) har jeg innstallert en hypervisor som enkelt lar meg spinne opp virtuelle maskiner med SSH og docker prekonfigurert vha. cloud init. Hypervisoren jeg har valgt er open-source varianten proxmox, men jeg kunne like enkelt brukt hypervisoren som kommer med Pro-versjonene av Windows, nemlig Hyper-V.

Fordelen med proxmox kontra Hyper-V er for min del et flott GUI, lite overhead og et ensrettet formål. Fordelen ved å bruke Hyper-V vil umiddelbart være å kunne beholde eksisterende Windows installasjon og kjøre dette parallelt.

VPN mellom server og klient 🔗

For å få tilgang til server på et lokalt hjemmenettverk fra en ekstern tilkobling har man typisk to alternativer:

1. Åpne porter på ruteren din (port-forward), — og dersom du ikke har statisk IP-adresse fra ISP opprett DDNS som oppdaterer IP-adressen jevnlig mot et definert domene.
2. Opprett et virtuelt privat nettverk hvor server og klient kan kommunisere. Typisk håndtert ved hjelp av WireGuard.

Ettersom det å åpne porter mot det vide internett mildt sagt er en ikke-triviell sak hva gjelder sikkerhet, valgte jeg alternativ 2.

For å unngå håndtering av autentisering og handshakes selv med WireGuard, gikk jeg for en eksisterende løsning med navn Tailscale. Med gratisversjonen av Tailscale kan jeg autentisere med min GitHub-bruker og videre ta inn maksimalt 25 noder i det virtuelle private nettverket mitt. Heldigvis kan jeg også opprette noder som subnet som lar meg koble til uendelig mange noder på samme nettverk. Det beste av alt, det bare fungerer 🤌.

sudo tailscale up --advertise-routes=192.168.10.0/24,192.168.10.1/24

Konfigurering av SSH 🔗

Det å koble til via SSH er en nokså triviell sak, men jeg vil likevel fremheve noen hindringer underveis.

Den første hindringen var i hvordan SSH-nøkler ikke forwardes til VM på server når jeg bruker Windows på min klient. Dette skyldes ulik implementasjon på tvers av Windows og Unix ved socket. Dette gjør at jeg må konfigurere git for hvert repo, altså kjøre:

git config user.name "endrekrohn" && \
git config user.email "endrekrohn@example.com"

Dette kan løses ved å logge inn på ekstern server via WSL. Dog dette var noe jeg siktet på å unngå i utgangspunktet 😵‍💫. Pytt, pytt. Kanskje er tiden kommet for å enten dual-boote Linux eller gå over til Mac OS.

Den andre utfordringen jeg støtte på var under bruken av reverse-proxy og devcontainer i utviklingen. Dette skyldes bruk av sub-domener i reverse-proxy som gjorde at følgende kommando måtte kjøres manuelt:

ssh -L 127.0.0.1:80:api.localhost:80 <Lokal IP-adresse>

Eventuelt endre i .ssh/config:

Host skript-dev-vm
  HostName <Lokal IP-adresse>
  User endre
  ForwardAgent yes

  LocalForward 3000 127.0.0.1:3000
  LocalForward 8001 127.0.0.1:8001
  LocalForward 8090 127.0.0.1:8090
  LocalForward 127.0.0.1:80 api.localhost:80
  LocalForward 127.0.0.1:80 app.localhost:80

Oppsummering 🔗

For å avslutte denne litt for lange utgreiingen vil jeg poengtere hvor behagelig og moden såkalt remote utvikling faktisk oppleves. Jeg kan nå la flere prosjekter være åpne i bakgrunnen uten å sluke ressurser. Samtidig har jeg en konstant god nettverkstilkobling fra server som gjør innlasting og bygging av docker-images hurtig. Den lokale maskinen holdes også kald, støyfri og rolig under utvikling foruten Electron og minnebruk. Ting er mildt sagt ganske smuuud 😎 (noe noe Murphys law nærme en frist).

Etterhvert som VSCode Server modnes kan jeg se for meg å gå over til web-versjonen av VSCode hostet på et eget domene. Inntil videre har jeg ikke lyst til å gi slipp på devcontainere som gjør denne idyllen umulig. Vi får vente i spenning 🤞.