Vår betasajt (http://beta.di.se) har nu legat ute flera månader och artiklar har varit i ”skarpt” läge för mobilanvändare i drygt en månad.
Betasajten är snabbare och tekniskt mer stabil än den nuvarande, allt för att kunna ge er besökare en bättre läsupplevelse.

Hur kan vi då tekniskt lösa en smidig övergång till webbadressen www.di.se, trots att många nödvändiga sidor och funktioner på nuvarande www.di.se ännu inte existerar på betasajten?  Vi vill alltså kunna länka mellan innehåll på vår nya sajt och innehåll som vi fortfarande vill visa från nuvarande www.di.se utan att besökaren kastas mellan två olika sajter i sin webbläsare.

Svaret är ”reverse proxy”.

Ett sätt för att göra detta på är att sätta upp regler i Akamai som styr vissa webbadresser till nya sajten och andra webbadresser till nuvarande sajten. Vårt devops-team har full koll och erfarenhet på Akamai och dess regelverk, och den erfarenheten säger att detta ofta resulterar i en mängd regelverk som ska konfigureras upp för att samverka med andra redan existerande regelverk och sedan publiceras ut, vilket för Akamai tar cirka en timmes tid innan de nått alla de noder som Akamai använder sig av. Det kan bli ohållbart och svårt att hantera framöver.
Dessutom blir det arbetsmässigt lite mer besvärligt då vi utvecklare överlämnar logik till devops-teamet som vi bäst har koll på, med tanke på att det är vi som vet hur applikationen kodmässigt fungerar och vilka webbadresser vi vill styra om.

Så det vi nu gjort är att vi i vår webbserver (IIS) ska prova att använda oss av de två modulerna ”URL Rewrite” och ”Application Request Routing” för att hantera de inkommande anropen till www.di.se så de landar på rätt sajt – antingen betasajten eller nuvarande sajten.

Application Request Routing

Modulen installeras tillsammans med ”URL Rewrite”-modulen på webbservern och fungerar för alla sajter som är uppsatta på servern.
När det är installerat så har man möjlighet att lägga upp en s.k. serverfarm. Bakom denna serverfarm definierar man upp en eller flera servrar som man med hjälp av olika regler styr sin inkommande webbtrafik till.

Reglerna tillhör ”URL Rewrite”-modulen som man skriver med regular expressions för att matcha ett visst mönster. Matchar det inkommande webbanropet mönstret så styr man anropet vidare till sin webbfarm istället för att släppa igenom det till webbsajten.

Exempel:

Inne i IIS-Manager för vår betasajt har jag nu fått möjligheten att skapa min serverfarm. I nedan exempel så har jag skapat en farm som jag kallar ”farmen”, och i den har jag lagt till en server med ett IP-nummer xxx.xxx.xxx.xxx till vår nuvarande di.se-sajt. Här kan man alltså lägga till vilken/vilka servrar som helst.
Man kan också definiera hur man vill fördela trafiken till dessa, men det är inget jag går in på i detalj här.

iis_farm

Om jag markerar maskinnamnet så har jag nu även en ny ikon för ”URL Rewrite” där jag kan skapa reglerna för inkommande anrop och styra dessa till min nyss skapade farm.

iis_url_rewrite

Nedan en enkel regel som fångar alla inkommande anrop som börjar med ”stockwatch” med kravet att det är för domäner som börjar med ”www.di.se” eller ”di.se”:

iis_rule

Längre ner på sidan kan man sedan ställa in vilken åtgärd som ska tas, vilket i vårt fall är att vi vill omdirigera anropet till vår serverfarm och skicka med den önskade urlen som efterfrågades – variabeln PATH_INFO. Man har även möjlighet att skicka med specifika server variabler om så önskas, t.ex. HOST-header eller liknande som kan behövas för att nå en önskad sajt på det/de IP-nummer som farmen pekar på.

iis_route

Så i ovanstående exempel skulle alla anrop på denna webbserver som kommer in på adressen www.di.se passera utan åtgärd och visas för besökaren förutom www.di.se/stockwatch som regeln då kommer omdirigera till de servrar som serverfarmen pekar mot.

Reglerna bli på detta sätt lätta för oss i utvecklingsteamet att underhålla och framförallt går de snabbt är ändra och uppdatera.

Konfiguration för Octopus Deploy

Att manuellt sätta upp och ändra ovanstående regler på webbfrontarna känns ändå mödosamt och risk för att man råkar göra lite fel på en av dem är stor.
Därför finns möjligheten att scripta dessa regler med hjälp av IIS kommandoradsprogram appcmd.exe vilket i sin tur öppnar upp för att göra det som ett PowerShell-steg i vår releaseprocess i Octopus Deploy. Ett enkelt sätt är att helt enkelt exportera, radera och importera dessa regler under releaseprocessen.

För att exportera de befintliga reglerna i IIS kan man exekvera kommandot:
C:\Windows\System32\inetsrv\appcmd.exe list config -section:system.webServer/rewrite/globalRules -xml > myExportFileName.xml

För radera en regel med ett viss namn:
C:\Windows\System32\inetsrv\appcmd.exe set config -section:system.webServer/rewrite/globalRules /-”[name=’Min regel‘]”

För att importera regler som finns i en XML-fil, t.ex. från en fil som tidigare exporterats:
C:\Windows\System32\inetsrv\appcmd.exe set config -in < myImportFileName.xml

Skulle något av dessa steg misslyckas av någon anledning kan vi meddela Octopus det och releasen stoppas.