什么是 Lambda 容器镜像?
lambda-images 其实不是一种完全不同的AWS Lambda技术,它是当下AWS Lambda 技术体系下的一种补充. 解决了当下AWS Lambda 代码打包发布 整体性不高,runtime比较单一的问题
传统的zip方式:
我们知道AWS Lambda以往发布代码是使用zip格式的,它们的runtime一般也比较固定,集中在几种主流的语言上,比如Go,JavaScript,Java,Python,Ruby,C#等,详情请看: lambda-runtimes
如果上面的几种语言不是你需要的,比如你需要Rust,Groovy等,那么就需要runtimes-custom. 这个就很有局限或者很考验devops的技术.
同时,一般当下的Lambda代码打包方式最佳实践是分为layer和业务代码两部分,两者相互配合但是又需要独立发布,layer和业务的版本兼容的同步就需要在发布时核验.
容器镜像
相比与AWS Lambda, 在全球范围或者中国地区,K8S+容器化更加普及. 绝大部分开发人员更熟练于使用容器,尤其是中国地区大多数公司当下的项目基本都是裸金属服务器部署微服务或者K8S编排容器服务.
这时Container方式部署lambda就有优势了:
- 对于想
serverless化的公司,现有的单体微服务很容易被打包为Docker容器或者已经是Docker容器. 这样在容器的基础上经过小幅度的改动,就可以直接使用serverless运行了 - 对于已经有
AWS Lambda使用经验的团队,有时需要使用其他运行时或者想要更加一体化的发布体验.那么就可以使用容器化技术讲需要的软件环境,依赖包和业务代码集中打包,形成一个整体.满足下列场景- 自己封装runtime,满足特定语言的需要
- 将layer和业务代码集中打包,解决layer和业务代码版本对齐的困扰
怎么使用容器镜像
使用容器镜像需要满足下面几点
CI/CD工具运行的环境需要有Docker环境(至少要有打包image的能力)- 需要有
Docker hub或者AWS ECR服务寄存打包好的images - 熟悉
AWS Lambda部署配置.比如serverless或者AWS cloudformation的配置 - 发布
lambda的IAM role具有ECR的读写权限
容器镜像的局限
前面讲了容器镜像是对当下zip打包方式的一种补充,那么它们两者有什么优劣呢, Lambda容器镜像 这篇文章也做了一些简单的总结
优点:
摆脱了runtime关于环境的局限,可选择的语言更多,还可以将必要的资源一并打包,就像传统的容器一样使用.
AWS Lambda is easy to use and manage; the execution environment has a specific runtime on a known environment and you can just send code to it and it runs. Nice! This has served us well over the years. The biggest problem with that status quo, however, is when you want to achieve a use case outside these predetermined environments. Perhaps you want to perform some form of processing using a library that is not included by default into the lambda environment? Or even use your own runtime that is not provided
AWS tried to help solve some of these issues with the introduction of Lambda layers which was useful but still quite limited. The real problem was that, while Lambda by default is great for pick up and run with little to no maintenance, flexibility was sacrificed to achieve that simplicity.
AWS Lambda易于使用和管理;执行环境在一个已知的环境上有一个特定的运行时，您只需向它发送代码，它就会运行。好了!这些年来，这对我们很有帮助。然而，这种现状的最大问题是，当您想要实现这些预先确定的环境之外的用例时。也许您想使用lambda环境中默认不包含的库来执行某种形式的处理?或者甚至使用没有提供的运行时?
AWS试图通过引入Lambda层来帮助解决其中的一些问题，Lambda层很有用，但仍然非常有限。真正的问题是，虽然Lambda在默认情况下非常适合进行拾起和运行，几乎不需要维护，但为了实现这种简单性，灵活性被牺牲了。
In December, 2020, we released some basic Docker container support and recently we have expanded on that to make it a lot easier for users to make use of this new feature. The container entirely encapsulates your Lambda function (libraries, handler code, OS, runtime, etc) so that all you need to do after that is point an event at it to trigger it.
在2020年12月，我们发布了一些基本的Docker容器支持，最近我们对其进行了扩展，让用户更容易地使用这个新特性。容器完全封装你的Lambda函数(库，处理程序代码，操作系统，运行时，等等)，所以你需要做的就是指向一个事件来触发它。
缺点:
container image尺寸大,导致发布慢,lambda冷启动慢或者可能导致运行效率略慢
同时容器镜像给我们带来了更低层次底层控制能力,但是也一定程度上失去了lambda以前的底层服务全托管的优势,运维在容器的打包,容器基础系统和软件版本的管理和软件补丁上需要自己做管理
AWS claims that cold start times should see no significant impact, but I think it’s safe to assume that it is possible to configure things in such a way as to make cold starts longer, so taking care and testing thoroughly may be needed. Especially since container images can be up to 10 GB in size; we have seen that package sizes can affect cold start times in the past. And this brings about the biggest downside of using your own docker containers. While this new feature is definitely needed and will provide a great amount of flexibility to the platform and Serverless development in general, it really should be seen as a last resort. Why?
One of the great selling points of Serverless development is that you can spit out a solution, and the underlying managed services manage everything for you; from infrastructure to networks, OS’s to runtimes. Now with docker support, you can ratchet that back a notch and take back management of the OS and runtimes, which may be required in some situations. But if you can use the pre-built, prepared environments, it's still advisable to do so to reduce the amount of work you may need to do in managing these environments; it's one of the reasons most of us started building applications with Serverless to begin with!
AWS声称冷启动时间不会有重大影响，但我认为可以放心地假设，可以通过这样的方式进行配置，使冷启动时间更长，因此可能需要注意并彻底测试。特别是容器映像的大小可以达到10gb;在过去，我们已经看到包大小会影响冷启动时间。这带来了使用自己的docker容器的最大缺点。虽然这个新特性是绝对需要的，并且一般来说将为平台和无服务器开发提供很大的灵活性，但它确实应该被视为最后的手段。为什么?
无服务器开发的一大卖点是，您可以提出一个解决方案，底层的托管服务为您管理一切;从基础设施到网络，从操作系统到运行时。现在，有了docker的支持，你可以把这一点向后推，收回对操作系统和运行时的管理，这在某些情况下可能是必需的。但是，如果您可以使用预先构建的、准备好的环境，那么仍然建议这样做，以减少您在管理这些环境中可能需要做的工作量;这是我们大多数人开始构建无服务器应用程序的原因之一!
总结
| zip 打包 | 容器镜像 |
|---|---|
| 启动时间短 | 启动时间相对长 |
| 代码包很小 | image普遍大,数百M到数个G |
| runtime 局限在有限的语言上(至少可直接使用的语言不太多) | image内部直接集成运行时,理论上你会的语言都可以编写lambda |
| 典型结构分为layer和业务代码分离,程序的整体行不太高.对齐layer和业务代码的版本需要人工检查 | All in one,很容易对齐layer和业务代码的版本 |
| 运行轻量,性价比高 | 运行相对重,内存理论上耗费多 |
| 对DevOps团队的技术要求高,需要做前期设计和CI/CD的规划,技术曲线高,但是一旦掌握,这种方式在发布的时间上非常低 | 可以大量复用现有的容器镜像,技术曲线略低,但是由于image尺寸大,发布普遍慢很多 |
实际代码演示
参考:
