Nginx Proxy Manager/systeem inrichting.

[prutser001]

Hallo,

Wist niet of dit het juiste forum was om dit te vragen, indien dit het geval is mijn excuses.
Gezien ik Ubuntu Server 2404, en Nextcloud als onderwerp heb dacht ik zo goed te zitten.

Ben al een paar weken bezig met de volgende software :
Ubuntu server 24.04, Apache2->Nextcloud+MySQL (LAMP installatie) - AdGuard en WireGuard. Collabora->draaide in Docker.
Docker met de volgende containers:
Collabora : collabora/code
Unifi Controller/MongoDB 5.0 : ghcr.io/goofball222/unifi (Gebruikte eerst een andere maar die ging elke keer op 'Unhealthy' deze doet het al een week goed).
Home Assistant : linuxserver/homeassistant:latest
Portainer : portainer/portainer-ce:latest
Nginx Proxy Manager draait op truenas scale als app/docker.

Eerst wat uitleg over de huidige situatie.
Nextcloud draait op Ubuntu Server 24.04 (192.168.1.2) met MariaDB/MySQL, SSL geactiveerd gekregen na veel gedoe voor zowel Nextcloud als Collabera met nc.domein.eu en collabera.domein.eu. Hier gingen poort 80/443 eerst naartoe.
Adguard en Wireguard werken, en werken samen. Al het VPN verkeer gaat via Adguard en de rest van mijn
netwerk ook. Om eerst via 'domein namen' overal bij te kunnen komen met AdGuard DNS rewrites gedaan naar b.v. adguard.domein.eu welke ook als CNAME in Cloudflare staat. En andere, Truenas.domein.eu, homeassistant.domein.eu, unifi.domein.eu, router, switch noem maar op. Wilde dan via een lokale website (Op IIS WS2025) alle links erin zetten en zo bij de juiste apparaten uitkomen.

n.b. WS2025 loopt al moet alleen nog in 'productie' worden gezet AD/DC/DHCP/DNS/IIS/CA.

Op dit moment draait Nginx Proxy Manager als app op Truenas Scale 192.168.1.5. maar heeft dus poort 80/81/443 nodig.
Na een poging of 5 om Nextcloud zo te krijgen als ik wilde, met HTTPS (Nextcloud talk/notes/passwords en Collabera) en later een update/bug die alles om zeep hielp weer gepoogd alles draaiende te krijgen maar tevergeefs, al bug report/feature request uitgedaan naar Nextcloud en is erkend dat er dus teveel instellingen achterblijven van eerder geïnstalleerde apps.

Ook ergens nog naar Apache virtualhosts gekeken maar kreeg dat niet voor elkaar, hoeveel guides ik ook gebruikte.

Dus in Nginx Proxy Managerregel aangemaakt naar Nextcloud met : https://nc.domein.eu / 192.168.1.2 P:443, SSL aan (*.domein.eu). Dit werkt (Eerst alleen intern en via VPN waar ik later achter kwam, ondertussen opgelost).
Maar collabora wilde met geen mogelijkheid meer werken. Herinstallaties van alles geprobeerd, uiteindelijk een soort knipperlicht relatie, ene moment wel dan weer niet.

Maar Nginx Proxy Manager krijg ik ook niet lekker werkend met andere dingen. Er draait b.v. een Minecraft server management console op 192.168.1.10:40404 welke het wel van buiten af doet maar niet intern via minecraft.domein.eu:40404 alleen op IP en extern kun je gewoon naar minecraft.domein.eu zonder poort nummer. En ik zit erg in de war met Docker en poorten. Krijg het er niet lekker in.

Maar ik wil alles op 1 machine hebben maar kom er niet helemaal uit, dus hopelijk heeft iemand hier meer ervaring en dat deze gedeeld kan worden.

Ik wil het volgende gaan doen :

Alles naar 1 server verhuizen, (i5 3570/16-24-32GB ram/500-1000GB Opslag, enige wat echt opslag nodig heeft is Nextcloud (Deze kan syncrhoniseren met een andere, heb er 13)
(Ben huidige NAS aan het overzetten naar Truenas Scale maar moet even ~32TB aan data overpompen)

Ik heb een .EU domein bij versio doorgezet naar Cloudflare, ingesteld en lijkt te werken. API key voor Letsencrypt om SSL aan de gang te krijgen.

Ubuntu Server 24.04 op 192.168.1.2 (Hier gaan alle portforwards naartoe).
Nginx Proxy Manager voorop en poort 80/81/443 open. Hier begint het dus al, moet ik die in docker gaan zetten of bare-metal installeren? Nu staan portforwards dus '80>30020>80','81>30021>81' en '443>30022>443' (Truenas Scale app).
80 = extern, 30020>80 in docker. Ik wil dus ook alle SSL/letsencrypt door Nginx Proxy Manager laten regelen.

Maar Nextcloud in Docker en Snap hebben me al genoeg kopzorgen opgeleverd, met Docker kreeg ik SSL niet aan de praat, kon niet makkelijk bij config.php en met Snap allemaal 'apparmor:denied' spam in mijn console en 1000en MB's aan logs. Dus bare-metal gegaan en dit lijkt het beste te werken.

Dus hier twijfel ik erg over, als Nginx Proxy Manager ervoor zorgt dat SSL werkt lijkt het me geen probleem en pak ik Nextcloud AIO Docker.
Waar ik ook tegenaan loop is dat bepaalde docker containers graag 80:80/443:443, 8080:8080 of 9000:9000 en andere poorten willen gebruiken even als voorbeeld. Het liefst zet ik alles 1 op 1 door dus 80extern naar 80:80docker. (Van ESXI gewend dat gewoon alles goed gaat). Het voelt allemaal wat onnatuurlijk en lijkt in mijn geval redelijk vaak verbindings problemen tussen verschillende Docker images te geven. Maar ik weet dus niet of dat komt door mijn instellingen in Nginx Proxy Managerdat ik dus Collabora:9980 daar ingevoerd heb, dus collabora gewoon de 'admin' pagina laat zien op https://collabora.domein.eu maar 'intern' bij Docker er iets fout gaat dat dat niet kan?
Adguard moet op 53, of in ieder geval 53 moet vrij zijn anders werkt het niet.

Eigenlijk 2(4) ideeën :

1 - Nginx Proxy Manager en Adguard op Ubuntu en de rest in Docker en uitvogelen hoe ik uitkom met poorten?
2 - Ubuntu server Alles in Docker? En met de poorten vogelen dat er niets op dezelfde poorten terecht komt. Misschien opvolgend doen zoals Truenas Scale dat doet waar mogelijk? Unifi heeft echt specifieke poorten nodig.
(3 - Adguard op Ubuntu en de rest in Docker?)
(4 - Alles via Truenas Scale? Alles lijkt beschikbaar te zijn daar en losse Ubuntu Server laten vallen? maar dan komt het op andere hardware, Xeon e5 269?v4 14c28t, 64GB, ~50TB opslag)

Ook over de nadelen nagedacht:

1 - Eigenlijk geen? LAMP (of LNMP) installatie? Nginx Proxy Manager installeren zal eerste keer worden op deze manier, basis blijft draaien, alleen zorgen dat docker->wireguard DNS instellingen goed te krijgen zijn en alle andere dingen.
2 - Als ik het niet in Docker aan de praat krijg wat dan?
3 - Als ik het in Docker niet voor elkaar krijg? Poort conflicten?
4 - Single point of failure alleen dan komt daar ook nog mijn NAS bij en even uitzoeken hoe ik opslag toe ken aan Nextcloud. Als Nginx Proxy Manager niet doet wat ik hoop dat het doet zal dit helemaal moeizaam gaan.

Dan nog wat herstel werkzaamheden achteraf, instellingen van HA, Unifi en Nginx Proxy Managergegevens voor Letsencrypt. En dan hopen dat het gaat? Adguard/Wireguard (WG-Easy) zijn op zich zo gedaan, Nextcloud met SSL zal wel weer hoofdpijn worden.

Dus ik sta open voor suggesties, heb ik het helemaal fout en moet ik het compleet anders doen mag ook.
Heb nu nog 12 Machines vrij om het 1 en ander te proberen.

[UTPBlokje]

Ik zou alles in Docker draaien. Kijk eens naar MacBridge Docker; hiermee heb je een oplossing voor je poorten.

Aangezien je je domein toch al naar Cloudflare verwijst, waarom dan niet een Cloudflare Tunnel gebruiken? Zo kun je Nginx Proxy Manager (NPM) helemaal weglaten.

[prutser001]

UTPBlokje schreef op vrijdag 31 januari 2025 @ 01:14:
Ik zou alles in Docker draaien. Kijk eens naar MacBridge Docker; hiermee heb je een oplossing voor je poorten.

Aangezien je je domein toch al naar Cloudflare verwijst, waarom dan niet een Cloudflare Tunnel gebruiken? Zo kun je Nginx Proxy Manager (NPM) helemaal weglaten.

https://developers.cloudf...rted/create-local-tunnel/ Dat ziet er interessant uit. Kijk wel even of ik daar wat mee kan.

'Macbridge' ? Kom ik op iets uit voor 'macOS' ?

Het heeft me heel wat moeite gekost om het van versio over te krijgen naar CF. Dit kwam omdat bepaalde opties niet beschikbaar waren in mijn dashboard en dus uiteindelijk door de helpdesk gedaan moesten worden.. Ik heb geen idee hoe ik alles zou moeten doen via CF?

Wat ik eerst in Versio deed was het volgende :
A record voor www.domein.eu en domein.eu
CNAME voor minecraft.domein.eu maar dan moest ik alsnog http://minecraft.domein.eu:40404 gebruiken en portforward aanmaken in router naar 192.168.1.10:40404.

Nu Nginx Proxy Manager draait kan je gewoon naar 'minecraft.domein.eu' zonder poort omdat deze in Nginx Proxy Manager aangegeven is portfoward is weg uit router. (Maar alleen extern, intern moet ik 192.168.1.10:40404 gebruiken).

Ook zit ik met nog wat vage SSL certificaten die ineens om de hoek komen kijken, heb ergens 'home.domein.eu' aangemaakt maar kan niet vinden waar deze vandaan komt. Ubuntu heeft nc.domein.eu aanstaan in 'nextcloud-le-ssl.conf' met daarin verwijzing maar nc.domein.eu.crt. Had al veel problemen met 'collabora.domein.eu' welke ik er uiteindelijk uitgekregen heb. Dus op dat gebied is het een zooitje.

Waar ik bij bepaalde images tegenaan liep was dat die binnen Portainer niet naar 'host network' verbonden konden worden. Ik moest die docker images dan aanmaken via 'stack' en alles aangeven dan kon het weer wel? Ben wel bezig geweest met docker maar redelijk simpel.



Bij HA zie je dus geen poorten.

[ Voor 3% gewijzigd door prutser001 op 31-01-2025 12:38 ]

[c-nan]

Ik wil je echt helpen, maar wat een lap tekst, ik moet het steeds opnieuw lezen maar terwijl ik lees haal ik het alweer door elkaar.

Een tekening zou bijvoorbeeld helpen, of het iets compacter neerzetten.

[prutser001]

c-nan schreef op vrijdag 31 januari 2025 @ 11:11:
Ik wil je echt helpen, maar wat een lap tekst, ik moet het steeds opnieuw lezen maar terwijl ik lees haal ik het alweer door elkaar.

Een tekening zou bijvoorbeeld helpen, of het iets compacter neerzetten.

Ik heb geprobeerd juist zoveel mogelijk informatie mee te geven.

Nou ja het is 'simpel'. Niet voor mij want het is redelijk nieuw voor me, op de 'oude manier' had ik gewoon VM's gemaakt, daar in gemaakt wat ik wilde hebben en dan zit het gewoon op hetzelfde netwerk en kan ik poorten forwarden naar IP van VM en onderling vinden ze elkaar wel.


->(192.168.1.2) Ubuntu/Docker->
Nginx Proxy Manager (Poort 80/81/443 - Let'sencrypt met api key voor wildcard en dan *.domein.eu meegeven deze op host netwerk draaien?)
Nextcloud+collabora (nextcloud 80/443?, collabora (coolwsd daemon) 9980)
Adguard (53)
Wireguard (51820)
HomeAssistant (8123)
Unifi Controller (8080/8880/8443/6789/3478/10001)

Dat moet allemaal dan in Docker, ik krijg het niet in mijn hoofd hoe ik er dus voor zorg dat Nextcloud niet gaat lopen piepen dat 80/443 niet beschikbaar zijn, deze draait nu op Ubuntu. En waar ik dus tegenaan liep met Docker/Snap was dat ik die poorten niet lekker voorelkaar kreeg bij SSL certs aanmaken. Toen Nextcloud op Ubuntu liep was het een fluitje (niet dat ik het goed deed) maar het werkte wel.

Ik kan hier wel een test omgeving voor maken, en dan tijdelijk even 80/81/443 naar die machine omzetten.
Kan ook wel met een VM maar dan moet ik het alsnog een keer overdoen, moet alleen even kijken hoe ik uitkom met schijven.

Het zou eventueel kunnen op Truenas_scale alles is beschikbaar daar, maar dan moet ik mijn 'oude' NAS afbreken en data zien weg te zetten voor het aanmaken van ZFS of begin klein en gooi daarna wat schijven erbij. Grootste nadeel hiervan vind ik als deze 'down/ in onderhoud' is dan werkt netwerk niet meer fatsoenlijk en SPOF. dus meh.

Netwerk : Edgerouter->EX4200 48t ->

server 1 : Ubuntu/Docker Nginx Proxy Manager/Nextcloud/Collabora/Adguard/Wireguard/Unifi/HA?
server 2 : Truenas_scale (Dan alleen als NAS en proberen/testen van andere docker gerelateerde dingen).
server 3 : WS2025 AD/DC/DNS/DHCP/IIS (Hier wil ik interne website hosten met alle links naar apparaten op mijn netwerk)

[c-nan]

Ik doe mijn best om het uit te vogelen wat je huidige setup is, waar je naar toe wilt en waar je tegenaan loopt, maar ik heb er moeite mee.

Het helpt ook niet dat je NPM als afkorting gebruikt voor Nginx Proxy Manager, ik dacht heel de tijd aan Node Package Manager, want NPM is daar de afkorting van.

Containers kan je op verschillende manieren inrichten. Direct op host ip, of een eigen ip met port forwards. Als je container op poort 80 luistert intern, hoeft dat buiten ook niet perse op poort 80. Je kan een container bijvoorbeeld aanmaken met "-p 2280:80".

Je zou ook SSL offloading kunnen doen dmv HAProxy.

Oh, en daarbij moet ik zeggen, ik blijf lekker ver weg van Snap. Niks voor mij.

Ik zal vanavond en anders morgen alles nog eens doorlezen, mocht ik begrijpen waar je naar toe wilt en waar je tegenaan loopt wil ik je erbij best helpen.

[prutser001]

c-nan schreef op vrijdag 31 januari 2025 @ 12:02:
Ik doe mijn best om het uit te vogelen wat je huidige setup is, waar je naar toe wilt en waar je tegenaan loopt, maar ik heb er moeite mee.

Het helpt ook niet dat je NPM als afkorting gebruikt voor Nginx Proxy Manager, ik dacht heel de tijd aan Node Package Manager, want NPM is daar de afkorting van.

Containers kan je op verschillende manieren inrichten. Direct op host ip, of een eigen ip met port forwards. Als je container op poort 80 luistert intern, hoeft dat buiten ook niet perse op poort 80. Je kan een container bijvoorbeeld aanmaken met "-p 2280:80".

Je zou ook SSL offloading kunnen doen dmv HAProxy.

Oh, en daarbij moet ik zeggen, ik blijf lekker ver weg van Snap. Niks voor mij.

Ik zal vanavond en anders morgen alles nog eens doorlezen, mocht ik begrijpen waar je naar toe wilt en waar je tegenaan loopt wil ik je erbij best helpen.

Ik zal de text even aanpassen.


Huidige setup is denk ik fubar, het oplossen van de dingen die ik allemaal geprobeerd heb kost teveel tijd.
Heb met certbot/keytool/letsencrypt zitten klooien (dat het werkte was al een wonder).

Ik ga wel een testsetup inelkaar steken en kijken waar ik tegenaan loop. Begin wel met kale Ubuntu/Docker en zet alles aan.


Ik dacht dat Nginx Proxy Manager dit al deed?
Met haproxy bedoel je dit? https://hub.docker.com/_/haproxy (dit is compleet nieuw voor me ziet er ingewikkeld uit)

[F_J_K]

offtopic:
'Hulp gezocht met ', dat geldt voor elk topic met een vraag. Ik poets dat dus even weg uit de titel zodat het relevante deel beter is te lezen.

[UTPBlokje]

Aah, een foutje van mijn kant! Het was al laat. 😅 Ik bedoel natuurlijk macvlan 😎

Voor een Cloudflare Tunnel (CF-Tunnel) moet je de nameservers van Cloudflare gebruiken. Wanneer je een domein toevoegt, neemt Cloudflare in 99,9% van de gevallen automatisch alle DNS-waarden over. Vervolgens dien je de nameservers bij Versio aan te passen naar die van Cloudflare.

Cloudflare heeft alles duidelijk en overzichtelijk gedocumenteerd:
https://developers.cloudflare.com/learning-paths/

Het grote voordeel van CF-Tunnel is dat je geen gedoe hebt met poorten en port forwarding. NPM kan eruit en macvlan is niet nodig.

Daarnaast kan alles eenvoudig binnen Docker op één machine draaien.

Mijn motto is altijd: Kan het niet in Docker?
Natuurlijk zijn er uitzonderingen; sommige dingen werken simpelweg niet in Docker. Maar dat zijn er echt weinig. In die gevallen gebruik ik een LXC-container of een losse VM.

Mocht je geen zin hebben in CF-Tunnel en Cloudflare, dan kun je inderdaad een reverse proxy naar keuze gebruiken, zoals HAProxy, NPM, Caddy of Traefik.

Tip: Maak een apart netwerk voor de proxy aan. Hierdoor hoef je geen exposed ports te gebruiken voor de verschillende Docker-containers.

[prutser001]

UTPBlokje schreef op vrijdag 31 januari 2025 @ 15:28:
Aah, een foutje van mijn kant! Het was al laat. 😅 Ik bedoel natuurlijk macvlan 😎

Voor een Cloudflare Tunnel (CF-Tunnel) moet je de nameservers van Cloudflare gebruiken. Wanneer je een domein toevoegt, neemt Cloudflare in 99,9% van de gevallen automatisch alle DNS-waarden over. Vervolgens dien je de nameservers bij Versio aan te passen naar die van Cloudflare.

Cloudflare heeft alles duidelijk en overzichtelijk gedocumenteerd:
https://developers.cloudflare.com/learning-paths/

Het grote voordeel van CF-Tunnel is dat je geen gedoe hebt met poorten en port forwarding. NPM kan eruit en macvlan is niet nodig.

Daarnaast kan alles eenvoudig binnen Docker op één machine draaien.

Mijn motto is altijd: Kan het niet in Docker?
Natuurlijk zijn er uitzonderingen; sommige dingen werken simpelweg niet in Docker. Maar dat zijn er echt weinig. In die gevallen gebruik ik een LXC-container of een losse VM.

Mocht je geen zin hebben in CF-Tunnel en Cloudflare, dan kun je inderdaad een reverse proxy naar keuze gebruiken, zoals HAProxy, NPM, Caddy of Traefik.

Tip: Maak een apart netwerk voor de proxy aan. Hierdoor hoef je geen exposed ports te gebruiken voor de verschillende Docker-containers.

Ik kwam wel iets tegen waarom CF tunnel mogelijk geen oplossing is.
In de voorwaarden heeft gestaan dat het niet bedoelt is voor grote hoeveelheden data. (schijnt later weer weggehaald te zijn). Als ik alleen al naar mijn eigen telefoon kijk was dat een backup van 64GB.

Nextcloud is dus wat het moet doen, cloud spelen. Niet dat ik later afgezet wordt bij CF omdat er teveel data overheen gaat. Ook b.v. beveiliging cameras etc. Je zou de gebanned kunnen worden. Dan heb ik het liever helemaal zelf in de hand. Zeker met testen al meerdere malen mijn telefoon backup laten maken naar nextcloud.

Ga de boel maar eens installeren en kijken waar ik uit kom! Wish me luck.

[Frogmen]

Op Truenas Scale de Nginx proxy app draaien deze doet ook de certificaten simpele en snelle oplossing.

[prutser001]

Frogmen schreef op dinsdag 4 februari 2025 @ 13:37:
Op Truenas Scale de Nginx proxy app draaien deze doet ook de certificaten simpele en snelle oplossing.

Zover was ik al en dit draait ook, maar omdat ik al eerder bezig ben geweest met andere computers voorzien van certificaten (welke dus 80/443) hadden is het een beetje kapot. Ook komen er bij bepaalde 'hosts' ineens verschillende certificaten naar voren. Ergens heb ik 'home.domein.eu' gemaakt maar kan nergens vinden waar of waar dat vandaan getoverd word.

Dus wil ik alles opnieuw opzetten. Gewoon complete netwerk reset.

Ik heb een test setup draaien met daarom een aantal docker images. Maar hoe geweldig docker ook mag en kan zijn voel ik me 'gehandicapt' omdat ik niet gewoon overal bij kan dus ff 'nano /etc/nogwat/nogiets/config.php' en even aanpassen zonder een hoop gedoe.

Waar ik nu tegenaan loop is het volgende:

(testsetup : Ubuntu 2404/Docker)

Portainer portainer/portainer-ce:2.21.5 9000

Nginx Proxy Manager jc21/nginx-proxy-manager:latest 80/81/443
jc21/mariadb-aria:latest

wg-easy ghcr.io/wg-easy/wg-easy 51820/51821

Adguard adguard/adguardhome 853:853 1443:443 53:53 784:784 180:80 3000:3000 5443:5443 8853:8853
### EDIT###
Adguard gaf niet de juiste informatie weer!? Na verwijderen en opnieuw aanmaken 444:443 3000:3000 53:53 82:80 (geen idee waar dat aan lag) die werkt nu.
### EDIT###
Nu loop ik al tegen het probleem aan dat ik adguard er niet fatsoenlijk bij krijg.
Die wil ook graag poort 80/443 hebben dus ik heb 180:80 en 1443:443 gedaan en ik kom er niet eens bij.
Dit is puur test omgeving oude installatie draait gewoon. Poort 53 heb ik op een of andere manier al opgelost. Ik raak gewoon in de war met die poorten allemaal.

Ik zit er ook mee of ik nou voor alles apart een compose / yml moet maken of 1? Ja ik heb gezocht en alles lijkt zo simpel tot je het zelf gaat doen, dan loop je tegen van alles aan en valt het in het niets. Voorbeelden zijn dan ook 'enkel' die container alleen.

En dan zijn we er nog niet eens, Nextcloud moet er ook nog bij, ook standaard 80/443.

Nextcloud docker.io/nextcloud/all-in-one:latest

Ook heb ik kennelijk meer succes als ik het gewoon via CLI doe dan als ik portainer gebruik, mis daar gewoon overzicht van wat er nou eigenlijk gebeurt en wat wel/niet aan is/welke poorten etc. aan - - heb ik niets. (Ja beetje gefrustreerd).

[ Voor 3% gewijzigd door prutser001 op 05-02-2025 14:32 ]

[Cyphax]

prutser001 schreef op woensdag 5 februari 2025 @ 14:15:
[...]

Waar ik nu tegenaan loop is het volgende:

(testsetup : Ubuntu 2404/Docker)

Portainer portainer/portainer-ce:2.21.5 9000

Nginx Proxy Manager jc21/nginx-proxy-manager:latest 80/81/443
jc21/mariadb-aria:latest

wg-easy ghcr.io/wg-easy/wg-easy 51820/51821

Adguard adguard/adguardhome 853:853 1443:443 53:53 784:784 180:80 3000:3000 5443:5443 8853:8853

Nu loop ik al tegen het probleem aan dat ik adguard er niet fatsoenlijk bij krijg.
Die wil ook graag poort 80/443 hebben dus ik heb 180:80 en 1443:443 gedaan en ik kom er niet eens bij.
Dit is puur test omgeving oude installatie draait gewoon. Poort 53 heb ik op een of andere manier al opgelost. Ik raak gewoon in de war met die poorten allemaal.

Dit soort dingen zijn ook al gauw verwarrend. Meestal pak ik er (mega-ouderwetsch) een vel papier bij om een beetje overzicht te schapen van ip-adressen en poorten.
Uiteindelijk maakt het niet zo heel veel uit op welke poorten je containers draaien, als je maar zorgt dat (80 en) 443 op de host niet worden gebruikt voor iets anders, dan hoef je alleen te zorgen dat je nginx-container wel op die poort(en) draait.

Ik zit er ook mee of ik nou voor alles apart een compose / yml moet maken of 1? Ja ik heb gezocht en alles lijkt zo simpel tot je het zelf gaat doen, dan loop je tegen van alles aan en valt het in het niets. Voorbeelden zijn dan ook 'enkel' die container alleen.

Uiteindelijk zijn het maar containers, en onder de streep draaien al die processen gewoon op de host.
Over het algemeen doe je per "dienst" een compose-file, en daarin zitten dan de containers die daarvoor nodig zijn. Vaak een container met webeserver en eentje met een database. Die kunnen in 1 compose-file.

Maar als je alles in 1 compose-file stopt moet dat in principe ook wel kunnen, alleen moet je dan je hele stack offline gooien bij een update van een van de containers, denk ik?

En dan zijn we er nog niet eens, Nextcloud moet er ook nog bij, ook standaard 80/443.

Ja maar wel op z'n eigen ip dan, je reverse proxy moet 'm benaderen via het "private" ip-adres van de container. Aangenomen dat je als netwerkdriver "bridge" gebruikt. Pas als je bij alle containers "host" gebruikt wordt het vervelend wanneer containers hun eigen poortnummer willen bepalen.

Ook heb ik kennelijk meer succes als ik het gewoon via CLI doe dan als ik portainer gebruik, mis daar gewoon overzicht van wat er nou eigenlijk gebeurt en wat wel/niet aan is/welke poorten etc. aan - - heb ik niets. (Ja beetje gefrustreerd).

Dat is toch prima, de cli-tools van docker zijn compleet genoeg om mee uit de voeten te kunnen. Ik heb lang gewoon in /var/docker een dir gemaakt per stack, met daarin een compose-file en een eventuele .env, en dan docker compose up draaien. Volgens mij doet portainer dat niet zo heel veel anders.
Kan je nog in source control gooien voor het gemak, dan heb je ook altijd een vorm van overzicht.

[prutser001]

@Cyphax Yup had alles al in een excel gegooid om het bij te houden, hele reeks aan de praat maar nu b.v.
Nextcloud AIO draait een soort installer en opent een andere container en die vereist dan weer 80/443 waar Nginx Proxy Manager op zit.. Maar testen is best lastig als je 443 nodig hebt en die aan de bestaande installatie zit.

Probeer het nu via 'stack' en dat lijkt beter te gaan, en ook makkelijker aan te passen als ik iets moet veranderen.

Ben wel iets verder maar te snel afgeleid open-webui en rustdesk er ook al bij gezet.

[ Voor 4% gewijzigd door prutser001 op 06-02-2025 07:57 ]

[MsG]

Ik zou sowieso loslaten dat je de interne poort structuur van een docker-container 1 op 1 wil overzetten, waarom zou je dat willen.

Ik heb op *.komkommer.nl alles via Nginx Proxy Manager lopen, zodat je überhaupt niet meer met poorten zit (aan de buitenkant) en alles 443 is met certificaat. In de Dns-server, Adguard in mijn geval, maak je dan een entry aan voor die hostname naar het lokale ip van NPM.

Baremetal gaan omdat je het niet volledig snapt lijkt me niet de meest handige aanpak.

[ufear]

Kijk ook eens naar Traefik ipv NGINX, maar volgens mij raken de laatste 2 reacties de juiste snaar, je interne docker-poorten zijn totaal irrelevant, zorg alleen dat de containers geen host-porten claimen en geen SSL doen, laat de proxy dat allemaal oplossen.

[prutser001]

MsG schreef op donderdag 6 februari 2025 @ 08:06:
Ik zou sowieso loslaten dat je de interne poort structuur van een docker-container 1 op 1 wil overzetten, waarom zou je dat willen.

Ik heb op *.komkommer.nl alles via Nginx Proxy Manager lopen, zodat je überhaupt niet meer met poorten zit (aan de buitenkant) en alles 443 is met certificaat. In de Dns-server, Adguard in mijn geval, maak je dan een entry aan voor die hostname naar het lokale ip van NPM.

Baremetal gaan omdat je het niet volledig snapt lijkt me niet de meest handige aanpak.

Dat is het dus een beetje, bare metal heb ik het 'zo aan de praat' met docker is het vechten/uitzoeken waar/waarom 80/443 nou weer bezet zijn, of hoe ze weer vrij te krijgen zodat de nieuwe docker images willen functioneren.

Op mijn huidige setup draaien dus Nextcloud/adguard/wireguard op Ubuntu en dat werkt, de rest in Docker.
NPM draait op een volledig andere machine nu maar wil dus alles op 1 server samenvoegen.

ufear schreef op donderdag 6 februari 2025 @ 08:11:
Kijk ook eens naar Traefik ipv NGINX, maar volgens mij raken de laatste 2 reacties de juiste snaar, je interne docker-poorten zijn totaal irrelevant, zorg alleen dat de containers geen host-porten claimen en geen SSL doen, laat de proxy dat allemaal oplossen.

Doen Traefik en NPM niet hetzelfde? NPM had ik eindelijk aan de praat.

Deze maar even aan het kijken : YouTube: Best for Homelab? Traefik vs Nginx Proxy Manager

Had er al eens naar gekeken.
https://github.com/Christ...pose/traefik/compose.yaml

Wel wat van kunnen leren
https://github.com/Christ.../tree/main/docker-compose

Ik ga weer even verder speuren.

[Oon]

Ik weet niet hoe relevant deze input nog is maar ik kom dit topic nu pas tegen dus toch maar:

Ik heb zelf een grote server waar ik bij voorbaat Proxmox op heb gezet, omdat ik in eerste instantie van plan was om met VMs te gaan werken. Dat was nog in de tijd dat Docker niet zo populair was en ik kwam van een ESXi server af, dus voor mij een logische keuze.
Daar ben ik toen Docker bij gaan draaien, wat prima werkt op de Debian-based Proxmox distro (met wel wat aanpassingen in de firewall voor VMs die poorten nodig hebben).

In eerste instantie heb ik ook geprobeerd om álles op Docker te gaan draaien, maar uiteindelijk heb ik Home Assistant terug naar een KVM VM verplaatst. De overhead is daar iets groter, maar het werkt zoveel fijner. Ik kan binnen Home Assistant nu ook gewoon weer Docker containers draaien (zoals bijv. code-server, die gewoon als add-on draait) en alles dat alleen voor Home Assistant draait zit daarmee netjes in die VM. Daarnaast is überhaupt het feit dat ik add-ons vanuit Home Assistant kan beheren een enorme verbetering t.o.v. Home Assistant in Docker waar je alles zelf moet uitvogelen, want hoe meer Home Assistant richting de 'alles in UI en instelbaar door een leek' gaat, hoe minder documentatie beschikbaar is voor dergelijke dingen.

Verder draai ik wel alles in Docker.

Ik ben eerst begonnen met Traefik, toen heb ik nog even Caddy geprobeerd, maar Nginx Proxy Manager is wel echt 'best in class' vwb reverse proxies. Deployment is zoveel makkelijker, en geen geneuzel met labels die je configs weer vervuilen. Knal een container online in het netwerk dat je hiervoor gebruikt (ik heb deze zelf nginxpm genoemd, maar proxy wordt ook vaak gebruikt) en je kunt NginxPM gewoon naar de container + interne poort wijzen en klaar.

NextCloud draai ik ook binnen Docker met het LinuxServer image, en die heeft z'n eigen Redis voor caching.

Verder draai ik een gedeelde MariaDB die door alles van Home Assistant en andere dingen die ik in Docker draai tot losse scripts gebruikt wordt, en ik ook gebruik voor bijv. lokaal development.

Vwb de poorten moet vooral even klikken dat je, wanneer je een reverse proxy gebruikt, eigenlijk vrijwel nooit een poort hoeft te forwarden in Docker. Als je een poort in je docker-compose hebt staan (of de -p parameter bij een docker run commando oid) dan ben je alleen de externe poort aan het verwijzen naar een interne poort, maar dat is meestal niet nodig. 9/10 dingen draaien op poort 80/443, 8080, 3000 etc. en die kun je prima meteen via NginxPM laten draaien.
Als je wél een poort nodig hebt dan is het vaak voldoende om een andere externe poort aan te geven, bijv. 8431:80 (ipv 80:80), zodat je daarna op <lokaal_ip>:8431 je container kunt bereiken.
Het zou dus eigenlijk nooit zo moeten zijn dat er meerdere containers poort 80/443 gebruiken, dat zou alleen je proxy (NginxPM) moeten. Alle andere containers hebben misschien wel poort 80/443 in hun interne service, maar die hoef je niet te forwarden, want je proxy kan die interne service+poort direct aanspreken.

Ik heb nu inmiddels twee servers draaien hier thuis, die samen in een Docker Swarm zitten met een gedeeld netwerk, en dat werkt ook verrassend goed. Ik kan gewoon dezelfde NginxPM gebruiken om beide servers aan te spreken. Als je toch naar één server wil is het niet nodig, maar anders misschien wel interessant om naar te kijken.

[MsG]

Mocht je geheel openstaan voor een andere aanpak, veel mensen zitten tegenwoordig op Proxmox (Het grote Proxmox VE topic). Hier zijn heel veel community scripts om allerlei bekende pakketten via 1 buildscript als losse LXC (soort containers) te kunnen draaien. Dan heb je wel de isolatie maar niet de overhead van een volledige VM.

Hier vind je die community scripts: https://community-scripts.github.io/ProxmoxVE/scripts

Dan is het opzetten van de meeste systemen ook redelijk kinderspel.

[prutser001]

MsG schreef op donderdag 6 februari 2025 @ 10:34:
Mocht je geheel openstaan voor een andere aanpak, veel mensen zitten tegenwoordig op Proxmox (Het grote Proxmox VE topic). Hier zijn heel veel community scripts om allerlei bekende pakketten via 1 buildscript als losse LXC (soort containers) te kunnen draaien. Dan heb je wel de isolatie maar niet de overhead van een volledige VM.

Hier vind je die community scripts: https://community-scripts.github.io/ProxmoxVE/scripts

Dan is het opzetten van de meeste systemen ook redelijk kinderspel.

Ik heb vooral met ESXI/vSphere/vCenter gewerkt en ook thuis gebruikt. Het nadeel is dat het systeem wat daar het best voor geschikt is erg luid is en dorstig. Supermicro SC827 met 2 nodes (X8DTT-HF+ 2x x5660 12c/24t/96GB ram, ~20TB per node) Hier staat dus al ESXI 8.0c op (laatste versie die ondersteund is). Ik heb al een test omgeving gehad met Proxmox maar ik kan er niet inkomen. Waar ik tegenaan liep was het maken van opslag/pools en dat KVM gebeuren. Het voelt niet echt volwassen? Heb mijn PVE net aangezet en nu lijkt poort 8006 dood 0.0 reactie, eerst maar herinstallatie... ESXI draait wel gewoon.

Tot nu is mijn ervaring met PVE niet je van het.

Ik wilde juiste de simpele Dell systeempjes gebruiken, stil en zuinig. PVE op een quad core? WS2025 draait als een trein op die Dell bakjes.