Zoals ik in mijn vorige post al vertelde ben ik aan de slag gegaan met het migreren van mijn webserver annex reverse proxy server.
Reverse proxy
Voor wie niet weet wat een reverse proxy is, en dat is geen schande.
Een reverse proxy wordt gebruikt om een interne webserver, die niet rechtstreeks via het internet te benaderen is, op internet te publiceren.
Ook biedt het de mogelijkheid om meerdere websites via 1 publiek IP adres beschikbaar te maken op het internet. Op basis van de URL (hostnaam) wordt het verzoek doorgestuurd naar de juiste (web)server op het interne netwerk.
Toen ik deze webserver destijds ging opzetten leek het mij een goed idee om alle web gerelateerde zaken, zoals WordPress sites en reverse proxy, te combineren op 1 server.
Eigenlijk best simpel, 1 MySQL server waarop alle WordPress databases draaien, 1 HTTP server, met voor iedere website een aparte directory, en alle overige websites via de reverse proxy via diezelfde Apache HTTP server.
Omdat een aantal websites al bestond, was het vooral een kwestie van copy-paste om de configuratie over te zetten.
Ik had beter moeten weten.
Tijdens de installatie destijds ging het eigenlijk al fout. Ik was gewend om al mijn servers te draaien op CentOS, een variant van RedHat Linux die gratis te gebruiken is. En CentOs is inmiddels ook overgenomen door RedHat, maar dat terzijde. De versie die ik op dat moment geïnstalleerd heb was eigenlijk al verouderd. Op zich niet zo’n heel groot probleem, maar updates installeren was bijvoorbeeld al vrij snel niet meer mogelijk, en ook het installeren van de Zabbix Agent, nodig voor de monitoring van de server, lukte niet.
Als ik verstandig was geweest, dan had ik op dat moment al een plan B bedacht.
Maar ik was niet verstandig.
Ik ben doorgegaan op de ingeslagen weg met het idee: ik fix het later wel.
En dat fixen is nu, enkele jaren later.
Ik had simpelweg een nieuwe server kunnen installeren en 1 op 1 alles over kunnen zetten. Maar het leek me ook een goed moment om nog eens kritisch neer het “design” te kijken. Ik had al ervaren dat alles op 1 server best een nadeel is. Zodra de configuratie aangepast werd, en er was daarvoor een herstart nodig, dan raakte dat direct alle web sites. Niet alleen de web site die op de server draaien, maar ook alle web sites die achter de reverse proxy zitten.
Nieuw design
Er moest dus een nieuw ontwerp komen voor de architectuur van de omgeving.
Als het om architectuur gaat, is er vaak niet een beste oplossing. Meestal zijn er meerdere opties met ieder hun voor- en nadelen.
Zo ook in mijn geval. Een enkele server “die alles doet” is afgevallen.
Dan blijven de volgende opties over:
- Aparte reverse proxy server, aparte webserver, aparte MySQL server.
- Aparte reverse proxy server, webserver per website, aparte MySQL server.
- Aparte reverse proxy server, aparte webserver inclusief MySQL server.
Ik heb de verschillende opties de revue laten passeren. Dat de reverse proxy server volledig los moet komen te staan van de web sites was voor mij al duidelijk. Mede omdat een aantal sites al op verschillende servers draaien.
Dan blijft over de keuze voor een centrale webserver en een centrale MySQL server.
Nu geldt natuurlijk, hoe minder servers, des te minder beheer er uitgevoerd hoeft te worden. Maar aan de andere kant, een centrale server betekent ook dat sommige configuratie instellingen voor de hele server gelden, en dus ook invloed kunnen hebben op andere web sites. En wanneer er een herstart nodig is, dat dit meerdere web sites raakt. Datzelfde geldt ook voor een centrale MySQL server.
De uiteindelijke keuze is geworden om voor iedere WordPress site een eigen Linux container te gebruiken. Als reverse proxy wordt niet meer een Apache HTTP server ingezet, maar dit is HAProxy geworden.
HAProxy is een open-source reverse proxy server en load-balancer. Daarnaast biedt het ook de mogelijkheid om automatisch SSL certificaten aan te vragen bij providers zoals Let’s Encrypt. Deze wordt nu ook dubbel uitgevoerd in een cluster setup. Dit betekent dat 1 van de HAproxy servers herstart kan worden zonder dat dit gevolgen heeft voor de web sites. De andere node neemt dan het werk over.
In eerste instantie zijn alle web sites gemigreerd naar een eigen Linux containers en zijn de overige entries uit de reverse proxy over gezet naar HAProxy en zijn alle ssl certificaten omgezet naar Let’s Encrypt. Mijn huidige wildcard certificaat verloopt in december en ik wil het liever niet meer vernieuwen. Niet alleen vanwege de kosten, maar ook omdat de geldigheid teruggebracht is naar 200 dagen en in de toekomst nog verder teruggebracht wordt.
Standaard gebruikt HAProxy een configuratiebestand waar handmatig alles aan toegevoegd moet worden. Toen ik hier mee bezig was kwam ik er achter dat er een additioneel product is, HAProxy-manager, dat een web based interface biedt om alles binnen HAProxy aan te maken en te configureren.
Nadat alles handmatig geconfigureerd was in de tekst based configuratie file, is alles direct gemigreerd naar HAProxy cluster manager.
HAProxy cluster manager heeft bovendien het voordeel dat het een aantal zaken standaard aan boord heeft, die ik eerder zelf allemaal moest regelen via custom scripts, zoals het aanvragen van de certificaten bij Let’s Encrypt en deze vervolgens distribueren naar de andere node. HAProxy cluster manager doet dit automatisch.
Behalve de migratie van de webserver, annex reverse proxy server, is er gelijk nog een aantal andere zaken opgepakt, waaronder het opzetten van een nieuwe Zabbix server voor het monitoren van alle omgevingen. Ik zal daar later nog een aparte post aan weiden omdat daar ook wat maatwerk en aanpassingen in zit.
Migratie web sites
Voor de web site heb ik gekozen voor LAMP containers. LAMP staat voor Linux, Apache MySQL en PHP. Alle producten die je nodig hebt om een WordPress web site op te kunnen zetten. Of in mijn geval, te migreren.
Turnkey biedt een kant-en-klare Linux container hiervoor aan in Proxmox. Echter is deze gebaseerd op Debian 12. Inmiddels is Debian 13 beschikbaar. Het leek mij niet verstandig om te starten met een verouderde versie van het OS. Dat was nu net de situatie waar ik vandaan kwam. Ik heb op basis van deze template een container aangemaakt, deze ge-upgrade naar de laatste versie van Debian, en vervolgens een eigen template gemaakt die ik gebruikt heb om alle containers op te zetten.
Overigens had ik er achteraf spijt van dat ik niet direct de Zabbix Agent in de template meegenomen heb. Deze moest ik achteraf alsnog overal installeren.
Volgende stappen
Het opzetten van nieuwe containers, het migreren van bestaande web sites naar nieuwe containers is een ding. Maar alles up-to-date houden is een ander ding. Oftewel het beheer en onderhoud wan de servers en containers. Zeker in de huidige tijd is het van belang om servers regelmatig te updaten en te voorzien van de laatste software updates, (security)patches en fixes. Nu zijn mijn web sites geen high profile web sites, maar voor sommige kwaadwilligen maakt dat niet uit, die hacken alles wat ze tegenkomen.
Nu kan ik er natuurlijk iedere week een avond voor uittrekken om alles langs te gaan en te voorzien van de laatste updates, en indien nodig, te herstarten. Maar nog handiger is het als dit automatisch gebeurd. Maar dan wel gecontroleerd.
Op de meeste servers en containers heb ik Webmin geïnstalleerd. Webmin is een web-based tool om Linux servers te beheren. Ook kan Webmin automatisch updates installeren. Maar dat gebeurd dan op volkomen willekeurige momenten. En dat is eigenlijk iets dat je niet wil. Vandaar dat ik gekozen heb voor een andere oplossing: Ansible.
Ansible is een product van RedHat da gebruiktwordt voor het centraal beheren van servers. Ongeacht of dit nu Windows of Linus servers zijn. Ansible kan gebruikt worden voor het installeren en updaten van software packages, maar ook voor het aanpassen van e configuratie van software of het OS.
Met Ansible is het relatief eenvoudig om in een keer meerdere servers te updaten, of nieuwe software uit te rollen op groepen van servers of individuele servers. Het vergt wat werk om het allemaal op te zetten, maar eenmaal opgezet pluk je er de vruchten van.
Daarnaast wil ik gebruik maken van een Gitlab server waar de scripts en Ansible playbooks opgeslagen worden, zodat ik versie beheer kan doen op de bestanden.
De Ansible en Gitlab server zijn inmiddels geïnstalleerd, en de eerste stappen zijn gezet voor het opzetten van de benodigde componenten.
To Do
Er is nog een lijstje met een aantal zaken die ik in de toekomst op wil pakken. Er is niet echt een harde deadline wanneer een en ander klaar moet zijn. Wel gaat mijn SSL certificaat, dat op de webmail server gebruikt wordt, in december verlopen. Dit certificaat wil ik voor die tijd vervangen hebben door een Let’sEncrypt certificaat. Op zich niet zo ingewikkeld. Ik kan dit zo configureren op de server. Of ik kan de webmail ook achter de HAProxy plaatsen en daar het certificaat laten beheren. Maar op de server draait ook een IMAP server die zijn eigen certificaten gebruikt. Althans, hetzelfde certificaat, maar geïnstalleerd op een andere locatie. Dat wordt nog een uitzoekklusje.
- Upgraden, dan wel vervangen van de DNS servers.
- Updaten van de Raspberry PI die de slimme meter uitleest.
- Vervangengen van de Oodo sever, een financieel pakket.
- SSL certificaten op de mail\webmail server vervangen door Let’s Encrypt certificaten.
- Upgraden mail gateway.
- Elastic Search installeren en configureren opde wiki server.
