Questions tagged «configuration»

正在尝试尝试在我们的Ansible设置中建立一些弹性，以处理配置和配置。 我了解在事物的配置方面进行测试的几种方法，但是我想知道如何最好地在事物的配置方面进行测试，以及是否有任何工具可以帮助实现这种类型的实现。 目前，我们的许多测试是在剧本期间连续进行的，这对于诸如“有服务出现； vip可用；异步任务已完成”之类的事情很有用，但真正令我感到担忧的是我们管理漂移的能力。在应用程序层和供应层进行配置（例如VM配置）。我知道Ansible并不是解决配置漂移的最佳工具，但我很想知道您的意见。 如果您有什么可以使流程完全自动化的更好。（我们有一些丑陋的脚本，它们每天都会以松弛状态返回报告）。 注意：现在，在一些情况下，可能会发生重新配置（例如，从备份进行重建，严重的系统问题），但是通常情况下，它只是循环执行一些烦人的配置任务，因此不再考虑其他事情。

33 testing  ansible  configuration  provisioning 

MichaelGrünewald最近发布了此评论： 您没有提到的一个非常重要的方法是在金融中使用的“四眼原则” –作为监管义务或作为安全保障。在软件行业中，它以多种方式实现，例如代码审查，但也可用于验证影响实时系统的命令。 如果我错了，请纠正我，但是在至少2个人（和/或自动化过程）给予了他们先前的祝福之后，我被告知“四眼原则”是关于“被批准发生”的事情。或使用有关的（略修正）的措辞“两轮（WO）人治”从维基百科： 两人规则是一种控制机制，旨在为特别重要的物料或操作实现高级别的安全性。根据此规则，所有访问和操作都必须始终有两个授权人员在场。 可以肯定的是，监管义务不在本文的讨论范围之内，但是在“安全防范”的背景下，这种四眼原则的可能概念性实现是什么，它们可能适用于所使用的任何平台/操作系统/硬件？

22 configuration  four-eyes 

最近，我一直在阅读有关“ 应将取决于环境的属性存储在哪里？ ” 的辩论。 经典的方法是拥有多个属性文件，每个属性文件都取决于环境，并且基于环境变量（DEV，PROD ...），您可以选择在启动应用程序时在何处读取它们（例如使用Spring概要文件）。 另一方面，如果您使用容器来部署应用程序，则据说这种配置应来自环境本身（使用应用程序读取的环境变量），因此映像在环境之间不会改变。 每种方法的利弊是什么？容器方案是否有“最佳”方法？

17 docker  containers  configuration 

考虑这种情况（与现实情况的任何比较纯属偶然）： 凌晨3:07：即将到来的支持电话“ 生产中的某件故障，我需要您的帮助！ ”。 凌晨3:12：已连接到系统（已接受登录）...而且没有时间喝咖啡。 凌晨3:15：很幸运，您可以立即通过某个错误消息在某处发现问题。 凌晨3:17：使用您的SCM工具箱获取代码，修复问题，对其进行测试，太好了……我的修复工作正常！ 凌晨3:20：与Dev Ops团队取得联系，以发送修复程序并重新开始生产。 凌晨3:21：危险信号……“ 为了尊重四只眼睛，我们还需要2只眼睛才能获得此修复程序的批准 ”。 凌晨3：22：ggggrrrreat，现在呢，我们还能叫谁（=叫醒经理）？ 如果您实施了类似于我对“ 四眼原则的可能实现方式（或示例）有什么答案？”的回答的批准程序，那么您很不走运……这是您的选择： 您的修补程序将被卡住（阅读：生产将下降），直到另外2只眼睛介入为止。 您想出一种方法来避开丢失的眼睛。 那么如何实施紧急修复的四眼原则呢？...这样您就可以尽快开始生产，即大约 凌晨3:25 ...并且还可以关闭该呼叫（并返回到您的来源）？

13 configuration  four-eyes 

我需要在每个环境中将配置信息存储在工具中。 这是一个带有GUI的工具，用于添加/更新配置值（例如，连接字符串）。这应该具有默认值，并且能够根据不同的环境进行更改。 应该有一个API，可以在部署到特定环境以添加到应用程序期间检索这些配置值。 我搜索了一段时间，找不到适合此账单的任何工具。有什么建议吗？ 注意：当前设置在TeamCity变量中，并且通过PowerShell脚本进行部署。

11 deployment  configuration-management  configuration  software-recommendation  casc 

这是一个有关环境变量/结构的方法和建议的非常广泛的问题。但是最终，我正在寻找非常具体的问题“我应该如何存储环境变量？”的答案。 首先进行一些澄清： 对我来说，环境可以是3到10台服务器，并且是包含特定客户基础结构的一种方式。 在每个环境中，都有一些变量，这些变量通常是由一些关键输入（名称，大小等）自动生成的。 就目前而言，我们将所有环境变量存储在这样的结构中： <playbook>.yml # Various playbooks for deployment roles/windows # Ansible role for Ubuntu roles/ubuntu # Ansible role for Ubuntu config/hosts/<name>.yml # Ansible inventory config/hosts/vars/<name>.json # Environment specific variables 现在，配置已被初始化为上述git存储库中的子模块。由于变量文件的更改非常频繁，这导致了数据更改的问题，两次提交之间发生了一次，两次甚至三遍，使得更改越来越难以跟踪。 正如我个人看到的那样，我们应该寻求以集中/可扩展的方式存储我们所有的客户变量，然后将其与ansible的动态库存挂钩。 我了解有几种技术似乎可以满足要求，例如Consul，但它们似乎在服务于一个大型应用程序而不是许多较小的略有不同的应用程序的环境中效果最佳。 我基本上看到我们必须编写清单脚本，然后将所有数据推送到一个非专用的内置数据库中，然后继续进行，就好像什么都没有改变一样。我认为这可能是一种减少当前存储的大量数据的方法，也许是研究存储数据的不同方法，而不仅仅是扩展再次提供服务的方法。 我希望有人在必须处理许多较小的环境而不是一个，两个或三个大环境时，具有将基础结构实现为代码的某种经验。 有什么建议么？

11 ansible  configuration  databases  provisioning  environment-variables 

我正在构建用于构建配置文件的模板，并且消耗该文件的服务对标识符长度施加了约束。 如果标识符的长度超过例如6个字符，则该服务将在应用配置时中途通过，失败，并使节点处于不一致状态。 如何执行断言以触发部署事务失败，以防止目标节点的服务配置错误？ 我的特殊情况是Salt，但是我很想知道其他系统也可以解决该问题。

11 configuration  configuration-management  linting