• Ben.Hahlen
  • Registratie: December 2003
  • Laatst online: 11:52
Ik heb verschillende stacks geordenend naar een, voor mij, logische indeling.
Zaken die vaker gebruikt worden (databases/brokers, etc) zitten in een eigen stack.

Uitzondering is de stack met Authentik, Traefik en Pihole, daar zit Postgres en Redis dedicated in, want die moet onafhankelijk zijn.

Blog


  • Shattering
  • Registratie: Oktober 2014
  • Laatst online: 13-09 18:04
Ik geraak dus geen stap verder met het implementeren van macvlan om mijn containers rechtstreeks te "exposen" op mijn netwerk. Iemand die me wat tips kan geven?

Ik wil mijn verschillende containers verbinden met verschillende VLAN's (Unifi Network), dus als ik het goed heb moet ik gebruik maken van 802.1Q trunk bridge mode. Kan iemand dit bevestigen?

Vervolgens ben ik gestart met mijn ethernet interface (enp89s0) in promiscuous te zetten. Met het show commando zie ik (denk ik) dat dit ook in orde is.
code:
1
2
3
4
5
ip link set enp90s0 promisc on
ip -d link show enp89s0

"enp89s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 1c:69:7a:ac:a7:5b brd ff:ff:ff:ff:ff:ff promiscuity 2 minmtu 68 maxmtu 9216 addrgenmode eui64 numtxqueues 4 numrxqueues 4 gso_max_size 65536 gso_max_segs 65535 parentbus pci parentdev 0000:59:00.0"



Mijn (test) Docker-Compose ziet er als volgt uit.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
networks:
  core:
    name: core
    external: false
    driver: macvlan
    driver_opts:
      parent: enp89s0.1
    ipam:
      driver: default
      config:
        - subnet: "192.168.1.0/24"
          gateway: "192.168.1.1"
          ip_range: "192.168.1.100/30"

services:
  nginx:
    image: nginx:1-alpine
    networks:
      core:
        ipv4_address: "192.168.1.111"
    ports:
      - 8089:80
    volumes:
      - ./html5up-stellar/:/usr/share/nginx/html


Als ik het goed heb, zal maclvan het subinterface (enp89s0.1) automatisch aanmaken (zoals beschreven in https://docs.docker.com/engine/network/drivers/macvlan/). Na het starten van de containers zie ik (met ifconfig) echter geen subinterfaces?

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
ifconfig

enp89s0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet 192.168.1.99  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fd3c:1b60:ba7d:7b4d:1e69:7aff:feac:a75b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1e69:7aff:feac:a75b  prefixlen 64  scopeid 0x20<link>
        ether 1c:69:7a:ac:a7:5b  txqueuelen 1000  (Ethernet)
        RX packets 973101  bytes 315786020 (315.7 MB)
        RX errors 0  dropped 67  overruns 0  frame 0
        TX packets 499162  bytes 77690743 (77.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x6a200000-6a2fffff

Verder geen enp89s0.1  :(...


Binnen Portainer zie ik echter dat mijn Netwerk is aangemaakt (parent = enp89s0.1). Ook mijn container is aangemaakt (IP adres = 192.168.1.111). De container is echter niet bereikbaar. Niet van de Docker host zelf, wat normaal is (er is nog geen shim) maar ook niet vn andere toestellen van het netwerk.

Dit is zelf allemaal redelijk nieuw voor mij, dus ik weet niet goed hoe verder.
- Moet ik op de Docker host mijn sub-interface manueel aanmaken?
- Moet ik nog zaken configureren op de interface?
- Moet ik manueel routes toevoegen op de host (lees ik ook soms?)

Alvast bedankt!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Freee!! schreef op donderdag 22 augustus 2024 @ 00:27:
[...]

Dat is op te lossen met een shim.
Heb je hier een voorbeeld van?
Wat betreft compose, ik gebruik "docker run" commands, kan ik beter mee uit de voeten dan compose.
Dat snap ik. Maar hoe regel je dan container afhankelijkheden? Met de hand of een scriptje handmatig in volgorde opstarten? Want dat is nogal... onhandig :X.

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
@RobertMe - je kan er ook bash scripts van maken en die in een cron-job steken?!

Maar goed - updaten doe ik via Watchtower.
Die ellenlange commando's heb ik in een of meer bash-script gestoken.

Bijvoorbeeld het pihole script om de container via het host netwerk te starten zodat Pihole op alle vlans tegelijk actief kan zijn - hieronder het script:
#!/bin/sh
docker pull pihole/pihole:latest
#
docker stop pihole
docker rm pihole
docker run -d \
--name pihole \
--network host \
-v /opt/docker/pihole/etc-pihole:/etc/pihole \
-v /opt/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \
-e TZ=Europe/Amsterdam \
-e QUERY_LOGGING=false \
-e FTLCONF_LOCAL_IPV4=192.168.139.235 \
-e WEB_PORT=88 \
-e IPv6=false \
-e WEBTHEME=default-light \
-e DNSMASQ_USER=pihole \
--cap-add=NET_ADMIN \
--restart unless-stopped \
pihole/pihole

# Remove all unused images
docker image prune --all --force


Voor swag heb ik twee scripts gemaakt - een voor het host netwerk en een voor bridge netwerk. Zo kan ik snel switchen en testen zonder alle containers opnieuw te moeten starten.

Met portainer heb ik snel inzicht in het eindresultaat. Maar ik doe hier geen aanpassingen mee - die gaan altijd via het bash-script.

makes it run like clockwork


  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Shattering Wat zegt (mits het netwerk core heet natuurlijk):
docker inspect core

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
@alex3305 - kan je 1 of 2 voorbeelden geven van strikte afhankelijkheden tussen 2 of meer containers? Waardoor je inderdaad beter af bent met Compose?

[ Voor 5% gewijzigd door Airw0lf op 22-08-2024 12:08 ]

makes it run like clockwork


  • Freee!!
  • Registratie: December 2002
  • Laatst online: 20:58

Freee!!

Trotse papa van Toon en Len!

RobertMe schreef op donderdag 22 augustus 2024 @ 09:37:
[...]
Hoe update je dan? Ik met docker compose up -d --pull always in de map (of een submap van) de compose.yaml. Met CLI moet je zeker stop + pull + run doen waarbij run weer het originele ellenlange commando is?
Meestal doet Watchtower dat voor me, als ik het handmatig moet doen, doe ik het via Portainer, ik hoef dat commando normaal gesproken niet weer in te geven.
En daarnaast heb je met de composer.yaml het uberhaupt in een bestand staan, dat je kunt backuppen, of bijhouden in versiebeheer (/Git).
En dat commando kun je in een .txt opslaan waar je wilt, hoeft niet op de RPi zelf waardoor het onbereikbaar is als de RPi dusdanig crasht dat je de zaak opnieuw moet opbouwen. Geen wezenlijk verschil in backup en versiebeheer.

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT


  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
@Shattering - mijn 0,500 Euro:
Mijn favoriete aanpak is vlans aanmaken via (bijvoorbeeld) /etc/network/interfaces.
En vervolgens de container opstarten met de netwerk-optie host.
Waardoor die in alle vlans zichtbaar is.

makes it run like clockwork


  • Shattering
  • Registratie: Oktober 2014
  • Laatst online: 13-09 18:04
alex3305 schreef op donderdag 22 augustus 2024 @ 12:02:
@Shattering Wat zegt (mits het netwerk core heet natuurlijk):
docker inspect core
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
[
    {
        "Name": "core",
        "Id": "7bfb86fe40eebb8d94754fc027339a1821fb7f602183378bc899f12bba6f17f2"                                                                                                                                                                             ,
        "Created": "2024-08-22T10:36:35.094613786+02:00",
        "Scope": "local",
        "Driver": "macvlan",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.1.0/24",
                    "IPRange": "192.168.1.100/30",
                    "Gateway": "192.168.1.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "4ca68f3388c02394bd2a89c852b1fb0c441ad893b1401eb14c76deb0aa82168c":                                                                                                                                                                              {
                "Name": "overes95-nginx-1",
                "EndpointID": "d20011a298685c106d3617910a774abc3f5cd99ad426691e4                                                                                                                                                                             90aa93f9006b3c7",
                "MacAddress": "02:42:c0:a8:01:6f",
                "IPv4Address": "192.168.1.111/24",
                "IPv6Address": ""
            }
        },
        "Options": {
            "parent": "enp89s0.1"
        },
        "Labels": {
            "com.docker.compose.network": "core",
            "com.docker.compose.project": "thuis",
            "com.docker.compose.version": "2.25.0"
        }
    }
]

Acties:
  • +1 Henk 'm!

  • Freee!!
  • Registratie: December 2002
  • Laatst online: 20:58

Freee!!

Trotse papa van Toon en Len!

alex3305 schreef op donderdag 22 augustus 2024 @ 12:00:
[...]
Heb je hier een voorbeeld van?
code:
1
2
3
4
5
6
7
docker network create -d macvlan \
    --subnet=192.168.2.0/24 \
    --gateway=192.168.2.254 \
    --ip-range 192.168.2.224/28 \
    --aux-address="raspberrypi4=192.168.2.231" \
    -o parent=eth0 \
    Whiskey


code:
1
2
3
4
5
6
7
8
9
10
#!/bin/sh
### location : /etc/network/if-pre-up.d
### name     : Whiskey-shim
### NB       : Make executable (chmod +x /etc/network/if-pre-up.d/Whiskey-shim)
ip link set eth0 promisc on
ip link add Whiskey-shim link eth0 address FE:D6:0C:2C:A7:59 type macvlan mode bridge
ip addr add 192.168.2.231/32 dev Whiskey-shim
ip link set Whiskey-shim up
ip route add 192.168.2.224/28 dev Whiskey-shim
exit 0
Dat snap ik. Maar hoe regel je dan container afhankelijkheden? Met de hand of een scriptje handmatig in volgorde opstarten? Want dat is nogal... onhandig :X.
Daar heb ik geen problemen mee.

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT


Acties:
  • +1 Henk 'm!

  • Shattering
  • Registratie: Oktober 2014
  • Laatst online: 13-09 18:04
Airw0lf schreef op donderdag 22 augustus 2024 @ 12:23:
@Shattering - mijn 0,500 Euro:
Mijn favoriete aanpak is vlans aanmaken via (bijvoorbeeld) /etc/network/interfaces.
En vervolgens de container opstarten met de netwerk-optie host.
Waardoor die in alle vlans zichtbaar is.
Bedoel je met "VLANs aanmaken" simpelweg dat je de subinterfaces zelf aanmaakt?

Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Airw0lf schreef op donderdag 22 augustus 2024 @ 12:04:
@alex3305 - kan je 1 of 2 voorbeelden geven van strikte afhankelijkheden tussen 2 of meer containers? Waardoor je inderdaad beter af bent met Compose?
Zeker, ook wel drie :+ :
  • Home Assistant is afhankelijk van MariaDB
  • Paperless NGX is afhankelijk van PostgreSQL
  • Immich is afhankelijk van PostgreSQL en Redis
Zoals je ziet vaak database afhankelijkheden. Maar ik zou er niet aan moeten denken om Immich als losse containers met de hand op te zetten. Daarnaast heeft Dockge ook een Convert to Compose om alvast een start te kunnen maken:

Afbeeldingslocatie: https://tweakers.net/i/tdKb0iVLv75q6vBHK6WXnbgDu88=/800x/filters:strip_exif()/f/image/zOV08jl2r4jQ5DHB5ssoBwOP.png?f=fotoalbum_large

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Daar zie ik niets bijzonders... Ik heb helaas geen VLAN support waar ik zelf mee zou kunnen testen :o.

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
Shattering schreef op donderdag 22 augustus 2024 @ 12:26:
[...]


Bedoel je met "VLANs aanmaken" simpelweg dat je de subinterfaces zelf aanmaakt?
Yup :)

makes it run like clockwork


  • DjoeC
  • Registratie: November 2018
  • Laatst online: 22:09
alex3305 schreef op donderdag 22 augustus 2024 @ 12:33:
[...]

Zeker, ook wel drie :+ :
  • Home Assistant is afhankelijk van MariaDB
  • Paperless NGX is afhankelijk van PostgreSQL
  • Immich is afhankelijk van PostgreSQL en Redis
Zoals je ziet vaak database afhankelijkheden. Maar ik zou er niet aan moeten denken om Immich als losse containers met de hand op te zetten. Daarnaast heeft Dockge ook een Convert to Compose om alvast een start te kunnen maken:

[Afbeelding]
Kunnen die afhankelijkheden niet middels een healthcheck worden opgelost?

Acties:
  • +1 Henk 'm!

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

Afhankelijkheden, bedoelen jullie daarmee de "depends_on"? Want die doet irl niet zoveel, houdt alleen rekening met volgorde van opstarten en meer niet.

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
DjoeC schreef op donderdag 22 augustus 2024 @ 13:48:
[...]

Kunnen die afhankelijkheden niet middels een healthcheck worden opgelost?
Ja natuurlijk. Alles kan. Maar dit is toch net zo makkelijk?
Sp33dFr34k schreef op donderdag 22 augustus 2024 @ 13:51:
Afhankelijkheden, bedoelen jullie daarmee de "depends_on"? Want die doet iirc niet zoveel, houdt alleen rekening met volgorde van opstarten en meer niet.
Ja. Niet helemaal. Je kunt er wel meer mee doen. Waaronder afhankelijk zijn van een healthcheck van een andere container.

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

alex3305 schreef op donderdag 22 augustus 2024 @ 13:58:
[...]

Ja natuurlijk. Alles kan. Maar dit is toch net zo makkelijk?


[...]

Ja. Niet helemaal. Je kunt er wel meer mee doen. Waaronder afhankelijk zijn van een healthcheck van een andere container.
Ah, ik zie het ja. Dat wist ik dan weer niet, maar heel spannend vind ik het ook niet om eerlijk te zijn.

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


Acties:
  • +3 Henk 'm!

  • Shattering
  • Registratie: Oktober 2014
  • Laatst online: 13-09 18:04
Ondertussen is het gelukt met mijn macvlan & docker containers :).

Afbeeldingslocatie: https://tweakers.net/i/jxcK3yBRm2TeN1YtDWCowwj1yl8=/800x/filters:strip_exif()/f/image/HDS8jILfpiaK6m4hdNJCyJOo.png?f=fotoalbum_large

Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Shattering schreef op donderdag 22 augustus 2024 @ 14:08:
Ondertussen is het gelukt met mijn macvlan & docker containers :).

[Afbeelding]
Wat goed. Deel de oplossing ook even voor anderen :).

  • Shattering
  • Registratie: Oktober 2014
  • Laatst online: 13-09 18:04
alex3305 schreef op donderdag 22 augustus 2024 @ 14:51:
[...]

Wat goed. Deel de oplossing ook even voor anderen :).

[ Voor 31% gewijzigd door Shattering op 22-08-2024 17:56 ]


Acties:
  • +1 Henk 'm!

  • Shattering
  • Registratie: Oktober 2014
  • Laatst online: 13-09 18:04
Belangrijk: ik ben geen expert. Dit is hoe ik het aan de praat gekregen heb, maar het is misschien niet perfect. Feedback zeker welkom :).

Heel de set-up begint op de UniFi Dream Machine, bij het aanmaken van de netwerken. LET OP: in het begin was ik dit alles aan het testen met het core netwerk, met VLAN ID 1 - maar dit leek niet te werken. Zodra ik aan de slag ging met mijn internal verliep alles een pak vlotter (ik weet dus niet of het mogelijk is met het core/default netwerk of niet, omdat je daar bijvoorbeeld ook niet de VLAN ID kan aanpassen).

Afbeeldingslocatie: https://tweakers.net/i/_7CGnmlar82Uf7hGhnXPvFtK0Aw=/800x/filters:strip_icc():strip_exif()/f/image/193fRlo8y6s1SZl218L4uRXy.jpg?f=fotoalbum_large

Het is ook belangrijk om zeker je "VLAN ID" netjes te configureren binnen het UniFi netwerk.

Afbeeldingslocatie: https://tweakers.net/i/gKVshM_uNH-qLB-Yk66rRh0XmVE=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/scuHlgDul3sDp0Bb8fFtSJwh.png?f=user_large

Daarna is het belangrijk om het één en het ander te configureren/uit te zoeken op je Docker Host.
Starten met ifconfig (of alternatieven) om achter de naam van je interface te geraken.

code:
1
2
3
4
5
6
7
8
9
10
11
12
ifconfig

enp89s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.99  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fd3c:1b60:ba7d:7b4d:1e69:7aff:feac:a75b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1e69:7aff:feac:a75b  prefixlen 64  scopeid 0x20<link>
        ether 1c:69:7a:ac:a7:5b  txqueuelen 1000  (Ethernet)
        RX packets 573547  bytes 245398172 (245.3 MB)
        RX errors 0  dropped 45  overruns 0  frame 0
        TX packets 475905  bytes 253432570 (253.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x6a200000-6a2fffff


Vervolgens deze interface in promiscuous mode zetten. Ik ben er momenteel nog niet achter of ik dit elke keer moet uitvoeren na een reboot.

code:
1
sudo ifconfig enp89s0 promisc


Daarna kan je aan de slag met de netwerken binnen docker-compose (ik heb alles het liefst binnen deze file voor migraties, back-up, ...). Zoals je kan zien heb ik enkel de netwerk aangemaakt die ik ga gebruiken binnen Docker.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
networks:
  internal:
    name: internal
    driver: ipvlan
    driver_opts:
      parent: enp89s0.10
    ipam:
      config:
        - subnet: 192.168.10.0/24
          gateway: 192.168.10.1
  iot:
    name: iot
    driver: macvlan
    driver_opts:
      parent: enp89s0.40
    ipam:
      config:
        - subnet: 192.168.40.0/24
          gateway: 192.168.40.1
  dmz:
    name: dmz
    driver: macvlan
    driver_opts:
      parent: enp89s0.50
    ipam:
      config:
        - subnet: 192.168.50.0/24
          gateway: 192.168.50.1


Eens de basis in orde is, kan je beginnen met het opzetten van je Docker Containers, die gebruik maken van de nieuwe netwerken. Een ding is dat als de containers herstarten ze meestal een nieuw mac adres krijgen. Dit vervuilde mijn UniFi Network dashboard nogal, door een hoop duplicaten. Dit kan je oplossen door elke container een vast IP adres EN een vast mac adres te geven.

code:
1
2
3
4
    mac_address: 02:42:c0:a8:50:11
    networks:
      dmz:
        ipv4_address: "192.168.50.11"


Hierbij enkele voorbeelden (ik maak gebruik van Code-Server voor het beheren van alle code/yaml en maak deze extern beschikbaar via Traefik met Entra ID SSO).

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
services:
  traefik:
      image: traefik:latest
      container_name: traefik
      restart: unless-stopped
      ports:
        - "443:443"
      mac_address: 02:42:c0:a8:50:10
      networks:
        dmz:
          ipv4_address: "192.168.50.10"
      volumes:
        - /etc/locatime:/etc/localtime:ro
        - /var/run/docker.sock:/var/run/docker.sock:ro
        - /configs/traefik/traefik.yml:/traefik.yml:ro
        - /configs/traefik/acme.json:/acme.json
        - /configs/traefik/letsencrypt:/letsencrypt
        - /configs/traefik/dynamic:/dynamic:ro
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.traefik.entrypoints=https"
        - "traefik.http.routers.traefik.rule=Host(`traefik.yourhost.be`)"
        - "traefik.http.routers.traefik.tls=true"
        - "traefik.http.routers.traefik.tls.certresolver=letsencrypt"
        - "traefik.http.routers.traefik.service=api@internal"

  traefik-forward-auth:
    image: ghcr.io/italypaleale/traefik-forward-auth:3
    container_name: traefik-forward-auth
    restart: unless-stopped
    mac_address: 02:42:c0:a8:50:11
    networks:
      dmz:
        ipv4_address: "192.168.50.11"
    volumes:
      - /configs/traefik-forward-auth/config.yaml:/etc/traefik-forward-auth/config.yaml:ro
    environment:
      - TFA_AUTHMICROSOFTENTRAID_CLIENTSECRET=${CLIENTSECRET}
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.address=http://traefik-forward-auth:4181"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.authResponseHeaders=X-Forwarded-User"
      - "traefik.http.services.traefik-forward-auth.loadbalancer.server.port=4181"
      - "traefik.http.routers.traefik-forward-auth.rule=Host(`auth.yourhost.be`)"
      - "traefik.http.routers.traefik-forward-auth.entrypoints=https"
      - "traefik.http.routers.traefik-forward-auth.tls=true"

  codeserver:
    container_name: code-server
    image: lscr.io/linuxserver/code-server:latest
    restart: unless-stopped
    mac_address: 02:42:c0:a8:10:11
    networks:
      internal:
        ipv4_address: "192.168.10.11"
    volumes: 
      - /configs/codeserver:/config
      - /codeVolume:/codeVolume
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Brussels
      - DEFAULT_WORKSPACE=/default
    ports:
      - 8443:8443
    depends_on:
      - portainer
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.codeserver.entrypoints=http"
      - "traefik.http.routers.codeserver.entrypoints=https"
      - "traefik.http.routers.codeserver.rule=Host(`vscode.yourhostname.be`)"
      - "traefik.http.routers.codeserver.tls=true"
      - "traefik.http.routers.codeserver.tls.certresolver=letsencrypt"
      - "traefik.http.services.codeserver.loadbalancer.server.port=8443"
      - "traefik.http.routers.codeserver.middlewares=auth@file"


Door het op deze manier te doen, krijgt elke docker container een IP in mijn thuisnetwerk en zit de container ook in het juiste netwerk/VLAN, zodat mijn firewall regels (binnen UniFI Network) ook hier netjes worden toegepast. Daarnaast is het natuurlijk ook fijn dat je containers netjes zichtbaar zijn binnen het systeem.

Afbeeldingslocatie: https://tweakers.net/i/PW3fCKLB5DV_IRDn8keUnM0PZmI=/800x/filters:strip_exif()/f/image/ZXaWr815JJZ5nqtYMaJEXSFr.png?f=fotoalbum_large

Los hiervan denk ik dat je beter Bridged netwerken kan gebruiken binnen docker als je (1) geen eigen VLANs/Firewall regels hebt en (2) het allemaal wat simpeler wil houden :).

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
=====

Een systeem genaamd logos wordt de “syncthing-backup-server”.
In die syncthing Docker container is een folder genaamd \data. Op de host wijst die naar /mnt/allData/syncthing.

Het idee is om in deze folder te werken met verschillende subfolders/shares - een voor elke syncthing client. Elke share is receive-only.

De syncthing container van logos is gestart met:
docker run \
--name syncthing \
--network bridge \
--hostname syncthing \
-p 192.168.139.250:8384:8384 \
-p 192.168.139.250:22000:22000/tcp \
-p 192.168.139.250:22000:22000/udp \
-p 192.168.139.250:21027:21027/udp \
-v /opt/docker/syncthing/config:/config \
-v /mnt/allData/syncthing/data:/data \
-e TZ=Europe/Amsterdam \
-e PUID=1000 \
-e PGID=1000 \
-d \
--restart unless-stopped \
linuxserver/syncthing


=====

Aan de client-kant - in dit voorbeeld morpheus - is er binnen de Docker container ook een /data-folder. Het idee is om in deze data-folder te werken met subfolders - een per host-folder wat gesynced gaat worden met logos.

Dus de morpheus-host-folder /home/will/update-scripts is in de container beschikbaar als /data/home-will-update-scripts. En geshared met send-only.

De syncthing container van morpheus is gestart met:
docker run \
--name syncthing \
--network bridge \
--hostname syncthing \
-p 192.168.139.235:8384:8384 \
-p 192.168.139.235:22000:22000/tcp \
-p 192.168.139.235:22000:22000/udp \
-p 192.168.139.235:21027:21027/udp \
-v /opt/docker/syncthing/config:/config \
-v /opt/docker/syncthing/data:/data \
-v /home/will/update-scripts:/data/home-will-update-scripts \
-e TZ=Europe/Amsterdam \
-e PUID=1000 \
-e PGID=1000 \
-d \
--restart unless-stopped \
linuxserver/syncthing


=====

Het verwachte eindresultaat is dat de morpheus-host-content van /home/will/update-scripts beschikbaar is in the morpheus-syncthing-container onder /data/home-will-update-scripts. En verstuurd naar logos.

Aan de kant van logos komt die content binnen in de container-folder /data/morpheus/home-will-update-scripts. Deze verwijst naar de host-folder /mnt/allData/syncthing/morpheus/home-will-update-scripts als eindbestemming.

=====

In de syncthing-webui krijg ik nu aan beide kanten de volgende melding:
Failed to create folder marker: mkdir <folder>.stfolder: permission denied
Terwijl de owner in beide gevallen 1000:1000 is (host en container - zie ook onderstaande output).

docker exec syncthing ls -l /data
total 12
drwxr-xr-x 2 abc users 4096 Aug 28 21:53 home-will-update-scripts
drwxr-xr-x 3 abc users 4096 Aug 29 10:28 morpheus


root@morpheus:/home/will# docker exec syncthing cat /etc/passwd
abc:x:1000:1000::/config:/bin/false

Iemand een idee hoe dat werkt met rechten in een container?
En wat er eventueel aangepast moet worden zodat syncthing zijn kunstje kan doen?

makes it run like clockwork


Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Airw0lf Ik vind het wat lastig om je verhaal te volgen, maar het lijkt erop dat de (root) folder mapping niet helemaal lekker gaat. Je zou nog met ls -ln kunnen kijken in de container én het gemounte bestandssysteem om te controleren of de permissies wel goed staan. Ik heb hier zelf recent nog over opgeschreven:

Bash:
1
2
3
4
cd /mnt/user/appdata/
mkdir syncthing
chown -R 1000:1000 syncthing
chmod -R 755 syncthing

Eventueel als sudo

Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Nog een korte update omtrent mijn avonturen rondom Caddy.

Ik heb mijn beide nodes aan Swarm gekoppeld als manager. Dat is wellicht niet super gewenst, maar anders had ik wat problemen op de tweede node met het aanmaken van het netwerk met alleen Compose. Ik gebruik namelijk Dockge voor het beheren van mijn Compose stacks, maar die ondersteund Swarm niet. Dus dat is een beetje houtje-touwtje. Maar deze aanpak werkt wel. En voor mijn persoonlijk gebruik ook niet bijster spannend. Ik kan immers alle gedeployde services met een overlay netwerk benaderen op beide nodes en dit is tevens enorm handig in gebruik.

Ook heb ik de eerder door @Mars Warrior aangeraden Caddy Level 4 proxy als plugin geïnstalleerd zodat ik TCP en UDP verkeer kan routeren met Caddy. Ik vind het alleen jammer dat dit niet zo eenvoudig te multiplexen is of op hostname kan. Ik bedoel, ik zou graag Git SSH alleen via git.mijndomein.nl benaderd willen hebben. En dus niet ook via tasks.mijndomein.nl. Dat zou met SNI wel kunnen, maar dan moet er wel een TLS handshake plaatsvinden en die is er dus niet altijd. Verder lijkt het wel aardig te werken.

Het meeste van mijn netwerkverkeer gaat nu niet meer over het ipvlan netwerk. Dit lijkt ook voordelen te hebben voor de stabiliteit van mijn thuisnetwerk. Ik weet niet hoe of wat, maar sinds ik die switch heb gemaakt lijken apparaten wat stabieler. Misschien zit dat in mijn hoofd.

Nu dus nog steeds bezig met het rustig overzetten van diensten. En ik zal er twee op het ipvlan netwerk moeten houden: Adguard Home (DNS) en Caddy.

Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
alex3305 schreef op vrijdag 30 augustus 2024 @ 16:48:
@Airw0lf Ik vind het wat lastig om je verhaal te volgen, maar het lijkt erop dat de (root) folder mapping niet helemaal lekker gaat. Je zou nog met ls -ln kunnen kijken in de container én het gemounte bestandssysteem om te controleren of de permissies wel goed staan. Ik heb hier zelf recent nog over opgeschreven:

Bash:
1
2
3
4
cd /mnt/user/appdata/
mkdir syncthing
chown -R 1000:1000 syncthing
chmod -R 755 syncthing

Eventueel als sudo
Bij syncthing krijg het ik niet aan het draaien - althans met wat ik in gedachten had:
docker run \
--name syncthing \
--network bridge \
--hostname syncthing \
-p 192.168.139.235:8384:8384 \
-p 192.168.139.235:22000:22000/tcp \
-p 192.168.139.235:22000:22000/udp \
-p 192.168.139.235:21027:21027/udp \
-v /opt/docker/syncthing/config:/config \
-v /var/syncthing:/var/data \
-e TZ=Europe/Amsterdam \
-e PUID=1900 \
-e PGID=1900 \
-d \
--restart unless-stopped \
linuxserver/syncthing


De rechten op de folder /var/syncthing zijn
drwxrwxr-x 2 syncthing root 4096 Sep 1 21:46 syncthing

En cat /etc/passwd laat het volgende zien:
syncthing:x:1900:1900::/home/syncthing:/bin/sh

De foutmelding in syncthing blijft:
2024-09-01 21:51:36: Failed to create folder root directory mkdir /var/syncthing: permission denied
2024-09-01 21:51:36: Error on folder "/var/syncthing/backups" (fgfrj-xdnmi): folder path missing


Waarbij mijn inschatting is dat de tweede melding gerelateerd is aan de eerste.

Het maakt niet uit of ik de folder /var/syncthing op voorhand aanmaak en voorzie van de juiste rechten.

Alleen als ik de data-folder ergens anders plaats dan in /var, dan loopt het wel.
Bijvoorbeeld in /home/syncthing (bron op de host) en /data (bestemming in de container). Die /var lijkt toch geen goede plek voor dit soort applicatie-data?

Tot slot: waar kan ik jou eerdere schriifsel(s) over dit onderwerp teruglezen?

makes it run like clockwork


Acties:
  • +2 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

@Airw0lf , waarom ga je in systeem mappen zitten schrijven? Dat is not done voor een normale docker container.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
Mars Warrior schreef op maandag 2 september 2024 @ 08:56:
@Airw0lf , waarom ga je in systeem mappen zitten schrijven? Dat is not done voor een normale docker container.
Ik heb ooit eens geleerd dat applicatiegegevens in /var/<applicatienaam> terecht komen - vandaar.

Maar omdat dat geen werkend iets opleverde heb ik dit nu ingeregeld via aparte gebruikers-id's en daaraan gekoppelde rechten op de folders. Die folders zitten dan weer buiten de systeemmappen.

makes it run like clockwork


Acties:
  • +2 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Airw0lf schreef op maandag 2 september 2024 @ 10:23:
[...]
Ik heb ooit eens geleerd dat applicatiegegevens in /var/<applicatienaam> terecht komen - vandaar.
Dat kan gelden voor directe installaties, maar bij Docker moet je OS en Apps compleet scheiden in aparte mappen zodat ze onafhankelijk van elkaar kunnen draaien.

Docker kan ook named volumes aanmaken. Daarvan worden de rechten door de container beheerd.
Maar omdat dat geen werkend iets opleverde heb ik dit nu ingeregeld via aparte gebruikers-id's en daaraan gekoppelde rechten op de folders. Die folders zitten dan weer buiten de systeemmappen.
Normaliter maak je een Docker map of /srv/Docker map aan op de root van je SSD of disk. En van daaruit kun je ook backups maken, en kun je altijd bij de data.

Die data kun je dus ook zo op een ander systeem zetten, met een totaal ander OS.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Airw0lf Heb jij nou een systeem user aangemaakt voor Docker :? ? Want dat hoeft niet. Of snap ik er nu even helemaal niets meer van?

Ik zou er zoiets van maken:
code:
1
2
3
mkdir -p /var/syncthing/backups
chmod -R 1900:1900 /var/syncthing
chown -R 755 /var/syncthing

Acties:
  • 0 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Mars Warrior Ik vind named volumes niet altijd super prettig werken. Ik wil daar nog eens naar kijken voor o.a. mijn databases en dan met een aparte container een backup maken naar een volume mount, maar voor applicatiedata vind ik het wel prettig om gewoon een volume mount te hebben. Ook omdat deze dan met mijn centrale backups mee kan. Ik vind named volumes enorm prettig, maar niet heel portable. En ik weet dat ik het kan exporteren, maar is toch weer een stapje extra.

Ik gebruik overigens veelal opt voor mijn Docker data. De reden dat ik hierboven naar /mnt/user/* verwees is omdat Unraid die directorystructuur gebruikt.

Acties:
  • +1 Henk 'm!

  • RobertMe
  • Registratie: Maart 2009
  • Laatst online: 21:38
Mars Warrior schreef op maandag 2 september 2024 @ 10:37:
Die data kun je dus ook zo op een ander systeem zetten, met een totaal ander OS.
Lijkt mij nogal afhankelijk van de data. Data in binairy vorm zou ik toch niet proberen te migreren tussen een 64 bits vs 32 bits OS of hardware. Of little endian vs big endian byte order. Sure, vaak kan het prima, en ook ik heb al meer dan eens datases gemigreerd door gewoon de ZFS snapshots heen en weer te sturen, maar garantie heb je niet, zeker niet cross OS of cross hardware platform.

Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
alex3305 schreef op maandag 2 september 2024 @ 11:02:
@Airw0lf Heb jij nou een systeem user aangemaakt voor Docker :? ? Want dat hoeft niet. Of snap ik er nu even helemaal niets meer van?

Ik zou er zoiets van maken:
code:
1
2
3
mkdir -p /var/syncthing/backups
chmod -R 1900:1900 /var/syncthing
chown -R 755 /var/syncthing
Dit is precies wat ik gedaan heb - en dan een per container (niks van/voor Docker zelf).
Voor syncthing is dit inderdaad 1900 - voor nextcloud 1500 - voor omada 1100 - en zo nog een paar.

Alleen heb ik chown 775 gebruikt zodat er op groups niveau dezelfde rechten kunnen gelden. Dat leek me wel handig mocht er in de nabije toekomst ooit een kruisbestuiving nodig zijn => hoef ik alleen de groeps-id's aan te passen naar iets wat past bij de gezamelijke folder(s).

De Docker data staat per container in een subfolder van /opt/docker.
Voor de data van zoiets als nextcloud en syncthing gebruik ik een subfolder van een raidvolume genaamd /mnt/allData - ook hier weer een subfolder per container.

[ Voor 13% gewijzigd door Airw0lf op 02-09-2024 11:44 ]

makes it run like clockwork


Acties:
  • 0 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Airw0lf Misschien begrijp ik dan de user mapping verkeerd, ik doe het namelijk iets anders, maar volgens mij werkt dat niet zo. Want de user mapping in de container is anders dan de user mapping op de host machine. Die kan hetzelfde zijn, maar dat hoeft niet. Dus de permissies in de container van user 1900 kunnen anders zijn dan die op de hostmachine. De enige reden dat je in Docker een andere user gebruikt is omdat standaard alles in Docker als root gedaan wordt. En dat is/was uit te buiten met bepaalde exploits.

Ik heb al mijn directories de user nobody gegeven. Op mijn Unraid machine is dat standaard user 99 met groep 100 en op mijn Debian machine user 65534 met groep 65534.

Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
alex3305 schreef op maandag 2 september 2024 @ 13:47:
@Airw0lf Misschien begrijp ik dan de user mapping verkeerd, ik doe het namelijk iets anders, maar volgens mij werkt dat niet zo. Want de user mapping in de container is anders dan de user mapping op de host machine. Die kan hetzelfde zijn, maar dat hoeft niet. Dus de permissies in de container van user 1900 kunnen anders zijn dan die op de hostmachine. De enige reden dat je in Docker een andere user gebruikt is omdat standaard alles in Docker als root gedaan wordt. En dat is/was uit te buiten met bepaalde exploits.

Ik heb al mijn directories de user nobody gegeven. Op mijn Unraid machine is dat standaard user 99 met groep 100 en op mijn Debian machine user 65534 met groep 65534.
Zie ook:https://hub.docker.com/r/linuxserver/syncthing

Hierin is te lezen dat er problemen kunnen ontstaan bij het gebruik van -v.
En dat deze voorkomen worden als de container gestart wordt met dezelfde user en group identifiers als de host - in dit voorbeeld dus 1900 en 1900:
-e PUID=1900
-e PGID=1900


Vandaar die aanvliegroute - geen idee in hoeverre dit een realistisch probleem is.
Maar aangezien ik zoveel mogelijk hun containers gebruik heb ik dit nu zo ingeregeld.

makes it run like clockwork


Acties:
  • +1 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Airw0lf schreef op maandag 2 september 2024 @ 14:01:
[...]
Zie ook:https://hub.docker.com/r/linuxserver/syncthing

Hierin is te lezen dat er problemen kunnen ontstaan bij het gebruik van -v.
En dat deze voorkomen worden als de container gestart wordt met dezelfde user en group identifiers als de host - in dit voorbeeld dus 1900 en 1900:
-e PUID=1900
-e PGID=1900


Vandaar die aanvliegroute - geen idee in hoeverre dit een realistisch probleem is.
Maar aangezien ik zoveel mogelijk hun containers gebruik heb ik dit nu zo ingeregeld.
Als je problemen wilt voorkomen met de -v optie, dan kun je ook named volumes gebruiken. Die worden weliswaar ergens in de docker map gegooid, maar in dat geval is de docker user in de container altijd eigenaar, dus nooit geen permissie problemen :D

Postgres heeft dit gezeik ook een tijd gehad. Daarna is de container slimmer geworden, en is dit redelijk opgelost.

Verder worden met named volumes natuurlijk de bestaande data overgezet, iets wat met een gekoppeld volume niet gebeurt.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
@Mars Warrior - heel eerlijk: ik heb geen idee wat een named volume eigenlijk is.

Ik ben 2-3 jaar terug begonnen met Docker containers. En heb altijd de -v optie gebruikt omdat ik dan altijd bij de gegevens kan - geen idee of er andere manieren zijn. En wat daar dan weer de pros en cons van zijn.

Twee weken terug gestart met syncthing en wat lopen te prutsen met rechten. Dat kreeg ik maar niet goed werkend.

Vervolgens een interpretatie en testen gedaan op basis van het advies van @alex3305. Dat bleek goed te werken => afgelopen weekend alle containers omgegooid naar die structuur.

makes it run like clockwork


Acties:
  • +2 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Airw0lf Named volumes zijn volumes die niet direct naar het bestandssysteem gemount staan, zoals volume mounts of bind mounts (hetzelfde met een ander naampje) Volume mounts waren ooit de enige manier om data in en uit Docker containers te krijgen. Later zijn daar Docker named volumes aan toegevoegd. Dan beheert Docker de onderliggende data.

Deze named volumes zijn kinderlijk eenvoudig in gebruik:
mkdir -p /var/syncthing
chown -R nobody:nobdy /var/syncthing
chmod -R 775 /var/syncthing

docker create volume syncthing-config
docker run -d --name syncthing \
  --restart=unless-stopped \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v syncthing-config:/config \
  -v /var/syncthing:/data \
  -e TZ=Europe/Amsterdam \
  -e PUID=1900 \
  -e PGID=1900 \
  linuxserver/syncthing:latest

Zoals je ziet verwijst de config niet naar een directory, maar naar een volume. Die volume staat dan op eenzelfde plek als bijvoorbeeld je images en container data en wordt (meestal) beheerd door de overlay driver.

Deze manier van werken is steeds belangrijker wanneer je geen controle hebt over de host machine of daar ook niet meer naartoe mag schrijven. Bijvoorbeeld met een gedistribueerde oplossing. Of wanneer je data wilt delen tussen containers. Want dat kan hiermee ook.

Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
@alex3305 - top d:)b - dank je voor de uitgebreide uitleg!

[ Voor 6% gewijzigd door Airw0lf op 02-09-2024 20:31 ]

makes it run like clockwork


Acties:
  • +2 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Ik gebruik al geruime tijd een eigen gehoste Gitea instanatie voor code. Super makkelijk in opzet met Compose:

Gitea Compose
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
---
services:
  gitea:
    container_name: gitea
    image: gitea/gitea:${GITEA_VERSION:-latest}
    restart: on-failure
    networks:
      swarm:
    environment:
      USER_UID: ${PUID:-1000}
      USER_GID: ${PGID:-1000}
    volumes:
      - ${APPDATA}/gitea:/data

networks:
  swarm:
    name: swarm-overlay
    external: true

Waarbij ik mijn externe Swarm netwerk gebruik met Caddy en de caddy-docker-proxy om Gitea extern toegankelijk te krijgen. Inclusief Git SSH toegang d:)b . Helemaal mooi ding.

Recent heb ik een Gitea Act runner toegevoegd zodat ik Gitea Actions heb. Hiermee bouw ik bijvoorbeeld ook mijn custom Caddy Docker image die ik dan op mijn host kan pullen vanuit de ingebouwde Docker registry in Gitea.

Compose met Gitea Act Runner
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
---
services:
  gitea:
    container_name: gitea
    image: gitea/gitea:${GITEA_VERSION:-latest}
    restart: on-failure
    networks:
      internal:
      swarm:
    environment:
      USER_UID: ${PUID:-1000}
      USER_GID: ${PGID:-1000}
    volumes:
      - ${APPDATA}/gitea:/data

  gitea-runner:
    container_name: gitea-runner
    image: gitea/act_runner:${GITEA_RUNNER_VERSION:-latest}-dind-rootless
    restart: on-failure
    privileged: true
    networks:
      internal:
    environment:
      DOCKER_HOST: unix:///var/run/user/1000/docker.sock
      GITEA_INSTANCE_URL: ${GITEA_INSTANCE_URL}
      GITEA_RUNNER_NAME: localhost
      GITEA_RUNNER_REGISTRATION_TOKEN: ${GITEA_RUNNER_REGISTRATION_TOKEN}
      USER_GID: "1000"
      USER_UID: "1000"
    volumes:
      - ${APPDATA}/gitea/runner:/data

networks:
  internal:
    name: ${COMPOSE_PROJECT_NAME}
  swarm:
    name: swarm-overlay
    external: true


Caddy Dockerfile
Docker:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ARG CADDY_VERSION=2.8

FROM caddy:${CADDY_VERSION}-builder-alpine AS builder
RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/greenpau/caddy-security \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/mholt/caddy-l4 \
    --with github.com/WeidiDeng/caddy-cloudflare-ip 

FROM caddy:${CADDY_VERSION}-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

RUN apk add --no-cache tzdata

ENTRYPOINT ["/usr/bin/caddy"]
CMD ["docker-proxy"]


Gitea Docker Build Action
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
---
name: Docker Build and Push
run-name: ${{ gitea.actor }} is running Docker build and push

on:
  push:
  schedule:
    - cron: "0 4 * * 0"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Login to local Gitea registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.registry }}
          username: ${{ gitea.actor }}
          password: ${{ secrets.PACKAGES_TOKEN }}
      - name: Docker Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ vars.gitea_url }}/${{ gitea.repository }}:latest


Inloggen op de host kan dan eenvoudig met:
docker login git.example.com

Hiervoor moet ik de externe URL gebruiken omdat Docker Login een beveiligde verbinding vereist. Hier kan ik dan inloggen met mijn gebruikersnaam en een PAT omdat de reguliere authenticatieflow (extern) via OAuth2 gaat.

Tot zover ben ik er blij mee :). Maar aangezien ik toch Swarm draai, dacht ik dat ik het misschien wel aardig zou zijn om ook een runner op mijn tweede node te draaien. Ik dacht dit te doen met docker stack in plaats van Compose. Alleen nu loop ik tegen het issue aan dat CPU pinning niet bestaat in Swarm :/. Dat heb ik wel nodig omdat ik processen wil pinnen op mijn E-cores. En ik heb ook niet per se het idee dat dit ooit nog geïmplementeerd gaat worden.

Ik denk dat het enige alternatief voor mij is om maar twee Compose projecten te deployen met een gedeeld Swarm netwerk. Of Kubernetes, maar daar heb ik weinig trek in voor thuis. Niet super erg, maar ik hoopte eindelijk eens Swarm te kunnen gebruiken :).

Acties:
  • 0 Henk 'm!

  • sterremos
  • Registratie: Mei 2013
  • Laatst online: 25-09 09:12
Goedemiddag, wie kan mij helpen met een issue waar ik al een tijdje meezit en ik maar niet de link kan vinden.
Ik krijg van Sonarr de melding dat '' You are using docker; download client NZBGet places downloads in /Series/Series but this directory does not appear to exist inside the container. Review your remote path mappings and container volume settings."'

Het heeft denk ik te maken met de paden in de Yaml files, maar wat ik ook probeer krijg steeds deze melding, maar bij ophalen van een aflevering wordt deze wel in de juiste map gezet, alleen maakt Sonarr er geen gezamelijke map van.

Mijn Nzbget file is volgens ondergaande, waarbij in nzbget het path /download is. en bij catergorie bv /downloads/Series, wat wel apart is, is dat nzbget dan de content daar niet plaatst maar in Nzbget/Series.

nzbget:
image: lscr.io/linuxserver/nzbget:latest
container_name: nzbget
environment:
- PUID=1000
- PGID=1000
- UMASK=0000
- TZ=Europa/Amsterdam
- NZBGET_USER=nzbget #optional
- NZBGET_PASS=tegbzn6789 #optional
volumes:
- /data/nzbget/data:/config
- /srv/dev-disk-by-uuid-ceb324e0-e7e5-4adb-84b5-8642094f1eed/Nas/Nzbget:/downloads
ports:
- 6789:6789
restart: unless-stopped[/code]

Sonarr laat ik via de yaml kijken naar de map Series volgens deze yaml.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
    volumes:
      - /data/sonarr/data:/config      
      - /srv/dev-disk-by-uuid-ceb324e0-e7e5-4adb-84b5-8642094f1eed/Nas/Nzbget/Series:/Series
    ports:
      - 8989:8989
    restart: unless-stopped


In Sonarr bij downloads clients heb ik dan
Host 192.168.2.234
Remote Path /downloads/
Local Path /Series

Bij Local maps kom je de map Series ook tegen, en als ik die opent zie ik de bestanden, maar Sonarr maakt er steeds 2 x Series van. Series/Series.

logfile

code:
1
2
3
2024-11-18 14:07:24.7|Info|Nzbget|Adding report [Barry.S04E07.A.Nice.Meal.2160p.MAX.WEB-DL.DDP5.1.HDR.DoVi.x265-NTb] to the queue.
2024-11-18 14:07:24.8|Info|DownloadService|Report sent to NZBGet. Indexer NZBFinder.ws. Barry.S04E07.A.Nice.Meal.2160p.MAX.WEB-DL.DDP5.1.HDR.DoVi.x265-NTb
2024-11-18 14:07:29.9|Error|DownloadedEpisodesImportService|Import failed, path does not exist or is not accessible by Sonarr: /Series/Series/Whitstable.Pearl.S03E04.Prisoners.of.the.Past.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb. Ensure the path exists and the user running Sonarr has the correct permissions to access this


Waar zit de fout?

Acties:
  • 0 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Ik tracht Postgres 17, of beter TimescaleDB werkende te krijgen over tls, maar ben het ff kwijt hoe ik dit nu weer naar Caddy Docker Proxy labels moet vertalen. Tijdje niet gedaan, en dan ben ik weer vergeten hoe ik de structuur moet invoeren.

@alex3305 Jij hebt ook l4 draaien toch?

Dit zou een werkende config zijn voor pg17, die sinds v17 tls ondersteund (geen gekloot meer met die custom connectie voor postgres):
JSON:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
    servers {
        listener_wrappers {
            layer4 {
                @postgres tls sni example.com
                route @postgres {
                    tls {
                      connection_policy {
                        alpn postgresql
                      }
                    }
                    proxy postgres:5432
                }
            }
            tls
        }
    }
}


Edit: ChatGPT maakt er dit van. Die mixed dus YAML met JSON om de definities om te zetten.
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
version: '3.9'
services:
  caddy:
    image: caddy:latest
    container_name: caddy
    ports:
      - "443:443"
      - "80:80"
    volumes:
      - ./data:/data
      - ./config:/config
    environment:
      - CADDY_DOCKER_MODE=true
    labels:
      caddy: example.com
      caddy.@postgres.tls.sni: "example.com"
      caddy.@postgres: |
        route {
          tls {
            connection_policy {
              alpn postgresql
            }
          }
          proxy postgres:5432
        }
  postgres:
    image: postgres:latest
    container_name: postgres
    expose:
      - "5432"

[ Voor 29% gewijzigd door Mars Warrior op 18-11-2024 16:39 ]

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • Ghoulli
  • Registratie: Juli 2021
  • Laatst online: 01-10 10:31
@sterremos Jouw foutcode beschrijft:
code:
1
 by Sonarr: /Series/Series/Whitstable.Pearl.S03E04.Prisoners.of.the.Past.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb. Ensure the path exists and the user running Sonarr has the correct permissions to access this


Een aantal vragen die misschien helpen:
1. Klopt het dat er in /Series nog een /Series map hoort te zitten?
2. Heb je de user die bij de map moet van Sonarr permissies op de dir gegeven? Heb je het probleem ook als je even de dir access geeft aan iedereen (777)?
3. Heb je de permissies recursive uitgevoerd?
4. Refereer je bij de /Series map naar een map op het apparaat zelf of naar een dir die eigenlijk via een andere container aangemaakt is?

Acties:
  • +1 Henk 'm!

  • sterremos
  • Registratie: Mei 2013
  • Laatst online: 25-09 09:12
Ghoulli schreef op maandag 18 november 2024 @ 16:14:
@sterremos Jouw foutcode beschrijft:
code:
1
 by Sonarr: /Series/Series/Whitstable.Pearl.S03E04.Prisoners.of.the.Past.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb. Ensure the path exists and the user running Sonarr has the correct permissions to access this


Een aantal vragen die misschien helpen:
1. Klopt het dat er in /Series nog een /Series map hoort te zitten?
2. Heb je de user die bij de map moet van Sonarr permissies op de dir gegeven? Heb je het probleem ook als je even de dir access geeft aan iedereen (777)?
3. Heb je de permissies recursive uitgevoerd?
4. Refereer je bij de /Series map naar een map op het apparaat zelf of naar een dir die eigenlijk via een andere container aangemaakt is?
Dank je wel voor je reactie, maar door Chatgpt ben ik eruit :)
Apart hoor , ben er de gehele weekend mee bezig geweest, en door Chat binnen een uurtje gevonden, voor het eerst eens gebruikt, maar dat gaan we vaker gebruiken...
Het pad in Nzbget voor de download main dir was niet juist, deze verwees naar een andere /downloads ?
dit aangepast en inderdaad nog eventjes permissies aangepast.
de Yaml van Sonarr was juist, de issue zat in Nzbget, omdat het pad niet juist was maakte sonarr er twee keer Series/Series van

we kunnen weer verder/

[ Voor 6% gewijzigd door sterremos op 18-11-2024 16:43 ]


Acties:
  • 0 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Mars Warrior Ik heb layer4 getemplate via Ansible naar een basis Caddyfile. Dat doe ik dus niet met de Docker Proxy. Daar staat ook nog wat andere configuratie in, waaronder auth / sso en opties die ik als 'standaard' gebruik.

Acties:
  • 0 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

alex3305 schreef op maandag 18 november 2024 @ 20:44:
@Mars Warrior Ik heb layer4 getemplate via Ansible naar een basis Caddyfile. Dat doe ik dus niet met de Docker Proxy. Daar staat ook nog wat andere configuratie in, waaronder auth / sso en opties die ik als 'standaard' gebruik.
Ah! Helemaal vergeten :D

Dan werk ik wel naar een kloppende Caddyfile via trial-and-error. Die kan ik in Portainer zien. Is ff meer werk, maar dan zal ik er op die manier uit moeten komen.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Mars Warrior In een Github issue stond wel een werkende layer4 configuratie door middel van labels.

Acties:
  • 0 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Misschien nog wel aardig om te vermelden. Na mijn vorige post over Gitea en het delen van resources over twee nodes heb ik dat toch nog werkend gekregen. Zoals ik al zei, doe ik het e.e.a. nu via Ansible. Ik heb daar geruime ervaring mee vanuit mijn werk, dus ik vind dat niet zo'n probleem. Maar ik heb het nu als volgt opgelost.

Ansible Playbook
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
---
- name: Deploy Docker Swarm and Docker configuration
  hosts: docker

  pre_tasks:
    - name: Ensure Swarm network
      community.docker.docker_network:
        name: "{{ item.name }}-overlay"
        driver: "{{ item.driver | default('overlay') }}"
        scope: "{{ item.scope | default('swarm') }}"
        attachable: "{{ item.attachable | default(true) }}"
        ipam_config: "{{ item.ipam_config | default(omit) }}"
      loop: "{{ swarm_networks }}"

  roles:
    - dockge


Group vars van `docker`
YAML:
1
2
3
swarm_networks:
  - name: swarm
  - name: gitea


Met de zelgemaakte dockge role, rol ik vervolgens Dockge uit en deploy ik tevens de relevante compose bestanden. Daarmee rol ik dus ook mijn Gitea compose uit zoals ik in mijn vorige post liet zien. Alleen heb ik nu op mijn secundaire node tevens een Gitea compose met daarin alleen een act runner:

Docker Compose - Gitea (secundaire node)
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
---
services:
  gitea-runner:
    container_name: gitea-runner
    image: gitea/act_runner:${GITEA_RUNNER_VERSION:-latest}-dind-rootless
    restart: on-failure
    privileged: true
    networks:
      internal:
    environment:
      DOCKER_HOST: unix:///var/run/user/1000/docker.sock
      GITEA_INSTANCE_URL: ${GITEA_INSTANCE_URL}
      GITEA_RUNNER_NAME: ${GITEA_RUNNER_NAME}
      GITEA_RUNNER_REGISTRATION_TOKEN: ${GITEA_RUNNER_REGISTRATION_TOKEN}
      USER_GID: "1000"
      USER_UID: "1000"
    user: 1000:1000
    volumes:
      - ${APPDATA}/gitea/runner:/data
      - /dev/shm/cache/gitea/runner:/cache

networks:
  internal:
    name: gitea-overlay
    external: true


En dit werkt nu al een weekje fantastisch.

Een vergelijkbare setup pas ik inmiddels ook toe voor mijn reverse proxy. De services op mijn secundaire host had ik namelijk ingericht met 'statische' labels bij Caddy. Maar ik heb nu een overlay netwerk gemaakt waarin ik de Docker socket via http proxy zodat Caddy er ook bij kan. Dit doe ik met socket-proxy.

Docker Compose Proxy (secundaire node)
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
---
services:
  socket-proxy:
    container_name: ${COMPOSE_PROJECT_NAME}-socket-proxy
    image: lscr.io/linuxserver/socket-proxy:${PROXY_OVERLAY_VERSION:-latest}
    hostname: "${PROXY_HOSTNAME}-socket"
    restart: unless-stopped
    read_only: true
    environment:
      AUTH: 0
      CONFIGS: 1
      CONTAINERS: 1
      DISABLE_IPV6: 1
      EVENTS: 1
      INFO: 1
      NETWORKS: 1
      NODES: 1
      POST: 0
      SERVICES: 1
      SWARM: 1
      SYSTEM: 1
      TASKS: 1
    networks:
      proxy:
    volumes:
      - type: tmpfs
        target: /run
      - /var/run/docker.sock:/var/run/docker.sock:ro

networks:
  proxy:
    name: proxy-overlay
    external: true

Waarbij ik dezelfde container naast Caddy op de primaire node heb draaien. En dan kan ik met Caddy beide Docker endpoints in de gaten houden:

Docker Compose Proxy (primaire node, snippet)
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
---
services:
  caddy:
    container_name: caddy
    networks:
      proxy:
      swarm:
      br0:
        ipv4_address: 192.168.1.2
    environment:
      CADDY_DOCKER_SOCKETS: "tcp://primary-socket:2375,tcp://secondary-socket:2375"
      CADDY_INGRESS_NETWORKS: swarm-overlay,proxy-overlay

networks:
  # Caddy network
  proxy:
    name: proxy-overlay
    external: true
  # ipvlan for exposing
  br0:
    name: br0
    external: true
  # Swarm for services
  swarm:
    name: swarm-overlay
    external: true


Wat ik wel merk is dat events van de secundaire node geen config reload lijken te triggeren. Dat gebeurt wel nadat de CADDY_DOCKER_POLLING_INTERVAL is bereikt of wanneer ik de Caddy container herstart. Dat is niet ideaal, maar geen ramp, aangezien ik niet bijster vaak aanpassingen maak op mijn secundaire node.

Acties:
  • 0 Henk 'm!

  • rens-br
  • Registratie: December 2009
  • Laatst online: 22:05

rens-br

Admin IN & Moderator Mobile
Momenteel gebruik ik een uitvoering: Asus Chromebox 2 G072U met daarop 37 dockers. Nu liep ik daar tegen wat performance problemen aan en heb ik dus een uitvoering: Dell OptiPlex 3050-DKJFJ Micro gekocht met 32GB ram en nu ben ik eigenlijk op zoek naar mijn hele docker omgeving over te zetten naar mijn nieuwe apparaat. Ik kan op internet wel vinden dat je containers / images e.d. kan exporteren en/of importeren, maar om ze nu alle 37 een voor een na te gaan is best wat werk. Zijn daar eenvoudigere manieren voor?

Acties:
  • +1 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

rens-br schreef op vrijdag 22 november 2024 @ 14:00:
Momenteel gebruik ik een uitvoering: Asus Chromebox 2 G072U met daarop 37 dockers. Nu liep ik daar tegen wat performance problemen aan en heb ik dus een uitvoering: Dell OptiPlex 3050-DKJFJ Micro gekocht met 32GB ram en nu ben ik eigenlijk op zoek naar mijn hele docker omgeving over te zetten naar mijn nieuwe apparaat. Ik kan op internet wel vinden dat je containers / images e.d. kan exporteren en/of importeren, maar om ze nu alle 37 een voor een na te gaan is best wat werk. Zijn daar eenvoudigere manieren voor?
Ik begrijp je probleem niet helemaal geloof ik.

Als je een docker compose file gebruikt, dan zouden alle images weer automatisch moeten worden binnengehaald en opgestart. Het ontgaat me dat je die moet exporteren/importeren eerlijk gezegd.

Je data is natuurlijk wat anders. Je zult weer dezelfde mappenstructuur moeten maken voor data die je wilt bewaren, en je zult die data (bijv. databases) natuurlijk wel moeten overzetten via bijv een export/import als het om een database gaat, en een tar/zip en untar/unzip als het om gewone data gaat.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • RobertMe
  • Registratie: Maart 2009
  • Laatst online: 21:38
Mars Warrior schreef op vrijdag 22 november 2024 @ 14:11:
en je zult die data (bijv. databases) natuurlijk wel moeten overzetten via bijv een export/import als het om een database gaat
Het kan ook mogelijk zijn om de database gewoon te kopieren. Wat daarbij bv wel van belang kan zijn zijn zaken als CPU architectuur, 32 vs 64 bits, little vs big endian etc. Een export en import doen is zeker veiliger en een optie die altijd werkt. Maar het kan best dat puur de bestanden overzetten ook werkt. En bij bv PostgreSQL geeft een export + import meteen de optie om te upgraden. Aangezien bij PG major versies niet compatible zijn en een los upgrade proces, of export + import, nodig is.

Maar v.w.b. compose, of shell scripts met directe docker run, of Ansible scripts, of... Zal puur het over zetten van die config / script bestanden voldoende zijn. Enige dingetje zou dan evt nog zelf gebuilde containers kunnen zijn. Maarja, ook daar kun je de Dockerfile van over zetten en opnieue builden.

Acties:
  • 0 Henk 'm!

  • rens-br
  • Registratie: December 2009
  • Laatst online: 22:05

rens-br

Admin IN & Moderator Mobile
Mars Warrior schreef op vrijdag 22 november 2024 @ 14:11:
[...]

Ik begrijp je probleem niet helemaal geloof ik.

Als je een docker compose file gebruikt, dan zouden alle images weer automatisch moeten worden binnengehaald en opgestart. Het ontgaat me dat je die moet exporteren/importeren eerlijk gezegd.
Al die images hebben toch data / settings in zich? Domoticz heb ik draaien en die heeft een mapping naar buiten (opt/Domoticz) die mappen kan ik inderdaad wel verplaatsen van oud naar nieuw. Maar bij containers die geen mapping naar buiten hebben, kan zo zelf geen voorbeelden noemen, gaat dat dan automatisch goed?

Zou ik bijvoorbeeld niet gewoon de gehele var/lib/docker map kunnen kopieren van oud naar nieuw?


Anders gezegd. Als ik bijvoorbeeld de Unifi Controller opnieuw moet installeren via de dockerfiles, dan moet ik ook alle stappen opnieuw doen. En mogelijk?/waarschijnlijk mijn configuratie opnieuw inladen, toch?

En zo heb ik meer dockers die wat zaken vereisen die ik zou moeten uitvoeren.Dus is best wel wat werk, denk ik, omdat voor 37 dockers opnieuw in te moeten stellen.

Edit:Kwam bijvoorbeeld nog dit tegen: https://www.reddit.com/r/.../18oxsk7/comment/kesuxah/, maar dat voelt ook een beetje, er kan van alles fout gaan.

[ Voor 29% gewijzigd door rens-br op 22-11-2024 14:51 ]


Acties:
  • +1 Henk 'm!

  • RobertMe
  • Registratie: Maart 2009
  • Laatst online: 21:38
rens-br schreef op vrijdag 22 november 2024 @ 14:36:
[...]


Al die images hebben toch data / settings in zich? Domoticz heb ik draaien en die heeft een mapping naar buiten (opt/Domoticz) die mappen kan ik inderdaad wel verplaatsen van oud naar nieuw. Maar bij containers die geen mapping naar buiten hebben, kan zo zelf geen voorbeelden noemen, gaat dat dan automatisch goed?

Zou ik bijvoorbeeld niet gewoon de gehele var/lib/docker map kunnen kopieren van oud naar nieuw?


Anders gezegd. Als ik bijvoorbeeld de Unifi Controller opnieuw moet installeren via de dockerfiles, dan moet ik ook alle stappen opnieuw doen. En mogelijk?/waarschijnlijk mijn configuratie opnieuw inladen, toch?

En zo heb ik meer dockers die wat zaken vereisen die ik zou moeten uitvoeren.Dus is best wel wat werk, denk ik, omdat voor 37 dockers opnieuw in te moeten stellen.

Edit:Kwam bijvoorbeeld nog dit tegen: https://www.reddit.com/r/.../18oxsk7/comment/kesuxah/, maar dat voelt ook een beetje, er kan van alles fout gaan.
Als je zelf geen mapping opgeeft dan maakt Docker automatisch een volume aan (op te vragen met docker volume ls meen ik). In hoeverre is deze kunt exporteren durf ik niet te zeggen, en daarnaast gelden daarvoor uiteraard dezelfde kanttekeningen. Kopieren werkt wellicht, maar geen garantie.

V.w.b. de UniFi controller: die heeft een ingebouwde backup (& restore) optie. Maar kopieren werkt mogelijk ook (/in mijn ervaring werkt het).

Acties:
  • +1 Henk 'm!

  • WheeleE
  • Registratie: Juni 2001
  • Laatst online: 21:42

WheeleE

Dinges

@rens-br Ik heb een paar maanden geleden een dozijn containers verhuist van een Synology naar een dockerhost op Proxmox.
Images kun je gewoon opnieuw binnenhalen op je nieuwe omgeving. De inhoud daarvan is hetzelfde, ongeacht op welke host je ze binnenhaalt.
Voor je containers die gebruik maken van die containers is er verschil tussen container die geen data of configuratie in volumes of op schijf hebben staan, en containers die dat wel hebben.

Het Hello-world image is een voorbeeld van de eerste variant. Heeft geen configuratie of persistente data. Zolang je het docker run comando of de compose-file hebt kun je de container gewoon vers aanmaken op je nieuwe host.

Voor containers met een mapping naar een lokale folder moet je de data wel zelf kopiëren.
code:
1
2
3
4
5
6
7
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /docker/portainer:/data

In dit voorbeeld uit een van mijn compose-files zou ik dus de directory /docker/portainer moeten kopiëren naar de nieuwe host.

Containers met mappings naar docker volumes vergen meer zoekwerk.
code:
1
2
3
4
5
6
services:
  app:
    image: fireflyiii/core:latest
    container_name: firefly-app
    volumes:
      - firefly_iii_upload:/var/www/html/storage/upload

Hier wordt het docker volume firefly_iii_upload gebruikt.
De data in docker volumes wordt uiteindelijk ook ergens op het filesystem van je host opgeslagen.
Als het goed is in /var/lib/docker/volumes/
De directories van de volumes die je perse nodig hebt zou je ook kunnen kopiëren naar je nieuwe host. Dat kan echter wel wat tricky zijn vanwege rechten, maar is zeker wel mogelijk.

Acties:
  • +1 Henk 'm!

  • rens-br
  • Registratie: December 2009
  • Laatst online: 22:05

rens-br

Admin IN & Moderator Mobile
RobertMe schreef op vrijdag 22 november 2024 @ 14:55:
[...]

Als je zelf geen mapping opgeeft dan maakt Docker automatisch een volume aan (op te vragen met docker volume ls meen ik). In hoeverre is deze kunt exporteren durf ik niet te zeggen, en daarnaast gelden daarvoor uiteraard dezelfde kanttekeningen. Kopieren werkt wellicht, maar geen garantie.
In ieder geval portrainer zelf maakt gebruik van zo'n volume, verder zijn er volgens Portrainer nog 12 andere volumes in gebruik.
WheeleE schreef op vrijdag 22 november 2024 @ 15:14:
@rens-br Ik heb een paar maanden geleden een dozijn containers verhuist van een Synology naar een dockerhost op Proxmox.
Images kun je gewoon opnieuw binnenhalen op je nieuwe omgeving. De inhoud daarvan is hetzelfde, ongeacht op welke host je ze binnenhaalt.
Voor je containers die gebruik maken van die containers is er verschil tussen container die geen data of configuratie in volumes of op schijf hebben staan, en containers die dat wel hebben.

Het Hello-world image is een voorbeeld van de eerste variant. Heeft geen configuratie of persistente data. Zolang je het docker run comando of de compose-file hebt kun je de container gewoon vers aanmaken op je nieuwe host.

Voor containers met een mapping naar een lokale folder moet je de data wel zelf kopiëren.
code:
1
2
3
4
5
6
7
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /docker/portainer:/data

In dit voorbeeld uit een van mijn compose-files zou ik dus de directory /docker/portainer moeten kopiëren naar de nieuwe host.

Containers met mappings naar docker volumes vergen meer zoekwerk.
code:
1
2
3
4
5
6
services:
  app:
    image: fireflyiii/core:latest
    container_name: firefly-app
    volumes:
      - firefly_iii_upload:/var/www/html/storage/upload

Hier wordt het docker volume firefly_iii_upload gebruikt.
De data in docker volumes wordt uiteindelijk ook ergens op het filesystem van je host opgeslagen.
Als het goed is in /var/lib/docker/volumes/
De directories van de volumes die je perse nodig hebt zou je ook kunnen kopiëren naar je nieuwe host. Dat kan echter wel wat tricky zijn vanwege rechten, maar is zeker wel mogelijk.
Bedankt voor de verhelderende uitleg, korte samenvatting dus:
  • Maak een backup van alle externe gebruikte mappen. (In mijn geval voornamelijk de /opt/ folder
  • Maak een backup van de volumes (/var/lib/docker/volumes)
  • Zet de backups terug
  • Installeer docker op de nieuwe machine
  • Voer daar alle docker-compose commands opnieuw uit
  • Klaar is kees?

Acties:
  • +1 Henk 'm!

  • WheeleE
  • Registratie: Juni 2001
  • Laatst online: 21:42

WheeleE

Dinges

rens-br schreef op vrijdag 22 november 2024 @ 16:30:
[...]


In ieder geval portrainer zelf maakt gebruik van zo'n volume, verder zijn er volgens Portrainer nog 12 andere volumes in gebruik.
[...]


Bedankt voor de verhelderende uitleg, korte samenvatting dus:
  • Maak een backup van alle externe gebruikte mappen. (In mijn geval voornamelijk de /opt/ folder
  • Maak een backup van de volumes (/var/lib/docker/volumes)
  • Zet de backups terug
  • Installeer docker op de nieuwe machine
  • Voer daar alle docker-compose commands opnieuw uit
  • Klaar is kees?
Volgens mij is Kees inderdaad Klaar met die samenvatting.

Voor de zekerheid zou ik wel éérst docker installeren op de nieuwe machine en daar een simpele testcontainer opzetten die gebruik maakt van een volume. Zo kun je zien welke rechten er op de bestanden in /var/lib/docker/volumes horen te staan.
En dan liever per volume:
- aanmaken in portainer
- inhoud van directory op de oude host naar directory op de nieuwe host kopiëren
- privileges corrigeren indien nodig

Portainer zou je wellicht ook vers kunnen installeren in plaats van de backup te gebruiken.
Als je dan per container/stack met de compose files de boel stap voor stap opbouwt heb je uiteindelijk weer een goedlopende en consistente omgeving. (en geen risico op conflicten uit je backup)

Acties:
  • +2 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

rens-br schreef op vrijdag 22 november 2024 @ 14:36:
[...]
Al die images hebben toch data / settings in zich? Domoticz heb ik draaien en die heeft een mapping naar buiten (opt/Domoticz) die mappen kan ik inderdaad wel verplaatsen van oud naar nieuw. Maar bij containers die geen mapping naar buiten hebben, kan zo zelf geen voorbeelden noemen, gaat dat dan automatisch goed?
Het hele punt van docker is nu juist, dat data en image gescheiden is: oftewel als jij data niet extern mapped (named volume, of een map) deze data weg is na een herstart/recreate van de container.

Dus als jij toestaat dat data in de container wordt opgeslagen en je doet een update van de container, je deze data helemaal kwijt bent: een image is nl in principe read-only!
Zou ik bijvoorbeeld niet gewoon de gehele var/lib/docker map kunnen kopieren van oud naar nieuw?


Anders gezegd. Als ik bijvoorbeeld de Unifi Controller opnieuw moet installeren via de dockerfiles, dan moet ik ook alle stappen opnieuw doen. En mogelijk?/waarschijnlijk mijn configuratie opnieuw inladen, toch?

En zo heb ik meer dockers die wat zaken vereisen die ik zou moeten uitvoeren.Dus is best wel wat werk, denk ik, omdat voor 37 dockers opnieuw in te moeten stellen.
Als jij een docker compose file gebruikt dan hoef je niks af te lopen omdat je in die compose file al kunt zien in welke mappen data staat. Die moet je dan overzetten. Je kunt daarbij de rechten ook goed overzetten als je op de juiste manier de spullekes inpakt (is een tar optie vziw).

Databases zou ik inderdaad altijd met een export/import doen. Dan zit je altijd goed, onafhankelijk van gewijzigde structuren.

Wat ik 1 keer heb gedaan is de bestaande compose file overzetten (mappen voor data al aangemaakt), dan alle containers aan laten maken (een database moet er wel zijn om te kunnnen importeren), en daarna d e data overzetten. Databases laat ik draaien voor het overzetten en de rest van de containers stop ik dan om de config/instellingen/data over te zetten. Na een herstart van de containers zou alles 1:1 moeten draaien.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Pffffffffffffffffffffffffffffffff 8)

Het is gelukt om TimescaleDB (Postgres v17++) toegang over poort 5432 in Caddy Layer4 werkend te krijgen, inclusief een TLS certificaat van Let's Encrypt.

Vanaf mijn desktop kon ik in een testje 125.000 rijen toevoegen in ca 16 seconden over een 1Gbit verbinding. Uiteindelijk moet dit richting de 500 miljoen rijen gaan (werk gerelateerd experiment).

Vanzelfsprekend omdat Postgres V17 - die nu zelf TLS ondersteund - vreselijk nieuw is, zijn er natuurlijk geen echte voorbeelden te vinden, en snapt ook ChatGPT er niks van.

De oplossing van ChatGPT die ik eerder poste klopt overigens ook van geen kant. Caddy verwijderde dit deel gewoon omdat het geen geldige configuratie voorstelde, laat staan dat er ook maar iets van Layer4 wilde werken...

Wat was het doel?
  • TimescaleDB over TLS verbinding poort 5432 op specifiek subdomein
  • Caddy die het certificaat opvraagt voor dit subdomein
  • Volledige definitie/configuratie via Docker labels (en dus de Caddy Docker Proxy plugin)
Met wat beperkingen is dit gelukt. Geen idee of ik die beperkingen nog kan fixen.
  • Layer4 vraagt een domein als label. Hierin zitten '.' karakters die de Caddy Docker Proxy plugin helaas gaat lopen omzetten. Geen idee hoe ik dit kan voorkomen.
  • Het certificaat voor het subdomein moet in de Postgres map staan, inclusief owner en r/w rechten. Dat is nu handmatig gedaan vanuit de Caddy map. Ik vermoed dat ik dit enkel met een script kan oplossen dat bijv. elke week draait om de updates van het certificaat te automatiseren.
Layer4 definities om eea te laten werken:
YAML:
1
2
3
4
5
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}= ""
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.@postgres.tls= sni ${TIMESCALEDB_VOS_DOMAIN}
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.route= "@postgres"
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.route.0_tls.connection_policy.alpn= "postgresql"
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.route.1_proxy= ${TIMESCALEDB_VOS_FULL}


Forceren TLS certificaat voor dit domein. Er is immers geen HTTP/HTTPS ingang hiervoor.
Mogelijk kan dit nog op een andere plek, namelijk bij het tls deel hierboven.
YAML:
1
2
      - caddy_1=${TIMESCALEDB_VOS_DOMAIN}
      - caddy_1.tls.issuer="acme"


De omgevingsvariabele TIMESCALEDB_VOS_FULL mag dus geen punten bevatten. Ik heb dus nu in de DNS lokaal enkel een naam ingevoerd om op de server uit te komen.

Vraag me dus af of de Layer4 definitie toch nog anders kan, zodat ik niet tegen dit probleem aanloop. Ik heb nu maar alles per regel uitgeschreven, maar of dat nodig is?

Wie weet kan de die variabele ook aan de rechterkant van het "=" teken staan net als bij het caddy_1 gedeelte voor het certificaat. Nou ja. Dat is voor later.

Edit/Update:
Vanzelfsprekend moet je in de config file van Postgres nog aangeven dat je ssl wilt, en waar dan de certificaten (.crt en .key) staan en hoe ze heten. De owner moet 70:70 zijn en beveiliging op 600, want anders wordt het certificaat geweigerd.

[ Voor 4% gewijzigd door Mars Warrior op 27-11-2024 18:44 ]

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • Kimi-Alonso
  • Registratie: Juli 2006
  • Niet online
Hebben jullie tips voor leuke 'dashboard' containers?

Voor mijn homeserver gebruik ik Homer Dashboard naar tevredenheid (zie afb). Ben benieuwd naar de dashboards van anderen.

Afbeeldingslocatie: https://tweakers.net/i/9SaGm9Qo5rWGltUkIkOrJJUzMLw=/800x/filters:strip_exif()/f/image/dAogb5gSTjHfdmvQVeGeOULJ.png?f=fotoalbum_large

Acties:
  • 0 Henk 'm!

  • Ortep
  • Registratie: Maart 2000
  • Niet online

Ortep

Soylent Green is People!

@Kimi-Alonso

Ik heb naar een aantal van die dashboards gekeken. Ook bv Heimdall. Maar ik snap het nut niet helemaal.

Dat is het voordeel boven bv een aantal tabs kiezen in een willekeurige browser en dat als 'Home Pages' bewaren?

Als je dan dat profiel opent kan je ook alle dingen benaderen.

Ik heb op die manier net als jij een Media versie, en een Synology management versie en een informatie versie

Only two things are infinite, the universe and human stupidity, Einstein
Alleen de doden kennen het einde van de oorlog, Plato


Acties:
  • +2 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Kimi-Alonso schreef op dinsdag 17 december 2024 @ 16:21:
Hebben jullie tips voor leuke 'dashboard' containers?

Voor mijn homeserver gebruik ik Homer Dashboard naar tevredenheid (zie afb). Ben benieuwd naar de dashboards van anderen.

[Afbeelding]
Leuk 8)

Ik gebruik Plugsy hiervoor. Ooit mee begonnen en niet meer verder gekeken.

@Ortep Natuurlijk als je weinig containers hebt, dan kan het ook via de browser, maar dit soort dashboards - in ieder geval Plugsy - zijn dynamisch: als ik wat toevoeg komt het op dit dashboard.

Ik heb ca 40 containers, met soms meervoudige GUI's per container. Dat is niet meer te doen met een browser tabje. Ik zou dan van 40 containers de urllen moeten onthouden. Dat doet mijn hoofd niet meer.

Van 10 vrouwen de namen onthouden is soms al een uitdaging :X

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • Freee!!
  • Registratie: December 2002
  • Laatst online: 20:58

Freee!!

Trotse papa van Toon en Len!

Ortep schreef op dinsdag 17 december 2024 @ 17:03:
@Kimi-Alonso

Ik heb naar een aantal van die dashboards gekeken. Ook bv Heimdall. Maar ik snap het nut niet helemaal.

Dat is het voordeel boven bv een aantal tabs kiezen in een willekeurige browser en dat als 'Home Pages' bewaren?

Als je dan dat profiel opent kan je ook alle dingen benaderen.

Ik heb op die manier net als jij een Media versie, en een Synology management versie en een informatie versie
Het voordeel is dat je een aantal minder gebruikte tabs, die je normaal niet open hebt staan, vlot kunt selecteren.
En ik gebruik Heimdall voor een paar portainers en een Omada controller.

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT


Acties:
  • 0 Henk 'm!

  • Kimi-Alonso
  • Registratie: Juli 2006
  • Niet online
Mars Warrior schreef op dinsdag 17 december 2024 @ 17:16:
[...]

Leuk 8)

Ik gebruik Plugsy hiervoor. Ooit mee begonnen en niet meer verder gekeken.

@Ortep Natuurlijk als je weinig containers hebt, dan kan het ook via de browser, maar dit soort dashboards - in ieder geval Plugsy - zijn dynamisch: als ik wat toevoeg komt het op dit dashboard.

Ik heb ca 40 containers, met soms meervoudige GUI's per container. Dat is niet meer te doen met een browser tabje. Ik zou dan van 40 containers de urllen moeten onthouden. Dat doet mijn hoofd niet meer.

Van 10 vrouwen de namen onthouden is soms al een uitdaging :X
Plugsy ken ik niet! Dat werkt met een docker socket connection zie ik.
Deze ga ik eens proberen, thanks!

Acties:
  • 0 Henk 'm!

  • Ortep
  • Registratie: Maart 2000
  • Niet online

Ortep

Soylent Green is People!

Mars Warrior schreef op dinsdag 17 december 2024 @ 17:16:

Ik heb ca 40 containers, met soms meervoudige GUI's per container. Dat is niet meer te doen met een browser tabje. Ik zou dan van 40 containers de urllen moeten onthouden. Dat doet mijn hoofd niet meer.
Ik heb er 20, verdeeld over 3 browser profiles. Eentje met 12 tabs en 2 met 4. Ik zit toch niet door elkaar te werken.

Als ik met de 4 Synology's die ik beheer bezig ben wil ik snel tussen de systemen kunnen schakelen.
Dan ben ik meestal niet tegelijk met Media bezig. Daarvoor start ik een ander profiel op.
Maar in theorie kan het zelfs in een enkel browser profiel als je ook nog met groepen werkt.
Dus een groep Servers met 4 tabs er in en een groep Media met 12 tabs er in.

Ik begrijp ook je opmerking over Urllen onthouden niet. Die tik je toch maar een keer in en daarna hoef je ze nooit meer in te tikken? Als ik de volgende keer de browser met dat profiel open, opent hij vanzelf de opgeslagen tabs.

Ik heb net voor de gein Heimdall nog eens in een docker container opgestart. Die doet niet wezenlijk iets anders.
Ik moet eerst (met enge moeite) allerlei buttons maken op het home scherm. En daar moet ik dan ook urellen invoeren. En als ik daar dan op klik opent hij een nieuw tabje in mijn browser.
Waarom de omweg? Ik had net zo goed gelijk de zaak in tabs kunnen zetten en dan in de instellingen kiezen voor sla huidige tabs op als home scherm. Dan hoef ik niet eerst naar Heimdall.

Ik probeer net te trollen of zo, iedereen moet werken zoals het goed voelt.
Ik probeer alleen te begrijpen waarom sommige mensen dit kiezen. Voor mij lijkt het alleen een omweg om hetzelfde te bereiken. Maar misschien mis ik iets heel belangrijks.

Only two things are infinite, the universe and human stupidity, Einstein
Alleen de doden kennen het einde van de oorlog, Plato


Acties:
  • 0 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Kimi-Alonso Ik heb een dashboard in Home Assistant gemaakt. Klein stukje:

Afbeeldingslocatie: https://tweakers.net/i/tad3UVzems6y8ohdLzcBoYRA8p0=/800x/filters:strip_exif()/f/image/14FAqd15J6ny9LhQTTrQTE1z.png?f=fotoalbum_large

Ik gebruik hiervoor wel een trucje O-) door de Tile card te modden met een subtitel:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
type: tile
entity: input_button.dummy
name: AdGuard Home
icon: mdi:dns
color: light-green
icon_tap_action:
  action: none
tap_action:
  action: url
  url_path: http://dns:3000/
card_mod:
  style:
    ha-tile-info$: |
      .secondary { 
        visibility: hidden; 
      }
      .secondary::before {
        content: 'DNS en adblocker';
        visibility: visible;
      }


Zelf gebruik ik het weinig, maar mijn vrouw vind het wel enorm prettig. Ze is nogal zelfredzaam en hierdoor hoeft ze niet altijd te vragen wat de URL ook alweer was van iets.

Acties:
  • +2 Henk 'm!

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

Ik gebruik Homepage, heb zo ongeveer alles geprobeerd en vind weinig ideaal, maar ben hierop blijven hangen :)

Afbeeldingslocatie: https://tweakers.net/i/hVbaaT87bn-NxVCHehR9yvw4Yb4=/x800/filters:strip_icc():strip_exif()/f/image/TfJ7Zky7wIHEoFIOVBOa6nRi.jpg?f=fotoalbum_large

[ Voor 20% gewijzigd door Sp33dFr34k op 17-12-2024 23:27 ]

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


Acties:
  • 0 Henk 'm!

  • RobertMe
  • Registratie: Maart 2009
  • Laatst online: 21:38
Ik ben al een tijdje op zoek naar een tool waarvan ik niet weet of die bestaat, en die ik nog niet direct heb kunnen vinden, maar misschien weten anderen hier dat wel :P

De "case" is dat ik nu compose files heb met gewoon de latest tag (of een latest achtige variant), en dus niet vast op een versie. Vervolgens ga ik periodiek de "mapjes" af en doe een docker compose up -d --pull op hoop van zegen dat alles blijft werken.
Echter heb ik ook een Gitea server draaien. En ken ik de tool Renovate om dependencies van een project te "monitoren" en pull requests aan te maken voor updates, en Renovate ondersteund daarbij ook compose files. Waar ik dus naar op zoek ben is een workflow waarbij ik per stack een Git repository aan maak en Renovate deze laat monitoren op updates. Waarbij in de compose files dus steeds specifieke versie tags gebruikt (kunnen) worden, de Renovate PR de notificatie is dat er een update is van het pakket, en de PR ook meteen een changelog bevat (en naar changelog linkt).

Echter wil ik dan wel dat als ik de PR merge, dat deze ook automatisch wordt "uitgerold". Waar ik dus op zoek ben is een tool waarin ik bv een mapping kan zetten van (lokale) mappen met bijbehorende Git repository (of alleen de map, want de git repo is uit te lezen uit de map), en die te koppelen is aan webhooks (van Gitea in dit geval). Waarbij de tool bij changes van in de repository (op basis van de webhook) vervolgens automatisch een pull van die repository doet en vervolgens een docker compose up -d

Ergo een stukje GitOps. Waarbij wijzigingen in de Git repository automatisch worden toegepast / uitgerold.

Het enige dat ik tot nu toe ben tegengekomen is Komodo die "iets" van ondersteuning voor [url=https://komo.do/docs/docker-compose]Docker Compose heeft in combinatie met Git[/mono]. Alleen kan ik daar nog niet uit op maken of die ook met de "lokale" repository werkt en dus ook alle bestanden in de repository pullt etc.. Immers zijn er ook voldoende stacks die uit "meer" bestaan. Bv een stack met Traefik wil ik ook de traefik.yaml in de repo zetten. De Home Assistant stack wil ik ook alle automations etc in dezelfde repository zetten, ... Waarbij zo'n tool pluspunten scoort als die variabel is in wat te doen. Als de compose file geupdate is doe een docker compose up -d. Als een config file veranderd is doe een docker compose restart, of roep een custom API endpoint aan, voer een script uit, you name it.

Acties:
  • 0 Henk 'm!

  • sjorsjuhmaniac
  • Registratie: Februari 2009
  • Laatst online: 20:47
RobertMe schreef op donderdag 16 januari 2025 @ 19:33:
Ik ben al een tijdje op zoek naar een tool waarvan ik niet weet of die bestaat, en die ik nog niet direct heb kunnen vinden, maar misschien weten anderen hier dat wel :P

De "case" is dat ik nu compose files heb met gewoon de latest tag (of een latest achtige variant), en dus niet vast op een versie. Vervolgens ga ik periodiek de "mapjes" af en doe een docker compose up -d --pull op hoop van zegen dat alles blijft werken.
Echter heb ik ook een Gitea server draaien. En ken ik de tool Renovate om dependencies van een project te "monitoren" en pull requests aan te maken voor updates, en Renovate ondersteund daarbij ook compose files. Waar ik dus naar op zoek ben is een workflow waarbij ik per stack een Git repository aan maak en Renovate deze laat monitoren op updates. Waarbij in de compose files dus steeds specifieke versie tags gebruikt (kunnen) worden, de Renovate PR de notificatie is dat er een update is van het pakket, en de PR ook meteen een changelog bevat (en naar changelog linkt).

Echter wil ik dan wel dat als ik de PR merge, dat deze ook automatisch wordt "uitgerold". Waar ik dus op zoek ben is een tool waarin ik bv een mapping kan zetten van (lokale) mappen met bijbehorende Git repository (of alleen de map, want de git repo is uit te lezen uit de map), en die te koppelen is aan webhooks (van Gitea in dit geval). Waarbij de tool bij changes van in de repository (op basis van de webhook) vervolgens automatisch een pull van die repository doet en vervolgens een docker compose up -d

Ergo een stukje GitOps. Waarbij wijzigingen in de Git repository automatisch worden toegepast / uitgerold.

Het enige dat ik tot nu toe ben tegengekomen is Komodo die "iets" van ondersteuning voor [url=https://komo.do/docs/docker-compose]Docker Compose heeft in combinatie met Git[/mono]. Alleen kan ik daar nog niet uit op maken of die ook met de "lokale" repository werkt en dus ook alle bestanden in de repository pullt etc.. Immers zijn er ook voldoende stacks die uit "meer" bestaan. Bv een stack met Traefik wil ik ook de traefik.yaml in de repo zetten. De Home Assistant stack wil ik ook alle automations etc in dezelfde repository zetten, ... Waarbij zo'n tool pluspunten scoort als die variabel is in wat te doen. Als de compose file geupdate is doe een docker compose up -d. Als een config file veranderd is doe een docker compose restart, of roep een custom API endpoint aan, voer een script uit, you name it.
Ik gebruik de functie zelf niet maar ik weet dat portainer i.i.g. de compose vanuit een git kan halen. Je zou eens in de documentatie kunnen kijken of het verder is wat je zoekt.


Mijn persoonlijke workflow is vergelijkbaar met wat je beschrijft, echter doe ik het met de hand. Ik loop de repo na en fetch/pull waar nodig, op mijn pc. Check de changelogs en push dat dan naar mijn eigen branch op mijn gitea. Op de server waar docker draait pull ik dan weer mijn eigen branch vanaf gitea . Daarna update ik met de hand de compose in portainer. Ik heb iets van 10stacks dus ik vind het nog te overzien.

Acties:
  • 0 Henk 'm!

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

Ik heb gewerkt met verschillende stacks, maar vond het lomp. Heb nu alles in 1 stack (+- 40 containers). Ik doe handmatig iedere maand een pull en loop dan alles na. Zelden problemen mee eigenlijk...

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


Acties:
  • 0 Henk 'm!

  • DjoeC
  • Registratie: November 2018
  • Laatst online: 22:09
Sp33dFr34k schreef op zaterdag 18 januari 2025 @ 16:04:
Ik heb gewerkt met verschillende stacks, maar vond het lomp. Heb nu alles in 1 stack (+- 40 containers). Ik doe handmatig iedere maand een pull en loop dan alles na. Zelden problemen mee eigenlijk...
Grappig... Ik hoor dit vaker maar heb nog niet (nooit) begrepen waarom alles in 1 stack beter zou zijn. Ik heb helemaal geen stacks maar alleen (nu 29) losse compose files. Portainer doet de pulls van nieuwe versies, daarna is het aan mij om de compose wel of niet opnieuw uit te voeren.

Misschien zie ik iets over t hoofd?

Acties:
  • +3 Henk 'm!

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

DjoeC schreef op zaterdag 18 januari 2025 @ 16:11:
[...]

Grappig... Ik hoor dit vaker maar heb nog niet (nooit) begrepen waarom alles in 1 stack beter zou zijn. Ik heb helemaal geen stacks maar alleen (nu 29) losse compose files. Portainer doet de pulls van nieuwe versies, daarna is het aan mij om de compose wel of niet opnieuw uit te voeren.

Misschien zie ik iets over t hoofd?
Ik gebruik geen Portainer, ik ben een CLI man ;)

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


Acties:
  • 0 Henk 'm!

  • sjorsjuhmaniac
  • Registratie: Februari 2009
  • Laatst online: 20:47
DjoeC schreef op zaterdag 18 januari 2025 @ 16:11:
[...]

Grappig... Ik hoor dit vaker maar heb nog niet (nooit) begrepen waarom alles in 1 stack beter zou zijn. Ik heb helemaal geen stacks maar alleen (nu 29) losse compose files. Portainer doet de pulls van nieuwe versies, daarna is het aan mij om de compose wel of niet opnieuw uit te voeren.

Misschien zie ik iets over t hoofd?
Een compose file == stack als je maar een node hebt.

Acties:
  • 0 Henk 'm!

  • sjorsjuhmaniac
  • Registratie: Februari 2009
  • Laatst online: 20:47
Sp33dFr34k schreef op zaterdag 18 januari 2025 @ 16:04:
Ik heb gewerkt met verschillende stacks, maar vond het lomp. Heb nu alles in 1 stack (+- 40 containers). Ik doe handmatig iedere maand een pull en loop dan alles na. Zelden problemen mee eigenlijk...
Had ik vroeger ook maar wordt snel vervelend als je meerdere services draait die afhankelijk zijn van een andere service. Met verschillende stacks kan je een service bewerken zonder dat een andere er last van hoeft te hebben. Ik heb BV mijn reverse proxy in z’n eentje in een compose staan. Die hoeft dan niet herstart te worden als ik bv een van de webservices wil updaten. Dan blijft bv de file storage gewoon beschikbaar terwijl je met de webservice bezig bent.

Maar ieder z’n ding ;)

Acties:
  • 0 Henk 'm!

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

sjorsjuhmaniac schreef op zaterdag 18 januari 2025 @ 18:13:
[...]


Had ik vroeger ook maar wordt snel vervelend als je meerdere services draait die afhankelijk zijn van een andere service. Met verschillende stacks kan je een service bewerken zonder dat een andere er last van hoeft te hebben. Ik heb BV mijn reverse proxy in z’n eentje in een compose staan. Die hoeft dan niet herstart te worden als ik bv een van de webservices wil updaten. Dan blijft bv de file storage gewoon beschikbaar terwijl je met de webservice bezig bent.

Maar ieder z’n ding ;)
Hoeft bij mij ook niet hoor ;)

Ik update meestal de service die ik wil met de containernaam in het commando. Heeft geen enkele andere container last van.

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


Acties:
  • 0 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

sjorsjuhmaniac schreef op zaterdag 18 januari 2025 @ 18:13:
[...]
Had ik vroeger ook maar wordt snel vervelend als je meerdere services draait die afhankelijk zijn van een andere service. Met verschillende stacks kan je een service bewerken zonder dat een andere er last van hoeft te hebben. Ik heb BV mijn reverse proxy in z’n eentje in een compose staan. Die hoeft dan niet herstart te worden als ik bv een van de webservices wil updaten. Dan blijft bv de file storage gewoon beschikbaar terwijl je met de webservice bezig bent.

Maar ieder z’n ding ;)
Huh?

Ik heb ook maar 1 compose file met ca 40 containers. Lekker makkelijk met al die depends_on dingen.

Als ik 1 van de services wijzig, wordt enkel die ene service ge-recreate door docker. Alle anderen blijven gewoon draaien. Tenzij er afhankelijkheden zijn, dan wordt een hele rits containers herstart.

Dus
code:
1
docker compose up -d

Natuurlijk kun je ook explixiet de container naam hierin opgeven, maar dat hoeft niet.

De 40 containers draaien circa 300 applicaties/processen 8)
De 3 grootste containers draaien al 180 processen (100 + 40 + 40).

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • sjorsjuhmaniac
  • Registratie: Februari 2009
  • Laatst online: 20:47
Aah. Ok kruip weer terug in mij hol :) het is nogal even geleden eer ik op de cli met docker bezig was.

Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Sp33dFr34k schreef op donderdag 22 augustus 2024 @ 13:51:
Afhankelijkheden, bedoelen jullie daarmee de "depends_on"? Want die doet irl niet zoveel, houdt alleen rekening met volgorde van opstarten en meer niet.
Ik weet het, dit is een wat oudere post, maar dit is wel kort door de bocht. Zet maar eens een healthcheck op de container(s) die in depends_on genoemd zijn. ;)

Ik heb overigens wél meerdere docker-compose.yml files. Ik heb de stacks eigenlijk gecategoriseerd. Containers voor de downloads zitten dan daarin. Ik heb dan vervolgens twee netwerken; $categorie en $categorie-ext. De backend containers zitten dan in het $categorie netwerk dat internal is, is er ook extern toegang nodig, krijgt de container ook het $categorie-ext netwerk. Vervolgens wordt dat al dan niet ontsloten via Traefik.

Binnenkort ga ik eens stoeien met socket-proxy voor Traefik, ipv direct de socket met :ro te mounten.

[ Voor 38% gewijzigd door CH4OS op 19-01-2025 12:12 ]


Acties:
  • 0 Henk 'm!

  • Arunia
  • Registratie: Februari 2003
  • Laatst online: 16:38
Lang geleden, maar hoop na mijn operatie gewoon wat meer hier aan te werken.
Denk dat ik docker desktop probeer te vervangen. Geloof dat dat meer zoiets is als Portainer. Die draai ik ook gewoon. Dus ben daarin met Stacks bezig. Op een enkeling na die niet binnen Portainer is gemaakt, lijkt dat gewoon prima te werken.
Moet nog steeds bekijken hoe ik dat met mijn kookboek container doe. Deze heb ik blijkbaar geen admin account voor aangemaakt. De default lijkt ook niet beschikbaar te zijn, maar dat kan ook een oudere variant zijn waardoor ik de volgende credentials heb.

Gewoon uiteindelijk alles wat netter maken en beter beheerbaar.

Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
Ik probeer via Docker-cli een Redis container te starten met een custom config file via een named volume:
code:
1
2
3
4
5
6
7
8
9
docker run \
  --name redis \
  --network host \
  -v /opt/docker/redis/redis-data:/redis-data \
  -v /opt/docker/redis/redis-config:/usr/local/etc/redis \
  -e TZ=Europe/Amsterdam \
  -d \
  --restart unless-stopped \
  docker.io/redis


Ondanks dat er een config-bestandje in de container-folder /usr/local/etc/redis
staat lijkt dit niet te worden uitgevoerd.

Het config-bestandje heet redis.conf en bevat maar één regel: bind 127.0.0.1.

Iemand suggesties?

[ Voor 9% gewijzigd door Airw0lf op 21-02-2025 11:03 ]

makes it run like clockwork


Acties:
  • 0 Henk 'm!

  • orvintax
  • Registratie: Maart 2018
  • Laatst online: 30-09 14:05

orvintax

www.fab1an.dev

Airw0lf schreef op vrijdag 21 februari 2025 @ 10:58:
Ik probeer via Docker-cli een Redis container te starten met een custom config file via een named volume:
code:
1
2
3
4
5
6
7
8
9
docker run \
  --name redis \
  --network host \
  -v /opt/docker/redis/redis-data:/redis-data \
  -v /opt/docker/redis/redis-config:/usr/local/etc/redis \
  -e TZ=Europe/Amsterdam \
  -d \
  --restart unless-stopped \
  docker.io/redis


Ondanks dat er een config-bestandje in de container-folder /usr/local/etc/redis
staat lijkt dit niet te worden uitgevoerd.

Het config-bestandje heet redis.conf en bevat maar één regel: bind 127.0.0.1.

Iemand suggesties?
Heeft de container write access naar de folder? Is een vereiste volgens Redis:
The mapped directory should be writable, as depending on the configuration and mode of operation, Redis may need to create additional configuration files or rewrite existing ones.
Als ik kijk naar hun voorbeeld runnen ze zelf ook het "redis-server" command met een path naar de config file:
$ docker run -v /myredis/conf:/usr/local/etc/redis --name myredis redis redis-server /usr/local/etc/redis/redis.conf

https://dontasktoask.com/


Acties:
  • +5 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Ik ben de laatste tijd wat minder op Tweakers te vinden, en besefte me daardoor ook dat het alweer even geleden was dat ik iets over Caddy en mijn Docker avonturen had gepost. Inmiddels heb ik in mijn homelab flink wat stappen gemaakt. Ik heb bijna alles naar Ansible gemigreerd. Professioneel heb ik daar best wat ervaring mee, maar dat was weer een flinke tijd geleden en dus weer even wennen. Aangezien dat best wel wat voeten in de aarde heeft, laat ik dat voor nu even.

Wel heb ik mijn Gitea installatie naar Forgejo gemigreerd en ben tegelijkertijd ook met Renovate aan de slag gegaan. Met Renovate kan ik eenvoudig versions pinnen en is het updaten van containers veel overzichtelijker en transparanter. Vooral ten opzichte van mijn eerdere setup met Watchtower. In mijn Renovate config heb ik ook custom managers opgenomen zodat ik in Dockerfiles en YAML files met annotations kan werken en dat Docker Compose in Jinja formaat toch gemanaged wordt. Hieronder een snippet van deze configuratie:

JSON:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
{
  "customManagers": [
    {
      "customType": "regex",
      "description": "Match renovate annotations in Dockerfiles",
      "fileMatch": ["(^|/|\\.)Dockerfile$", "(^|/)Dockerfile\\.[^/]*$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>[a-z-]+?) depName=(?<depName>.+?)(?: (?:packageName|lookupName)=(?<packageName>.+?))?(?: versioning=(?<versioning>[a-z-]+?))?\\s(?:ENV|ARG) .+?_VERSION=(?<currentValue>.+?)\\s"
      ]
    },
    {
      "customType": "regex",
      "description": "Match renovate annotations in YAML files",
      "fileMatch": ["^.*\\.ya?ml$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s(?<yamlKey>.*?)?: ['\"]?(?<currentValue>.*?)['\"]?\\s"
      ],
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
    },
    {
      "customType": "regex",
      "description": "Docker Compose Jinja",
      "fileMatch": "(^|/)(?:docker-)?compose[^/]*\\.ya?ml?\\.j2$",
      "matchStrings": [
        "(?:image: \\\"?)(?<depName>.*?)(?::(?<currentValue>.*?))?(?:@(?<currentDigest>sha256:[a-f0-9]+))?\\\"?\\n"
      ],
      "datasourceTemplate": "docker",
      "versioningTemplate": "docker"
    }
  ]
}


Ik gebruik dit bijvoorbeeld in mijn Caddy Dockerfile:

Docker:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# renovate: datasource=github-releases depName=caddyserver/caddy
ARG CADDY_VERSION=2.9.1

FROM caddy:${CADDY_VERSION}-builder-alpine AS builder
RUN GOTOOLCHAIN=go1.24.1 xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/greenpau/caddy-security \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/mholt/caddy-l4 \
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/WeidiDeng/caddy-cloudflare-ip

FROM caddy:${CADDY_VERSION}-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

RUN apk add --no-cache tzdata

LABEL org.opencontainers.image.source="https://github.com/caddyserver/caddy"

ENTRYPOINT ["/usr/bin/caddy"]
CMD ["docker-proxy"]


Waarbij het version pinnen van de modules nog op het todo lijstje staat ;).

Met mijn migratie van Gitea naar Forgejo vond ik het wel enorm jammer dat er geen complete Forgejo runner dind image was zoals bij Gitea. ik heb een tijdje proberen aan te klooien met twee losse containers (runner en dind), maar dat vond ik enorm omslachtig en kreeg het uiteindelijk ook niet werkend. Daarom heb ik hier uiteindelijk een eigen custom image voor gebouwd op basis van de Gitea en Forgejo code. Ik wil dit nog (open source) beschikbaar gaan stellen, maar ben ik nog niet aan toegekomen.

Voortbordurend op Caddy ben ik echt enorm te spreken over mijn setup die ik al een keer eerder heb genoemd met, Caddy Docker Proxy, Caddy Layer4, Caddy Security en Docker labels. Voor Forgejo ziet er dit als Ansible template bijvoorbeeld zo uit:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#jinja2: lstrip_blocks: "True", trim_blocks: "True"
---
# {{ ansible_managed }}

services:
  forgejo:
    container_name: {{ role_name }}
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: {{ forgejo_user_id }}
      USER_GID: {{ forgejo_group_id }}
    networks:
      internal:
      ingress:
    volumes:
      - {{ forgejo_appdata }}:/data
      - /etc/localtime:/etc/localtime:ro
    {% if forgejo_docker_options is defined %}
    {{ forgejo_docker_options | to_nice_yaml | indent(4) }}
    {%- endif %}
    labels:
      caddy_1: "{{ forgejo_domain }}"
      caddy_1.@{{ docker_compose_project_name }}.import: "local-ip-whitelist"
      caddy_1.@{{ docker_compose_project_name }}.host: "{{ forgejo_domain }}"
      caddy_1.handle: "@{{ docker_compose_project_name }}"
      caddy_1.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.ssh:
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.remote_ip: "{{ local_ip_range }}"
      caddy_2.layer4.:22.route: "@{{ docker_compose_project_name }}-ssh"
      caddy_2.layer4.:22.route.proxy: "{{ '{{' }}upstreams 22{{ '}}' }}"
      {%- if "unraid" in (ansible_kernel | lower) +%}
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash
      {% endif %}

networks:
  internal:
    name: {{ forgejo_overlay_network }}
    external: true
  ingress:
    name: {{ swarm_overlay_network }}
    external: true

En gerendered dan zo:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
---
# Ansible Managed

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: 2001
      USER_GID: 2001
    networks:
      internal:
      ingress:
    volumes:
      - /mnt/applications/appdata/forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    cpus: 2
    cpuset: 12-15
    labels:
      caddy_1: "example.com"
      caddy_1.@forgejo.import: "local-ip-whitelist"
      caddy_1.@forgejo.host: "example.com"
      caddy_1.handle: "@forgejo"
      caddy_1.handle.reverse_proxy: "{{upstreams 80}}"
      caddy_2.layer4.:22.@forgejo-ssh.ssh:
      caddy_2.layer4.:22.@forgejo-ssh.remote_ip: "192.168.0.0/16"
      caddy_2.layer4.:22.route: "@forgejo-ssh"
      caddy_2.layer4.:22.route.proxy: "{{upstreams 22}}"
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash

networks:
  internal:
    name: forgejo-overlay
    external: true
  ingress:
    name: swarm-overlay
    external: true


Daarbij vind ik het echt heel fijn dat dit dynamisch uitgerold wordt. Dat verminderd de beheerlast met bijvoorbeeld een tool zoals Nginx Proxy Manager aanzienlijk.

Bij een push of pull request (update) wordt er automatisch een Forgejo workflow getriggerd. Dit gebeurd standaard als dry-run om in ieder geval het playbook te kunnen test. En afhankelijk van de applicatie wordt er bij een merge naar de hoofdbranch een daadwerkelijke uitrol gedaan. Dus ook bij applicatie updates. Zo'n workflow triggered dan een Ansible playbook die vervolgens na template actie(s) een Docker Compose Up doet op de target machine. Waarbij ik Docker Compose tevens manage via Ansible, Forgejo (Actions) en Renovate ;).

Grootste project waar ik momenteel nog mee bezig ben is het SSO migreren naar Pocket ID. Dat heeft alleen niet bijster veel met Docker te maken :9.

Acties:
  • 0 Henk 'm!

  • DjoeC
  • Registratie: November 2018
  • Laatst online: 22:09
@alex3305 Tja, wat jij gedaan hebt en hier beschrijft is hoe ik het graag zou willen hebben ;) Helaas ontbreekt het mij aan een stuk basiskennis op dit vlak. Zelfs jaren in (een andere hoek van) de IT bekenet niet dat ik alles zomaar ken en kan...

Dan brengt t voorjaar ook nog eens flink wat huis en tuinklussen die voorrang gaan krijgen.

Maar, ik heb je post gebookmarked om zo af en toe te gebruiken als vertrekpunt bij kennis opbouwen. Dank dus voor die post!

Acties:
  • +3 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@DjoeC Het is misschien wat veel voor een GoT post. En het is ook niet alles :|. Maar ik moet zeggen dat Renovate bijvoorbeeld kinderlijk eenvoudig was om mee te starten :o. Mijn eigen documentatie is ook erg kort en daarin verwijs ik naar een Gitea pagina / blogpost en een blogpost van Logan Marchione. Ik gebruik dan de volgende workflow:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
name: Run Renovate

# yamllint disable-line rule:truthy
on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:
    inputs:
      log_level:
        description: Log level
        required: true
        default: info
        type: choice
        options:
          - debug
          - info
          - warn
          - error
          - fatal

concurrency:
  group: ${{ github.workflow }}
  cancel-in-progress: true

jobs:
  renovate:
    name: Renovate
    runs-on: docker
    container: ghcr.io/renovatebot/renovate:39.223.0
    timeout-minutes: 30
    steps:
      - name: ⤵️ Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: 🧾 Set log level
        id: log_level
        run: |
          LOG_LEVEL_INPUT=${{ inputs.log_level }}
          echo "::set-output name=level::${LOG_LEVEL_INPUT:-"info"}"

      - name: 🚀 Renovate
        run: renovate
        env:
          LOG_LEVEL: ${{ steps.log_level.outputs.level }}
          DOCKER_HUB_USERNAME: ${{ vars.RENOVATE_DOCKER_HUB_USERNAME }}
          DOCKER_HUB_PASSWORD: ${{ secrets.RENOVATE_DOCKER_HUB_TOKEN }}
          GITEA_REGISTRY_USERNAME: ${{ vars.RENOVATE_GITEA_REGISTRY_USERNAME }}
          GITEA_REGISTRY_PASSWORD: ${{ secrets.RENOVATE_GITEA_REGISTRY_TOKEN }}
          GITHUB_COM_TOKEN: ${{ secrets.RENOVATE_GITHUB_COM_TOKEN }}
          RENOVATE_CONFIG_FILE: 'config.js'
          RENOVATE_CONFIG_MIGRATION: 'true'
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}


Met daarna wat slim gekozen instellingen is het vervolgens redelijk hands-off en laat ik Renovate bot het werk doen:
Afbeeldingslocatie: https://tweakers.net/i/BT3m9bxsCjQuj3uvN-R2CuXxhms=/800x/filters:strip_exif()/f/image/M797tIRh1FBQKoCrz5OSZ5Bs.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/g4utv-bUEjrZa8EPDpPqhQohU04=/800x/filters:strip_exif()/f/image/UjBcjzvrHG9HvrcyLZ54eD8r.png?f=fotoalbum_large

Dat noem ik nogmaals omdat ik merk dat Renovate mij enorm veel werk uit handen heeft genomen. Als in dat ik niet hoef te controleren of er versie-updates zijn. En wanneer ik dan ga of wil updaten. Ook kan ik Renovate op pauze zetten bij bijvoorbeeld vakanties of bepaalde applicaties niet automatisch updaten. Dat is niet zo transparant of evident bij een tool zoals Watchtower.

Toen ik laatst bijvoorbeeld dit issue in Stirling PDF tegenkwam kon ik direct terug naar een oude(re) versie omdat ik wist welke versie (de vorige) nog werkte. En als klap op de vuurpijl heb ik ook de build status van de main branch in de readme:

Afbeeldingslocatie: https://tweakers.net/i/n6K4WzBZU-lyD0aSCuijB3Kfn04=/800x/filters:strip_exif()/f/image/1KmRAGyasmiWGGgC0f3cFgcC.png?f=fotoalbum_large

Ik wil hier nog graag de huidige versienummers bij hebben, maar op deze manier kan ik ook al zien wat de build / deployment status is.

Allemaal verbeteringen die initieel wel wat (meer) tijd kosten, maar uiteindelijk door het gebrek aan aanvullend onderhoud weer veel tijd opleveren om andere leuke dingen te doen :).

Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
Klinkt goed en ziet er fraai uit. Hoe verhoudt zich dit tot Kubernetes?

[ Voor 31% gewijzigd door Airw0lf op 31-03-2025 17:48 ]

makes it run like clockwork


Acties:
  • +2 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Airw0lf schreef op maandag 31 maart 2025 @ 17:48:
Klinkt goed en ziet er fraai uit. Hoe verhoudt zich dit tot Kubernetes?
Goede vraag, maar dat is een beetje appels en peren vergelijken.

Als je degelijke Kubernetes deploys hebt, heb je ook nog abstractie van systemen. Dat houdt in dat je applicaties deployed op je Kubernetes cluster. Het is dan aan de orchestrator en scheduler om op de applicatie op de juiste plek(ken) neer te zetten. Dat is fantastisch als je meerdere systemen hebt die (redelijk) gelijk aan elkaar zijn, maar wat mij betreft ongeschikt als de onderliggende systemen veel van elkaar verschillen. Zoals bij mij. Mijn primaire machine is 10x sneller dan mijn secundaire.

Daarmee kom ik ook meteen op het volgende struikelblok, ik heb (in principe) maar 2 systemen. 1 te weinig voor een minimaal gezond HA cluster van 3 systemen. Ik weet dat er manieren zijn om een cluster te draaien met 1 of 2 machines, maar ik zie het niet zo zitten om een kapot cluster te hebben als ik de master node reboot.

Ook is Kubernetes niet bepaald lichtgewicht. Ik weet niet of CPU affinity (wat ik veel gebruik) ondersteund wordt, volgens mij niet. In Docker Swarm deployments in ieder geval ook niet, vandaar dat ik dat ook niet gebruik. Het mappen van hardware (Zigbee en Z-Wave dongles) is niet altijd evident. En dan heb ik het nog niet over storage gehad :X.

Voor mijn thuissituatie is Docker met Docker Compose vanuit Ansible voor deployments en Docker Swarm voor networking dus ruim voldoende. Vanuit Docker Swarm gebruik ik toch alleen maar overlay networking.

Ansible vind ik ook niet altijd je-van-het. Voornamelijk door de enorm hoge initiële drempel, maar aangezien ik daar al bekend mee was, was dat voor mij geen probleem. En daarnaast heb ik dit ook niet in één keer opgezet hè. Mijn eerste compose config in Git is misschien ook al van 10 jaar geleden.

Acties:
  • 0 Henk 'm!

  • orvintax
  • Registratie: Maart 2018
  • Laatst online: 30-09 14:05

orvintax

www.fab1an.dev

alex3305 schreef op maandag 31 maart 2025 @ 14:53:
Ik ben de laatste tijd wat minder op Tweakers te vinden, en besefte me daardoor ook dat het alweer even geleden was dat ik iets over Caddy en mijn Docker avonturen had gepost. Inmiddels heb ik in mijn homelab flink wat stappen gemaakt. Ik heb bijna alles naar Ansible gemigreerd. Professioneel heb ik daar best wat ervaring mee, maar dat was weer een flinke tijd geleden en dus weer even wennen. Aangezien dat best wel wat voeten in de aarde heeft, laat ik dat voor nu even.

Wel heb ik mijn Gitea installatie naar Forgejo gemigreerd en ben tegelijkertijd ook met Renovate aan de slag gegaan. Met Renovate kan ik eenvoudig versions pinnen en is het updaten van containers veel overzichtelijker en transparanter. Vooral ten opzichte van mijn eerdere setup met Watchtower. In mijn Renovate config heb ik ook custom managers opgenomen zodat ik in Dockerfiles en YAML files met annotations kan werken en dat Docker Compose in Jinja formaat toch gemanaged wordt. Hieronder een snippet van deze configuratie:

JSON:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
{
  "customManagers": [
    {
      "customType": "regex",
      "description": "Match renovate annotations in Dockerfiles",
      "fileMatch": ["(^|/|\\.)Dockerfile$", "(^|/)Dockerfile\\.[^/]*$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>[a-z-]+?) depName=(?<depName>.+?)(?: (?:packageName|lookupName)=(?<packageName>.+?))?(?: versioning=(?<versioning>[a-z-]+?))?\\s(?:ENV|ARG) .+?_VERSION=(?<currentValue>.+?)\\s"
      ]
    },
    {
      "customType": "regex",
      "description": "Match renovate annotations in YAML files",
      "fileMatch": ["^.*\\.ya?ml$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s(?<yamlKey>.*?)?: ['\"]?(?<currentValue>.*?)['\"]?\\s"
      ],
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
    },
    {
      "customType": "regex",
      "description": "Docker Compose Jinja",
      "fileMatch": "(^|/)(?:docker-)?compose[^/]*\\.ya?ml?\\.j2$",
      "matchStrings": [
        "(?:image: \\\"?)(?<depName>.*?)(?::(?<currentValue>.*?))?(?:@(?<currentDigest>sha256:[a-f0-9]+))?\\\"?\\n"
      ],
      "datasourceTemplate": "docker",
      "versioningTemplate": "docker"
    }
  ]
}


Ik gebruik dit bijvoorbeeld in mijn Caddy Dockerfile:

Docker:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# renovate: datasource=github-releases depName=caddyserver/caddy
ARG CADDY_VERSION=2.9.1

FROM caddy:${CADDY_VERSION}-builder-alpine AS builder
RUN GOTOOLCHAIN=go1.24.1 xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/greenpau/caddy-security \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/mholt/caddy-l4 \
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/WeidiDeng/caddy-cloudflare-ip

FROM caddy:${CADDY_VERSION}-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

RUN apk add --no-cache tzdata

LABEL org.opencontainers.image.source="https://github.com/caddyserver/caddy"

ENTRYPOINT ["/usr/bin/caddy"]
CMD ["docker-proxy"]


Waarbij het version pinnen van de modules nog op het todo lijstje staat ;).

Met mijn migratie van Gitea naar Forgejo vond ik het wel enorm jammer dat er geen complete Forgejo runner dind image was zoals bij Gitea. ik heb een tijdje proberen aan te klooien met twee losse containers (runner en dind), maar dat vond ik enorm omslachtig en kreeg het uiteindelijk ook niet werkend. Daarom heb ik hier uiteindelijk een eigen custom image voor gebouwd op basis van de Gitea en Forgejo code. Ik wil dit nog (open source) beschikbaar gaan stellen, maar ben ik nog niet aan toegekomen.

Voortbordurend op Caddy ben ik echt enorm te spreken over mijn setup die ik al een keer eerder heb genoemd met, Caddy Docker Proxy, Caddy Layer4, Caddy Security en Docker labels. Voor Forgejo ziet er dit als Ansible template bijvoorbeeld zo uit:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#jinja2: lstrip_blocks: "True", trim_blocks: "True"
---
# {{ ansible_managed }}

services:
  forgejo:
    container_name: {{ role_name }}
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: {{ forgejo_user_id }}
      USER_GID: {{ forgejo_group_id }}
    networks:
      internal:
      ingress:
    volumes:
      - {{ forgejo_appdata }}:/data
      - /etc/localtime:/etc/localtime:ro
    {% if forgejo_docker_options is defined %}
    {{ forgejo_docker_options | to_nice_yaml | indent(4) }}
    {%- endif %}
    labels:
      caddy_1: "{{ forgejo_domain }}"
      caddy_1.@{{ docker_compose_project_name }}.import: "local-ip-whitelist"
      caddy_1.@{{ docker_compose_project_name }}.host: "{{ forgejo_domain }}"
      caddy_1.handle: "@{{ docker_compose_project_name }}"
      caddy_1.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.ssh:
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.remote_ip: "{{ local_ip_range }}"
      caddy_2.layer4.:22.route: "@{{ docker_compose_project_name }}-ssh"
      caddy_2.layer4.:22.route.proxy: "{{ '{{' }}upstreams 22{{ '}}' }}"
      {%- if "unraid" in (ansible_kernel | lower) +%}
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash
      {% endif %}

networks:
  internal:
    name: {{ forgejo_overlay_network }}
    external: true
  ingress:
    name: {{ swarm_overlay_network }}
    external: true

En gerendered dan zo:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
---
# Ansible Managed

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: 2001
      USER_GID: 2001
    networks:
      internal:
      ingress:
    volumes:
      - /mnt/applications/appdata/forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    cpus: 2
    cpuset: 12-15
    labels:
      caddy_1: "example.com"
      caddy_1.@forgejo.import: "local-ip-whitelist"
      caddy_1.@forgejo.host: "example.com"
      caddy_1.handle: "@forgejo"
      caddy_1.handle.reverse_proxy: "{{upstreams 80}}"
      caddy_2.layer4.:22.@forgejo-ssh.ssh:
      caddy_2.layer4.:22.@forgejo-ssh.remote_ip: "192.168.0.0/16"
      caddy_2.layer4.:22.route: "@forgejo-ssh"
      caddy_2.layer4.:22.route.proxy: "{{upstreams 22}}"
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash

networks:
  internal:
    name: forgejo-overlay
    external: true
  ingress:
    name: swarm-overlay
    external: true


Daarbij vind ik het echt heel fijn dat dit dynamisch uitgerold wordt. Dat verminderd de beheerlast met bijvoorbeeld een tool zoals Nginx Proxy Manager aanzienlijk.

Bij een push of pull request (update) wordt er automatisch een Forgejo workflow getriggerd. Dit gebeurd standaard als dry-run om in ieder geval het playbook te kunnen test. En afhankelijk van de applicatie wordt er bij een merge naar de hoofdbranch een daadwerkelijke uitrol gedaan. Dus ook bij applicatie updates. Zo'n workflow triggered dan een Ansible playbook die vervolgens na template actie(s) een Docker Compose Up doet op de target machine. Waarbij ik Docker Compose tevens manage via Ansible, Forgejo (Actions) en Renovate ;).

Grootste project waar ik momenteel nog mee bezig ben is het SSO migreren naar Pocket ID. Dat heeft alleen niet bijster veel met Docker te maken :9.
Interessante post om te lezen. Coole setup! Ik was in eerste instantie wel verward hoe je Watchtower had "vervangen" door Renovate. Maar als ik het goed begrijp kickt je pipeline een Ansible playbook af die de daadwerkelijke update doet op je Docker host. Dus het is meer de samenwerking tussen Renovate en Ansible die dan het stukje Watchtower vervangt.

Ik ben zelf tegenwoordig wel meer van het eenvoudig te houden. Dus ik laat Renovate lekker gaan, Gitlab CI/CD publisht de image dan naar een container registry. Vervolgens draait Watchtower om de zoveel uur om de update binnen te trekken. Good ol' polling.

https://dontasktoask.com/


Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
orvintax schreef op dinsdag 1 april 2025 @ 14:57:
[...]

Interessante post om te lezen. Coole setup! Ik was in eerste instantie wel verward hoe je Watchtower had "vervangen" door Renovate. Maar als ik het goed begrijp kickt je pipeline een Ansible playbook af die de daadwerkelijke update doet op je Docker host. Dus het is meer de samenwerking tussen Renovate en Ansible die dan het stukje Watchtower vervangt.
Misschien omdat ik wat teveel in de materie zit, dat ik wellicht over wat details heen ben gevlogen :). Eerder controleerde Watchtower (bij mij) iedere dag of er updates voor containers waren. Ik had per Docker Compose stack een aparte Watchtower container draaien zodat dit proces nog enigszins beheersbaar was. Echter gaf het me totaal geen inzicht welke versie nu waar draaide.

Tegelijkertijd beheer(de) ik mijn Docker Compose stacks met Dockge. De Docker Compose stacks kopieerde ik bij aanpassingen handmatig in Dockge. De eerste stap die ik heb gemaakt is om deze met Ansible automatisch over te zetten. Ik gebruikte hiervoor de onderstaande Ansible playbook:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
- name: Deploy Docker Compose
  hosts: docker

  tasks:
    - name: Ensure remote directories
      ansible.builtin.file:
        path: "/opt/appdata/dockge/stacks/{{ item.path }}"
        state: directory
        mode: "0755"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'directory'

    - name: Copy regular files
      ansible.builtin.copy:
        src: "{{ item.src }}"
        dest: "/opt/appdata/dockge/stacks/{{ item.path }}"
        mode: "0644"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'file' and (item.src | splitext | last) != '.j2'

    - name: Template Jinja .j2 files
      ansible.builtin.template:
        src: "{{ item.src }}"
        dest: "/opt/appdata/dockge/stacks/{{ item.path | splitext | first }}"
        mode: "0644"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'file' and (item.src | splitext | last) == '.j2'

Voor dit voorbeeld en de leesbaarheid heb ik zoveel mogelijk Ansible-eigen constructies eruit gehaald, maar er zijn slimmere manieren om bijvoorbeeld paden aan elkaar te plakken.

De directory layout die ik dan gebruikte was:
┌── compose
│   └── hostnameA/
│       └── adguard_home/
│           └── compose.yaml
│       └── home_assistant/
│           └── compose.yaml
│           └── .env
│   └── hostnameB/
│       └── adguard_home/
│           └── compose.yaml
│       └── zigbee2mqtt/
│           └── compose.yaml
│           └── .env.j2


Dat was voor mij al een enorme verbetering omdat ik hiermee in ieder geval de Compose bestanden niet meer handmatig - en dus foutgevoelig - in hoefde te voeren. Je zou zelfs de onderste stap weg kunnen laten en alleen kopiëren. Ook dat verminderd de complexiteit aanzienlijk.

Je zou dit ook met Forgejo, Gitea of GitLab CI en zoiets als scp kunnen doen. Ik heb vooral Ansible gekozen vanwege het Jinja templaten. En vanaf hier was Renovate eigenlijk een paar kleine stappen.

1. Als eerste heb ik een Renovate user aangemaakt genaamd renovate-bot met hetzelfde e-mailadres als in de configuratie hieronder. Je mag dit zelf kiezen :).

2. Voor deze user heb ik een repo aangemaakt genaamd renovate-config.
In die repo zit een secret genaamd RENOVATE_TOKEN en dat is een Personal Access Token met de permissies conform de Renovate documentatie.

3. Ik heb een standaard Renovate config aangemaakt genaamd config.js met uiteraard de juiste gegevens / parameters.
JavaScript:
1
2
3
4
5
6
7
8
9
10
11
12
13
module.exports = {
  platform: 'gitea',
  endpoint: 'https://git.example.com/api/v1/',
  gitAuthor: 'Renovate Bot <renovate@users.noreply.github.com>',
  username: 'renovate-bot',
  autodiscover: true,
  onboardingConfig: {
    $schema: 'https://docs.renovatebot.com/renovate-schema.json',
    extends: ['config:recommended']
  },
  optimizeForDisabled: true,
  persistRepoData: true,
}


4. Vervolgens heb ik een workflow aangemaakt in .forgejo/workflows in dezelfde repository met een hele basic workflow:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
---
name: Renovate

# yamllint disable-line rule:truthy
on:
  schedule:
    - cron: "@daily"
  workflow_dispatch:

jobs:
  renovate:
    runs-on: ubuntu-latest
    container: ghcr.io/renovatebot/renovate:39.229.0
    steps:
      - uses: actions/checkout@v4
      - run: renovate
        env:
          RENOVATE_CONFIG_FILE: "config.js"
          LOG_LEVEL: "debug"
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}


5. En als laatste stap heb ik de renovate-bot toegevoegd aan de repositories waarin ik Renovate wil hebben.

Daarna kon ik een run starten en werkte het... Natuurlijk pakt Renovate geen latest op en moet je zelf eerst de juiste versies intikken. En daarnaast heb ik uiteraard mijn configuratie verder uitgebreid met bijvoorbeeld een dependency dashboard en custom matchers, maar dat hoeft allemaal niet. Daar ben ik ook pas na een maand of anderhalf mee gestart. In ieder geval was ik nu wel af van alle :latest-tags, Watchtower containers (laatste update meer dan 1 jaar geleden!) en had ik transparantie van updates.
Ik ben zelf tegenwoordig wel meer van het eenvoudig te houden. Dus ik laat Renovate lekker gaan, Gitlab CI/CD publisht de image dan naar een container registry. Vervolgens draait Watchtower om de zoveel uur om de update binnen te trekken. Good ol' polling.
Ieder z'n ding :). Ik zeg ook niet dat mijn oplossing het einddoel is, maar ik vind het zo verdomd makkelijk werken. En zoals je misschien merkt heb ik me echt verbaasd over de enorm eenvoudige setup.

Acties:
  • 0 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Harstikke leuk en luxe @alex3305 _/-\o_

Ik doe al mijn 40 containers nog steeds handmatig :X

Die staan dus iha op vaste versies, en eens in de zoveel tijd kijk ik in de changelog en doe een update. Ik haat namelijk breaking changes :F

En sommige van mijn containers gebruiken een Ansible playbook intern om de container te initialiseren en te starten: dat is tergend traag, en er worden soms dingen gereset in de config die de container kapot maken.

Andere containers draaien wel in docker, maar zijn feitelijk old-school: je moet bij een upgrade òf een upgrade container draaien voor de nieuwe versie, òf handmatig een backup maken en later weer importeren.

En Yep, betaalde legacy software die nooit gebouwd is voor docker :D

Ik heb ook nog steeds één compose file. Soms handig, en soms niet. Ik zou dit wel in aparte stacks willen onderbrengen, maar er zijn dikke afhankelijkheden onderling.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • Airw0lf
  • Registratie: Mei 2005
  • Laatst online: 30-09 09:21
Op dit moment gebruik ik op elke docker host een aantal docker-cli scripts om (handmatig) containers te starten. Deze worden wekelijks door watchtower bijgewerkt naar de laatste versie.

Dit zou ik willen automatiseren/verbeteren. Het idee is om te werken met een centrale repository waarin ik per docker host kan aangeven welke containers er gestart moeten worden en met welke parameters. Vervolgens wordt er "iets" aangemaakt en gestart. Bijvoorbeeld in de vorm van een docker compose bestand.

Parallel hieraan loopt er wekelijks een update proces - dat mag watchtower zijn. Maar een wekelijkse compose-down en up is ook prima.

Van deze acties zou ik graag een dashboard hebben waarin is te zien wat de status is van elke container, wat het versienummer is, of er een nieuwere versie is en wat het resultaat is geweest van de laatste 3 update/upgrade acties.

Iemand een idee wat hiervoor een handige aanpak/marsroute is?

makes it run like clockwork


Acties:
  • 0 Henk 'm!

  • Sp33dFr34k
  • Registratie: Juni 2006
  • Niet online

Sp33dFr34k

Retro-Geek

Mars Warrior schreef op dinsdag 1 april 2025 @ 16:43:
Harstikke leuk en luxe @alex3305 _/-\o_

Ik doe al mijn 40 containers nog steeds handmatig :X

Die staan dus iha op vaste versies, en eens in de zoveel tijd kijk ik in de changelog en doe een update. Ik haat namelijk breaking changes :F

En sommige van mijn containers gebruiken een Ansible playbook intern om de container te initialiseren en te starten: dat is tergend traag, en er worden soms dingen gereset in de config die de container kapot maken.

Andere containers draaien wel in docker, maar zijn feitelijk old-school: je moet bij een upgrade òf een upgrade container draaien voor de nieuwe versie, òf handmatig een backup maken en later weer importeren.

En Yep, betaalde legacy software die nooit gebouwd is voor docker :D

Ik heb ook nog steeds één compose file. Soms handig, en soms niet. Ik zou dit wel in aparte stacks willen onderbrengen, maar er zijn dikke afhankelijkheden onderling.
Niets mis mee toch, ik zit ook rond de 40 containers, en doe ze ook handmatig :)

Eerst zat ik met Watchtower continue automatisch te updaten, wat weleens iets brak en dan is het moeilijk terug te herleiden. Nu reserveer ik 1 keer in de maand een uurtje, met 3 commando's heb je weer alles up-to-date. Effe snel checken of er niets kapot is en weer door. Ik vind het prima zo.

i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte RTX5070Ti | Samsung 970 Pro 512GB + 860 EVO 1TB + 860 QVO 4TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Samsung Oddyssey G7 Neo | Edifier M60


Acties:
  • 0 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
Mars Warrior schreef op dinsdag 1 april 2025 @ 16:43:
Ik doe al mijn 40 containers nog steeds handmatig :X
Hey, ook niets mis mee. Zolang het werkt is het niet dom :).
Die staan dus iha op vaste versies, en eens in de zoveel tijd kijk ik in de changelog en doe een update. Ik haat namelijk breaking changes :F
Same here. Dat vind denk ik niemand echt leuk ;). Misschien val ik in herhaling, maar mijn huidige workflow geeft me dus grip op veranderingen. Ik heb momenteel automerge aanstaan voor patches en minors, behalve bij packages die CalVer gebruiken. Maar dat hoeft natuurlijk niet, dan krijg je van Renovate namelijk alleen een PR die je handmatig kunt mergen. Renovate werkt deze tevens bij bij updates. Je kunt tevens configureren dat Renovate automatisch de changelog in het PR toevoegt:

Afbeeldingslocatie: https://tweakers.net/i/fPLwQjm08i00vWeFKazP9KiPxOQ=/800x/filters:strip_exif()/f/image/gXjpyIwDdcx0dKOWhLXAibHy.png?f=fotoalbum_large

Wederom is dit relatief eenvoudig in te stellen. Ook kun je kiezen voor een minimumReleaseAge zodat je minder snel opgezadeld wordt met een verkeerde release.
Ik heb ook nog steeds één compose file. Soms handig, en soms niet. Ik zou dit wel in aparte stacks willen onderbrengen, maar er zijn dikke afhankelijkheden onderling.
Je kunt dit tegenwoordig ook opsplitsen met include(s). Misschien nog interessant voor jou?

Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Airw0lf Ansible en Ansible Tower zou je kunnen gebruiken, maar eerlijk gezegd vind ik dat nogal overkill en Ansible Tower is niet heel eenvoudig om op te zetten :|. Of te gebruiken :X.

Ik ben echt te spreken over mijn Forgejo en Forgejo Runner combinatie, dat heb volgens mij al duidelijk gemaakt :+. Hiervoor had ik Gitea en Gitea Runner en dat werkt niet zo goed. Ik ben met name overgestapt omdat ik wat meer ontwikkeling bij Forgejo zag. GitLab CI werkt ook prima, maar Gitlis wat resource intensief. TeamCity heb ik professioneel ervaring mee en is relatief eenvoudig in gebruik, maar ook een draak om mee te starten.

Het geeft me in ieder geval wel het deploy inzicht:
Afbeeldingslocatie: https://tweakers.net/i/sCblH8vgp69iiTZ_afOj9nyQfLw=/800x/filters:strip_exif()/f/image/bnt4loZH69xL6r5rUoWtBozV.png?f=fotoalbum_large

Alleen mis ik nog een overzicht van huidige versienummers. Daar heb ik al kort naar gekeken, maar was niet heel voor de hand liggend om op te zetten. Dat staat dus nog op de todo.

Verder vind ik mijn setup en repo layout enorm overzichtelijk, ik heb voor applicaties netjes een playbook, bijvoorbeeld van Home Assistant:

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
---
- name: Deploy Home Assistant
  hosts: docker

  roles:
    - role: mosquitto
      tags: [infra, mqtt]
      when: inventory_hostname == 'leetower'

    - role: esphome
      tags: [app, home_automation]
      when: inventory_hostname == 'leetower'

    - role: home_assistant
      tags: [app, home_automation, hub]
      when: inventory_hostname == 'leetower'

    - role: zigbee2mqtt
      tags: [app, home_automation, zigbee]
      when: inventory_hostname == 'brickhouse'

    - role: zwavejs
      tags: [app, home_automation, zwave]
      when: inventory_hostname == 'brickhouse'


Per playbook heb ik dan tevens een vars bestand met daarin de relevante variabelen. Bijvoorbeeld:
YAML:
1
2
3
home_assistant_database_name: homeassistant
home_assistant_database_username: homeassistant
home_assistant_database_password: "{{ vault_home_assistant_database_username }}"


En dan uiteraard een Ansible vault bestand met daarin de secrets. Het wachtwoord daarvan staat tevens in Forgejo als secret, waardoor ik

Voor iets kant-en-klaar en een echt dashboard hiervoor zou je eventueel nog kunnen kijken naar Whats Up Docker. Maar zelf vond ik dat niet prettig werken toen ik dat een hele tijd geleden uitprobeerde.

Acties:
  • 0 Henk 'm!

  • Yarisken
  • Registratie: Augustus 2010
  • Laatst online: 21:41
Boys, ik draai een stuk of 30 docker containers met gewoon standaard netwerk dus gebruik makend van het ip van de server.
Ik loop soms tegen zaken aan dat bepaalde poorten hard coded in een docker container zitten zoals bv poort 8080.en deze poort is al in gebruik door een andere docker container.
Om dit te vermijden was ik aan het denken om docker macvlan te gaan gebruiken zodat elke docker container zijn eigen ip gaat hebben . Ik heb nog genoeg interne ip adressen over.

Ik heb er zelf geen ervaring mee dus mijn vraag is of docker macvlan ook nadelen heeft ?

Acties:
  • +1 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Yarisken schreef op woensdag 2 april 2025 @ 17:23:
Boys, ik draai een stuk of 30 docker containers met gewoon standaard netwerk dus gebruik makend van het ip van de server.
Ik loop soms tegen zaken aan dat bepaalde poorten hard coded in een docker container zitten zoals bv poort 8080.en deze poort is al in gebruik door een andere docker container.
Om dit te vermijden was ik aan het denken om docker macvlan te gaan gebruiken zodat elke docker container zijn eigen ip gaat hebben . Ik heb nog genoeg interne ip adressen over.

Ik heb er zelf geen ervaring mee dus mijn vraag is of docker macvlan ook nadelen heeft ?
Macvlan kan, heeft elke container zijn eigen adres.

Ik heb alles achter Caddy zitten, dan maakt het niet uit als tig containers op dezelfde poort zitten.

Verder kun je toch altijd een poort mappen, dus dit probleem bestaat toch niet?

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • Yarisken
  • Registratie: Augustus 2010
  • Laatst online: 21:41
Mars Warrior schreef op woensdag 2 april 2025 @ 17:26:
[...]

Macvlan kan, heeft elke container zijn eigen adres.

Ik heb alles achter Caddy zitten, dan maakt het niet uit als tig containers op dezelfde poort zitten.

Verder kun je toch altijd een poort mappen, dus dit probleem bestaat toch niet?
Wat bedoel je met poort mappen ? In de docker-compose kan ik de poorten aanpassen maar dit lukt niet voor alle docker-containers.
Dus stel dat er in de compose file 8080 staat verander ik dit in 8081 maar als ik dan de container start via docker-compose -d zodat ik output zie dan start de container met poort 8080 ipv 8081.

Acties:
  • +4 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Yarisken schreef op woensdag 2 april 2025 @ 17:36:
[...]


Wat bedoel je met poort mappen ? In de docker-compose kan ik de poorten aanpassen maar dit lukt niet voor alle docker-containers.
Dus stel dat er in de compose file 8080 staat verander ik dit in 8081 maar als ik dan de container start via docker-compose -d zodat ik output zie dan start de container met poort 8080 ipv 8081.
Het mappen van een interne naar een port op de host.

Zie: https://docs.docker.com/g...ports/#use-docker-compose

Dus in docker compose staat dan iets van het volgende om de docker poort 8080 te mappen naar 8081 op de host.
YAML:
1
2
ports:
  - 8081:8080

[ Voor 4% gewijzigd door Mars Warrior op 02-04-2025 17:41 ]

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • Yarisken
  • Registratie: Augustus 2010
  • Laatst online: 21:41
Mars Warrior schreef op woensdag 2 april 2025 @ 17:40:
[...]

Het mappen van een interne naar een port op de host.

Zie: https://docs.docker.com/g...ports/#use-docker-compose

Dus in docker compose staat dan iets van het volgende om de docker poort 8080 te mappen naar 8081 op de host.
YAML:
1
2
ports:
  - 8081:8080
Ja dat werkt ! Hartelijk bedankt, ik kan weer verder zonder alles te herconfigureren in macvlan _/-\o_ _/-\o_ _/-\o_

Acties:
  • 0 Henk 'm!

  • Mars Warrior
  • Registratie: Oktober 2003
  • Laatst online: 21:20

Mars Warrior

Earth, the final frontier

Yarisken schreef op woensdag 2 april 2025 @ 17:46:
[...]
Ja dat werkt ! Hartelijk bedankt, ik kan weer verder zonder alles te herconfigureren in macvlan _/-\o_ _/-\o_ _/-\o_
Mooi. Heb je weer wat geleerd wat je een hoop werk scheelt 8)

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • +1 Henk 'm!

  • RobertMe
  • Registratie: Maart 2009
  • Laatst online: 21:38
Yarisken schreef op woensdag 2 april 2025 @ 17:23:
Boys, ik draai een stuk of 30 docker containers met gewoon standaard netwerk dus gebruik makend van het ip van de server.
Ik loop soms tegen zaken aan dat bepaalde poorten hard coded in een docker container zitten zoals bv poort 8080.en deze poort is al in gebruik door een andere docker container.
Om dit te vermijden was ik aan het denken om docker macvlan te gaan gebruiken zodat elke docker container zijn eigen ip gaat hebben . Ik heb nog genoeg interne ip adressen over.

Ik heb er zelf geen ervaring mee dus mijn vraag is of docker macvlan ook nadelen heeft ?
Je informatie is nogal karig. Standaard zou dan een bridge netwerk gebruikt worden, en dan kun je een port mapping gebruiken zoals @Mars Warrior aangeeft. Maar ik associeer je probleem met dat je wellicht overal network mode host gebruikt, en uberhaupt geen "isolatie" toepast? En dan is er niet direct een oplossing buiten iets anders gebruiken v.w.b. "netwerk".

En laatste optie is dan zoals @Mars Warrior aangeeft in ieder geval alle applicaties met een webserver (/die je via een brower benaderd) achter een reverse proxy te zetten en uberhaupt niet de poort open te zetten. Enqua reverse proxy is er keuze genoeg. Traefik, Caddy, Nginx proxy manager (NPM), ....

Acties:
  • +1 Henk 'm!

  • alex3305
  • Registratie: Januari 2004
  • Laatst online: 20:55
@Yarisken Ik kan je wel aanraden om ipvlan te gebruiken ipv macvlan. De verschillen zijn subtiel, maar het is wat makkelijker te configureren en te beheren.

Alles omgooien valt, gelukkig, ook wel weer mee. In mijn standaard netwerkconfiguratie zonder VLAN's was het aanmaken redelijk triviaal:

docker network create -d ipvlan \
    --subnet=192.168.1.0/24 \
    --gateway=192.168.1.1 \
	-o parent=enp3s0 br0

Waarbij enp3s0 mijn primaire netwerkinterface is. Deze kun je eventueel vinden met ip link show. Waarna ik het kan gebruiken vanuit Compose met:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
services:
  home-assistant:
    image: ghcr.io/home-assistant/home-assistant:2025.3.4
    networks:
      ipvlan:
        ipv4_address: 192.168.1.3
    volumes:
      - /opt/homeassistant/config:/config
      - /etc/localtime:/etc/localtime:ro

networks:
  ipvlan:
    name: br0
    external: true

Let wel op dat hiermee de ipvlan configuratie in dezelfde range zit als de DHCP en theoretisch dus ip conflicten kan veroorzaken. In mijn DHCP server heb ik daarom de range ingesteld vanaf .50 en wijs ik de IP adressen met de hand toe.

De oplossing die @Mars Warrior voordraagt is overigens wel vele malen beter. Immers heb je dan een single point of entry en geeft je dus veel meer controle.
Pagina: 1 ... 13 14 Laatste