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

[thof]

AW_Bos schreef op vrijdag 29 december 2023 @ 23:03:
[...]

Ik heb een server bij Contabo, en ik heb niet het idee dat er een firewall op draait.
Maar zelf intern op de server krijg ik met een CURL-command:

curl: (56) Recv failure: Connection reset by peer

Dus ergens wil Docker niet lekker naar de buitenwereld reageren. En voor zover ik kan zien staat er geen firewall van Ubuntu aan. Maar iemand enig idee hoe ik dit in iptables kan checken? Via iptables -S zie ik een hele lijst met wat regels, dus waar moet ik dan op letten?

Ubuntu gebruik tegenwoordig toch UFW als firewall? Je zou het volgende eens kunnen proberen:

code:

sudo ufw status verbose

Deze zou aan moeten geven of de firewall enabled is en voor welke poorten. Sommige cloud leveranciers hebben ook nog een eigen firewall (Azure, AWS, Hetzener) welke buiten je VM leeft, normaal gesproken in te stellen in een control panel.

Het eerder geplaatste curl command zou je ook eens vanaf localhost op die machine kunnen proberen, mocht je dat nog niet gedaan hebben.

[ Voor 6% gewijzigd door thof op 30-12-2023 00:06 ]

[AW_Bos]

@thof Ik had al eerder van ufw de status gezien dat de firewall disabled was. En verder met Curl op localhost krijg ik ook niks te zien, en enkel een 'reset bij peer'.

Ik kan eens kijken of een simpele webserver in Docker werkt? Misschien dat er wat mis is in GoTrain? De data lijk ik ook niet binnen te krijgen, of dat wordt niet gelogd, maar dat is voor later een zaak. Maar misschien is poort 8080 wel bezet door iets anders, al zou ik niet weten wat. Maar dat is ook iets om uit te zoeken.

Maar mocht iemand nog verdere tips hebben....

[ Voor 54% gewijzigd door AW_Bos op 30-12-2023 00:20 ]

[thof]

Je kan nog kijken of een andere container op die host port 8080 gebruikt, door de kolom 'ports' te checken bij het uitvoeren van

code:

docker ps

Of via een van deze commando's te kijken of er een ander proces port 8080 heeft geclaimed.

In ieder geval klinkt het draaien van een simpele webserver (nginx) en die mappen naar port 8080 een prima test om te doen.

[AW_Bos]

Dat ga ik komende dagen eens proberen! Wordt vervolgd!

[lolgast]

thof schreef op zaterdag 30 december 2023 @ 00:25:
Je kan nog kijken of een andere container op die host port 8080 gebruikt, door de kolom 'ports' te checken bij het uitvoeren van

code:

docker ps

Of via een van deze commando's te kijken of er een ander proces port 8080 heeft geclaimed.

In ieder geval klinkt het draaien van een simpele webserver (nginx) en die mappen naar port 8080 een prima test om te doen.

In dat geval zou het starten van de nieuwe container een foutmelding moeten geven met in mijn ogen zeer duidelijke feedback welke poort al in gebruik is Zie:

[ Voor 6% gewijzigd door lolgast op 30-12-2023 19:50 ]

[AW_Bos]

AW_Bos schreef op zaterdag 30 december 2023 @ 00:18:
@thof Ik had al eerder van ufw de status gezien dat de firewall disabled was. En verder met Curl op localhost krijg ik ook niks te zien, en enkel een 'reset bij peer'.

Ik kan eens kijken of een simpele webserver in Docker werkt? Misschien dat er wat mis is in GoTrain? De data lijk ik ook niet binnen te krijgen, of dat wordt niet gelogd, maar dat is voor later een zaak. Maar misschien is poort 8080 wel bezet door iets anders, al zou ik niet weten wat. Maar dat is ook iets om uit te zoeken.

Maar mocht iemand nog verdere tips hebben....

Het is getackled hoor, en ik wou dat even laten weten.....

netstat -an gaf aan dat de poort gewoon geopend was, Ook andere applicaties in docker-containers draaien prima. En dan doet je iets te denken zetten dat die poort niet gebind werd door GoTrain.

Blijkbaar werd de config.yaml niet ingeladen, maar de benodigde parameters (waaronder poort 8080) heb ik via een reeks -e environment parameters in kunnen laden bij de docker run.

Waarom de config.yaml genegeerd wordt is mij een raadsel, en dat mag de bouwer even uitzoeken. Maar ik ben blij dat het zo in ieder geval werkt.

[Wachten...]

Ik had even een vraag over rechten op een Synology i.c.m. docker.

Ik heb hier een nieuwe photo management docker container daaien om uit te proberen (immich), Alles werkt verder prima met het uploaden van bestanden etc, echter wil ik nu laten verwijzen naar de standaard photo folder van Synology. Dit kan ook aan de hand van deze uitleg. Echter als ik dit doe, dan krijg ik een permission denied in de log van immich naar die externe map.

Mijn vraag is nu hoe dit normaal werkt, en wat hierin aan te raden is. Zou ik een nieuwe Synology gebruiker aan moeten maken om die rechter te geven? Want uiteraard hoeven alle andere docker containers niet bij die map te kunnen. Dit geldt enkel voor immich.

Ik ben benieuwd hoe je dit normaal gesproken zou doen in docker.

[Webgnome]

Je zou, als je van basis docker uit gaat, inderdaad een speciale user aan maken die je toevoeg aan de docker groep dan kan ie in docker en ook de dingen die hij zelf mag. Volgens mij..

[Wachten...]

Webgnome schreef op vrijdag 1 maart 2024 @ 09:08:
Je zou, als je van basis docker uit gaat, inderdaad een speciale user aan maken die je toevoeg aan de docker groep dan kan ie in docker en ook de dingen die hij zelf mag. Volgens mij..

Ja ik heb dat gedaan, maar het lijkt alsof de rechten niks doen vanuit Synology

Ik heb dus die gebruiker en die UID en GUID heb ik gebruikt in de docker compose.
Ik heb nu verwezen naar een externe map in de docker, waarvan ik weet dat iedereen er toegang tot heeft.
Dit werkt dan ook, want dan kan ik immich gewoon starten en ziet hij de externe link.

Echter als ik nu die user (in synology) de rechten ontneem van die map, en immich herstart. dan krijg ik geen foutmelding. Oftewel die gebruiker kan nog steeds in die map komen.

Het is echt heel erg gek, maar ik snap er niks van waarom de rechten vanuit synology niet goed worden overgenomen.

@Webgnome Ik heb nu bijvoorbeeld voor alles gebruikers voor die shared folder de rechten ontnomen, en nog steeds kan immich verbinden en krijg ik geen foutmelding o.i.d.
Ik gebruik de standaard groep 100 (users)

[ Voor 10% gewijzigd door Wachten... op 01-03-2024 11:30 ]

[alex3305]

@Wachten... Aan de hand van jouw uitleg weten we niet met welke gebruiker de Immich container(s) gestart zijn. Het is dus een beetje koffiedik kijken hoe dit nu in elkaar zit bij jou. Maar hiermee doe je denk ik een verkeerde aanname:

Want uiteraard hoeven alle andere docker containers niet bij die map te kunnen. Dit geldt enkel voor immich.

Andere containers kunnen niet zomaar bij de (laten we zeggen) foto map. Die mapping moet je namelijk expliciet maken met een bind mount of volume mapping. Als je een dergelijke mapping niet maakt, kunnen (andere) containers er niet bij. Dat is ook direct de kracht van containers .

Ik snap jouw vraag overigens wel hoor . Ik weet niet of Synology Moments/Photos als alternatieve gebruiker kan draaien, maar ik ben een beetje bang voor dat dat niet zomaar gaat. Als dat wel gaat zou je die gebruiker kunnen gebruiken om ook de container te starten. Dan heb je beide dezelfde permissies.

Ik ben benieuwd hoe je dit normaal gesproken zou doen in docker.

Ik draai alles in containers en heb daar dus (denk ik) wat meer beheer over. Normaal draai ik mijn containers als niet root user. Zo ook Immich. Echter heb ik een aantal uitzonderingen. Met mijn backup container gebruik ik wel de root user. Omdat ik zeker wil weten dat die overal bij komt.

Wachten... schreef op vrijdag 1 maart 2024 @ 11:23:
Echter als ik nu die user (in synology) de rechten ontneem van die map, en immich herstart. dan krijg ik geen foutmelding. Oftewel die gebruiker kan nog steeds in die map komen.

Zou het niet zo kunnen zijn dat de permissies te breed staan, waardoor je dus altijd leesrechten hebt bijvoorbeeld?

Persoonlijk zou ik mij hier niet per se initieel super druk over maken. Maar eerst even lekker een setupje maken die werkt. Rechten en permissies kun je later altijd nog rechtzetten . En daarnaast expliciet en bewust met al je mappings omgaan.

[Wachten...]

@alex3305

Dank voor je heldere uitleg, en ook over de mappings.
Dus jij zegt eigenlijk dat je nooit een aparte gebruiker aan hoeft te maken voor docker?
Oftewel je kunt je admin account UID en GUID gebruiken voor alle containers, aangezien je toch bepaalde mappings aanmaakt en het hierdoor niet bij de rest kan?

Echter blijf ik dan met het probleem zitten. Want voor de duidelijkheid. Ik kan immich gewoon runnen, en ik kan ook naar een externe folder verwijzen. Dit werkt prima. Echter werkt dit niet voor de "photo" folder in Synology. Ik heb in Synology Photos ook de rechten gegeven aan deze gebruiker.

Zelfs als ik mijn admin UID gebruik, dan krijg ik een foutmelding van permission denied. Alle andere folders kan ik wel gewoon toewijzen, dan werkt immich direct.

En even voor de duidelijkheid. in de standaard "users" group in Synology heb ik alles uit staan. Ik bepaal de rechten namelijk met eigen groepen. Als ik dan voor deze specifieke gebruiker de rechten geef tot de Synology photo folder, dan krijg ik gewoon een foutmelding bij het opstarten van de container van immich. Zodra ik naar een andere algemene shared folder verwijs, dan werkt hij direct.

Naar mijn inziens heeft het dus echt specifiek met die default "photo" folder te maken, en precies die folder moet ik gebruiken, want daar staan al mijn foto`s

[Wachten...]

@alex3305 @Webgnome

Ik heb nu bijvoorbeeld de compose aangepast naar de UID van de administrator, en de GUID ook (dus van 100 naar 101). Dit zou inhouden dat deze compose overal rechten tot heeft. Echter kan de container nog steeds niet opstarten vanwege een permission denied.

Ik krijg de onderstaande foutmelding

code:

Error: EACCES: permission denied, watch '/usr/src/app/external/@eaDir/SYNO@.fileindexdb'

[alex3305]

Wachten... schreef op vrijdag 1 maart 2024 @ 11:41:
Dus jij zegt eigenlijk dat je nooit een aparte gebruiker aan hoeft te maken voor docker?
Oftewel je kunt je admin account UID en GUID gebruiken voor alle containers, aangezien je toch bepaalde mappings aanmaakt en het hierdoor niet bij de rest kan?

Heel kort door de bocht, ja dat klopt. Echter zijn er in het verleden security issues geweest waardoor je, omdat je al root was in de container, makkelijker uit de container kon breken. Vandaar dat het gebruiken van een root (of admin) gebruiker wordt afgeraden. Maar wat mij betreft moet je dit ook even in context plaatsen. Als je hiermee bezig bent is het prima om dit soort fouten of 'gevaarlijke' configuraties toe te passen. Je bent immers nog aan het leren. Ik kan je in ieder geval zeggen dat tot afgelopen jaar bij mij de permissies gewoon een bende was en zoveel mogelijk als root gebruiker draaide. Dat heeft bij mij niet tot problemen geleid.

Wachten... schreef op vrijdag 1 maart 2024 @ 11:51:
@alex3305 @Webgnome

Ik heb nu bijvoorbeeld de compose aangepast naar de UID van de administrator, en de GUID ook (dus van 100 naar 101). Dit zou inhouden dat deze compose overal rechten tot heeft. Echter kan de container nog steeds niet opstarten vanwege een permission denied.

Ik krijg de onderstaande foutmelding

code:

Error: EACCES: permission denied, watch '/usr/src/app/external/@eaDir/SYNO@.fileindexdb'

Ik ken de ins en outs niet van Docker op Synology, maar ik lees nu al dat dat toch al wat anders is . Maar volgens deze reddit post moet je sowieso de @eaDir directory uitsluiten.

Ik weet niet hoe jouw Compose file eruit ziet, maar volgens mij zou Immich wel op moeten kunnen starten zonder toegang tot die directory. Maar volgens mij moet je die niet mappen naar /usr/src/app...

[Wachten...]

alex3305 schreef op vrijdag 1 maart 2024 @ 12:00:
[...]

Heel kort door de bocht, ja dat klopt. Echter zijn er in het verleden security issues geweest waardoor je, omdat je al root was in de container, makkelijker uit de container kon breken. Vandaar dat het gebruiken van een root (of admin) gebruiker wordt afgeraden. Maar wat mij betreft moet je dit ook even in context plaatsen. Als je hiermee bezig bent is het prima om dit soort fouten of 'gevaarlijke' configuraties toe te passen. Je bent immers nog aan het leren. Ik kan je in ieder geval zeggen dat tot afgelopen jaar bij mij de permissies gewoon een bende was en zoveel mogelijk als root gebruiker draaide. Dat heeft bij mij niet tot problemen geleid.


[...]

Ik ken de ins en outs niet van Docker op Synology, maar ik lees nu al dat dat toch al wat anders is . Maar volgens deze reddit post moet je sowieso de @eaDir directory uitsluiten.

Ik weet niet hoe jouw Compose file eruit ziet, maar volgens mij zou Immich wel op moeten kunnen starten zonder toegang tot die directory. Maar volgens mij moet je die niet mappen naar /usr/src/app...

toon volledige bericht

Ik heb onderstaande toegevoegd aan de: immich-server: en de immich-microservices:, zoals omschreven in de documentatie.

code:

- ${EXTERNAL_PATH}/photo:/usr/src/app/external

Ik weet dat dit werkt, want als ik de /photo verander naar de /test, (een test folder die ik heb aangemaakt), dan werkt alles direct. Ik heb het dus enkel met de /photo map.

Dat stuk over @eaDir zou het wel eens kunnen zijn, echter hoe sluit ik dat uit in de compose, want dat kan ik nergens vinden. Ik kan dan testen of het werkt.

Echter zoals jij ook al aangeeft, is het ergens gek dat immich uberhaupt niet wilt starten met deze foutmelding.

[Airw0lf]

Voor een training zoek ik een manier om binnen een VPS 10 Docker containers met een Debian CLI op te starten. Binnen elke container worden vervolgens via de CLI apps geïnstalleerd en uitgevoerd. Deze apps hebben een CLI of web interface.

Wat is een handige marsroute voor zoiets?
Ook al omdat je voor 10 containers een ssh poort nodig hebt.
En een of meer poorten voor een webUI.

[RobertMe]

Airw0lf schreef op dinsdag 9 april 2024 @ 14:39:
Voor een training zoek ik een manier om binnen een VPS 10 Docker containers met een Debian CLI op te starten. Binnen elke container worden vervolgens via de CLI apps geïnstalleerd en uitgevoerd. Deze apps hebben een CLI of web interface.

Wat is een handige marsroute voor zoiets?
Ook al omdat je voor 10 containers een ssh poort nodig hebt.
En een of meer poorten voor een webUI.

Ik vind dit meer klinken alsof je op zoek bent om 10 LXC containers te starten? Daarin kun je echt een volwaardig OS draaien met zoveel services etc als je maar wilt. Want SSH in Docker draaien voelt gewoon al raar.

En LXC containers zijn diep onder water hetzelfde als Docker containers. Als in: ze gebruiken beiden dezelfde kernel technieken om de isolatie te bewerkstelligen. Alleen is de uitwerking/implementatie anders en daardoor ook de toepassing. LXC is een alternatief voor VMs, Docker is een manier om een (/één) applicatie onafhankelijk van distro (versie) eenvoudig te kunnen draaien op meerdere systemen.
En naar mijn interpretatie ben jij op zoek naar "10 VMs", dus LXC, en niet Docker.

[alex3305]

@Airw0lf Niet . Maar dat is natuurlijk geen antwoord...

Volgens mij kan dat prima met zoiets:

docker run -d --name ssh-0 -e SUDO_ACCESS=true PASSWORD_ACCESS=true USER_PASSWORD=blabla USER_NAME=user -p 2220:2222 -p 8000-8009:8000-8009 lscr.io/linuxserver/openssh-server:latest

docker run -d --name ssh-1 -e SUDO_ACCESS=true PASSWORD_ACCESS=true USER_PASSWORD=blabla USER_NAME=user -p 2221:2222 -p 8010-8019:8010-8019 lscr.io/linuxserver/openssh-server:latest
...
docker run -d --name ssh-9 -e SUDO_ACCESS=true PASSWORD_ACCESS=true USER_PASSWORD=blabla USER_NAME=user -p 2229:2222 -p 8090-8099:8090-8099 lscr.io/linuxserver/openssh-server:latest

Verder eens met @RobertMe.

[Airw0lf]

Bedankt voor de reacties.

Ik ben nog aan het twijfelen tussen een LXC die per deelnemer alles klaar heeft staan. Versus twee of meer Docker containers met per container een of meer apps/services.

Ander dingetje is dat het scripten van Docker containers bekende materie is. Het scripten van LXC containers is voor mij greenfield - ook al omdat er eigenlijk nauwelijks voorbeelden van te vinden zijn.

Bij elkaar bracht me dat naar de aanvliegroute over de as van Docker containers. Met het idee desnoods een Docker container per app/service.

[Mars Warrior]

@Airw0lf Ik draai meerdere complete ISP omgevingen in een docker container, dus ik zie geen enkel probleem.

Je kunt per container ook een IP adres opgeven, dan heb je ook geen portmapping enzo meer nodig. Kun je voor elke container exact dezelfde poorten gebruiken.

Ik ben de afgelopen 7 jaren (sinds ik Docker gebruik dus) nog geen enkele use-case tegengekomen voor LXC.

Door gebruik te maken van AdGuard om subdomeinen te definieren en Caddy + plugin voor web toegang wordt alles helemaal simpel tijdens het gebruik.

Toevoeging:
In de meeste containers draaien gewoon (volgens Portainer) 1-5 processen, maar ik heb er dus ook containers met meer dan 50 processen. De grote containers draaien op Alma Linux 8, terwijl mijn server op Ubuntu 22.04 LTS draait.

Container is wel zelf gemaakt:

YAML:

# Use Alma 8 with init system...
FROM almalinux:8
RUN dnf -y upgrade
RUN dnf makecache --refresh
RUN dnf -y install epel-release

# <<installatie andere software>>

# Clean image from dnf updates & cache
RUN dnf autoremove -y
RUN dnf clean all

# Expose Ports for the Application
EXPOSE 22 80 443 888 3306 7800

Zoals je ziet gewoon poorten 22, 80/443 etc. geexposed omdat deze containers een eigen IP hebben.

Mocht je overigens systemd/init nodig hebben, dan zul je denk ik toch moeten terugvallen op LXC, want dat werkt niet meer lekker met Docker. Er zijn Python scripts geloof ik die dat weer volledig emuleren binnen Docker, maar die heb ik ook nog nooit nodig gehad

[ Voor 48% gewijzigd door Mars Warrior op 09-04-2024 18:23 ]

[browser666]

Ik heb een raspberry pi 5 draaien met daarin een docker container met Photoprism. Ik wil graag mijn filmpjes hardwarematig laten renderen door Photoprism, maar het lukt mij niet om dit in te stellen. Toegevoegd mijn compose file. Is er iemand die advies heeft?

code:

version: '3.5'

# Note:
# - Running PhotoPrism on a server with less than 4 GB of swap space or setting a memory/swap limit can cause unexpected
#   restarts ("crashes"), especially when the indexer temporarily needs more memory to process large files.
# - If you install PhotoPrism on a public server outside your home network, please always run it behind a secure
#   HTTPS reverse proxy such as Traefik, Caddy, or NGINX. Your files and passwords will otherwise be transmitted
#   in clear text and can be intercepted by anyone, including your provider, hackers, and governments.
#
# Documentation : https://docs.photoprism.org/getting-started/docker-compose/
# Docker Hub URL: https://hub.docker.com/r/photoprism/photoprism/
#
# DOCKER COMPOSE COMMAND REFERENCE
# see https://docs.photoprism.org/getting-started/docker-compose/#command-line-interface
# --------------------------------------------------------------------------
# Help     | docker-compose exec photoprism photoprism help
# Config   | docker-compose exec photoprism photoprism config
# Reset    | docker-compose exec photoprism photoprism reset
# Backup   | docker-compose exec photoprism photoprism backup -a -i
# Restore  | docker-compose exec photoprism photoprism restore -a -i
# Index    | docker-compose exec photoprism photoprism index
# Reindex  | docker-compose exec photoprism photoprism index -f
# Import   | docker-compose exec photoprism photoprism import
#
# To search originals for faces without a complete rescan:
# docker-compose exec photoprism photoprism faces index
#
# All commands may have to be prefixed with "sudo" when not running as root.
# This will point the home directory placeholder ~ to /root in volume mounts.

services:
  ## App Server (required)
  photoprism:
    ## Use photoprism/photoprism:preview for testing preview builds:
    image: photoprism/photoprism:latest
    depends_on:
      - mariadb
    ## Only enable automatic restarts once your installation is properly
    ## configured as it otherwise may get stuck in a restart loop,
    ## see https://docs.photoprism.org/getting-started/faq/#why-is-photoprism-getting-stuck-in-a-restart-loop
    container_name: photoprism
    restart: unless-stopped
    security_opt:
      - seccomp:unconfined
      - apparmor:unconfined
    ## Run as a specific, non-root user (see https://docs.docker.com/engine/reference/run/#user):
    user: "1000:1000"
    ports:
      - "2342:2342" # HTTP port (host:container)
    environment:
      PHOTOPRISM_ADMIN_PASSWORD: "${PHOTOPRISM_ADMIN_PASSWORD}"          # PLEASE CHANGE: Your initial admin password (min 4 characters)
      PHOTOPRISM_SITE_URL: "${PHOTOPRISM_SITE_URL}"  # Public server URL incl http:// or https:// and /path, :port is optional
      PHOTOPRISM_ORIGINALS_LIMIT: 5000               # File size limit for originals in MB (increase for high-res video)
      PHOTOPRISM_HTTP_COMPRESSION: "gzip"            # Improves transfer speed and bandwidth utilization (none or gzip)
      PHOTOPRISM_DEBUG: "false"                      # Run in debug mode (shows additional log messages)
      PHOTOPRISM_PUBLIC: "${PHOTOPRISM_PUBLIC:-false}" # No authentication required (disables password protection)
      PHOTOPRISM_READONLY: "${PHOTOPRISM_READONLY:-false}"   # Don't modify originals directory (reduced functionality)
      PHOTOPRISM_EXPERIMENTAL: "false"               # Enables experimental features
      PHOTOPRISM_DISABLE_CHOWN: "false"              # Disables storage permission updates on startup
      PHOTOPRISM_DISABLE_WEBDAV: "false"             # Disables built-in WebDAV server
      PHOTOPRISM_DISABLE_SETTINGS: "false"           # Disables Settings in Web UI
      PHOTOPRISM_DISABLE_TENSORFLOW: "false"         # Disables all features depending on TensorFlow
      PHOTOPRISM_DISABLE_FACES: "${PHOTOPRISM_DISABLE_FACES:-false}"  # Disables facial recognition
      PHOTOPRISM_DISABLE_CLASSIFICATION: "false"     # Disables image classification
      PHOTOPRISM_DARKTABLE_PRESETS: "true"          # Enables Darktable presets and disables concurrent RAW conversion
      PHOTOPRISM_DETECT_NSFW: "false"                # Flag photos as private that MAY be offensive (requires TensorFlow)
      PHOTOPRISM_UPLOAD_NSFW: "true"                 # Allow uploads that MAY be offensive
      # PHOTOPRISM_DATABASE_DRIVER: "sqlite"         # SQLite is an embedded database that doesn't require a server
      PHOTOPRISM_DATABASE_DRIVER: "mysql"            # Use MariaDB 10.5+ or MySQL 8+ instead of SQLite for improved performance
      PHOTOPRISM_DATABASE_SERVER: "mariadb:3306"     # MariaDB or MySQL database server (hostname:port)
      PHOTOPRISM_DATABASE_NAME: "photoprism"         # MariaDB or MySQL database schema name
      PHOTOPRISM_DATABASE_USER: "photoprism"         # MariaDB or MySQL database user name
      PHOTOPRISM_DATABASE_PASSWORD: "${MYSQL_PASSWORD}" # MariaDB or MySQL database user password
      PHOTOPRISM_SITE_TITLE: "test"
      PHOTOPRISM_SITE_CAPTION: "In vogelvlucht"
      PHOTOPRISM_SITE_DESCRIPTION: ""
      PHOTOPRISM_SITE_AUTHOR: ""
      PHOTOPRISM_THUMB_FILTER: "lanczos"      # resample filter, best to worst: blackman, lanczos, cubic, linear
      PHOTOPRISM_THUMB_UNCACHED: "true"       # enables on-demand thumbnail rendering (high memory and cpu usage)
      PHOTOPRISM_THUMB_SIZE: 2048             # pre-rendered thumbnail size limit (default 2048, min 720, max 7680)
      PHOTOPRISM_THUMB_SIZE_UNCACHED: 7680    # on-demand rendering size limit (default 7680, min 720, max 7680)
      ## Set a non-root user, group, or custom umask if your Docker environment doesn't support this natively:
      # PHOTOPRISM_UID: 1000
      # PHOTOPRISM_GID: 1000
      # PHOTOPRISM_UMASK: 0000
      ## Enable TensorFlow AVX2 support for modern Intel CPUs (requires starting the container as root):
      # PHOTOPRISM_INIT: "tensorflow-amd64-avx2"
      ## Hardware video transcoding config (optional):
      PHOTOPRISM_FFMPEG_BUFFERS: "64"              # FFmpeg capture buffers (default: 32)
      PHOTOPRISM_FFMPEG_BITRATE: "50"              # FFmpeg encoding bitrate limit in Mbit/s (default: 50)
      # PHOTOPRISM_FFMPEG_ENCODER: "h264_v4l2m2m"    # Use Video4Linux for AVC transcoding (default: libx264)
      # PHOTOPRISM_FFMPEG_ENCODER: "h264_qsv"        # Use Intel Quick Sync Video for AVC transcoding (default: libx264)
      # PHOTOPRISM_INIT: "intel-graphics tensorflow-amd64-avx2" # Enable TensorFlow AVX2 & Intel Graphics support
      PHOTOPRISM_FFMPEG_ENCODER: "libx264"
      PHOTOPRISM_FFMPEG_SIZE: "3840"
      PHOTOPRISM_DARKTABLE_BIN: "darktable-cli"
      PHOTOPRISM_RESOLUTION_LIMIT: "150"
      
      # PHOTOPRISM_FFMPEG_ENCODER: "raspberry"
      HOME: "/photoprism"
    ## Hardware devices for video transcoding and machine learning (optional):
    # devices:
    #  - "/dev/video11:/dev/video11" # Video4Linux (h264_v4l2m2m)
    #  - "/dev/dri/renderD128:/dev/dri/renderD128" # Intel GPU
    #  - "/dev/dri/card0:/dev/dri/card0"
    working_dir: "/photoprism"
    volumes:
      ## The *originals* folder contains your original photo and video files (- "[host folder]:/photoprism/originals"):
      ## - "${HOST_MEDIA_PATH}:/photoprism/originals"
      - "/srv/remotemount/photo/PhotoLibrary/:/photoprism/originals"
      ## Multiple folders can be made accessible by mounting them as subfolders of /photoprism/originals:
      ## - "/srv/remotemount/photo/PhotoLibrary/:/photoprism/originals/Drone"    # [folder 1]:/photoprism/originals/[folder 1]
      # - "/mnt/Friends:/photoprism/originals/Friends"  # [folder 2]:/photoprism/originals/[folder 2]
      ## You may mount an *import* folder from which files can be transferred to *originals* (optional):
      - "${HOST_MEDIA_PATH}/import:/photoprism/import"
      ## Cache, session, thumbnail, and sidecar files will be created in the *storage* folder (never remove):
      ## - "/portainer/Files/AppData/Config/PhotoPrism/storage:/photoprism/storage"
      - "${HOST_MEDIA_PATH}/storage:/photoprism/storage"


  ## Database Server (recommended)
  ## see https://docs.photoprism.org/getting-started/faq/#should-i-use-sqlite-mariadb-or-mysql
  mariadb:
    restart: unless-stopped
    image: mariadb:10.6
    security_opt:
      - seccomp:unconfined
      - apparmor:unconfined
    command: mysqld --transaction-isolation=READ-COMMITTED --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --max-connections=512 --innodb-rollback-on-timeout=OFF --innodb-lock-wait-timeout=120
    volumes:
      - "/portainer/Files/AppData/Config/PhotoPrism/database:/var/lib/mysql" # never remove
    environment:
      MYSQL_ROOT_PASSWORD: "${MYSQL_ROOT_PASSWORD}"
      MYSQL_DATABASE: photoprism
      MYSQL_USER: photoprism
      MYSQL_PASSWORD: "${MYSQL_PASSWORD}"

  ## Watchtower upgrades services automatically (optional)
  ## see https://docs.photoprism.org/getting-started/updates/#watchtower
  #
  # watchtower:
  #   restart: unless-stopped
  #   image: containrrr/watchtower
  #   environment:
  #     WATCHTOWER_CLEANUP: "true"
  #     WATCHTOWER_POLL_INTERVAL: 7200 # checks for updates every two hours
  #   volumes:
  #     - "/var/run/docker.sock:/var/run/docker.sock"
  #     - "~/.docker/config.json:/config.json" # Optional, for authentication if you have a Docker Hub account

[RobertMe]

browser666 schreef op zaterdag 20 april 2024 @ 17:49:
Ik heb een raspberry pi 5 draaien met daarin een docker container met Photoprism. Ik wil graag mijn filmpjes hardwarematig laten renderen door Photoprism, maar het lukt mij niet om dit in te stellen. Toegevoegd mijn compose file. Is er iemand die advies heeft?

1. Plaats de code in [code] tags, want dit is onleesbaar
2. De Photoprism docs? https://docs.photoprism.a...transcoding/#raspberry-pi

[browser666]

De handleiding zegt hier weinig over. Niet genoeg in ieder geval om het op te lossen.

RobertMe schreef op zaterdag 20 april 2024 @ 17:57:
[...]

1. Plaats de code in [code] tags, want dit is onleesbaar
2. De Photoprism docs? https://docs.photoprism.a...transcoding/#raspberry-pi

[RobertMe]

browser666 schreef op zaterdag 20 april 2024 @ 18:20:
De handleiding zegt hier weinig over. Niet genoeg in ieder geval om het op te lossen.


[...]

Sorry, maar de eerste 2 items die in de link genoemd staan (m.b.t. ffmpeg encoder & devices stuk) staan zelfs letterlijk in de docker-compose.yaml die je zelf post

spoiler:

Het enige dat je dus hoeft te doen is ze te uncommenten, dus de # aan het begin van de regel weghalen.

[ElCondor]

Hello, ik heb even een duw in de juiste richting nodig. Ik post het even in dit topic omdat ik vermoed dat de oplossing meer in docker zelf dan in Traefik in te stellen moet zijn.

Traefik kan volgens de documentatie luisteren op meerdere IP's als entrypoint en raadt aan om, als je meerdere TCP routers wilt gebruiken, deze dan elk op een eigen port of IP te zetten.

Nu heb ik mijn docker host meerdere IP's gegeven inmiddels, maar ik weet niet precies hoe ik deze IP's dan doormap naar de container van Traefik zelf.
Sterker, is dit inderdaad de manier om dit te doen? Traefik kun je ook als stand-alone binary draaien en dan ziet hij uiteraard alle IP adressen beschikbaar op het systeem.
Nu map je door middel van de docker-compose in principe ports en als nodig ook IP adressen door, maar hoe dan verder? De container zelf is aangesloten op één bridge network en heeft derhalve op dat netwerk één ip adres.
Moet ik de traefik container dan in meerdere networks plaatsen en dan op die manier IP adressen doormappen of kan een enkele container op één docker /portainer network ook meerdere IP adressen hebben? En hoe stel ik dat dan persistent in de container in? Ik ben nog wat nieuw op het gebied van docker, dus vandaar dat ik nog wat zoekende ben naar hoe bepaalde concepten werken.
Ik zat bijvoorbeeld ook al te denken om gewoon een tweede container in de lucht te trekken en op zijn eigen network aan te sluiten, maar hoe map ik dan de specifieke network adressen naar die specifieke docker/portainer networks?

Ik ben al wat wezen grasduinen in de verschillende documentaties, maar die van Traefik is erg rudimentair en met de documentatie van docker vind ik vooral hoe je dit inricht met de docker executable zelf en niet met een docker-compose file. Aangezien ik portainer gebruik wil heel specifiek van docker-compose files gebruik maken omdat dit het werk vanuit portainer weer vereenvoudigd.

[Airw0lf]

ElCondor schreef op dinsdag 30 april 2024 @ 09:27:
Hello, ik heb even een duw in de juiste richting nodig. Ik post het even in dit topic omdat ik vermoed dat de oplossing meer in docker zelf dan in Traefik in te stellen moet zijn.

Traefik kan volgens de documentatie luisteren op meerdere IP's als entrypoint en raadt aan om, als je meerdere TCP routers wilt gebruiken, deze dan elk op een eigen port of IP te zetten.

Nu heb ik mijn docker host meerdere IP's gegeven inmiddels, maar ik weet niet precies hoe ik deze IP's dan doormap naar de container van Traefik zelf.
Sterker, is dit inderdaad de manier om dit te doen? Traefik kun je ook als stand-alone binary draaien en dan ziet hij uiteraard alle IP adressen beschikbaar op het systeem.
Nu map je door middel van de docker-compose in principe ports en als nodig ook IP adressen door, maar hoe dan verder? De container zelf is aangesloten op één bridge network en heeft derhalve op dat netwerk één ip adres.
Moet ik de traefik container dan in meerdere networks plaatsen en dan op die manier IP adressen doormappen of kan een enkele container op één docker /portainer network ook meerdere IP adressen hebben? En hoe stel ik dat dan persistent in de container in? Ik ben nog wat nieuw op het gebied van docker, dus vandaar dat ik nog wat zoekende ben naar hoe bepaalde concepten werken.
Ik zat bijvoorbeeld ook al te denken om gewoon een tweede container in de lucht te trekken en op zijn eigen network aan te sluiten, maar hoe map ik dan de specifieke network adressen naar die specifieke docker/portainer networks?

Ik ben al wat wezen grasduinen in de verschillende documentaties, maar die van Traefik is erg rudimentair en met de documentatie van docker vind ik vooral hoe je dit inricht met de docker executable zelf en niet met een docker-compose file. Aangezien ik portainer gebruik wil heel specifiek van docker-compose files gebruik maken omdat dit het werk vanuit portainer weer vereenvoudigd.

toon volledige bericht

En als je die Docker container koppelt aan het host netwerk?
Waardoor die zich ook aan alle interfaces kan koppelen?

Ik ben enigszins woordblind => misschien eens een tekening/schema posten van wat je zou willen bereiken?

[ElCondor]

Airw0lf schreef op dinsdag 30 april 2024 @ 10:12:
[...]


En als je die Docker container koppelt aan het host netwerk?
Waardoor die zich ook aan alle interfaces kan koppelen?

Ik ben enigszins woordblind => misschien eens een tekening/schema posten?

Hmmm, kijk daar komt mijn onkunde wat betreft docker en docker networking om de hoek piepen.
Ik vermoed zo maar eens dat het nu net de bedoeling is om ziets als Traefik direct aan het host network te koppelen. Ik ken echter alleen maar de bridge network instelling in portainer. Hoe stel ik daar dan in dat het host network gebruikt moet worden?

-UPDATE- Zie nu een 'host' network in portainer... Die moet ik hebben dan, neem ik aan?

Kiek, dat had ik nodig. Daar ga ik maar eens mee klooien dan, dat scheelt een hele hoop geconfigueer.

[Airw0lf]

ElCondor schreef op dinsdag 30 april 2024 @ 10:27:
[...]

-UPDATE- Zie nu een 'host' network in portainer... Die moet ik hebben dan, neem ik aan?

Kiek, dat had ik nodig. Daar ga ik maar eens mee klooien dan, dat scheelt een hele hoop geconfigueer.

Inderdaad - die moet je hebben.

Veel plezier met het verdere "geklooi".

[ElCondor]

Airw0lf schreef op dinsdag 30 april 2024 @ 10:30:
[...]


Inderdaad - die moet je hebben.

Veel plezier met het verdere "geklooi".

[DjoeC]

Ondanks de zoekfunctie blijf ik met een vraag zitten en als niet heel erg Docker kundig kom ik ook nog niet veel verder met dat wat het www mij terug geeft.....

Ik gebruik een Raspi 4 met daarop OMV 7 en Docker. Ik ben bezig om al mijn containers van andere Pi's op deze nieuwe opstelling neer te zetten door middel van Docker Compose files.

Op zich werkt dat uitstekend - behalve bij een reboot of een update van de container service waardoor alle containers geherstart moeten worden. Diverse containers falen dan omdat (bijvoorbeeld) de Mariadb of Mosquitto containers die in veel van de andere containers gebruikt worden nog niet (volledig) opgestart zijn.

Ik kom in Docker een dependency optie tegen maar die lijkt alleen maar effect te hebben zolang de containers in dezelfde compose file zijn gedefinieerd. Ik zou dan dus ALLE containers in 1 compose file moeten opnemen? Dat lijkt me niet de bedoeling.... Wat zijn mijn opties? Of moet ik me naast (of: in plaats van) Docker ook in Kubernetes oid gaan verdiepen? Hoe kom ik zo begrijpelijk en onderhoudbaar mogelijk aan definities voor containers waarin dependencies verwerkt zijn, die rekening houden met het al dan niet actief zijn van de container op het moment van de herstart (docker herstart alleen containers die actief waren op het moment van herstart) en niet alvast beginnen te draaien voordat de database en MQTT containers ook echt beschikbaar zijn?

[Freee!!]

DjoeC schreef op dinsdag 14 mei 2024 @ 11:09:
Ondanks de zoekfunctie blijf ik met een vraag zitten en als niet heel erg Docker kundig kom ik ook nog niet veel verder met dat wat het www mij terug geeft.....

Ik gebruik een Raspi 4 met daarop OMV 7 en Docker. Ik ben bezig om al mijn containers van andere Pi's op deze nieuwe opstelling neer te zetten door middel van Docker Compose files.

Op zich werkt dat uitstekend - behalve bij een reboot of een update van de container service waardoor alle containers geherstart moeten worden. Diverse containers falen dan omdat (bijvoorbeeld) de Mariadb of Mosquitto containers die in veel van de andere containers gebruikt worden nog niet (volledig) opgestart zijn.

Ik kom in Docker een dependency optie tegen maar die lijkt alleen maar effect te hebben zolang de containers in dezelfde compose file zijn gedefinieerd. Ik zou dan dus ALLE containers in 1 compose file moeten opnemen? Dat lijkt me niet de bedoeling.... Wat zijn mijn opties? Of moet ik me naast (of: in plaats van) Docker ook in Kubernetes oid gaan verdiepen? Hoe kom ik zo begrijpelijk en onderhoudbaar mogelijk aan definities voor containers waarin dependencies verwerkt zijn, die rekening houden met het al dan niet actief zijn van de container op het moment van de herstart (docker herstart alleen containers die actief waren op het moment van herstart) en niet alvast beginnen te draaien voordat de database en MQTT containers ook echt beschikbaar zijn?

toon volledige bericht

Ik begrijp je probleem en vraagstelling en ik ben blij dat probleem niet te hebben. Ik zal eens kijken of ik wat voor je kan vinden.

[Hathi]

Je hoeft niet per se alle containers in één compose file te plaatsen, maar wel alle containers die enige relatie/afhankelijkheid met elkaar hebben. Dat maakt het naar mijn idee ook wel zo overzichtelijk. Ik heb al mijn containers met betrekking tot mijn smarthome bijvoorbeeld in één compose file staan. Home Assistant, Zigbee2MQTT, Mosquitto, Influxdb en Grafana. Die hebben allemaal een vrij sterke relatie met elkaar, dus die heb ik in één compose file staan.

Het is verder ook niet ongebruikelijk om meerdere database containers te hebben voor verschillende applicaties die helemaal niets met elkaar te maken hebben.
Mocht je dan bijvoorbeeld een applicatie hebben die een bepaalde versie van MariaDB vereist terwijl een andere applicatie daar juist niet mee overweg kan, dan gaat dit ook nooit tot conflicten leiden.

[Freee!!]

Hathi schreef op dinsdag 14 mei 2024 @ 11:25:
Je hoeft niet per se alle containers in één compose file te plaatsen, maar wel alle containers die enige relatie/afhankelijkheid met elkaar hebben. Dat maakt het naar mijn idee ook wel zo overzichtelijk. Ik heb al mijn containers met betrekking tot mijn smarthome bijvoorbeeld in één compose file staan. Home Assistant, Zigbee2MQTT, Mosquitto, Influxdb en Grafana. Die hebben allemaal een vrij sterke relatie met elkaar, dus die heb ik in één compose file staan.

Het is verder ook niet ongebruikelijk om meerdere database containers te hebben voor verschillende applicaties die helemaal niets met elkaar te maken hebben.
Mocht je dan bijvoorbeeld een applicatie hebben die een bepaalde versie van MariaDB vereist terwijl een andere applicatie daar juist niet mee overweg kan, dan gaat dit ook nooit tot conflicten leiden.

Bedankt, dat was eigenlijk ook mijn idee al.

Nog dit gevonden als leesvoer voor @DjoeC:
https://www.baeldung.com/...container-interdependence
https://www.reddit.com/r/...rtup_order_of_containers/

[lolgast]

Ik doe dat zoals @Hathi, maar heb opzich wel een strenge scheiding in compose-bestanden. Als een docker container een database nodig heeft dan zet ik de database container in diezelfde compose-file. Maar andere database containers van andere applicaties, die staan respectievelijk in hun eigen compose-file.
Ik heb dus per applicatie een compose-file. Bijvoorbeeld

YAML:

version: '2.4'

services:
  dsmrdb:
    image: postgres:13-alpine
    container_name: dsmrdb
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./dsmrdb:/var/lib/postgresql/data
    environment:
      - TZ=Europe/Amsterdam
      - PG_TZ=Europe/Amsterdam
      - POSTGRES_USER=***
      - POSTGRES_PASSWORD=***
      - POSTGRES_DB=dsmrreader
    networks:
      - bridge
    cpus: 0.4

  dsmr:
    image: ualex73/dsmr-reader-docker
    container_name: dsmr
    depends_on:
      - dsmrdb
    cap_add:
      - NET_ADMIN
    links:
      - dsmrdb
    restart: always
    environment:
      - VIRTUAL_HOST=localhost
      - TZ=Europe/Amsterdam
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./dsmrdb_backups:/dsmr/backups
    ports:
      - 8888:80
    devices:
      - /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI1X3KNY-if00-port0:/dev/ttyUSB0
    networks:
      - bridge

networks:
  bridge:

YAML:

version: "3.7"

services:
  lychee:
    image: linuxserver/lychee
    container_name: lychee
    depends_on:
      - lycheedb
    restart: always
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - DB_HOST=lycheedb
      - DB_USERNAME=***
      - DB_PASSWORD=***
      - DB_DATABASE=lychee
      - DB_CONNECTION=mysql
      - TRUSTED_PROXIES=*
      - APP_URL=''
    volumes:
      - ./config:/config
      - ./pictures:/pictures
    labels:
      - traefik.http.routers.lychee.rule=Host("images.lolgast.nl")
      - traefik.http.routers.lychee.entrypoints=https
      - "traefik.http.routers.lychee.middlewares=hsts@file"
      - traefik.http.routers.lychee.tls=true
      - traefik.enable=true
    networks:
      - bridge
      - traefik

  lycheedb:
    image: mariadb
    container_name: lycheedb
    restart: always
    volumes:
       - ./db:/var/lib/mysql
    networks:
       - bridge
    environment:
       - MYSQL_ROOT_PASSWORD=***
       - MYSQL_PASSWORD=***
       - MYSQL_USER=***
       - MYSQL_DATABASE=lychee
#    labels:
#      - com.centurylinklabs.watchtower.enable=true

networks:
  bridge:
    external: false
  traefik:
    external: true

[Webgnome]

Kun je niet iets doen met het mergen van docker compose files? Volgens mij kun je dan wel dat ze op elkaar wachten. Heb het overigens zelf niet getest maar kan mij herrineren dat we ooit op kantoor zoiets hebben gedaan. Hadden een basch script dat diverse compose files samen raapte en er 1 grote file van maakte voor op test/staging/productie.

[DjoeC]

@Hathi @Freee!! @lolgast Tja, de oplossing van meerdere databases had ik ook al maar ben daar ivm resourcebeslag, de Raspi heeft maar 8GB en 2TB SSD, het is geen Intel/AMD met vrijwel onbeperkte resources. Ik wil niet zover gaan komen dat de 8GB onvoldoende wordt.. De oplossing van groeperen per doel (HA bijvoorbeeld) klinkt leuk maar bijvoorbeeld Mosquitto als MQTT broker zou nu juist 1 centrale speler in een totaal moeten kunnen zijn. Voor achtergrond taken als database en messagebroker zijn ook de interfaces nog wel te behappen, maar wat als er meerdere Grafana's gaan draaien met ieder hun eigen toegangspoort en hun eigen dashboards? Lijkt me op den duur onoverzichtelijk te worden.......

@Webgnome Ook die oplossing heb ik ergens langs zien komen. Werkmatig begrijpelijk en beheer(s)baar, prive lijkt me dat al snel een extra onderhoudstaak te worden als er geen "team" achter zit.

Voor mijn gevoel is er niet een "simpele" oplossing voor thuisgebruik zonder ge-emmer. Misschien dan toch Kubernetes oid als orchestrator? Of neemt die de startups/shutdoens door Docker niet over? Het probleem speelt puur bij reboots en restarts van docker-ce. Eigenlijk get dat je niet een soort van Priority kunt meegeven en dat de dependency niet over de containers heen werkt.

[remyz]

Kijk eens naar https://docs.docker.com/c...le-compose-files/extends/. Ik denk dat je dit kan gebruiken om te komen waar je wil zijn.

[DjoeC]

remyz schreef op dinsdag 14 mei 2024 @ 12:05:
Kijk eens naar https://docs.docker.com/c...le-compose-files/extends/. Ik denk dat je dit kan gebruiken om te komen waar je wil zijn.

Hmm, ook daar ga ik eens goed naar kijken. Ik zie op t eerste gezicht wel "you must make sure all paths in the files are relative to the base Compose file (i.e. the Compose file in your main-project folder)". Weet niet hoe izh dat verhoud tot het maken/hebben/gebruiken van compose files in OMV.

Tijd om de komende week een extra Pi op te zetten en wat dingen te gaan testen.....

[Mars Warrior]

@DjoeC : Ik ga ervan uit dat je de nieuwe compose gebruikt, en dan wordt het doodsimpel als je de volgende documentatie leest: https://docs.docker.com/compose/compose-file/14-include/

YAML:

include:
  - my-compose-include.yaml  #with serviceB declared
services:
  serviceA:
    build: .
    depends_on:
      - serviceB #use serviceB directly as if it was declared in this Compose file

[Hathi]

DjoeC schreef op dinsdag 14 mei 2024 @ 12:00:
@Hathi @Freee!! @lolgast Tja, de oplossing van meerdere databases had ik ook al maar ben daar ivm resourcebeslag, de Raspi heeft maar 8GB en 2TB SSD, het is geen Intel/AMD met vrijwel onbeperkte resources. Ik wil niet zover gaan komen dat de 8GB onvoldoende wordt.. De oplossing van groeperen per doel (HA bijvoorbeeld) klinkt leuk maar bijvoorbeeld Mosquitto als MQTT broker zou nu juist 1 centrale speler in een totaal moeten kunnen zijn. Voor achtergrond taken als database en messagebroker zijn ook de interfaces nog wel te behappen, maar wat als er meerdere Grafana's gaan draaien met ieder hun eigen toegangspoort en hun eigen dashboards? Lijkt me op den duur onoverzichtelijk te worden.......

@Webgnome Ook die oplossing heb ik ergens langs zien komen. Werkmatig begrijpelijk en beheer(s)baar, prive lijkt me dat al snel een extra onderhoudstaak te worden als er geen "team" achter zit.

Voor mijn gevoel is er niet een "simpele" oplossing voor thuisgebruik zonder ge-emmer. Misschien dan toch Kubernetes oid als orchestrator? Of neemt die de startups/shutdoens door Docker niet over? Het probleem speelt puur bij reboots en restarts van docker-ce. Eigenlijk get dat je niet een soort van Priority kunt meegeven en dat de dependency niet over de containers heen werkt.

Je hebt gelijk dat je inderdaad maar één centrale mosquitto broker moet willen hebben, maar heb je echt zo veel containers die gebruik maken van MQTT dat ze niet samen in één compose file kunnen? Zo heb ik het namelijk wel gewoon gedaan. Al vraag ik me ook af in hoeverre die echt voor een probleem zorgen als de broker even niet bereikbaar is. De meeste applicaties proberen het daarna toch gewoon even opnieuw? Bij mij is het volgens mij alleen zigbee2mqtt die moeilijk doet als de broker niet bereikbaar is bij het opstarten, maar die heb ik dan ook gewoon samen in één file staan aangezien die echt niet zonder elkaar kunnen en wel heel erg bij elkaar horen.
Meerdere grafana's is inderdaad wel heel overdreven, maar naar mijn idee totaal overbodig. Grafana haalt bij mij de gegevens uit mijn InfluxDB database. Daar heb ik er maar eentje van (die ook in mijn 'smarthome' compose file staat), maar mocht het nodig zijn dan zou ik gewoon een extra InfluxDB database container maken, in plaats van een extra Grafana container.

Overigens zie ik het probleem van grote compose files ook niet zo. Scheelt ook heel veel heen en weer switchen tussen files als je even wil opzoeken hoe je die andere container ook alweer geconfigureerd hebt. Stuk sneller te vinden als het gewoon in één file staat.

[DjoeC]

Hathi schreef op dinsdag 14 mei 2024 @ 12:24:
[...]


Je hebt gelijk dat je inderdaad maar één centrale mosquitto broker moet willen hebben, maar heb je echt zo veel containers die gebruik maken van MQTT dat ze niet samen in één compose file kunnen? Zo heb ik het namelijk wel gewoon gedaan. Al vraag ik me ook af in hoeverre die echt voor een probleem zorgen als de broker even niet bereikbaar is. De meeste applicaties proberen het daarna toch gewoon even opnieuw? Bij mij is het volgens mij alleen zigbee2mqtt die moeilijk doet als de broker niet bereikbaar is bij het opstarten, maar die heb ik dan ook gewoon samen in één file staan aangezien die echt niet zonder elkaar kunnen en wel heel erg bij elkaar horen.
Meerdere grafana's is inderdaad wel heel overdreven, maar naar mijn idee totaal overbodig. Grafana haalt bij mij de gegevens uit mijn InfluxDB database. Daar heb ik er maar eentje van (die ook in mijn 'smarthome' compose file staat), maar mocht het nodig zijn dan zou ik gewoon een extra InfluxDB database container maken, in plaats van een extra Grafana container.

Overigens zie ik het probleem van grote compose files ook niet zo. Scheelt ook heel veel heen en weer switchen tussen files als je even wil opzoeken hoe je die andere container ook alweer geconfigureerd hebt. Stuk sneller te vinden als het gewoon in één file staat.

Tja, ik ben persoonlijk nogal verknocht aan MQ(TT) dus de door mij zelf gebrouwen applicaties gebruiken dat volop. Het is een magnifiek medium om data (asynchroon) heen of weer te pompen naar/van 1 of meer subscribers. En die hebben niet allemaal een duidelijke relatie met elkaar.

Mogelijk heb je wel gelijk en moet ik m'n hele Docker compose gebruik heroverwegen... Dat zal gaan blijken als ik alle suggesties/geboden oplossingen/oplossingsrichtingen heb doorgewerkt. Gaat alleen wat tijd kosten ;-)

[DjoeC]

Mars Warrior schreef op dinsdag 14 mei 2024 @ 12:19:
@DjoeC : Ik ga ervan uit dat je de nieuwe compose gebruikt, en dan wordt het doodsimpel als je de volgende documentatie leest: https://docs.docker.com/compose/compose-file/14-include/

YAML:

include:
  - my-compose-include.yaml  #with serviceB declared
services:
  serviceA:
    build: .
    depends_on:
      - serviceB #use serviceB directly as if it was declared in this Compose file

Die was ik nog niet eerder tegen gekomen. Als dat betekent meerdere keren een include van (bijvoorbeeld) mariadb terwijl er toch maximaal 1 gestart wordt is dat waarschijnlijk de beste oplossing voor alle afhankelijkheden, inclusief het probleem dat @Hathi aankaartte van verschillende versies vd database. En dat is binnen OMV met variabelen (lees: versienummers als al dan niet gevulde variabelen) beheer(s)baar. Denk ik.

Meer uitzoek en testwerk.

[Webgnome]

De include is eigenlijk een vergelijkbare actie als de merge functionaliteit die ik aankaarte anders dan dat de merge inderdaad dubbele zaken probeert samen te voegen waarbij de include dat expliciet niet doet ( en zal falen ).

[alex3305]

Als alternatief voor de goede oplossing van @Mars Warrior kun je ook een health check in Compose gebruiken. Een repo met voorbeelden. Wat je dan kunt doen is bijvoorbeeld een container laten lopen in je stack die controleert of een service al beschikbaar is.

Overigens zou ik simpelweg voor elke Compose waar nodig een database laten lopen. Als ik bij mij kijk dan gebruiken mijn Postgres databases veelal minder dan 100MB geheugen.

[RobertMe]

alex3305 schreef op dinsdag 14 mei 2024 @ 13:18:
Overigens zou ik simpelweg voor elke Compose waar nodig een database laten lopen. Als ik bij mij kijk dan gebruiken mijn Postgres databases veelal minder dan 100MB geheugen.

Absoluut dit. Software zou niet zomaar veel RAM moeten gebruiken omdat die het leuk vindt terwijl het er niet is. Een database zou maar een geringe hoeveelheid geheugen moeten gebruiken. Maar als er veel RAM beschikbaar is kan die wel meer gebruiken.

Heb zelf een mini PCtje met 8GB RAM en Intel N5105 CPU. Draaien meerdere "stacks" op (waaronder Home Assistant met PostgreSQL + InfluxDB, Paperless-NGX met een eigen DB, Gitea met een eigen DB) en dat gaat gewoon prima. Geheugengebruik ligt rond de 7GB (dus ~1GB available). Maar dat is wel met ZFS als filesystem waarbij de "ARC" (cache) al iets van 2 of 3GB opslokt.

En hetzelfde op mijn minimale VPS bij Contabo (goedkoopste variant met 4 "cores" en 8GB RAM, waarschijnlijk op een overprovisioned fysieke server). Ding draaien minimaal 6 database servers op en ook daar nog wat geheugen "available" en meerdere GBs semi beschikbaar maar nu in gebruik door ZFS ARC.

Wat overigens wel aan te raden is is om in ieder geval te pogen dezelfde versies te gebruiken, en daarmee dan ook het identieke image (digest). Dan staan de libraries / executables ook maar 1x op het systeem (HDD) en worden ze ook maar 1x in het RAM ingeladen. Maar dat heb ik zelf ook niet specifiek en gaat ook zonder dus prima.

[Ben.Hahlen]

Dissenting voice!

Ik heb mijn compose files ook gescheiden (backend, management, smarthome, etc), maar ik heb in de backend compose mijn database containers (postgres, mariadb, influx), die door de andere stacks worden gebruikt.

Een aantal dingen die "hergebruikt" worden staan in een shared.yml compose file.

[alex3305]

@RobertMe Sterker nog. Deze databases staan op een server die meer dan voldoende resources heeft

alex@LeeTower:~# docker stats --no-stream | grep -i postgres
CONTAINER ID   NAME                       CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
422323c6a703   outline-postgres           0.00%     43.27MiB / 31.17GiB   0.14%     59MB / 94MB       99.6MB / 41.7MB   8
2f9408dc1520   paperless-postgres         0.00%     50.52MiB / 31.17GiB   0.16%     29MB / 304MB      290MB / 178MB     8
b788c011a510   immich-postgres            0.00%     237.9MiB / 31.17GiB   0.75%     402MB / 224MB     2.55GB / 4.36GB   23

alex@LeeTower:~# free -m
               total        used        free      shared  buff/cache   available
Mem:           31914       13702         991        4889       17220       12931
Swap:              0           0           0

en dit zijn ook geen lichte applicaties. Toegegeven, Home Assistant en Spotweb gebruiken wat meer memory met 1GB en 500MB respectievelijk. Maar ik heb geen enkele applicatie, database of stack begrensd in resources. Want dat is ook nog een optie met Docker. Het enige wat ik doe is CPU affiniteit instellen om mijn stroomverbruik te beperken. En een ander voorbeeld, ik heb voor elke stack een aparte Watchtower instantie draaien waar ik dat wil. Tja dat zijn dan 10 applicaties met 10MB geheugen. Daar maak ik me dan echt niet druk over.

Ik heb jaren lang mijn applicaties op aardappels gedraaid en 8GB geheugen is echt prima te managen. Home Assistant en wat neven containers op een Pi3B met 1GB RAM was pas echt krap .

Ben.Hahlen schreef op dinsdag 14 mei 2024 @ 14:12:
[...]
Een aantal dingen die "hergebruikt" worden staan in een shared.yml compose file.

Ik snap het, maar dit voelt toch niet zo lekker. Vooral omdat dan de stacks niet meer los te deployen zijn zonder de shared.yml compose. En voor een message broker (Mosquitto, RabbitMQ) snap ik dat ook nog wel, maar voor zoiets als een database voelt dat toch niet zo .

[Ben.Hahlen]

alex3305 schreef op dinsdag 14 mei 2024 @ 14:31:
[...]

Ik snap het, maar dit voelt toch niet zo lekker. Vooral omdat dan de stacks niet meer los te deployen zijn zonder de shared.yml compose. En voor een message broker (Mosquitto, RabbitMQ) snap ik dat ook nog wel, maar voor zoiets als een database voelt dat toch niet zo .

Mijn shared.yaml heeft dit soort dingen er in staan:

YAML:

services:
  base:
    domainname: home
    restart: always
    volumes:
      - ${CONF_DIR}/shared:/shared

  main-shared:
    extends:
      service: base
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}

  common-shared:
    extends:
      service: main-shared
    labels:
      ## Traefik
      - "traefik.enable=true"
      - "traefik.docker.network=lan_net"

Dat kan ik prima in de losse compose-files zetten, maar ik hou niet van duplicatie

[DjoeC]

Zomaar een greep uit 23 running containers:

code:

CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
aa3c72f996ce   homeassistant   0.88%     573.2MiB / 7.628GiB   7.34%     5.12MB / 1.64MB   350MB / 54.3MB    40
0d3167ea2585   mariadb         0.22%     283.3MiB / 7.628GiB   3.63%     5.74MB / 13.7MB   277MB / 3.3MB     29
4f1a61ec5be9   grafana         0.04%     249.8MiB / 7.628GiB   3.20%     52.6kB / 10.1kB   221MB / 565kB     18
b84b941633f3   influxdb        0.64%     2.524GiB / 7.628GiB   33.09%    422kB / 45.8kB    2.3GB / 922kB     17

Vooral influxdb valt op.... Dit is wel een kwartier na een complete reboot omdat de stats geen stats weergaven ;-) en er eerst

code:

 cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1

aan de /boot/firmware/cmdline.txt moest worden toegevoegd.

Ik neem alle suggesties mee en ga deze week/komende weken wat experimenteren. Voorlopig probeer ik vast te houden aan "zoveel mogelijk" 1 instantie van de database/grafana/etc containers.

Omdat het totale CPU verbruik nog laag is was ik van plan om nog veel meer containers toe te voegen binnen die 8GB. Alleen swappen e.d. is voor mij voorlopig not-done vanwege I/O delays en wear-and-tear op de SSD. O ja, de dagelijkse logging staat op RAM disk (256MB van de 8GB).

[ Voor 11% gewijzigd door DjoeC op 14-05-2024 15:02 ]

[alex3305]

@DjoeC Ik weet niet wat jouw InfluxDB uitvreet. Ik heb hier Influx 1 draaien met continious queries en retention policies en die van mij gebruikt echt een stuk minder resources:

alex@LeeTower:~# docker stats --no-stream | grep -i influx
e1c28845c9cb   homeassistant_influxdb     0.06%     155.5MiB / 31.17GiB   0.49%     1.38GB / 27.2MB   46.6GB / 15.9GB   11

Ik gebruik de volgende Influx configuratie in Compose:

YAML:

services:
  influxdb:
    container_name: homeassistant_influxdb
    image: influxdb:1.8
    environment:
      INFLUXDB_DATA_WAL_FSYNC_DELAY: 60s
      INFLUXDB_MONITOR_STORE_ENABLED: false
      INFLUXDB_DATA_QUERY_LOG_ENABLED: false
      INFLUXDB_HTTP_LOG_ENABLED: false

Hiernaast kun je ook de container nog limiteren op geheugenverbruik, bijvoorbeeld:

YAML:

services:
  influxdb:
    container_name: homeassistant_influxdb
    image: influxdb:1.8
    deploy:
      resources:
        limits:
          memory: 1G

Daarnaast heb je InfluxDB eigenlijk niet meer nodig met de huidige Home Assistant long term storage.

[Mars Warrior]

InfluxDB is inderdaad wel extreem veel ja:

Bash Session:

$ docker stats --no-stream | grep "influx"
41e3c34ec982   met-influxdb              0.06%     229.4MiB / 30.89GiB   0.73%     5.17GB / 4.95GB   14GB / 66.8GB     63

[alex3305]

Na de edit van @DjoeC:

DjoeC schreef op dinsdag 14 mei 2024 @ 15:00:
Omdat het totale CPU verbruik nog laag is was ik van plan om nog veel meer containers toe te voegen binnen die 8GB.

Ik heb tijden een volledige *arr stack gedraaid met SabNZBd, Immich en AdGuard op 8GB geheugen met ruimte over. Dus ik snap het eigenlijk niet. Dat was echt totaal geen probleem. Idem voor mijn andere node met Home Assistant, Plex en nog wat andere zaken, ook met 8GB.

Weet je zeker dat je geheugen tekort komt en niet dat het gedeeld of gebufferd is? Linux werkt in dat opzicht toch anders dan Windows.

Alleen swappen e.d. is voor mij voorlopig not-done vanwege I/O delays en wear-and-tear op de SSD. O ja, de dagelijkse logging staat op RAM disk (256MB van de 8GB).

Ik had swap uitstaan op de node met 8GB RAM. Gaf in mijn geval nooit problemen. Wear en tear op de SSD hoef je je echt helemaal geen zorgen over te maken. Mijn Samsung 980 1TB systeem disk heeft na 1 jaar gebruik (power on hours) 80TB gebruikt. Dat is tevens de disk waar ik mijn data op binnenhark. Volgens SMART is er nu 13% van de schijf gebruikt en volgens Samsung is de TBW 600TB. Als ik dus in hetzelfde tempo doorga kan ik nog minimaal 7,5 jaar met de disk doen. Maar dan denk ik dat mijn 1TB al afgeschreven is .

Overigens heb je het in andere posts over Kube. Als er iets veel geheugen gebruikt zonder dat er iets is, is het Kubernetes wel . Ik zou je aanraden om met Prometheus en/of cAdvisor eens te gaan kijken waar het verbruik vandaan komt. Want met 8GB moet wat jij wilt volgens mij makkelijk kunnen.

[RobertMe]

TIL: docker stats.

DSMR reader is dan zo te zien ook niet heel erg zuinig, 5-10 procent CPU gebruik. En dan is het ook nog een DSMR4 meter. Dus elke 5 of 10 seconden (weet ik even niet meer) dat die data stuurt. Bij DSMR5 is dat elke seconde. Meter wordt uitgelezen door een custom ESPtje die het raw via een socket doorgeeft. Aan de DSMR Reader kant dus een "ser2net" variant.

[DjoeC]

alex3305 schreef op dinsdag 14 mei 2024 @ 15:18:
Na de edit van @DjoeC:


[...]

Ik heb tijden een volledige *arr stack gedraaid met SabNZBd, Immich en AdGuard op 8GB geheugen met ruimte over. Dus ik snap het eigenlijk niet. Dat was echt totaal geen probleem. Idem voor mijn andere node met Home Assistant, Plex en nog wat andere zaken, ook met 8GB.

Weet je zeker dat je geheugen tekort komt en niet dat het gedeeld of gebufferd is? Linux werkt in dat opzicht toch anders dan Windows.


[...]

Ik had swap uitstaan op de node met 8GB RAM. Gaf in mijn geval nooit problemen. Wear en tear op de SSD hoef je je echt helemaal geen zorgen over te maken. Mijn Samsung 980 1TB systeem disk heeft na 1 jaar gebruik (power on hours) 80TB gebruikt. Dat is tevens de disk waar ik mijn data op binnenhark. Volgens SMART is er nu 13% van de schijf gebruikt en volgens Samsung is de TBW 600TB. Als ik dus in hetzelfde tempo doorga kan ik nog minimaal 7,5 jaar met de disk doen. Maar dan denk ik dat mijn 1TB al afgeschreven is .

Overigens heb je het in andere posts over Kube. Als er iets veel geheugen gebruikt zonder dat er iets is, is het Kubernetes wel . Ik zou je aanraden om met Prometheus en/of cAdvisor eens te gaan kijken waar het verbruik vandaan komt. Want met 8GB moet wat jij wilt volgens mij makkelijk kunnen.

toon volledige bericht

Momenteel kom ik nog geen geheugen tekort, zit op 50%. Maar als iemand die al jaren (onder andere) aan allerlei performance en capaciteits issues heeft gewerkt en wetende wat ik er allemaal nog bij wil zetten: Ik voorkom die uitdagingen liever....

Qua disk: Ik heb een T7, smartctl geeft niet alles weer, daarvoor moet ik de SSD aan de Windows PC hangen (nu effe niet), TBW niet gespecificeerd, zal wel ergens rond 1000TBW liggen, momenteel zit ik op 12TB written en 56TB read, ook daar: Liever voorkom ik excessief gebruik door er vanaf moment 0 "slim" mee om te gaan.

Kubernetes: nog geen ervaring mee al begreep ik dat je er containers mee kunt stoppen/starten/besturen (regisseren), vandaar mijn opmerking. Maar als t niet hoeft: Heb al weer veel dingen om me in te verdiepen.

[DjoeC]

@alex3305 InfluxDB staat bij mij op de onderzoekslijst. Momenteel draait ie zonder specifieke configuartie, alleen voor de HA long term. Ik wil me nog verdiepen in wat en hoe ie de dingen daar precies opslaat en die gegevens eventueel "anders" gaan opslaan. Ik ben van de hierarchische of relationele databases, NOG niet van de timeseries tabellen waar alles maar ingeknikkerd wordt.... Maar misschien is het wel een heel mooi iets dat ik onderscht.......

[DjoeC]

En nu, naast alle andere werkzaamheden, eerst aan de gang met alle tips en tricks en dus voorlopig geen reacties meer ;-) Tweakers bijhouden kost ook tijd.

[Mars Warrior]

DjoeC schreef op dinsdag 14 mei 2024 @ 16:56:
[...]
Kubernetes: nog geen ervaring mee al begreep ik dat je er containers mee kunt stoppen/starten/besturen (regisseren), vandaar mijn opmerking. Maar als t niet hoeft: Heb al weer veel dingen om me in te verdiepen.

Ik zou Kubernetes lekker links laten liggen als je je zorgen maakt over CPU, RAM en SSD gebruik

En dat nog even los van de complexiteit tov een docker compose file...

[FateTrap]

Je kunt meestal ook gewoon FreeBSD Jails gebruiken in plaats van Docker. Op gebied van beveiliging zit er heel veel malware in de meerderheid van de Docker images. En Docker zelfs is ook minder goed beveiligd dan Jails.

Ik heb de populariteit van Docker nooit echt begrepen. Het is 10 jaar later uitgebracht als Jails en was op veel gebieden inferieur aan Jails. Hoewel we nu 2024 zijn lijkt Jails nog altijd beter te zijn in veel situaties:
https://it-notes.dragas.n...to-a-new-freebsd-machine/
https://medium.com/thecon...s-in-freebsd-e2a3ef86d09c

Of als ik Zones van Illumos/Solaris technologisch vergelijk met Docker kom ik al snel tot de conclusie dat Docker veel nuttige basisfuncties niet eens heeft.

Waarom is het dan zo populair geworden als Jails en Zones zoveel jaar eerder grotendeels dezelfde taken al beter deden?

[FateTrap]

Enkele feiten die over Docker geschreven zijn om bovenstaande visie te verduidelijken.

'Even today, trying to run a 5 year old Docker "image" will probably no longer work, which I think is quite amusing.'

'The word "container" doesn't come from Docker, it comes from Solaris and basically means holistic sandboxing.'

'There is no containerization in Docker. It's cgroups and namespaces, that's it. Security is not even a design constraint for docker. Docker should be called CFEngine++.'

'What I found with Zones after using them for a number of years was that I got containers/virtual machine in one nice package. I actually had to "install" a zone which put a mini OS there with ethernet ports available on each zone and console ports for each zone. I could login to a zone and not even know it was just a piece of a machine however, under the hood, it would lay over the existing ethernet drivers, use the existing TCP stack, and use the same shared libraries that the other zones used in a single shared instance. It was literally the best of both worlds. Zones, ZFS and Dtrace just are not quite on Linux yet.'

[FateTrap]

'I prefer Illumos containers, far better designed.'
'Docker was not designed for security, it has a lot of security issues consequently, unlike Illumos.'

'SmartOS/Illumos zones are actually a later incarnation of BSD Jails that was based on the idea of BSD Jails, specifically instead of just having a kernel shim it actually has entries in the kernel process table itself, that allows processes to have unique networking, unique I/O, unique everything, with the kernel mediating between. It is significantly more advanced and capable.'

[Webgnome]

FateTrap schreef op woensdag 15 mei 2024 @ 02:12:
Je kunt meestal ook gewoon FreeBSD Jails gebruiken in plaats van Docker. Op gebied van beveiliging zit er heel veel malware in de meerderheid van de Docker images. En Docker zelfs is ook minder goed beveiligd dan Jails.

Ik heb de populariteit van Docker nooit echt begrepen. Het is 10 jaar later uitgebracht als Jails en was op veel gebieden inferieur aan Jails. Hoewel we nu 2024 zijn lijkt Jails nog altijd beter te zijn in veel situaties:
https://it-notes.dragas.n...to-a-new-freebsd-machine/
https://medium.com/thecon...s-in-freebsd-e2a3ef86d09c

Of als ik Zones van Illumos/Solaris technologisch vergelijk met Docker kom ik al snel tot de conclusie dat Docker veel nuttige basisfuncties niet eens heeft.

Waarom is het dan zo populair geworden als Jails en Zones zoveel jaar eerder grotendeels dezelfde taken al beter deden?

Lotus Notes was ook veel eerder een NoSql database voordat zaken als mongo etc een hit werden. Hoe lang iets op de markt is zegt niks over de bruikbaarheid/populariteit.

Als ik je post doorlees dan voelt het een beetje als een ' ja maar jullie...' Daar gaat dit topic niet over toch?

[alex3305]

Ik hap wel.

FateTrap schreef op woensdag 15 mei 2024 @ 02:12:
Op gebied van beveiliging zit er heel veel malware in de meerderheid van de Docker images.

Dit slaat nergens op en is 100% onwaar. Het enige wat ik hierover kan vinden is dit onderzoek van 2 jaar geleden. Waar zo'n 1600 images van de onderzochte 250.000, zonder officiële images (!), verdacht waren. Dat is minder dan 1% van de onderzochte images. Met de populariteit van Docker is malware ook enigszins te verwachten.

Wat jij denk ik bedoelt te zeggen is dat Docker images veelal beveiligingsproblemen hebben. Bijvoorbeeld door oude software te gebruiken met daarin CVE's. Dat is namelijk wel zo. Maar in de praktijk is dit veelal probleem omdat Docker containers veelal afgeschermd worden door een aparte buitenlaag. En daarnaast staan veel van mijn applicaties, bijvoorbeeld databases, niet ontsloten naar de buitenwereld. Het is dus 'onmogelijk' om daar zomaar bij te komen.

FateTrap schreef op woensdag 15 mei 2024 @ 03:03:
'Even today, trying to run a 5 year old Docker "image" will probably no longer work, which I think is quite amusing.'

Toverwoord probably. Want ik weet zeker dat images van 5 jaar geleden nog wel werken. Die gebruik(te) ik namelijk weleens.

'The word "container" doesn't come from Docker, it comes from Solaris and basically means holistic sandboxing.'

En Jail komt ook niet van BSD, maar van gevangenis . Dit is een pedantische zeikopmerking zonder inhoud.

Je kunt meestal ook gewoon FreeBSD Jails gebruiken in plaats van Docker. [...]

Ik heb de populariteit van Docker nooit echt begrepen. Het is 10 jaar later uitgebracht als Jails Docker (FTFY ) en was op veel gebieden inferieur aan Jails. [...]

Waarom is het dan zo populair geworden als Jails en Zones zoveel jaar eerder grotendeels dezelfde taken al beter deden?

Het mag dan misschien technisch beter zijn, Docker is simpelweg heel eenvoudig in gebruik. Daarnaast is het onmogelijk om FreeBSD Jails of Solaris Zones op Linux te draaien. Aangezien ik geen FreeBSD systemen heb, kan ik dus geen Jails gebruiken.

Maar buiten dit alles snap ik niet zo goed wat je hier nu komt verkondigen... Dat er Jails en Docker is, is toch prima? Het is geen pis verwedstrijd. Dat Audi, BMW en Mercedes naast elkaar bestaan is toch ook prima ? Dergelijke onsamenhangende posts voegen ook m.i. weinig toe aan de discussie. Uiteindelijk vind ik het prachtig dat het doel van containerisatie wordt bereikt. Of dat dan met Jails, Zones, Containers of Potatoes is kan me vrij weinig interesseren.

Docker heeft het (wellicht zwakke) product heel erg sterk vermarkt en dat is enorm knap en daar pluk ik vandaag de dag nog steeds de vruchten van .

[FateTrap]

alex3305 schreef op woensdag 15 mei 2024 @ 10:12:
Ik hap wel.


[...]

Dit slaat nergens op en is 100% onwaar. Het enige wat ik hierover kan vinden is dit onderzoek van 2 jaar geleden. Waar zo'n 1600 images van de onderzochte 250.000, zonder officiële images (!), verdacht waren. Dat is minder dan 1% van de onderzochte images. Met de populariteit van Docker is malware ook enigszins te verwachten.

'Slaat nergens' op is niet echt hoe ik het zou verwoorden. Eerder het omgekeerde. Het Docker ecosysteem is sowieso meer dan 1 % malware.

Millions of Malicious Containers Found on Docker Hub
https://www.infosecurity-...-containers-found-docker/
According to JFrog, approximately 25% of these repositories lack useful functionality and serve instead as vehicles for spam, pirated content promotion and malware dissemination.

Docker Images: Why are Many Cyber Attacks Originating Here?
https://blog.checkpoint.c...attacks-originating-here/

Three million Docker Hub repositories are being used to spread malware
https://www.itpro.com/sec...ng-used-to-spread-malware

Misconfigured container services are a security risk
https://www.computerweekl...vices-are-a-security-risk
“Seemingly simple misconfigurations within cloud services can lead to severe impacts on organisations,” says the blog post, giving the example of the theft of keys and tokens for about 190,000 Docker accounts in April 2019, when an attacker was able to exploit weak security configurations of key and token storage within a cloud environment.

Root Account Misconfiguration Potentially Exposes 19% of the Top 1,000 Containers in Docker Hub
https://www.trendmicro.co...-containers-in-docker-hub

In de VS gebruikt men voor het evalueren van academische studenten vaak een lettersysteem, van A tot en met F. Wat ik met mijn oorspronkelijke comment probeer te zeggen is dat Docker op gebied van beveiliging/prestaties/mogelijkheden heel frequent en objectief gezien onder deze F beoordelingsschaal valt.

Verder zie je ook de populariteit van Python en C++, maar voor een eindgebruiker biedt dit geen voordeel tov een app die in Zig/Rust/C geprogrammeerd is.
De Python apps gaan gewoon vele malen trager draaien en bovendien veel bugs hebben.
En hetzelfde geldt voor C++ apps die door de objectgeoriënteerde overhead zo goed als altijd trager zijn dan C apps en ook meer bugs hebben dan C apps.
Hetzelfde met JavaScript dat vaak veel trager en onveiliger is dan WebAssembly. En meestal ook volledig overbodig is voor een website en een populaire bron van exploits voor eingebruikers omdat het ontwikkeld was als een lichtgewicht scriptingtaal en helemaal niet bedoeld was om de standaard voor het web te worden.
Verder zie ik ook de populariteit van Ubuntu, maar voor welk type taak is Ubuntu het snelst en/of het veiligst en/of het makkelijkst te beheren? Antwoord: zo goed als helemaal niks.

Om mijn comment meer algemeen te plaatsten, wat is nog het nut van universitaire diploma's en opleiding als de meeste computer ingenieurs objectief gezien op gebied geleverde resultaten in (procentueel gezien) grote aantallen in deze F categorie vallen? Ik denk dat Docker niet populair is geworden om goed gefundeerde redenen maar eerder een random bandwagon effect was. Het is toch redelijk voor de hand liggend dat dit enkel kan gebeuren als men op school geen basic kritische denkvaardigheden heeft aangeleerd en men in grote aantallen sterk afgestompt geweest is. (een verdomming in plaats van een verslimming)

Als dit de observaties uit de realtiteit zijn dan denk ik dat het ook verplicht dient te worden dat 'hoogopgeleiden' voortaan hernoemd worden met een term die deze opleiding beter omschrijft. 'laagopgeleiden' of 'leeglopers'

Ik zou graag willen zien dat dit topic over ervaringen met Docker blijft gaan. Het is een ieders recht om wat van de achterliggende techniek, kwaliteit of evt. noodzaak te vinden maar daar is dit niet het juiste topic voor. Dit topic gaat over mensen die docker gebruiken en daar ervaringen over willen uitwisselen.

Ik snap dat de grens soms wat grijs is. Maar probeer een beetje on-topic te blijven.

[ Voor 10% gewijzigd door Question Mark op 14-06-2024 11:24 ]

[RobertMe]

FateTrap schreef op woensdag 15 mei 2024 @ 13:48:
[...]


'Slaat nergens' op is niet echt hoe ik het zou verwoorden. Eerder het omgekeerde. Het Docker ecosysteem is sowieso meer dan 1 % malware.

Millions of Malicious Containers Found on Docker Hub
https://www.infosecurity-...-containers-found-docker/
According to JFrog, approximately 25% of these repositories lack useful functionality and serve instead as vehicles for spam, pirated content promotion and malware dissemination.

Docker Images: Why are Many Cyber Attacks Originating Here?
https://blog.checkpoint.c...attacks-originating-here/

Three million Docker Hub repositories are being used to spread malware
https://www.itpro.com/sec...ng-used-to-spread-malware

Misconfigured container services are a security risk
https://www.computerweekl...vices-are-a-security-risk
“Seemingly simple misconfigurations within cloud services can lead to severe impacts on organisations,” says the blog post, giving the example of the theft of keys and tokens for about 190,000 Docker accounts in April 2019, when an attacker was able to exploit weak security configurations of key and token storage within a cloud environment.

Root Account Misconfiguration Potentially Exposes 19% of the Top 1,000 Containers in Docker Hub
https://www.trendmicro.co...-containers-in-docker-hub

In de VS gebruikt men voor het evalueren van academische studenten vaak een lettersysteem, van A tot en met F. Wat ik met mijn oorspronkelijke comment probeer te zeggen is dat Docker op gebied van beveiliging/prestaties/mogelijkheden heel frequent en objectief gezien onder deze F beoordelingsschaal valt.

Verder zie je ook de populariteit van Python en C++, maar voor een eindgebruiker biedt dit geen voordeel tov een app die in Zig/Rust/C geprogrammeerd is.
De Python apps gaan gewoon vele malen trager draaien en bovendien veel bugs hebben.
En hetzelfde geldt voor C++ apps die door de objectgeoriënteerde overhead zo goed als altijd trager zijn dan C apps en ook meer bugs hebben dan C apps.
Hetzelfde met JavaScript dat vaak veel trager en onveiliger is dan WebAssembly. En meestal ook volledig overbodig is voor een website en een populaire bron van exploits voor eingebruikers omdat het ontwikkeld was als een lichtgewicht scriptingtaal en helemaal niet bedoeld was om de standaard voor het web te worden.
Verder zie ik ook de populariteit van Ubuntu, maar voor welk type taak is Ubuntu het snelst en/of het veiligst en/of het makkelijkst te beheren? Antwoord: zo goed als helemaal niks.

Om mijn comment meer algemeen te plaatsten, wat is nog het nut van universitaire diploma's en opleiding als de meeste computer ingenieurs objectief gezien op gebied geleverde resultaten in (procentueel gezien) grote aantallen in deze F categorie vallen? Ik denk dat Docker niet populair is geworden om goed gefundeerde redenen maar eerder een random bandwagon effect was. Het is toch redelijk voor de hand liggend dat dit enkel kan gebeuren als men op school geen basic kritische denkvaardigheden heeft aangeleerd en men in grote aantallen sterk afgestompt geweest is. (een verdomming in plaats van een verslimming)

Als dit de observaties uit de realtiteit zijn dan denk ik dat het ook verplicht dient te worden dat 'hoogopgeleiden' voortaan hernoemd worden met een term die deze opleiding beter omschrijft. 'laagopgeleiden' of 'leeglopers'

toon volledige bericht

Goed verhaal, lekker kort ook.

Gelukkig is Docker in Go geschreven dan, als C++ en Python zo slecht zijn. Of wat was je punt nu?

[lolgast]

@FateTrap Even voor mijn beeldvorming: Doe je dit ook in de Windows topics? En ga je in de Cisco topics ook random links naar pro-F5 artikelen posten?

Oftewel: Wat kom je doen? Heb je een inhoudelijke vraag?
Als je jezelf de vraag moet stellen waarom FreeBSD Jails niet zo populair is als Docker zit je als FreeBSD user heel erg veilig in je FreeBSD-bubbel. Lekker daar blijven

[alex3305]

Ik haal uit de, wederom onsamenhangende, posts dat @FateTrap vooral denkt dat techniek een wedstrijd is. En misschien is het nieuws voor die persoon, maar dat is niet zo. Het is heel simpel:

• Er is geen beste programmeertaal.
• Er is geen beste OS.
• Er is geen beste container-omgeving.

Het is allemaal gereedschap. Python is enorm geschikt om snel PoC's in te maken. C en C++ zijn enorm geschikt voor embedded. Rust is daar een opvolging van. Met Go kun je enorm eenvoudig multitasken. JavaScript is enorm eenvoudig om in te stappen en heeft een enorm ecosysteem. Java is fijn in enterprise omgevingen. En .NET werkt prettig op Windows. Om maar even wat voorbeelden te noemen. Dit geldt uiteraard ook voor besturingssystemen en andere technieken. Ik bedoel maar, je gaat ook geen spijkers in hout slaan met een boormachine. Of schroeven met een tang. Kan wel, maar is niet zo handig.

Docker is ook geen wedstrijd. Docker is eenvoudig in gebruik en portable. Dat maakt het enorm krachtig. Als je dat niet ziet ben je wat mij betreft enorm kortzichtig. Sterker nog, niet alle gereedschappen naar waarde kunnen schatten en gebruiken is wat mij betreft laagopgeleid. Want ik vind het nogal wat @FateTrap, hier alle Docker gebruikers als laagopgeleiden of leeglopers neerzetten .

En dan nog even over malware in Docker. Er zal vast malware zijn. Al is het 10%, percentages boeien me vrij weinig. Ook hierbij geldt weer, je kunt alles wel misbruiken. Messen, auto's en ook computersystemen. Maar je gaat er compleet aan voorbij dat populariteit tevens zorgt voor meer misbruik. Je hebt ook meer Windows malware dan Linux malware bijvoorbeeld. Dus de cijfers die je noemt zeggen niets, want ze staan nergens tot in verhouding.

[DjoeC]

Mars Warrior schreef op dinsdag 14 mei 2024 @ 12:19:
@DjoeC : Ik ga ervan uit dat je de nieuwe compose gebruikt, en dan wordt het doodsimpel als je de volgende documentatie leest: https://docs.docker.com/compose/compose-file/14-include/

YAML:

include:
  - my-compose-include.yaml  #with serviceB declared
services:
  serviceA:
    build: .
    depends_on:
      - serviceB #use serviceB directly as if it was declared in this Compose file

Yep, compose (ik meen) 3.8 in docker 26.1.3. Ik heb nog steeds als uitgangspunt: 1 actieve mariadb instantie en dan gaat include met depends_on niet werken

Met include:

Container database Creating
Error response from daemon: Conflict. The container name "/database" is already in use by container "2d434ede87e1f43d8fe2cc13bb37f36863ea39dcb948760c974cfc8479784134". You have to remove (or rename) that container to be able to reuse that name.

Zonder include maar met depends_on en container "database" actief:

service "applicatie" depends on undefined service "database": invalid compose project

Losse database container gestopt, dan compose uitvoeren met opbrengen beide containers (en wachten op de healthcheck) werkt wel maar ja, dat gaat dus niet met maar 1 dabase instantie over meerdere compose files. Jammer want dit leek me de meest veelbelovende optie.

Tijd voor de andere suggesties...

[DjoeC]

Ben.Hahlen schreef op dinsdag 14 mei 2024 @ 14:12:
Dissenting voice!

Ik heb mijn compose files ook gescheiden (backend, management, smarthome, etc), maar ik heb in de backend compose mijn database containers (postgres, mariadb, influx), die door de andere stacks worden gebruikt.

Een aantal dingen die "hergebruikt" worden staan in een shared.yml compose file.

Maar, hoe zorg jij ervoor dat ze volgtijdelijk correct worden opgestart? Of is dat "op hoop van zegen" na een reboot/docker update?

[RobertMe]

DjoeC schreef op vrijdag 17 mei 2024 @ 14:07:
[...]

Maar, hoe zorg jij ervoor dat ze volgtijdelijk correct worden opgestart? Of is dat "op hoop van zegen" na een reboot/docker update?

Fatsoenlijke software zou dat gewoon moeten handlen? Dus error als DB niet beschikbaar is en op moment dat DB weer beschikbaar is weer verbinden.
Nog los van dat Docker uberhaupt een crashende (/niet startende) container automatisch opnieuw laat opstarten (tot een X aantal pogingen). Dus dan zou die het als het goed is opnieuw proberen nadat de DB wel in de lucht is.

Of ben ik nu in de war met zowel systemd als Kubernetes die falende services / pods automatisch herstarten?

[DjoeC]

RobertMe schreef op vrijdag 17 mei 2024 @ 14:11:
[...]

Fatsoenlijke software zou dat gewoon moeten handlen? Dus error als DB niet beschikbaar is en op moment dat DB weer beschikbaar is weer verbinden.
Nog los van dat Docker uberhaupt een crashende (/niet startende) container automatisch opnieuw laat opstarten (tot een X aantal pogingen). Dus dan zou die het als het goed is opnieuw proberen nadat de DB wel in de lucht is.

Of ben ik nu in de war met zowel systemd als Kubernetes die falende services / pods automatisch herstarten?

Joomla in Docker faalt als de DB niet beschikbaar is. Misschien heb je wel gelijk en zou ik daarvoor een ticket bij Joomla moeten openen?
Correctie, het heeft wat tijd nodig maar Joomla faalt er niet op.

[ Voor 4% gewijzigd door DjoeC op 17-05-2024 15:30 . Reden: Fout vertrekpunt ]

[RobertMe]

DjoeC schreef op vrijdag 17 mei 2024 @ 14:13:
[...]

Joomla in Docker faalt als de DB niet beschikbaar is. Misschien heb je wel gelijk en zou ik daarvoor een ticket bij Joomla moeten openen?

Joomla is in PHP geschreven. En PHP heeft een lifecycle bestaande uit requests. Dus alleen als je de Joomla website wilt openen en de DB is niet bereikbaar zou dat tot problemen mogen leiden. Tenzij de Docker container bij het opstarten het een en ander met de DB wilt doen. Maar dat is dan een probleem met het specifieke image en ligt dus niet aan Joomla zelf. Bij de PHP applicaties die ikzelf draai in Docker heb ik in ieder geval geen specifieke depends op de DB container.

offtopic:
Joomla, dat is een naam die ik al lang niet meer heb gehoord / gelezen. Ik dacht dat dat al lang een stille dood gestorven zou zijn.

[Ben.Hahlen]

DjoeC schreef op vrijdag 17 mei 2024 @ 14:07:
[...]
Maar, hoe zorg jij ervoor dat ze volgtijdelijk correct worden opgestart? Of is dat "op hoop van zegen" na een reboot/docker update?

Zoals @RobertMe zegt:

RobertMe schreef op vrijdag 17 mei 2024 @ 14:11:
[...]

Fatsoenlijke software zou dat gewoon moeten handlen? Dus error als DB niet beschikbaar is en op moment dat DB weer beschikbaar is weer verbinden.
Nog los van dat Docker uberhaupt een crashende (/niet startende) container automatisch opnieuw laat opstarten (tot een X aantal pogingen). Dus dan zou die het als het goed is opnieuw proberen nadat de DB wel in de lucht is.

Of ben ik nu in de war met zowel systemd als Kubernetes die falende services / pods automatisch herstarten?

Ik ga er van uit (aannames, altijd gevaarlijk) dat de software op een dergelijke manier geschreven is, dat deze niet stuk gaat als de DB er nog niet is.

Daarnaast heb ik een paar "depends_on" referenties in de compose zitten.

Mijn Wordpress container heeft volgens mij wel een external-link naar de mariadb container, maar dat is volgens mij alleen maar om de connectie te garanderen.

In ieder geval (nog) geen problemen mee gehad.

[DjoeC]

Ben.Hahlen schreef op vrijdag 17 mei 2024 @ 14:39:
Ik ga er van uit (aannames, altijd gevaarlijk)

Uit ervaring weet ik dat aannames je ooit pijn kunnen doen, zou fantastische voorbeelden kunnen geven Ik heb de Joomla fout ook maar 1x gezien en helaas niet bewaard.

Voor prive is de oplossing niet super belangrijk anders dan in de context: "dit moet toch gewoon kunnen?". Dat mijn website een halve dag of een dag uit de lucht is kost niks MAAR t moet niet hoeven en moet te voorkomen zijn. Ik zie om me heen al veel te veel POCjes en Pilots en weet ik al niet wat waarbij het (nog lang niet eind)resultaat gammel is en blijft. Maar nu dwaal ik af.

Het zou gewoon moeten kunnen dat een container pas in de lucht komt als een andere (onafhankelijke!) container draait. Mijn gevoel is dat hier een "gebrek" in Docker zit: Afhankelijkheden kunnen niet of je moet alles in 1 grote compose mikken, include gebruiken is effectief natuurlijk hetzelfde.

[DjoeC]

Correctie op DjoeC in "[Docker] [alle OS] Het grote Docker ervaringen en tips topic" : Joomla geeft (nu) wel fatsoenlijke meldingen en blijft proberen te verbinden. Helaas, de eerdere "hang" melding heb ik niet meer en de huidige container is een nieuwere Joomla sub-versie. Ofwel klagen over de Joomla container was onterecht.

[Sharky]

FateTrap schreef op woensdag 15 mei 2024 @ 13:48:


[...] Het is toch redelijk voor de hand liggend [...]

Voor iemand die anderen beticht van een gebrek aan niveau schaam je je er ook niet echt voor om te laten zien dat je zelf ergens onderaan bungelt. Ik waardeer je eerlijkheid, maar het maakt je punt niet sterker. Als je nou wat minder onsamenhangend was en feit en mening kon scheiden in je teksten zou je nog een enkele medestander kunnen vinden.

[Flans]

Sharky schreef op vrijdag 17 mei 2024 @ 15:39:
[...]


Voor iemand die anderen beticht van een gebrek aan niveau schaam je je er ook niet echt voor om te laten zien dat je zelf ergens onderaan bungelt. Ik waardeer je eerlijkheid, maar het maakt je punt niet sterker. Als je nou wat minder onsamenhangend was en feit en mening kon scheiden in je teksten zou je nog een enkele medestander kunnen vinden.

Ik heb op basis van je reactie het relaas eens gelezen want TLTR. Wat een vermakelijk stukje tekst

[Arunia]

Lange tijd niet in mijn eigen topic geweest.
Maar kom er vandaag achter dat sinds gisteren ineens al mijn containers en alles verdwenen is. Docker Desktop onder Windows via WSL met Linux containters.

Volgens mij is er geen update geweest. Niet wat ik zelf geïnitieerd heb. Ik ben bang dat alles dus gewoon weg is. Dat is dan wel meteen het nadeel van Docker heb ik gemerkt. Maar wellicht komt dat meer door niet te weten hoe je backups maakt.

Ik heb al gecheckt, er draait niets meer op de achtergrond.
Geen idee of de verwijzing naar de plek wellicht verkeerd is, maar net nu alles een beetje lekker begon te draaien, is dit wat er gebeurd.
Is er iets met een update geweest waar dit door kan gebeuren? Ergens in 2021 is zoiets wel aan de hand geweest kwam ik achter na een zoektocht.

[lolgast]

@Arunia Ik heb geen oplossing voor je probleem want ik heb weinig ervaring met WSL en al helemaal niet icm Docker op de achtergrond.

Maar WSL images kun je 'gewoon' backuppen, dus daar zou ik eens mee beginnen voordat je alles weer opbouwd

code:

wsl export [distribution] [export path]

[Arunia]

@lolgast Dank je wel voor je reactie. Via WSL backuppen is inderdaad wel een goeie.

Ik ben de vm's wel tegengekomen van WSL. Wellicht dat er een andere map is waar het in staat en dat Docker Desktop ergens anders kijkt door een update. Who knows.
Ga daar ook nog eens in duiken. Gelukkig zijn het dingen waar ik wel even zonder kan. Alhoewel ik het wel ruk vind dat ik nu mijn kookboek hierdoor kwijt ben. Daar stond weer van alles in. Alhoewel die waarschijnlijk zichtbaar is in een map binnen Windows zelf. Dat zou dan nog iets schelen. Nope.
Enige wat ik vervelend vind om kwijt te raken was dus Mealie, mijn kookboek. Echt...

[ Voor 8% gewijzigd door Arunia op 11-06-2024 10:43 ]

[DjoeC]

Dit zo lezend, wat is de beste oplossing om Docker containers en/of daarbij behorende gegevens regelmatig en gestructureerd te backuppen? In mijn geval een Pi. Databases, configuraties, data is redelijk te doen via kopie naar een andere machine. Maar alles op een eenvoudige manier - liefst in 1 keer?

[Arunia]

Ik zie dat er net een update is en na voor het eerst in mijn leven een release note te hebben gelezen, staat er precies mijn probleem omschreven...

En alles is weer terug. Poeh, dat was even schrikken. Ben blij dat ik toch nog even naar de updates ben gaan kijken.

[Webgnome]

DjoeC schreef op dinsdag 11 juni 2024 @ 10:41:
Dit zo lezend, wat is de beste oplossing om Docker containers en/of daarbij behorende gegevens regelmatig en gestructureerd te backuppen? In mijn geval een Pi. Databases, configuraties, data is redelijk te doen via kopie naar een andere machine. Maar alles op een eenvoudige manier - liefst in 1 keer?

Je sources en je configs etc niet in de container op te slaan maar gewoon in een andere directory ergens op je schijf en die de backuppen net als de compose files. Althans zo doe ik t wil ik het doen. Alle config files netjes in een aparte map per project. Heb dat de basis al wel staan. Mijn RPI heeft ene /mnt/ssd/docker en daarin zit een map met bijvoorbeeld domoticz. Die map heeft in de root een docker-compose staan en dan naar gelang de services een map met de naam van de service met daarin de config files.

[DjoeC]

@Webgnome In de basis gebruik ik zoiets. Ik ben aan t herstructureren: Docker onder OMV-7. Daarbij een paar Shared dir's met configs, data, containers zelf. Da's natuurlijk wel te backuppen. Alleen, wat zal de (data)consistentie zijn van de backup van een draaiende container?

[lolgast]

Arunia schreef op dinsdag 11 juni 2024 @ 10:16:
@lolgast Dank je wel voor je reactie. Via WSL backuppen is inderdaad wel een goeie.

Ik ben de vm's wel tegengekomen van WSL. Wellicht dat er een andere map is waar het in staat en dat Docker Desktop ergens anders kijkt door een update. Who knows.
Ga daar ook nog eens in duiken. Gelukkig zijn het dingen waar ik wel even zonder kan. Alhoewel ik het wel ruk vind dat ik nu mijn kookboek hierdoor kwijt ben. Daar stond weer van alles in. Alhoewel die waarschijnlijk zichtbaar is in een map binnen Windows zelf. Dat zou dan nog iets schelen. Nope.
Enige wat ik vervelend vind om kwijt te raken was dus Mealie, mijn kookboek. Echt...

Hmm dat ziet er wel interessant uit. Mijn vrouw en ik gebruiken nu 'Receptenmaker', maar alles wat selfhosted ook kan is beter :-D

[Arunia]

@lolgast Mealie werkt erg lekker. Je kunt er (op de AH website na) best wel wat recepten webpagina's tegenaan smijten waarna Mealie zelf er een recept met ingredienten en stappen van maakt. Voordat je het er echt in zet, kun je nog editten waarbij je standaard voorloop spaties en wat nog meer gewoon uit kan laten halen.

[Webgnome]

DjoeC schreef op dinsdag 11 juni 2024 @ 11:09:
@Webgnome In de basis gebruik ik zoiets. Ik ben aan t herstructureren: Docker onder OMV-7. Daarbij een paar Shared dir's met configs, data, containers zelf. Da's natuurlijk wel te backuppen. Alleen, wat zal de (data)consistentie zijn van de backup van een draaiende container?

Container down -> backup -> container up?

[Mars Warrior]

DjoeC schreef op dinsdag 11 juni 2024 @ 11:09:
@Webgnome In de basis gebruik ik zoiets. Ik ben aan t herstructureren: Docker onder OMV-7. Daarbij een paar Shared dir's met configs, data, containers zelf. Da's natuurlijk wel te backuppen. Alleen, wat zal de (data)consistentie zijn van de backup van een draaiende container?

Een database backuppen al draaiend is natuurlijk een no-go: je weet nooit wat nog in de cache staat, of welke transactie/update nu loopt tijdens je backup van de files.

Ik doe altijd een export via de CLI van de database: dat kan voor MySQL/MariaDB en Postgress. En dan een aantal versies (dagen oid) bewaren.

Dat backuppen overigens kun je geheel automatisch via een Docker container (yep ) doen natuurlijk, inclusief interval en bewaarregels...

Docker DB Backup overigens kan CouchDB, InfluxDB, MySQL/MariaDB, Microsoft SQL, MongoDB, Postgres en Redis servers backuppen...

• dump to local filesystem or backup to S3 Compatible services, and Azure.
• multiple backup job support
• selectable when to start the first dump, whether time of day or relative to container start time
• selectable interval
• selectable omit scheduling during periods of time
• selectable database user and password
• selectable cleanup and archive capabilities
• selectable database name support - all databases, single, or multiple databases
• backup all to separate files or one singular file
• checksum support choose to have an MD5 or SHA1 hash generated after backup for verification
• compression support (none, gz, bz, xz, zstd)
• encryption support (passphrase and public key)
• notify upon job failure to email, matrix, mattermost, rocketchat, custom script
• zabbix metrics support
• hooks to execute pre and post backup job for customization purposes
• companion script to aid in restores

Dankzij de encryptie kun je de backups ook behoorlijk veilig extern opslaan en dankzij de notificatie blijven backup problemen niet onopgemerkt!

Ik doe overigens wel gewoon een backup van de database op basis van de files (ben lui). Maar als de restore daarvan niet lukt, dan heb ik dus altijd nog de echte database export.

[ Voor 47% gewijzigd door Mars Warrior op 11-06-2024 12:35 ]

[alex3305]

Webgnome schreef op dinsdag 11 juni 2024 @ 11:34:
Container down -> backup -> container up?

Dat vind ik echt onacceptabel.

Ik gebruik Kopia als backup oplossing en die backupt mijn Docker appdata netjes elke paar uur. Bij veel applicaties heb ik een .kopiaignore staan, met daarin de bestanden en mappen die niet meegenomen horen te worden. Bijvoorbeeld voor de *arr applicaties:

code:

*.db-shm
*.db-wal
*.pid
logs.db
asp
MediaCover
logs
Sentry

En Plex:

code:

.LocalAdminToken
Setup Plex.html
plexmediaserver.pid
transcode
Cache
Codecs
Crash Reports
Diagnostics
Drivers
Logs
Plug-in Support/Caches
Updates

Alle *arr applicaties maken zelf sowieso backups met een retentie van een aantal dagen. Die neem ik dan ook mee in mijn backups, maar ook de primaire database en config.xml. Dat gaat goed, inclusief restores.

Voor MariaDB, MySQL en PostgreSQL applicaties heb ik dump scripts die de database dumpt naar SQL bestanden. Die kun je dan naderhand ook weer eenvoudig inlezen. Voorbeeld:

Bash:

# MariaDB dump single database (ie. Spotweb)
docker exec -i spotweb-mariadb sh -c 'mariadb-dump -u"$DATABASE_USER" -p"$DATABASE_PASS" $DATABASE_NAME' > /opt/appdata/spotweb/database.sql

# MariaDB dump all (ie. Home Assistant)
docker exec -i homeassistant-mariadb sh -c 'mariadb-dump --all-databases' > /opt/appadata/homeassistant/database.sql

# PostgreSQL dump single database (ie. Paperless)
docker exec -i paperless-postgres /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dump --username=$POSTGRES_USER $POSTGRES_DB' > /opt/appadata/paperless/database.sql

# PostgreSQL dump all databases (ie. Outline)
docker exec -i outline-postgres /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /opt/appdata/outline/database.sql

Deze dumps maak ik dan per applicatie via een cronjob. Ik heb dan een .kopiaignore gemaakt voor databases, zodat de ruwe data niet meegenomen wordt. Bijvoorbeeld dit:

code:

database
!database.sql

En een restore voor Outline (Postgres) is dan zoiets:

Bash:

# Stop the database
docker stop outline-postgres

# Delete the current Postgres data and Redis cache
rm -rf /opt/appdata/outline/database/ /opt/appdata/outline/redis/

# Re-start the database
docker start outline-postgres

# Restore the dumped database through psql
docker exec -i outline-postgres /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD psql -U $POSTGRES_USER' < /opt/appdata/outline/database.sql

# Re-start Redis and Outline
docker start outline-redis outline

Dan hoeft de applicatie niet offline voor een backup. En omdat de sql bestanden in principe tekst bestanden zijn comprimeert en dedupliceert dat ook nog eens fantastisch in Kopia. Mijn Kopia backups sync in dan overigens ook weer naar externe locaties zodat ik altijd meerdere kopieën van mijn backups heb.

[Webgnome]

@alex3305 had je het gemist?

[alex3305]

Webgnome schreef op dinsdag 11 juni 2024 @ 12:36:
@alex3305 had je het gemist?

offtopic:
Ik kan niet ruiken welke subtekst jij bedoelt met een duiveltje. Wat mij betreft betekend dat gewoon lomp zijn, zoals je zelf suggereert .

[RobertMe]

Mars Warrior schreef op dinsdag 11 juni 2024 @ 12:20:
[...]

Een database backuppen al draaiend is natuurlijk een no-go: je weet nooit wat nog in de cache staat, of welke transactie/update nu loopt tijdens je backup van de files.

Dat is afhankelijk van de database die je gebruikt. Bv PostgreSQL gebruikt een Write-Ahead-Log. Elke wijziging wordt gelogd en daarna pas verwerkt. De WAL wordt in één write actie geupdate en is dus altijd consistent, en de wijzigingen van de database zelf kan die altijd replayen op basis van de WAL.
De PostgreSQL developers geven dan ook de garantie af dat je met een backup incl WAL altijd de database kunt "restoren". InfluxDB gebruikt ook een WAL en zou daardoor gelijk moeten zijn, maar zij doen geen uitspraken over een garanties.
MySQL daarentegen gebruikt uberhaupt geen WAL en geeft IIRC ook expliciet aan dat je altijd een dump moet maken.

[alex3305]

Mars Warrior schreef op dinsdag 11 juni 2024 @ 12:20:
[...]

Docker DB Backup overigens kan CouchDB, InfluxDB, MySQL/MariaDB, Microsoft SQL, MongoDB, Postgres en Redis servers backuppen...

Hier wil ik ook nog eens naar kijken. Mijn cronjob oplossing van boven werkt goed, maar staat los van de stack en is afhankelijk van het host OS. Dat voelt toch niet helemaal je-van-het. Ik wil eigenlijk gewoon een oplossing kunnen deployen in mijn (Compose) stack. Dat is m.i. ook wat minder onderhoudsgevoelig.

[DjoeC]

Webgnome schreef op dinsdag 11 juni 2024 @ 11:34:
[...]


Container down -> backup -> container up?

Tja... Dat kan en is voor sommige containers niet zo'n issue. Maar voor anderen (zoals Mosquitto) ligt dat natuurlijk anders - al is een backup daarvan maar heel beperkt qua duur/omvang.

Mars Warrior schreef op dinsdag 11 juni 2024 @ 12:20:
[...]

Een database backuppen al draaiend is natuurlijk een no-go: je weet nooit wat nog in de cache staat, of welke transactie/update nu loopt tijdens je backup van de files.

Ik doe altijd een export via de CLI van de database: dat kan voor MySQL/MariaDB en Postgress. En dan een aantal versies (dagen oid) bewaren.

Dat backuppen overigens kun je geheel automatisch via een Docker container (yep ) doen natuurlijk, inclusief interval en bewaarregels...

Docker DB Backup overigens kan CouchDB, InfluxDB, MySQL/MariaDB, Microsoft SQL, MongoDB, Postgres en Redis servers backuppen...

• dump to local filesystem or backup to S3 Compatible services, and Azure.
• multiple backup job support
• selectable when to start the first dump, whether time of day or relative to container start time
• selectable interval
• selectable omit scheduling during periods of time
• selectable database user and password
• selectable cleanup and archive capabilities
• selectable database name support - all databases, single, or multiple databases
• backup all to separate files or one singular file
• checksum support choose to have an MD5 or SHA1 hash generated after backup for verification
• compression support (none, gz, bz, xz, zstd)
• encryption support (passphrase and public key)
• notify upon job failure to email, matrix, mattermost, rocketchat, custom script
• zabbix metrics support
• hooks to execute pre and post backup job for customization purposes
• companion script to aid in restores

Dankzij de encryptie kun je de backups ook behoorlijk veilig extern opslaan en dankzij de notificatie blijven backup problemen niet onopgemerkt!

Ik doe overigens wel gewoon een backup van de database op basis van de files (ben lui). Maar als de restore daarvan niet lukt, dan heb ik dus altijd nog de echte database export.

toon volledige bericht

Mariadb (database deel) doe ik nu met Navicat scheduled tasks vanaf Windows. Niet alle schema's want elke keer 21GB over t netwerk backuppen vergt ook al snel een bak met tijd (4 minuten voor 2GB). Bij een restore van een 5GB schema werd m'n target SSD wel erg warm (50+ C.)

Eigenlijk zou er iets moeten zijn zoals VSS onder Windows.

De Backup container was ik ook al tegengekomen. Geen idee of die echt goed werkt maar ontkoppelt me natuurlijk wel van het aan hebben staan van de Windows PC.

[Mars Warrior]

RobertMe schreef op dinsdag 11 juni 2024 @ 12:41:
[...]

Dat is afhankelijk van de database die je gebruikt. Bv PostgreSQL gebruikt een Write-Ahead-Log. Elke wijziging wordt gelogd en daarna pas verwerkt. De WAL wordt in één write actie geupdate en is dus altijd consistent, en de wijzigingen van de database zelf kan die altijd replayen op basis van de WAL.
De PostgreSQL developers geven dan ook de garantie af dat je met een backup incl WAL altijd de database kunt "restoren". InfluxDB gebruikt ook een WAL en zou daardoor gelijk moeten zijn, maar zij doen geen uitspraken over een garanties.
MySQL daarentegen gebruikt uberhaupt geen WAL en geeft IIRC ook expliciet aan dat je altijd een dump moet maken.

Klopt. Ik had mijn post ook nog gewijzigd met "Ik doe overigens wel gewoon een backup van de database op basis van de files (ben lui). Maar als de restore daarvan niet lukt, dan heb ik dus altijd nog de echte database export."

En dat is gebaseerd op wat jij aangeeft, al heb ik dus ook al na een crash een Postgress database gehad die echt niet meer wilde restoren, ondanks de WAL.

MySQL / MariaDB zijn wat dat betreft pokke databases die ook na een herstart van een container wel eens willen crashen met een fatal error. Die moet ik dan een paar keer herstarten helaas

[Raven]

Arunia schreef op dinsdag 11 juni 2024 @ 10:47:
Ik zie dat er net een update is en na voor het eerst in mijn leven een release note te hebben gelezen, staat er precies mijn probleem omschreven...

En alles is weer terug. Poeh, dat was even schrikken. Ben blij dat ik toch nog even naar de updates ben gaan kijken.

https://github.com/docker/for-win/issues/14118 ? Er zijn er een aantal met dataverlies

[RobertMe]

Mars Warrior schreef op dinsdag 11 juni 2024 @ 12:47:
[...]

Klopt. Ik had mijn post ook nog gewijzigd met "Ik doe overigens wel gewoon een backup van de database op basis van de files (ben lui). Maar als de restore daarvan niet lukt, dan heb ik dus altijd nog de echte database export."

Die had ik inderdaad gemist.
En doe zelf ook beiden. "Officieel" doe ik een pg_dump, maar boel draait op ZFS en ik snapshot (en sync / send & receive) gewoon ook de data dir van PG.

En dat is gebaseerd op wat jij aangeeft, al heb ik dus ook al na een crash een Postgress database gehad die echt niet meer wilde restoren, ondanks de WAL.

Niet toevallig geprobeerd te gebruiken met een andere PG versie? PGs data format is namelijk maar compatible met 1 (major) versie en niet "upgradeable". Als je de files hebt moet je dus dezelfde major versie gebruiken om weer een werkende DB te krijgen.
Daarnaast is er IIRC ook nog een dingetje met file consistency. Het kan zijn dat er nog 1 of 2 additionele files bij de WAL hoorde en deze set aan files moet onderling consistent zijn. Iets dat ZFS snapshots kan garanderen. Maar als je gewoon tududuu de files doet kopieren kan het zijn dat dat file 2 wordt aangepast terwijl file 1 gekopieerd wordt in de oude state. Waardoor file 2 nieuwer is en mismatcht met file 1.

MySQL / MariaDB zijn wat dat betreft pokke databases die ook na een herstart van een container wel eens willen crashen met een fatal error. Die moet ik dan een paar keer herstarten helaas

Dat heb ik persoonlijk nog niet mee gemaakt. Maarja, MySQL / MariaDB...

[CSB]

Ik heb vandaag ook voor het eerst eens Docker geïnstalleerd. Ik rommel al een tijdje met Proxmox VE op een "oud" PC-tje waar nu een aantal containertjes op draaien (pihole, HAOS, etc.).

Ik had ook nog een oude game pc "over", waar nog een redelijke GPU in zit; een Asus RX 6650 TX. En ik wilde al een tijdje iets met Local LLM's gaan doen.

Heb nu dus Ubuntu 24.04 LTS baremetal draaien met daarop Ollama. Daarnaast draait nu dus ook Docker met wat ondersteunende containers (Portainer uiteraard, maar ook AnythingLLM en StableDiffusion) en alles draait en werkt best geinig. Echter: Ik heb (bijna) geen Linux ervaring, los van wat gerommel met een Raspberry Pi en ik voorzie een klein issue op redelijk korte termijn... Ik heb het geheel geinstalleerd op een SSD van 128 GB.

Nu zit er een extra SSD in van 256 GB en heb ik een nieuwe ext4 partitie toegevoegd, maar het probleem zit hem in het verplaatsen van de containers. Kan het uberhaubt?

Misschien is er een Linux guru die een n00b wat kan leren?

[Webgnome]

hier al gekeken?

Tja, dit helpt ook niet echt natuurlijk.

Tuurlijk zal de vraag op te zoeken zijn, maar de poster geeft wel aan dat hij noob en dus beginner is. Tuurlijk is eigen inzet gewenst, maar op een vriendelijke toon wat goede zoektermen meegeven zou in mijn ogen een wat betere reactie geweest zijn.

[ Voor 54% gewijzigd door Question Mark op 14-06-2024 11:29 ]

[Falcon]

Raven schreef op dinsdag 11 juni 2024 @ 12:50:
[...]

https://github.com/docker/for-win/issues/14118 ? Er zijn er een aantal met dataverlies

Het kwaliteitsproces bij dit dev team moet echt gewijzigd worden. Zoveelste keer dat er regressiebevindingen voordoen.

Terwijl Docker (Desktop) icm WSL2 in menig Dev team cruciaal is.

[Webgnome]

It looks like the WSL instance "docker-desktop-data" isn't used anymore. Instead AppData\Local\Docker\wsl\disk\docker_data.vhdx is hard coded?

I used to move the data to a different partition by using wsl --export and wsl --import, guess that's not going to work anymore and I will have an ever growing file on my system drive.

Iets met broek en afzakken en zo.

[alex3305]

@CSB Ja dat kan. Ik heb bijvoorbeeld toen ik Home Assistant nog op een Pi draaide, had ik mijn Docker data op een externe USB staan zodat de SD kaart niet overbelast raakte. Bij IBM staat een aardige uitleg hoe je de data-root zoals dat heet kunt verplaatsen. In mijn notes had ik het verkort zo staan:

Bash:

sudo -s

# Stop all containers and Docker
docker stop $(docker ps -aq)
systemctl stop docker

# Create new directory and copy everything over
mkdir -p /var/data/usb/docker
cp -p -r /var/lib/docker/* /var/data/usb/docker/

# Add docker root to dameon config
vim /etc/docker/daemon.json
# Add -> "data-root": "/var/data/usb/docker/"

# Start Docker
systemctl start docker

Waarbij /var/data/usb/ uiteraard de andere partitie was.