使用Maven和Jenkins来管理我的Web应用程序的部署。基本上:
这很好用,并且使用这种技术我可以使用maven替换适当的环境特定配置,只要它们在项目中。但是,我的SysAdmin认为在VC中拥有生产凭证存在安全风险。相反,我们更愿意将生产凭证存储在将使用它们的生产机器上。我可以想象编写一个简单的bash脚本ssh到服务盒中,并将conf文件软链接到类路径上,但这似乎是一个非常不优雅的解决方案。
这合理吗?是否有更好/更标准的方法来实现这一目标?在VC中持有生产凭证实际上是一种安全风险吗?
答案 0 :(得分:0)
您的生产服务器上的某个位置有您的conf文件。这个位置也可能是一个属性。
如果没有特定的理由不将其作为文件从磁盘加载而不是从类路径加载为资源,则可以创建一个单独的Maven profile production
,filter location将其替换为生产服务器的文件路径。
答案 1 :(得分:0)
是的,在版本控制中拥有生产凭据存在安全风险。它使您的开发人员可以随心所欲地完成他们想要的任何生产。医学上的HIPAA或电子商务的PCI或美国公共公司的SoX等法规都不会对此表示不满。您的sys-admin也是合理的。
基本策略是外部化此配置,并使部署过程在特定于环境的数据中滚动。
在生产服务器上拥有这些信息是一个好的,但不是很好的解决方案。当你只有一个目标服务器时,这是一个很好的选择。一旦你有了一堆,就会出现维护问题。环境时特定的数据更改,必须在每台服务器上更新。你还需要确保只有env。其中的特定信息或开发人员对早期环境所做的更改可能无法传达给sys-admin,以便在部署时进行更改,从而导致生产部署错误。
我认为,这就是Hudson让您从持续交付的角度出发。一些商业工具,包括我公司的uBuild/AnthillPro,正式跟踪不同的环境,并安全地让sys-admin配置生产凭证,开发人员使用该工具配置开发凭证。同样,像uDeploy这样的应用程序发布自动化工具可以从Hudson中提取构建并部署它们,应该将这种环境配置烘焙出来。
在这些场景中,大多数property / xml文件都有通用配置,部署引擎替换env。部署时的特定数据。
为这个问题添加新工具可能有点过分,但将环境特定信息外部化到可以查找部署时间的中心位置的基本策略可能有效。由于您是Maven商店,因此您可能会考虑将您的Maven仓库中的部分内容存储在一个仅限操作访问的区域中。然后在部署时为适当的环境提取最新配置。
这里有一系列选项。考虑环境因人而异的变化;什么因服务器而异;需要保护什么,开发方面的时间会发生什么变化等等。请,请与您的系统管理员坐下来一起制定解决方案。你们每个人都有其他人没有的洞察力,最终解决方案对合作会更好。