/etc/tomcat8/context.xml中，我要确保以下部分：<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!--
<Manager pathname="" />
-->
更改为：
<!-- Disable session persistence across Tomcat restarts -->
<Manager pathname="" />
lineinfile模块似乎无法提供帮助，因为这是多行部分。
xml模块可能能够确保
<Manager...到位，但似乎无法执行删除注释掉的版本。如果需要的话，我可以编写一个脚本用
sed做到这一点，但是我发现最好使用ansible模块。 >#1 楼
正如问题和评论中提到的那样，这不是Ansible擅长的领域。 “最佳”解决方案在某种程度上取决于您要处理的文件的类型及其结构。处理Ansible中此类更改的最干净方法是对整个文件进行模板化事情;这使您可以一次查看整个文件，而不必在许多地方将其拼凑在一起，并且比基于模式或基于行的方法要脆弱得多。当您需要在多个位置（例如，不同的角色）添加配置时，动态加载指令就变得非常有用，例如Apache httpd的
Include：Include /etc/httpd/conf.d/*.conf
此然后允许您从不同位置编写单个配置文件，并让客户端软件将它们连接起来。但是，据我所知，Tomcat不支持此功能，因此您需要使用单个模板文件进行操作。
lineinfile是一个非常脆弱的解决方案，并且template几乎总是一个更好的选择。但是，在这种情况下，您要添加的节点是一个自动关闭的节点，因此只要它是顶级节点，它就可以随处可见，并且lineinfile可以正常工作（我知道您说不会，但是我”。 xml是一个类似的选项，但有点不那么脆弱。您已经排除了这两个选项，因为它们无法删除文件中的注释。但是，我认为这是不适当的要求（在大多数情况下，并且可能是您的要求）。
使用配置管理工具时，真相的来源会从服务器上的文件本身转移到已签入母版的配置。如果有人要编辑文件，他们将通过编辑配置管理脚本而不是直接在服务器上编辑文件来进行编辑。因此，不需要在驻留在服务器上的结果文件中进行注释，除非顶部的注释是“这是自动生成的，而是查看源代码控制”。该注释应该在您的模板代码中-并且只要结果能够正确编译和正常工作，您就根本不需要在乎它的外观。
评论
建议的标签（我自己不能创建它们）：xml注释行中文件这些标签没有理由（它们无助于更好地找到问题）。以我的观点，不要走sed路，甚至不要去修改文件，不管是否管理整个文件，但通过正则表达式匹配更改行都很脆弱，并且很可能会失败。
我发现管理被程序包管理器替换的整个文件也很脆弱。有时，某些东西会添加到确实需要存在的新版本中。不幸的是，tomcat配置没有conf.d目录，可以轻松地向其中添加新文件。
“有时，某些东西会添加到真正需要的新版本中。” <-，如果您让它们在不了解它们及其原因的情况下进入您的生产环境，则让软件包维护者代表您执行他们希望做的任何事情。 。最好打破此更新的CI，并确保您与维护者所做的更改保持一致。
而且无论如何，如果维护者也更改了文件si，则尝试从行号或通过正则表达式修改可能会在没有先验信息的情况下中断，所以这取决于您，但是我真的建议您反对这种做法。