Containeuriser VueJS

a marqué ce sujet comme résolu.

Bonjour à tous,

Version la plus récente de l’OP

Je suis confronté à un problème étrange avec ma webapp vuejs.

  • Si j’utilise : npm run serve, alors il va lancer le serveur vuejs dev et il faire le rendu correctement des fichiers construits.
  • Si j’utilise docker : il lance le serveur dev vuejs, puis construit les fichiers, mais il fera le rendu d’une ancienne version des fichiers construits !

Un autre comportement étrange est :

  • Lorsque j’exécute npm run serve, alors mes modifications de code VueJS en direct seront rebuilt en direct. (attendu)
  • Mais si j’utilise Docker, alors mes modifications de code VueJS en direct ne seront pas rebuilt (comportement réel et non-prévu).

Le Dockerfile de VueJS que j’ai écrit est :

FROM node:14-alpine

WORKDIR /src

COPY package*.json ./

Lancer npm install

VOLUME /src

EXPOSE 8080

CMD ["npm", "run", "serve"] # package.JSON contient : '"scripts" : { "serve" : "vue-cli-service serve",'

Le docker-compose.YML de Laravel, qui est utilisé par la commande vendor/bin/sail up de Laravel et qui lancera le service vuejs , définit ce service :

    vuejs :
        build :
            context : /home/FOOBAR/Documents/projets/web/job-board-front
            dockerfile : Dockerfile
        ports :
            - '8080:8080'
        réseaux :
            - voile
        depends_on :
            - laravel.test
        volumes :
            - '/home/FOOBAR/Documents/projets/web/job-board-front/src:/src'

NB: Dans tout ce post, "si j’utilise docker" signifie systématiquement : si je tape vendor/bin/sail up, qui exécute les conteneurs Docker Laravel et les réseaux définis dans le fichier docker-compose.YML ci-dessus.

Pouvez-vous me dire ce qui ne va pas dans ma configuration Docker s’il vous plaît ?

Je pense qu’il s’agit d’un problème de configuration de Docker car npm run serve directement tapé dans le projet d’application vuejs fonctionne bien. Les bugs ne se produisent que lors de l’exécution avec docker.

Ancien OP

Aujourd’hui j’ai besoin de Dockeriser mon application VueJS afin de pouvoir la mettre dans le même domaine que le container docker de mon application Laravel. Autrement dit, à terme je voudrais faire un doker network connect réseau_laravel_sail container_vuejs. ("Sail" est juste une surcouche logicielle de Laravel qui permet de démarrer un container docker pour le serveur HTTP de laravel + son serveur mysql + son serveur ceci cela, et de les gérer sans devoir taper une commande docker à proprement parler).

Pourquoi ai-je besoin de mettre ça sur un même réseau ? Juste parce que j’utilise un authentificateur d’utilisateurs dénommé "Sanctum" et que VueJS ne sera capable d’envoyer les identifiants de connexion à Laravel Sanctum sans génération d’une CORS Policy Errors si, et seulement si, VueJS est présent sur le même domaine que Laravel/Laravel Sanctum. Mais bref nous nous égarons. :clemhehe: (je me permets juste de rajouter que VueJS sans avoir été préalablement dockeurisé peut tout à fait communiquer avec le serveur Laravel qui quant à lui est dockeurisé, ça me semble étrange puisque normalement il faut que tout soit sur un même réseau docker pour que ça puisse communiquer ! mais passons).

Du coup j’ai créé ce Dockerfile VueJS :

FROM node:14-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080

CMD ["npm", "run", "serve"]

Et pour le lancer : docker run my-vuejs-app.

Le souci est le suivant : il semblerait que quand je modifie le code des fichiers de l’application VueJS, il faille que je relance un docker build -t my-vuejs-app . pour en tenir compte. Utiliser --watch de npm ou autre listen ne fonctionne pas…

Etant débutant à la fois en Docker et VueJS, je vous avouerais ne pas trop savoir quoi faire. Je n’ai pas envie de devoir relancer docker build -t my-vuejs-app . à chaque micro-modif que j’ai faite dans l’un des fichiers de VueJS pour les voir haha.

Pourriez-vous s’il vous plaît me donner un indice sur la marche à suivre ?

Merci !

+0 -0

Le fait de containeriser toute la pile NodeJS + NPM m’a l’air d’être une solution bien compliquée à ton problème. En particulier, ceci est faux, parce que les autorisations CORS ça se paramètre côté serveur :

si, et seulement si, VueJS est présent sur le même domaine que Laravel/Laravel Sanctum

Tu as un problème de CORS, il faut donc chercher à corriger ce problème de CORS proprement :

  • Soit en autorisant le serveur de dev front dans la configuration du serveur de dev (je ne sais pas comment faire ça en Laravel, mais ça devrait pas être très compliqué),
  • Soit en démarrant un serveur HTTP (Nginx, Apache…) pour faire proxy et servir « proprement » ton application VueJS – et là aussi il faudrait sans doute l’autoriser dans la configuration du serveur de dev Laravel.

PS : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS, https://www.laravel.fr/t/autour-de-laravel/laravel-corsne pas utiliser hors de dev parce que ça supprime la sécurité)

Bonjour Herbe,

Dans ton dockerfile, tu fais une copie de ton code dans l’image que tu construis. C’est pour cette raison que tu as besoin de rebuilder l’image et recréer le container à chaque changement de code.

Tu dois utiliser un volume à la place.

Tu crées d’abord ton image avec node sans la partie COPY . .. Et au moment de lancer le container tu lui assignes comme volume le code source de ton application.

Ta commande pour lancer le container devrait ressembler à docker run -it --name my-vuejs-app -v .:/app my-vuejs-app. L’option -v permet de dire à ton container de monter le dossier courant (.) de ta machine dans le dossier /app du container.

Ainsi, chaque modification dans le dossier courant sera répercutée dans le dossier /app du container.

J’ajouterai au commentaire de @Spacefox que tu as l’air d’utiliser le serveur intégré à Vue pour servir ton app depuis Docker. Or, ce serveur est basé sur webpack-dev-server et n’est pas du tout fait pour un usage de production : il fait beaucoup de calculs dédiés du développement (comme du watch de fichiers pour build en temps réel et du live reload) et surtout n’a pas été testé contre les failles de sécurité ni les montées en charge.

Il vaut donc mieux faire un build de ton app et mettre celui-ci (le résultat est normalement mis dans un dossier dist/ à la racine du projet) dans un conteneur Docker (voire sans conteneur suivant ta configuration) basé sur un serveur adapté (comme nginx ou Apache) qui lui saura gérer proprement tous types de clients et que tu pourras paramétrer à ta guise.

Bonjour à tous,

Je suis désolé de répondre avec du retard, j’étais occupé toute l’après-midi !

Mes réponses à vos posts

Réponse à @SpaceFox

Oui, le problème CORS peut en effet être corrigé côté serveur, c’est ce que j’avais lu sur https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS par exemple. Laravel prévoit bien un middleware cors qui fait partie de la stack des middlewares qui, par défaut, s’exécutent sur toute requête. La configuration de ce middleware contient par défaut cette ligne: 'allowed_origins' => ['*'], . Donc normalement ce middleware devrait déjà ajouter l’en-tête Access-Control-Allow-Origin et je ne devrais pas avoir de problème.

Mais dans la doc de Sanctum plus précisément (qui n’est autre qu’un package d’authentification), on peut lire :

In order to authenticate, your SPA and API must share the same top-level domain. However, they may be placed on different subdomains. Additionally, you should ensure that you send the Accept: application/json header with your request.

Ceci peut se trouver ici : https://laravel.com/docs/9.x/sanctum#spa-authentication et fait référence visiblement à CORS. Il est bon de noter que la partie https://laravel.com/docs/9.x/sanctum#mobile-application-authentication m’intéresse davantage puisqu’il s’agit bien d’une appli mobile et non d’une SPA mais le paragraphe que j’ai cité s’applique aussi pour une appli mobile.

Le lien que tu donnes donc (https://www.laravel.fr/t/autour-de-laravel/laravel-cors) défini un nouveau middleware cors pour autoriser toutes les IP mais c’est déjà ce qu’est censé faire le middleware de Laravel par défaut : https://laravel.com/api/9.x/Illuminate/Http/Middleware/HandleCors.html

Il semblerait toutefois que ce soit Sanctum qui apporte un nouveau problème, enfin je sais pas. Je suis en train d’analyser.

Réponse à BestCoder

OK merci ! Effectivement je pensais également aux volumes mais mon attention était accaparée par ce problème CORS que je souhaite résoudre en premier lieu.

Je relirai très attentivement ton post pour modifier mon Dockerfile :D !

Réponse à viki53

OK je prends note pour un projet en prod. Actuellement c’est vraiment du dev et pour un projet perso, et je réserve à ce sujet un petite surprise pour ZDS si vous voulez tout savoir… :clemhehe:

Nouvelle solution

Sinon, j’y pensais : pourquoi, dans le docker-compose.YML de Laravel, je n’ajouterais pas le serveur VueJS ? Il serait ajouté et lancé automatiquement quand je lancerais tous les containeurs de Laravel et en plus il sera directement connecté au réseau de Laravel.

Vous en dites quoi ?

ça me permet de simplifier tout ça (car mes compétences en docker/vuejs/configuration sont trop limitées pour l’instant) et de virer l’erreur CORS !

+0 -0

Oui, le problème CORS peut en effet être corrigé côté serveur, c’est ce que j’avais lu sur https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS par exemple. Laravel prévoit bien un middleware cors qui fait partie de la stack des middlewares qui, par défaut, s’exécutent sur toute requête. La configuration de ce middleware contient par défaut cette ligne: 'allowed_origins' => ['*'], . Donc normalement ce middleware devrait déjà ajouter l’en-tête Access-Control-Allow-Origin et je ne devrais pas avoir de problème.

Mais dans la doc de Sanctum plus précisément (qui n’est autre qu’un package d’authentification), on peut lire :

In order to authenticate, your SPA and API must share the same top-level domain. However, they may be placed on different subdomains. Additionally, you should ensure that you send the Accept: application/json header with your request.

Ceci peut se trouver ici : https://laravel.com/docs/9.x/sanctum#spa-authentication et fait référence visiblement à CORS. Il est bon de noter que la partie https://laravel.com/docs/9.x/sanctum#mobile-application-authentication m’intéresse davantage puisqu’il s’agit bien d’une appli mobile et non d’une SPA mais le paragraphe que j’ai cité s’applique aussi pour une appli mobile.

Herbe

Je vois, le module en question c’est une bidouille que je qualifierais d’assez sale pour éviter de gérer un système d’authentification propre. Mais à la limite, ça n’est pas le sujet – gérer un système d’authentification propre est un problème délicat, je le sais, c’est mon boulot actuel. Cette solution peut très bien suffire si tu n’as pas de contrainte forte là-dessus.

Quoi qu’il en soit, c’est pas ça le vrai problème. Par contre, tes réponses me laissent penser que tu mélanges des concepts très différents ; en particulier :

  1. « share the same top-level domain » est très différent de « si, et seulement si, VueJS est présent sur le même domaine que Laravel/Laravel Sanctum » :
    • Ta proposition (dans le premier message, que je cite) signifierait que l’application et l’API doivent être sur monapplication.com (par exemple avec la SPA à la racine et l’API sur monapplication.com/api, ce qui a des contraintes fortes sur l’architecture (notamment : un seul serveur HTTP doit servir les deux modules).
    • La documentation dit juste que le top-level domain doit être partagé, ce qui veut dire que tu pourrais avoir l’application sur monapplication.com et l’API sur api.monapplication.com (ou même spa.monapplication.com et api.monapplication.com ce qui libère toutes les contraintes sur l’architecture (les serveurs, réseaux, et même les certificats SSL peuvent être différents).
  2. Même en admettant que tu veuille servir l’API sur le même domaine que l’application, ça n’impose absolument pas que tout ça partage un même réseau. La seule chose qui doit être partagée pour que ça fonctionne c’est la couche HTTP. L’API et la SPA ne se parlent (par conception) qu’à travers la couche HTTP, puisque l’API est sur le serveur et la SPA d’exécute sur le poste client. Tu pourrais très bien avoir une architecture avec un réseau Docker entre l’API et un serveur HTTP proxy, un autre réseau Docker entre ton npm run serve de tests/debug et le même serveur HTTP proxy, et un troisième réseau (celui exposé) qui te permet d’accéder au serveur HTTP.
  3. Deux containers Docker dans le même fichier Docker-Compose peuvent très bien tourner sur des réseaux différents. C’est toi qui décide de la configuration.

Pour illustrer la différence entre réseaux et sous-domaines : spacefox.fr et ses sous-domaines renvoient vers au moins trois serveurs différents, chez trois hébergeurs différents ; au moins l’une de ces machines sert aussi un domaine qui n’a absolument rien à voir.

Mon expérience – mais ça ne reste que mon expérience, tu en fais ce que tu veux et d’autres peuvent en avoir d’autres – c’est de travaille comme ça en dev (et en dev uniquement !) :

  • Le serveur de dev de la SPA tourne en natif sur ta machine et est accessible via https://localhost:1234 (port indicatif)
  • Le serveur d’API tourne en natif sur ta machine et est accessible via https://localhost:2345 (autre port indicatif) ; et a les CORS configurés pour accepter au moins https://localhost:1234 (si c’est pas facile à faire dans un fichier de conf, c’est qu’il te manque une conf – c’est typiquement le genre de truc qui devrait être en conf parce que le coder en dur, c’est trop de risque que ça se retrouve en prod). Les éventuelles dépendances (BDD…) peuvent être dockerisées.

L’intérêt d’avoir tout en local et pas dans des Dockers c’est que c’est généralement plus facile pour coller des points d’arrêts, du debug, et rends la boucle de tests/vérification plus courte.

Si avec ça Sanctum t’emmerde encore parce que pour lui localhost:1234 et localhost:2345 sont deux domaines différents (je ne sais pas comment il le gère), tu n’auras pas d’autre choix que de passer par un proxy HTTP. Soit en local, soit en balançant tout sous Docker.

Bonjour Herbe,

Dans ton dockerfile, tu fais une copie de ton code dans l’image que tu construis. C’est pour cette raison que tu as besoin de rebuilder l’image et recréer le container à chaque changement de code.

Tu dois utiliser un volume à la place.

Tu crées d’abord ton image avec node sans la partie COPY . .. Et au moment de lancer le container tu lui assignes comme volume le code source de ton application.

Ta commande pour lancer le container devrait ressembler à docker run -it --name my-vuejs-app -v .:/app my-vuejs-app. L’option -v permet de dire à ton container de monter le dossier courant (.) de ta machine dans le dossier /app du container.

Ainsi, chaque modification dans le dossier courant sera répercutée dans le dossier /app du container.

BestCoder

Je ne peux pas utiliser l’instruction VOLUME dans le Dockerfile de vuejs ? Cela m’éviterait de devoir utiliser la commande que tu cites.

De plus, ça serait un bon complément à la solution que j’explique dans la section "Nouvelle solution".

@SpaceFox

Merci encore pour tes explications très bien détaillées !

En résumé :

  • Effectivement, je ne maîtrisais pas et étais confus au niveau des top-level-domain et domain. Si je comprends bien, dans ton exemple, il faut juste que .com soit partagé par le serveur de dev VueJS et le serveur Laravel.

  • Malheureusement, mes connaissances en infrastructure internet sont trop limitées pour que je puisse comprendre "ce qui libère toutes les contraintes sur l’architecture (les serveurs, réseaux, et même les certificats SSL peuvent être différents)." ainsi que l’entièreté de ta deuxième puce… Je ne vais pas te demander de m’expliquer ça, c’est à moi de monter rapidement en compétences dessus.

Pour illustrer la différence entre réseaux et sous-domaines : spacefox.fr et ses sous-domaines renvoient vers au moins trois serveurs différents, chez trois hébergeurs différents ; au moins l’une de ces machines sert aussi un domaine qui n’a absolument rien à voir.

ça , OK , compris :) La résolution DNS je connais (un peu) ouais

Mon expérience – mais ça ne reste que mon expérience, tu en fais ce que tu veux et d’autres peuvent en avoir d’autres – c’est de travaille comme ça en dev (et en dev uniquement !) :

J’entends bien que tu ferais tout sans Docker, mais je suis vraiment habitué à utiliser Laravel Sail qui s’occupe de tout containeuriser et mettre en relation MySQL, le serveur HTTP, ceci cela ^^

Je ne souhaite vraiment pas changer de fusil d’épaules, et préfère rester sur cette façon de développer.

et a les CORS configurés pour accepter au moins https://localhost:1234 (si c’est pas facile à faire dans un fichier de conf, c’est qu’il te manque une conf – c’est typiquement le genre de truc qui devrait être en conf parce que le coder en dur, c’est trop de risque que ça se retrouve en prod). Les éventuelles dépendances (BDD…) peuvent être dockerisées.

Du coup je sais faire cette config mais pour une raison que je ne comprends pas, en tout cas quand tout est Dockeurisé (ce qui peut-être ne correspond pas au contexte que tu décris avec localhost:1234 etc.), le middlwares Cors de Laravel, activé par défaut, et configuré par mes soins pour autoriser toutes les origines, n’ajoute en dépit pas d’en-tête HTTP Allow-X-Origins, malheureusement. Je ne pense pas que ce soit un bug, mais un problème situé au niveau du réseau que j’ai mis en place (terme vaste je le sais).

Ma solution

Côté Laravel, docker-compose.yml

Même s’il n’y a pas besoin de tout mettre sur le même réseau comme tu l’as indiqué @SpaceFox, je vais quand même le faire. Car ça me garantit que le top-level-domain sera le même entre VueJS et Laravel, et ça me va ^^

J’ai donc modifié le fichier de Laravel docker-compose.yml pour ajouter le service vuejs (situé presque à la toute fin du fichier) :


# For more information: https://laravel.com/docs/sail
version: '3'
services:
    laravel.test:
        build:
            context: ./vendor/laravel/sail/runtimes/8.1
            dockerfile: Dockerfile
            args:
                WWWGROUP: '${WWWGROUP}'
        image: sail-8.1/app
        extra_hosts:
            - 'host.docker.internal:host-gateway'
        ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'
        environment:
            WWWUSER: '${WWWUSER}'
            LARAVEL_SAIL: 1
            XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}'
            XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}'
        volumes:
            - '.:/var/www/html'
        networks:
            - sail
        depends_on:
            - mysql
            - redis
            - meilisearch
            - mailhog
            - selenium
    mysql:
        image: 'mysql/mysql-server:8.0'
        ports:
            - '${FORWARD_DB_PORT:-3306}:3306'
        environment:
            MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ROOT_HOST: "%"
            MYSQL_DATABASE: '${DB_DATABASE}'
            MYSQL_USER: '${DB_USERNAME}'
            MYSQL_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ALLOW_EMPTY_PASSWORD: 1
        volumes:
            - 'sail-mysql:/var/lib/mysql'
            - './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
        networks:
            - sail
        healthcheck:
            test: ["CMD", "mysqladmin", "ping", "-p${DB_PASSWORD}"]
            retries: 3
            timeout: 5s
    redis:
        image: 'redis:alpine'
        ports:
            - '${FORWARD_REDIS_PORT:-6379}:6379'
        volumes:
            - 'sail-redis:/data'
        networks:
            - sail
        healthcheck:
            test: ["CMD", "redis-cli", "ping"]
            retries: 3
            timeout: 5s
    meilisearch:
        image: 'getmeili/meilisearch:latest'
        ports:
            - '${FORWARD_MEILISEARCH_PORT:-7700}:7700'
        volumes:
            - 'sail-meilisearch:/meili_data'
        networks:
            - sail
        healthcheck:
            test: ["CMD", "wget", "--no-verbose", "--spider",  "http://localhost:7700/health"]
            retries: 3
            timeout: 5s
    mailhog:
        image: 'mailhog/mailhog:latest'
        ports:
            - '${FORWARD_MAILHOG_PORT:-1025}:1025'
            - '${FORWARD_MAILHOG_DASHBOARD_PORT:-8025}:8025'
        networks:
            - sail
    selenium:
        image: 'selenium/standalone-chrome'
        extra_hosts:
            - 'host.docker.internal:host-gateway'
        volumes:
            - '/dev/shm:/dev/shm'
        networks:
            - sail
    phpmyadmin:
        image: 'phpmyadmin/phpmyadmin'
        links:
          - 'mysql:mysql'
        ports:
          - '81:80'
        networks:
          - sail
        environment:
            MYSQL_USERNAME: "${DB_USERNAME}"
            MYSQL_ROOT_PASSWORD: "${DB_PASSWORD}"
            PMA_HOST: mysql
    vuejs:
        build:
            context: /home/xxx/Documents/projets/web/job-board-front
            dockerfile: Dockerfile
        ports:
            - '8080:8080'
        networks:
            - sail
        depends_on:
            - laravel.test
            
networks:
    sail:
        driver: bridge
volumes:
    sail-mysql:
        driver: local
    sail-redis:
        driver: local
    sail-meilisearch:
        driver: local

Dockerfile de VueJS

Le but est ici de générer l’image du container VueJS en utilisant un volume monté : /src du container est monté sur /src de mon ordi.

FROM node:14-alpine

WORKDIR /src

COPY package*.json ./

RUN npm install

VOLUME /src

EXPOSE 8080

CMD ["npm", "run", "watch"]

La commande npm run watch que j’utilise est définie dans package.json :

  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "lint": "vue-cli-service lint",
	"watch": "npm run serve --watch"
  },

Problème

Malgré tout ça, quand je lance vendor/bin/sail up, lequel lance tous les containers Docker définis dans le fichier docker-compose.yml de Laravel, ça compile bien VueJS mais mes modifications que je fais à la volée ne sont pas répercutées en direct…

De plus même après une ré-exécution de vendor/bin/sail up, qui rebuild bien VueJS apparemment, les modifications que j’avais effectuées avant cette ré-exécution ne sont pas prises en compte, ce qui est très étrange !

+0 -0

Comme pour le service laravel, tu dois déclarer un volume dans le docker compose.

        volumes:
            - './chemin/vers/ton/code/vuejs:/src'

L’instruction VOLUME dans ton dockerfile dit à docker de créer un volume à la création de ton container mais ne lui dit pas quoi mettre dedans.

Le dockerfile permet de créer une image. Cette image ne peut pas contenir un volume qui est monté sur ta machine car une image docker peut être partagée.

C’est au moment de la création du container que tu peux demander à docker de monter un dossier de ta machine dans le container (et pas dans l’image).

Comme pour le service laravel, tu dois déclarer un volume dans le docker compose.

        volumes:
            - './chemin/vers/ton/code/vuejs:/src'

L’instruction VOLUME dans ton dockerfile dit à docker de créer un volume à la création de ton container mais ne lui dit pas quoi mettre dedans.

Le dockerfile permet de créer une image. Cette image ne peut pas contenir un volume qui est monté sur ta machine car une image docker peut être partagée.

C’est au moment de la création du container que tu peux demander à docker de monter un dossier de ta machine dans le container (et pas dans l’image).

BestCoder

Ah oui, exact. Je pensais que VOLUME dans le dockerfile montait automatiquement le volume sur le même chemin, il faudra de toute façon que je regarde plus précisément la doc. C’est la première fois que j’ai écrit un Dockerfile. Jusque-là je me contentait d’utiliser les commandes dockers ainsi que d’écrire des docker-compose.YML

Du coup dans le docker-compose.YML de Laravel, j’ai modifié le service VueJS en :

    vuejs:
        build:
            context: /home/FOOBAR/Documents/projets/web/job-board-front
            dockerfile: Dockerfile
        ports:
            - '8080:8080'
        networks:
            - sail
        depends_on:
            - laravel.test
        volumes:
            - '/home/xxx/Documents/projets/web/job-board-front/src:/src'

Néanmoins, quand je lance les containers définis dans ce docker-compose, j’ai toujours la toute première version de mon appli VueJS, alors que je vois bien du build se faire. Et bien sûr quand je modifie le code de VueJS, le rebuild n’est toujours pas relancé, c’est assez étrange :(

Solution en cours de test (après test : échec)

Je crois que c’est mon npm run watch que j’avais rajouté en tant que script dans package.JSON et que j’utilise dans le Dockerfile de VueJS qui pose souci. A la place, je vais réutiliser le script déjà renseigné CMD ["npm", "run", "serve"] (enfin je veux dire, le script npm run serve).

Indication supplémentaire

Si je lance vuejs directement avec npm run serve, sans passer par les containers docker, alors le code utilisé pour le rendu est bien le plus récent (celui qui vient d’être modifié) et les modifs live sont bien répercutées.

+0 -0

Tu as supprimé l’instruction VOLUME /src dans ton Dockerfile et recréé l’image ?

BestCoder
  • Je n’avais pas supprimé cette instruction dans le dockerfile de vuejs car je pensais qu’elle était complémentaire au docker-compose’s volumes de Laravel, je viens donc de le faire.

  • Je pense que j’ai effectivement recréé l’image de vuejs puisque pour lancer les containers Laravel (qui comportent le container de vuejs d’après le docker-compose), je lance vendor/bin/sail up , lequel effectue bien de la compilation de fichiers. Cependant, je n’ai pas manuellement supprimé le container ni l’image de docker préalablement.

  • Edit : je viens de supprimer tous les containers docker, donc pour le coup il est sûr et certain que le container vuejs a bien été recréé et idem pour son image.

Pour info, voici le retour de vendor/bin/sail up (En faisant CTRL+F, vous pourrez voir "vuejs") :

the-gummy-bears-laravel.test-1   "start-container"   laravel.test        exited (0)          
Shutting down old Sail processes...
[+] Running 9/9
 ⠿ Network the-gummy-bears_sail              Created                                                                                                 0.1s
 ⠿ Container the-gummy-bears-mailhog-1       Created                                                                                                 0.5s
 ⠿ Container the-gummy-bears-selenium-1      Created                                                                                                 0.7s
 ⠿ Container the-gummy-bears-mysql-1         Created                                                                                                 0.4s
 ⠿ Container the-gummy-bears-redis-1         Created                                                                                                 0.4s
 ⠿ Container the-gummy-bears-meilisearch-1   Created                                                                                                 0.5s
 ⠿ Container the-gummy-bears-phpmyadmin-1    Created                                                                                                 0.4s
 ⠿ Container the-gummy-bears-laravel.test-1  Created                                                                                                 0.2s
 ⠿ Container the-gummy-bears-vuejs-1         Created                                                                                                 0.2s
Attaching to the-gummy-bears-laravel.test-1, the-gummy-bears-mailhog-1, the-gummy-bears-meilisearch-1, the-gummy-bears-mysql-1, the-gummy-bears-phpmyadmin-1, the-gummy-bears-redis-1, the-gummy-bears-selenium-1, the-gummy-bears-vuejs-1
the-gummy-bears-mailhog-1       | 2022/12/10 12:00:33 Using in-memory storage
the-gummy-bears-mailhog-1       | 2022/12/10 12:00:33 [SMTP] Binding to address: 0.0.0.0:1025
the-gummy-bears-mailhog-1       | [HTTP] Binding to address: 0.0.0.0:8025
the-gummy-bears-mailhog-1       | Creating API v1 with WebPath: 
the-gummy-bears-mailhog-1       | Creating API v2 with WebPath: 
the-gummy-bears-mailhog-1       | 2022/12/10 12:00:33 Serving under http://0.0.0.0:8025/
the-gummy-bears-mysql-1         | [Entrypoint] MySQL Docker Image 8.0.31-1.2.10-server
the-gummy-bears-meilisearch-1   | Error: Expected Meilisearch engine version: 0.29.1, current engine version: 0.30.1.
the-gummy-bears-meilisearch-1   |         To update Meilisearch please follow our guide on https://docs.meilisearch.com/learn/advanced/updating.html.
the-gummy-bears-redis-1         | 1:C 10 Dec 2022 12:00:34.174 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
the-gummy-bears-redis-1         | 1:C 10 Dec 2022 12:00:34.174 # Redis version=7.0.5, bits=64, commit=00000000, modified=0, pid=1, just started
the-gummy-bears-redis-1         | 1:C 10 Dec 2022 12:00:34.174 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.175 * monotonic clock: POSIX clock_gettime
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.179 * Running mode=standalone, port=6379.
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.179 # Server initialized
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.179 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.185 * Loading RDB produced by version 7.0.5
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.185 * RDB age 11 seconds
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.185 * RDB memory usage when created 0.85 Mb
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.185 * Done loading RDB, keys loaded: 0, keys expired: 0.
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.185 * DB loaded from disk: 0.002 seconds
the-gummy-bears-redis-1         | 1:M 10 Dec 2022 12:00:34.185 * Ready to accept connections
the-gummy-bears-mysql-1         | [Entrypoint] Starting MySQL 8.0.31-1.2.10-server
the-gummy-bears-meilisearch-1 exited with code 1
the-gummy-bears-mysql-1         | 2022-12-10T12:00:35.154532Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.
the-gummy-bears-mysql-1         | 2022-12-10T12:00:35.158627Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.31) starting as process 1
the-gummy-bears-mysql-1         | 2022-12-10T12:00:35.192637Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
the-gummy-bears-selenium-1      | 2022-12-10 12:00:35,423 INFO Included extra file "/etc/supervisor/conf.d/selenium.conf" during parsing
the-gummy-bears-selenium-1      | 2022-12-10 12:00:35,433 INFO RPC interface 'supervisor' initialized
the-gummy-bears-selenium-1      | 2022-12-10 12:00:35,433 CRIT Server 'unix_http_server' running without any HTTP authentication checking
the-gummy-bears-selenium-1      | 2022-12-10 12:00:35,434 INFO supervisord started with pid 8
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,437 INFO spawned: 'xvfb' with pid 10
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,439 INFO spawned: 'vnc' with pid 11
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,442 INFO spawned: 'novnc' with pid 12
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,445 INFO spawned: 'selenium-standalone' with pid 13
the-gummy-bears-selenium-1      | Setting up SE_NODE_GRID_URL...
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,561 INFO success: xvfb entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,561 INFO success: vnc entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,561 INFO success: novnc entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
the-gummy-bears-selenium-1      | 2022-12-10 12:00:36,561 INFO success: selenium-standalone entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
the-gummy-bears-mysql-1         | 2022-12-10T12:00:36.711989Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
the-gummy-bears-phpmyadmin-1    | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.16.7. Set the 'ServerName' directive globally to suppress this message
the-gummy-bears-phpmyadmin-1    | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.16.7. Set the 'ServerName' directive globally to suppress this message
the-gummy-bears-selenium-1      | Selenium Grid Standalone configuration: 
the-gummy-bears-selenium-1      | [network]
the-gummy-bears-selenium-1      | relax-checks = true
the-gummy-bears-selenium-1      | 
the-gummy-bears-selenium-1      | [node]
the-gummy-bears-selenium-1      | session-timeout = "300"
the-gummy-bears-selenium-1      | override-max-sessions = false
the-gummy-bears-selenium-1      | detect-drivers = false
the-gummy-bears-selenium-1      | drain-after-session-count = 0
the-gummy-bears-selenium-1      | max-sessions = 1
the-gummy-bears-selenium-1      | 
the-gummy-bears-selenium-1      | [[node.driver-configuration]]
the-gummy-bears-selenium-1      | display-name = "chrome"
the-gummy-bears-selenium-1      | stereotype = '{"browserName": "chrome", "browserVersion": "108.0", "platformName": "Linux"}'
the-gummy-bears-selenium-1      | max-sessions = 1
the-gummy-bears-selenium-1      | 
the-gummy-bears-selenium-1      | Starting Selenium Grid Standalone...
the-gummy-bears-selenium-1      | Tracing is disabled
the-gummy-bears-phpmyadmin-1    | [Sat Dec 10 12:00:39.105351 2022] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.53 (Debian) PHP/8.0.19 configured -- resuming normal operations
the-gummy-bears-phpmyadmin-1    | [Sat Dec 10 12:00:39.105402 2022] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
the-gummy-bears-mysql-1         | 2022-12-10T12:00:39.358382Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
the-gummy-bears-mysql-1         | 2022-12-10T12:00:39.358456Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
the-gummy-bears-mysql-1         | 2022-12-10T12:00:39.593254Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
the-gummy-bears-mysql-1         | 2022-12-10T12:00:39.593769Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.31'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server - GPL.
the-gummy-bears-laravel.test-1  | 2022-12-10 12:00:39,672 INFO Set uid to user 0 succeeded
the-gummy-bears-laravel.test-1  | 2022-12-10 12:00:39,677 INFO supervisord started with pid 1
the-gummy-bears-laravel.test-1  | 2022-12-10 12:00:40,806 INFO spawned: 'php' with pid 16
the-gummy-bears-vuejs-1         | 
the-gummy-bears-vuejs-1         | > job-board-front@0.1.0 serve /app
the-gummy-bears-vuejs-1         | > vue-cli-service serve
the-gummy-bears-vuejs-1         | 
the-gummy-bears-laravel.test-1  | 2022-12-10 12:00:41,807 INFO success: php entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
the-gummy-bears-selenium-1      | 12:00:42.647 INFO [LoggingOptions.configureLogEncoding] - Using the system default encoding
the-gummy-bears-selenium-1      | 12:00:42.683 INFO [OpenTelemetryTracer.createTracer] - Using OpenTelemetry for tracing
the-gummy-bears-laravel.test-1  | 
the-gummy-bears-laravel.test-1  |    INFO  Server running on [http://0.0.0.0:80].  
the-gummy-bears-laravel.test-1  | 
the-gummy-bears-laravel.test-1  |   Press Ctrl+C to stop the server
the-gummy-bears-laravel.test-1  | 
the-gummy-bears-vuejs-1         |  INFO  Starting development server...
the-gummy-bears-selenium-1      | 12:00:44.969 INFO [NodeOptions.getSessionFactories] - Detected 4 available processors
the-gummy-bears-selenium-1      | 12:00:45.217 INFO [NodeOptions.report] - Adding chrome for {"browserVersion": "108.0","se:noVncPort": 7900,"browserName": "chrome","platformName": "LINUX","se:vncEnabled": true} 1 times
the-gummy-bears-selenium-1      | 12:00:45.296 INFO [Node.<init>] - Binding additional locator mechanisms: relative, name, id
the-gummy-bears-selenium-1      | 12:00:45.371 INFO [GridModel.setAvailability] - Switching Node 809e4ae5-00c1-48b6-87e9-ef019925eebe (uri: http://192.168.16.3:4444) from DOWN to UP
the-gummy-bears-selenium-1      | 12:00:45.375 INFO [LocalDistributor.add] - Added node 809e4ae5-00c1-48b6-87e9-ef019925eebe at http://192.168.16.3:4444. Health check every 120s
the-gummy-bears-selenium-1      | 12:00:46.012 INFO [Standalone.execute] - Started Selenium Standalone 4.7.0 (revision 52e3a49ea2): http://192.168.16.3:4444
 DONE  Compiled successfully in 9984ms12:00:58 PM
the-gummy-bears-vuejs-1         | 

the-gummy-bears-vuejs-1         |   App running at:
the-gummy-bears-vuejs-1         |   - Local:   http://localhost:8080/ 
the-gummy-bears-vuejs-1         |   - Network: http://192.168.16.4:8080/
the-gummy-bears-vuejs-1         | 
the-gummy-bears-vuejs-1         |   Note that the development build is not optimized.
the-gummy-bears-vuejs-1         |   To create a production build, run npm run build.
the-gummy-bears-vuejs-1         | 
 WAIT  Compiling...12:00:59 PM
the-gummy-bears-vuejs-1         | 
the-gummy-bears-vuejs-1         | Compiling...
 DONE  Compiled successfully in 368ms12:00:59 PM
the-gummy-bears-vuejs-1         | 

the-gummy-bears-vuejs-1         |   App running at:
the-gummy-bears-vuejs-1         |   - Local:   http://localhost:8080/ 
the-gummy-bears-vuejs-1         |   - Network: http://192.168.16.4:8080/
the-gummy-bears-vuejs-1         | 
Build finished at 12:00:59 by 0.000s
the-gummy-bears-mailhog-1       | [APIv1] KEEPALIVE /api/v1/events
the-gummy-bears-mailhog-1       | [APIv1] KEEPALIVE /api/v1/events
+0 -0

Salut Herbe,

Si tu es dans un environnement de développement, l’utilisation des volumes est la solution qu’il te faut.

Pour forcer la recréation des containers et des images, tu peux lancer les commandes suivantes :

docker-compose down // pour arrêter et supprimer les containers
docker-compose up --build --force-recreate  // Pour recréer les containers en rebuildant les images.

Pour t’assurer que le bon dossier est monté comme volume dans le container, tu peux créer un fichier lambda depuis ta machine et vérifier s’il est bien présent dans ton container.

Tu peux te connecter dans ton container avec la commande :

docker-compose exec vuejs bash
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte