Closed vishal550 closed 1 year ago
Same interest here
Same here, no commits since July, last release on 2021, project abandoned? (hope not)
The current release just crashes with nodejs-16 on alpine linux. Would be great to have a compatible version.
Same interest here
Same interest here.
I got an email from Amazon telling me to upgrade my lambdas to node 16... and then am met with this.
image doesn't build with node:16 any update ? Looks like this project is dead
For what it's worth although it doesn't seem to build with the node:16-buster or node:18-buster images it does seem to build with Node.js installed via the binary archive so, for example I did the following where the first stage build-image differs from the docs in this repo, but the second stage is largely the same:
FROM debian:buster as build-image
RUN apt-get update && \
apt-get install -y \
ca-certificates curl \
make cmake autoconf automake libtool \
libcurl4-openssl-dev g++ python3 && \
# --------------------------------------------------------------------------
# Install LTS Node.js via binary archive
# https://github.com/nodejs/help/wiki/Installation
VERSION=v16.16.0 ARCH=linux-x64 DISTRO=node-${VERSION}-${ARCH} && \
curl -sSL https://nodejs.org/dist/${VERSION}/${DISTRO}.tar.gz | \
tar -xzv -C /usr/local/bin/ && \
# symlink the Node.js binaries to a sane location
ln -s /usr/local/bin/${DISTRO}/bin/node /usr/local/bin/node && \
ln -s /usr/local/bin/${DISTRO}/bin/npm /usr/local/bin/npm && \
ln -s /usr/local/bin/${DISTRO}/bin/npx /usr/local/bin/npx && \
# Build and install Lambda Runtime Interface Client for Node.js via npm
cd /usr/local/lib && \
npm install aws-lambda-ric
FROM node:16-buster-slim
ENV LAMBDA_TASK_ROOT=/usr/local/lib
COPY --from=build-image ${LAMBDA_TASK_ROOT} ${LAMBDA_TASK_ROOT}
COPY lambda-entrypoint.sh /
COPY echo.js ${LAMBDA_TASK_ROOT}
WORKDIR ${LAMBDA_TASK_ROOT}
ENTRYPOINT ["/lambda-entrypoint.sh"]
CMD ["echo.handler"]
and for Node.js 18
FROM debian:buster as build-image
RUN apt-get update && \
apt-get install -y \
ca-certificates curl \
make cmake autoconf automake libtool \
libcurl4-openssl-dev g++ python3 && \
# --------------------------------------------------------------------------
# Install LTS Node.js via binary archive
# https://github.com/nodejs/help/wiki/Installation
VERSION=v18.15.0 ARCH=linux-x64 DISTRO=node-${VERSION}-${ARCH} && \
curl -sSL https://nodejs.org/dist/${VERSION}/${DISTRO}.tar.gz | \
tar -xzv -C /usr/local/bin/ && \
# symlink the Node.js binaries to a sane location
ln -s /usr/local/bin/${DISTRO}/bin/node /usr/local/bin/node && \
ln -s /usr/local/bin/${DISTRO}/bin/npm /usr/local/bin/npm && \
ln -s /usr/local/bin/${DISTRO}/bin/npx /usr/local/bin/npx && \
# Build and install Lambda Runtime Interface Client for Node.js via npm
cd /usr/local/lib && \
npm install aws-lambda-ric
FROM node:18-buster-slim
ENV LAMBDA_TASK_ROOT=/usr/local/lib
COPY --from=build-image ${LAMBDA_TASK_ROOT} ${LAMBDA_TASK_ROOT}
COPY lambda-entrypoint.sh /
COPY echo.js ${LAMBDA_TASK_ROOT}
WORKDIR ${LAMBDA_TASK_ROOT}
ENTRYPOINT ["/lambda-entrypoint.sh"]
CMD ["echo.handler"]
This was with a trivial echo lambda
"use strict";
exports.handler = async (event, context) => {
return event;
}
One other thing I observed is that with Node 16 and 18 npx seems to launch less "cleanly", there seems to be a sh -c rather than directly execing node, so I observed aws-lambda-ric starts fine, but segfaults (or the launcher does) if its HTTP connection is disconnected. That doesn't happen if aws-lambda-ric is run directly with node, so my lambda-entrypoint.sh looks like this:
#!/bin/sh
if [ $# -ne 1 ]; then
echo "entrypoint requires the handler name to be the first argument" 1>&2
exit 142
fi
if [ -z "${AWS_LAMBDA_RUNTIME_API}" ]; then
#exec /usr/local/bin/aws-lambda-rie /usr/local/bin/npx aws-lambda-ric "$1"
exec /usr/local/bin/aws-lambda-rie node /usr/local/lib/node_modules/.bin/aws-lambda-ric "$1"
else
#exec /usr/local/bin/npx aws-lambda-ric "$1"
exec node /usr/local/lib/node_modules/.bin/aws-lambda-ric "$1"
fi
Hopefully this is useful and helps give folks an approach that lets them continue to use the official node node:16-buster or node:18-buster images.
As has been pointed out elsewhere it's also possible to "kidnap" the aws-lambda-ric from the official AWS base images. That actually appears somewhat different to the aws-lambda-ric in this repo, though that may be superficial/packaging differences. Like others here I think AWS should at least give a heads-up/ETA of when up to date versions of Node.js will be properly supported, especially as the official AWS images are kind of large......
HTH
@fadams I managed to make the "kidnap" option work (pretty well so far) for Node 18. Given my unique needs, that turned out to be the best option. It's unfortunate AWS support has been so lacking.
Anyhow, if it's helpful to anyone else, this was my multi-stage Dockerfile
:
FROM public.ecr.aws/lambda/nodejs:18 as lambda-image
FROM node:18
RUN ln -sf bash /bin/sh
RUN mkdir /var/task
WORKDIR /var/task
RUN apt-get update && \
apt-get install -y \
g++ \
make \
cmake \
unzip \
libcurl4-openssl-dev \
autoconf \
libtool \
libtool-bin
ENV LAMBDA_RUNTIME_DIR=/var/runtime
ENV LAMBDA_TASK_ROOT=/var/task
RUN mkdir /var/lang
RUN ln -s /usr/local/bin /var/lang/bin
COPY --from=lambda-image /lambda-entrypoint.sh /lambda-entrypoint.sh
COPY --from=lambda-image /var/runtime /var/runtime
COPY --from=lambda-image /usr/local/bin/aws-lambda-rie /usr/local/bin/aws-lambda-rie
ADD . .
RUN npm i
ENTRYPOINT ["/lambda-entrypoint.sh"]
CMD ["index.handler"]
Hi,
We investigated the issue and have updated instructions on how to use the RIC with Node16+.
Summary of the issue:
Starting from npm@8.6.0
, npm writes logs under the /home/.npm dir: https://github.com/npm/cli/pull/4594
This is not possible inside the Lambda execution env since the fs is read-only. In earlier versions of npm, there was a bug which caused it to silently fail when unable to write cache directory: https://github.com/npm/cli/issues/4996, hence why the runtime was just returning the 254 error code. There are some ways to prevent this:
/tmp
using a Docker ENV var:
ENV NPM_CONFIG_CACHE=/tmp/.npm
yarn
instead of npm
since it fallbacks to /tmp if the preferred cache folder isn't writableENV NPM_CONFIG_CACHE=/tmp/.npm
inside Lambda as an env varaws-lambda-ric
directly using node instead of using npx
by when it will support node 16