【问题标题】:How can I use TeamCity to do Production releases safely?如何使用 TeamCity 安全地进行生产发布?
【发布时间】:2014-05-31 10:27:33
【问题描述】:

我们目前使用 TeamCity 来构建部署工件,然后进一步的 TeamCity 任务会使用该工件并按需将其部署到我们的开发和测试服务器。

我们可以将密码和其他机密数据存储在我们可以检查到源代码控制中的属性文件中,因为这些都是内部服务器,开发人员可以完全访问它们。

但是,对于发布到生产(以及我们的最终测试层),我们不希望将秘密密码和配置检查到正常的源代码控制中,或者让开发人员能够发现密码。因此,要进行“真正的”部署,我们必须将工件交给另一个团队,他们会维护一个包含生产值的属性文件。

存在哪些方法来存储这些机密并允许 TeamCity 运行部署而不会泄露机密?

(请注意,我是开发人员之一,这不是信任问题...我不想有能力找出 prod 密码,所以我永远不会意外知道它们并造成可怕的伤害!)

【问题讨论】:

    标签: continuous-integration teamcity continuous-deployment


    【解决方案1】:

    您可能需要在这里创建一个权限范围更窄的单独项目(例如,只允许某些人编辑构建配置)。在这个项目中创建一个构建配置,负责部署。在此配置中,您可以定义一个“密码”类型的Typed Parameter 来存储生产环境的密码。

    另一种选择是使用Deployer Plugin,尤其是它能够通过带有私钥身份验证的 ssh 进行部署

    【讨论】:

      【解决方案2】:

      如果您可以使用第三方解决方案,请考虑使用 CloudMunch 之类的解决方案,它可以帮助您执行发布管理功能,这些安全参数在部署时收集并在部署后加密。

      免责声明:我与 CloudMunch 合作

      【讨论】:

      • 不幸的是,如果我们尝试使用任何多云的东西,我们的操作就会死掉,但其他人可能会感兴趣。
      • Loofer,CloudMunch 还提供 on-prem 部署以及支持 DevOps 实施。
      【解决方案3】:

      你可以做两件事。

      1. 使用 teamcity 项目仅部署用于生产的工件。这只有 ops 成员可以访问。

      2. Teamcity 还支持运行具有不同用户 ID 的代理。您可以创建一个可以访问生产“秘密”(密码和配置)的新用户 ID。使用此 ID 在第一步中运行目标。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-10-06
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多