此博客文章最初发布于米凯马迪森.net并经许可在这里再版我最近发布了一篇关于Drupal9配置的介绍。如果你对这个话题不感兴趣，我会在深入讨论这篇文章之前先读一下这篇文章！有很多方法可以管理drupal9的配置。这里有一些选项，虽然这可能会使您的生活更具挑战性，尤其是如果您还没有时间来全面了解配置管理，它还允许您根据需要调整配置管理策略。什么是配置管理策略？ 简单地说，配置管理策略是您的项目如何利用配置管理系统的计划。通常，一个项目的需求（单站点与多站点，公共特性与定制特性，等等）将决定在该项目上使用哪些工具。一旦您确定了需求并确定了需要哪些工具来满足这些需求，您将需要两件事情：如何使用这些工具实现目标的策略您的开发人员将用于实现您的策略的工作流制定战略时要考虑的变量使Drupal架构如此复杂的一件事是，大数据如何处理，做一件事通常有不止一种方法。遗憾的是，配置也没什么不同。所以我不能只告诉你"总是这样做"，因为虽然我通常是"以一种特定的方式"去做，但我自己并不总是这样做。因此，我想用我在为客户设计配置管理策略时带来的决策协议来武装您。以下是收集信息时要考虑的一些变量。单站点vs.多站点vs.多站点您在Drupal社区逗留的时间越长，对讨论的期望就越高。这些天来，我的许多架构考虑和决策都受到这个问题的影响。单个站点就是运行单一代码库、数据库和文件系统的站点。多站点是一个单独的代码库，但独立的数据库和文件系统（在多站点数组中运行的每个"站点"对应一个数据库和文件系统）。许多站点通常是独立的代码库、数据库和文件系统，它们仍然以某种方式派生自模板化/分布式代码库。作为一般规则，单个站点完全使用存储在其代码库中的配置（也许，对环境逻辑有一些警告）。然而，游戏返利平台，多站点和许多站点就不那么简单了，大数据和云计算，根据它们的定义，它们必须至少有一些不同的配置为什么？因为如果您使用Drupal9提供的核心配置管理系统，并且从代码库执行完整的配置同步，那么您的所有站点最终都将是相同的（甚至包括站点的名称）。这是因为Drupal核心没有提供在多站点配置中忽略或有条件地更改配置管理的机制。虽然从技术上讲，它试图将配置存储在每个站点的一个单独的"文件"目录中，但强烈建议不要使用此功能（而是重写配置目录，使其位于docroot之外）。特征变化不，我不是在说"Drupal特性模块"。我说的是你们平台上功能的共性。下面是一个简单的例子：我们正在建立一个多站点代码库。我们有客户想在他们的网站上有一个英雄旋转木马。但是，客户对英雄横幅的类型并不认同。其中一位顾客想要一个带有背景图像和行动号召的水平滚动旋转木马。另一个客户想要一个带有背景视频的垂直滚动旋转木马（没有CTA）。这里我们有一个共同的特性（carousel），它在实现细节上有很大的不同。我们想设计一个支持这个用例的配置管理策略。我总是建议您做一些发现，以确定您的平台的特性，这样您就可以分析这些类型的差异。最好的情况是设计一个简化站点之间差异的解决方案。我从两个方面来看（对于这个例子）：我们构建了两个英雄旋转木马，它们做的事情非常相似（有细微的变化）。我们建立一个英雄旋转木马，它有几个额外的字段，允许改变滚动方向，背景类型等。第二个例子无疑是一个更复杂的旋转木马。但最终的结果是一个可以在两个网站上使用的旋转木马。两个站点的配置都是一样的。我并不是说这对每个功能都有效。然而，当考虑多站点/多站点配置时，总是会有特性变化。这是游戏的一部分。你能减少的功能变化越多越好！要素分组一旦确定了这些特性，就应该考虑如何对它们进行分组。这是战略的重要组成部分，所以一定要花点时间在这上面！通常，您将分为以下四类：所有站点的配置基本相同（90-95%共享）站点被分组到配置文件/分发文件中，这些组中的站点具有相同的配置（同样，90-95%共享）每个站点都需要单独的配置，个人免费云服务器，但它们通常仍共享大部分配置（同样，90-9%的配置是共享的）每个站点都有定制的配置，并且完全是独一无二的。一般来说，如果您要使用选项2、3或4（配置文件拆分、站点拆分或没有默认配置的站点拆分），我强烈建议您最多只能使用五个拆分。这意味着五个站点，五个配置文件，等等。原因是，即使采用了健壮的配置管理策略，您仍然会遇到规模经济问题。我今年的一个客户有一个平台，大约有100个站点，每个站点都有自己的定制配置（所以，上面的选项4）。在这种情况下，平台会遭受意想不到的后果，这意味着当一个站点更新某些内容时，该更新会频繁地影响到平台上的其他站点（甚至有时会使它们崩溃）。随着平台上拆分数量的扩展和增长。所以，你必须在任何时候改变测试的数量。任何时候应用安全更新。无论何时添加新功能或更新模块。保持列表相对较小（例如少于5组配置）意味着您可以随时测试这些更改。你能要10个吗？还是20？当然。你能要100或1000吗？当然。记住，你拥有的越多，管理、测试和部署就越困难。实施配置管理策略的工具把细节放在一起可能是一个漫长而痛苦的过程。虽然在这种情况下听起来相当简单，但是在真正锁定配置管理策略之前，您确实需要对Drupal平台的规模和复杂性有一个很好的了解。在高层，您通常会围绕以下关键模块/方法制定策略：配置拆分配置拆分模块允许您定义条件并在满足这些条件时激活配置版本。典型的例子是环境、配置文件或站点拆分（但您可以对任何内容进行拆分）。配置拆分通常是配置完全同步的一部分。Config ignore配置忽略模块允许您从同步中排除某些配置。这对于某些配置键（如站点名称）非常有价值。"过度使用"这个模块是非常危险的（例如忽略视图或实体的配置）。适度使用"简单"配置通常是安全的。Config Ignore可以用作完全同步或部分同步的一部分，如何学习大数据，但通常在完全同步之外是冗余的。"已安装"配置此配置与模块/主题/配置文件捆绑在一起，并在安装时安装。这种方法类似于Features模块使用的方法，我通常将其称为部分工作流。注意：功能模块在Drupal7和早期的Drupal8中被广泛使用。但是，在D8和D9中使用较少。配置管理策略示例完成配置同步：使用完整配置同步的主要好处是：所有环境（local、dev、ci、stage、prod等）都具有相同的配置（差别最小）所有配置都通过git进行管理（这意味着对配置的更改会随着代码更改而跟踪）一种环境中的故障——通常是电报机在其他环境中的故障（例如，局部故障几乎总是意味着生产中会发生同样的故障）对于使用config开发的东西，有一个清晰的、可测试的升级路径（例如视图、内容包等）这种方法的缺点是：在那里可以轻松地管理上千个单一平台的文件如果你需要多站点的不同配置，它可以很快失控修补程序可能变得非常具有挑战性（如果您在prod上而不是在代码中更改它，下一次部署将破坏您的更改）概述：所有配置都导出到一个config sync目录（通常是config/default）config split和config ignore用于增强核心配置系统drush用于管理配置导入/导出理想情况下，您可以在部署期间自动导入配置配置导入应在数据库更新后进行请注意，此策略适用于站点和配置文件配置拆分。但是，如果您可以在"所有"拆分之间共享一组公共配置（90%或更高），并在必要时利用分割和/或配置忽略来处理特定的情况，那么它就"最好"了。如果您有一个大型平台，并且每个配置文件/站点都有大量的独特/定制配置，那么这种方法很快就会失效。部分配置同步：使用部分配置同步的主要好处是：对于如何"使用"配置，您有更大的灵活性（此方法最好用于分发版/配置文件/模块和定制的多站点/多站点平台）只有你的配置显式为m