I have a node application on GAE (Google App Engine) flex environment. In the code, package.json specifies: "node": "8.11.4":
{
"name": "prismic-universal-app",
"version": "1.0.0",
"description": "",
"main": "public/js/compiled/server.js",
"engines": {
"node": "8.11.4"
},
"scripts": {
...
But when I open a Cloud Shell window from the google cloud console the project and run 'node --version', I get v8.9.4
Reading through google's documentation, I don't see anything yet about using a different version from what's in package.json. Does anyone know if google has another way to determine what version of node will ultimately be used? Or is there another spot where Node.js version can be set that may be conflicting with package.json?
The Cloud Shell is a GCP product separate from GAE (flexible). It does not execute on your GAE flexible app instance. From Virtual machine instance:
When you start Cloud Shell, it provisions a g1-small Google Compute
Engine virtual machine running a Debian-based Linux operating
system.
The info you obtained is from that VM.
To check the info on your GAE flexible app instance, you need to connect to it specifically, see Connecting to the instance.
Related
Migrating your Elastic Beanstalk Linux application to Amazon Linux 2 - AWS Elastic Beanstalk
According to the docs, the aws:elasticbeanstalk:container:nodejs namespace is no longer supported and the new way to set NodeCommand is to "Use a Procfile or the scripts keyword in a package.json file to specify the start script.".
I've never dealt with Procfiles and the part "the scripts keyword in a package.json file" isn't very clear, are they going to execute the scripts in order, until something sticks or what?
Did anyone figure out how exactly to set a custom NodeCommand in Amazon Linux 2?
you can use script option in your package.json. For example, if you start sample node.js application that EB provides, the file is:
package.json
{
"name": "Elastic-Beanstalk-Sample-App",
"version": "0.0.1",
"private": true,
"dependencies": {},
"scripts": {
"start": "node app.js"
}
}
Update
Docs have example how to use Procfile:
You can add a Procfile to your source bundle to specify the command that starts your application, as the following example shows. This feature replaces the legacy NodeCommand option in the aws:elasticbeanstalk:container:nodejs namespace.
web: node index.js
When you don't provide a Procfile, Elastic Beanstalk runs npm start if you provide a package.json file. If you don't provide that either, Elastic Beanstalk looks for the file app.js or server.js, in this order, and runs it.
I can run the app locally without any issue by yarn start command. here I have provided photographs which represent my problem. I googled and noticed several people faces the same problem. but their context is different.
By default, Now publishes your files as a static directory. You can add a builder to your now.json file to tell Now how to build and deploy your site.
In a case where app.js contains a web server application, your now.json might look like this:
{
"version": 2,
"name": "my-project",
"builds": [
{"src": "app.js", "use": "#now/node"}
]
}
This tells Now to use the #now/node builder to generate a lambda that runs app.js to respond to requests.
If your app is purely js+html to be run on the client machine, you wouldn't need the lambda, but you can still build the source before deploying it as static files with #now/static-build.
Check out the Now docs for more info: https://zeit.co/docs/v2/deployments/basics/#introducing-a-build-step
Good day,
my very basic Nodejs app is deployed on a Google Cloud App Engine instance is not starting. The app works locally, deployment with app deploy runs without error - and on the app instance the app runs successfully when started manually through Cloud shell (with >npm start).
However, as soon as the Cloud Shell is closed my app is dead. What am I missing? How do I start-up the app to run permanently?
The app consists of
bot4.js file,
npm dependencies
app.yaml
package.json
app.yaml:
runtime: nodejs8
handlers:
- url: /
script: auto
package.json:
{
"name": "blexplorer",
"version": "1.0.0",
"description": "",
"main": "bot4.js",
"scripts": {
"start": "node bot4.js"
},
"author": "oystersauce",
"license": "ISC",
"dependencies": {
"discord.js": "^11.4.2",
"request": "^2.88.0"
}
}
Again, the app is running fine when started through the Cloud Shell but no longer, as soon as the Cloud Shell is closed. Also, it's a super simple discord-bot - hence there is no front-end whatsoever.
EDIT:
this is how I thought I started the app manually - but what I did here is starting the app within the cloud shell and not on the app instance:
here is how I deploy the app:
From GAE perspective the cloud shell is simply a shell on a "local" development machine which just happens to be hosted in the cloud. The instance running the cloud shell has no special relationship with GAE whatsoever.
What you're doing when running npm start is not actually starting the GAE instance, you're just starting a "local" execution of your service, just like when you'd be doing the same on your local machine.
With your configuration GAE should start your app automatically as soon a request for it is received. On an app with a frontend just clicking on the link you circled in the snapshot would get you on it. Since yours doesn't have a frontend it would probably be just started, but you'd have to rely on the dashboard info and/or your app's logs to confirm it is running.
We are having some problems with the node version in production, so we changed the version required in the package.json from 0.10.0 to 6.2.2..
"engines": {
"node": ">= 6.2.2"
}
However in Elastic Beanstalk, when new instances are created they appear with node version of 0.10.0. How can we update the version in Elastic Beanstalk so the new instances created have the required version placed in package.json?
Thank you very much.
Verifying the version is supported
Most newer Beanstalk platforms have up to 6.2.2 for Node.js so if your platform version is up to date you should have it (current platform version for Node.js is v2.1.3).
If you do not want to update your current platform you can verify which versions are valid using the AWS CLI:
aws elasticbeanstalk describe-configuration-options --solution-stack-name "64bit Amazon Linux 2016.03 v2.1.3 running Node.js" --options "OptionName=NodeVersion, Namespace=aws:elasticbeanstalk:container:nodejs"
Which should return something like:
{
"Options": [
{
"Name": "NodeVersion",
"UserDefined": false,
"DefaultValue": "4.4.6",
"ChangeSeverity": "RestartApplicationServer",
"Namespace": "aws:elasticbeanstalk:container:nodejs",
"ValueType": "Scalar",
"ValueOptions": [
"0.8.28",
"0.10.46",
"0.12.15",
"4.4.6",
"5.12.0",
"6.2.2"
]
}
],
"SolutionStackName": "64bit Amazon Linux 2016.03 v2.1.3 running Node.js"
}
Making it work
In order for your application to start up with correct Node version you will have to set the option setting for the specific version. This can be done multiple ways.
Web UI
Navigate to the Configuration tab for your environment and then into the Software Configuration panel to change the Node version setting. Click apply when you are finished to deploy the changes to your environment.
AWS CLI
You can update your environment with the correct option setting via the command line interface.
aws elasticbeanstalk update-environment --environment-name yourEnvName --option-settings "OptionName=NodeVersion, Namespace=aws:elasticbeanstalk:container:nodejs, Value=6.2.2"
Here are some additional option settings specific to the Node.js platform.
I am trying to run a node.js application that uses PouchDB (a local CouchDB implementation). I can run this successfully locally and even upload it and build it on my Bluemix instance. However, whenever I send a request to my app, I do not get a response and I see the following error in my Bluemix console:
[Error: Module version mismatch. Expected 46, got 14. This generally implies that leveldown was built with a different version of node than that which is running now. You may try fully removing and reinstalling PouchDB or leveldown to resolve.]
I have tried to add npm rebuild into my build pipeline above the npm install, which I can see does indeed do a rebuild. However, I still get the previous error.
A bit about my app: It is a bot for the Slack platform. A user sends a command and my Bluemix app then responds. My Bluemix app has multiple documents that PouchDB stores. As I say, all this runs and responds correctly on my development machine.
Here is my package.js for reference:
{
"name": "XXXXXXXXXXX",
"version": "0.x.0",
"description": "XXXXXXXXXXXX",
"main": "app.js",
"scripts": {
"start": "node app.js"
},
"repository": {
"type": "git",
"url": "XXXXXXXXXXX"
},
"keywords": [
"slack",
"bot",
"nodejs"
],
"author": "xxxxxxxxx",
"license": "MIT",
"dependencies": {
"bluebird": "^3.1.1",
"body-parser": "^1.14.2",
"cfenv": "^1.0.3",
"cheerio": "^0.19.0",
"express": "^4.13.3",
"pouchdb": "^5.1.0",
"request-promise": "^1.0.2"
},
"engines": {
"node": "^4.2.x",
"npm": "^2.14.x"
}
}
Also some additional history: I ran a prior version of my app on Bluemix when I was using MongoDB instead of PouchDB. My node version at the time was the default that Bluemix gave me when I started, which was version 0.12.x. However, this version didn't support arrow functions, which I make heavy use of now. Hence, the bump to node 4.2.x.
Thanks!
Edit: After some digging I found out that 'leveldown' (a dependency of PouchDB) makes use of npm prebuilds where available. What this means is that if a prebuild is available on their GitHub it will be downloaded instead of the source, as a convenience. Looking through the logs I notice that version 1.4.2 is being downloaded as the prebuild version through Bluemix. However, there is a version 1.4.3 available that looks like it solves my 'Expected 46, got 14` issue. So the new question is why is Bluemix doing this and how can I rectify it?
I tried to push on Bluemix the same version that you are using ("^5.1.0") in your package.json and it is working fine, even using node engine "4.0.x".
Moreover according to CF infrastructure, the runtime is build during application staging step, so the pouchdb module should be built with the right dependencies and references.
Have you tried to push your application again in order to force a full application restage?
If yes, the first step to understand what is going on is to get the application logs during the staging process and also as soon as this error message is returned.
So, on your terminal, run the following commands:
1 - cd into your source directory
2 - connect to Bluemix API
cf api https://api.[REGION].bluemix.net

where [REGION] is one of
eu-gb for United Kingdom
ng for US South
au-syd for Sydney
3 - Login to Bluemix and choose the right ORG and SPACE
cf login -u [BLUEMIX USERNAME]
cf target -o [BLUEMIX ORG] -s [BLUEMIX SPACE]
4 - push your application and, as soon as it has been staged, run
cf logs [app-name] --recent > staging_output.txt
5 - tail the application logs, running
cf logs [app-name]
and without closing it make the request that is generating the error message
6 - check the output generated at step #5 for details on where in the code your application is failing and on the failing module
After a lot of debugging the answer, as ever, was to delete my Bluemix application first and then push a new version via the build system. The leveldown prebuilt npm package that was causing the error was cached somewhere. I could only get rid of this by deleting my app. Nothing special there.