如何“弄平”将Lambda功能部署到AWS时,无服务器框架目录
开发AWS lambda函数...
并使用无服务器框架
服务server> server> server.yml
文件:
service: user
frameworkVersion: '3'
provider:
name: aws
runtime: nodejs16.x
architecture: arm64
region: ${opt:region, 'us-east-1'}
stage: ${opt:stage, 'development'}
package:
individually: true
functions:
- ${file(./lambda/functions/authorizeUser/serverless.yml)}
function server> server> serverless.yml
(在上面引用的相对目录中)
authorizeUser:
handler: index.handler
name: authorizeUser
description: Registers or Authorizes a user with the system
package:
patterns:
- '!**/*'
- ./lambda/functions/authorizeUser/index.js
- ./lambda/functions/authorizeUser/magic.js
我需要使用服务serverless.yml
文件的目录作为单个lambda函数源源*。js
文件的基本路径。我最初希望我可以使用函数serverless.yml
驻留的目录作为单个lambda函数源源*。js
文件的基本路径。 我如何告诉sls部署
使用函数serverless.yml
文件的目录作为单个lambda函数源源源**的基本路径。 。
单个lambda函数源*。js
文件降落在我的lambda函数中):
/euthorizeuser/lambda/functions/euthorizeizeuser
目录,当我测试我的lambda函数时会导致以下错误:
{
"errorType": "Runtime.ImportModuleError",
"errorMessage": "Error: Cannot find module 'index'\nRequire stack:\n- /var/runtime/index.mjs",
"trace": [
"Runtime.ImportModuleError: Error: Cannot find module 'index'",
"Require stack:",
"- /var/runtime/index.mjs",
" at _loadUserApp (file:///var/runtime/index.mjs:726:17)",
" at async Object.module.exports.load (file:///var/runtime/index.mjs:741:21)",
" at async file:///var/runtime/index.mjs:781:15",
" at async file:///var/runtime/index.mjs:4:1"
]
}
如果我手动将单个lambda函数源*。js
文件移动到/euthorizeuser
(lambda函数的根目录),则该函数将执行。 我如何告诉sls部署
在将lambda函数部署到AWS时(如果可能的话)?
我意识到我可以将所有内容放置我的开发环境中同一目录中的文件以及我遇到的这些问题将不会发生,但是我的偏爱是在嵌套目录结构中管理源文件,以帮助将文件分类为逻辑组。
https://www.serverless.com/framework.com/framework/framework/framework/docs/providers/ AWS/指南/功能
Developing an AWS lambda function...
and deploying it using the Serverless Framework
service serverless.yml
file:
service: user
frameworkVersion: '3'
provider:
name: aws
runtime: nodejs16.x
architecture: arm64
region: ${opt:region, 'us-east-1'}
stage: ${opt:stage, 'development'}
package:
individually: true
functions:
- ${file(./lambda/functions/authorizeUser/serverless.yml)}
function serverless.yml
(in the relative directory referenced above)
authorizeUser:
handler: index.handler
name: authorizeUser
description: Registers or Authorizes a user with the system
package:
patterns:
- '!**/*'
- ./lambda/functions/authorizeUser/index.js
- ./lambda/functions/authorizeUser/magic.js
I need to use the directory in which the service serverless.yml
file resides as the base path for the individual lambda function source *.js
files. I originally expected that I could have just used the directory in which the function serverless.yml
resides as the base path to the individual lambda function source *.js
files. How can I tell sls deploy
to use the directory in which the function serverless.yml
file resides as the base path to the individual lambda function source *.js
files?
But a bigger issue with my approach is that when the individual lambda function source *.js
files are deployed on AWS the directory structure is recreated (e.g. the individual lambda function source *.js
files land in my lambda function's):
/authorizeUser/lambda/functions/authorizeUser
directory which causes the following error when I test my lambda function:
{
"errorType": "Runtime.ImportModuleError",
"errorMessage": "Error: Cannot find module 'index'\nRequire stack:\n- /var/runtime/index.mjs",
"trace": [
"Runtime.ImportModuleError: Error: Cannot find module 'index'",
"Require stack:",
"- /var/runtime/index.mjs",
" at _loadUserApp (file:///var/runtime/index.mjs:726:17)",
" at async Object.module.exports.load (file:///var/runtime/index.mjs:741:21)",
" at async file:///var/runtime/index.mjs:781:15",
" at async file:///var/runtime/index.mjs:4:1"
]
}
If I manually move the individual lambda function source *.js
files to the /authorizeUser
(the lambda function's root directory) the function will execute. How can I tell sls deploy
to flatten the directory structure when it deploys the lambda function to AWS (if this is even possible)?
I realize that I can just place all of the files in the same directory in my development environment and these problems that I'm experiencing will not occur, but my preference is to manage source files in a nested directory structure to help categorize files into logic groups.
https://www.serverless.com/framework/docs/providers/aws/guide/functions
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我得出的结论是,由于无服务器构造了基本的云形式模板的方式,因此无法进行扁平化。放入应用程序服务的父目录(基本目录下方),这使得(或从纯粹的计算机科学 tree Perspective中简直是不合逻辑的)将同胞目录附加到服务上。如果存在与无服务器“路径”引用的解决方式相关的文档并将其一起工作的方式,例如
glob
vers$ file()
引用。如果存在某个地方,请给我发送一个链接。I have come to the conclusion that flattening cannot be done because of the way that Serverless constructs the underlying CloudFormation template. Dropping to a parent directory (below the base directory) for the application services makes it impossible (or simply illogical from a purely computer science tree perspective) to attach sibling directories to the services. It would be helpful if there were documentation related to the way that Serverless "path" references are resolved and work together e.g.,
glob
versus$file()
references. If this exists somewhere, please send me a link.