search

lambci / docker-lambda

Docker images and test runners that replicate the live AWS Lambda environment
MIT License
5.83k stars 431 forks source link

.NET debugger inconsistencies #284

Closed AdamLewisGMSL closed 4 years ago

AdamLewisGMSL commented 4 years ago

Environment:

Using the lambci .net 2.1 image we're able to attach a debugger in Visual Studio to the dotnet process running MockServer when STAY_OPEN is given. (Attach to Process -> Connection Type: Docker (Linux Container) -> dotnet process -> Managed Code).

When we invoke the lambda via the CLI breakpoints are triggered & all the good stuff.

Using the 3.1 image however this isn't possible:

mhart commented 4 years ago

Indeed, the dotnetcore3.1 runtime is a completely different beast to the other two – built on Amazon Linux 2 and using the custom Lambda runtime HTTP API instead of native library integration.

I'm not going to be able to give you much help on debugging .NET 3.1 I'm afraid – I'm honestly not sure what the Lambda bootstrap accepts as args for debugging – it's a compiled binary, and AWS hasn't given me access to the source, so I really don't know much more than that.

You can pass whatever you like as --bootstrap and --bootstrap-args to /var/rapid/init – so you can bootstrap your own debugging however you'd like: https://github.com/lambci/docker-lambda/blob/74bc9c4f70cf595e6bc482dcb67d15ce5dbec48c/provided/run/init.go#L103-L104

You might want to see if https://github.com/awslabs/aws-sam-cli has support built in for this (as well as https://github.com/aws/aws-toolkit-vscode) – they both use this image, so the source might provide some illumination on how they do debugging with these containers (if they support it at all for .NET Core 3.1?)

AdamLewisGMSL commented 4 years ago

Think I've cracked the underlying issue. Visual Studio 2019 when attaching:

On the 2.1 image this works, the 3.1 image fails with:

Downloading https://vsdebugger.azureedge.net/vsdbg-16-6-20415-1/vsdbg-linux-x64.tar.gz ERROR: Unable to find 'wget' or 'curl'. Install 'curl' or 'wget'. It is needed to download the vsdbg package.

mhart commented 4 years ago

Well curl (or wget) don't exist on the Amazon Linux 2 runtimes, so yep, that error makes sense.

AdamLewisGMSL commented 4 years ago

Can confirm that if I put the .vs-debugger folder manually in place it's possible to attach the Visual Studio debugger.

Is there any scope for adding wget/curl to the 3.1 image or shall I call this a no-go something that will need to be implemented internally?

mhart commented 4 years ago

That's a no-go. Anything added to the run images would mess with ppl's assumptions of what's actually available on Lambda itself. Things would pass locally (say, if you called out to curl), but fail in Lambda.

Glad you got it working though!

ScottFinlaysonGMSL commented 4 years ago

I think not adding it makes complete sense. I don't believe curl or wget are actually required at all for this request though. It's the presence of the additional binary to aid debugging that's required. Would your thinking also apply to the addition of the vsdbg binary? If not then you could solve this with a docker multi-stage build.

mhart commented 4 years ago

Either that, or you can just mount a local directory that contains everything you need (ie, with the -v docker flag). If you mount it at /opt, then you'll get library and binary paths for free (/opt/bin is already in PATH and /opt/lib is already in LD_LIBRARY_PATH)

Have a look into Lambda layers, and check the README for how to mount them with docker-lambda. I think that'd be the best way to go