Beste klant/collega,

(Is dit bericht niet goed leesbaar? Bekijk dan de online versie.)

Wij vragen aandacht voor het volgende:

1. Nu ook reguliere software updates voor CHP
2. End of Life van Postgresql-9, Ruby-2.6, PHP-7.3 en Node.js-12
3. Aanpassing webproxies appcluster
4. Reguliere software updates

Deze maandelijkse software update aankondigingen waren vooral gefocussed op de klassieke NPO hosting omgeving, “het appcluster”. In de nieuwe omgeving, het Cummunity Hosting Platform draait natuurlijk net zo goed software, alleen daar is het een beetje anders georganiseerd. De software die je daar draait wordt bepaald door het image dat je kiest in je container. Het is daarbij mogelijk om willekeurige images van het internet te downloaden, bijvoorbeeld vanaf Docker Hub en het is mogelijk om bepaalde door NPO team Hosting&Streaming onderhouden images te gebruiken.

Helaas hebben we moeten constateren dat het “onderhoud” van H&S op die laatste categorie een beetje een ondergeschoven kindje was. Er was nog geen proces om deze images ook regelmatig te updaten, waardoor er bijvoorbeeld erg lang oude php-fpm en nginx images aangeboden werden.

Dat gaat vanaf nu verbeteren. De CHP images worden nu ook meegenomen in de maandelijkse software udates. Het betreft de volgende images:

De nieuwe images komen steeds beschikbaar gelijk met de updates in de appcluster testomgeving en kunnen vanaf dat moment gebruikt worden.

Anders dan in het appcluster is er in CHP nu nog geen moment waarin er vanuit H&S actief updates gedaan worden. Als je in je container de “latest” tag gebruikt dan worden deze images vanzelf opgepikt als er een nieuwe container gestart wordt. We moeten ons nog beraden wat we doen met oude images. Het ligt in de lijn der verwachting dat we oudere versies ook in CHP actief willen gaan updaten. Het punt is alleen dat containers expliciet kunnen zeggen welke versie ze exact willen, wat betekent dat zo'n container stuk zou gaan op het moment dat die exacte versie verwijderd wordt. In de nabije toekomst willen we containers gaan scannen op eventueel gebruikte verouderde software versies en zorgen dat de gebruikers hier notifies van krijgen.

In Q3 2021 en Q1 2022 zijn zowel Postgresql-9 als Ruby-2.6 als PHP-7.3 als Node.js-12 End Of Life Het is dus van belang om voor die tijd te upgraden naar een nieuwere versie.

Omdat dit bijna samenvalt met het EOL moment van het appcluster zelf (31 dec 2021) is het belangrijk om hier even goed rekening mee te houden met een eventuele migratie naar CHP.

We houden nog in beraad of er een uitzondering voor postgresql-9 gemaakt gaat worden. Dat is EOL op 11 november 2021, 6 weken voor de EOL date van het appcluster zelf. Omdat databases als postgresql niet direct zelf vanaf het internet benaderbaar zijn, maar alleen maar via de applicatiecode die ertussen zit, is het mogelijk dat het risico aanvardbaar geacht wordt om dit aan te bieden tot 31 december 2021, maar dat is dan minimaal op voorwaarde dat de EOL date van het appcluster niet naar achteren gaat schuiven.

In CHP is het overigens theoretisch mogelijk om zelf verouderde software te draaien. Er is niets dat je weerhoudt om zelf bijvoorbeeld een image met een verouderde PHP versie samen te stellen, maar vanuit H&S zullen we onze eigen images niet post-EOL aanbieden. We raden natuurlijk ten sterkste af om in CHP verouderde, unmaintained software te draaien.

Verder wijst de praktijk uit dat het vaak niet verstandig is om zelf afhankelijkheden te creëren in de vorm van “we bouwen een nieuwe website, op basis van een nieuwe PHP en die draaien we dan ook meteen in een nieuwe omgeving”. Op die manier heb je jezelf te pakken als bv het bouwen van de nieuwe website uitloopt, of als de migratie naar de nieuwe omgeving tot lastig bleek te zijn.

“Divide and conquer” werkt in dit soort gevallen vaak beter. Bouw vooral die nieuwe website, maar maak dat niet afhankelijk van een migratie naar CHP. In CHP en op het appcluster bieden we dezelfde software versies aan, dus het is heel goed mogelijk om een “laterale” migratie naar CHP te doen, zonder dat daar een nieuwe website oid onder hoeft te hangen. Andersom ook, in het appcluster kunnen alsnog diverse nieuwere software versies aangeboden worden (denk bijvoorbeeld aan php-8 of postgresql-13) waardoor je ook in het applcuster eerst zou kunnen upgraden en daarna migreren naar een andere omgeving.

In het appcluster zitten er om zowel performance als security redenen webproxies tussen aan de ene kant de gebruikers op het internet en aan de andere kant de plek waar de applicatiecode draait. Een gevolg hiervan is dat de applicatie code geen directe TCP connectie met de eindgebruiker op het internet heeft, maar inplaats daarvaneen TCP connectie met de webproxy. En die webproxy onderhoudt de TCP connectie met de eindgebruiker. Deze constructie zorgt ervoor dat als je bijvoorbeeld in PHP het directe IP adres van een connectie opvraagt (REMOTE_ADDR in PHP) je niet het IP adres van de eindgebruiker ziet, maar een ander adres. (het IP adres van de eindgebruiker is overigens wel op te vragen door naar X-Forwarded-For te kijken, want die wordt door onze proxies toegevoegd).

Dat “andere” adres wat je ziet in REMOTE_ADDR gaat veranderen. Voorheen was dat het IP adres van de server waar de proxy op draait. Dit wordt nu het eigen IP adres van de proxy zelf.

De reden voor deze verandering is dat als een proxy heel veel connecties richting een applicatieserver maakt er in bepaalde gevallen een tekort aan TCP connecties kan ontstaan als daarvoor het server adres gebruikt wordt. Door het eigen proxy adres te gebruiken kunnen meerdere proxies die op dezelfde server draaien elkaar in dit opzicht niet meer in de weg zitten en is de kans op een tekort aan TCP connecties veel lager.

Zo heel veel verschil zal de applicatiecode naar verwachting overigens niet zien. In de meeste gevallen was dit voorheen al een vrij cryptisch IPv6 adres. Voor apache proxies iets dat eruit zag als 2a02:458:101:28:100:*, dat blijft zo, het wordt alleen een ander cryptisch adres, dat er dus ook weer uitziet als 2a02:458:101:28:100:*. Voor nginx proxies (in geval van php-fpm) zag het IPv6 adres er voorheen uit als 2a02:458:1fe:1ac:100:*, dit wordt nu iets als 2a02:458:1fe:1ac:200:*.

Deze wijziging wordt op maandag 10 mei doorgevoerd en heeft geen impact op de beschikbaarheid van websites.

Het software update rooster voor de komende tijd ziet er als volgt uit:

De updates worden op 30 april op het testcluster doorgevoerd, waarna de week van 3–7 mei gebruikt kan worden om te testen. In de periode van 10–12 mei worden de updates op de productie-omgevingen doorgevoerd volgens onderstaand schema:

Veel software kan zonder, of met heel weinig impact ge-update worden. Voor deze zaken kiezen we ervoor om zo'n update overdag uit te voeren. Bij een aantal andere componenten is er iets meer impact merkbaar. Die voeren we uit in een nachtelijks change window. Hieronder is de impact genummerd van 0 (geen impact) via 1 (korte onderbreking van enkele seconden) tot 2 (onderbreking van enkele minuten op de dienstverlening). De tijdstippen zijn als volgt:

Team Hosting&Streaming is gedurende al het onderhoud via de normale kanalen bereikbaar. Zie de contact pagina.