Questions tagged «databases»

我正在和一个朋友讨论Docker用例。团队中的一个人想使用Docker来完成所有工作-就像一种通用的unix进程包装器。另外认为，应该多克仅用于无状态的类似应用微服务和AWS LAMBDA风格的应用程序。 我们为两者设计了概念证明。在我们的Docker集群上，我们有一个共享驱动器，该驱动器在Docker主机安装时就被挂载了，如果在容器中的数据库被挂载了，它只会将一个卷挂载到共享驱动器上。 尽管有相反的证据，我的朋友仍然坚持他的立场。（他还指出，Docker通过增加堆栈的复杂性而增加了不必要的风险。） 无论是出于同理心，还是与他更好地推理，我都试图倾听并理解他的观点。（我们都相处得很好-因此，这是疯狂和认真讨论的结合）。 问题背后的一种问题是：数据库是牛吗？此注释表明，对于数据库而言，良好的自动备份和检索策略与牛服务器是无法区分的。 我的问题是：为何不应该将Docker用于数据库？ 编辑： 人们要求我阐明我的术语。我以为数据库应用程序位于容器中，而存储位于卷中。我的意思是，RDBMS位于容器中，而数据库存储位于卷中。 一些评论者建议docker卷驱动程序不能很好地处理数据库写入。（或类似的东西）。您能对此进行扩展吗？

25 containers  databases  cattle-vs-pet  risk 

与尝试对数据库（尤其是RDBMS）使用相同的方法相比，连续交付或持续部署基础结构和代码相对简单。部署完成后，代码和基础架构将不会更改或发展。但是，如果数据库不是架构固有的可变组件，则将向数据库中添加新数据，从而构成数据。 我知道有一些做法，例如仅添加数据库对象（即表和列），从不修改或删除它们-这种纯粹的累加方式来处理数据库架构，具有确保架构向后兼容的优势，但代价是顺序复杂一些模式。 同样，还有诸如Flyway和Ready Roll之类的产品，它们可以帮助编写要在模式版本之间编写的迁移。 当前存在哪些其他实践和工具可以将数据库架构连续部署到关注数据完整性的生产环境中？

17 continuous-delivery  continuous-deployment  databases 

这是一个有关环境变量/结构的方法和建议的非常广泛的问题。但是最终，我正在寻找非常具体的问题“我应该如何存储环境变量？”的答案。 首先进行一些澄清： 对我来说，环境可以是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