环境配置管理？
有一个团队开发带有Web界面的企业应用程序：java、tomcat、struts、mysql、REST和LDAP调用外部服务等。
所有配置都存储在 context.xml 中——tomcat 特定文件，其中包含通过 servlet 上下文可用的变量和通过 JNDI 资源可用的对象。
开发人员无法访问生产和 QA 平台（理应如此），因此 context.xml 由支持/系统管理团队管理。
每个版本都有config-notes.txt，其中包含如下说明：
please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and credentials) named "barDb"
这不好。
这是我的想法如何解决它。
每个版本都有特殊的config文件，其中包含所需的变量名称、描述和默认值（如果有）：甚至可以使用web.xml。
这是伪示例：
foo=bar
userLimit=123
barDb=SET_MANUAL(connection to our new server)
并且有一个支持团队针对部署工件运行的特殊工具。 看看它（“>”之后的文本是由支持人员输入的）：
Config for version 123 of artifact "mySever".
Enter your config file location> /opt/tomcat/context/myServer.xml
+"foo" value "bar" -- already exists and would not be changed
+"userLimit" value "123" -- adding new
+"barDb"(connection to our new server) please type> jdbc:mysql:host/db
Saving your file as /opt/tomcat/context/myServer.xml
Your environment is not configured to run myServer-123.
这将使我们能够在任何环境上部署应用程序并在需要时更新配置。
你喜欢我的想法吗？您使用什么进行环境配置管理？有现成的工具吗？
There is a team develops enterprise application with web interface: java, tomcat, struts, mysql, REST and LDAP calls to external services and so on.
All configuration is stored in context.xml --tomcat specific file that contains variables available via servlet context and object available via JNDI resources.
Developers have no access to production and QA platforms (as it should be) so context.xml is managed by support/sysadmin team.
Each release has config-notes.txt with instructions like:
please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and credentials) named "barDb"
That is not good.
Here is my idea how to solve it.
Each release has special config file with required variable names, descriptions and default values (if any): even web.xml could be used.
Here is pseudo example:
foo=bar
userLimit=123
barDb=SET_MANUAL(connection to our new server)
And there is a special tool that support team runs against deployment artifact.
Look at it (text after ">" is typed by support guy):
Config for version 123 of artifact "mySever".
Enter your config file location> /opt/tomcat/context/myServer.xml
+"foo" value "bar" -- already exists and would not be changed
+"userLimit" value "123" -- adding new
+"barDb"(connection to our new server) please type> jdbc:mysql:host/db
Saving your file as /opt/tomcat/context/myServer.xml
Your environment is not configured to run myServer-123.
That will give us ability to deploy application on any environment and update configuration if needed.
Do you like my idea? What do you use for environment configuration management? Does there is ready-to-use tools for that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有很多不同的策略。所有这些都很好，取决于最适合您的。
至于整个开发人员是否应该有权访问产品，这实际上取决于每个公司的基础。对于每次出现问题时都会调用开发人员的小型公司，无论该问题是与服务器还是应用程序相关，那么显然开发人员都需要访问该盒子。
DevOps 并不是让开发人员能够访问盒子，而是让开发人员能够使用基础设施即服务，能够使用配置 Y 的应用程序 X 生成新实例，并将其应用程序推送到没有操作的环境中。在像我们这样的大公司中，它允许开发人员管理他们放置在服务器上的应用程序。运营人员不应该关心他们的版本是什么，那是我们的工作，他们的工作就是保持服务器正常运行。
There are plenty of different strategies. All of them are good and depends on what suit you best.
As for the whole should devs be given access to prod, it really depends on a per company basis. For smaller companies where the dev is called every time there is a problem, regardless of whether that problem is server or application related, then obviously devs require access to the box.
DevOps is not about giving devs access to the box, its about giving devs the ability to use infrastructure as a service, the ability to spawn new instances with application X with config Y and to push their applications into environments without ops. In a large company like ours, what it allows is the ability for devs to manage the application they put on a server. Operations shouldn't care what version is on their, thats our job, their job is all about keeping the server up and running.
我强烈不同意您关于开发人员不应访问产品或暂存环境的言论。正是这种态度导致团队相互对抗而不是共同努力。
但要回答您的问题：您正在考虑通常所谓的持续集成（http://en.wikipedia。 org/wiki/Continously_integration ）并转向 DevOps。理想情况下，您应该瞄准神奇的“一键自动部署”。 Flickr 的人写了很多关于他们如何实现这一目标的博客（和书籍）。
无论如何..该领域有很多工具。您可能想看看 Hudson/Jenkins 或 Puppet/Chef 之类的东西。
I strongly disagree with your remark that devs shouldn't have access to prod or staging environments. It's this kind of attitude that leads to teams working against each other instead of with eath other.
But to answer your question: you are thinking about what is typically called continuous integration ( http://en.wikipedia.org/wiki/Continuous_integration ) and moving towards devops. Ideally you should aim for the magic "1 click automated deployment". The guys from Flickr wrote a lot of blogs (and books) about how they achieved that.
Anyhow .. there's a lot of tools around that sector. You may want to have a look a things like Hudson/Jenkins or Puppet/Chef.