更新生产Ubuntu可以做的事情

我经常登录生产web / db / tools框，然后看到典型的消息：

可以更新30个软件包。16个更新是安全更新。

我的问题是，你们所有人如何处理生产Ubuntu机器上的更新？您会自动执行这些更新吗？您为他们设置停机时间吗？问题是，您永远不知道更新何时会破坏某些内容，例如现有的配置文件等。

这个问题的另一部分是，与补丁保持同步是“一件好事”，但是补丁几乎每天都会发布。如果每天有新的安全补丁可用，则必须进行多少次预定停机？

我认为回答有关如何管理更新的主题将非常有用。

将Ubuntu与Windows，RHEL，CentOS，SuSE，debian等打补丁并没有什么特别的。

设计补丁程序时，您需要保持的基本心态是假设某些东西会损坏。

在设计补丁程序设置时，我倾向于使用一些基本准则：

• 始终使用本地系统从内部集中安装补丁程序的网络

这可能包括使用WSUS或<your_os_here>内部补丁程序管理器的镜像。最好是可以集中查询并让您知道各个计算机上安装的补丁程序状态的工具。

• 在机器上尽可能进行预安装。

在可能的情况下，随着补丁的出现，中央服务器将它们复制到单独的计算机上。这实际上只是节省时间，因此您不必等待它们下载并安装，只需在补丁程序窗口中开始安装即可。

• 获取中断窗口以安装修补程序，您可能必须重新启动，并且可能会损坏某些内容。确保这些系统的利益相关者知道有正在部署的补丁程序。为“ this”不起作用的调用做好准备。

按照我的基本理论，即修补程序会破坏性能，请确保您有一个停机窗口，可以应用足够长的时间来修补关键问题，并可能回滚该修补程序。您不需要一定要让别人坐在那里对补丁进行测试。我个人非常依赖我的监视系统，让我知道一切都在我们可以逃脱的最低限度上运行。但也要做好准备，以防人们上班时遇到一些小麻烦。您应该始终安排一个人在那里准备接听电话-最好不要凌晨3点之前为盒子打补丁的那个人。

• 尽可能自动化

像IT中的其他所有内容一样，脚本，脚本再编写更多脚本。脚本脚本包下载，安装开始，镜像。基本上，您希望将拼装窗口变成婴儿看护任务，以防万一发生问题时只需要一个人。

• 每月有多个窗口

如果由于某种原因无法在“指定的夜晚”对某些服务器进行修补，则可以使您不对某些服务器进行修补。如果您无法在晚上1进行操作，则要求它们在晚上2空闲。另外，还可以使您同时修补的服务器数量保持理智。

最重要的是紧跟补丁！如果不这样做，您将发现自己不得不做10个小时以上的大型补丁程序窗口，才能回到被困的位置。在可能出现问题的地方引入更多点，并使得造成问题的补丁更加复杂。

这个问题的另一部分是，与补丁保持同步是“一件好事”，但是补丁几乎每天都会发布。如果每天有新的安全补丁可用，则必须进行多少次预定停机？

恕我直言，每月一次或每隔一个月对服务器打补丁是一个非常可实现且可以接受的目标。不仅如此，而且您将不断为服务器打补丁，而更少的话，您将开始陷入需要为每个服务器应用数百个补丁的局面。

至于一个月需要多少个窗户？这取决于您的环境。您有几台服务器？您的服务器所需的正常运行时间是多少？

9x5的较小环境可能每个月只有一个补丁程序窗口。大型24x7商店可能需要两个。大型24x7x365每周可能需要滚动窗口，才能每周修补一组不同的服务器。

找到适合您和您的环境的频率。

要记住的一件事是，达到100％的最新状态是不可能实现的目标-请勿让您的安全部门告诉您。尽力而为，不要落在后面。

要做的事情：

1. 备份
2. 确保它是可还原的备份（尽管这是两个基本要点）
3. 升级时，尝试将流量从生产包装箱中引开。
4. 万一出了错，请尝试使用带外访问方法，例如KVM，串行控制台，本地访问或远程操作。
5. 在将更新部署到更多服务器上之前，在一台服务器上进行测试，然后确保一切正常
6. 如果可以确保多个服务器之间的版本号相同，请使用puppet。（您也可以使用它来强制升级）
7. 在测试服务器上，将配置文件的版本与新的（已安装更新的）配置文件进行比较，并确保不会严重破坏配置文件。我似乎记得dpkg在安装不同于当前安装的新版本之前询问。

避免的事情：

1. 在一天当中或周一早上09:00或星期五下午5pm进行更新！（感谢@ 3influence！）
2. 在大型数据库服务器上升级MySQL（重新启动可能需要很长时间）
3. 一次处理所有服务器（尤其是内核）
4. 做任何可能改变/ etc / networks的事情（因为可能会失去连接）
5. 无需您检查所有内容即可进行上述操作的自动更新也可以。

还有一点值得做的：如果你正在使用Windows时，你会惊奇地发现，大多数的Linux更新都不会需要停机或重启。有些功能，例如内核更新。但是，通常需要将此类更新标记为需要重启或停机，并且可以按单独的时间表进行处理。

我们的Ubuntu计算机都运行LTS版本。

我们只是自动安装所有更新-确保它不是“最佳实践”，但是我们是一家相对较小的商店，没有针对每项服务的测试/开发/生产环境。LTS更新通常都经过了很好的测试，并且无论如何都是微创的。

升级到新版本显然要花更多的时间。

对于ubuntu LTS系统，我们采用以下方式处理更新：

1. 保持一套验收测试套件，以检查我们软件中的所有关键路径
2. 每天凌晨4点安装无人值守的安全升级，并立即运行验收测试。如果发生任何故障，将调动一名工程师，并且有足够的时间来修复问题或在上午9点之前回滚。到目前为止，这仅在五年中发生过两次-LTS经过了充分的测试和稳定。
3. 我们每周（在Digitalocean上）通过蓝/绿部署自动重新部署整个基础架构，从而使所有软件包保持最新版本。如果新部署未通过验收测试，则该部署将暂停，直到工程师可以调试问题为止。

对我们而言，下一个合乎逻辑的步骤是消除内存中的会话信息，因此我们可以简单地每天（甚至每天）多次重新部署基础结构，而不会影响客户，并消除步骤（2）。

这种方法维护成本低，完全避免了维护窗口。

我建议的一件事是处理软件包的回滚。有关如何执行此操作的建议，请参见使用Debian进行事务和回滚，因为有时您需要快速解决升级问题。