☰

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

tag-icon • tag-icon unattended-upgrades
保持 EC2 Ubuntu 机器更新的最佳实践

继最近心血由于 OpenSSL 存在漏洞，我希望定期更新我的 EC2 机器。最简单的方法是设置每小时一次的安全更新计划任务 ( sudo apt-get update && sudo unattended-upgrade)。

这样做有风险吗？ 有没有针对 EC2 机器的推荐更新机制？

答案1

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

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

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

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

如果您想改变其行为，可以编辑默认配置： https://help.ubuntu.com/lts/serverguide/automatic-updates.html

答案2

我们从 2015 年一直使用unattended-upgrades到 2020 年，没有出现任何问题。我们在 DigitalOcean 上有一个小型设置，其中包括：

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

根据过去良好的表现，以这种方式进行更新比不进行更新感觉更安全。但这不一定能保证未来！

这可能不是一个好主意apache，基于其他用户的报告以及我过去的apache更新经验。[见上文，这里]

unattended-upgrades，当释放临近时，仍然需要人工干预停产。

（除了这个问题：根据我使用 TWiki、WordPress 和 Jenkins 的经验，保持这些应用程序为最新版本实际上是比操作系统本身更令人担忧的问题，尽管我们当然应该同时做这两件事。为了安心，您可以将面向 Internet 的应用程序沙盒化为在 Docker 容器内运行的非 root 进程。）

但既然你问到了最佳实践，建议的主要方法AWS 文档是：

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

    新的实例将在安装期间安装最新的安全补丁。

（2020 年 2 月）

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

其他优势：

  • 如果需要人工关注，测试可以提前发出警告（相反unattended-upgrades，只有当问题出现时才由用户发出警告！）

  • 如果您的系统确实受到攻击，或者您决定更换提供商，这种方法应该可以轻松推出新的部署。您的部署策略是脚本化的，而不是古老的记忆。

但当然，这种方法需要的设置比简单的安装要多unattended-upgrades，而且更复杂，因此仍然存在出错的可能性。

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

相关内容