Background jobs per nextcloud #21

New Issue

giuliof · 2022-12-14T20:46:09Z

giuliof commented

2022-12-14 20:46:09 +00:00

Girovagando nella configurazione di nextcloud, ho notato che le attività in background vengono invocate ad ogni accesso pagina (metodo AJAX). Per istanze più grandi viene consigliato di usare cron, ma non so se il nostro container è predisposto per questo. Da valutare.

reference

Girovagando nella configurazione di nextcloud, ho notato che le attività in background vengono invocate ad ogni accesso pagina (metodo AJAX). Per istanze più grandi viene consigliato di usare cron, ma non so se il nostro container è predisposto per questo. Da valutare. [reference](https://docs.nextcloud.com/server/22/admin_manual/configuration_server/background_jobs_configuration.html)

lan-quil commented

2022-12-14 21:51:41 +00:00

Per reference, il mio docker-compose per nextcloud, in cui uso per l'appunto la soluzione con cron:

---
# https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/insecure/postgres/apache

version: '3.9'

networks:
    proxy:
        external: true
    internal:
        external: false

secrets:
    db_password:
        file: /srv/secrets/nextcloud/dbpwd

services:
    app:
        container_name: nextcloud
        image: nextcloud:25-apache
        restart: unless-stopped
        networks:
            - proxy
            - internal
        volumes:
            - /srv/volumes/nextcloud:/var/www/html
        secrets:
            - db_password
        environment:
            - POSTGRES_HOST=db
            - POSTGRES_DB=nextcloud
            - POSTGRES_USER=nextcloud
            - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
            - REDIS_HOST=redis
        depends_on:
            - db
            - redis
        labels:
            - traefik.enable=true
            - traefik.http.routers.nextcloud.rule=Host(`nextcloud.golem.linux.it`)
            - traefik.http.routers.nextcloud.entrypoints=websecure
            - traefik.http.routers.nextcloud.tls.certresolver=letsencrypt
            - traefik.http.services.nextcloud.loadbalancer.server.port=80
        ports:
            - 8001:80  # direct VPN access

    db:
        image: postgres:14
        restart: always
        networks:
            - internal
        volumes:
            - /srv/volumes/nextcloud-db:/var/lib/postgresql/data
        secrets:
            - db_password
        environment:
            - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
            - POSTGRES_DB=nextcloud
            - POSTGRES_USER=nextcloud

    redis:
        image: redis:alpine
        restart: always
        networks:
            - internal

    cron:
        image: nextcloud:stable
        restart: always
        networks:
            - internal
        depends_on:
            - db
            - redis
        volumes:
            - /srv/volumes/nextcloud:/var/www/html
        entrypoint: /cron.sh

Per reference, il mio docker-compose per nextcloud, in cui uso per l'appunto la soluzione con cron: ```yaml --- # https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/insecure/postgres/apache version: '3.9' networks: proxy: external: true internal: external: false secrets: db_password: file: /srv/secrets/nextcloud/dbpwd services: app: container_name: nextcloud image: nextcloud:25-apache restart: unless-stopped networks: - proxy - internal volumes: - /srv/volumes/nextcloud:/var/www/html secrets: - db_password environment: - POSTGRES_HOST=db - POSTGRES_DB=nextcloud - POSTGRES_USER=nextcloud - POSTGRES_PASSWORD_FILE=/run/secrets/db_password - REDIS_HOST=redis depends_on: - db - redis labels: - traefik.enable=true - traefik.http.routers.nextcloud.rule=Host(`nextcloud.golem.linux.it`) - traefik.http.routers.nextcloud.entrypoints=websecure - traefik.http.routers.nextcloud.tls.certresolver=letsencrypt - traefik.http.services.nextcloud.loadbalancer.server.port=80 ports: - 8001:80 # direct VPN access db: image: postgres:14 restart: always networks: - internal volumes: - /srv/volumes/nextcloud-db:/var/lib/postgresql/data secrets: - db_password environment: - POSTGRES_PASSWORD_FILE=/run/secrets/db_password - POSTGRES_DB=nextcloud - POSTGRES_USER=nextcloud redis: image: redis:alpine restart: always networks: - internal cron: image: nextcloud:stable restart: always networks: - internal depends_on: - db - redis volumes: - /srv/volumes/nextcloud:/var/www/html entrypoint: /cron.sh ```

gbiotti commented

2022-12-15 10:24:37 +00:00

Premetto che sto parlando della mia istanza che gira sulla Raspberry.

Come Giulio e Giomba sanno ho recentemente avuto una serie di interruzioni di alimentazione (temporale notturno) che hanno totalmente incasinato il disco.

Dopo una serie di fsck sono riuscito a rendere il disco relativamente stabile per poterci leggere e recuperare il recuperabile.

Ho quindi usato un altro disco per reinstallare tutto da campo. Questa volta, invece di fare l'inistallazione di NextcloudPi direttamente sul sistema ho deciso di usare docker (tramite Portainer).

Ho quindi installato l'immagine e ripristinato in qualche modo sia il db che i files. Devo ancora finire di mettere a punto la configurazione e renderle accessibile da internet, ma direi che l'istanza e' funzionante (forse tra qualche anno dovro' accedere a qualche file che dara' errore, ma tanto vale).

Quello pero' che ho notato e' che, usando l'immagine ufficiale che si trova sull'hub docker, l'impostazione del tipo gestione dei processi schedulati interni a Nextcloud e' gestibile direttamente dall'interfaccia web senza dover fare niente nella configurazione del dockerfile.

Io mi sono trovato l'opzione su Cron dopo aver ripristinato il db dalla vecchia istanza. Non ricordo se ho cambiato io l'impostazione o nel tempo hanno cambiato il default loro.

Ad ogni modo non credo ci sia da fare niente a livello di dockerfile. Allego screenshot.

Premetto che sto parlando della mia istanza che gira sulla Raspberry. Come Giulio e Giomba sanno ho recentemente avuto una serie di interruzioni di alimentazione (temporale notturno) che hanno totalmente incasinato il disco. Dopo una serie di fsck sono riuscito a rendere il disco relativamente stabile per poterci leggere e recuperare il recuperabile. Ho quindi usato un altro disco per reinstallare tutto da campo. Questa volta, invece di fare l'inistallazione di NextcloudPi direttamente sul sistema ho deciso di usare docker (tramite Portainer). Ho quindi installato l'immagine e ripristinato in qualche modo sia il db che i files. Devo ancora finire di mettere a punto la configurazione e renderle accessibile da internet, ma direi che l'istanza e' funzionante (forse tra qualche anno dovro' accedere a qualche file che dara' errore, ma tanto vale). Quello pero' che ho notato e' che, usando l'immagine ufficiale che si trova sull'hub docker, l'impostazione del tipo gestione dei processi schedulati interni a Nextcloud e' gestibile direttamente dall'interfaccia web senza dover fare niente nella configurazione del dockerfile. Io mi sono trovato l'opzione su Cron dopo aver ripristinato il db dalla vecchia istanza. Non ricordo se ho cambiato io l'impostazione o nel tempo hanno cambiato il default loro. Ad ogni modo non credo ci sia da fare niente a livello di dockerfile. Allego screenshot.

NextcloudPi_BackgroundJobs.jpg

35 KiB

giomba commented

2022-12-15 21:59:31 +00:00

Appurato che si tratta di una cosa che va fatta, vorrei capire meglio cosa fa questo: è un microservizio a parte che in qualche modo si collega al database e periodicamente esegue i cron jobs?

    cron:
        image: nextcloud:stable
        restart: always
        networks:
            - internal
        depends_on:
            - db
            - redis
        volumes:
            - /srv/volumes/nextcloud:/var/www/html
        entrypoint: /cron.sh

Se comunque si tratta di modificare solo qualche riga nel docker-compose.yml sono molto più felice rispetto a dover fare un'immagine personalizzata da metterla nel registry, altrimenti diventa l'ennesima cosa da mantenere.

Comunque, per quanto possa valere, mi sembrava di aver già attivato i cron jobs, insieme a n-altre cose che ti suggerisce in warning nel pannello di amministrazione, ma forse si è rotto qualcosa durante qualche aggiornamento.

Appurato che si tratta di una cosa che **va** fatta, vorrei capire meglio cosa fa questo: è un microservizio a parte che in qualche modo si collega al database e periodicamente esegue i cron jobs? > ``` > cron: > image: nextcloud:stable > restart: always > networks: > - internal > depends_on: > - db > - redis > volumes: > - /srv/volumes/nextcloud:/var/www/html > entrypoint: /cron.sh > ``` Se comunque si tratta di modificare solo qualche riga nel `docker-compose.yml` sono molto più felice rispetto a dover fare un'immagine personalizzata da metterla nel registry, altrimenti diventa l'ennesima cosa da mantenere. Comunque, per quanto possa valere, mi sembrava di aver già attivato i cron jobs, insieme a n-altre cose che ti suggerisce in warning nel pannello di amministrazione, ma forse si è rotto qualcosa durante qualche aggiornamento.

giuliof commented

2022-12-16 21:15:33 +00:00

Mi sono permesso di spulciare un po' nell'immagine stock di nextcloud e nel nostro container:

Sia l'immagine debian che alpine (non ricordo quale delle due usiamo, ma è irrilevante) attivano a prescindere il cron per l'utente www-data, invocando ogni 5 minuti il file cron.php (ref);
Il cron.php controlla se l'impostazione dei background jobs fatta dai settings web è effettivamente "cron", altrimenti schianta lì;
Sul nostro container il file "/var/spool/cron/crontabs/www-data" è effettivamente popolato come ci si aspetterebbe per un cron funzionante.

Quindi, ha ragione @gbiotti, dovrebbe essere già tutto pronto out-of-the-box e non dovremmo aver problemi a switchare.
Per me si può fare anche martedì, almeno siamo in compagnia se il container dovesse andare a fuoco :D

Mi sono permesso di spulciare un po' nell'immagine stock di nextcloud e nel nostro container: * Sia l'immagine debian che alpine (non ricordo quale delle due usiamo, ma è irrilevante) attivano a prescindere il cron per l'utente www-data, invocando ogni 5 minuti il file cron.php ([ref](https://github.com/nextcloud/docker/blob/e3c4b823e31c55dc7d908f591a51c947535cee78/Dockerfile-alpine.template)); * Il cron.php controlla se l'impostazione dei background jobs fatta dai settings web è effettivamente "cron", altrimenti schianta lì; * Sul nostro container il file "/var/spool/cron/crontabs/www-data" è effettivamente popolato come ci si aspetterebbe per un cron funzionante. Quindi, ha ragione @gbiotti, dovrebbe essere già tutto pronto out-of-the-box e non dovremmo aver problemi a switchare. Per me si può fare anche martedì, almeno siamo in compagnia se il container dovesse andare a fuoco :D

gbiotti commented

2023-05-31 15:48:10 +00:00

Riprendo.
Effettivamente, usando docker, la cosa deve essere portata avanti in modo diverso dal setup standard su host fisico.

Come dice @giuliof dal punto di vista dell'applicazione nextcloud tutto e' configurato correttamente, e effettivamente se si installa nextcloud su di una macchina (senza usare docker) tutto funziona, ma in realta' nell'immagine docker non c'e' cron e quindi non funzionera'.

Per questa cosa pare ci siano diverse soluzioni, tra cui quella riportata da @lanquil che usa un altro "servizio" per cron nel docker-compose; sarebbe anche possibile (anche se da ignorante non mi piace) eseguire il comando php via docker exec direttamente con cron sulla macchina host.

Riporto qui, a futura memoria, qualche link utile:
Nextcloud Docker Container - best way to run cron job
Docker setup & cron
Issue su github - Background jobs: Cron does not run #1695 in particolare questo commento alla issue.

Riprendo. Effettivamente, usando docker, la cosa deve essere portata avanti in modo diverso dal setup standard su host fisico. Come dice @giuliof dal punto di vista dell'applicazione nextcloud tutto e' configurato correttamente, e effettivamente se si installa nextcloud su di una macchina (senza usare docker) tutto funziona, ma in realta' nell'immagine docker non c'e' `cron` e quindi non funzionera'. Per questa cosa pare ci siano diverse soluzioni, tra cui quella riportata da @lanquil che usa un altro "servizio" per `cron` nel docker-compose; sarebbe anche possibile (anche se da ignorante non mi piace) eseguire il comando `php` via `docker exec` direttamente con `cron` sulla macchina host. Riporto qui, a futura memoria, qualche link utile: [Nextcloud Docker Container - best way to run cron job](https://help.nextcloud.com/t/nextcloud-docker-container-best-way-to-run-cron-job/157734) [Docker setup & cron](https://help.nextcloud.com/t/docker-setup-cron/78547) [Issue su github - Background jobs: Cron does not run #1695](https://github.com/nextcloud/docker/issues/1695) in particolare [questo commento](https://github.com/nextcloud/docker/issues/1695#issuecomment-1043312667) alla issue.

giuliof commented

2023-06-05 18:40:50 +00:00

Come dice @giuliof dal punto di vista dell'applicazione nextcloud tutto e' configurato correttamente, e effettivamente se si installa nextcloud su di una macchina (senza usare docker) tutto funziona, ma in realta' nell'immagine docker non c'e' cron e quindi non funzionera'.

Io speravo tanto che fosse tutto già pronto, sigh.

Per questa cosa pare ci siano diverse soluzioni, tra cui quella riportata da @lanquil che usa un altro "servizio" per cron nel docker-compose; sarebbe anche possibile (anche se da ignorante non mi piace) eseguire il comando php via docker exec direttamente con cron sulla macchina host.

Quella di invocare il comando direttamente dall'host è una soluzione sicuramente brutta, ma magari più efficiente in risorse. Ho fatto notare in #16 che non siamo proprio larghi in ram, e spawnare l'ennesima immagine in più mi infastidisce.
Comunque, non mi oppongo a fare una prova anche nell'altro senso, ovvero aggiungendo il container parallelo, è effettivamente più pulito. Al solito, si tiene il server sott'occhio per un po' e se tutto va liscio si lascia così.

> Come dice @giuliof dal punto di vista dell'applicazione nextcloud tutto e' configurato correttamente, e effettivamente se si installa nextcloud su di una macchina (senza usare docker) tutto funziona, ma in realta' nell'immagine docker non c'e' `cron` e quindi non funzionera'. Io speravo tanto che fosse tutto già pronto, sigh. > Per questa cosa pare ci siano diverse soluzioni, tra cui quella riportata da @lanquil che usa un altro "servizio" per `cron` nel docker-compose; sarebbe anche possibile (anche se da ignorante non mi piace) eseguire il comando `php` via `docker exec` direttamente con `cron` sulla macchina host. Quella di invocare il comando direttamente dall'host è una soluzione sicuramente brutta, ma magari più efficiente in risorse. Ho fatto notare in #16 che non siamo proprio larghi in ram, e spawnare l'ennesima immagine in più mi infastidisce. Comunque, non mi oppongo a fare una prova anche nell'altro senso, ovvero aggiungendo il container parallelo, è effettivamente più pulito. Al solito, si tiene il server sott'occhio per un po' e se tutto va liscio si lascia così.

Sign in to join this conversation.