这不是一个具体的技术问题，而是更多建议。
我进行了一些搜索，但是很难找到完全相同的问题。如果您认为这是另一个问题的重复，请给我一些链接！ ：-）
作为许多开发人员（我想），我有一台“ Ali Baba的洞穴”服务器托管我的博客，并提供多种服务：GitLab，Minio，我的自由帐户的账单系统等...
所有服务都是根据我可能的可能性在Ubuntu服务器上使用不同的方式设置的：apt-get install，tar提取或针对个人项目的Capistrano部署。
这是有效的，但对我来说却是个维护难关。由于系统依赖项与另一个依赖项冲突或在我的操作系统上根本不可用，因此某些项目无法升级，或者更新可能会对某些项目产生副作用。例如，我的个人项目所需的PHP升级完全破坏了手动安装的PHP服务，因为不支持新版本。
我目前正在学习Kubernetes和Helm图表。目标是建立一个新的CoreOS服务器和一个Kubernetes生态系统，其中包含我所有的应用程序和项目。
有了它，我将能够：
我通过使用helm create my-network创建了一个基本图表，创建了一个基本的nginx应用程序进行了测试，非常适合添加我的网络主页！
但是现在我想添加并连接一些应用程序，让我们从Gitlab开始。
我发现了两种添加方式：
helm upgrade --install gitlab gitalb/gitlab命令即可进行配置。两者都能起作用，给我几乎相同的结果。
第一个解决方案似乎更“独立”，但我真的不知道如何在CI下构建/测试它（我想自动化升级）。
第二个允许我用单个values.yaml文件配置所有文件，但是我不知道在升级过程中要做什么（在图表升级过程中是否运行gitlab的升级过程？）合并到一个“项目”中。
GitLab是一个示例，但我想通过这种方式添加更多“即用型”应用程序。
您对我有什么建议？解决方案1或2？对于这两种解决方案，特别是对于升级/备份，我应该真正照顾些什么？
如果您有完全不同的第三种方案建议使用Helm，请放心！ ：-）
谢谢
答案 0 :(得分：2)
我的经验通常是，对每件/每项服务使用单独的helm install会更好。如果这些服务具有依赖项（“微服务X需要Redis缓存”），那么将它们放在requirements.yaml文件中是件好事。
一个大的“图表”会遇到两个问题：
Helm将展平依赖项，因此，如果服务X需要Redis，而服务Y也需要Redis，则图表设置将安装一个Redis并使其共享；但实际上，这通常不是您想要的。
将“共享”配置与“每服务”配置分开会有些怪异。对于单独的图表，您可以使用helm install -f两次来提供两个单独的值文件，但是在图表中，很难在不复制所有内容的情况下拥有一组真正的全局设置以及一组每个组件的设置。
有一个标准的命名约定，其中包含Helm helm install --name和特定的组件名称。如果它是service-x-redis，这看起来很正常；如果是service-x-service-x，这有点奇怪；如果您有一个全局发布名称，the-world-service-x，这有点奇怪。
有充分的理由要启动某个东西的多个独立副本，或者仅测试一项特定服务的部署脚本，如果您的唯一部署是“绝对所有”，则难度会更大。
对于您的用例，您还可能考虑非Docker系统管理工具（Ansible，Chef，Salt Stack）是否可以在不完全重建系统架构的情况下重现现有的手动部署； Kubernetes非常令人兴奋，但是旧的方法也能很好地工作。