Closed AdamLewisGMSL closed 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?)
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.
Well curl (or wget) don't exist on the Amazon Linux 2 runtimes, so yep, that error makes sense.
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?
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!
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.
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
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: