The Gathering Technical blog KANDU:Systemstøtte

Intro: Webservere og slikt

Om du fulgte med veldig nøye på ettermiddagen søndag 3. mars så la du kanskje merke til at www.gathering.org var utilgjengelig i en liten stund. Perioden med nedetid var varslet i god tid i forveien (ca 30 minutter) slik at alle i crewet visste hva som foregikk (her kommer altså forklaringen så alle i crewet vet hva vi gjorde).

Historien begynner med at noen små og store nerder satt samlet på Frivillighetshuset i Kolstadgata 1 i Oslo. KANDU:Systemstøtte hadde hatt møte dagen før og vi hadde blitt enige om at vi måtte gjøre noe med hvordan www.gathering.org fungerte. Før vi begynte bestod nettsiden av en server med en salig blanding av Apache, Varnish, WordPress, og vår egenutviklede Node.JS baserte web API. Konfigurasjonen var så komplisert at var lett å gjøre feil som kunne være vanskelige å nøste opp i. Vi bestemte oss derfor å bygge alt opp på nytt igjen. Dette er forklaringen på hva vi endte opp med, og en intro til hvordan det fungerer.

HTTP og HTTPS

Når du åpner en nettside med alle moderne nettlesere så benytter du en protokoll som heter Hypertext Transfer Protocol (eller bare HTTP). Protokollen håndterer å hente og sende informasjon til nettsider på en standardisert måte. Du har sikkert lagt merke til at foran de fleste linker så står det noe lignende http://example.com. Dette er en instruks for nettleseren om å prøve å nå example.com over http protokollen.

Det eneste problemet med protokollen er at alt du sender over den er fullt leselig for alle som lytter. Noen glupe hoder fant ut at om du legger til en S på slutten av HTTP så får du HTTPS, og "S"en står for "Secure". Når nettleseren prøver å nå serveren så blir de enige om en felles krypteringsnøkkel slik at de kan kommunisere med hverandre uten at andre kan se hva som blir sendt. Metoden heter Diffie-Hellman key exchange (DH) og du kan lese mer om den her.

Før vi bygget om stacken vår så var det Apache som hadde ansvaret for å ta imot HTTPS tilkoplinger, men det var lett å lage redirect looper mellom Apache og Varnish (hvor nettleseren din blir sendt frem og tilbake mellom Apache og Varnish i all evighet) så vi valgte en annen metode. Vi installerte Hitch på serveren og konfigurerte den til å bruke et SSL/TLS sertifikat fra Let's Encrypt. Hitch gjør ingenting annet enn å ta imot tilkoblingen, dekryptere den og sende forespørselen videre til neste ledd i prosessen.

Caching og reverse proxy

Nå som Hitch tar imot HTTPS så trenger vi å route forespørslene til riktig sted. Til det installerer vi Varnish. Varnish er egentlig en webcache, men programvaren har mange kraftige funksjoner som gjør det praktisk å bruke den som en proxy også.

Siden www.gathering.org består av to forskjellige biter i bakgrunnen trenger vi å proxye (videresende) alle forespørsler for https://www.gathering.org/api til WordPress, mens resten går til en Node.JS basert applikasjon på https://www.gathering.org/tg19. Fordelen med en reverse proxy her er at du som bruker av nettsiden bare trenger å forholde deg til en webadresse, mens webserveren som tar deg imot kan benytte mange tjenester i bakgrunnen uten at du legger merke til det.

Men hva er en cache? En cache er et mellomlager mellom deg og nettsiden som gjør responsen fra nettsiden raskere. Når du kobler til en webside så må webserveren generere en versjon av nettsiden for deg. Dette kan være en tung oppgave og kan ofte være treg. Det cachen gjør er å ta vare på en kopi av nettsiden, så når neste person spør om samme nettside så svarer Varnish bare med den mellomlagrede kopien istedenfor å la webserveren generere en helt ny en. Dette fungerer bare en liten stund, for etterhvert så endrer jo innholdet på nettsiden seg når det blir publisert nye artikler og slikt, så Varnish kan bare mellomlagre sider i maksimalt noen minutter. Kanskje bare så lite som noen sekunder hvis innholdet endrer seg fort. I www.gathering.org sitt tilfelle så lagrer vi dataen ganske lenge for vi har satt det opp slik at dersom noe innhold endrer seg så sendes det en beskjed til Varnish om å slette den mellomlagrede kopien.

Hva skjer etterpå?

Nå som forespørselen er kommet gjennom Hitch og Varnish så ender den enten opp direkte i vår Node.JS applikasjon eller så treffer den Apache som leverer Wordpress siden. Totalt sett så ser arkitekturen vår slik ut.

Webserver arkitektur for www.gathering.org

Hvordan vi bruker Wordpress og vår egenlagde frontend kommer vi nok tilbake til i en senere bloggpost (og kanskje kan du få tatt en titt på koden?).

Wannabe - hva er det egentlig?

Wannabe er et evig mysterium. En stor dinosaur med svære misfostrede armer og bein, en ekstra hale og noen store, unormale kuler. Kort fortalt så er Wannabe TGs "management-system" for frivillige.

Wannabe?

De fleste kjenner nok Wannabe som det systemet der man søker seg inn i crewet på TG. Fyller ut side opp og side ned med utrolig finskrevet og bearbeidet tekst, i håp om at man kanskje endelig kommer inn i crewet, eller i håp om at man får fortsette å være med. (misforstå meg rett her, vi trenger maange i crew). Systemet lar deg så vente, noen venter litt, andre venter lenge. Og plutselig en dag får man en slik velkomst-mail fra Wannabe om at "tjohei, kom å bli med i crew, da!". Da har Wannabe gjort sitt for deg, tenker du. Nå er Wannabes funksjonalitet for deg bare en enkel liste over hvem du er crew-buddies med.

Men hva ANNET brukes Wannabe egentlig til?

Som du sikkert las øverst så er Wannabe en dinosaur. Og med det så menes det at på et eller annet tidspunkt ble bestemt at alt skal styres fra Wannabe. Du har naturlige funksjoner som hører til i Wannabe, som behandling av crew og søknader, utsendelse av SMS, epostliste-administrasjon, oppmøte, ernæring og medisinsk informasjon og lignende. Men så har du jo også ting som Logistikk-systemet til TG, lost and found, Akkrediterings-modul, sovekart og styring av infoskjermer.

Det betyr at: en deltaker har mistet noe, hva gjør crewmedlemmene som skal sjekke etter det? De bruker Wannabe. Når en skal dele ut akkreditering til en journalist, hva må du gjøre? Logge deg på Wannabe. Du vil oppdatere sovekartet? Logg deg på Wannabe. Få ut informasjon til deltakerene via de mange info-skjermer? Logg deg på Wannabe.

Et flott kaos..

Du må virkelig ikke misforstå meg her, fordi Wannabe er et veldig bra system, med sin egen lille sjarm. Det er bare en dinosaur. Og som alle andre dinosaurer så er de svære, vanskelig å ha med å gjøre og trøblete å ha oversikt over. Men det funker! Wannabe fungerer, gjør det det skal og bare tråler videre.

Systems sin oppgave i dette

Vi er jo Systems, og vi skal ha kontroll på dette. Vi administrerer alle modulene, oppdaterer de, vedlikeholder de og gir de den etterlengtede kjærligheten de trenger. Vi gjør også andre ting, som å gi tilganger og godkjenne profilbilder.

Wannabes fremtid

Det som er "inn" i dag er jo mikrotjenester, la frontend skrike til backend igjennom et RESTful API, som naturligvis er stateless og famler i mørket. Det er nok også dit Wannabe skal, om noen år. Segmentering av tjenestene som Wannabe tilbyr er nok en av de beste veiene å gå. En egen liten by av docker-konteinere som snakker sammen og samarbeider i harmoni for å gi brukeren det en måtte ønske. Ahh, for en flott fremtid..

Og til syvende og sist så prøver vi bare å ha system..

get it? Systems, system? Eh....

Vi ses på TG!

Labels: Blog, Wannabe

A sign of life...

Hello!

This year, the Info:System has had some major changes. The structure of The Gathering has been changed, and in that process the Info:Systems crew has been renamed Core:Systems (read more about the change here, in Norwegian..). Oh, and another thing, no one from the old Info:Systems crew is participating this year. That means the entire Systems crew is new blood. Of course, this is not without some challenges.

Christian, aka lizter, has been so nice to help with the transition. He has been with the old Info:Systems crew for many years and has a lot of information and experience that we in Core:Systems really appreciate. Together with reading code, understanding documentation and sorting through config files, we have managed to somewhat get control over the potentially messy situation. I mean, everyone with some programming and/or IT-background knows it can be a messy thing to take over the work of a group of people.

We are pretty sure TG17 will be a really nice experience for all of us new bloods, and we really hope that the transition has not been too obvious. Well... Apart from closing down the forum. And did you notice the front page has SSL now? More on that later!

Labels: Blog, Systems TG17

About

TG - Technical Blog is the unofficial rambling place of the Info:Systems, Tech:Net and Tech:Server crews from The Gathering.

Related sites

Collaborators