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.
Related
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.
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.
I'm struggling to figure out how to deploy multiple nodejs services on google app engine flexible.
I'm using multiple nodejs classes with firebase-queue to process my tasks.
Right now, i'm using my package.json to trigger starting everything at once.
However, this has become problematic. I would like to be able to push a change to one particular service/script without having to stop every other script.
My package.json currently looks like something like this:
"scripts": {
"task1": "node ./src/task1.js",
"task2": "node ./src/task2.js",
"start": "npm-run-all -p task1 task2"
}
I'm using different .yaml files to determine which build variant I want to push (Debug or Release) but am finding it hard to deploy each task individually. I found documentation on how to do so in python, but nothing on nodejs. Does anyone have any suggestions?
(Answering my own question, big thanks to Justin for helping)
I was specifically having issues dynamically changing the script to start in my package.json.
I found the package.json can access environment variables using '$'
package.json:
"scripts": {
"start": "node $SCRIPT_TO_RUN"
}
myService.yaml
runtime: nodejs
vm: true
api_version: 1
instance_class: B4
manual_scaling:
instances: 1
service: cart-monitor-dev
env_variables:
SCRIPT_TO_RUN: './src/mytask.js'
Then deploy using:
gcloud app deploy myService.yaml
This is exactly why App Engine services exist :) You can create a {serviceName}.yaml for each service you want to deploy. Then, call gcloud app deploy service.yaml for each one. That creates multiple services in the same app. For an example see:
https://github.com/JustinBeckwith/cloudcats
Hope this helps!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
How does one deploy a production MeteorJS app to Windows Azure?
Yes it is. See http://www.meteorpedia.com/read/Deploying_to_a_PaaS
In most cases this is as simple as using "meteor bundle",
demeteorizer, and then uploading the resulting files with your PaaS
provider's CLI deploy tool.
Demeteorizer wraps and extends Meteor’s bundle command by creating
something that more closely resembles a standard looking Node.js
application, complete with a package.json file for dependency
management.
$ cd /my/meteor/app
$ demeteorizer -o /my/node/app
$ cd /my/node/app
$ npm install
$ export MONGO_URL='mongodb://user:password#host:port/databasename?autoReconnect=true&connectTimeout=60000'
$ export PORT=8080
$ forever start main.js
Forever keeps your app running after a disconnect or crash, but not a reboot unless you manually add a boot entry.
The whole deploy is much easier using Meteor Up instead. Or maybe mups, though that doesn't even have updated docs.
To run a Meteor app in an Azure web app:
Azure Web App
Python 2.7
Websockets ON (optional)
WEBSITE_NODE_DEFAULT_VERSION 0.10.32 (default)
ROOT_URL http://webapp.azurewebsites.net
MONGO_URL mongodb://username:password#instance.mongolab.com:36648/dbname (For advanced apps. Request log should say if you need it.)
Dev Machine
Install Visual Studio Community 2015
Install Node 0.12.6
Install Meteor MSI
app> demeteorizer -o ..\app-dem
app-dem\programs\server\packages\webapp.js change .PORT line to "var localPort = process.env.PORT"
app-dem\package.json change "node": "0.10.36" to "node": "0.12.6"
app-dem> npm install
app-dem> git init
app-dem> git add -A .
app-dem> git commit -m "version 1.0 demeteorized Meteor + tweaks"
app-dem> git remote add azure https://username#webapp-slot.scm.azurewebsites.net:443/webapp.git
app-dem> git config http.postBuffer 52428800
app-dem> git push azure master
Instead of demeteorizer -o, perhaps you could use meteor build and create a package.json in the output root:
{
"name": "App name",
"version": "0.0.1",
"main": "main.js",
"scripts": {
"start": "node main.js"
},
"engines": {
"node": "0.12.6"
}
}
If bcrypt doesn't compile, make sure to use a more recent version:
"dependencies": {
"bcrypt": "https://registry.npmjs.org/bcrypt/-/bcrypt-0.8.4.tgz"
}
Before starting make sure your have install'd a 32 bit version of nodejs and have run "npm -g install fibers" on your windows build machine. Default nodejs on azure is running 32 bit only!
Note: this will not work if you'r using for example the spiderable package which relays on PhantomJS. PhantomJS can not be executed in a webapp on azure?
In your project "meteor build ..\buildOut" and extract the .tar.gz file located in "..\buildOut".
Place/create in "..\buildOut\bundle" a "package.json" containing:
{
"name": "AppName",
"version": "0.0.1",
"main": "main.js",
"scripts": {
"start": "node main.js"
},
"engines": {
"node": "0.12.6"
}
}
Note: Make sure "name" doesn't contain spaces, the deploy on azure will fail.
On your favorite shell, goto "..\buildOut\bundle\programs\server" and run "npm install". This will pre download all the requirements and build them.
Now open the file "..\buildOut\bundle\programs\server\packages\webapp.js" and search for "process.env.PORT".
it looks like this:
var localPort = parseInt(process.env.PORT) || 0;
alter this line into:
var localPort = process.env.PORT || 0;
This is needed so your meteor project can accept a named socket as soon as it runs in node. The function "parseInt" will not let a string go thru, the named socket is a string located in your webapp's environment. This my be done for a reason, a warning here! Now save this change an we are almost done...
Solve the bcrypt issue: Download this file and extract it somewhere: https://registry.npmjs.org/bcrypt/-/bcrypt-0.8.4.tgz
Extract it.
Now replace the files located: "..\buildOut\bundle\programs\server\npm\npm-bcrypt\node_modules\bcrypt*"
with the directory's and file's located somewhere: ".\bcrypt-0.8.4\package*"
Now go on the shell in the directory "..\buildOut\bundle\programs\server\npm\npm-bcrypt\node_modules\bcrypt\" and make sure you remove the "node_modules" directory. If the node_modules directory is not removed npm will not build the package for some reason.
Run on the shell "npm install".
Make sure you set the "Environment" variables: "MONGO_URL" and "ROOT_URL" in the portal for you webapp.
If everything worked without an error, you can deploy your app to the git repository on the deployment slot for your webapp. Go to "..\buildOut\bundle" and commit the files there to the deployment slot's repository. This will course the deploy on the deployment slot and create the needed iis configuration file(s).
Now wait a little and your app should fire after some time... Your app should be running and you can access it on the *.azuresites.net
Thanks to all that made this possible.
How can I change the name of default starter script for node on openshift ?
default starter script is server.js.
I saw a thread on openshift forum, however it is difficult for me to understand.
Take a look in the package.json file, and you should see this:
"main": "server.js"