[Docker] [alle OS] Het grote Docker ervaringen en tips topic

[Foxdelta-mods]

Le Enfant! schreef op zondag 13 februari 2022 @ 12:05:
[...]

Al de client_max_body size aangepast in de proxy conf?

In mijn swag container:
- nginx.conf client_max_body_size 0;
- default.cong client_max_body_size 0;
- nextcloud.subdomain.conf client_max_body_size 0;

hetzelfde geld voor mijn nextcloud container. Alle php.ini files staan op 16G en timeouts staan hoog ingesteld. Vanuit mijn client logs krijg in totaal geen data waar ik iets op kan zoeken en de enige foutmelding die ik krijg is:
"connection closed".

Mocht je nog meer ideeën hebben dan hoor ik het graag!

EDIT: Probleem blijkt te zitten in de laatste versie van de windows sync client. Deze heeft een probleem met "chunking" van de bestanden waardoor cloudflare de verbinding stopt als de upload groter wordt dan 100mb. Zie dit bugrapport die ik gisteren heb aangemaakt.

[Voor 36% gewijzigd door Foxdelta-mods op 14-02-2022 09:13]

[technorabilia]

@pven
Wat ik zo kan bedenken.

• De gebruiker is lid van de docker groep?
• De rechten op docker.sock staan goed?

[Foxdelta-mods]

D vd V schreef op zaterdag 12 februari 2022 @ 14:15:
[...]

Nginx Proxy Manager vond ik toch behoorlijk makkelijk op te zetten met mijn Docker containers. Ik zou SWAG hooguit willen proberen om te testen om dat wel goed klikt met Authelia. Op een later moment. Voor nu heb ik er ff genoeg van, haha.

Heb na twee dagen hobbiën Authelia aan de gang gekregen, om vervolgens tot de conclusie te komen dat ik geen enkele container naar buiten wil brengen. Dus authelia is er weer vanaf. VPN via wireguard is voldoende voor mij en mijn vriendin voorlopig. Kom toch langzaam op het punt dat ik geen flauw idee meer heb wat ik aan containers kan gebruiken/nodig heb.

EDIT:
op verzoek van Mars Warrior.
In mij geval was het een kwestie van een docker compose maken zoals hier staat beschreven. Zodra de container is gemaakt krijg je de ene na de andere error m.b.t je configuratie file wat niet is ingesteld. Ik heb uiteindelijk deze config gebruikt. Hier staan zaken ingesteld m.b.t welke DB je gebruikt/SMTP settings/ welke manier van 2FA etc. etc. Documentatie omtrent dit alles staat vrij goed beschreven op de site van Authelia. Een aantal zaken heb ik met enviroment variables via portainer meegegeven o.a. AUTHELIA_JWT_SECRET, AUTHELIA_STORAGE_MYSQL_PASSWORD en AUTHELIA_NOTIFIER_SMTP_PASSWORD.

Authelia heeft verschillende manier voor het opslaan van gebruikers. Voor je homelab is opslaan in een file de meest voor de handliggend tenzij je bijv al LDAP hebt draaien. In mij geval kwestie van een gebruiker aanmaken en wachtwoordt toevoegen (gehashed). Deze gebruiker worden dan opgeslagen in: /config/users_database.yml zoals ook in de config staat

Als je dat eenmaal draaiende hebt en authelia start op zonder errors moet je nog je SWAG container configureren. In de swag/config/nginx/site-conf/ de default aanpassen en de twee regels m.b.t. authelia uit commentaar halen. Vervolgens zorgen dat er op je DNS server een CNAME ingesteld staat naar je endpoint (bijv. sonarr of radarr etc. etc.) en tot slot in swag/config/nginx/proxy-confs de juiste .conf gebruiken. Hier staat allemaal samples voor zo'n beetje iedere endpoint die je maar kunt verzinnen. de .sample weghalen en de .conf openen. Controleer je poort en de authelia regels weer uit commentaar halen. SWAG opnieuw opstarten en dan moet je op de authelia pagina uitkomen als je naar je subdomein navigeert. Inloggen met je gebruiker/pass om vervolgens een 2FA code toe te voegen. Als alles goed gaat komt je uit op je ingestelde endpoint.

Beknopte samenvatting . Als er vragen zijn hoor ik het wel.

[Voor 58% gewijzigd door Foxdelta-mods op 05-03-2022 22:06]

[Mars Warrior]

Foxdelta-mods schreef op zaterdag 5 maart 2022 @ 21:42:
[...]
Heb na twee dagen hobbiën Authelia aan de gang gekregen, om vervolgens tot de conclusie te komen dat ik geen enkele container naar buiten wil brengen. Dus authelia is er weer vanaf. VPN via wireguard is voldoende voor mij en mijn vriendin voorloping. Kom toch langzaam op het punt dat ik geen flauw idee meer heb wat ik aan containers kan gebruiken/nodig heb.

Wil je nog aangeven hoe je Authelia aan de gang hebt gekregen qua configuratie?

Dan kan iedereen daar weer profijt van hebben!

[MDXTweaker]

Ik heb inmiddels ook al een aantal containers draaien op mijn Debian bakje (oa Portainer, watchtower, vaultwarden, adguard). Af en toe kom ik erachter dat vaultwarden niet meer actief is. Ik zou het handig vinden om daar op één of andere manier een notificatie van te ontvangen. Heel spannend hoeft dat niet te zijn, maar nu kom ik er vaak achter op het moment dat de container al een tijdje niet meer draait. Aangezien ik 'm ook voor andere mensen dan mezelf gebruik vind ik dat vervelend. Iemand een goede tip voor een eenvoudige monitoring tool voor zulk doel? Zit dat toevallig niet in Portainer?

[Yucko]

Volgens mij heb je binnen Portainer geen optie om een notificatie te sturen bij het stoppen van een container (draai zelf ook Debian icm Portainer, Watchtower en Vaultwaren en draait eigenlijk mega-stabiel).

Ik zou daarnaast toch gaan eens kijken in de logs waarom de container stopt. Restart-policy = never neem ik aan? Wellicht die ook even op "unless-stopped" te zetten.

[Voor 4% gewijzigd door Yucko op 04-04-2022 13:57]

[MDXTweaker]

@Yucko Restart stond inderdaad op "never" en nu aangepast naar "unless-stopped". Logs heb ik inderdaad niet in detail bekeken.... Dat zal ik volgende keer zeker doen!

Met dank aan de tip van @ThinkPad draai ik nu een smokeping container. Best grappig om te zien en heel eenvoudig in te stellen. Wat ik zou willen is iets vergelijkbaars (zo simpel is goed genoeg) maar dan met de mogelijkheid om een notificatie te versturen op het moment dat een endpoint niet bereikbaar is. Iemand een idee?

[Voor 53% gewijzigd door MDXTweaker op 04-04-2022 17:08. Reden: smokeping toegevoegd]

[ravedek]

MDXTweaker schreef op maandag 4 april 2022 @ 14:01:
@Yucko Restart stond inderdaad op "never" en nu aangepast naar "unless-stopped". Logs heb ik inderdaad niet in detail bekeken.... Dat zal ik volgende keer zeker doen!

Met dank aan de tip van @ThinkPad draai ik nu een smokeping container. Best grappig om te zien en heel eenvoudig in te stellen. Wat ik zou willen is iets vergelijkbaars (zo simpel is goed genoeg) maar dan met de mogelijkheid om een notificatie te versturen op het moment dat een endpoint niet bereikbaar is. Iemand een idee?

Voor monitoring van oa. Docker containers gebruik ik tegenwoordig Telegraf.
De metrics schrijft Telegraf weg naar een InfluxDB bucket (database). Vervolgens kan je binnen InfluxDB notifications en endpoints instellen. Ook is het eenvoudig om de historie te raadplegen en bijvoorbeeld voor een dashboard te gebruiken (leuk met Grafana ).

Misschien iets meer werk om op te zetten maar het bevalt erg goed. InfluxDB gebruikte ik al voor andere data dus de keuze was bij mij snel gemaakt.

En de linkjes naar Docker Hub voor de liefhebber :
Telegraf en InfluxDB

[Voor 3% gewijzigd door ravedek op 04-04-2022 19:22]

[DikkieDick]

ravedek schreef op maandag 4 april 2022 @ 19:19:
[...]


Voor monitoring van oa. Docker containers gebruik ik tegenwoordig Telegraf.
De metrics schrijft Telegraf weg naar een InfluxDB bucket (database). Vervolgens kan je binnen InfluxDB notifications en endpoints instellen. Ook is het eenvoudig om de historie te raadplegen en bijvoorbeeld voor een dashboard te gebruiken (leuk met Grafana ).

Misschien iets meer werk om op te zetten maar het bevalt erg goed. InfluxDB gebruikte ik al voor andere data dus de keuze was bij mij snel gemaakt.

En de linkjes naar Docker Hub voor de liefhebber :
Telegraf en InfluxDB

Heb je ook voorbeelden hoe je dit monitort? Ben wel beneuwd hoe je status van containers hierin krijgt.

Gebruik nu de combinatie wel voor wat data uit de HomeAssistant en Pihole.
Nog wel met Influxdb 1.x, want ik krijg het allemaal nog niet goed aan de praat met 2.x. Zal daar als ik meer tijd heb weer induiken.

Draai overigens Influxdb, Telegraf en Grafana in 1 container op de Raspberry Pi. Het image daarvoor was erg oud (uit 2018) en heb ik gefaseerd up-to-date gemaakt en werk ik ook weer bij indien nodig, en dat is toch regelmatig want Grafana kan er wat van qua releases. :-)

[ravedek]

@DikkieDick Binnen Telegraf heb je de Docker Input Plugin en de InfluxDB Output Plugin nodig. De configuration kan je trouwens laten genereren binnen de InfluxDB GUI, ook wel handig .
Het docker run script die ik gebruik (let op de --user parameter):

code:

docker run -d \
 --name=telegraf \
 --hostname=telegraf \
 --user telegraf:$(stat -c '%g' /var/run/docker.sock) \
 -p 8125:8125/udp \
 -p 8092:8092/udp \
 -p 8094:8094 \
 -v $PWD/config/telegraf.conf:/etc/telegraf/telegraf.conf:ro \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -e TZ=Europe/Amsterdam \
 --restart unless-stopped \
 telegraf

Zie eventueel ook mijn notitie.

Ik draai dit met InfluxDB 2.x. Home Assistant heb ik ook op 2.x draaien mocht je daar interesse in hebben (maar ik had geen historie in InfluxDB 1.x dus dan is het wat makkelijker...).

De status van de containers staat dan als volgt in InfluxDB:


En nog een lading andere metrics

[DikkieDick]

Aha, thanx @ravedek ik duik er later eens dieper in. Had het ook al wel geprobeerd met Mariadb maar mijn conversie van de SQLite-database naar MariaDb ging op zich goed, maar daarna raakte de data behoorlijk vernaggeld. Met name die van de P1-meter. Had al wel eens de upgrade van Influxdb 1.x naar 2.x gedaan (na eerst kopie te hebben gemaakt), maar dat kon ik niet goed aan de praat krijgen. Op zich werkt het nu ook nog goed, dus heb ik het even in de ijskast gezet.

[Jazco2nd]

Ik heb mijn homeserver opnieuw geinstalleerd (van Ubuntu naar Manjaro) en volg nu veel beter de officiele documentatie. Dit keer wil ik docker rootless installeren:
https://docs.docker.com/engine/security/rootless/
Dat is gelukt. Het werkt. Maar via mijn compose file moet ik ook een systeemmap (/usr/share/fonts/) kunnen mounten. Dat gaat natuurlijk niet...

code:

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/home/asterix/.local/share/docker/volumes/6b317558e2e43b67a999890647c14fd389e75a774dd4cf0f51d969737548f6c1/_data" to rootfs at "/usr/share/fonts/truetype/custom": mkdir /home/asterix/.local/share/docker/btrfs/subvolumes/4eda4a9d259568ac7dc3b23c6761346f0ee53515b00a89c1dab00268a69ea535/usr/share/fonts/truetype: permission denied: unknown

Bestaat er een manier om dit toch te kunnen doen, net zoals je bijvoorbeeld privileged ports toch kan mappen?

edit: los hiervan, compose up -d werkt prima, maar ik kan geen enkele container bereiken. Ook Portainer niet. Terwijl als ik Portainer simpelweg via:

code:

docker run -d -p 9000:9000 --name=portainer --restart=always -v /$XDG_RUNTIME_DIR/docker.sock:/var/run/docker.sock -v ~/.local/share/docker/volumes:/var/lib/docker/volumes portainer/portainer-ce

maak en start, kan ik deze prima bereiken.. via Compose niet

edit2: aha, het verschil is dat ik in mijn compose file netjes netwerken definieer. Als ik dat in mijn compose file uitcomment zoals hieronder, werkt Portainer ook via Compose.

code:

##____________________ Portainer [Management/Docker]
  portainer:
    container_name: portainer
    image: portainer/portainer-ce
    restart: always
    #networks: 
     # - management
    volumes:
      - /$XDG_RUNTIME_DIR/docker.sock:/var/run/docker.sock
      - ~/.local/share/docker/volumes:/var/lib/docker/volumes 
      - $DOCKERDIR/portainer/data:/data
    ports:
      - 9000:9000

Ik mis dus iets.. in rootless mode kan je blijkbaar niet (zomaar) docker networks aanmaken..

edit3: AHA, rootless mode ondersteund geen overlay networks. Dus ik moet kiezen: of overlay networks gebruiken waarbij docker containers root access hebben, of geen overlay networks gebruiken met rootless mode..

Hoe weet je nu wat het beste/veiligste is voor een homeserver?

[Voor 96% gewijzigd door Jazco2nd op 08-04-2022 15:13]

[Ben.Hahlen]

Ik zit met een probleem waar ik niet uit kom en heb ondertussen zo'n beetje alles afgestruind wat ik kon vinden, maar nog steeds geen oplossing...
Dus ik hoop dat jullie mij kunnen helpen! (Geen druk verder ).

Situtatieschets:
Op mijn server draai ik Docker met een MACVLan netwerk. Dit heb ik destijds gedaan om er mee te leren omgaan én omdat ik dan IP's had voor de verschillende services, zodat ik ook HomeAssistant (o.a.) makkelijk kon draaien

Dit heeft tijden lang goed gedraaid, tot ik mijn switch heb vervangen van een Zyxel naar een Ubiquiti, omdat ik ook al een USG had en de AP's.
Nu weet ik niet of dat een causaal verband is, maar het is wel belangrijk om te melden.

Sindsdien krijg ik van watchtower de volgende meldingen tijdens runs:

code:

$ docker run --rm --network=lan_net -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --run-once
time="2022-08-18T10:34:06Z" level=info msg="Watchtower 1.4.0"
time="2022-08-18T10:34:06Z" level=info msg="Using no notifications"
time="2022-08-18T10:34:06Z" level=info msg="Checking all containers (except explicitly disabled with label)"
time="2022-08-18T10:34:06Z" level=info msg="Running a one time update."
time="2022-08-18T10:34:41Z" level=warning msg="Could not do a head request for \"linuxserver/transmission:latest\", falling back to regular pull." container=/transmission image="linuxserver/transmission:latest"
time="2022-08-18T10:34:41Z" level=warning msg="Reason: Head \"https://index.docker.io/v2/linuxserver/transmission/manifests/latest\": dial tcp 44.205.66.155:443: i/o timeout" container=/transmission image="linuxserver/transmission:latest"
time="2022-08-18T10:35:41Z" level=warning msg="Could not do a head request for \"linuxserver/nginx:latest\", falling back to regular pull." container=/eefsoriginals image="linuxserver/nginx:latest"
time="2022-08-18T10:35:41Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.205.66.155:443: i/o timeout" container=/eefsoriginals image="linuxserver/nginx:latest"
time="2022-08-18T10:36:41Z" level=warning msg="Could not do a head request for \"linuxserver/nginx:latest\", falling back to regular pull." container=/wowmirrors image="linuxserver/nginx:latest"
time="2022-08-18T10:36:41Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.205.66.155:443: i/o timeout" container=/wowmirrors image="linuxserver/nginx:latest"
time="2022-08-18T10:37:42Z" level=warning msg="Could not do a head request for \"homeassistant/home-assistant:latest\", falling back to regular pull." container=/homeassistant image="homeassistant/home-assistant:latest"
time="2022-08-18T10:37:42Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.206.182.67:443: i/o timeout" container=/homeassistant image="homeassistant/home-assistant:latest"
time="2022-08-18T10:38:42Z" level=warning msg="Could not do a head request for \"eclipse-mosquitto:latest\", falling back to regular pull." container=/mosquitto image="eclipse-mosquitto:latest"
time="2022-08-18T10:38:42Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.206.182.67:443: i/o timeout" container=/mosquitto image="eclipse-mosquitto:latest"
time="2022-08-18T10:39:23Z" level=warning msg="Could not do a head request for \"linuxserver/unifi-controller:latest\", falling back to regular pull." container=/unifi image="linuxserver/unifi-controller:latest"
time="2022-08-18T10:39:23Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": net/http: TLS handshake timeout" container=/unifi image="linuxserver/unifi-controller:latest"
time="2022-08-18T10:40:13Z" level=warning msg="Could not do a head request for \"portainer/portainer-ce:latest\", falling back to regular pull." container=/portainer image="portainer/portainer-ce:latest"
time="2022-08-18T10:40:13Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.206.182.67:443: i/o timeout" container=/portainer image="portainer/portainer-ce:latest"
time="2022-08-18T10:41:14Z" level=warning msg="Could not do a head request for \"linuxserver/wireguard:latest\", falling back to regular pull." container=/wireguard image="linuxserver/wireguard:latest"
time="2022-08-18T10:41:14Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.205.66.155:443: i/o timeout" container=/wireguard image="linuxserver/wireguard:latest"
time="2022-08-18T10:43:13Z" level=info msg="Session done" Failed=0 Scanned=35 Updated=0 notify=no
time="2022-08-18T10:43:13Z" level=info msg="Waiting for the notification goroutine to finish" notify=no

Als ik watchtower in een run-once draai, zonder gebruik te maken van het MACVLan netwerk, dan werkt dit zonder problemen (let ook op dat de macvlan variant eerder is gestart, maar langer heeft geduurd):

code:

$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --run-once
time="2022-08-18T10:34:29Z" level=info msg="Watchtower 1.4.0"
time="2022-08-18T10:34:29Z" level=info msg="Using no notifications"
time="2022-08-18T10:34:29Z" level=info msg="Checking all containers (except explicitly disabled with label)"
time="2022-08-18T10:34:29Z" level=info msg="Running a one time update."
time="2022-08-18T10:35:02Z" level=info msg="Session done" Failed=0 Scanned=36 Updated=0 notify=no
time="2022-08-18T10:35:02Z" level=info msg="Waiting for the notification goroutine to finish" notify=no

Verder relevante info:

code:

$ docker network inspect lan_net
[
    {
        "Name": "lan_net",
        "Id": "148a4c4c72d13f2e816fd932e4c874d3421b52c3f1488b4b817c16539c185d7f",
        "Created": "2022-08-18T10:47:49.404058043+02:00",
        "Scope": "local",
        "Driver": "macvlan",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "192.168.2.0/24",
                    "IPRange": "192.168.2.0/24",
                    "Gateway": "192.168.2.1",
                    "AuxiliaryAddresses": {
                        "host": "192.168.2.251"
                    }
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            ... (Verwijderd)
        },
        "Options": {
            "parent": "enp0s31f6"
        },
        "Labels": {}
    }
]

Commands voor creëren netwerk:

code:

docker network create -d macvlan \
  -o parent=enp0s31f6 \
  --subnet=192.168.2.0/24 \
  --gateway=192.168.2.1 \
  --ip-range=192.168.2.0/24 \
  --aux-address 'host=192.168.2.251' \
  lan_net

MACVLan Shim voor communicatie:

code:

ip link add lan_net_shim link enp0s31f6 type macvlan mode bridge
ip addr add 192.168.2.251/32 dev lan_net_shim
ip link set lan_net_shim up
ip route add 192.168.2.0/24 dev lan_net_shim

Zoals ik dus zei: ik ben redelijk lost waar ik het moet zoeken, dus als iemand de gouden tip heeft

[Freee!!]

Ben.Hahlen schreef op donderdag 18 augustus 2022 @ 12:43:
Ik zit met een probleem waar ik niet uit kom en heb ondertussen zo'n beetje alles afgestruind wat ik kon vinden, maar nog steeds geen oplossing...
Dus ik hoop dat jullie mij kunnen helpen! (Geen druk verder ).

Situtatieschets:
Op mijn server draai ik Docker met een MACVLan netwerk. Dit heb ik destijds gedaan om er mee te leren omgaan én omdat ik dan IP's had voor de verschillende services, zodat ik ook HomeAssistant (o.a.) makkelijk kon draaien

Dit heeft tijden lang goed gedraaid, tot ik mijn switch heb vervangen van een Zyxel naar een Ubiquiti, omdat ik ook al een USG had en de AP's.
Nu weet ik niet of dat een causaal verband is, maar het is wel belangrijk om te melden.

Sindsdien krijg ik van watchtower de volgende meldingen tijdens runs:

code:

$ docker run --rm --network=lan_net -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --run-once
time="2022-08-18T10:34:06Z" level=info msg="Watchtower 1.4.0"
time="2022-08-18T10:34:06Z" level=info msg="Using no notifications"
time="2022-08-18T10:34:06Z" level=info msg="Checking all containers (except explicitly disabled with label)"
time="2022-08-18T10:34:06Z" level=info msg="Running a one time update."
time="2022-08-18T10:34:41Z" level=warning msg="Could not do a head request for \"linuxserver/transmission:latest\", falling back to regular pull." container=/transmission image="linuxserver/transmission:latest"
time="2022-08-18T10:34:41Z" level=warning msg="Reason: Head \"https://index.docker.io/v2/linuxserver/transmission/manifests/latest\": dial tcp 44.205.66.155:443: i/o timeout" container=/transmission image="linuxserver/transmission:latest"
time="2022-08-18T10:35:41Z" level=warning msg="Could not do a head request for \"linuxserver/nginx:latest\", falling back to regular pull." container=/eefsoriginals image="linuxserver/nginx:latest"
time="2022-08-18T10:35:41Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.205.66.155:443: i/o timeout" container=/eefsoriginals image="linuxserver/nginx:latest"
time="2022-08-18T10:36:41Z" level=warning msg="Could not do a head request for \"linuxserver/nginx:latest\", falling back to regular pull." container=/wowmirrors image="linuxserver/nginx:latest"
time="2022-08-18T10:36:41Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.205.66.155:443: i/o timeout" container=/wowmirrors image="linuxserver/nginx:latest"
time="2022-08-18T10:37:42Z" level=warning msg="Could not do a head request for \"homeassistant/home-assistant:latest\", falling back to regular pull." container=/homeassistant image="homeassistant/home-assistant:latest"
time="2022-08-18T10:37:42Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.206.182.67:443: i/o timeout" container=/homeassistant image="homeassistant/home-assistant:latest"
time="2022-08-18T10:38:42Z" level=warning msg="Could not do a head request for \"eclipse-mosquitto:latest\", falling back to regular pull." container=/mosquitto image="eclipse-mosquitto:latest"
time="2022-08-18T10:38:42Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.206.182.67:443: i/o timeout" container=/mosquitto image="eclipse-mosquitto:latest"
time="2022-08-18T10:39:23Z" level=warning msg="Could not do a head request for \"linuxserver/unifi-controller:latest\", falling back to regular pull." container=/unifi image="linuxserver/unifi-controller:latest"
time="2022-08-18T10:39:23Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": net/http: TLS handshake timeout" container=/unifi image="linuxserver/unifi-controller:latest"
time="2022-08-18T10:40:13Z" level=warning msg="Could not do a head request for \"portainer/portainer-ce:latest\", falling back to regular pull." container=/portainer image="portainer/portainer-ce:latest"
time="2022-08-18T10:40:13Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.206.182.67:443: i/o timeout" container=/portainer image="portainer/portainer-ce:latest"
time="2022-08-18T10:41:14Z" level=warning msg="Could not do a head request for \"linuxserver/wireguard:latest\", falling back to regular pull." container=/wireguard image="linuxserver/wireguard:latest"
time="2022-08-18T10:41:14Z" level=warning msg="Reason: Get \"https://index.docker.io/v2/\": dial tcp 44.205.66.155:443: i/o timeout" container=/wireguard image="linuxserver/wireguard:latest"
time="2022-08-18T10:43:13Z" level=info msg="Session done" Failed=0 Scanned=35 Updated=0 notify=no
time="2022-08-18T10:43:13Z" level=info msg="Waiting for the notification goroutine to finish" notify=no

Als ik watchtower in een run-once draai, zonder gebruik te maken van het MACVLan netwerk, dan werkt dit zonder problemen (let ook op dat de macvlan variant eerder is gestart, maar langer heeft geduurd):

code:

$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --run-once
time="2022-08-18T10:34:29Z" level=info msg="Watchtower 1.4.0"
time="2022-08-18T10:34:29Z" level=info msg="Using no notifications"
time="2022-08-18T10:34:29Z" level=info msg="Checking all containers (except explicitly disabled with label)"
time="2022-08-18T10:34:29Z" level=info msg="Running a one time update."
time="2022-08-18T10:35:02Z" level=info msg="Session done" Failed=0 Scanned=36 Updated=0 notify=no
time="2022-08-18T10:35:02Z" level=info msg="Waiting for the notification goroutine to finish" notify=no

Verder relevante info:

code:

$ docker network inspect lan_net
[
    {
        "Name": "lan_net",
        "Id": "148a4c4c72d13f2e816fd932e4c874d3421b52c3f1488b4b817c16539c185d7f",
        "Created": "2022-08-18T10:47:49.404058043+02:00",
        "Scope": "local",
        "Driver": "macvlan",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "192.168.2.0/24",
                    "IPRange": "192.168.2.0/24",
                    "Gateway": "192.168.2.1",
                    "AuxiliaryAddresses": {
                        "host": "192.168.2.251"
                    }
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            ... (Verwijderd)
        },
        "Options": {
            "parent": "enp0s31f6"
        },
        "Labels": {}
    }
]

Commands voor creëren netwerk:

code:

docker network create -d macvlan \
  -o parent=enp0s31f6 \
  --subnet=192.168.2.0/24 \
  --gateway=192.168.2.1 \
  --ip-range=192.168.2.0/24 \
  --aux-address 'host=192.168.2.251' \
  lan_net

MACVLan Shim voor communicatie:

code:

ip link add lan_net_shim link enp0s31f6 type macvlan mode bridge
ip addr add 192.168.2.251/32 dev lan_net_shim
ip link set lan_net_shim up
ip route add 192.168.2.0/24 dev lan_net_shim

Zoals ik dus zei: ik ben redelijk lost waar ik het moet zoeken, dus als iemand de gouden tip heeft

Waarschijnlijk checkt je Watchtower te vaak, er is al een tijdje een limiet aan het aantal opvragingen per tijdseenheid. Ik heb het interval nu op elke twee uur staan.

code:

-e WATCHTOWER_POLL_INTERVAL=7200 \

[Ben.Hahlen]

Freee!! schreef op donderdag 18 augustus 2022 @ 18:39:
[...]

Waarschijnlijk checkt je Watchtower te vaak, er is al een tijdje een limiet aan het aantal opvragingen per tijdseenheid. Ik heb het interval nu op elke twee uur staan.

code:

-e WATCHTOWER_POLL_INTERVAL=7200 \

Thanks, maar dat bleek het niet te zijn...

Wat wel?
Nou... Als je dus MACVlans doet, dan moet je wel adressen reserveren.
Watchtower pakte blijkbaar 192.168.2.2, waar mijn main switch ook op draait... En dat gaat dus niet.

De vraag is natuurlijk wel: waarom gebeurde dat eerst niet, maar nu ineens wel... Maar dat is voor later...

[Freee!!]

Ben.Hahlen schreef op vrijdag 19 augustus 2022 @ 09:31:
[...]
Thanks, maar dat bleek het niet te zijn...

Wat wel?
Nou... Als je dus MACVlans doet, dan moet je wel adressen reserveren.
Watchtower pakte blijkbaar 192.168.2.2, waar mijn main switch ook op draait... En dat gaat dus niet.

De vraag is natuurlijk wel: waarom gebeurde dat eerst niet, maar nu ineens wel... Maar dat is voor later...

Daar had ik niet aan gedacht, ik hoef Watchtower niet te benaderen en andere services ook niet, dus dat draait bij mij niet in macvlan.

[Hathi]

Ik vraag me inderdaad af waarom je watchtower in een macvlan zou draaien. Voor homeassistant snap ik het, dan is die gewoon benaderbaar op een eigen IP, maar watchtower zou ik lekker in een bridge netwerk draaien.

[Ben.Hahlen]

Freee!! schreef op vrijdag 19 augustus 2022 @ 11:35:
[...]
Daar had ik niet aan gedacht, ik hoef Watchtower niet te benaderen en andere services ook niet, dus dat draait bij mij niet in macvlan.

Hathi schreef op vrijdag 19 augustus 2022 @ 12:37:
Ik vraag me inderdaad af waarom je watchtower in een macvlan zou draaien. Voor homeassistant snap ik het, dan is die gewoon benaderbaar op een eigen IP, maar watchtower zou ik lekker in een bridge netwerk draaien.

Dat is ook niet bewust zo, moet ik eerlijk zeggen...
Ik dacht altijd dat watchtower in de bridge draaide...

...maar toen kwam ik dit stukje in mijn compose.yaml tegen:

YAML:

networks:
  lan_net:
    external: true
  default:
    external: true
    name: lan_net

Ooit zo opgezet (lang, lang geleden) en nooit meer naar gekeken, want: "het werkte"

Nu ben ik toch bezig om e.e.a. te bekijken en te herconfigureren, dus er zullen vast meer wijzigingen gaan plaatsvinden

[Piet400]

Heeft iemand een goede suggestie voor een (docker) app waarmee je backups maakt van iOS en Android devices kan maken?

[HenkEisjedies]

Ik heb een docker image (https://www.freqtrade.io/en/stable/docker_quickstart/) die ik draaiend wil hebben en houden in Azure. Lokaal lukt het me prima om de image te starten. Ik doorloop gewoon de stappen uit de handleiding en klaar.

code:

mkdir ft_userdata
cd ft_userdata/
# Download the docker-compose file from the repository
curl https://raw.githubusercontent.com/freqtrade/freqtrade/stable/docker-compose.yml -o docker-compose.yml

# Pull the freqtrade image
docker-compose pull

# Create user directory structure
docker-compose run --rm freqtrade create-userdir --userdir user_data

# Create configuration - Requires answering interactive questions
docker-compose run --rm freqtrade new-config --config user_data/config.json

Zoals je ziet, redelijk simpel. Ik download de docker-compose file die freqtrade meelevert, pull de freqtrade image en maak een nieuwe config file aan.

Maar zodra ik ditzelfde wil doen op Azure gaat het mis. Je kunt bij Azure bij het aanmaken van een nieuwe container een aantal commando's meegeven die als eerste worden uitgevoerd. Dus ik zet bovenstaande commando's neer, maar de container killt zichzelf vrijwel direct. Nu heb ik geleerd dat dit opzich normaal docker gedrag is als een container niets meer te doen heeft en er geen actieve processen draaien. Ik denk dat het komt omdat het laatste commando een interactieve questionaire is en er dus eigenlijk nooit een valide config.json bestand wordt aangemaakt. Zou ik de antwoorden op deze questionairre ook kunnen meegeven in Azure?

Daarnaast vraag ik me af hoe het gaat in Azure met lokale bestanden. Ik heb nu de bestanden lokaal staan, maar deze moeten uiteindelijk ook in Azure terecht komen. Alleen als ik bovenstaande riedeltje uitvoer dan staan die bestanden in de container en als ik docker goed begrijp bestaan deze bestanden alleen zolang de container bestaat. Hoe vertel ik Azure dat hij het config.json bestand in Azure aanmaakt op een niet vluchtige manier?

Tot slot heb ik nog een vraag over de SQL database in de container. Deze moet ook persistant worden, maar first things first eerst maar eens dat config bestand persistant maken.

Of gebruik ik docker verkeerd en kan ik beter een virtuele ubuntu omgeving in Azure maken en daar python en freqtrade op installeren? Dan heb ik alles netjes in één pakketje, maar dan moet ik ook gaan nadenken over updaten en beveiligen van linux (waar ik niet goed in ben). Mijn ultieme doel is dat ik vrij makkelijk ook voor wat vrienden freqtrade draaiend kan krijgen, dus het is niet alleen voor mijzelf.

[Jaguar645]

Met Azure maak je gebruik van Container Instance neem ik aan?

Volgens mij wordt alleen Azure files als persistent storage ondersteund om je config/logging dan in op te slaan zoals bv:

code:

az container create -g MyResourceGroup --name myapp --image myimage:latest --command-line "cat /mnt/azfile/myfile" --azure-file-volume-share-name myshare --azure-file-volume-account-name mystorageaccount --azure-file-volume-account-key mystoragekey --azure-file-volume-mount-path /mnt/azfile

komt uit de az cli docs: https://docs.microsoft.co...atest#az-container-create

voor persistent sql/dabase kun je dan het beste Azure SQL inzetten natuurlijk helemaal als je beide vnet integrate gaat er niets het internet over

ik heb nog geen commands gerund tegen een container instance aan maar volgens mij gaat dat volgens de docs op de volgende manier:

code:

az container create -g MyResourceGroup --name myapp --image myimage:latest --command-line "/bin/sh -c '/path to/myscript.sh'"

maar dan uiteraard customized naar wat jij nodig hebt

[HenkEisjedies]

Thanks man, ik ga vanavond even kijken of het me lukt met Azure Files. Ik gebruik inderdaad een Azure Container Instance.

Verder werkt Freqtrade met sqllite en dat zit dus ook allemaal in die Docker Image neem ik aan, ik moet even checken waar die dbms zijn storage/files doet. Ik weet niet zeker wat het slimste is om te doen: die dbms zijn bestanden in Azure Files hosten of een Azure database gebruiken. Die eerste lijkt me het makkelijkst omdat ik dan alleen bestandslocaties hoef aan te passen.

[Jaguar645]

Denk dat je een SQLite DB prima in files kunt hosten die is in principe snel genoeg... mocht je toch tegen zaken aanlopen kun je altijd nog naar een serverless azure sql migreren

[Jaguar645]

Heb even nog gezocht en vond een oude pipeline waar ooit een syslog-ng instance als ACI deployed was geweest heb het even proberen te vertalen naar de globale stappen zoals uitgevoerd:

1. Deploy storage account (Standard_LRS in ons geval)
2. Enable privatelink en configure dns (mits van toepassing, je kunt uiteraard ook over service endpoint connecten)
3. Create file shares:

code:

$resourceGroupName = ""
$filesharename = ""
$storageaccountname = ""
$storagekey=$(az storage account keys list --resource-group $resourceGroupName --account-name $storageaccountname --query "[0].value" --output tsv)
az storage share create --name $filesharename --account-name $storageaccountname --account-key $storagekey

4. Create container:

code:

$resourceGroupName = ""
az container create --resource-group $resourceGroupName --file .\deploytemplate.yml

template.yml:

code:

apiVersion: '2021-07-01'
location: westeurope
name: ##containername##
properties:
  containers:
  - name: ##containername##
    properties:
      environmentVariables: []
      image: lscr.io/linuxserver/syslog-ng
      ports:
      - protocol: tcp
        port: 6514
      resources:
        requests:
          cpu: 2.0
          memoryInGB: 3.5
      volumeMounts:
      - mountPath: /config
        name: ##mountname##
      - mountPath: /var/log
        name: ##mountname##
  osType: Linux
  restartPolicy: Always
  ipAddress:
    type: Private
    ports:
      - protocol: tcp
        port: 6514
  volumes:
  - name: ##name##
    azureFile:
      sharename: ##sharename##
      storageAccountName: ##storageAccountName##
      storageAccountKey: ##storageAccountKey##
  subnetIds:
    - id: /subscriptions/$subscription/resourceGroups/$rg/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/$sub
      name: ##subnetname##
tags: {}
type: Microsoft.ContainerInstance/containerGroups

ipv cli voor de container zelf dus yaml gebruikt omdat ik dat iets makkelijker/begrijpelijker vond dan de cli maar choice of preference

uiteraard aanpassen waar nodig naar je eigen config

[HenkEisjedies]

Cool thanks wederom. Dit is echt precies wat ik straks nodig ga hebben om het deployen helemaal te automatiseren denk ik.

Ik heb inmiddels storage (volgens mij ook standard_LRS), de juiste resource group heeft dr toegang tot en dr zitten files in. Dan is het nu volgens mij alleen nog een kwestie van docker runnen met een verwijzing naar die files. 🙃 Nice!

Dit weekend ga ik kijken of ik hem dan ook daadwerkelijk kan runnen.

[HenkEisjedies]

Grappig dat je zei dat je het via een YML file gedaan hebt omdat de CLI wat weinig overzichtelijk is. Ik denk dat ik hier tegen dezelfde complexiteit aan loop.

Volgens mij moet ik docker-compose run freqtrade trade --config /user_data/config.json --strategy SampleStrategy meegeven bij het opstarten. Dit werkt in elk geval op Docker Desktop zo.

Ik probeer daarom nu een container aan te maken als volgt:
az container create --command-line "`"docker-compose run freqtrade trade --config /user_data/config.json --strategy SampleStrategy`""


Alleen als ik dan ga kijken bij de aangemaakte Container Instances dan zie ik dit:

Maar dit zijn geen losse commando's. Naja, morgen weer verder.

[Webgnome]

Hi,

een docker noob hier. Ik ben in mijn vrije tijd een beetje aan het klooien met Docker om wat services op mijn pi te draaien. En de basis dat lukt mij altijd wel echter loop ik op dit moment tegen een bepaald probleempje aan wat ik niet helemaal begrijp.

Ik heb twee docker compose files.

domoticz.yml

code:

version: '3.3'

services:
  domoticz:
    image: domoticz/domoticz
    container_name: domoticz
    restart: unless-stopped
    # Pass devices to container
    devices:
      - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB6648AH-if00-port0:/dev/ttyUSB0"
    ports:
      - "8080:8080"
    volumes:
      - /mnt/ssd/docker/data/domoticz/:/opt/domoticz/userdata
      - /mnt/ssd/logs/domoticz:/opt/domoticz/userdata/logs
    environment:
      - TZ=Europe/Amsterdam
      - LOG_PATH=/opt/domoticz/userdata/logs/logsdomoticz.log
    networks:
      - domoticz

networks:
  domoticz:
    name: domoticz

wordpress.yml

code:

services:
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    command: '--default-authentication-plugin=mysql_native_password'
    volumes:
      -  /mnt/ssd/docker/data/blog/mysql:/var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
  wordpress:
    image: wordpress:latest
    ports:
      - 8081:80
    restart: always
    depends_on:
      - db
    volumes:
      -  /mnt/ssd/docker/data/blog/www:/var/www/html
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress

Nu starte ik zojuist de wordpress op en krijg ik in de console de volgende melding
Found orphan containers ([config-web-1 domoticz]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.

Ik begrijp even niet waar dat docker deze melding vandaan tovert. Immers het zijn twee losstaande compose files. Is het nu zo dat docker deze twee compose files ziet als eenzelfde set containers of hoe moet ik dat zien? En belangrijker nog. Wat gebeurd er als ik een van de twee docker compose -f file.yml down breng?

[lolgast]

@Webgnome Staan beide compose files in dezelfde directory? Óf, heeft 1 van de compose files beide containers erin gehad en heb je ze later gesplit?

Het is in principe de bedoeling dat alle containers in dezelfde compose file staan, of je moet per container een eigen directory aanmaken en daarin een compose file met alleen die container/benodigdheden erin

[Webgnome]

Ik heb een directory /mnt/ssd/docker/config waar ik alle compose files heb staan aangezien ik de structuur aan houd:

/mnt/ssd/docker/config/ -> compose files
/mnt/ssd/docker/data/naamconfig/... -> container data voor compose file x

[lolgast]

Dan is de foutmelding logisch. Als je 1 dir wilt voor je compose.yaml, ‘moet’ je al je containers in die ene file zetten

[Webgnome]

En daar is geen andere oplossing voor? Wel jammer wel..

[technorabilia]

Webgnome schreef op zaterdag 27 augustus 2022 @ 19:00:
En daar is geen andere oplossing voor? Wel jammer wel..

Vanuit een unieke directory refereren naar de compose file in je verzamel directory met de -f optie misschien?

[MikeyMan]

Ben momenteel bezig om zoveel mogelijk spul dat op de Pi draait over te zetten op mijn DS1520+. Iets duurzamer oplossing.

Echter; daarmee word ik in veel gevallen geforceerd om Docker te gebruiken. Prima als het werkt. Maar als het dat niet doet, is de probleemanalyse er niet perse makkelijker op.

Waar ik nu tegenaan loop is een issue in NodeRed. Waarom dan in dit topic? Nou, dezelfde flow/call doet het op de Pi helemaal prima. Maar nu krijg ik een error:



De volledige request call is:
https://gateway-2017-8871...r-mobile-web/1/enduserAPI

Nu denk ik dat dit komt doordat dit een multicast call is. Iemand enig idee of dit op te lossen is binnen docker? Zie dat @ThinkPad al eerder iets vroeg over multicast. Nog aan de praat gekregen?

Ip Adressen kan ik gewoon pingen vanuit de container dus dat is het niet.

[Voor 8% gewijzigd door MikeyMan op 01-09-2022 09:19]

[ThinkPad]

Het multicast verhaal bij mij was dat het inkomend moest werken op de Docker container en dat bleek vrij lastig te zijn. Dat van jou lijkt uitgaand te zijn en zal dus meer kans van slagen hebben.

Misschien kun je toelichten wat je flow zou moeten doen?

[Voor 6% gewijzigd door ThinkPad op 01-09-2022 09:22]

[MikeyMan]

ThinkPad schreef op donderdag 1 september 2022 @ 09:21:
Het multicast verhaal bij mij was dat het inkomend moest werken op de Docker container en dat bleek vrij lastig te zijn. Dat van jou lijkt uitgaand te zijn en zal dus meer kans van slagen hebben.

Misschien kun je toelichten wat je flow zou moeten doen?

Ik heb nu de simpelste flow die je kunt bedenken, aangezien ik nog aan het pogen ben om de API's via NodeRed te ontsluiten.

In dit geval gaat het om een get version number.


Komt er van diezelfde call ook niet iets terug via multicast dan?

[ThinkPad]

Ik denk dat je beter een eigen topic kunt openen, het gaat hier offtopic denk ik

Naar mijn idee kan hij het adres gewoon niet vinden, maar ik vind het ook wel een bijzonder adres. Met multicast heeft het volgens mij niks te maken, het is gewoon een HTTP-request ?

Wat voor apparaat op je netwerk is dat precies? Kun je het vanaf je PC/laptop wel bereiken op dat adres?

[Voor 13% gewijzigd door ThinkPad op 01-09-2022 09:33]

[MikeyMan]

ThinkPad schreef op donderdag 1 september 2022 @ 09:33:
Ik denk dat je beter een eigen topic kunt openen, het gaat hier offtopic denk ik

Naar mijn idee kan hij het adres gewoon niet vinden, maar ik vind het ook wel een bijzonder adres. Met multicast heeft het volgens mij niks te maken, het is gewoon een HTTP-request ?

Wat voor apparaat op je netwerk is dat precies? Kun je het vanaf je PC/laptop wel bereiken op dat adres?

.local is volgens mij Multicast gerelateerd:



Het is een Somfy Tahoma Switch. En als je met 'bereiken' bedoelt dat de API call het daar wel doet; ja. Vanaf alle andere apparaten. Sterker nog het werkt vanaf de PI ook gewoon met een Curl get.
Eens even op de Nas proberen.

edit: Heb je me toch geholpen denk ik.
Op de NAS Krijg ik een "could not resolve host". Dus dat zal niet beperkt zijn tot Docker.
Mocht iemand hier nog tegenaan lopen op een of andere vreemde manier. mDNS (Multicast DNS) zou de oplossing moeten zijn hier.

[Voor 10% gewijzigd door MikeyMan op 01-09-2022 10:08]

[Jazco2nd]

Ik heb weer een mooie uitdaging.

ik draai FileRun (via Docker Compose) op mijn homeserver. Aanrader. Vind het stuk prettiger dan bijvoorbeeld NextCloud. En het ondersteund webDAV. Verschillende devices zoals laptop syncen (2-weg) persoonlijke data via webDAV met de server. Bij 1 laptop gaat het om al onze persoonlijke data (fotos van vakanties enzo), 600GB.
Het nadeel is dat webDAV denkt dat alles opnieuw gesynced moet worden wanneer ik mijn server reboot. Hierdoor gaat mijn laptop maandelijks 600GB opnieuw downloaden en naar de SSD schrijven... dat is natuurlijk vrij vervelend.. het duurt lang (via wifi), mijn laptop zet ik ondertussen allang weer uit (dus het rond de klus niet af) plus het is niet zo goed voor de levensduur van mijn SSD.

De oorzaak heb ik gevonden. De container heeft 2 volumes die worden gemount:

code:

    volumes:
      - $DOCKERDIR/filerun/html:/var/www/html
      - $DATAPOOL/users:/user-files

De oorzaak is dat het deviceID van volume "user-files" n de container na een reboot van de server is verandert. Waarschijnlijk logisch, docker wordt opgestart, de containers worden opgestart en blijkbaar worden de volumes dan opnieuw gemount.

Dit zie ik door het stat commando binnen de container uit te voeren voor en na reboot.
Voor een reboot:

code:

 root@d0ec110775a0:/# stat /user-files
  File: /user-files
  Size: 120             Blocks: 0          IO Block: 4096   directory
Device: 2ah/42d Inode: 256         Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ asterix)   Gid: ( 1000/ asterix)
Access: 2022-10-12 09:48:42.281721759 +0000
Modify: 2022-10-12 09:48:42.281721759 +0000
Change: 2022-10-12 09:48:42.281721759 +0000
 Birth: -

Na een reboot:

code:

root@d0ec110775a0:/# stat /user-files
  File: /user-files
  Size: 120             Blocks: 0          IO Block: 4096   directory
Device: 10002fh/1048623d        Inode: 256         Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ asterix)   Gid: ( 1000/ asterix)
Access: 2022-10-12 09:48:42.281721759 +0000
Modify: 2022-10-12 09:48:42.281721759 +0000
Change: 2022-10-12 09:48:42.281721759 +0000
 Birth: -

Zoals je ziet is "Device: ..." verschillend.

Ik zie hier dat je zelf een ID kan opgeven. Het voorbeeld dat ik vond:

code:

docker volume create --driver local \
    --opt type=tmpfs \
    --opt device=tmpfs \
    --opt o=size=100m,uid=1000 \
    --opt ID=2ah/42d \
    foo

het gaat mij dus alleen om "--opt ID=2ah/42d".
Maar ik kom geen syntax tegen hoe ik dit in mijn Compose kan doen. Heeft iemand enig idee?

[Mr.Viper]

Jazco2nd schreef op donderdag 13 oktober 2022 @ 11:15:
Ik heb weer een mooie uitdaging.

ik draai FileRun (via Docker Compose) op mijn homeserver. Aanrader. Vind het stuk prettiger dan bijvoorbeeld NextCloud. En het ondersteund webDAV. Verschillende devices zoals laptop syncen (2-weg) persoonlijke data via webDAV met de server. Bij 1 laptop gaat het om al onze persoonlijke data (fotos van vakanties enzo), 600GB.
Het nadeel is dat webDAV denkt dat alles opnieuw gesynced moet worden wanneer ik mijn server reboot. Hierdoor gaat mijn laptop maandelijks 600GB opnieuw downloaden en naar de SSD schrijven... dat is natuurlijk vrij vervelend.. het duurt lang (via wifi), mijn laptop zet ik ondertussen allang weer uit (dus het rond de klus niet af) plus het is niet zo goed voor de levensduur van mijn SSD.

De oorzaak heb ik gevonden. De container heeft 2 volumes die worden gemount:

code:

    volumes:
      - $DOCKERDIR/filerun/html:/var/www/html
      - $DATAPOOL/users:/user-files

De oorzaak is dat het deviceID van volume "user-files" n de container na een reboot van de server is verandert. Waarschijnlijk logisch, docker wordt opgestart, de containers worden opgestart en blijkbaar worden de volumes dan opnieuw gemount.

Dit zie ik door het stat commando binnen de container uit te voeren voor en na reboot.
Voor een reboot:

code:

 root@d0ec110775a0:/# stat /user-files
  File: /user-files
  Size: 120             Blocks: 0          IO Block: 4096   directory
Device: 2ah/42d Inode: 256         Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ asterix)   Gid: ( 1000/ asterix)
Access: 2022-10-12 09:48:42.281721759 +0000
Modify: 2022-10-12 09:48:42.281721759 +0000
Change: 2022-10-12 09:48:42.281721759 +0000
 Birth: -

Na een reboot:

code:

root@d0ec110775a0:/# stat /user-files
  File: /user-files
  Size: 120             Blocks: 0          IO Block: 4096   directory
Device: 10002fh/1048623d        Inode: 256         Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ asterix)   Gid: ( 1000/ asterix)
Access: 2022-10-12 09:48:42.281721759 +0000
Modify: 2022-10-12 09:48:42.281721759 +0000
Change: 2022-10-12 09:48:42.281721759 +0000
 Birth: -

Zoals je ziet is "Device: ..." verschillend.

Ik zie hier dat je zelf een ID kan opgeven. Het voorbeeld dat ik vond:

code:

docker volume create --driver local \
    --opt type=tmpfs \
    --opt device=tmpfs \
    --opt o=size=100m,uid=1000 \
    --opt ID=2ah/42d \
    foo

het gaat mij dus alleen om "--opt ID=2ah/42d".
Maar ik kom geen syntax tegen hoe ik dit in mijn Compose kan doen. Heeft iemand enig idee?

Heb er nog nooit gebruik van gemaakt maar wel eens tegengekomen ooit, maar misschien werkt dit:

volumes:
my_volume:
driver: local
driver_opts:
type: none
device: "/path/to/your/host/dir"
o: bind
id: "2ah/42d"

Gevonden via: https://forums.docker.com...stom-mount-options/117924

[Webgnome]

Mensen,

heb een vraagje. Ik probeer al de hele avond om eens te kijken of ik grafana, influxdb en telegraf aan de praat kan krijgen op mijn RPI 3.

Mijn compose file ziet er als volgt uit:

[code]
version: "3"

networks:
grafana:

services:
grafana:
image: grafana/grafana
user: 1000:1000
ports:
- 9000:3000
volumes:
- /mnt/ssd/docker/grafana/data/grafana:/var/lib/grafana
- /mnt/ssd/docker/grafana/config/grafana.ini:/etc/grafana/grafana.ini
- /mnt/ssd/docker/grafana/data/logs/grafana:/var/log/grafana
env_file: /mnt/ssd/docker/grafana/config/config.env
networks:
- grafana
links:
- influxdb
depends_on:
- influxdb

influxdb:
user: 1000:1000
image: influxdb
restart: always
volumes:
- /mnt/ssd/docker/grafana/data/influxdb:/var/lib/influxdb
env_file: /mnt/ssd/docker/grafana/config/config.env
networks:
- grafana

telegraf:
image: telegraf
user: 1000:1000
restart: always
volumes:
- /mnt/ssd/docker/grafana/config/telegraf.conf:/etc/telegraf/telegraf.conf:ro
networks:
- grafana
links:
- influxdb
[/]

mijn env ziet er zo uit:
[code]
# Grafana options
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=admin
GF_INSTALL_PLUGINS=
GF_LOG_MODE=file

# InfluxDB options
INFLUXDB_DB=pihole
INFLUXDB_ADMIN_USER=admin
INFLUXDB_ADMIN_PASSWORD=admin
[/]
Niks spannends aan. De paden in de compose file kloppen maar toch als ik deze configuratie start krijgt steevast van telegraf de volgende :

[code]grafana-telegraf-1 | 2022-10-13T19:12:12Z W! [outputs.influxdb] When writing to [http://influxdb:8086]: database "telegraf" creation failed: 401 Unauthorized
[/]

Ik begrijp even niet wat ik verkeerd doe. Dit zou toch moeten werken volgens mij?

[offtopic] En ja natuurlijk ga ik de credentials nog aanpassen in de env file [/]

Nevermind. Influx was versie 2.0 en ik probeerde er op de v1 manier op de connecten.

[Voor 4% gewijzigd door Webgnome op 13-10-2022 21:47]

[Jazco2nd]

Mr.Viper schreef op donderdag 13 oktober 2022 @ 11:43:
[...]


Heb er nog nooit gebruik van gemaakt maar wel eens tegengekomen ooit, maar misschien werkt dit:

volumes:
my_volume:
driver: local
driver_opts:
type: none
device: "/path/to/your/host/dir"
o: bind
id: "2ah/42d"

Gevonden via: https://forums.docker.com...stom-mount-options/117924

Goed gevonden!

Helaas:

code:

volumes:
  userdata:
    driver: local
    driver_opts:
      type: none
      device: $DATAPOOL/users:/user-files
      o: bind
      id: 2aho42d

Geeft:

code:

docker-compose up -d --remove-orphans 
[+] Running 0/0
Volume "docker_userdata"  Error      
Error response from daemon: create docker_userdata: invalid option: "id"

[Mr.Viper]

Jazco2nd schreef op vrijdag 14 oktober 2022 @ 09:29:
[...]


Goed gevonden!

Helaas:

code:

volumes:
  userdata:
    driver: local
    driver_opts:
      type: none
      device: $DATAPOOL/users:/user-files
      o: bind
      id: 2aho42d

Geeft:

code:

docker-compose up -d --remove-orphans 
[+] Running 0/0
Volume "docker_userdata"  Error      
Error response from daemon: create docker_userdata: invalid option: "id"

Werkt dit misschien?

code:

volumes:
  userdata:
    driver: local
    driver_opts:
      type: bind
      device: $DATAPOOL/users:/user-files
      o: "id=2aho42d"

[Jazco2nd]

@Mr.Viper we zijn volgens mij heel dichtbij. De syntax klopt nu, maar blijkbaar kan ik niet zomaar een ID verzinnen (waarom niet?):

Error response from daemon: failed to mount local volume: mount /mnt/pool/users:/user-files:/var/lib/docker/volumes/docker_userdata/_data, data: id=2aho42d: no such device

$DATAPOOL is trouwens "/mnt/pool/"

edit:
Aha, ik kan dus maar 1x een volumenaam gebruiken "userdata", daarna zal altijd die worden gebruikt inclusief het ID dat ik toen in compose had staan. Al verander ik daarna het ID, de foutmelding blijft en blijft het oude ID tonen.
Dus ik moet, als ik verder wil met trial & error, telkens een andere naam gebruiken voor het volume. Er wordt namelijk daadwerkelijk een map /var/lib/docker/volumes/docker_userdata/_data aangemaakt, en die kan je niet verwijderen met docker commandos lijkt het..

Ik begrijp dit niet, zelfs docker prune volumes schoont dit niet op.
En hoe ik van de error af kom weet ik dan ook niet, maar ik begrijp denk ik niet goed wat hier gebeurd.

[Voor 81% gewijzigd door Jazco2nd op 14-10-2022 15:59]

[Yarisken]

Piet400 schreef op vrijdag 19 augustus 2022 @ 16:55:
Heeft iemand een goede suggestie voor een (docker) app waarmee je backups maakt van iOS en Android devices kan maken?

Heb je een goede app gevonden ? Ik ben ook op zoek !

[Jazco2nd]

Yarisken schreef op vrijdag 14 oktober 2022 @ 17:06:
[...]

Heb je een goede app gevonden ? Ik ben ook op zoek !

Wat bedoel je precies? Een complete image? Hoe denk je dat te restoren?

Ik gebruik dus gewoon FolderSync app (webDAV) en synchroniseer (per type data verschillend) mijn /Pictures map een een mapje /Appsbackup waarin Signal, Whatsapp databases, Aegis (2FA), NZB360, Microsoft launcher en FolderSync backup zelf zitten.
Daarnaast heb ik nog een /Shared map die 2-weg synct met de server en met de telefoon van mijn partner, zodat als we op vakantie zijn we onze foto's daarin dumpen en dan hebben we elk alle fotos. Ook als ik die van de losse camera op mn telefoon zet.

Server maakt nachtelijk backup dus dan is al die data ook gebackupped.

Iets wat Android apps configuratie backupped anders dan Google zelf (heel beperkt) bestaat volgens mij niet..

[Mars Warrior]

Jazco2nd schreef op vrijdag 14 oktober 2022 @ 14:15:
@Mr.Viper we zijn volgens mij heel dichtbij. De syntax klopt nu, maar blijkbaar kan ik niet zomaar een ID verzinnen (waarom niet?):

Ik begrijp dit niet, zelfs docker prune volumes schoont dit niet op.
En hoe ik van de error af kom weet ik dan ook niet, maar ik begrijp denk ik niet goed wat hier gebeurd.

Een named volume kun je wel degelijk verwijderen. Ik doe dat regelmatig met Portainer.

Kan het zijn dat er nog een image aan het volume hangt? Dan is het volume namelijk niet te verwijderen.

[Jazco2nd]

Mars Warrior schreef op vrijdag 14 oktober 2022 @ 17:54:
[...]

Een named volume kun je wel degelijk verwijderen. Ik doe dat regelmatig met Portainer.

Kan het zijn dat er nog een image aan het volume hangt? Dan is het volume namelijk niet te verwijderen.

Ja dat is uiteindelijk gelukt.
Maar dan nog krijg ik deze foutmelding:

code:

Error response from daemon: failed to mount local volume: 
mount /mnt/pool/users:/var/lib/docker/volumes/docker_userdata/_data: no such device

Als ik dit gebruik:

code:

volumes:
  userdata:
    driver_opts:
      type: local
      device: /mnt/pool/users

[Dennis]

Mag ik hier ook om wat hulp vragen? Absoluut nieuw met Docker.

Ik wil thuis een proefje draaien met Discourse en dat moet in Docker, anders wordt het niet ondersteund. Gisteren een VPS aangemaakt bij TransIP en deze kan ik via mijn interne netwerk benaderen. Hij draait op Ubuntu 22 en ik heb succesvol Docker geïnstalleerd.

Het lijkt allemaal goed te werken.

code:

administrator@ubuntu:/var/discourse$ sudo docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                                                      NAMES
db85022fb988   local_discourse/app   "/sbin/boot"   30 minutes ago   Up 30 minutes   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app

code:

administrator@ubuntu:/var/discourse$ sudo docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
0efdca436ae8   bridge    bridge    local
40bf93dc2b69   host      host      local
6565085a599a   none      null      local

code:

administrator@ubuntu:/var/discourse$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:a6ff:fedd:f45f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:a6:dd:f4:5f  txqueuelen 0  (Ethernet)
        RX packets 13757  bytes 1301089 (1.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 39251  bytes 134436083 (134.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.1.50  netmask 255.255.255.0  broadcast 172.16.1.255
        inet6 fe80::5054:ff:feb4:9e6d  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:b4:9e:6d  txqueuelen 1000  (Ethernet)
        RX packets 45294  bytes 134912036 (134.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16880  bytes 2803236 (2.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ping werkt goed op hostname. Firewall op de machine staat uit. Maar toch kan ik niet connecten op de poorten 80 en 443. Moet ik nu nog iets instellen aan het bridgen van de netwerken? De tutorials slaan die stappen over en daar kun je in één keer verbinding maken met de administrator-console maar ik krijg een "Kan geen verbinding maken".

Alvast dank voor alle tips.

[Mars Warrior]

Dennis schreef op zaterdag 15 oktober 2022 @ 14:12:
Mag ik hier ook om wat hulp vragen? Absoluut nieuw met Docker.

Ik wil thuis een proefje draaien met Discourse en dat moet in Docker, anders wordt het niet ondersteund. Gisteren een VPS aangemaakt bij TransIP en deze kan ik via mijn interne netwerk benaderen. Hij draait op Ubuntu 22 en ik heb succesvol Docker geïnstalleerd.

Het lijkt allemaal goed te werken.

code:

administrator@ubuntu:/var/discourse$ sudo docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                                                      NAMES
db85022fb988   local_discourse/app   "/sbin/boot"   30 minutes ago   Up 30 minutes   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app

code:

administrator@ubuntu:/var/discourse$ sudo docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
0efdca436ae8   bridge    bridge    local
40bf93dc2b69   host      host      local
6565085a599a   none      null      local

code:

administrator@ubuntu:/var/discourse$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:a6ff:fedd:f45f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:a6:dd:f4:5f  txqueuelen 0  (Ethernet)
        RX packets 13757  bytes 1301089 (1.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 39251  bytes 134436083 (134.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.1.50  netmask 255.255.255.0  broadcast 172.16.1.255
        inet6 fe80::5054:ff:feb4:9e6d  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:b4:9e:6d  txqueuelen 1000  (Ethernet)
        RX packets 45294  bytes 134912036 (134.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16880  bytes 2803236 (2.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ping werkt goed op hostname. Firewall op de machine staat uit. Maar toch kan ik niet connecten op de poorten 80 en 443. Moet ik nu nog iets instellen aan het bridgen van de netwerken? De tutorials slaan die stappen over en daar kun je in één keer verbinding maken met de administrator-console maar ik krijg een "Kan geen verbinding maken".

Alvast dank voor alle tips.

Ik heb geen ervaring met discourse, maar je dient wel de juiste poort mappings te gebruiken, en daarbij de interne Nginx proxy correct te configureren om een SSL certificaat te krijgen.

Lijkt me niet dat dat volledig automatisch werkt zonder dat je de configuratie wijzigt voor het subdomein waarop je discourse wilt laten draaien. Als je meer diensten hebt draaien op 80/443 dan zul je een externe Nginx proxy moeten gebruiken overigens.

[Dennis]

Mars Warrior schreef op zaterdag 15 oktober 2022 @ 15:44:
Ik heb geen ervaring met discourse, maar je dient wel de juiste poort mappings te gebruiken, en daarbij de interne Nginx proxy correct te configureren om een SSL certificaat te krijgen.

Lijkt me niet dat dat volledig automatisch werkt zonder dat je de configuratie wijzigt voor het subdomein waarop je discourse wilt laten draaien. Als je meer diensten hebt draaien op 80/443 dan zul je een externe Nginx proxy moeten gebruiken overigens.

De installatie van discourse regelt wat jij noemt allemaal automagisch. Aan het einde wordt docker run aangeroepen en met de argumenten "-p 80:80 -p 443:443" waarmee (volgens de manual die ik heb gelezen) keurig de portmapping zou moeten werken. Ik zie het ook keurig terug in de ps aux op de host:

code:

root         822  0.0  0.1 1001008 3176 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 443 -container-ip 172.17.0.2 -container-port 443
root         827  0.0  0.1 1074740 3120 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 443 -container-ip 172.17.0.2 -container-port 443
root         840  0.0  0.1 1074740 3264 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 80 -container-ip 172.17.0.2 -container-port 80
root         844  0.0  0.1 1001008 3300 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 80 -container-ip 172.17.0.2 -container-port 80

SSL certificaat kan trouwens ook werken (met let's encrypt) maar aangezien ik bijzondere domeinnaam heb werkt dat niet. Dan zou de foutmelding echter anders moeten zijn en met http op poort 80 werkt het ook niet .

[edit]
Nou, opgelost. Toch even de logfiles van nginx in kunnen zien nadat ik de locatie op internet had gevonden en daar zag ik een fatal error van nginx vanwege... inderdaad @Mars Warrior dank! - het niet kunnen laden van de certificaten.

Gelukkig heb ik mijn eigen CA draaien (EJBCA) dus kon ik even snel geldige certificaten aanmaken.

[Voor 8% gewijzigd door Dennis op 15-10-2022 19:52]

[Mars Warrior]

Dennis schreef op zaterdag 15 oktober 2022 @ 19:33:
[...]

De installatie van discourse regelt wat jij noemt allemaal automagisch. Aan het einde wordt docker run aangeroepen en met de argumenten "-p 80:80 -p 443:443" waarmee (volgens de manual die ik heb gelezen) keurig de portmapping zou moeten werken. Ik zie het ook keurig terug in de ps aux op de host:

code:

root         822  0.0  0.1 1001008 3176 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 443 -container-ip 172.17.0.2 -container-port 443
root         827  0.0  0.1 1074740 3120 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 443 -container-ip 172.17.0.2 -container-port 443
root         840  0.0  0.1 1074740 3264 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 80 -container-ip 172.17.0.2 -container-port 80
root         844  0.0  0.1 1001008 3300 ?        Sl   17:19   0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 80 -container-ip 172.17.0.2 -container-port 80

SSL certificaat kan trouwens ook werken (met let's encrypt) maar aangezien ik bijzondere domeinnaam heb werkt dat niet. Dan zou de foutmelding echter anders moeten zijn en met http op poort 80 werkt het ook niet .

Aha

Ik zie in je ifconfig enkel private adressen staan. Geen publiek adres.
Verder snap ik ff niet hoe je met je domein omgaat. Die moet toch naar het publieke ip van deze vps wijzen?

Afhankelijk hoe de interne nginx server staat geconfigureerd wordt alles naar poort 443 doorgezet. Http wordt dan enkel gebruikt om een ssl certificaat aan te vragen.

Ik vraag me dus of of het een docker probleem is, en niet iets in jou omgeving die niet standaard is, of waarop de discourse config niet is aangepast.

Edit: je hebt het al opgelost

Veel plezier met je VPS!

[DikkieDick]

Ik zit me suf te zoeken waarom het volgende niet werkt. Ik heb een aantal dockerfiles gebaseerd op architectuur die ik aanroep middels docker build -f <filenaam> etc. En dan middels manifest push, maar ik wil graag 1 Dockerfile voor beide architecturen. Volgens de beschrijving op https://www.docker.com/bl...nd-images-the-simple-way/ moet dat ook kunnen.

Maar met mijn stukje code

YAML:

ARG ARCH=
FROM ${ARCH}debian:bullseye-slim

gaat het al mis. Overigens zou er denk ik ${ARCH}/debian;bullseye-slim moeten staan zoals ook mijn afzonderlijke dockerfiles dat hebben.
Maar krijg bij deze de melding:

Bash:

Dockerfile:2
--------------------
   1 |     ARG ARCH=
   2 | >>> FROM ${ARCH}debian:bullseye-slim

ERROR: failed to solve: debian:bullseye-slim: no match for platform in manifest sha256:b46fc4e6813f6cbd9f3f6322c72ab974cc0e75a72ca02730a8861e98999875c7: not found

terwijl ik netjes een docker pull van debian:bullseye-slim kan doen.
Verderop in de dockerfile komen dan ook een paar if-statements om op basis van architectuur een wget te doen. Dat gaat wel (deels) goed als ik bovenstaande niet ARG ARCH= zeg maar ARG ARCH-arm64v8. Maar dan is arm64v8 default en gaat ie ook verder zo gedragen en dat moet niet. Ik wil dus zowel een arm32v7 als arm64v8.

Het script wat de dockerfile aanroept:

Bash:

#!/bin/bash

VANDAAG=$(date +"%Y%m%d")
docker buildx build  --platform linux/arm64/v8,linux/arm32/v7  -f Dockerfile -t pluim003/influxdb-grafana-telegraf:${VANDAAG} --push .

Wat zie ik over het hoofd?

Update: ik kom iets verder:

YAML:

ARG TARGETOS
FROM ${TARGETARCH}${TARGETVARIANT}/debian:bullseye-slim

Dat gaat toevallig cq gelukkig goed voor bijvoorbeeld arm32v7 maar voor arm64 weer niet omdat het image arm64v8/debian:bullseye-slim heet.
En een if-else werkt niet in dit stuk voor zover ik weet.

Update2:
Misschien hielp het om hier het al te deponeren ondanks dat er nog geen reactie was maar bleef nog verder speuren op het wereldwijde web. En dat nadat ik al veelvuldig had gezocht.

Maar kom nu inmiddels bijna tot het eind met de volgende Dockerfile:

YAML:

ARG TARGETOS
FROM arm64v8/debian:bullseye-slim as debian-arm64
FROM arm32v7/debian:bullseye-slim as debian-arm32

# Default versions
ENV INFLUXDB_VERSION=1.8.10
ENV TELEGRAF_VERSION=1.24.2
ENV GRAFANA_VERSION=9.2.1

ENV GF_DATABASE_TYPE=sqlite3

WORKDIR /root

# Clear previous sources
FROM debian-${TARGETARCH}
# Default versions
ENV INFLUXDB_VERSION=1.8.10
ENV TELEGRAF_VERSION=1.24.2
ENV GRAFANA_VERSION=9.2.1

RUN rm /var/lib/apt/lists/* -vf \
    # Base dependencies
    && apt-get -y update \
    && apt-get -y install \
        apt-transport-https \
        apt-utils \
        ca-certificates \
        curl \
        dialog \
        git \
        htop \
        libfontconfig1 \
        lsof \
        nano \
        procps \
        vim \
        net-tools \
        wget \
        gnupg \
        supervisor

# Install InfluxDB
ARG TARGETARCH
ARG INFLUXDB_VERSION=${INFLUXDB_VERSION}
ARG ARCH=${TARGETARCH}
RUN if [ "${TARGETARCH}" = "arm32" ]; then ARCH="armhf"; fi && \
    if [ "$[TARGETARCH]" = "arm64" ]; then ARCH="arm64"; fi && \
  wget https://dl.influxdata.com/influxdb/releases/influxdb_${INFLUXDB_VERSION}_${ARCH}.deb \
    && dpkg -i influxdb_${INFLUXDB_VERSION}_${ARCH}.deb && rm influxdb_${INFLUXDB_VERSION}_${ARCH}.deb \

# Install Telegraf
 && wget  https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_linux_${ARCH}.tar.gz \
     && tar -xf telegraf-${TELEGRAF_VERSION}_linux_${ARCH}.tar.gz -C / && rm telegraf-${TELEGRAF_VERSION}_linux_${ARCH}.tar.gz \
     && cd /telegraf-${TELEGRAF_VERSION} && cp -R * / && cd / && rm -rf telegraf-${TELEGRAF_VERSION} \
     && groupadd -g 998 telegraf && useradd -ms /bin/bash -u 998 -g 998 telegraf \

# Install Grafana
 && apt-get install -y adduser libfontconfig1 \
     && wget https://dl.grafana.com/oss/release/grafana_${GRAFANA_VERSION}_${ARCH}.deb \
     && dpkg -i grafana_${GRAFANA_VERSION}_${ARCH}.deb && rm grafana_${GRAFANA_VERSION}_${ARCH}.deb \
    # Cleanup
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* \
    # Configure Supervisord
    && mkdir -p /var/log/supervisor

COPY supervisord/supervisord.conf /etc/supervisor/conf.d/supervisord.conf

# Configure InfluxDB
COPY influxdb/influxdb.conf /etc/influxdb/influxdb.conf
COPY influxdb/init.sh /etc/init.d/influxdb
RUN chmod 0755 /etc/init.d/influxdb

# Configure Grafana
COPY grafana/grafana.ini /etc/grafana/grafana.ini

# Configure Telegraf
COPY telegraf/init.sh /etc/init.d/telegraf
RUN chmod 0755 /etc/init.d/telegraf

CMD [ "/usr/bin/supervisord" ]

En wordt ook netjes gepusht naar hub.docker.com met nog 1 warning:

Bash:

 1 warning found (use --debug to expand):
 - Empty continuation line found in: RUN if [ "${TARGETARCH}" = "arm32" ]; then ARCH="armhf"; fi &&     if [ "$[TARGETARCH]" = "arm64" ]; then ARCH="arm64"; fi &&   wget https://dl.influxdata.com/influxdb/releases/influxdb_${INFLUXDB_VERSION}_${ARCH}.deb     && dpkg -i influxdb_${INFLUXDB_VERSION}_${ARCH}.deb && rm influxdb_${INFLUXDB_VERSION}_${ARCH}.deb  && wget  https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_linux_${ARCH}.tar.gz      && tar -xf telegraf-${TELEGRAF_VERSION}_linux_${ARCH}.tar.gz -C / && rm telegraf-${TELEGRAF_VERSION}_linux_${ARCH}.tar.gz      && cd /telegraf-${TELEGRAF_VERSION} && cp -R * / && cd / && rm -rf telegraf-${TELEGRAF_VERSION}      && groupadd -g 998 telegraf && useradd -ms /bin/bash -u 998 -g 998 telegraf  && apt-get install -y adduser libfontconfig1      && wget https://dl.grafana.com/oss/release/grafana_${GRAFANA_VERSION}_${ARCH}.deb      && dpkg -i grafana_${GRAFANA_VERSION}_${ARCH}.deb && rm grafana_${GRAFANA_VERSION}_${ARCH}.deb     && apt-get clean     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*     && mkdir -p /var/log/supervisor

Nu nog maar ff finetunen, want die ARG-definities wil buiten het influxdata-stukje hebben maar dat is meer cosmetisch.

Update3:
die optie om met --debug te draaien vat ik niet, want --debug wordt weer niet herkend als parameter bij het docker buildx build-commando. Die empty line waar ie over mekkert komt door de lege regels tussen de diverse installaties. In mijn oorspronkelijke afzonderlijke dockerfiles zijn dat ook 3 verschllende blokken. Nou ja, nu werkt het dus zoals ik wilde. Vraag dus beantwoord, maar laat het ter leringh ende vermaeck hier allemaal maar staan, want dit heeft me de nodige uren zoekwerk gekost. Misschien heeft iemand anders er nog iets aan.

Update4:
Had toch nog een aanpassing nodig, want op mijn Pi2 (32bit) kon ik niet de image pullen. Als platform had ik in het shellscript linux/arm/v7 nodig ipv linux/arm32/v7 en dat resulteerde weer in een aanpassing van de Dockerfile, want nu werd het niet debian-arm32 maar debian-arm.

Zo werd het weer een leerzame dag. :-)

[Voor 68% gewijzigd door DikkieDick op 21-10-2022 15:26]

[Marc3l]

Vandaag het plan om aan een (nieuw) project te werken, was alleen niet vooruit te branden. Ik had Docker nog niet op WSL2 draaien, in het verleden wel mee lopen kloten maar nooit echt lekker aan de praat gekregen. Vandaag toch nog maar een poging gedaan en zowaar gelukt.

Wel aardig wat werk want andere projecten moet ik ook overzetten.
Wel een stuk betere performance dus is het wel waard.

'Oude' Docker omgeving 3x feature/unit test laten draaien (+/- 350 testen)
Time: 02:50.566, Memory: 108.50 MB
Time: 02:11.983, Memory: 108.50 MB
Time: 02:37.326, Memory: 108.50 MB

'Nieuwe' omgeving:
Time: 00:44.691, Memory: 108.50 MB
Time: 00:43.208, Memory: 108.50 MB
Time: 00:52.704, Memory: 108.50 MB

[Webgnome]

en hoe heb je het nu voor elkaar gekregen? Welke tutorial heb je gevolgd, etc etc? Want dat het veel sneller is dat weet het internet wel

[Marc3l]

Webgnome schreef op maandag 24 oktober 2022 @ 17:54:
en hoe heb je het nu voor elkaar gekregen? Welke tutorial heb je gevolgd, etc etc? Want dat het veel sneller is dat weet het internet wel

Dan weet het internet ook dat het gewoon op de site van Docker zelf staat https://docs.docker.com/desktop/windows/wsl/

Update: niet helemaal Docker gerelateerd maar had nog wel een probleem met schrijfrechten.
Ik gebruik Docker voor laravel development en met het 'artisan' commando kan je o.a. testen, migraties, controllers enz. maken. Deze kregen dan als file eigenaar 'root'.

In PHPstorm krijg je bij het aanpassen van zo'n bestand een permissie error.
Daarna maakte het systeem een kopie met ~ achter het bestandsnaam maar dit zag je niet in PHPStorm.

Oplossing is om in de Dockerfile voor PHP een gebruiker aan te maken en deze aan de usergroep toe te voegen zodat nieuwe bestanden via artisan niet worden toegewezen aan de root user.

code:

FROM php:8.1-fpm-alpine

.....

# Create a new user
RUN adduser --disabled-password --gecos '' developer

# Add user to the group
RUN chown -R developer:www-data /var/www

RUN chmod 755 /var/www

# Switch to this user
USER developer

[Voor 54% gewijzigd door Marc3l op 05-11-2022 11:54. Reden: typo/update]

[eheijnen]

Ik heb al flink zitten zoeken maar heb eigenlijk niet echt iets kunnen vinden.
Daarom een generieke vraag.

Voor Docker word aangegeven dat je vanaf kernel 3.xx geen compatibiliteits problemen kunt ondervinden met het draaien van containers.

Is dit zo of zijn er ervaringen bekend dat op bepaalde Linux distros een container problemen heeft en op andere niet?

[Mars Warrior]

eheijnen schreef op dinsdag 8 november 2022 @ 10:56:
Ik heb al flink zitten zoeken maar heb eigenlijk niet echt iets kunnen vinden.
Daarom een generieke vraag.

Voor Docker word aangegeven dat je vanaf kernel 3.xx geen compatibiliteits problemen kunt ondervinden met het draaien van containers.

Is dit zo of zijn er ervaringen bekend dat op bepaalde Linux distros een container problemen heeft en op andere niet?

Docker engine heeft minimaal Linux Kernel 3.10 nodig om te kunnen werken.

Ik gebruik zelf altijd een moderne Linux distro, dus heb verder geen ervaring dat zaken niet werken. In het begin draaide docker het beste onder Ubuntu, maar volgens mij is dat allang niet meer zo, al doet RHEL af en toe zijn best met incompatibel zijn, maar dat is Oracle

[Shattering]

Hey! Ik ben redelijk nieuw in Docker, maar gebruik ondertussen al een jaartje verschillende containers op mijn NUC. Tot nu toe gebruikte ik altijd "docker run" om de containers vervolgens te beheren via Portainer, maar ik zou dit nu wat beter willen aanpakken met behulp van een dockerfile.

Ik merk echter dat als ik een file aanmaken en deze "start" met docker-compose, mijn containers opnieuw worden aangemaakt. Maar ik wil dus mijn huidige containers "converteren" naar docker-compose containers (als dat ergens op slaat ). Kan dit? Kunnen jullie mij in de juiste richting sturen?

Bedankt!

[lolgast]

@Shattering Nee dat kan niet. Waarom zou je dat willen? Het idee van containers is dat er geen nuttige data instaat en dat ze vervangbaar zijn

[itons]

Met docker commit kan je je aanpassingen binnen de container opslaan als image. Of het een goed idee is laat ik in het midden.

https://www.dataset.com/blog/create-docker-image/

[Mars Warrior]

Shattering schreef op dinsdag 8 november 2022 @ 14:49:
Hey! Ik ben redelijk nieuw in Docker, maar gebruik ondertussen al een jaartje verschillende containers op mijn NUC. Tot nu toe gebruikte ik altijd "docker run" om de containers vervolgens te beheren via Portainer, maar ik zou dit nu wat beter willen aanpakken met behulp van een dockerfile.

Ik merk echter dat als ik een file aanmaken en deze "start" met docker-compose, mijn containers opnieuw worden aangemaakt. Maar ik wil dus mijn huidige containers "converteren" naar docker-compose containers (als dat ergens op slaat ). Kan dit? Kunnen jullie mij in de juiste richting sturen?

Bedankt!

Als je docker-compose gebruikt dan doet die het beheer van de containers. Dus wat hij niet kent - buiten DC is aangemaakt - zal opnieuw worden aangemaakt!

[Shattering]

lolgast schreef op dinsdag 8 november 2022 @ 15:10:
@Shattering Nee dat kan niet. Waarom zou je dat willen? Het idee van containers is dat er geen nuttige data instaat en dat ze vervangbaar zijn

Hey! Ik draai mijn HomeAssistant in een docker container, maar mijn config files staan dus buiten de container. Het probleem zat 'm dus in mijn volumes, die had ik verkeerd in m'n dockerfile staan waardoor HA terug "leeg" was. Nu dus gefixt - thx!

[bdu]

Heeft een van jullie al eens een Webdav client (dus geen server) gedraaid middels docker?

Of als volume gebruikt in docker-compose?

Wat ik graag zou willen is snel (en eenvoudig) een webdav folder beschikbaar maken op de host om beschikbaar te maken voor andere containers, of als volume kunnen gebruiken voor een container.

Iets wat op lijkt maar ik niet aan de praat krijg is: https://github.com/efrecon/docker-webdav-client

[DikkieDick]

Eigenaardig probleempje. Ik heb 2 Raspberry Pi's. Een Pi4 en een Pi2 met beiden Docker en een zootje containers. Op de Pi4 wat meer dan de Pi2, maar dat spreekt min of meer voor zich. :-)

Na een reboot van de Pi4 wordt netjes de Docker-daemon gestart. Op de Pi2 echter niet. Moet ik het steeds handmatig doen middels systemctl service start docker. Als ik opvraag wat de status is via systemctl is-enabled docker dan krijg ik de melding enabled. Je zou dus verwachten dat ie netjes zou moeten starten, maar doet ie niet. Waar kan ik nog meer zoeken?

[Webgnome]

wat zeggen de logs?

[DikkieDick]

Webgnome schreef op donderdag 24 november 2022 @ 07:42:
wat zeggen de logs?

Reageerde je op mij? Zo ja, geen logs te vinden. Dacht het met een workaround te doen, maar dat gaat nog niet helemaal zoals ik wil.

Overigens dacht ik eerst even de service te disabelen en vervolgens enabelen, maar dat bood geen soelaas.

De workaround. Start een cronjob onder root die na een reboot + 1 minuut een 'systenctl start docker' doet. Script start netjes maar helaas geen start van docker. Als ik dan middels sudo hetzelfde script start gaat het vlekkenloos.
Na aanpassen met script dat ie ook status opvraagt en dan start doet logt ie wat meer:

Bash:

vr 25 nov 2022 21:44:20 CET
* docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2022-11-25 21:43:00 CET; 1min 19s ago
TriggeredBy: * docker.socket
       Docs: https://docs.docker.com
    Process: 531 ExecStart=/usr/sbin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock $DOCKER_OPTS (code=exited, status=1/FAILURE)
   Main PID: 531 (code=exited, status=1/FAILURE)
        CPU: 544ms

nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Failed with result 'exit-code'.
nov 25 21:43:00 raspberrydick systemd[1]: Failed to start Docker Application Container Engine.
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
nov 25 21:43:00 raspberrydick systemd[1]: Stopped Docker Application Container Engine.
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Start request repeated too quickly.
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Failed with result 'exit-code'.
nov 25 21:43:00 raspberrydick systemd[1]: Failed to start Docker Application Container Engine.
* docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2022-11-25 21:43:00 CET; 1min 21s ago
TriggeredBy: * docker.socket
       Docs: https://docs.docker.com
    Process: 531 ExecStart=/usr/sbin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock $DOCKER_OPTS (code=exited, status=1/FAILURE)
   Main PID: 531 (code=exited, status=1/FAILURE)
        CPU: 544ms

nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Failed with result 'exit-code'.
nov 25 21:43:00 raspberrydick systemd[1]: Failed to start Docker Application Container Engine.
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
nov 25 21:43:00 raspberrydick systemd[1]: Stopped Docker Application Container Engine.
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Start request repeated too quickly.
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Failed with result 'exit-code'.
nov 25 21:43:00 raspberrydick systemd[1]: Failed to start Docker Application Container Engine.
nov 25 21:44:22 raspberrydick systemd[1]: docker.service: Start request repeated too quickly.
nov 25 21:44:22 raspberrydick systemd[1]: docker.service: Failed with result 'exit-code'.
nov 25 21:44:22 raspberrydick systemd[1]: Failed to start Docker Application Container Engine.
vr 25 nov 2022 21:44:22 CET

En draai ik hem vervolgens via sudo start_docker.sh:

Bash:

pi@raspberrydick:~/scripts $ sudo /home/pi/scripts/start_docker.sh
vr 25 nov 2022 21:48:20 CET
vr 25 nov 2022 21:49:20 CET
* docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset>
     Active: failed (Result: exit-code) since Fri 2022-11-25 21:43:00 CET; 6min>
TriggeredBy: * docker.socket
       Docs: https://docs.docker.com
    Process: 531 ExecStart=/usr/sbin/dockerd -H fd:// --containerd=/run/contain>
   Main PID: 531 (code=exited, status=1/FAILURE)
        CPU: 544ms

nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Failed with result 'e>
nov 25 21:43:00 raspberrydick systemd[1]: Failed to start Docker Application Co>
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Scheduled restart job>
nov 25 21:43:00 raspberrydick systemd[1]: Stopped Docker Application Container >
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Start request repeate>
nov 25 21:43:00 raspberrydick systemd[1]: docker.service: Failed with result 'e>
nov 25 21:43:00 raspberrydick systemd[1]: Failed to start Docker Application Co>
nov 25 21:44:22 raspberrydick systemd[1]: docker.service: Start request repeate>
nov 25 21:44:22 raspberrydick systemd[1]: docker.service: Failed with result 'e>
nov 25 21:44:22 raspberrydick systemd[1]: Failed to start Docker Application Co>

* docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset>
     Active: active (running) since Fri 2022-11-25 21:50:00 CET; 71ms ago
TriggeredBy: * docker.socket
       Docs: https://docs.docker.com
   Main PID: 1353 (dockerd)
      Tasks: 72
        CPU: 11.098s
     CGroup: /system.slice/docker.service
             |-1353 /usr/sbin/dockerd -H fd:// --containerd=/run/containerd/con>
             |-1570 /usr/sbin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-po>
             |-1574 /usr/sbin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-po>
             |-1624 /usr/sbin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-po>
             |-1632 /usr/sbin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-po>
             |-1661 /usr/sbin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-po>
             |-1673 /usr/sbin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-po>
             `-1699 /usr/sbin/docker-proxy -proto udp -host-ip 0.0.0.0 -host-po>

nov 25 21:49:46 raspberrydick dockerd[1353]: time="2022-11-25T21:49:46.53766457>
nov 25 21:49:47 raspberrydick dockerd[1353]: time="2022-11-25T21:49:47.00584921>
nov 25 21:49:48 raspberrydick dockerd[1353]: time="2022-11-25T21:49:48.41394001>
nov 25 21:49:48 raspberrydick dockerd[1353]: time="2022-11-25T21:49:48.41835023>
nov 25 21:49:48 raspberrydick dockerd[1353]: time="2022-11-25T21:49:48.42901847>
nov 25 21:49:51 raspberrydick dockerd[1353]: time="2022-11-25T21:49:51.18258596>
nov 25 21:49:58 raspberrydick dockerd[1353]: time="2022-11-25T21:49:58.66442019>
nov 25 21:49:59 raspberrydick dockerd[1353]: time="2022-11-25T21:49:59.59577972>
nov 25 21:49:59 raspberrydick dockerd[1353]: time="2022-11-25T21:49:59.61548983>
nov 25 21:50:00 raspberrydick systemd[1]: Started Docker Application Container >
vr 25 nov 2022 21:50:10 CET

Wat ik nog kan proberen is niet 1 minuut na reboot starten maar iets later omdat mogelijk nog niet alle afhankelijkheden zijn gestart.

Update: klaarblijkelijk inderdaad niet genoeg. Heb er 2 minuten van gemaakt en toen ging ie van een leien dakje. Hier kan ik mee leven.

[Voor 32% gewijzigd door DikkieDick op 25-11-2022 21:59]

[Jazco2nd]

Ik heb een vraag over Named Volumes.
Kan het nergens vinden. Ik gebruik Docker Compose 2.4 (de laatste versie voordat het Swarm werd, dit betreft een thuisserver).

host:
OS: Manjaro Linux (Arch based dus)
Filesystem: BTRFS

Het gaat dus hierom:
https://docs.docker.com/c.../compose-file-v2/#volumes
https://docs.docker.com/e...ommandline/volume_create/
En hier staat "local" nieteens genoemd als storage driver: https://docs.docker.com/storage/

Mijn vraag:
Voor een bepaalde service mag wanneer ik de container recreate, de ID van de mapped volume niet wijzigen. Deze service ondersteund namelijk webDAV en wanneer het ID van de mapped volume wijzigt, wijzigt ook het webDAV id en denken alle clients die syncen dat ze alles geheel opnieuw moeten syncen.
Als je dus 1TB in sync houdt met je laptop, wordt telkens 1 TB geschreven wanneer de container op de server wordt recreated.
Om dit op te lossen vervang ik dit:

code:

services:
  filerun:
    volumes:
      - /mnt/pool/users:/user-files

Voor dit:

code:

services:
  filerun:
    volumes:
      - userdata:/user-files

volumes:
  userdata:
    driver_opts:
      type: btrfs
      device: /dev/sdb
      o: "defaults,noatime,compress-force=zstd:3" # simply copied from /etc/fstab

Dat gaat goed, ik check dit door in de container, via Portainer, dit commando te draaien, voor en nadat ik de container recreate, zie ik altijd Device: 43h/67d, waar dat eerst iedere keer een ander ID was:

code:

stat /user-files        
  File: /user-files
  Size: 80              Blocks: 32         IO Block: 4096   directory
Device: 43h/67d Inode: 256         Links: 1

De grote vraag die ik nu heb:
Docker Engine gebruikt bij mij standaard BTRFS, daar heb ik niks voor hoeven te doen, omdat mijn host dat filesystem gebruikt.

Maar moet ik dan voor dit named volume ook echt type: btrfs invullen ? Of volstaat type: local ?
Ik kan nergens, maar dan ook echt nergens de betekenis van "local" vinden binnen de context van volumes. Wat houdt dat precies in?
Ik zie wel dit staan, maar hoe mag je dat interpreteren?

The container creation endpoint (/containers/create) accepts a VolumeDriver field of type string allowing to specify the name of the driver. If not specified, it defaults to "local" (the default driver for local volumes).

Wat is de default driver voor local volumes precies?
En hoe weet ik zeker dat als ik toch gewoon "local" gebruik, dat mijn data opgeslagen in /mnt/pool/users daadwerkelijk de compressie optie volgt die ik in mijn /etc/fstab heb staan, wanneer ik data via de docker container opsla in dit named volume?

[orvintax]

Jazco2nd schreef op vrijdag 6 januari 2023 @ 13:01:
Ik heb een vraag over Named Volumes.
Kan het nergens vinden. Ik gebruik Docker Compose 2.4 (de laatste versie voordat het Swarm werd, dit betreft een thuisserver).

host:
OS: Manjaro Linux (Arch based dus)
Filesystem: BTRFS

Het gaat dus hierom:
https://docs.docker.com/c.../compose-file-v2/#volumes
https://docs.docker.com/e...ommandline/volume_create/
En hier staat "local" nieteens genoemd als storage driver: https://docs.docker.com/storage/

Mijn vraag:
Voor een bepaalde service mag wanneer ik de container recreate, de ID van de mapped volume niet wijzigen. Deze service ondersteund namelijk webDAV en wanneer het ID van de mapped volume wijzigt, wijzigt ook het webDAV id en denken alle clients die syncen dat ze alles geheel opnieuw moeten syncen.
Als je dus 1TB in sync houdt met je laptop, wordt telkens 1 TB geschreven wanneer de container op de server wordt recreated.
Om dit op te lossen vervang ik dit:

code:

services:
  filerun:
    volumes:
      - /mnt/pool/users:/user-files

Voor dit:

code:

services:
  filerun:
    volumes:
      - userdata:/user-files

volumes:
  userdata:
    driver_opts:
      type: btrfs
      device: /dev/sdb
      o: "defaults,noatime,compress-force=zstd:3" # simply copied from /etc/fstab

Dat gaat goed, ik check dit door in de container, via Portainer, dit commando te draaien, voor en nadat ik de container recreate, zie ik altijd Device: 43h/67d, waar dat eerst iedere keer een ander ID was:

code:

stat /user-files        
  File: /user-files
  Size: 80              Blocks: 32         IO Block: 4096   directory
Device: 43h/67d Inode: 256         Links: 1

De grote vraag die ik nu heb:
Docker Engine gebruikt bij mij standaard BTRFS, daar heb ik niks voor hoeven te doen, omdat mijn host dat filesystem gebruikt.

Maar moet ik dan voor dit named volume ook echt type: btrfs invullen ? Of volstaat type: local ?
Ik kan nergens, maar dan ook echt nergens de betekenis van "local" vinden binnen de context van volumes. Wat houdt dat precies in?
Ik zie wel dit staan, maar hoe mag je dat interpreteren?


[...]


Wat is de default driver voor local volumes precies?
En hoe weet ik zeker dat als ik toch gewoon "local" gebruik, dat mijn data opgeslagen in /mnt/pool/users daadwerkelijk de compressie optie volgt die ik in mijn /etc/fstab heb staan, wanneer ik data via de docker container opsla in dit named volume?

Zover ik er mee bekend ben gaan storage drivers alleen over images en containers, niet over volumes. Dit lijkt ook impliciet bevestigd door wat ik lees op deze pagina.

Ideally, very little data is written to a container’s writable layer, and you use Docker volumes to write data. However, some workloads require you to be able to write to the container’s writable layer. This is where storage drivers come in.

Volumes gebruiken gewoon het onderlingende filesystem zover ik weet.

[Jazco2nd]

orvintax schreef op vrijdag 6 januari 2023 @ 16:53:
[...]

Zover ik er mee bekend ben gaan storage drivers alleen over images en containers, niet over volumes. Dit lijkt ook impliciet bevestigd door wat ik lees op deze pagina.

[...]

Volumes gebruiken gewoon het onderlingende filesystem zover ik weet.

Dat kan niet juist zijn, immers moet je een device en type opgeven onder de hoofdsectie "volumes"..
als type niet op storage driver slaat, waar dan wel op?

Nu snap ik er nog minder van..

[orvintax]

Jazco2nd schreef op vrijdag 6 januari 2023 @ 16:56:
[...]


Dat kan niet juist zijn, immers moet je een device en type opgeven onder de hoofdsectie "volumes"..
als type niet op storage driver slaat, waar dan wel op?

Nu snap ik er nog minder van..

Toch heb ik hier de docker compose file van mijn werk omgeving voor me staan, waarin dit allemaal niet word aangegeven. Misschien dat er een default is, of misschien dat er tussen 2.4 en 3 (versie van werk) er iets is veranderd. Maar het lijkt niet vereist te zijn.

[RobertMe]

Wellicht dat ik hier met mijn, wat meer high level, vraag terecht kan.

Momenteel heb ik een Proxmox machine met daarop enkele LXC containers waarin vervolgens Docker draait. De reden dat ik dit zo heb is omdat ik in mijn netwerk meerdere VLANs heb en daarmee cintainers in het juiste VLAN kan plaatsen. Zo heb ik bv een LXC "controller.iot" waar dan Docker in draait met bv Home Assistant, een SQL Database, DSMR Reader, .... Waarbij alles dus in het IoT VLAN zit en poorten die ik open zet ook alleen in het IoT VLAN bereikbaar zijn. En hetzelfde idee heb ik dan gedaan met meerdere zaken. Een LXC vanuit Proxmox waarbij de LXC aan één specifiek VLAN gekoppeld is en port forwards etc alleen vanuit dat VLAN bereikbaar zijn en het spul in de LXC / docker dus ook niet met andere VLANs kan communiceren.
An zich werkt dit prima, alleen valt dat extra laagje mij tegen. In principe heb ik nu niet één OS dat ik moet onderhouden (Proxmox / dat wat bare metal draait), maar een stuk of 10 (Proxmox + de LXCs). Waarbij dus elk geupdate moeten worden, ik soms 2 keer zaken moet mappen (Proxmox => LXC => Docker), etc. Qua onderhoud niet ideaal dus.

Intussen heb ik een nieuw mini PCtje gekocht en wil ik hier nog eens goed naar kijken. En dus of ik niet bv gewoon Debian kan draaien met Proxmox en alles overal juist in prop. Daarnaast wil ik ook "Docker Docker" evalueren of ik dat wil blijven gebruiken, of bv de overstap maken naar Podman (lees: een alternatieve OCI compliant runtime).
Voordeeltje wat ik daarbij zie bij Podman is dat dit een "pod" concept heeft, net zoals Kubernetes. Waarbij je meerdere containers in dezelfde namespace kunt plaatsen en bv zaken als networking gewoon "localhost" kunnen gebruiken binnen dezelfde pod (bv Home Assistant die via localhost met Mosquito verbind, omdat ze dezelfde netwerk namespace / netwerk interface delen). Alleen zie ik dus niet hoe ik bv een complete pod dan aan een eigen interface / VLAN kan koppelen. Maar bij Docker lijkt dit ook nogal complex te regelen te zijn (voorbeeld dat ik een tijdje terug gevonden heb zet volledige iptables / firewall management van Docker uit. Waardoor zelf de regels aangemaakt kunnen worden en dus ook SNAT toegepast kan worden om alle verkeer vanaf een Docker bridge uit te sturen / te NATen over een specifieke andere interface (/VLAN)).

Heeft iemand hier dus (toevallig) kennis van en/of ervaring met dit soort zaken? Dus in het kort "specifieke containers v.w.b. het netwerk specifieke VLANs laten gebruiken, zowel voor inkomende als uitgaande verbindingen".

De reden dat ik overigens wel in de "Docker" (/Podman / ...) hoek wil blijven is, uiteraard, het gemak. Gewoon een pull + "up" / recreate en de boel is bijgewerkt. Alternatief zou in principe LXC kunnen zijn, zonder Docker er in dan, maar dan heeft elk "programma" natuurlijk weer zijn eigen installatie & update methode, dependencies die allemaal moeten kloppen, etc.

[Mars Warrior]

@RobertMe , je kunt binnen Docker toch gewoon eigen netwerken maken, waarna de naam van de container bekend is op dat netwerk?

Podman gebruik ik niet, dus ook geen idee van de verschillen en of elke container het dan nog blijft doen.

Ik gebruik voor een aantal zaken macvlans zodat ik vanaf buiten altijd weet hoe ik een bepaalde container kan bereiken.

[RobertMe]

Mars Warrior schreef op maandag 16 januari 2023 @ 17:36:
@RobertMe , je kunt binnen Docker toch gewoon eigen netwerken maken, waarna de naam van de container bekend is op dat netwerk?

Klopt, maar een (docker) netwerk kan niet aan een VLAN worden gekoppeld (tenzij iptables support in Docker uit wordt gezet en dan zelf een SNAT regel maken om de bridge behorende tot het netwerk te NATen naar de interface naar keuze).

Podman gebruik ik niet, dus ook geen idee van de verschillen en of elke container het dan nog blijft doen.

Intussen is het al een aantal jaren zo dat dat uit Docker een aantal standaarden ontstaan zijn op gebied van image, runtime, ... en dat Docker zelf maar een van de implementaties is, net zoals Kubernetes een implementatie van een runtime bevat, en dus ook Podman een implementatie is. Dus als het goed is werken alle Docker images ook met Podman.

Ik gebruik voor een aantal zaken macvlans zodat ik vanaf buiten altijd weet hoe ik een bepaalde container kan bereiken.

Nadeel daarvan is dan weer dat alles direct aan het netwerk hangt. Ik hoef niet voor 10 containers ook 10 clients in de router te zien Maar inderdaad, macvlan kan weer wel aan een specifieke parent interface gekoppeld worden en dus aan een VLAN.

[Freee!!]

RobertMe schreef op maandag 16 januari 2023 @ 17:53:
[...]
Nadeel daarvan is dan weer dat alles direct aan het netwerk hangt. Ik hoef niet voor 10 containers ook 10 clients in de router te zien Maar inderdaad, macvlan kan weer wel aan een specifieke parent interface gekoppeld worden en dus aan een VLAN.

Macvlan moet je alleen gebruiken voor containers, die van buitenaf te bereiken moeten zijn.

[RobertMe]

Freee!! schreef op maandag 16 januari 2023 @ 18:20:
[...]

Macvlan moet je alleen gebruiken voor containers, die van buitenaf te bereiken moeten zijn.

Nja, dat zijn er dus ook weer meerdere. Kijk ik alleen naar mijn "controller.iot" LXC kom ik op mijn hoofd uit op:

• Home Assistant
• Mosquito
• Zigbee2mqtt
• Zwavejs UI
• ESPHome
• DSMR Reader
• PostgreSQL
• Traefik

Waarvan dan überhaupt maar een klein deel echt toegang tot netwerk nodig heeft. Home Assistant uiteraard om met apparaten en webservices te babbelen (hangt omwille van mDNS / discovery ook nu al in macvlan); ESPHome voor flashen ESPs; DSMR Reader omdat die via ser2net met een ESP aan de meter babbelt; Traefik dan als proxy naar een aantal zaken en naar buiten/internet toe voor Lets Encrypt; De rest heeft sowieso überhaupt geen netwerk toegang nodig. Maar ook dan zou het eigenlijk fijn zijn als ik die 4 kan combineren tot 1 IP / interface. (/Traefik zou ik effectief de voorkeur geven aan één instance globaal. Nu heb ik ook meerdere LXCs met Traefik voor Docker auto discovery doeleinden).

[Shadow771]

Freee!! schreef op maandag 16 januari 2023 @ 18:20:
[...]

Macvlan moet je alleen gebruiken voor containers, die van buitenaf te bereiken moeten zijn.

Waarom moet je macvlan gebruiken om je containers van buitenaf bereikbaar te maken?

[RobertMe]

Shadow771 schreef op dinsdag 17 januari 2023 @ 15:12:
[...]


Waarom moet je macvlan gebruiken om je containers van buitenaf bereikbaar te maken?

Dat moet niet, maar is in een aantal situaties wel een semi vereiste. Bv software die iets met auto discovery / broadcast packets doet werkt niet als je deze op de standaard manier gebruikt. Dit omdat ze dan in een eigen (virtueel) netwerk hangen, achter NAT. En de broadcast berichten dus beperkt blijven tot binnen dat netwerk.

Alternatief is network_mode: host. Maar dat haalt enigszins het hele idee van netwerk isolatie onderuit doordat de container dan überhaupt gewoon de interface(s) van de host gebruikt. Daar waar met macvlan een aparte netwerk interface wordt aangemaakt die ook aan het echte netwerk hangt. Waardoor die container zijn eigen "publieke" IP krijgt, alle poorten ook rechtstreeks open staan, etc.

[Freee!!]

Shadow771 schreef op dinsdag 17 januari 2023 @ 15:12:
[...]
Waarom moet je macvlan gebruiken om je containers van buitenaf bereikbaar te maken?

Je draait nu de zaken even om. Ik zeg niet dat je macvlan moet gebruiken, ik zeg, dat je het alleen moet gebruiken voor containers, die van buitenaf bereikbaar moeten zijn en niet voor containers, waarvoor dat niet geldt. Overigens zijn er ook alternatieven voor macvlan, maar dat is weer een ander verhaal.

[Raven]

RobertMe schreef op dinsdag 17 januari 2023 @ 16:31:
En de broadcast berichten dus beperkt blijven tot binnen dat netwerk.

* Raven gebruikt https://wiki.debian.org/Avahi om dergelijke berichten door te sturen naar andere VLAN's

[RobertMe]

Raven schreef op dinsdag 17 januari 2023 @ 17:32:
[...]

* Raven gebruikt https://wiki.debian.org/Avahi om dergelijke berichten door te sturen naar andere VLAN's

Avahi is alleen mDNS? Dat werkt dus niet voor IGMP, UPnP en ander broadcast verkeer.

Edit: overigens is mDNS dan wel weer de meest gebruikte optie. Maar vooral vroeger zag je ook nog wel eens IGMP. Mijn versterker (Denon AVR-X2400H) werkte vroeger niet met de Denon Heos app doordat de versterker in ander VLAN zat en die niet via mDNS (dat ik ook op router ingeschakeld heb) werkte. Later werkte dat weer wel. Dus zal met een firmware update vast geswitcht zijn.

[Voor 37% gewijzigd door RobertMe op 17-01-2023 17:59]

[Raven]

RobertMe schreef op dinsdag 17 januari 2023 @ 17:48:
[...]

Avahi is alleen mDNS? Dat werkt dus niet voor IGMP, UPnP en ander broadcast verkeer.

IGMP en UPnP heb ik nog niet mee te maken gehad, mDNS werkt i.i.g. goed

[Djarune]

Vraagje hier, want ik kom er niet helemaal uit.

Ik had een "User Defined Bridge" netwerk (172.18.0.0/16) waarin 5 containers draaiden. Dat is fijn, want ze kunnen met elkaar communiceren m.b.v. DNS naam (container naam).

Nu heb ik sinds kort een wireguard vpn container draaien op een nieuw bridge netwerk (172.50.0.0/16). Van de 5 containers uit de oude situatie heb ik er 2 zo ingericht dat ze het netwerk van de vpn container draaien en dat werkt. Echter wil ik de overige containers op het oude netwerk zonder vpn houden.

Het probleem is nu dat de containers van het oude netwerk niet met containers van het vpn netwerk kunnen communiceren en vice versa. Het zijn immers beide geisoleerde bridge netwerken. Hoe kan ik ze wel laten communiceren? Met een Nginx reverse proxy? En hoe moet dat? Ik zou eigenlijk een tuturial ofzo.

[Mr.Viper]

Djarune schreef op woensdag 18 januari 2023 @ 16:05:
Vraagje hier, want ik kom er niet helemaal uit.

Ik had een "User Defined Bridge" netwerk (172.18.0.0/16) waarin 5 containers draaiden. Dat is fijn, want ze kunnen met elkaar communiceren m.b.v. DNS naam (container naam).

Nu heb ik sinds kort een wireguard vpn container draaien op een nieuw bridge netwerk (172.50.0.0/16). Van de 5 containers uit de oude situatie heb ik er 2 zo ingericht dat ze het netwerk van de vpn container draaien en dat werkt. Echter wil ik de overige containers op het oude netwerk zonder vpn houden.

Het probleem is nu dat de containers van het oude netwerk niet met containers van het vpn netwerk kunnen communiceren en vice versa. Het zijn immers beide geisoleerde bridge netwerken. Hoe kan ik ze wel laten communiceren? Met een Nginx reverse proxy? En hoe moet dat? Ik zou eigenlijk een tuturial ofzo.

Volgens mij kun je containers ook in 2 netwerken zetten. Tenminste zo heb ik een bridge en een macvlan gecombineerd...

[Djarune]

Mr.Viper schreef op woensdag 18 januari 2023 @ 16:08:
[...]


Volgens mij kun je containers ook in 2 netwerken zetten. Tenminste zo heb ik een bridge en een macvlan gecombineerd...

dat kan, maar dan snap ik niet hoe het dan ingericht kan worden.

Met 2 netwerken zou op bridge netwerk A: alle 5 containers draaien en op vpn bridge netwerk B: 2 containers (+ nog de wireguard container). Hoe zorg ik ervoor dat de 2 containers die zowel op A en B draaien enkel via vpn laat verlopen?

[RobertMe]

Djarune schreef op woensdag 18 januari 2023 @ 16:14:
[...]

dat kan, maar dan snap ik niet hoe het dan ingericht kan worden.

Met 2 netwerken zou op bridge netwerk A: alle 5 containers draaien en op vpn bridge netwerk B: 2 containers (+ nog de wireguard container). Hoe zorg ik ervoor dat de 2 containers die zowel op A en B draaien enkel via vpn laat verlopen?

Met wat geluk door te zorgen dat de interface met wireguard netwerk de eerste interface is, door dat ook als eerste netwerk te gebruiken.
Dit kun je ook controleren door in de uiteindelijke container ip route uit te voeren. Dan zou je moeten zien dat de default route via dat netwerk gaat.

[Raven]

Mr.Viper schreef op woensdag 18 januari 2023 @ 16:08:
[...]


Volgens mij kun je containers ook in 2 netwerken zetten. Tenminste zo heb ik een bridge en een macvlan gecombineerd...

Daar heb ik een tijd terug eens naar zitten Googlen, maar kon niet zo gauw wat vinden om een container aan meerdere macvlan's tegelijk te koppelen (of ik heb er overheen gekeken)

[Shadow771]

Raven schreef op woensdag 18 januari 2023 @ 17:57:
[...]

Daar heb ik een tijd terug eens naar zitten Googlen, maar kon niet zo gauw wat vinden om een container aan meerdere macvlan's tegelijk te koppelen (of ik heb er overheen gekeken)

Vanuitgaande dat je de macvlan netwerken al aangemaakt hebt:
docker network connect ?

[Raven]

Shadow771 schreef op woensdag 18 januari 2023 @ 18:31:
[...]


Vanuitgaande dat je de macvlan netwerken al aangemaakt hebt:
docker network connect ?

Dat klinkt bekend, volgens mij had ik daar wel iets over gelezen maar geskipt nadat ik zag dat het alleen bij al draaiende containers gedaan kon worden. Ik zocht toen iets waarmee ik bij het aanmaken (achter docker run commando) al meteen meerdere netwerken kon opgeven.

[Shadow771]

Raven schreef op woensdag 18 januari 2023 @ 18:49:
[...]

Dat klinkt bekend, volgens mij had ik daar wel iets over gelezen maar geskipt nadat ik zag dat het alleen bij al draaiende containers gedaan kon worden. Ik zocht toen iets waarmee ik bij het aanmaken (achter docker run commando) al meteen meerdere netwerken kon opgeven.

De container hoeft niet persee te draaien. Zolang het wel al bestaat zal de "docker network connect" commando werken.

En idd zover ik weer kan je idd maar 1 netwerk opgeven achter het 'docker run' commando. Dus ik denk dat je docker-compose nodig heb om zoiets te simuleren wat je wilt.

[Djarune]

@Mr.Viper @RobertMe
Het is me gelukt door alle containers in 1 bridge netwerk te zetten.
De containers die via VPN moeten gaan via de wireguard container. In docker compose te doen met het volgende onder services. <container_via_vpn> als voorbeeld container en wireguard als de vpn container.

code:

services:
  <container_via_vpn>:   
    network_mode: service:wireguard

De containers die ik niet via VPN wil laten verlopen krijgen enkel een fixed IP binnen hetzelfde netwerk.

Vervolgens kunnen de containers binnen de wireguard container wel communiceren met de containers buiten de wireguard container, maar in hetzelfde bridge netwerk.

[Broodje_Aap]

Ik gooi even een balletje op hier,

Ik heb een thuisserver waar ik UNRAID op draai, met een Wireguard VPN. Voor de installatie van zonnepanelen heeft het huis even zonder stroom gezeten, waarbij de server netjes is afgesloten. Hierna heb ik de server ook geüpdatet naar de nieuwste stable versie van UNRAID (6.11.5) ik draaide 6.10.3.

Nu heb ik het volgende probleem. Als ik vanuit een extern netwerk verbind met mijn VPN kan ik succesvol verbinden. Ik kan services bereiken op mijn interne netwerk (zoals mijn router en dergelijke) mijn geen van mijn Docker containers. Ik heb geen idee of er iets mis is met mijn configuratie of dat het misschien een bug is.

Port forward en static route zijn aangemaakt voor mijn Wireguard configuratie (en dat werkt ook aangezien ik mijn router van binnenuit kan benaderen)

Docker is met UNRAID versie 6.11.4 geüpdatet naar version 20.10.21.

Docker network type staat op MACVLAN.
Host access to custom networks staat ook aan.
Preserve user defined networks NO.
Containers draaien in Br0 met allemaal een eigen IP.

Mijn tunnel heeft Pi-Hole Docker container als DNS. Als ik een NSLOOKUP doe voor een andere container krijg ik netjes een reply van Pi-Hole met het IP van de reversed proxy (ook een Docker container) maar als ik vervolgens met de browser naar dat IP of hostname ga krijg ik een ERROR CONNECTION TIMED OUT.

Ik kan me niet voorstellen dat met een power outage (waarbij de server gewoon netjes is afgesloten) Wireguard opeens niet meer normaal kan communiceren met docker containers.

Is er iets met een update van Docker geweest waardoor ik iets anders in moet stellen?
Heeft iemand enig idee wat er fout gaat?

[Jazco2nd]

@Broodje_Aap waarom precies gebruik je macvlan?
Ik gebruik zelf geen Unraid. Mijn server draait Manjaro Gnome (= Arch based. Nooit meer upgrades. Alleen incrementele updates. Goede documentatie beschikbaar.) en is verder Docker Compose based. Werkt heerlijk en lekker zuinig.

Heb dus ook WireGuard VPN, sterker nog, al mijn mobile devices verbinden automatisch wanneer ze mijn LAN/WiFi verlaten met mijn VPN, maar alleen voor de DNS verzoeken. Zodat die gefilterd worden door AdGuard Home. Bijkomend voordeel is dat ik dankzij DNS-via-VPN ook toegang heb tot 192.168.x.x dus ook mijn Docker services altijd kan benaderen.

macvlan heb ik vroeger mee gestoeid maar blijf ik graag beetje ver van wanneer het niet nodig is.
Mijn containers hebben elk hun eigen local domein (ipv eigen IP), een domein dat niet exposed is online.
Slechts enkele containers hebben wel een exposed (https) domein (paswoord manager, filecloud, firefox sync server).

Zo bereik ik portainer via http://docker.o/, Jellyfin via jellyfin.o/ Sonarr via sonarr.o/ etc. _{(die / op het einde is wat je nodig hebt in moderne browsers als "trucje" zodat ze niet automatisch https ervan maken).}
Ook via VPN werkt dit prima. Ze zijn ook nog steeds bereikbaar via mijn server lan IP:Port. Maar dat gebruik ik eigenlijk nooit. Ik hoef dus nooit IP adressen op te zoeken/in te voeren om de services te benaderen.

En hier is dus geen macvlan voor nodig.
Hoe ik dat doe staat hier en dan Stap 4: https://github.com/zilexa/Homeserver

Het kan dus wellicht simpeler?

[Voor 8% gewijzigd door Jazco2nd op 06-02-2023 12:19]

[Broodje_Aap]

Jazco2nd schreef op maandag 6 februari 2023 @ 11:39:
@Broodje_Aap waarom precies gebruik je macvlan?
Ik gebruik zelf geen Unraid. Mijn server draait Manjaro Gnome (= Arch based. Nooit meer upgrades. Alleen incrementele updates. Goede documentatie beschikbaar.) en is verder Docker Compose based. Werkt heerlijk en lekker zuinig.

Heb dus ook WireGuard VPN, sterker nog, al mijn mobile devices verbinden automatisch wanneer ze mijn LAN/WiFi verlaten met mijn VPN, maar alleen voor de DNS verzoeken. Zodat die gefilterd worden door AdGuard Home. Bijkomend voordeel is dat ik dankzij DNS-via-VPN ook toegang heb tot 192.168.x.x dus ook mijn Docker services altijd kan benaderen.

macvlan heb ik vroeger mee gestoeid maar blijf ik graag beetje ver van wanneer het niet nodig is.
Mijn containers hebben elk hun eigen local domein (ipv eigen IP), een domein dat niet exposed is online.
Slechts enkele containers hebben wel een exposed (https) domein (paswoord manager, filecloud, firefox sync server).

Zo bereik ik portainer via http://docker.o/, Jellyfin via jellyfin.o/ Sonarr via sonarr.o/ etc. _{(die / op het einde is wat je nodig hebt in moderne browsers als "trucje" zodat ze niet automatisch https ervan maken).}
Ook via VPN werkt dit prima. Ze zijn ook nog steeds bereikbaar via mijn server lan IP:Port. Maar dat gebruik ik eigenlijk nooit. Ik hoef dus nooit IP adressen op te zoeken/in te voeren om de services te benaderen.

En hier is dus geen macvlan voor nodig.
Hoe ik dat doe staat hier en dan Stap 4: https://github.com/zilexa/Homeserver

Het kan dus wellicht simpeler?

Ik gebruik MACVLAN omdat dit bij het updaten naar een nieuwe versie van Docker automatisch is omgezet. Ik gebruik het dus niet met een specifieke reden. Er staat mij wel bij dat ik dit al eens heb gewijzigd (MACVLAN > IPVLAN), zonder succes, dus had ik het daarna maar weer terug gewijzigd.

Ik hoef daarnaast ook in principe geen IP adressen op te zoeken, omdat ik gebruik maak van een reversed proxy, maar ik maakte in dit geval gebruik van IPs om DNS problemen uit te sluiten.

Jij zegt dus dat het beter zou moeten werken met IPVLAN? Heb je daar verder nog tips bij?

[Mars Warrior]

Broodje_Aap schreef op maandag 6 februari 2023 @ 18:43:
[...]
Ik gebruik MACVLAN omdat dit bij het updaten naar een nieuwe versie van Docker automatisch is omgezet. Ik gebruik het dus niet met een specifieke reden. Er staat mij wel bij dat ik dit al eens heb gewijzigd (MACVLAN > IPVLAN), zonder succes, dus had ik het daarna maar weer terug gewijzigd.

Ik hoef daarnaast ook in principe geen IP adressen op te zoeken, omdat ik gebruik maak van een reversed proxy, maar ik maakte in dit geval gebruik van IPs om DNS problemen uit te sluiten.

Jij zegt dus dat het beter zou moeten werken met IPVLAN? Heb je daar verder nog tips bij?

Bij de wijziging naar macvlan wijzigen toch ook je ip adressen, en moet je dus je dns wijzigen om eea nog te laten werken?

[Broodje_Aap]

Mars Warrior schreef op maandag 6 februari 2023 @ 18:54:
[...]

Bij de wijziging naar macvlan wijzigen toch ook je ip adressen, en moet je dus je dns wijzigen om eea nog te laten werken?

Nee want mij IP adressen zijn statisch toegekend aan de containers, dus dat zou niet zo mogen zijn.

[Ferrox1]

@Broodje_Aap , draait je reverse proxy op de host? Want dan moet je een brugje slaan tussen je host en je macvlan netwerken. Wellicht dat je die ooit eens gemaakt hebt, maar nu niet meer werkt?

Zie deze blog:
https://blog.oddbit.com/p...-docker-macvlan-networks/

[begintmeta]

Ik ben mijn oude servertje aan het vervangen. Omdat ik een Synology als vervangend apparaat had gekozen (heb hier een beetje spijt van, maar goed ik zal het er wel weer een jaar of tien mee kunnen doen denk ik), kom ik al snel op docker uit om het een en ander te kunnen draaien. Heb inmiddels al wat containers gemaakt, werkt allemaal best simpel. Het enige dat toch wel erg veel aandacht vraagt (m.n. als iemand anders het werk niet al voor je heeft gedaan), is precies nagaan welke locaties persistent storage moeten zijn, dat kan nogal verschillen per software.

[Voor 4% gewijzigd door begintmeta op 12-02-2023 21:26]

[Shadow771]

begintmeta schreef op zondag 12 februari 2023 @ 21:26:
Ik ben mijn oude servertje aan het vervangen. Omdat ik een Synology als vervangend apparaat had gekozen (heb hier een beetje spijt van, maar goed ik zal het er wel weer een jaar of tien mee kunnen doen denk ik), kom ik al snel op docker uit om het een en ander te kunnen draaien. Heb inmiddels al wat containers gemaakt, werkt allemaal best simpel. Het enige dat toch wel erg veel aandacht vraagt (m.n. als iemand anders het werk niet al voor je heeft gedaan), is precies nagaan welke locaties persistent storage moeten zijn, dat kan nogal verschillen per software.

Op een Synology NAS lijkt /volume1/docker me dan toch meestal de beste locatie om de persistent storage van je docker containers op te slaan.

[NaN]

Shadow771 schreef op zondag 12 februari 2023 @ 22:08:
[...]


Op een Synology NAS lijkt /volume1/docker me dan toch meestal de beste locatie om de persistent storage van je docker containers op te slaan.

En dan daar in folders voor je containers, per container.

[Voor 5% gewijzigd door NaN op 13-02-2023 10:03]

[Shadow771]

NaN schreef op maandag 13 februari 2023 @ 10:02:
[...]

En dan daar in folders voor je containers, per container.

Ja idd. thanks voor de verduidelijking .. Zo heb ik bijv:

/volume1/docker/AdGuard1
/volume1/docker/AdGuard2
/volume1/docker/qbittorrent
/volume1/docker/nordvpn1
/volume1/docker/nordvpn2
/volume1/docker/nordvpn3
/volume1/docker/privoxy1
/volume1/docker/privoxy2
/volume1/docker/privoxy3
/volume1/docker/nginx-proxy-manager
/volume1/docker/nextcloud
/volume1/docker/mariadb