Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

Pages : 1

#1 Le 13/12/2024, à 08:34

alex2423

Nexcloud avec Docker - le volume n'est pas persistant

Bonjour,

Par curiosité, j'ai voulu installé Installer via Docker Composer.

Comme suggérer par la documentation officiel, je me suis créer un fichier docker-compose.yml avec le contenu suivant 

volumes:
  nextcloud:
  db:

services:
  db:
    image: mariadb:10.6
    restart: always
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root_pass
      - MYSQL_PASSWORD=pass
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    restart: always
    ports:
      - 8080:80
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=pass
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

Puis je lance 

root@nextcloud:~# docker compose up
[+] Running 2/0
 ✔ Container root-db-1   Created                                                                                                                                                                             0.0s 
 ✔ Container root-app-1  Created                                                                                                                                                                             0.0s 
Attaching to app-1, db-1
db-1   | 2024-12-13 07:12:08+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.6.2+maria~ubu2404 started.
db-1   | 2024-12-13 07:12:08+00:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB
db-1   | 2024-12-13 07:12:08+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
db-1   | 2024-12-13 07:12:08+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.6.2+maria~ubu2404 started.
app-1  | => Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/before-starting
app-1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.3. Set the 'ServerName' directive globally to suppress this message
app-1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.3. Set the 'ServerName' directive globally to suppress this message
app-1  | [Fri Dec 13 07:12:08.653615 2024] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) PHP/8.2.26 configured -- resuming normal operations
app-1  | [Fri Dec 13 07:12:08.653651 2024] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
db-1   | 2024-12-13 07:12:08+00:00 [Note] [Entrypoint]: MariaDB upgrade not required
db-1   | 2024-12-13  7:12:08 0 [Note] Starting MariaDB 11.6.2-MariaDB-ubu2404-log source revision d8dad8c3b54cd09fefce7bc3b9749f427eed9709 server_uid 72+4ASMvYxproTQgRqIDplDA1XA= as process 1
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Compressed tables use zlib 1.3
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Number of transaction pools: 1
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
db-1   | 2024-12-13  7:12:08 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
db-1   | 2024-12-13  7:12:08 0 [Warning] mariadbd: io_uring_queue_init() failed with errno 95
db-1   | 2024-12-13  7:12:08 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Completed initialization of buffer pool
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: End of log at LSN=3636331
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Opened 3 undo tablespaces
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: log sequence number 3636331; transaction id 5956
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
db-1   | 2024-12-13  7:12:08 0 [Note] Plugin 'FEEDBACK' is disabled.
db-1   | 2024-12-13  7:12:08 0 [Note] Plugin 'wsrep-provider' is disabled.
db-1   | 2024-12-13  7:12:08 0 [Note] InnoDB: Buffer pool(s) load completed at 241213  7:12:08
db-1   | 2024-12-13  7:12:10 0 [Note] Server socket created on IP: '0.0.0.0'.
db-1   | 2024-12-13  7:12:10 0 [Note] Server socket created on IP: '::'.
db-1   | 2024-12-13  7:12:10 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
db-1   | 2024-12-13  7:12:10 0 [Note] mariadbd: ready for connections.
db-1   | Version: '11.6.2-MariaDB-ubu2404-log'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
app-1  | 192.168.1.99 - - [13/Dec/2024:07:13:31 +0000] "POST / HTTP/1.1" 302 1411 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"
app-1  | 192.168.1.99 - - [13/Dec/2024:07:13:42 +0000] "GET /index.php/core/apps/recommended HTTP/1.1" 200 7366 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"
app-1  | 192.168.1.99 - - [13/Dec/2024:07:13:42 +0000] "GET /dist/core-recommendedapps.js?v=19256074-0 HTTP/1.1" 200 5331 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"
app-1  | 192.168.1.99 - - [13/Dec/2024:07:13:42 +0000] "GET /apps/theming/css/default.css?v=60ca31af-0 HTTP/1.1" 200 2208 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"
app-1  | 192.168.1.99 - - [13/Dec/2024:07:13:42 +0000] "GET /apps/theming/theme/light.css?plain=1&v=692df570 HTTP/1.1" 200 2061 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"

Je me rends sur NextCloud via son adresse ip, par exemple : http://192.168.1.20:8080. On me demande de créer un compte admin, et ensuite NextCloud se configure automatiquement.

Mais je ne vois aucun fichier dans mon volume /var/www/html

root@nextcloud:/var/www/html# ls -l
total 0
root@nextcloud:/var/www/html#

Or tel que j'avais compris dans la documentation, mes données d'installation sont supposées êtres accessible depuis l'extérieur afin d'être persistante. Lorsque j'arrête puis je reconstrui le conteneur (avec l'option up), j'ai bien entendu tout perdu, et je dois refaire la configuration du compte admin.

Hors ligne

#2 Le 13/12/2024, à 09:13

kastopidiak

Re : Nexcloud avec Docker - le volume n'est pas persistant

Bonjour,

    volumes:
      - nextcloud:/var/www/html

Cela signifie que le volume nextcloud est monté dans le conteneur sur /var/www/html et non l'inverse. Autrement dit les données sont sur l'hôte dans le répertoire nextcloud.
Comme le chemin est relatif le répertoire nextcloud doit se trouver dans celui où est le fichier docker-compose.

De même la base de données est dans le dossier db de l'hôte qui est monté sur /var/lib/mysql dans le conteneur.

Ainsi ni la configuration, les utilisateurs et leurs données ne devraient pas être perdues lors d'un redémarrage du conteneur. Quelles commandes ont été utilisées ?


Réf :
https://docs.docker.com/reference/compose-file/volumes/

Dernière modification par kastopidiak (Le 13/12/2024, à 09:19)

Hors ligne

#3 Le 13/12/2024, à 10:55

alex2423

Re : Nexcloud avec Docker - le volume n'est pas persistant

kastopidiak a écrit :

Bonjour,

    volumes:
      - nextcloud:/var/www/html

Cela signifie que le volume nextcloud est monté dans le conteneur sur /var/www/html et non l'inverse. Autrement dit les données sont sur l'hôte dans le répertoire nextcloud.
Comme le chemin est relatif le répertoire nextcloud doit se trouver dans celui où est le fichier docker-compose.

Ok je comprends /var/www/html correspond au chemin dans le conteneur.

Je suis dans le répertoire home de root pour tester avec le fichier docker-compose. J'y ai du coup créé 2 répertoires db et nextcloud correspond au 2 répertoires relatifs. 

root@nextcloud:~# pwd
/root
root@nextcloud:~# ls -l
total 20
drwxr-xr-x 2 root root 4096 Dec 13 08:49 db
-rw-r--r-- 1 root root  664 Dec 13 09:16 docker-compose.yml
-rw-r--r-- 1 root root  664 Dec 13 09:05 docker-compose.yml.backup
-rw-r--r-- 1 root root  656 Dec 13 09:16 docker-compose.yml.mapping
drwxr-xr-x 2 root root 4096 Dec 13 08:49 nextcloud
root@nextcloud:~# docker compose up -d
[+] Running 2/2
 ✔ Container root-db-1   Started                                                                                                                                                                             0.3s 
 ✔ Container root-app-1  Started                                                                                                                                                                             0.5s 
root@nextcloud:~#

Mais malheureusement, cela ne fonctionne toujours pas. Je n'ai pas de fichier qui s'inscrive dans le sous dossier nextcloud.


kastopidiak a écrit :

Ainsi ni la configuration, les utilisateurs et leurs données ne devraient pas être perdues lors d'un redémarrage du conteneur. Quelles commandes ont été utilisées ?

J'ai créé le fichier doker-compose, puis immédiatement après j'ai lancé docker compose up dans le répertoire ou se trouve le fichier.



Mais j'ai l'impression qu'il y a 2 possibilités d'avoir un volume permanent.
Soit par un volume mappé, on précisé directement la source et la destination
Soit par un volume managé. Et là, il faudrait tel que je comprends, créer en amont le volume, le nommer, puis ensuite créer le point de montage avec le répertoire source et destination. 

docker run --mount type=volume,src=<volume-name>,dst=<mount-path>

https://docs.docker.com/engine/storage/ … bdirectory

La documentation sur les volumes managés :
https://www.nicelydev.com/docker/volume … ocker#h2_4

J'ai réussi à résoudre mon problème via la première option, en précisant directement les répertoires locaux. Ce n'est peut être pas la solution la plus propre, mais cela a le mérite de marcher et de m'éviter de m'arracher tous les cheveux 

root@nextcloud:~# cat docker-compose.yml
services:
  db:
    image: mariadb
    restart: always
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
    volumes:
      - /var/lib/mysql:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root_pass
      - MYSQL_PASSWORD=pass
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    restart: always
    ports:
      - 8080:80
    links:
      - db
    stdin_open: true
    tty: true
    volumes:
      - /var/www/nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=pass
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db
root@nextcloud:~#

Dernière modification par alex2423 (Le 13/12/2024, à 10:59)

Hors ligne

#4 Le 13/12/2024, à 11:23

kastopidiak

Re : Nexcloud avec Docker - le volume n'est pas persistant

Désole j'ai dis une bêtise sur l'emplacement des volumes en relatif. Il sont sous : /var/lib/docker/volumes/
Soit dans ton cas /var/lib/docker/volumes/nextcloud et /var/lib/docker/volumes/db

Tu peux utiliser les emplacements absolus comme tu l'as fait. C'est effectivement souvent plus pratique que d'aller chercher les données sous /var/lib/docker.


Par contre attention avec cette ligne :

/var/lib/mysql:/var/lib/mysql

si tu installes un serveur MySQL sur l'hôte tes base de données seront écrasées, car c'est le répertoire par défaut pour MySQL !
Il vaudrait mieux utiliser un autre emplacement, par exemple :

/var/lib/db-nextcloud:/var/lib/mysql

.

De manière général il ne faut surtout pas définir des volumes susceptibles d'être utilisés par le système hôte ou d'autre conteneurs.

Pour relancer proprement un conteneur il faut l'arrêter (stop), le supprimer (rm) peuis le lancer (up). Il existe aussi une commande restart avec docker-compose

Pour installer un serveur Nextcloud il peut être plus simple et plus prudent de ne pas passer par docker. Cette doc me paraît relativement correcte : https://doc.ubuntu-fr.org/nextcloud-serveur

Hors ligne

#5 Le 13/12/2024, à 14:20

alex2423

Re : Nexcloud avec Docker - le volume n'est pas persistant

kastopidiak a écrit :

Désole j'ai dis une bêtise sur l'emplacement des volumes en relatif. Il sont sous : /var/lib/docker/volumes/
Soit dans ton cas /var/lib/docker/volumes/nextcloud et /var/lib/docker/volumes/db
Tu peux utiliser les emplacements absolus comme tu l'as fait. C'est effectivement souvent plus pratique que d'aller chercher les données sous /var/lib/docker.

En effet quand on regarde la liste des points de montage puis que l'on inspect, le point de montage par défaut est toujours dans /var/lib/docker/volumes/. Je m'étais entrainé à créer un volume supplémentaire super_volume, et toujours au même endroit. 

root@nextcloud:/var/www/nextcloud/data# docker volume ls      
DRIVER    VOLUME NAME
local     9f55d62eea65c0f61f505fd1d6901da6e988c270d52f09f692b5a50b87ab73cf
local     root_db
local     root_nextcloud
local     super_volume
root@nextcloud:/var/www/nextcloud/data# docker volume inspect root_nextcloud
[
    {
        "CreatedAt": "2024-12-12T22:23:03Z",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "root",
            "com.docker.compose.version": "2.31.0",
            "com.docker.compose.volume": "nextcloud"
        },
        "Mountpoint": "/var/lib/docker/volumes/root_nextcloud/_data",
        "Name": "root_nextcloud",
        "Options": null,
        "Scope": "local"
    }
]




kastopidiak a écrit :

Par contre attention avec cette ligne :

/var/lib/mysql:/var/lib/mysql

si tu installes un serveur MySQL sur l'hôte tes base de données seront écrasées, car c'est le répertoire par défaut pour MySQL !
Il vaudrait mieux utiliser un autre emplacement, par exemple :

/var/lib/db-nextcloud:/var/lib/mysql

.

De manière général il ne faut surtout pas définir des volumes susceptibles d'être utilisés par le système hôte ou d'autre conteneurs.

Alors j'aimerais bien mutualiser la base de donnée plutot que de créer "bêtement" une base à chaque fois.
J'aimerai bien à l'avenir installer un piwigo. Je pense qu'il s'agit d'une bonne pratique avec des comptes utilisateurs différents.


kastopidiak a écrit :

Pour relancer proprement un conteneur il faut l'arrêter (stop), le supprimer (rm) peuis le lancer (up). Il existe aussi une commande restart avec docker-compose

Merci pour le rappel. smile

kastopidiak a écrit :

Pour installer un serveur Nextcloud il peut être plus simple et plus prudent de ne pas passer par docker. Cette doc me paraît relativement correcte : https://doc.ubuntu-fr.org/nextcloud-serveur

C'est ce que je faisais justement sur mon raspberry, j'installé un Ngnix, un PHP et son pilote fmp, un mariadb, créé un virtual host puis j'y déposais les pages PHP de nextCloud.
Et puis pour mon piwigo, j'y créé un 2ème virtual host.

Mais j'ai voulu me mettre un peu à la mode. On n'arrète pas de parler de docker.
Je suis passé au mini pc, et je me suis dis pourquoi faire le truc à la mode.

Il est certain que je vais galérer un peu

Dernière modification par alex2423 (Le 13/12/2024, à 14:21)

Hors ligne

#6 Le 13/12/2024, à 15:35

kastopidiak

Re : Nexcloud avec Docker - le volume n'est pas persistant

C'est c'est juste par effet de mode, c'est absurde. Si c'est dans un but didactique pourquoi pas.

Tu vas te compliquer la vie, gaspiller des ressources et rendre ton système moins sûr. Les images ocker contiennent parfois de nombreuses vulnérabilités, exemple pour nextcloud et la version de maraidb utilisée.
il faut donc les mettre à jour régulièrement et même s'il existe des outils pour automatiser ces tâches de maintenance(*) cela rajoute encore une couche de complexité et on est loin du confort des mises à jour automatiques des paquets.

Si tu veux cloisonner les services web il faut un utilisateur différent pour chaque service. Avec php-fpm et ses pools cela se fait relativement facilement.

--
(*) vérifier régulièrement si une image plus à jour est disponible ; arrêter le conteneur, détruire le conteneur, le relancer.

Hors ligne

Pages : 1