CaaS、PaaS和FaaS用户如何知道他们的服务器环境的操作系统是否属于最新版本？
请考虑一下这张图表；它显示了今天常见的不同托管模式：
从图表中我了解到，CaaS、PaaS和FaaS是三种托管模式--用户无法控制它获得的操作系统(作为其服务器环境的操作系统-- gets服务器、电子邮件服务器和其他依赖于互联网的服务器)。
但我想知道，CaaS/PaaS/FaaS服务的客户端如何才能真正知道他们的服务器环境的操作系统是否是最新版本的really (以任何可能的方式)。
我想知道，当客户报告“您的Debian是最新的”(比如Debian 9或10 (应该很快发布，或11或12)或“您的ArchLinux是最新的”等)时，有什么方法可以确保CaaS/PaaS/FaaS公司不会对我撒谎。
在这三种情况下，我都可以用Ansible自动化操作系统之上的所有东西，但这仍然不能让我在脑海中安静下来；我仍然对我的操作系统感到“焦虑”；我希望它的所有升级也是完全自动化的。
我应该在我的环境中拥有的<#>What工具( CLI终端本身并不一定足够)，能够真正知道它们是否在操作系统版本(次要的、主要的和发布的)上向我报告了真相而不是简单的谎言？
虽然有点老(比如说4-8年)的操作系统相对于上面所有的up2date软件来说都是稳定的，但如果情况允许的话，我还是更愿意成为up2date (到目前为止，我在DigitalOcean上有5美元-30美元的IaaS VPSs )。
回答 2
DevOps用户
发布于 2018-12-11 18:57:59
首先，CaaS/PaaS/FaaS服务背后的关键概念之一是卸载操作系统维护负担:)因此，只要CaaS/PaaS/FaaS服务根据各自的SLA执行，提供者甚至不应该在乎哪个版本(甚至可以是什么OS！--它甚至可以是专有版本)。
在某种程度上，这就是为什么至少有些服务被认为是无服务器 --如果没有“服务器”，OS发布意味着什么？
至于在最新的版本-我严重怀疑一个大型服务提供商是否会使用最新的OS发行版的任何产品的生产级SLA。简单的动机是，当该版本的质量达到足够高的/生产质量水平(根据供应商的QA资格标准)时，它不再是最新的了:是的，在(大型)企业环境中限定第三方提供的OS发布并不是一件小事，它可能需要几个月/几年才能完成。
最近的补丁/服务包级别更有可能出现(但我仍然对“最新”表示怀疑)。这是典型的稳定性与质量冲突。看看任何新的操作系统和它在发布后的最初几个月里收集到的严重错误列表。
另一个考虑因素是:在CaaS/PaaS/FaaS上下文中运行最新的OS版本可能并不像人们在某些情况下所想的那么重要，这取决于所提供的服务及其实现。例如，如果OS运行时/执行沙箱不允许宿主应用程序进行系统调用，谁会关心PaaS系统调用漏洞？例如，参见Google的Python Sandbox。或者，如果系统甚至不直接暴露于外部世界，侦听端口漏洞？
注意:在某些情况下，即使是CaaS/PaaS/FaaS服务的语言支持滞后也可能很重要，而且IMHO可以想象，类似的推理可能会解释操作系统滞后的原因。
DevOps用户
发布于 2020-03-17 05:32:27
您可以使用特殊的发布监视工具(如https://release-monitoring.org/ )跟踪软件堆栈更新，并通知订阅者或触发自动更新操作。
https://devops.stackexchange.com/questions/5688
复制相似问题
腾讯云开发者
