问大家一个关于运维职责的问题

2016-06-01 09:22:59 +08:00
 LedChang

中型企业,我们公司服务基本上都是 java war 包的形式提供出去,运维基本不改配置文件,要求开发提供好,各种环境的配置。他们部署上线要能直接部署。原来配置在包里,如果配置有问题,他们直接要打回重新出包,而不是改一下配置。这样合理么?

5866 次点击
所在节点    DevOps
37 条回复
kideny
2016-06-01 09:35:22 +08:00
额,我最近就接收了一个 war 包,到现在公司服务器还没配好。
开发写的文档太差,部署太费劲了。
LedChang
2016-06-01 09:37:22 +08:00
@kideny 不说文档好不好,起码生产环境改配置的工作不应该在开发这边吧
ruhua
2016-06-01 09:44:34 +08:00
@LedChang 环境相关的配置文件有问题?具体啥问题
clino
2016-06-01 09:46:58 +08:00
不合理,话说"要求开发提供好,各种环境的配置。他们部署上线要能直接部署"这就不合理哈
goodryb
2016-06-01 10:02:28 +08:00
基础环境还是要运维来配置好的,如果是业务相关的配置,应该是开发在 包 里面提供,随版本一起发布,回滚也是如此。
csdreamdong
2016-06-01 10:10:19 +08:00
可以参考下, zookeeper

我们现在是, jenkins+docker+zookeeper
LedChang
2016-06-01 11:02:06 +08:00
@ruhua 写错域名或者端口之类的
LedChang
2016-06-01 11:09:55 +08:00
@csdreamdong 我们这儿网络环境都是隔离的,我是 QA ,测试环境用 jenkins 加一些 shell 脚本直接部署的,今天上线邮件中有个邮件版本忘记写了,运维直接说了句,不写版本不部署。 但是 1.随邮件的测试报告中已经写清版本了。 2.提供的 svn 库中最新的版本就是想要上线的版本,线上版本是倒数第二个。 3.配置文件也写版本了,难道会部署一个与配置文件不一致的包版本? MDZZ
holyzhou
2016-06-01 11:14:29 +08:00
线上改配置效率低下,等配置文件很大的时候 牵扯到的配置项又有很多,可能有些还是新增的 这种情况下运维需要解包再跟你确定实际需要配置项确定无误再打包。 如果你愿意在我旁边慢慢指导我改完或者出一份详尽文档说明这次更新各个配置项的值,这种情况我是愿意自己来的,但是时间成本肯定还是存在的。又或者我们在上线前就沟通好配置应该填什么,等到上线的时候 直接扔下去就好了
LedChang
2016-06-01 11:23:07 +08:00
@holyzhou 是啊,我觉得需要配合是肯定的,但是强制交给原本对生产环境的 dev 起码是不成熟的,更别提一单配错端口之类的就踢回去重新打包是否更不妥?
virusdefender
2016-06-01 11:28:16 +08:00
你们需要的是 docker
holyzhou
2016-06-01 11:29:51 +08:00
@LedChang 流程都是这样做起来的,开始没人会爽。 至少 dev 清楚配置项所代表的代码里面的更深入些的含义 打包前可以先把配置跟运维那边再确认一下啊
holyzhou
2016-06-01 11:31:01 +08:00
@virusdefender 即使是 docker 配置也是 QA 那边改好的吧 ,运维只是 run 起来,保持交付物的一致性
9hills
2016-06-01 11:37:09 +08:00
配置随便改最后早晚会吃大亏。你们需要的是一个配置中心。

举个我们的实践,比如某个模块叫 fuck , RD 的代码库以及发布的 release 程序包中,是一个 配置模板,类似于 jinja2 的那种,比如

#fuck_config.template
master.addr = {{master_addr}}
port = {{port}}


然后 OP 和 RD 共同维护另外一个代码库,叫 fuck_config ,里面存储一个线上环境的配置情况, eg :

注:我司的机器都是在一个树上维护的


HostGroup: /online/www/xxx
port = 89
master_addr = xxxx.dev.com


HostGroup: /offline/www/xxxx
port = 1233
master_addr = xxxx.dev.com

这样部署的时候,会根据机器所属的 Group 的不同,适配不同的配置。


配置的修改, rd 和 op 均可以发起修改,和上线新版本的流程一样。

而且要求 RD 和 OP 均十分了解线上环境,而不是只有 OP 了解,这点尤其尤其重要!!!
LedChang
2016-06-01 11:47:39 +08:00
@holyzhou 互联网的 OP 都只是 run 起来?我没在特别大的互联网公司待过,原来在 ALU 的时候是,技术支持的同事负责 site 的部署,根据用户手册配置 site, RD 只是偶尔需要提供支持。 OP 不需要了解业务吗?
holyzhou
2016-06-01 11:49:04 +08:00
@LedChang 我指的是 docker 啊 .
aibangjuxin
2016-06-01 14:25:26 +08:00
作为一个运维同学,内容我还是看完了。顺带吐槽下,现在的开发同学。 30 多岁的开发同学了。想要从家里访问公司办公环境,竟然不知道 vpn 是什么,你给他解释下,竟然说。我们研发不需要知道这个概念。连出口 IP 地址都不晓得 还搞个毛开发哪 。要求从办公区网络直接访问 IDC 机房的数据库也就忍了。你能不告诉我,你开了个带管理界面的 Mysql 客户端,想要从线上直接倒出几个 G 的数据,然后还要找我 什么破数据库。卡的要死 。
hl
2016-06-01 15:02:51 +08:00
归根结底还是沟通最重要
9999999999999999
2016-06-01 19:46:37 +08:00
背锅啊
snopy
2016-06-01 20:23:06 +08:00
楼上的,你们用 tomcat 么?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/282639

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX