rnag / rust.aws-cdk-lambda Goto Github PK

I've created a repo using the setup in cdk-examples/rust-standalone.

I want to do local testing (run this lambda as a server on localhost and make HTTP GET requests to it), so I've tried running this:

sam local start-lambda --port 3000 --template ./cdk.out/RustStandaloneStack.template.json

The server successfully starts up, but I can't figure out what sort of request to send it. It just responds with a 404 no matter what path or headers I specify to it with my GET requests.

By comparison, one-off invocations work just fine:

# ./tests/sample.json is an event matching the same format of the one seen in this issue comment:
# https://github.com/awslabs/aws-lambda-rust-runtime/issues/365#issue-1054795934
$ sam local invoke MyRustLambda --event ./tests/sample.json --template ./cdk.out/RustStandaloneStack.template.json

Requesting using the exact same path and headers specified in my ./tests/sample.json file, I am met with a 404 response.

Usage with the SAM CLI may be out of scope, but I was hoping you might happen to know!

Hey, it looks like RustFunction is trying to execute cargo lambda upon synth, which in my opinion shouldn't happen. I have multiple stacks and don't want to compile the rust function every time I deploy one of the stacks (most don't include rust functions)

The goal here is quite simple, but ideally we want to provide a way for users to compile rust code in a containerized manner, perhaps leveraging Docker and an Amazon Linux build image. If the host machine doesn't have rustup or cargo-zigbuild installed, we should by default use Docker to build and compile rust code.

The end goal would probably be to find a suitable Docker container, so if the container for example has zigbuild and zig already installed, that would be ideal; though of course if the architecture in the Docker container matches the target, then there's a chance we might not need zigbuild in such a case.

We could also take inspiration from other similar NPM libraries such as aws-lambda-go, which does also support building code in a Docker environment.

Docker Image

For the actual Docker image to use, I'm still open to suggestions as mentioned above, so ideally an image that comes with tools like cargo-zigbuild and cross already installed. I think an excellent starting point would be to look into the image that softprops/lambda-rust provides:

https://github.com/softprops/lambda-rust

Hi 👋

This is a really cool project, thanks for putting it together!

I wanted to let you know about this other project I started a few weeks ago and we recommend for people using the Rust runtime for Lambda:

https://github.com/calavera/cargo-lambda

It abstracts away cargo-zigbuild, and also installs Zig for people automatically. It would allow you to reduce the code necessary to compile and locate functions significantly. Check it out and let me what you think about it. I can also help you integrate it if you're interested.

Using the latest build 1.2.1, it seems that specifying buildEnvironment as a param to multiple RustFunction instances causes only the first passed env vars for the first hit RustFunction instance to be passed for all following creations of RustFunction.

Minimum example:

const foo_lambda = new RustFunction(this, 'foo_lambda', {
	directory: path.resolve(path.join(__dirname, '../lambda')),
	package: 'foo',
	buildEnvironment: {
		FOO_ENV: 'foo',
	},
})

const bar_lambda = new RustFunction(this, 'bar_lambda', {
	directory: path.resolve(path.join(__dirname, '../lambda')),
	package: 'bar',
	buildEnvironment: { 
		BAR_ENV: 'bar' 
	},
})

With the rust code doing e.g.:

const FOO_ENV: &str = env!("FOO_ENV");
const BAR_ENV: &str = env!("BAR_ENV");

I'm getting the error when compiling the second rust functionenvironment variable "BAR_ENV" not defined, however - the FOO_ENV is available for the second function. If reversing the order of the two RustFunctions, now BAR_ENV is available, and compilation will fail with FOO_ENV not defined.

This issue can be worked-around by building each package individually by doing:

import { Settings } from 'rust.aws-cdk-lambda'
Settings.BUILD_INDIVIDUALLY = true

I'm using local dependencies in my Lambda cargo.toml.
Like this:

my_tools = { path = "../../shared/rust/my_tools/" }

And it seams like rust.aws-cdk-lambda does not likes it. cdk synth fails with an error

Error: Cannot find asset at /Users/....

Meanwhile cargo lambda build --output-format zip works well.

Would appreciate any workaround.

TypeError: Cannot read properties of null (reading 'toString')

This rather cryptic error is thrown from:

... when trying to call cargo.stderr.toString(). The reason is that cargo.stderr may be null if a cargo executable was not found by the call to spawnSync('cargo' /* ... other args... */).

Troubleshooting:

If, when you run which cargo in your usual shell, you get cargo not found or similar, then you need to make sure the cargo executable is both installed and on your shell's path.

Recommendations:

I think ideally this library should have some way of double-checking whether cargo is indeed on-path (I'm not sure what the usual approach for this is), but this kind of environment health-check may arguably be out-of-scope.

At the very least, it would save some onboarding friction if this library could, in the event of cargo.stderr being null, suggest that perhaps cargo is either not installed or not on path.

This issue derives from an understandable concern in this Reddit thread. Essentially it can be summed up as follows:

[...] I'm just worried that this is just working so far by chance, because if the aarch64-unknown-linux-gnu default glibc version ever increases to a version higher than the AL2 glibc then everything will stop working.

So basically, in our case it would be a good idea to specify the glibc version - when running zigbuild at least, I'm not sure if cross supports it.

It might be worth it to hardcode glibc=2.26, as I believe that's what the docs on amazon linux 2 seem to indicate is the version of glibc that the AL2 runtime uses.

Resolution

As suggested in the same Reddit thread, we easily specify glibc version when running zigbuild - for example, to compile for glibc 2.26 (which is what AL2 uses) with the aarch64-unknown-linux-gnu target:

cargo zigbuild --target aarch64-unknown-linux-gnu.2.26

It seems that some crates rely on native openssl. Building on my M1 mac I receive an error that the openssl cannot be found. I assume it is because I am building for Linux. Did you encounter this problem and how did you manage to solve it?

Since the whole stack is about to be deleted, there's no need to rebuild it, right?

% cdk destroy
🍺  Building Rust code with `cargo lambda`. This may take a few minutes...
🎯  Cross-compile `s3-rust-noodles-bam`: 119.11s
🎯  Cross-compile `apigw`: 0.00s
Are you sure you want to delete: s3-rust-noodles-bam (y/n)?