I created a new Node.js app on Bluemix this morning and downloaded the boilerplate code. I worked on it locally and then pushed it up. On Bluemix, it refuses to start. The error according to the logs is:
Instance (index 0) failed to start accepting connections
So I Googled for that, in every case where I found the result, the answer was that my application was trying to use a specific port instead of letting Bluemix set it.
Ok, but I'm setting the host/port with the exact code the boilerplate uses:
var appEnv = cfenv.getAppEnv();
// start server on the specified port and binding host
app.listen(appEnv.port, function() {
// print a message when the server starts listening
console.log("server starting on " + appEnv.url);
});
So if this is incorrect, it means the code Bluemix told me to download itself is incorrect as well, and I can't imagine that is the issue.
To identify whether cfenv is at fault, I've tested that piece of code with a number of more complex Node.js apps I have, and they work perfectly on Bluemix.
That message can also come when an application you've deployed to Bluemix fails to start at all. Here's a few things you can do to troubleshoot your Node.js application on Bluemix.
Tail logs in another terminal while pushing with "cf logs
". Inspect logs after the failure to see if something
failed during the staging process.
Check that your start command in one of two recommended places, scripts.start in package.json or in a Procfile with web: node <start-script>.
Check that your application works locally. First (optional), create a .cfignore file with "/node_modules" in it, so that when you push the app to Bluemix, CF CLI doesn't push your entire folder of node_modules (as they will be installed dynamically). Next, wipe out your node_modules directory and do an npm install --production followed by npm start (or your custom start command). This is what Bluemix does when trying to start your application, so you should double check that it works locally.
Finally, try bumping up your memory, although this is very unlikely that this is why your application fails to start.
Related
I am new to google cloud and so I deployed a Nodejs app using the tutorial. Everything worked just fine, here is my file structure (I didn't make the my-nodejs-service folder):
app.yaml
server.js
package.json
I deployed it, everything was fine. So then I tried to make it look like this:
mySite/
server.js
package.json
app.yaml
public/
site contents
I just forked a github repo, deployed it, and it didn't work. By that I mean the site didn't load! I checked the logs, and here was what appeared:
Error: Cannot find module '/workspace/server.js'
at Function.Module._resolveFilename (loader.js:880)
at Function.Module._load (loader.js:725)
at Function.executeUserEntryPoint (internal/modules/run_main.js:72)
"GET / HTTP/1.1" 500
listening on port 3000
It said it couldn't find the server.js file. Was it because I moved the code into the folder? I deployed it on the current working directory being the folder mySite.
package.json (Im only including the scripts part, it other stuff such as the dependencies):
{
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "node server.js"
}
}
Other things I tried:
deploying with app.yaml at the end of the deployment command
Using path.join()
Deploying multiple times
Other info:
I checked the logs and I got this:
"GET / HTTP/1.1" 500 - - "Web browser agent info in here"
Another showed:
i This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.
And another log said:
!! Process was terminated because the request deadline was exceeded. Please ensure that your HTTP server is listening for requests on 0.0.0.0 and on the PORT environment variable. (Error code 123)
App Engine uses a set of conventions in order to be able to deploy and run code successfully. As you've seen, you can't necessarily take an arbitrary web server solution and deploy it successfully.
Please include more details about specific steps you take. For example, you say "I .. deployed it". It would be useful for you to include the command that you used and any immediate errors that were thrown to provide readers with more context when helping answer your question. It's unclear to me from which directory you attempted to deploy the mySite example but I assume from within mySite.
The first error Cannot find module '/workspace/server.js' results because App Engine builds your code using Cloud Build and Cloud Build (by default) puts your code into a /workspace directory on the build VM. It's not very user-friendly, but it was unable to find server.js and, because your package.json specifies node server.js, it needs it.
Another statement that gives me pause is listening on port 3000. I'm not very familiar with the Node.JS runtime but generally App Engine expects web server's to either listen on port :8080 or provide an environment variable that specifies the port, In your tutorial, this is explained: "process.env.PORT is not set, port 8080". That's probably (!?) another issue.
Lastly, you may (I think you probably don't) need to explicitly reference the public subdirectory (unsure) in order to ensure that it's available at runtime.
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'm trying to run Heroku applications locally via 'heroku local,' but a missing module error is occurring in the Heroku CLI. Is this a Heroku bug that just needs to be reported or is there something wrong with how things have been setup on my machine (mac)? Any suggestions are appreciated.
In order to ensure my application isn't the problem, I've been debugging this issue with the node application Heroku provides in its getting started guides. Meaning, it already has a Procfile that can be run using default settings.
Things I've tried:
Re-install node modules for both application and CLI
Re-install the Heroku CLI
Here's the error:
node-js-getting-started [master] :> heroku local
Error: Cannot find module '../../load-foreman-procfile'
at Object.<anonymous> (/usr/local/Cellar/heroku/7.26.1/libexec/node_modules/#heroku-cli/plugin-local/lib/commands/local/index.js:5:18)
The file for the route above requires a 'load-foreman-procfile' like so:
const Procfile = require('../../load-foreman-procfile');
That require path doesn't lead to a to file by that name. In fact, this is the only reference to 'load-foreman-procfile' I can find in '/usr/local/Cellar/heroku/7.26.1'.
Rather than the error code above, I would expect heroku local to yield a running local server started via my Procfile.
I got the same error running heroku-cli v7.26.0. I switched to their edge channel (currently v7.26.2) and heroku local worked for me after that.
like #sophon mentioned - updating from v7.26.0 to v7.26.2 solved this for me. heroku update on mac did the trick.
I am trying to assist in setting up AppDynamics with an Angular 2 app that is hosted in IIS. The app is already up and running. There is a part I am having trouble on, the instructions for that part say say:
1) From the root directory of your Node.js application, run this command:
npm install appdynamics#4.3.5
For every Node.js application you are instrumenting, insert the following call in the application source code at the first line of the main module (such as the server.js file), before any other require statements:
require("appdynamics").profile({
controllerHostName: '<controller host name>',
controllerPort: <controller port number>,
controllerSslEnabled: false, // Set to true if controllerPort is SSL
accountName: '<AppDynamics_account_name>',
accountAccessKey: '<AppDynamics_account_key>',
applicationName: 'your_app_name',
tierName: 'choose_a_tier_name',
nodeName: 'choose_a_node_name'
});
2) Restart you application
I did step 1 locally in the console, but I don't know what to do for step 2. If I add that script to the page I get "The Reference error: require is not defined".
I learned that that function is not meant to run on the browser. It's meant to be run server-side, but I do not see node js or any server.js files on our dev web server.
Does anyone have any suggestions on where to put that snippet. Will it even work with the current setup?
It turns out the code I was given was completely wrong for angular 2 implementation. The code they gave me is for running on the web server's side with node js. Since angular 2 is an SPA that runs on the browser, it would never work.
I did some research and found this example application that I added a few tweaks to: https://github.com/derrekyoung/appd-sampleapp-angular2
I have an electron app where I need not only to run the interface to the user but also start an express server that will serve files for people connected through the network.
I have everything working if I start both electron and the express server normally, but I'm pretty confident that I will need the server running in a different thread to avoid slugish interface and even problems with the server.
For that matter I tried to run my express server using the child_process.fork and it worked when I use npm start, but when I use electron-builder to create an .exe, the installed program doesn't start the express server.
I tried to run my server right away using:
require('child_process').fork('app/server/mainServer.js')
I tried several changes, prefixing the file with __dirname, process.resourcesPath and even hard coding the generated file path; changing the fork options to pass cwd: __dirname, detached: true and stdio: 'ignore'; and even tried using spawn with process.execPath, which will also work with npm start but won't when packaged (it keeps opening new instances of my app, seems obvious after you do hehe)
Note: If I don't fork and require the server script right away, using require('server/mainServer.js') it works on the packaged app, so the problem most like isn't the express itself.
Note 2: I have asar: false to solve other problems, so this is not the problem solver here.
I put up a small git project to show my problem:
https://github.com/victorivens05/electron-fork-error
Any help will be highly appreciated.
With the great help from Samuel Attard (https://github.com/MarshallOfSound) I was able to solve the problem (he solved for me actually)
As he said:
the default electron app will launch the first file path provided to it
so `electron path/to/thing` will work
in a packaged state, that launch logic is not present
it will always run the app you have packaged regardless of the CLI args passed to it
you need to handle the argument manually yourself
and launch that JS file if it's passed in as the 1st argument
The first argument to fork simply calls `process.execPath` with the first
argument being the path provided afaik
The issue is that when packaged Electron apps don't automatically run the
path provided to them
they run the app that is packaged within them
In other words. fork is actually spawn being executed with process.execPath and passing the fork's first argument as the second for spawn.
What happens in a packaged app is that the process.execPath isn't electron but the packaged app itself. So if you try to spawn, the app will be open over and over again.
So, what Samuel suggest was implemented like this:
if (process.argv[1] === '--start-server') {
require('./server/mainServer.js')
return
}
require('./local/mainLocal.js')
require('child_process').spawn(process.execPath, ['--start-server'])
That way, the first time the packaged app will be executed, the process.argv[1] will be empty, so the server won't start. It will then execute the electron part (mainLocal in my case) and start the app over, but this time passing the argv. Next time the app starts, it will start the server and stop the execution, so the app won't open again because spawn is never reached.
Huge thanks to Samuel.