58d9be1f48
All checks were successful
Deploy server-up (dev) / deploy (push) Successful in 2m1s
- Elk *arr-onderdeel is nu ook een losse app in de store (46 nieuwe sjablonen); los en gebundeld komen uit één bron (tools/arr_sjablonen.py) met een test die bewaakt dat ze niet uiteen lopen - Alles deelt één /data-map, zodat hardlinks werken; losse /tv-, /movies- en /downloads-mounts zijn eruit, UMASK=002 erbij - Nieuwe eerste stap "Onderdelen" in het invulmenu, met kopjes per soort; de dubbele groepsschakelaar en de lege kaarten in Instellingen zijn weg - Eigen IP-adres per container in plaats van per stack; containers zonder adres houden hun poortmapping. Ook Pangolin publiceert nu per container - Huntarr vervangen door NeutArr (project offline na lekken, image bestaat niet meer), Maintainerr naar zijn nieuwe organisatie - 31 apps toegevoegd uit het *arr-ecosysteem, alle images tegen hun registry gecontroleerd - data_dir hernoemd naar appdata_dir in de hele catalogus, naast de nieuwe data_root; qBittorrent van poort 8080 naar 8097 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
253 lines
10 KiB
Markdown
253 lines
10 KiB
Markdown
# Stacks een eigen IP-adres geven (macvlan / ipvlan)
|
||
|
||
Standaard publiceert een stack poorten op de host: Vaultwarden op `8222`, Mealie
|
||
op `9925`, enzovoort. Dat werkt, maar levert op den duur een lange lijst
|
||
poortnummers op die je moet onthouden, en twee apps die allebei poort 8080 willen
|
||
gaan niet samen.
|
||
|
||
Met een **macvlan**- of **ipvlan**-netwerk krijgt een stack een eigen IP-adres in
|
||
je LAN. De app draait dan gewoon op zijn eigen standaardpoort:
|
||
|
||
| Zonder | Met eigen IP |
|
||
|--------|--------------|
|
||
| `http://192.168.1.10:8222` | `http://192.168.1.240` |
|
||
| `http://192.168.1.10:9925` | `http://192.168.1.241` |
|
||
|
||
Je kunt er ook per app op firewallen, en een DNS-naam aan koppelen.
|
||
|
||
---
|
||
|
||
## ⚠️ Lees dit eerst: de host bereikt zijn eigen containers niet
|
||
|
||
Dit is de bekendste valkuil van macvlan. De Docker-host kan **niet** bij een
|
||
container die op een macvlan-netwerk draait, en andersom ook niet. Alle andere
|
||
apparaten in je netwerk kunnen dat wél.
|
||
|
||
Draait Server Up op dezelfde machine als de containers, dan zie je dus:
|
||
|
||
- vanaf je laptop: `http://192.168.1.240` werkt
|
||
- vanaf de server zelf: `curl http://192.168.1.240` loopt vast
|
||
|
||
Heb je dat nodig (bijvoorbeeld voor een healthcheck of een reverse proxy die op
|
||
de host draait), maak dan een shim-interface aan op de host:
|
||
|
||
```bash
|
||
# Eenmalig; vervang eth0 en de adressen door die van jouw netwerk.
|
||
ip link add shim link eth0 type macvlan mode bridge
|
||
ip addr add 192.168.1.239/32 dev shim
|
||
ip link set shim up
|
||
ip route add 192.168.1.240/28 dev shim
|
||
```
|
||
|
||
Zet dat in een systemd-unit of in `/etc/network/interfaces`, anders is het na een
|
||
herstart weg.
|
||
|
||
**ipvlan (l2)** heeft dit probleem niet op dezelfde manier, maar vereist wel dat
|
||
je switch en router er goed mee omgaan. Werkt macvlan niet, probeer dan ipvlan.
|
||
|
||
---
|
||
|
||
## Stap 1 — Netwerk aanmaken in Server Up
|
||
|
||
Ga naar **Instellingen → Netwerken → Netwerk**. Server Up kijkt zelf welk netwerk
|
||
je server gebruikt en toont dat bovenaan als voorstel: interface, subnet, gateway
|
||
en een vrije IP-range. Eén klik vult het hele formulier.
|
||
|
||
> Die detectie werkt door heel kort een container te starten die de
|
||
> netwerknamespace van de host deelt en daar de routetabel uitleest. Server Up
|
||
> zelf zit in een eigen namespace en ziet anders alleen zijn eigen bridge.
|
||
|
||
Lukt detecteren niet, dan vul je het met de hand in. De vier velden:
|
||
|
||
| Wat | Voorbeeld | Hoe kom je eraan |
|
||
|-----|-----------|------------------|
|
||
| Host-interface | `eth0` | `ip -br link` op de server |
|
||
| Subnet | `192.168.1.0/24` | Je router; hetzelfde subnet als de server |
|
||
| Gateway | `192.168.1.1` | `ip route \| grep default` |
|
||
| IP-range | `192.168.1.240/28` | Een blok dat je **buiten je DHCP-bereik** houdt |
|
||
|
||
### Hoe die vier zich tot elkaar verhouden
|
||
|
||
Dit is waar het meestal misgaat, dus expliciet:
|
||
|
||
```
|
||
┌─────────────── subnet: 192.168.1.0/24 ───────────────┐
|
||
│ │
|
||
.1 .20 ──── DHCP ──── .239 .240 ── Docker ── .255
|
||
│ │ │ │ │
|
||
gateway je laptop, telefoon, einde begin einde
|
||
(je router) printer, enz. DHCP IP-range IP-range
|
||
```
|
||
|
||
- **Subnet** — precies hetzelfde als je router gebruikt. Een ander subnet
|
||
betekent dat je containers niemand kunnen bereiken.
|
||
- **Gateway** — je router, bijna altijd het eerste adres (`.1`). Laat je dit
|
||
leeg, dan kunnen de containers wel het LAN op maar niet het internet.
|
||
- **IP-range** — het deel dat Docker mag uitdelen. Dit moet **buiten** het
|
||
bereik liggen dat je router via DHCP uitgeeft, anders krijgt een container
|
||
hetzelfde adres als een apparaat in huis. Het einde van het subnet is meestal
|
||
vrij, vandaar `.240/28`.
|
||
- **Host-interface** — de netwerkkaart waar het LAN op zit. Niet die van Docker
|
||
(`docker0`, `br-…`) en niet wifi.
|
||
|
||
**Belangrijk:** het instellen van de range in Server Up doet niets aan je router.
|
||
Je moet dáár het DHCP-bereik verkleinen, bijvoorbeeld naar `192.168.1.20` –
|
||
`192.168.1.239`. Doe je dat niet, dan blijven er dubbele adressen mogelijk.
|
||
|
||
Terwijl je typt controleert Server Up de combinatie en toont hoeveel adressen je
|
||
overhoudt (`192.168.1.240/28` → veertien bruikbare adressen, `.241` t/m `.254`).
|
||
Klopt er iets niet, dan staat er in gewone taal bij waarom.
|
||
|
||
### Veelgebruikte ranges
|
||
|
||
| Subnet | Gateway | Voorstel | Ruimte |
|
||
|---|---|---|---|
|
||
| `192.168.1.0/24` | `192.168.1.1` | `192.168.1.240/28` | 14 stacks |
|
||
| `192.168.0.0/24` | `192.168.0.1` | `192.168.0.240/28` | 14 stacks |
|
||
| `10.0.0.0/24` | `10.0.0.1` | `10.0.0.240/28` | 14 stacks |
|
||
| `192.168.1.0/24` | `192.168.1.1` | `192.168.1.224/27` | 30 stacks |
|
||
|
||
Meer nodig? Neem een groter blok: `/27` geeft 30 adressen, `/26` geeft 62. Zorg
|
||
dan wel dat je DHCP-bereik navenant kleiner wordt.
|
||
|
||
## Stap 2 — Wat Server Up ermee doet
|
||
|
||
Hetzelfde met de hand zou zijn:
|
||
|
||
```bash
|
||
docker network create -d macvlan \
|
||
--subnet 192.168.1.0/24 \
|
||
--gateway 192.168.1.1 \
|
||
--ip-range 192.168.1.240/28 \
|
||
-o parent=eth0 \
|
||
lan
|
||
```
|
||
|
||
## Stap 3 — Een stack installeren op een eigen IP
|
||
|
||
Kies in de installatiemodal bij **Netwerk** je netwerk in plaats van "Poorten op
|
||
de host". Server Up stelt het eerstvolgende vrije adres voor; je kunt het
|
||
overschrijven.
|
||
|
||
Bij het installeren gebeurt er dit met het compose-bestand:
|
||
|
||
```yaml
|
||
# vóór # ná
|
||
services: services:
|
||
vaultwarden: vaultwarden:
|
||
image: vaultwarden/server image: vaultwarden/server
|
||
ports: networks:
|
||
- "8222:80" default:
|
||
lan:
|
||
ipv4_address: 192.168.1.240
|
||
networks:
|
||
lan:
|
||
external: true
|
||
```
|
||
|
||
De poortmapping verdwijnt — die heeft geen functie meer. Vaultwarden luistert op
|
||
poort 80 en is bereikbaar op `http://192.168.1.240`. Het `default`-netwerk blijft
|
||
erbij staan: zodra een container een `networks`-blok krijgt, vervalt zijn
|
||
lidmaatschap van het netwerk van de stack, en dan vindt hij zijn eigen database
|
||
niet meer.
|
||
|
||
### Meerdere containers, meerdere adressen
|
||
|
||
Bestaat een stack uit meerdere containers, dan kies je bij **Adres per container**
|
||
wie er een eigen adres krijgt. Dat hoeft niet iedereen te zijn: geef Sonarr en
|
||
Radarr een adres en laat de rest op zijn hostpoort staan.
|
||
|
||
**Een container die je geen adres geeft, houdt zijn poortmapping.** Dat is precies
|
||
het verschil met hoe dit eerder werkte: toen raakte élke container in de stack
|
||
zijn poorten kwijt zodra er één een adres kreeg, en waren de andere daarna nergens
|
||
meer te bereiken.
|
||
|
||
Containers met `network_mode` — de downloadclients achter een VPN — slaat Server
|
||
Up over. Die delen al de namespace van een andere container, en compose weigert
|
||
`network_mode` en `networks` naast elkaar.
|
||
|
||
---
|
||
|
||
## Adresbeheer
|
||
|
||
Server Up bewaart het toegekende adres in `.serverup.json` in de stackmap. Zo
|
||
blijft het gereserveerd, ook als de stack gestopt is, en krijgt een volgende
|
||
installatie het volgende vrije adres voorgesteld.
|
||
|
||
Wil je het adres van een bestaande stack wijzigen, pas dan het compose-bestand
|
||
aan via **compose bewerken** en werk `ipv4_address` bij.
|
||
|
||
## Verwijderen
|
||
|
||
Een netwerk kan pas weg als er geen containers meer op draaien. Stop eerst de
|
||
betreffende stacks; Server Up weigert het anders met een melding.
|
||
|
||
## Problemen oplossen
|
||
|
||
| Symptoom | Oorzaak |
|
||
|----------|---------|
|
||
| `network ... not found` bij het starten | Netwerk verwijderd terwijl de stack er nog naar verwijst — maak het opnieuw aan |
|
||
| Container krijgt geen verbinding | Verkeerde `parent`-interface, of de interface zit in een bond/bridge |
|
||
| Adres al in gebruik | Het adres valt binnen je DHCP-bereik; verklein de DHCP-pool of kies een andere range |
|
||
| Vanaf de server niet bereikbaar, vanaf laptop wel | Verwacht gedrag — zie de shim-interface bovenaan |
|
||
| Werkt niet op WiFi | Klopt: macvlan werkt niet over een draadloze interface |
|
||
|
||
|
||
---
|
||
|
||
## Gedeelde netwerken tussen apps
|
||
|
||
Naast een eigen IP-adres is er het gedeelde bridge-netwerk waarop apps elkaar op
|
||
containernaam vinden. Tot v0.7.70 was dat er één (`serverup`) en hing élke app
|
||
eraan: Vaultwarden kon bij je mediaserver, en andersom.
|
||
|
||
Nu kies je per app aan welke netwerken hij meedoet, en kun je er bij het
|
||
installeren zelf een maken. Laat je de naam leeg, dan wordt er een voorgesteld
|
||
(`su-<appnaam>`). Het netwerk verschijnt daarna in de lijst bij elke andere app.
|
||
|
||
```
|
||
Stap 2 — Verbinden
|
||
|
||
☑ serverup standaard 12 containers
|
||
☑ su-media 3 containers
|
||
☐ su-beheer 2 containers
|
||
|
||
[ media ] [+ Netwerk maken]
|
||
```
|
||
|
||
Een app kan aan meerdere netwerken tegelijk hangen — handig voor een reverse
|
||
proxy die bij alles moet kunnen.
|
||
|
||
Verwijderen kan alleen als er geen containers meer aan hangen, en het
|
||
standaardnetwerk blijft altijd staan.
|
||
|
||
---
|
||
|
||
## Is dit adres nog vrij?
|
||
|
||
Bij het invullen van een IP-adres controleert Server Up vier dingen:
|
||
|
||
1. valt het binnen het **subnet** van het netwerk;
|
||
2. valt het binnen het ingestelde **bereik** (buiten je DHCP-pool dus);
|
||
3. is het al **toegekend aan een container** in dit netwerk of gereserveerd door
|
||
een andere stack;
|
||
4. heeft de host het adres recent **op het LAN gezien** — dat leest de ARP-tabel
|
||
van de host, en vangt een fysiek apparaat met een DHCP-adres.
|
||
|
||
Klopt er iets niet, dan staat erbij wat en krijg je een vrij adres voorgesteld.
|
||
|
||
> Punt 4 is geen garantie: een apparaat dat uit staat, staat niet in de
|
||
> ARP-tabel. Houd je macvlan-bereik daarom buiten wat je router uitdeelt.
|
||
|
||
---
|
||
|
||
## Is deze poort nog vrij?
|
||
|
||
Poortvelden krijgen automatisch een vrij nummer voorgesteld. Daarbij wordt niet
|
||
alleen gekeken naar wat Docker publiceert, maar ook naar wat er **rechtstreeks
|
||
op de host luistert** — een nginx of DNS-server buiten Docker zag Server Up
|
||
eerder niet, terwijl je er net zo goed mee botst.
|
||
|
||
Dat laatste gaat via een korte hulpcontainer met `--network host`. Lukt dat
|
||
niet, dan meldt het antwoord `host_checked: false`: "vrij" is dan een aanname
|
||
op basis van Docker alleen.
|