我遵循了一个优秀的指南（Serverless Stack），它创建了一个带有反应前端的典型CRUD无服务器基础架构。它使用Serverless Framework用于AWS。
我不喜欢的是，为了引导设置，有很多手动点击GUI（主要是亚马逊的控制台界面）。即设置不受版本控制，不易重现。使用CI / CD进程等扩展它并不容易。在此示例中，需要手动设置以下资源：
从代码构建的唯一资源是无服务器函数（lambdas）本身以及API网关实例。这就是无服务器框架使用其serverless.yml文件所做的事情。但是，以上所有资源都是不自动创建的。它们有时需要referenced to使用其ARN，但它们不是由serverless.yml配置创建的。在生产中运行这样的系统（严重依赖于通过GUI手动创建服务）似乎存在风险。
我在想这个解决方案就是使用Terraform或Cloudformation。但无服务器框架本身已经使用Cloudformation来设置Lambdas，但不是用于其他资源。那么如何消除这种差距呢？换句话说，如何在代码中重建Serverless Stack中描述的整个设置？
让CloudFormation设置无服务器似乎很奇怪，也许是不可能的，然后它有自己的Cloudformation模板来设置lambdas。扩展无服务器框架可能更有意义，不仅要定义需要在serverless deploy上创建的功能和API网关，还要定义其他资源，如DynamoDB或Cognito用户池。有没有人做过这样的例子或尝试？
答案 0 :(得分：7)
我同意关于此的文档会很好pull request here。
您确认serverless正在使用CloudFormation。该框架确实通过resources的{{1}}密钥向您公开了底层的CloudFormation机制。
我认为the intent of the framework是您将serverless.yml文件的resources:部分中的其余资源（Cognito stuff，S3等）放入regular old CloudFormation syntax使用{{3} }}
例如，除了无服务器功能外，此文件还将创建DynamoDB表和S3存储桶：
serverless.yml如果您是CloudFormation的新手，我还建议您查看CloudFormer。
答案 1 :(得分：0)
基于@Mike Patrick的选项，增加了我对无服务器框架和其他类似无服务器焦点工具的理解。
正如您所提到的，对于无服务器项目，涉及很多资源。将它们结合在一起并非易事。所以选择合适的工具很难。
将Serverless framework与Cloudformation和Terraform进行比较，无服务器框架无服务器专家，Cloudformation和Terraform GP
Cloudformation和terraform完全Infrastructure as Code，涵盖了大部分资源。
无服务器框架是一个中间层，仅用于生成Cloudformation模板，该模板主要用于无服务器相关资源。
您可以直接在Cloudformation模板中编写所有内容，但模板文件很大，很难通过其JSON / Yaml模板进行维护。在serverless.yml中有几十行，无服务器框架可以生成一千或几千行的云信息模板。它节省了大量时间来处理云信息代码。
让无服务器框架处理所有AWS资源是没有意义的，其他工具已经做得最好。
无服务器框架仍处于开发阶段，由于其受欢迎程度，许多开发人员每天都会参与其中添加功能。也许有一天你可以得到你需要的东西，但现在你必须在某些情况下将无服务器框架与Cloudformation或Terraform或其他工具混合在一起。
答案 2 :(得分：0)
您肯定已经可以使用各种部署工具来部署IaC的几乎所有内容（事实上，我们每天都在工作）。
如果您碰巧主要使用Serverless；则可以选择类似Serverless Framework（SF）之类的东西来抽象化使用CloudFormation（CF）所固有的一些复杂性/灵活性。不管CF可以做什么，SF都可以做，但是SF有一个插件系统，该插件系统允许运行代码来淘汰API（例如，可以允许您创建CF不支持的资源）。