Inleiding
Naast de vele ingebouwde pakketten, is het mogelijk om op de zwaardere Synology NAS Servers (voornamelijk de plus-modellen, de lijst kan hier gevonden worden) ook Docker-containers te hosten. Dit soort containers zijn ideaal om extra stukjes software toe te voegen en beschikbaar te maken, er zijn duizenden containers beschikbaar. Heel wat van die containers zijn bereikbaar via een web-interface, maar dan moet die natuurlijk wel van buitenaf bereikbaar zijn, en dat is soms niet eenvoudig. In dit artikeltje willen we iedereen wat op weg zetten hoe dit aan te pakken.
1. Installatie van de container
Aangezien er al heel wat collega’s zijn die de installatie van Docker-containers uitgebreid beschreven hebben, zullen we hier niet teveel op ingaan. Heb je een container ontdekt die je graag zou willen hosten, probeer dan eerst even te zoeken of Mariushosting hier toevallig geen handleiding voor geschreven heeft. Deze zijn normaal gezien up-to-date en eenvoudig te volgen, zodat u in 1-2-3 de container binnen uw netwerk beschikbaar hebt.
2. Poorten
Eén belangrijk concept bij het hosten van verschillende pakketten is het gebruik van poorten. Een poort op een Synology NAS Server is als een deur in het huis: Hij laat toe om naar één bepaalde kamer te gaan. Als er verschillende kamers rechtstreeks bereikbaar moeten zijn, dan zijn er ook verschillende deuren nodig, en dit zijn de zogenaamde poorten.
Standaard wordt een webserver op poort 80 (http) en poort 443 (https) beschikbaar gemaakt, maar deze poorten zijn bij een Synology NAS Server al ingenomen door de Reverse Proxy (waarover later meer) of de webserver. Als er dus een Docker-container wordt toegevoegd, dan moet als deel van de installatie een unieke, beschikbare, poort gekozen worden. Wat ik altijd aanraad is om een poort te kiezen in de hogere ranges, zoals 28080, 28081, 28082, enz, want deze zijn meestal nog niet in gebruik en zo is het duidelijk dat dit over poorten gaat die door containers worden gebruikt. Eens een container goed is opgestart op zo’n unieke poort, dan is het pakket normaal gezien bereikbaar via http://<ip-van-de-nas>:<unieke-poort>
=> Als er een poort gekozen wordt die wél al gebruikt is, dan zal de installatie van de container een fout geven, dan is het een kwestie van een andere poort te selecteren en opnieuw te proberen.
3. Reverse proxy
In het vorige punt werd een unieke poort gekozen en terwijl de service daarmee op die poort bereikbaar is, is dit verre van handig of “mooi” als die service ook vanop internet gebruikt wordt. Makkelijker is om te zorgen dat we die unieke poort bereikbaar maken via een uniek (sub-)domein, bijvoorbeeld <mijn-containernaam>.<gekozen-naam>.synology.me (op de standaard-poort 443). Om dit te doen, moeten we gebruikmaken van een reverse proxy, een soort van poort-wachter aan de voordeur, die bezoekers rechtstreeks naar de correcte binnendeur doorstuurt. Synology heeft een ingebouwde reverse proxy en de handleidingen van Mariushosting zal de configuratie hiervan vaak al bevatten, dus we zullen dit hier niet herhalen.
Wel vermelden we nog even dat er ook alternatieve reverse proxy-pakketten gebruikt kunnen worden, zoals de Nginx Proxy Manager, aangezien die soms meer functionaliteiten aan boord hebben dan die van Synology. Wel belangrijk om te vermelden is dat deze niet op poort 443 kan worden opgezet maar een andere poort nodig heeft (bijvoorbeeld 8443), in het volgende puntje lichten we toe hoe dit voor de gebruikers van buitenaf dan toch transparant kan zijn.
4. Port-forwarding op de router
Een reverse proxy zal er dus voor zorgen dat we gebruik kunnen maken van de standaard https-poort (443) en van onze eigen domeinnaam om onze containers individueel bereikbaar te maken. Uiteraard moeten de bezoekers nog van buitenaf tot aan de Synology NAS Server raken, hiervoor maken we gebruik van port-forwarding. Het instellen van port-forwarding is op elk merk van router anders, maar zo goed als elke zelf aangekochte en elke provider-geleverde router biedt deze functionaliteit aan. Om dit te laten werken, moet de poort 443 op de router (de voordeur) worden doorgestuurd naar dezelfde poort 443 op de Synology NAS Server (de binnendeur) als er gebruik gemaakt wordt van de Synology Reverse Proxy.
Maar hoe zit dat dan met die alternatieve Reverse Proxy? Hiervoor maken we gebruik van een trucje door poort 443 op de router door te sturen naar de poort die we aan de reverse proxy hebben toegekend op de Synology NAS Server, bijvoorbeeld 8443. Van buitenaf verbinden bezoekers dan naar 443 maar binnenin ons netwerk wordt dit gestuurd naar 8443, waardoor de reverse proxy dit kan oppikken om door te sturen naar de finale bestemming op de unieke poort van de container (bijvoorbeeld 28080). Dit lijkt een heel complex gegeven maar eens dit eenmaal staat ingesteld, dan moet er bij het aanmaken van een nieuwe container, enkel op de reverse proxy een configuratie worden toegevoegd.
5. SSL
Vandaag de dag is het absoluut noodzakelijk om een container die van buitenaf bereikbaar wordt gemaakt, te configureren met een SSL-certificaat, waardoor de connectie tussen de bezoeker en de server versleuteld is. Dit certificaat wordt aangemaakt en gebruikt op de reverse proxy, en meestal wordt er gebruik gemaakt van een Let’s Encrypt-certificaat. Voor de Synology Reverse Proxy wordt dit certificaat ingesteld in het DSM Controlepaneel => Beveiliging => Certificaat, waarbij een <gekozen-naam>.synology.me-certificaat meteen ook bruikbaar is voor elk subdomein (dus ook voor <mijn-containernaam>.<gekozen-naam>.synology.me). Wordt er een andere domeinnaam gebruikt, dan moet hiervoor een apart certificaat worden aangemaakt, we gaan hier nu niet verder op in maar helpen u hiermee graag verder indien dit niet lukt!
Wordt er gebruik gemaakt van een alternatieve Reverse Proxy, dan worden certificaten meestal daarin aangemaakt, de voornaamste opmerking is dat de domeinnaam zal moeten werken (cfr het vorige punt over de port-forwarding) vooraleer een certificaat kan worden aangemaakt.
Tot slot
Hoewel handleidingen en online instructies focussen op het draaiend krijgen van de eigenlijke container, zit de moeilijkheid meestal in de netwerk-instellingen om de bezoekers tot op die container te krijgen. Ook al hopen we dat bovenstaande punten wat hints kunnen geven, toch is het samen bekijken van de unieke configuratie van het netwerk soms noodzakelijk om dit in orde te brengen.
=> Wij hebben uitgebreide ervaring met het gebruik en bereikbaar maken van Docker containers en vaak kunnen we dan ook snel de nodige instellingen goed zetten, neem zeker contact op als u ergens vast zit en wij u kunnen helpen om uw probleem op te lossen!