J'ai Wordpress fonctionnant dans Docker, pour le développement local, et c'est super lent. Mon docker-compose.yml ressemble à ceci:
version: '3.3'
services:
db:
image: mysql:5.7
volumes:
- ./db_data:/var/lib/mysql
- ./dbconfig.cnf:/etc/mysql/conf.d/custom.cnf
restart: always
ports:
- "3308:3306"
environment:
MYSQL_ROOT_PASSWORD: root_password
MYSQL_DATABASE: wp_database
MYSQL_USER: db_user
MYSQL_PASSWORD: some_secure_password
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "80:80"
- "443:443"
restart: always
volumes:
- ./wp-content:/var/www/html/wp-content
- ./.htaccess:/var/www/html/.htaccess
- ./wp-config.php:/var/www/html/wp-config.php
- ./logs/debug.log:/var/www/html/wp-content/debug.log
volumes:
db_data: {}
wp_content: {}
Pour autant que je lise en ligne, cela peut être la raison pour laquelle je monte le volume wp-content , qui provoque un chargement de page très lent (prend environ une demi-seconde pour charger chaque fichier, par exemple un fichier jquery, et il doit charger une tonne de fichiers pour une page).
Y a-t-il une solution pour cela? J'ai lu sur NFS, mais cela n'a pas fonctionné pour moi de configurer NFS avec docker-compose, d'une manière ou d'une autre, je continue à avoir des "erreurs d'autorisation". D'un autre côté, l'interface Docker de macOS me montre déjà un onglet "Dossier partagé" mais je ne sais pas si j'utilise ces dossiers partagés pour le moment ou si je les monte simplement à nouveau.
Aide est apprécié.
3 Réponses :
TL; DR Montez dans un dossier temporaire sur le conteneur, synchronisez ce dossier avec Bindfs dans le dossier du serveur public. Servir le site WP avec un montage direct est lent car le conteneur doit accéder aux fichiers hôte un par un, ce qui est un processus lourd. Servir à partir d'un dossier public alors que les fichiers font partie directement du conteneur est beaucoup plus rapide.
J'ai rencontré exactement le même problème avec WordPress local sur le développement de Docker Compose. Peu importe la vitesse de votre ordinateur, il sera toujours lent lors du montage des dossiers dans les conteneurs.
J'ai également essayé des solutions comme NFS et d'autres recommandations comme l'exclusion correcte du projet dans l'antivirus, l'ajout de .dockerignore, etc. qui au mieux n'améliorent que légèrement les performances.
En recherchant une amélioration de vitesse similaire, je suis tombé sur ce Dockerfile dans le référentiel WordPress Starter https://github.com/visiblevc/wordpress-starter/blob/master/Dockerfile . Si vous regardez ce fichier, vous verrez que la façon dont ils initialisent et montent le projet dans le conteneur est de le monter non pas dans, disons, / var / www / html / directement, mais dans un dossier temporaire à la place. Ensuite, ils synchronisent ce dossier temporaire avec / var / www / html / via bindfs. De cette façon, chaque fois que vous chargez une page WordPress dans le navigateur, ce sera extrêmement rapide car il n'aura pas à accéder et à lire les fichiers hôte à chaque demande. Les fichiers WordPress font partie du conteneur Linux. Lorsque vous apportez des modifications à votre code, ces modifications seront reflétées sur le dossier temporaire du conteneur et bindfs synchronisera instantanément ces modifications avec le dossier du conteneur public, et inversement. Toutes les modifications apportées au dossier public seront synchronisées avec le dossier temporaire, et de là vers vos fichiers de projet hôte.
Je ne peux pas voir où cela est fait dans le Dockerfile que vous suggérez.
La partie dont je parle se trouve dans le dernier bloc du fichier docker. Vous pouvez voir qu'il ajoute un utilisateur administrateur, ajuste les autorisations sur le dossier / app où vos fichiers hôtes WordPress seront montés, et enfin il ajoute un lien symbolique de / app vers / var / www / html avec la magie de bindfs.
Ce serait une 404
Il vous suffit de remonter le temps pour trouver le dépôt aux alentours de la date de publication pour trouver le fichier docker que @ArmanShahinyan suggère: github.com/visiblevc/wordpress-starter/blob/...
Merci pour la biche dans la bonne direction. Mais je n'ai pas utilisé bindfs car ce n'est pas si populaire et j'essaie d'éviter trop de dépendances de sources inconnues. Mais j'ai trouvé un programme avec une fonctionnalité similaire avec une syntaxe très simple: lsyncd --rsync / source / path / target / path . Bien que ce ne soit pas bidirectionnel. github.com/axkibe/lsyncd
Normalement, TL; DR serait en haut de votre message, pas en bas. Ce n'est pas très utile si quelqu'un lit l'intégralité de votre message puis rencontre la partie TL; DR à la fin. À ce stade, ils ont déjà tout lu et n'ont plus besoin de TL; DR partie.
J'ai rencontré le même problème, mais j'ai peut-être trouvé une solution.
Dans l'application de bureau Docker (en haut avec le temps, ressemble à une baleine)
Ouvrir les paramètres Sélectionnez Ressources \ Partage de fichiers
Ajoutez les dossiers appropriés. J'avais MySQL et les dossiers Wordpress dans le même dossier parent, alors j'ai ajouté cela.
Cliquez sur Appliquer et redémarrer.
Mon site Web s'est accéléré massivement.
J'espère que cela vous aidera.
N'a pas aidé du tout :( Exactement le même mauvais temps de chargement qu'avant dans mon cas. Pourriez-vous peut-être partager des captures d'écran ou des extraits de code de votre docker-compose.yml et / ou Dockerfile?
Sous Mac et Windows, il existe des problèmes de performances des volumes que nous devrions considérer.
J'ai fait des changements dans mon docker-compose.yml
Notez que j'ai changé le syntaxe courte à syntaxe longue .
Cette notation permet d'ajouter une option de cohérence .
J'ai ajouté wp-content et php-conf (pour obtenir php.ini) car il s'agit du répertoire de fichiers le plus souvent appelé à chaque fois qu'une page Wordpress est chargé dans le navigateur.
services:
wordpress:
...
volumes:
- ./data:/data
- ./scripts:/docker-entrypoint-initwp.d
#- ./wp-content:/app/wp-content
- type: bind
source: ./wp-content
target: /app/wp-content
consistency: cached
#- ./php-conf:/usr/local/etc/php
- type: bind
source: ./php-conf
target: /usr/local/etc/php
consistency: cached
