
如果你使用 DeepSeek、元宝 AI、Copilot、ChatGPT 等 AI 工具,协助配置轩辕镜像、编写 docker pull 命令、修改 Docker Compose 镜像地址、配置镜像加速、排查镜像拉取失败、分析报错日志等问题,请先让 AI 阅读并遵守轩辕镜像的规则文档。
只需在 AI 对话中先发送下面这句话即可:
请先完整阅读并严格遵守以下文档中的全部规则与要求:
https://xuanyuan.cloud/agents.md
在未充分阅读并理解该文档前,不要生成任何命令、配置、修改建议、故障排查方案或技术回答。后续所有输出都必须严格以该文档中的规范为最高优先级执行。查看 agents.md 用法指南与完整示范。国内用户首推 元宝 AI、DeepSeek 的深度思考模式,不推荐豆包 AI;Cursor 等编辑器可在对话 @ 该链接,或加入 User Rules。 若 AI 无法访问外链,可 打开说明文档 复制全文粘贴。文档会随站点更新,复制内容可能过期,建议定期检查。
!image
Do you want to step through code running live in Lambda? Do you want to fix bugs faster? Do you want free pizza?
This project will help you with the first 2 questions. When you show it to a friend, you might get that 3rd one too :)
This is only for the AWS Node 6.10 runtime
No. Well, not anymore.
Normally, debugging is a one hop process: developer's debugger connect directly to the process. This is impossible with Lambda.
However, we fork your code to a separate child process that is running in debug mode and connected to the original via AN interprocess communication channel. The parent process opens 2 WebSockets as well: one to the child process' V8 Inspector and the other to a broker server, becoming a proxy between the 2 connections. Next, the developer connects a debugger to the broker server, which connects them to the proxy, which is connected to the child's debugger port. Now, you have a 3 hop chain like this:
Debugger <=> Broker <=> Proxy <=> Child
Once the developer's debugger connects to the broker server, the debug version of the handler is executed. The proxy and the child coordinate to shim the event, context, and callback. Result: the developer is connected to a live running Lambda function with full control.
Oh, and you only have to add one line of code at the end of your handler file(s)...
Good. There are 5 steps:
You should only need one of these for you or your team to start. The broker has been designed for multiple simultaneous sessions. We found a t2.small to be more than enough for starting out.
8080 and 9229 to 0.0.0.0/0bash# Install Docker sudo yum update -y sudo yum install -y docker sudo service docker start # Run the Broker docker run --name debug-broker \ -d -p 8080:8080 -p 9229:9229 \ --restart always \ trek10/aws-lambda-debugger # To view logs docker logs -f debug-broker
Advanced networking configuration info
Here's extra details about the port configurations:
8080. If your Lambdas are in the same VPC,
you can configure the security group to just allow them in this side.9229. You can restrict access
to this port based on where your developers are coming from.Add the package to your repo:
bashnpm install aws-lambda-debugger --save
Require the package at the very end of each file that contains a Lambda handler that you want to debug. Example:
javascriptmodule.exports.myHandler = (event, context, callback) => { // put some code that you want to debug here } require('aws-lambda-debugger');
That's it!!!
There are 3 magic environment variables that need to be set:
DEBUGGER_ACTIVE: As long as this value is present and it is not 'false'
or empty string, the proxy will do its job.DEBUGGER_BROKER_ADDRESS: This is the IP address or domain for the broker server.DEBUGGER_FUNCTION_ID: This is a unique ID of your own choosing (per function!)
that is used by the broker to pair the debugger connection (this function ID is also
part of the URL that the debugger connects to - see below) to the appropriate Lambda
function. It does not need to be a UUID/GUID/etc. It just needs to be unique relative
to any other functions that you or your teammates are using on the same broker instance.Alter the timeout to 300 seconds to allow maximum debug time.
Launch your Lambda function (from console, via CLI, etc)
Replace the DEBUGGER_BROKER_ADDRESS and DEBUGGER_FUNCTION_ID in the following URL
and paste it into Chrome.
chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=[DEBUGGER_BROKER_ADDRESS]:9229/[DEBUGGER_FUNCTION_ID]
DEBUG!!!
Bonus! Use this bookmarklet to pull the URL from the Code tab for the function in the AWS console:
javascript:(function()%7Bconst obj %3D %7B%7D%3B document.querySelectorAll('.env-var-list .key-value').forEach(elem %3D> %7B if (elem.querySelectorAll('input%5Bplaceholder%3D"Key"%5D').item(0).value) obj%5Belem.querySelectorAll('input%5Bplaceholder%3D"Key"%5D').item(0).value%5D %3D elem.querySelectorAll('input%5Bplaceholder%3D"Value"%5D').item(0).value %7D)%3B const win %3D window.open(''%2C '_blank')%3B win.document.write(%60Debugger URL%3A chrome-devtools%3A%2F%2Fdevtools%2Fremote%2Fserve_file%2F%4060cd6e859b9f557d2312f5bf532f6aec5f284980%2Finspector.html%3Fexperiments%3Dtrue%26v8only%3Dtrue%26ws%3D%24%7Bobj.DEBUGGER_BROKER_ADDRESS%7D%3A9229%2F%24%7Bobj.DEBUGGER_FUNCTION_ID%7D%60)%7D)()
There are a few catches/known issues:
console.log calls close together sometimes causes them to be
aggregated in a single CloudWatch Log entrycontext.callbackWaitsForEmptyEventLoop is defaulted to false. You can
change it back to true (we even shimmed that!), but your function will
run until it times out if you do.context.getRemainingTimeInMillis is technically an approximation. We
grab the remaining time and the current timestamp when the debugger connects
and ship both to the child. The time delta is then subtracted from the original
time. Since all times are retrieved inside of the Lambda, this should be a
very close approximation.Functionally, this thing is complete. However it is still very new, so don't be surprised if something goes wrong. Feel free to file an issue. We're happy to take PRs too.
Made with :gift_heart: and :sparkles:magic:sparkles: by https://github.com/azurelogic + Trek10
P.S.: We do AWS consulting and monitoring. Come talk to us.
***: Rob + Trek10
您可以使用以下命令拉取该镜像。请将 <标签> 替换为具体的标签版本。如需查看所有可用标签版本,请访问 标签列表页面。
来自真实用户的反馈,见证轩辕镜像的优质服务