ansible操作数据库

如今，当您为Linux机器打补丁时，我可以原谅您问：“这有多难？” 当然， yum更新-y将在一瞬间为您排序。

但是对于我们中使用少数机器的人来说，并不是那么简单。 有时，更新可能会在许多计算机上造成意想不到的后果，而您却想知道如何将事情恢复原状。 或者您可能会想：“我应该自己应用关键补丁并为自己省去很多麻烦吗？”

过去面对这些挑战使我建立了一种选择所需更新并使它们的应用程序自动化的方法。

灵活的想法

以下是该过程的概述：

现在，对机器进行修补可归结为1）所预订的存储库和2）进行“修补”。 通过使用变量来控制订阅和补丁许可，我们不需要篡改逻辑（剧本）。 我们只需要更改数据。

这是一个满足两个要求的 。 它管理存储库订阅，并具有一个简单变量来控制运行patch命令。

---      
          
     # tasks file for patching      
          
     - name      
     :  Include OS version specific differences      
       include_vars      
     :       
     "{
      { ansible_distribution }}-{
      { ansible_distribution_major_version }}.yml"      
          
     - name      
     :  Ensure Yum repositories are configured      
       template :      
         src      
     :  template.repo.j2      
         dest      
     :       
     "/etc/yum.repos.d/{
      { item.label }}.repo"      
         owner      
     :  root      
         group      
     :  root      
         mode      
     :  0644      
       when      
     :  patching_repos is defined      
       loop      
     :       
     "{
      { patching_repos }}"      
       notify      
     :  patching-clean-metadata     
          
     - meta      
     :  flush_handlers     
          
     - name      
     :  Ensure OS shipped yum repo configs are absent      
       file :      
         path      
     :       
     "/etc/yum.repos.d/{
      { patching_default_repo_def }}"      
         state      
     :  absent     
          
          
     # add flexibility of repos here      
     - name      
     :  Patch this host      
       shell      
     :  'yum update -y'      
       args :      
         warn      
     :  false      
       when      
     :  patchme|bool      
       register      
     :  result      
       changed_when      
     :       
     "'No packages marked for update' not in result.stdout"

情境

在我们虚拟的，大型的，全球分散的环境中（由四个主机组成），我们具有：

• 两台Web服务器
• 两台数据库服务器
• 包含每种服务器类型之一的应用程序

好的，因此这台机器不是“企业级”的，而是消除了计数，并将环境想象成多个，分层的，地理位置分散的应用程序。 我们想要跨服务器类型，应用程序堆栈，地理位置或整个资产修补堆栈的元素。

仅使用对变量的更改，我们能否实现这种灵活性？ 有点。 Ansible的哈希是覆盖。 在我们的示例中， db1和web1主机的patching_repos变量被覆盖，因为它们稍后出现在清单中。 嗯，有点泡菜 有两种方法可以解决此问题：

1. 多个库存文件

我选择第一是因为它保持清晰度。 一旦开始合并变量，就很难找到哈希在何处出现以及如何将其组合在一起。 使用默认行为可以保持清晰，这是我鼓励您坚持自己的理智的方法。

然后继续吧

让我们运行该剧本，仅关注数据库服务器。

您是否注意到最后一步- 修补此主机-说 跳过了 ？ 那是因为我们没有设置来进行修补。 我们要做的是准备好存储库订阅。

因此，让我们再次运行该播放，将其限制在Web服务器上，并告诉它进行修补。 我使用详细输出运行了此示例，因此您可以看到yum更新正在发生。

修补应用程序堆栈需要另一个清单文件，如上所述。 让我们重新播放一下。

在欧洲地区修补主机与应用程序堆栈的方案相同，因此需要另一个清单文件。

现在，所有存储库订阅都已配置完毕，让我们为整个资产打补丁。 请注意， app1和emea组在这里不需要清单-它们仅用于分隔存储库定义和设置。 现在， yum update -y修补所有内容。 如果您不想捕获这些存储库，则可以将它们配置为enabled = 0 。

结论

灵活性来自我们如何对主机进行分组。 由于默认的哈希行为，我们需要考虑重叠问题，至少在我看来，最简单的方法是使用单独的清单。

关于存储库设置，我确定您已经对自己说：“嗯，但是挑选樱桃并不是那么简单！” 此模型有额外的开销，需要下载修补程序，测试它们是否可以协同工作以及将它们与存储库中的依赖项捆绑在一起。 使用补充工具，您可以自动化该过程，并且在大型环境中，您必须这样做。

我的一部分被吸引到只应用完整补丁集作为一种更简单的方法。 跳过挑剔的部分，并将完整的修补程序应用于“标准构建”。 我已经看到这种方法适用于具有强制性季度更新的Unix和Windows领域。

我很想听听您在修补制度方面的经验，以及在此处，下面的评论中或提出的方法。

翻译自:

ansible操作数据库