Nginx

Als webserver draaien we Nginx. Nginx is in staat op SSL af te handelen, bestanden via HTTP uit te serveren en requests naar andere server(s) sturen. Daarnaast is Nginx zeer goed in staat om responses te cachen voor een volgende bezoeker, een eigenschap waar we dankbaar gebruik va maken.

Configuratie

Er zijn drie site-configuraties actief, een voor kc-xbrl.cooljapan.nl, eentje voor alle andere requests die per ongeluk bij nginx komen (op ip-adres, interne trans-ip-naam) en eentje special voor een domein dat ons ip-adres claimt. (nothing we can do about it).

nginx.conf

Naast de gebruikelijke defaults staan er een paar aanwijzingen in het bestand die voor ons van belang zijn. Zo werken we met een niet-standaard log-formaat, aanpassingen die je hier doet zal je ook moeten doorvoeren bij goAccess. Het logformat robots wordt alleen gebruikt voor niet standaard access-logging.

De andere belangrijke regel is

proxy_cache_path  /var/cache/nginx/  levels=1:2    keys_zone=STATIC:50m inactive=365d max_size=50G; 

Waarin we nginx de opdracht geven om 50GB aan schijfruimte in /var/cache/nginx te gebruiken om responses te cachen. Dit is op dit moment voldoende, maar zal in de toekomst ontoereikend blijken.

### 00-kc-xbrl De server is geconfigureerd in /etc/nginx/sites-available/00-kc-xbrl. Hierin wordt de routing gedaan voor de verschillende paden die requests kunnen hebben. Alle requests met /api vooraan in het pad zullen naar de toolkit-API worden omgeleid. Tenzij het request uit cache kan worden geserveerd, dan geeft nginx direct antwoord.

Speciale aandacht voor /api/admin we willen niet dat die responses worden gecachet. Deze gaan dus altijd naar de toolkit-API. Dit is omdat we hier de toestand op de server kunnen aanpassen en we dus altijd een response willen hebben die de huidige toestand reflecteert.

Het kan voor komen dat je een aanpassing hebt gedaan aan de API-output, en dat dus een make rebuild_cache nodig is om de aanpassing ook zichtbaar te maken op het web. Dit is echter een zeer tijdrovend proces, dus wil je zeker zijn dat je aanpassing goed werkt. Omdat in de configuratie voor /api de volgende regel is opgenomen:

proxy_cache_bypass $http_x_cache_refresh;

Je kan hierdoor de cache van één pagina verversen door met het request een extra header mee te sturen. Met het command line tool httpie zou zo'n request er bijv. zo uit zien:

http https://kc-xbrl.cooljapan.nl/api/nt_versions X-Cache-Refresh:Please

De locatie /api/get_log heeft een eigen configuratie. Aangezien deze elke vijf seconden pollt, zou dit request heel vaak in de logs terecht komen. En daarmee onze goAccess statistiek nagenoeg onbruikbaar maken. Als oplossing heb ik er voor gekozen dit request niet te laten loggen.

Tot slot, de directorie /nta/version_compare is opvraagbaar met een file-listing, zodat er buiten de admin om door de rapporten kan worden kan worden geklikt door niet-ingelogde gebruikers.

Geen 404's

Wat misschien opvalt, in de serverlogs komen (tegenwoordig) geen 404's meer voor, en dat terwijl er genoeg niet bestaande url's worden opgevraagd. Dit heeft te maken met Vue, het javascript framework waarmee de taxonomy-viewer is geschreven. Elk request dat niet op schijf gevonden kan worden sluizen we door naar de viewer, die kan vervolgens besluiten de gebruiker een 404 pagina te laten zien, maar de response status in nginx zal 200 registreren, we hebben immers index.html als geldig antwoord teruggegeven.

HTTPS

Uiteraard wordt de site via https verstuurd, requests op http worden doorgezet naar https indien de hostname correct is. In alle andere gevallen (voornamelijk scans op ip-adres) verdwijnen ze in een andere logfile op een lege site.

Cache

De API is traag. En de responses zijn soms erg groot, van enkele megabytes to honderden megabytes. Om de traagheid van de toolkit te reduceren werken we met cache op de webserver, een eenmaal opgehaalde respons van de API-server wordt op schijf bewaard. Alle volgende clients krijgen deze gecachte versie als response. Hier zul je je van bewust moeten zijn, de API response is niet per se de meest recente response van de API-server. 1. Je hebt een nieuwe taxonomie ingelezen 2. Je hebt de response van 1 (of een klein aantal) pagina's aangepast. 3. Je hebt een programmawijziging doorgevoerd die de API-response (van pagina, paginatype, veldje toegevoegd ..) verandert

In het geval van een nieuwe taxonomie; de admintool is zo ingericht dat direct nadat er een taxonomie is opgeslagen in de database er een crawler wordt gestart die alle 'zware' nieuwe responses opvraagt en in de cache zet.

Je kan de cache van 1 of meerdere pagina's geforceerd verversen. Stel dat je de response van https://kc-xbrl.cooljapan.nl/api/nt-versions niet uit cache maar van de server hebben, dan kan je aan je request een extra header http_x_cache_refresh meesturen.

curl --header 'Host: kc-xbrl.cooljapan.nl' --header 'X-Cache-Refresh: 1' 'https://kc-xbrl.cooljapan.nl/api/nt-versions' 

In geval van 3 zit er niets anders op dan de hele cache weggooien en een nieuwe opbouwen. Ook hierin voorziet de toolkit, er staat een procedure klaar die alle API responses aanroept.

/app/kenniscentrumxbrl$ make rebuild_cache