Elasctic Beanstalk platform error on eb create - node.js

I'm setting up an elastic beanstalk for a node server. When running the 'eb create' command I'm getting the following error:
ERROR: NotFoundError - Platform Node.js running on 64bit Amazon Linux does not appear to be valid
I can't find much about it online and the node.js running on 64bit is the way my instance is set so I'm not sure why it is marked as invalid.

(From my comment): This sounds like a bug in the EBCLI. The EBCLI somehow overwrote the platform name in the .config.yml file in an incorrect form.
You can easily fix this by replacing the default_platform field in the .elasticbeanstalk/config.yml file with "node.js", or "64bit Amazon Linux 2017.09 v4.4.5 running Node.js".

Related

sam local invoke failing in nodejs18.x environment

A while ago AWS announced that they had released nodejs18 runtime env support for serverless lambda and lambda#edge services.
I tried to upgrade the whole project to node18.x.
There was first some issue with sam which didn't recognize runtime nodejs18.x.
After upgrading the sam-cli to the latest version. It sounds like it looks for some emulation environment which is not out there. even in amazon ecr public registry.
our service prominently depends on integration testing which uses sam local invoke in it.
and sam local invoke returns the following:
Building image.....................
Failed to build Docker Image
NoneType: None
Error: Error building docker image: The command '/bin/sh -c mv /var/rapid/aws-lambda-rie-x86_64 /var/rapid/aws-lambda-rie && chmod +x /var/rapid/aws-lambda-rie' returned a non-zero code: 1
Does anyone know any workarounds like a custom dockerfile or similar stuff?
update:
sounds like there is a nodejs18.x emulation for sam. but still get the same error on sam local invoke.
update2:
found the issue. I was on a macOS machine and it turned out that I need to declare architecture inside my template file like the following under properties section of serverless lambda conf:
Type: 'AWS::Serverless::Function'
Properties:
Architectures:
- arm64

GitLab fails on install and/or reconfigure

For a college assignment I had to configure gitlab on my virtual machine that’s hosted on google cloud engine and is currently running Ubuntu 20.04.
I tried to install gitlab twice but the install fails (first it got stuck for at least 5 minutes on unpacking github-ce (13.10.2-ce.0) then it failed.
Reconfiguring gets me the same message but without any context, I don’t know where the error is, what is causing it and how to fix it.
I did research this error but the only thing that I found out is that it’s probably related with the config file. Only line in my config line that’s not commented out is the external url and it has a value so I have no idea what to do.
I guess something on the machine is fup. Try the same on a known-good new machine / fresh install.
Ubunut 20.04
Sounds like a fun OS.

Running a bash script in nodejs application deployed on amazon ECS

I have a nodejs application that is deployed on Amazon ECS. I have setup codepipeline to automatically build and deploy the application. The application is dockerized and is deployed on a ubuntu machine. The application is working fine. However, there is a requirement to run a shell script from within the application. I am calling the shell script using await exec(path/to/shellscript). However, I keep getting the following error:
2021-02-08 17:19:48FAILED: undefined, 4e9d8424-3cfd-4f35-93cb-fac886b1c4918fc9f680cfea45ec813db787f8b8380a
2021-02-08 17:19:48/bin/sh: src/myApp/myScript.bash: not found
I have tried giving it permission using chmod but I keep getting errors still.
Any help is appreciated.
I realized that the script that I am running calls an executable created to run on Ubuntu. However, the docker image is an alpine Linux distribution. The issue has been explained in detail here:
Why can't I run a C program built on alpine on ubuntu?

Puphpet provisioning fails on installing node

running the vagrant up on a previously functioning infrastructure fails with the following error
==> default: Error: Command npm is missing
==> default: Error: /Stage[main]/Puphpet_nodejs/Package[express]/ensure: change from absent to present failed: Command npm is missing
Had a look into the responsible script within the VM "/.puphpet-stuff/node_install.sh" and it seems the URL its using to fetch the latest node version is not exists anymore and thats cause this failure.
I found out the correct URL (perhaps changed recently on nodejs.org website and replaced in the file and it works now.
vagrant ssh
sudo vim /.puphpet-stuff/node_install.sh
and change
http://nodejs.org/dist/latest/SHASUMS.txt
To
http://nodejs.org/dist/latest/SHASUMS256.txt

Cross-compile node module with native bindings with node-gyp

I'm using AWS Lambda, which involves creating an archive of my node.js script, including the node_modules folder and uploading that to their infrastructure to run.
This works fine, except when it comes to node modules with native bindings (using node-gyp). Because the binding was complied and project archived on my local computer (OS X), it is not compatible with AWS's (Amazon Linux) servers.
How can I cross-compile/install a node module (specifically, node-sqlite3) so when I upload it to another server arch it runs?
While not really a solution to your problem, a very easy workaround could be to simply compile the native addons on a Linux machine.
For your particular situation, I would use Vagrant. Vagrant can create virtual machines and configure them within seconds.
Find an OS image that resembles Amazon's Linux distro (Fedora, CentOS, others that use yum as package manager - see Wiki)
Use a simple configuration script that, when run by Vagrant on machine startup, will run npm install (optionally it might also remove the node_modules folder before to ensure a clean installation)
For extra comfort, the script can also create the zip file for deployment
Once the installation finishes, the script will shutdown the VM to avoid unnecessary consumption of system resources
Deploy!
It might require some tuning if the linked libraries are not at the same place on the target machine but generally this seems to me like the best and quickest solution.
While installing the app using Vagrant might be sufficient in some cases, I have found it necessary to build the app on Linux which is as close to Lambda's Amazon Linux AMI as possible.
You can read the original answer here: https://stackoverflow.com/a/34019739/303184
Steps to make it work:
Spawn new EC2 instance. Make sure it is based on exactly the same image as your AWS Lambda runtime. You can review Lambda env details here: http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html. In our case, it was Amazon Linux AMI called amzn-ami-hvm-2015.03.0.x86_64-gp2.
Install nvm and use it to install the same version of Node.js as on the AWS Lambda. At the time of writing this, it was v0.10.36. You can refer to http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html again to find out.
You will probably need to install git & g++ compiler on the EC2. You can do this running
sudo yum install git gcc-c++
Finally, clone your app to your new EC2 and install your app's dependecies:
nvm use 0.10.36
npm install --production
You can then easily download the node_modules using scp or such.
Same lines as Robert's answer, when I had to work on my MAC in a different OS I use vm ware like Oracle's free virtualizer VirtualBox to get a linux on my mac, no cost to me. Or sign up for a new AWS account, you get a micro for a year free. Use that to get your linux box, do whatever you need there.
AWS has a page describing how to deal with native NPM modules: https://aws.amazon.com/blogs/compute/nodejs-packages-in-lambda/

Resources