I have a VUE app I have been developing locally which I am trying to deploy to a remote server for testing.
My dev machine is running Arch with Docker 20.10.17
My VUE app has the following Dev.Dockerfile which is used to build it:
FROM node:lts-alpine
WORKDIR /code
COPY package*.json /code/
RUN npm install --location=global #vue/cli
RUN yarn install
COPY . .
# serve application in development
CMD [ "yarn", "serve" ]
The relevant service in my docker-compose.yml is:
frontend:
build:
context: ./frontend
dockerfile: dockerfiles/Dev.Dockerfile
command: yarn serve
stdin_open: true
restart: always
volumes:
- ./frontend/:/code/
ports:
- "8080:8080"
The VUE service is part of a larger set of services I am setting up with docker-compose.
This seems to be running fine on my local machine (Arch with the latest Docker).
When I try to deploy this to an Ubuntu 20.04 server, however, I run into issues.
The server is running Docker-compose 1.29.2 and Docker 20.17.1
The build goes fine, but when I try to run docker-compose up I get:
yarn run v1.22.19
$ vue-cli-service serve
/bin/sh: vue-cli-service: not found
Reading elsewhere on stackoverflow about this issue, I tried installing:
RUN npm install -g #vue/cli-service
This changes the error to:
yarn run v1.22.19
$ vue-cli-service serve
...
Error: Cannot find module '#vue/cli-plugin-babel'
I have also tried to explicitly install:
RUN npm install #babel/core #babel/preset-env
RUN npm install #vue/cli-plugin-babel
The error remains the same.
This is not an issue on my local machine running Arch, only the remote machine running Ubuntu 20. How do I fix this?
MORE INFORMATION.
After experimenting with #amir's answer I have some more information.
On Arch, Docker compose is now a command in Docker and I have been using it without thinking about it. On the Ubuntu server that doesn't work and instead I am using the 'docker-compose' command. I "assumed" these were functionally the same but I think docker-compose is causing the failure.
If I build my frontend service manually with Docker and my Dev.Dockerfile and then run it with Docker it works perfectly. No warnings.
Building with Docker-compose works... but throws a number a warnings:
yarn add v1.22.19
info No lockfile found.
[1/4] Resolving packages...
warning #vue/cli-service > cssnano > cssnano-preset-default > postcss-svgo > svgo > stable#0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
warning #vue/cli > #vue/cli-ui > apollo-server-express > subscriptions-transport-ws#0.9.19: The `subscriptions-transport-ws` package is no longer maintained. We recommend you use `graphql-ws` instead. For help migrating Apollo software to `graphql-ws`, see https://www.apollographql.com/docs/apollo-server/data/subscriptions/#switching-from-subscriptions-transport-ws For general help using `graphql-ws`, see https://github.com/enisdenjo/graphql-ws/blob/master/README.md
warning #vue/cli > #vue/cli-ui > apollo-server-express > apollo-server-core > subscriptions-transport-ws#0.9.19: The `subscriptions-transport-ws` package is no longer maintained. We recommend you use `graphql-ws` instead. For help migrating Apollo software to `graphql-ws`, see https://www.apollographql.com/docs/apollo-server/data/subscriptions/#switching-from-subscriptions-transport-ws For general help using `graphql-ws`, see https://github.com/enisdenjo/graphql-ws/blob/master/README.md
warning #vue/cli > #vue/cli-ui > apollo-server-express > graphql-tools#4.0.8: This package has been deprecated and now it only exports makeExecutableSchema.\nAnd it will no longer receive updates.\nWe recommend you to migrate to scoped packages such as #graphql-tools/schema, #graphql-tools/utils and etc.\nCheck out https://www.graphql-tools.com to learn what package you should use instead
warning #vue/cli > #vue/cli-ui > apollo-server-express > apollo-server-core > graphql-tools#4.0.8: This package has been deprecated and now it only exports makeExecutableSchema.\nAnd it will no longer receive updates.\nWe recommend you to migrate to scoped packages such as #graphql-tools/schema, #graphql-tools/utils and etc.\nCheck out https://www.graphql-tools.com to learn what package you should use instead
warning #vue/cli > #vue/cli-ui > apollo-server-express > graphql-tools > uuid#3.4.0: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.
warning #vue/cli > vue-codemod > jscodeshift > micromatch > snapdragon > source-map-resolve#0.5.3: See https://github.com/lydell/source-map-resolve#deprecated
warning #vue/cli > #vue/cli-ui > apollo-server-express > apollo-server-core > apollo-cache-control#0.14.0: The functionality provided by the `apollo-cache-control` package is built in to `apollo-server-core` starting with Apollo Server 3. See https://www.apollographql.com/docs/apollo-server/migration/#cachecontrol for details.
warning #vue/cli > #vue/cli-ui > apollo-server-express > apollo-server-core > graphql-extensions#0.15.0: The `graphql-extensions` API has been removed from Apollo Server 3. Use the plugin API instead: https://www.apollographql.com/docs/apollo-server/integrations/plugins/
warning #vue/cli > vue-codemod > jscodeshift > micromatch > snapdragon > source-map-resolve > resolve-url#0.2.1: https://github.com/lydell/resolve-url#deprecated
warning #vue/cli > vue-codemod > jscodeshift > micromatch > snapdragon > source-map-resolve > source-map-url#0.4.1: See https://github.com/lydell/source-map-url#deprecated
warning #vue/cli > vue-codemod > jscodeshift > micromatch > snapdragon > source-map-resolve > urix#0.1.0: Please see https://github.com/lydell/urix#deprecated
warning #vue/cli > #vue/cli-ui > apollo-server-express > apollo-server-core > apollo-tracing#0.15.0: The `apollo-tracing` package is no longer part of Apollo Server 3. See https://www.apollographql.com/docs/apollo-server/migration/#tracing for details
So it isn't finding the yarn.lock file - which is there - and throwing a number of module errors.
Again, this does not occur on my Arch machine running 'Docker compose' but does on an Ubuntu 20.04 server running docker-compose
I did try adding a volume directly to the node_module directory as per #amir's answer but that did not work. I also tried changing the copy location for the Dockerfile as per that answer. No joy.
Ideas? I am really stuck here.
Hi I fixed my own version with below dockerfile:
FROM node:16.6-alpine3.14
WORKDIR /code
RUN apk update && apk upgrade && apk add curl py-pip make g++
COPY package*.json ./
COPY . .
EXPOSE 8080
RUN yarn install
CMD yarn dev # or serve
I think there might be a problem in your copying package.json file line
frontend:
container_name: frontend
ports:
- 8080:8080
env_file:
- ./.env
build:
context: <Context>
target: <TARGET>
networks:
- network
volumes:
- <Location>:/code
- <Location>/node_modules
Ok. After a lot of trial and error and lots of help from #Amir Jani I was able to fix it.
In case it helps anyone else. What was occuring is the node_module directory was being overwritten in the final image build. This is simmilar to this issue
The fix was to add a volume to store the node_module directory. The syntax for the volume had to be absolute from the volume storing the code - since that's where my node_module was located.
Final Dockerfile and docker-compose.yml
FROM node:lts-alpine
WORKDIR /code
COPY package*.json /code/
RUN yarn add global #vue/cli
RUN yarn install
COPY . .
CMD [ "yarn", "serve" ]
docker-compose.yml
version: "3.9"
services:
...
frontend:
container_name: frontend
build:
context: ./frontend
dockerfile: dockerfiles/Dev.Dockerfile
restart: always
volumes:
- ./frontend/:/code/
- /code/node_modules
ports:
- "8080:8080"
I'm not sure this is the best solution, but it seems to work. Is mounting the node_modules bad for any reason?
I am still confused why this wasn't a problem on an Arch machine but was on Ubuntu 20. The versions of docker used were the same. If anyone could explain that it would be a big help
Just add the following code in the Dockerfile:
NODE_ENV=development npm run instal and this might resolve vue-cli issue
Related
I'm trying to dockerize Nuxt 3 app, but I have strange issue.
This Dockerfile is working with this docker run command:
docker run -v /Users/my_name/developer/nuxt-app:/app -it -p 3000:3000 nuxt-app
# Dockerfile
FROM node:16-alpine3.14
# create destination directory
RUN mkdir -p /usr/src/nuxt-app
WORKDIR /usr/src/nuxt-app
# update and install dependency
RUN apk update && apk upgrade
RUN apk add git
# copy the app, note .dockerignore
COPY . /usr/src/nuxt-app/
RUN npm install
# RUN npm run build
EXPOSE 3000
# ENV NUXT_HOST=0.0.0.0
# ENV NUXT_PORT=3000
CMD [ "npm", "run", "dev"]
I don't understand why despite mounting it to /app folder in the container and declaring /usr/src/nuxt-app in Dockerfile it works.
When I try to match them then I get this error:
ERROR (node:18) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 3) 20:09:42
(Use `node --trace-warnings ...` to show where the warning was created)
✔ Nitro built in 571 ms nitro 20:09:43
ERROR [unhandledRejection]
You installed esbuild for another platform than the one you're currently using.
This won't work because esbuild is written with native code and needs to
install a platform-specific binary executable.
Specifically the "#esbuild/darwin-arm64" package is present but this platform
needs the "#esbuild/linux-arm64" package instead. People often get into this
situation by installing esbuild on Windows or macOS and copying "node_modules"
into a Docker image that runs Linux, or by copying "node_modules" between
Windows and WSL environments.
If you are installing with npm, you can try not copying the "node_modules"
directory when you copy the files over, and running "npm ci" or "npm install"
on the destination platform after the copy. Or you could consider using yarn
instead of npm which has built-in support for installing a package on multiple
platforms simultaneously.
If you are installing with yarn, you can try listing both this platform and the
other platform in your ".yarnrc.yml" file using the "supportedArchitectures"
feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
Keep in mind that this means multiple copies of esbuild will be present.
Another alternative is to use the "esbuild-wasm" package instead, which works
the same way on all platforms. But it comes with a heavy performance cost and
can sometimes be 10x slower than the "esbuild" package, so you may also not
want to do that.
at generateBinPath (node_modules/vite/node_modules/esbuild/lib/main.js:1841:17)
at esbuildCommandAndArgs (node_modules/vite/node_modules/esbuild/lib/main.js:1922:33)
at ensureServiceIsRunning (node_modules/vite/node_modules/esbuild/lib/main.js:2087:25)
at build (node_modules/vite/node_modules/esbuild/lib/main.js:1978:26)
at runOptimizeDeps (node_modules/vite/dist/node/chunks/dep-3007b26d.js:42941:26)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
I have absolutely no clue what is going on here except architecture mismatch (that doesn't seem to be the case with working version - I'm on MacBook Air M1).
The second issue is that mounting doesn't update the page.
Okay, found the way. The issue was with Vite because HMR module is using port 24678 and I didn't expose it so it couldn't reload the page. This is how it should be looking:
docker run --rm -it \
-v /path/to/your/app/locally:/usr/src/app \
-p 3000:3000 \
-p 24678:24678 \
nuxt-app
Dockerfile
FROM node:lts-slim
WORKDIR /usr/src/app
CMD ["sh", "-c", "npm install && npm run dev"]
I'm trying to get create-react-app working on my Ubuntu wsl2 without having to install node, but rather using Docker. I have the following.
so I have this utility.docker-compose.yml file
version: '3.7'
services:
npm:
build:
context: .
dockerfile: utility.Dockerfile
volumes:
- ./:/app
stdin_open: true
tty: true
utility.Dockerfile
FROM node:18-alpine
WORKDIR /app
ENTRYPOINT [ "npm" ]
I also have a shell script
docker-compose -f utility.docker-compose.yml run --rm npm "init" "react-app" "my-app"
This is under my directory \wsl$\Ubuntu-20.04\home\username\Projects
I am able to install npm packages by modifying the shell script to something like "install" "axios". That works, but I haven't had luck trying to create a react app that.
I keep getting this error "sh: create-react-app: Permission denied" I tried changing the permissions and ownership but nothing works.
sh: create-react-app: Permission denied
npm ERR! code 127
npm ERR! path /app
npm ERR! command failed
npm ERR! command sh -c -- create-react-app my-app
But when I try it on my Windows10, it works easily. Any ideas on how to fix this issue? I kinda don't like to keep moving my files from Windows 10 to my WSl2 Ubuntu instance.
I prefer using wsl2 cause when I make a change in react, I can see the changes reflect right away as opposed to on Windows 10 I have to rebuild the containers.
So, I ended up finding another stackoverflow question that worked for my situation. I added the command below is what worked for me.
docker run -it -p 8080:80 -v $PWD:/app -w /app node:12-slim bash
The link below is the solution that worked for me.
create-react-app error in nodejs docker environment
I want to make a development setup of a Blitz.js app with Docker (because it will be deployed and tested with it, too). I am developing on Windows, the code resides within WSL2.
After starting up, the container exits with:
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
Environment variables loaded from .env
Prisma schema loaded from db/schema.prisma
Prisma Studio is up on http://localhost:5555
info - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
[Error: EACCES: permission denied, unlink '/home/node/app/.next/server/blitz-db.js'] {
errno: -13,
code: 'EACCES',
syscall: 'unlink',
path: '/home/node/app/.next/server/blitz-db.js'
}
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
This is what my Dockerfile looks like:
# Create a standard base image that has all the defaults
FROM node:16-slim as base
ENV NODE_ENV=production
ENV PATH /home/node/app/node_modules/.bin:$PATH
ENV TINI_VERSION v0.19.0
WORKDIR /home/node/app
RUN apt-get update && apt-get install -y openssl --no-install-recommends \
&& rm -rf /var/lib/apt/lists/* \
&& chown -R node:node /home/node/app
# Blitz.js recommends using tini, see why: https://github.com/krallin/tini/issues/8
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
USER node
COPY --chown=node:node package*.json yarn.lock* ./
RUN yarn config list && yarn install --frozen-lockfile && yarn cache clean --force
# Create a development image
FROM base as dev
ENV NODE_ENV=development
USER node
COPY --chown=node:node . .
RUN yarn config list && yarn install && yarn cache clean --force
CMD ["bash", "-c", "yarn dev"]
Within WSL2, I run docker-compose up -d to make use of the following docker-compose.yml:
version: "3.8"
services:
app:
container_name: itb_app
build: .
image: itb_app:dev
ports:
- 3000:3000
volumes:
# Only needed during development: Container gets access to app files on local development machine.
# Without access, changes made during development would only be reflected
# every time the container's image is built (hence on every `docker-compose up`).
- ./:/home/node/app/
The file in question (blitz-db.js) is generated by yarn dev (see Dockerfile). I checked the owner of it within WSL2: It seems to be root. But I wouldn't know how to change it under these circumstances, let alone know to which user.
I wonder how I can mount the WSL2 directory into my container for Blitz.js to use it.
The issue is that the .next directory and its content (the code of the compiled Blitz.js app) was created by the host system before the docker container was introduced. So, the host system user was owner of the directory and its files. Thus, the container's user did not have write permissions and couldn't compile its own app version into the .next directory, raising the error above.
The solution is to delete the .next folder from the host system and restarting the container, giving it the ability to compile the app.
I'm trying to dockerize an Expo React Native app in order to have an Development Environment for reuse cases.
At the moment I make it possible to build the container.
http://prntscr.com/rezs9e
The problem is when i go to localhost:19002 trying to access to Expo developer tools it loads the tab image but the window content is a black screen.
http://prntscr.com/reztg5
I find this similar to issue, but his main problem was solved.
I cannot figure out what whats the problem.
Here is the code to reproduce this issue.
https://github.com/joselrodrigues/docker-react-native
My Dockerfile
FROM node:12
EXPOSE 19000
EXPOSE 19001
EXPOSE 19002
EXPOSE 19006
WORKDIR /usr/src/app
COPY . .
WORKDIR /usr/src/app/ReactNative
#install latest yarn
RUN curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
#Add expo-cli globaly
RUN yarn global add expo-cli
#install all react-native dependencies
RUN yarn install
CMD yarn start
My docker-compose.yml
version: '3.7'
services:
reactnative:
build:
context: ./
dockerfile: docker/Dockerfile
container_name: reactNative
environment:
- REACT_NATIVE_PACKAGER_HOSTNAME=0.0.0.0
- EXPO_DEVTOOLS_LISTEN_ADDRESS=0.0.0.0
ports:
- "19000:19000"
- "19001:19001"
- "19002:19002"
- "19006:19006"
volumes:
- .:/usr/src/app
- node_modules:/usr/src/app/ReactNative/node_modules
volumes:
node_modules:
I had a similar error with my http://localhost:19002/ starting at a black screen.
What helped was to update my expo cli with npm install -g expo-cli and then start again my project with npm start.
I updated to expo#3.21.9. Hope this helps!
I have a Dockerfile I'm pointing at from a docker-compose.yml.
I'd like the volume mount in the docker-compose.yml to happen before the RUN in the Dockerfile.
Dockerfile:
FROM node
WORKDIR /usr/src/app
RUN npm install --global gulp-cli \
&& npm install
ENTRYPOINT gulp watch
docker-compose.yml
version: '2'
services:
build_tools:
build: docker/gulp
volumes_from:
- build_data:rw
build_data:
image: debian:jessie
volumes:
- .:/usr/src/app
It makes complete sense for it to do the Dockerfile first, then mount from docker-compose, however is there a way to get around it.
I want to keep the Dockerfile generic, while passing more specific bits in from compose. Perhaps that's not the best practice?
Erik Dannenberg's is correct, the volume layering means that what I was trying to do makes no sense. (There is another really good explaination on the Docker website if you want to read more). If I want to have Docker do the npm install then I could do it like this:
FROM node
ADD . /usr/src/app
WORKDIR /usr/src/app
RUN npm install --global gulp-cli \
&& npm install
CMD ["gulp", "watch"]
However, this isn't appropriate as a solution for my situation. The goal is to use NPM to install project dependencies, then run gulp to build my project. This means I need read and write access to the project folder and it needs to persist after the container is gone.
I need to do two things after the volume is mounted, so I came up with the following solution...
docker/gulp/Dockerfile:
FROM node
RUN npm install --global gulp-cli
ADD start-gulp.sh .
CMD ./start-gulp.sh
docker/gulp/start-gulp.sh:
#!/usr/bin/env bash
until cd /usr/src/app && npm install
do
echo "Retrying npm install"
done
gulp watch
docker-compose.yml:
version: '2'
services:
build_tools:
build: docker/gulp
volumes_from:
- build_data:rw
build_data:
image: debian:jessie
volumes:
- .:/usr/src/app
So now the container starts a bash script that will continuously loop until it can get into the directory and run npm install. This is still quite brittle, but it works. :)
You can't mount host folders or volumes during a Docker build. Allowing that would compromise build repeatability. The only way to access local data during a Docker build is the build context, which is everything in the PATH or URL you passed to the build command. Note that the Dockerfile needs to exist somewhere in context. See https://docs.docker.com/engine/reference/commandline/build/ for more details.