I have exhausted all the probable solutions on stackoverflow and beyond all to no success.
My use case is a very simple nodejs app that uses puppeteer ^19.7.1.
My directory structure has the file .puppeteerrc.cjs with content
const { join } = require('path');
/**
* #type {import("puppeteer").Configuration}
*/
module.exports = {
// Changes the cache location for Puppeteer.
cacheDirectory: join(__dirname, '.cache', 'puppeteer'),
};
However, when the server starts I am constantly greeted with the error message:
/workspace/.cache/puppeteer/chrome/linux-1069273/chrome-linux/chrome: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory
Everything works well on my localhost. The issue only starts when I hosted it on Digital Ocean Droplets.
I tried copying over the Dockerfile setup here https://pptr.dev/troubleshooting#running-puppeteer-in-the-cloud as is over to the root of my project to see if the issue will be resolved all to no available.
So, please I would really appreciate if any one can help me with a working Dockerfile configuration to address this as I've spent all day on this to no success.
I intend to host the app on Digital Ocean's Droplets
Thanks in anticipation for your time
Related
I am trying to deploy an AzureFunctions in NodeJs but it doesn't work on Azure.
My apllication is a v3 functions running on Linux.
When the deploy is completed, i get this 500 error:
Error:
/home/site/wwwroot/node_modules/canvas/build/Release/canvas.node:
invalid ELF header
Its happen only when I do this imports:
import ChartDataLabels from 'chartjs-plugin-datalabels';
const canvasRenderService = new CanvasRenderService(width, height, chartCallback);
const chartCallback = (ChartJS) => {
ChartJS.register(require('chartjs-plugin-datalabels'))
};
const jsdom = require("jsdom");
const { JSDOM } = jsdom;
const { document } = (new JSDOM(`...`)).window;
Would someone help me please?
It works (only) on my machine :(
Edit: It works when I make the deploy by Linux Subsystem.
I hope this will help somebody.
Azure function will not include the Node_modules while deploying into azure. Because Node_modules directory contains very large file. You can include your package.json in you function directory and run npm install as you normally would with Node.js projects using Kudu (https://<function_app_name>.scm.azurewebsites.net )or the Console in the Azure portal.
Check Dependency management for more information.
Refer here Link 1 & Link 2
Any updates on this topic?
Doesn't seem like a valid option for me to manually run npm install via KUDU or some other terminal in a Cloud Function App - especially with Continoues Deployment etc.
Got the same problem while using canvas for barcode generation...
I've started the Realm-provided realm-electron-advanced-quickstart found here.
Everything works fine when running in dev, but when I package this with electron-builder, the app does not work. I moved createWindow() to the top of the app.whenReady() function so I could see the debugger, and it showed the following message:
Failed to open realm: Error: illegal operation on a directory
at run (renderer.js:26)
at renderer.js:39
Line 26 is
const realm = new Realm(config);
I suspect this is some sort of path/permissions issue with the .realm file.
In main.js, I changed the path in the realm config to
path.join(app.getPath("home"),"my.realm")
But I could not do so on renderer.js.
I would appreciate any ideas or examples of how this has been implemented before.
I'm running Node v14.15.4.
I'm running a next.js react app in a docker container. It's being composed with several other contains: one running Ghost (I'm using the API), one running mysql, and one running NGINX. I've got everything running in development mode.
It works perfectly when run using next dev. But when I run it by doing next build and next start, I start seeing errors like Error: getaddrinfo ENOTFOUND ghost-api when I try to make server-side HTTP requests to my Ghost API container. I'm not entirely sure what the issue is but it seems like there's some issue with how Node is making requests after being built. I've been digging through a lot of Docker/Node questions trying to figure this one out but haven't had any luck.
The entire project can be found here: https://github.com/MichaelWashburnJr/react-cms
The problem may exist in the environment variable that you are using. In both getGhostApi and getGhostApiKey function, you are using the environment variable.
In NextJs you'll have to specify a next.config.js in which you define the variables that you need for
Ex. next.config.js
module.exports = {
serverRuntimeConfig: {
// Will only be available on the server side
mySecret: 'secret',
secondSecret: process.env.SECOND_SECRET, // Pass through env variables
},
publicRuntimeConfig: {
// Will be available on both server and client
staticFolder: '/static',
},
}
You can also refer to the next documentation for the same.
https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration
I'm not able to reproduce the error. How are you starting the frontend container in prod mode?
From the error it appears like you might be trying to start the frontend container or the frontend app as a separate process without starting it as part of the compose project. If that is the case, the name ghost-api won't be resolvable and you would get the Error: getaddrinfo ENOTFOUND ghost-api error.
I've changed the command key of frontend container as follows:
command: [ "yarn", "start-prod" ]
Changed the "start-prod" script in frontend/package.json as follows:
"start-prod": "next build && NODE_ENV='production' next start"
and everything worked as it worked in dev mode. I got some UNKNOWN_CONTENT_API_KEY error in both dev and prod mode but definitely there is no ghost-api name resolution error.
After cloning your repos:
$ grep -R ST_API *
frontend/.env.development:GHOST_API_URL=http://ghost-api:2368
frontend/.env.production:GHOST_API_URL=http://ghost-api:2368
frontend/src/constants/Config.js:export const getGhostApi = () => process.env.GHOST_API_URL || 'http://localhost:8000';
ghost-api is not a domain name: to make it work you need to edit your hosts file or (for a real production environment) to change http://ghost-api:2368 in frontend/.env.production file with the real deploy domain name.
If you are asking why you can't trust on docker compose networking, the answer is: you can, but only in the containers; while the front end will run in the browser of your application client, which is outside the containers.
Hope this helps.
It seems that Docker's hostname resolution does not work during build time. That is why ghost-api is not found.
Instead of referencing the other container by its name (ghost-api), on Mac you can try host.docker.internal. On Linux, using host networking during build worked for me:
nextjs-app:
build:
network: "host"
# ...
network_mode: "host"
This way, you can reference the other container using localhost.
I have an Angular Universal app that I am deploying to Azure App Service (Windows).
When the app runs locally on my Windows 10 PC it works fine but in the cloud it seems like the process.cwd() is different than when I run it locally. This is causing Express.js to look in the wrong place for some view files.
The process pwc should be based on how I executed node, in my case I have a start script in my package.json that executes "node dist/server.js". But I can remove this script and Azure will still start my app. So I think the root of my pwc problem is in how Azure starts up my node app.
Unfortunately Microsoft thinks that some code snippets and a couple John Papa videos is good enough documentation for developers to resolve issues.
Questions
Does documentation exist that explains any configuration or
conventions that the App Service uses to init my node app? Where is
it?
Given the script "start": "node dist/server.js" why would process.cwd() be different on my local host versus Azure App Service? The file structure is the same in both places.
const DIST_FOLDER = join(process.cwd(), 'dist');
app.set('views', join(DIST_FOLDER, 'browser'));
Error: Failed to lookup view "index" in views directory "D:\home\site\wwwroot\dist\dist\browser"
root
package.json
dist
server.js
browser (client app)
server (server app)
Documentation: Not an exhaustive guide, but this is what I found useful on MSDN forums:
Windows Azure Websites uses IISNode to host the Node process inside of IIS. Your Node site is actually given a Named Pipe which receives the incoming requests, not a TCP port like you would use when running locally or hosting yourself.
...
As a node.js application running on Azure Web Apps, needs a server.js or app.js file as the entrance in the root directory with a web.config file to control the iis
Working Directory: When web.config and iisnode are used to run server.js, the rules rewrite the directory to point to where server.js resides. That is why it isn't able to find a subfolder 'dist'.
I had to change the line above to this, in order for it to work on Azure:
const DIST_FOLDER = process.cwd();
Another thing I found important was to set the right version of node for your App Service, using WEBSITE_NODE_DEFAULT_VERSION in App Settings. Here's a bit more info on that from a blog on MDSN - NodeJs and NPM versions on Azure App Services
Since I am used to hosting Node apps on Linux this totally slipped my mind. The answer is...
see web.config
If anyone else finds themselves here put this in your server.ts file to work both locally and on azure
import * as fs from 'fs';
const distFolderExists = fs.existsSync(join(process.cwd(), 'dist'));
const DIST_FOLDER = distFolderExists ? join(process.cwd(), 'dist') : process.cwd();
big thanks to KayS for their answer - really helpful.
I am deploying my first website where I used nodejs in the backend. I am facing an issue for which I have not been able to find a solution for. The website is running perfectly localy and I deployed it a first time with heroku (free version), there was no problem at all.
I just paid for a vps so I would be able to deploy my application with flightplan. Everything works and the website is correctly deployed to the VPS, but when I try to access it with "ip-address:port" I get the following error:
Error: ENOENT: no such file or directory, open './views/base.html'.
Would anyone have an idea on how this happened?
The line that calls the file is:
var file = fs.readFileSync("./views/base.html", "UTF8");
res.status(200).send(file);
Thanks for your help !
Edit:
In the server.js file I use the following line to 'hide' the files in the frontend, could it have something to do with that?
app.use('/webapp', express.static(path.join(__dirname, '/views')));
Found the solution, I don't know why, but the path didn't seem to work properly. Anyway I used
var file = fs.readFileSync(__dirname + "/../views/login.html", "UTF8");
which worked fine