Indietro

questo il mio docker-compose.yml:

networks:
   cloudflared:
     external: true
   postgres:
     external: true

 services:
   museum:
     environment:
       - "ENTE_CREDENTIALS_FILE=/credentials.yaml"
     image: "ghcr.io/ente-io/server"
     networks:
       - "postgres"
       - "cloudflared"
     restart: "unless-stopped"
     volumes:
       - "/mnt/ssd/docker/ente/credentials.yaml:/credentials.yaml:ro"
       - "/mnt/ssd/docker/ente/custom-logs:/var/logs"
       - "/mnt/ssd/docker/ente/data:/data:ro"
       - "/mnt/ssd/docker/ente/museum.yaml:/museum.yaml:ro"

   photo-backup:
     image: "ente-photo-backup:latest"
     network_mode: "bridge"
     restart: "unless-stopped"
     volumes:
       - "/mnt/ssd/docker/ente/cli-data:/cli-data"
       - "/mnt/ssd/docker/ente/config.yaml:/config.yaml"
       - "/mnt/ssd/docker/ente/ente:/ente"
       - "/mnt/hdd/Backups/ente:/backup"

   postgresente:
     environment:
       - "POSTGRES_USER=pguser"
       - "POSTGRES_PASSWORD=pgpass"
       - "POSTGRES_DB=ente_db"
     image: "postgres:15"
     networks:
       - "postgres"
     restart: "unless-stopped"
     volumes:
       - "/mnt/ssd/docker/ente/postgres-data:/var/lib/postgresql/data"

   web-build:
     image: "ente-web-builder:latest"
     network_mode: "bridge"
     restart: "unless-stopped"
     volumes:
       - "/mnt/ssd/docker/caddy/ente-web:/output"
       - "/mnt/ssd/docker/ente/build-web.sh:/build-web.sh"

note:

1. all’epoca il client web non lo facevano preconfezionato in una pratica immagine docker ma era “che ci vuole basta compilarlo da soli con node” - quindi feci un’immagine locale ente-web-builder che chiamo tutte le domeniche per rifarmi la compilazione, poi la servo con caddy. Ho accidentalmente eliminato il Dockerfile, quindi devo fare un po’ di reverse engineering per capire cosa ho fatto l’anno scorso. Si può usare la loro immagine docker che però se ho capito bene usa node serve - un po’ assurdo usare node per hostare delle pagine statiche. Da maniaco dell’efficienza lo rifeci con Caddy.

2. photo-backup è un’immagine docker fatta da me che tutte le domeniche usa ente-cli per scaricare il backup di tutte le foto di tutti gli utenti. Ho accidentalmente eliminato il Dockerfile quindi devo fare un po’ di reverse engineering per capire cosa feci l’anno scorso

3. supponendo che il client web lo si pubblichi su photo.example.com,

4. bisogna creare museum.yaml e scriverci

apps:
      public-albums:  "https://photo.example.com/"
e poi le key encryption, hash, jwt secret, i dati smtp, e poi volendo quali id utenti sono admin

5. supponendo che museum lo si pubblichi su api.example.com,

6. bisogna creare config.yaml e scriverci

endpoint:
      api: "https://api.example.com/"

7. non uso minio ma un server s3 esterno, questo va configurato in credentials.yml

in pratica sono questi 4 componenti:

1. museum: sono le API che fanno parlare le app web e android/ios/windows/linux col database e col server s3
2. postgres: contiene le path su s3 di ogni immagine (da fare backup frequenti)
3. web: sono pagine statiche html+javascript che mostrano le immagini disponibili sul server. Opzionale, volendo uno può anche usare solo le app
4. minio: è un server s3 compatibile che mantiene tutti i dati. Si può anche usare garage o server di altri. Personalmente uso b2 di backblaze.

backup strategy:

1. prima copio tutte le immagini di tutti gli utenti con ente-cli - le ritrovo tutte decriptate in jpg normali esattamente come furono caricate
2. poi copio il contenuto del bucket s3 (che è criptato e quindi di per sé non è che sia utilissimo, è che in caso di disastro il recupero è più veloce non dovendo ricominciare da zero dal backup delle immagini sfuse)
3. poi faccio il backup di postgres che contiene le chiavi di criptazione di ogni immagine contenuta nel bucket s3 (quindi se fai il backup del bucket ma senza postgres, è solo uno spreco di spazio, perché non lo puoi decrittare - anche qui è per velocizzare un eventuale recupero dopo disastro)