保持EC2 Ubuntu计算机更新的最佳实践

继最近出现 OpenSSL 令人毛骨悚然的漏洞之后，我想定期更新我的EC2计算机。天真的方法是为安全更新（sudo apt-get update && sudo unattended-upgrade）设置每小时的cron作业。

有这样做的风险吗？EC2计算机是否有推荐的更新机制？

无人值守升级软件包是在Ubuntu中自动应用重要错误修复和安全补丁的标准方法。

我建议在每个Ubuntu系统上安装它：

sudo apt-get update &&
sudo apt-get install unattended-upgrades

您无需创建自己的Cron作业。该软件包将为您安装一个。

如果您要更改默认配置，则可以编辑默认配置：https : //help.ubuntu.com/lts/serverguide/automatic-updates.html

unattended-upgrades从2015年到2020年，我们一直在使用，没有问题。我们有一个小型安装程序（在DigitalOcean上）：

• nginx
• mysql-server
• php5-fpm php5-curl php5-mysql

基于过去的良好表现，以这种方式进行更新比不进行更新更安全。但这并不一定是未来的保证！

apache根据其他用户的报告以及我过去的apache更新经验，对于来说，这可能不是一个好主意。[见上文和此处 ]

使用时unattended-upgrades，当版本接近EOL时仍需要手动干预。

（除了问题：根据我在TWiki，WordPress和Jenkins的经验，与OS本身相比，使这些应用程序保持最新实际上是更大的关注点，尽管我们当然应该同时进行这两种操作。为了省心，您可以将面向Internet的应用程序沙箱化为在Docker容器中运行的非根进程。）

但是，由于您询问了最佳实践，因此AWS文档中推荐的主要方法是：

• 创建并启动新实例以替换当前的在线实例。然后删除当前实例。

  新实例将在安装过程中安装最新的安全补丁集。

（2020年2月）

这可以作为蓝绿色部署策略的一部分来完成。这样做的好处是，您可以在切换流量之前针对新服务器运行测试。如果您的测试是彻底的，那么从理论上讲，您的更新可以完全自动化，在上线之前进行验证，并且不会造成停机。

其他优点：

• 如果需要人工关注，则测试可以向您提供高级警告（与相对unattended-upgrades，当警告仅在问题存在后才由您的用户发出！）

• 如果您的系统确实受到威胁，或者您决定更换提供商，则此方法应该使推出全新部署变得容易。您的部署策略是脚本化的，而不是古老的记忆。

但是，当然unattended-upgrades，与简单安装相比，此方法需要更多的设置，并且更加复杂，因此仍然存在错误的余地。

AWS确实也提到了执行“更新依赖项堆栈命令”，这似乎是他们执行类似于的正式方式unattended-upgrades。似乎可以从其“实例”界面触发，但是我不确定是否可以自动化。