更改通常涉及单个文件（例如serverless.yml或Makefile），因此涉及共享库的解决方案例如git子模块似乎不可行。每个项目都有其自己需要维护的一组配置，例如Dockerfiles或serverless.yml，因此不适用于VM的集中式配置管理解决方案。
如何确保新的微服务符合组织标准并以现有方式包含现有项目的错误修正/功能？对想要启动新项目的开发人员来说简单而直观？解决这些问题的最佳做法是什么？
我们当前的工作流程是问您旁边的人“我应该克隆哪个项目用作模板？”然后删除该项目不需要的所有内容。
#1 楼
我将回答到目前为止的解决方案，但是我仍然非常想听听其他组织如何解决此问题以及他们拥有的最佳实践。解决以下问题由于没有一致的基础来创建项目，因此我的想法是创建样板/模板的存储库（存储库？），并使用cookiecutter作为工具来构建新的微服务。这样，每个项目都是从一个标准的基础上创建的，并将我们作为一个组织所学到的所有经验教训都集成到其中。我们所做的任何更改都可以上游集成到样板存储库中。我想我们将拥有Nodejs Docker映像，无服务器SPA，Python lambda等的模板。
要解决对传播到每个项目下游的模板所做的更改的问题，我的解决方案是实施一个使微服务的所有者知道模板的更改，然后负责将这些更改传播到其微服务的过程。
#2 楼
使用配置管理/自动部署系统。这就是这些设计的目的。诸如Kubernetes，Puppet，Chef，Ansible和Salt Stack之类的东西就是为此目的而设计的，可以与Golden Master模板，kickstart脚本，Amazon AMI或仅用于Docker容器一起使用。这使您可以使用默认的基本模板，然后在其他角色上分层。这将确保将构建完全记录（作为代码），并且将快速，轻松地将其部署到生产中，并且将与设计的部署完全相同地部署，或者在出现可伸缩性或冗余需求或出现故障时部署其他实例。更改/更新也可以通过这种方式集成。就像发布软件更新一样，您可以发布配置更新，并且可以像管理软件代码一样管理配置代码-在相同的存储库中，使用相同的工作流程。而且，当升级时间到来时，构建它的方式并没有什么神秘的，只需看一下脚本即可。配置管理系统执行此操作的一种方法是大量使用配置文件的模板。例如，在您的环境中，通常会有很多行相同或相似。 SaltStack使用jinja模板，puppet使用Embedded Ruby模板。以AWS为例，您可能需要设置一个api密钥，IAM角色，区域（或从区域列表中随机选择一个区域），VPC等，在所有实例中都相同。但是随后您需要使功能和输出具有唯一性。或者更好的是，您可以编写一个定义“合同”的人偶模块或盐公式，并将这些合同（API定义）用于输入和输出，从而使您不必在两个或三个地方配置微服务。
例如，SaltStack最近召开了一次聚会来讨论此特定情况。此外，SaltStack还能够本地管理和部署Docker容器。 （Puppet还具有适用于Docker的模块）同样，Ansible也具有用于处理无服务器部署和Docker容器的剧本和文档。如果您希望继续使用此主题，则saltstack都是无主模式或支持无主模式。
评论
我在问题中添加了一些示例和说明。配置管理并没有真正的帮助，因为每个项目的配置都是独立的。将配置迁移为代码没有问题，这是关于将配置保持为代码，并且如果您拥有100个具有不同配置的微服务，最终可能会导致配置泛滥。目前，我们在CI / CD中使用一致的版本，因此也不在乎。
–user2640621
17-10-18在22:23
@ user2640621-您曾经使用过配置管理系统吗？集中化“配置扩展”可帮助您更轻松地从一个位置（而不是100个不同的位置）进行管理。尽管每个项目可能都是独立的，但是当您询问模板部署时，显然会有一些重叠。在注销之前，最好在sanbox中尝试一下，以了解它们的工作原理……这不仅可以自动管理配置文件，还可以做很多工作。
–詹姆斯·谢威（James Shewey）
17-10-19在5:17
我使用过SaltStack，Chef和Puppet，但仅用于管理VM。感谢您的回答，我肯定会看到现在如何在管理VM之外使用配置管理。
–user2640621
17-10-19在6:08
@ user2640621：如果它们都不同：“编写代码，然后运行它”。让团队管理他们的服务运营。让他们感到你的痛苦。
–马丁·施罗德（MartinSchröder）
17-10-20在20:47
#3 楼
这个问题很广泛，因此，如果我的回答有点离题，请随时添加上下文和特定示例，以便我更好地理解。使用诸如AWS AMI的机器映像可以使您创建基本或金色图像，然后可以在连续交付中进行维护，分发或实施。使用此架构，您可以确保将每个微服务部署在具有相同配置的一致硬件上，以便您遇到的任何问题都与微服务/应用程序配置有关。
您可以通过添加诸如Ansible和Packer之类的配置工具来进一步实现这种不变性。使用配置管理，您可以在计算机映像上提供所需的任何内容（包括应用程序）。 Packer随后将允许您为该计算机映像拍摄快照，并且每个部署都将是相同的。
使用本示例，您可以在Ansible和Packer的帮助下“烘烤”具有正确软件包，更新和配置的基本AMI。此外，您可以通过提取应用程序代码，进行任何更改并在该基础映像之上部署微服务，来查看“ Ansible-Pull”以完成部署。
但是，我能提供的最重要的建议是提出一个整个组织可以支持和维护的解决方案。值得尝试建立一个SDLC，以解决您的特定问题，与领导的文化和态度相匹配，并采用现代建筑实践。
我已经在三个组织工作过，我们已经聘请了三个组织非常不同的方法。
祝你好运！
评论
我们没有使用任何基于VM的解决方案（主要是无服务器和一些Docker），但是我将尝试将问题应用于您的示例。当有人要创建新的打包程序映像时，他们将从哪里开始？如果每个项目都是独立的，并且没有用于打包程序配置的中央存储库，那么它们将用作创建映像的基础吗？可能的区别之一是，我正在处理的项目尝试尽可能独立，而不依赖于诸如Ansible这样的集中式服务，您可以在其中为所有项目立即更新配置。
–user2640621
17-10-18在22:08
使用无服务器和基于Docker的体系结构，您仍然可以应用这些基础知识。一种策略是维护基本docker文件。您可以构建一个基于centOS的docker文件，其中包含您希望在每个微服务上进行的一些配置，然后每个团队都可以拉入该docker文件并在此之上构建自己的特定于微服务的docker文件。为了帮助进行容器管理和持续部署，您可以使用Kubernetes之类的工具。
–乍得
17-10-20在21:05
评论
这就是我们的工作，并结合了一个简单的hello world应用程序，该应用程序以具体示例说明了最佳做法。
–熊佳亚诺夫
17-10-20在6:38