浅谈DevOps，文化、技术和职业发展

anklos

iceman 发表于 2016-8-21 22:18
Jenkins是最差的，可以试试buildkite

buildkite的CD功能也很弱啊

purplechilli

heroxk 发表于 2016-8-20 09:25
数据库一般Dev环境是stub的，integration test环境弄点少量数据，完整数据测试要Load test或者staging环 ...

能展开说一下吗，是同时平行跑2条或者3条或者更多条线？

一条dev, 一条staging,一条prod？
然后每一条线配置不同的数据？ staging或者load test那边需要最接近PROD的数据把？这个同步是怎么实现的呢？比如几百个G或者上T的数据？

楼主和楼上各位指教一下啊，非常感激，我对软件开发这个流程完全不了解，要是问了蠢问题，不要介意哦

还有就是想了解一下，当前比较流行哪些工具，来实现多个代码环境。

目前我接触到， USER -> GIT -> Gerrit/JENKINS, Gerrit 用来做code review, Jenkins用来推送代码到各个服务器。
这样的流程有什么更好的实现方式吗？其他产品工具？其他的流程图？
我是想重新搭建一套，能有多条线的，然后方便程序猿测试的环境，想要了就起一套环境，用完了就随手摧毁掉。

（几分钟似乎夸张了，个人觉得实际环境中有很多要考虑的东西，一圈全走下来还是会远超过这个时间的）

楼上谈到puppet，我个人觉得这个东西用来管理服务端的配置还是比较好，但是有几个较麻烦的地方：

• 服务端的配置一但需要变化，puppet里的config的书写和测试，是要花掉大量的时间的。原来的意图是通过中央管理config来节省时间，但是实际环境里，可能花在维护config的时间，还远大于手动一个个管理的时间。
• PUPPET产品还没固定，有可能还会有很大的改变，比如之前从2到3.X，改了很多东西，以前的配置方式基本需要重写，而不是升级。
  

个人觉得，适用于部署大数量的，服务器之间硬件差别不大的，服务器端更新周期较长的。如果需要管理的服务器数量不多，最好不要上这个东西。

purplechilli

对了，各位有没有兴趣拉一个学习资源共享群，大家共同进步，让我们的微信里不再被二手买卖群，团购群占领

heroxk

anklos 发表于 2016-8-21 11:30
很多CI的工具的CD功能都太弱了，比如没有testing->staging->production的pipeline支持。

jenkins好像是 ...

没有完美的工具。

从CD的功能上讲，Bamboo还可以，支持多环境的持续部署，比如：



当然，bamboo也有自己的问题，比如，和Stash，JIRA整合太深，个人不太喜欢。

czy1024

purplechilli 发表于 2016-8-19 13:57
手动给楼主点个赞啊。有空好好跟楼主取个经，楼主描述的那种 PROD和 DEV的构架，一直是本屌丝想要搭的东西 ...

AWS是managed，有很多限制和意想不到的惊喜。

这句话怎么理解?

你觉得初学者,看书+实验 能够获得AWS的工作机会么?

heroxk

purplechilli 发表于 2016-8-22 09:18
能展开说一下吗，是同时平行跑2条或者3条或者更多条线？

一条dev, 一条staging,一条prod？

heroxk 发表于 2016-8-20 09:25
数据库一般Dev环境是stub的，integration test环境弄点少量数据，完整数据测试要Load test或者staging环 ...

能展开说一下吗，是同时平行跑2条或者3条或者更多条线？

一条dev, 一条staging,一条prod？
然后每一条线配置不同的数据？ staging或者load test那边需要最接近PROD的数据把？这个同步是怎么实现的呢？比如几百个G或者上T的数据？

如果有多个dev，一般Dev环境一般不止一个，同时进行。Staging和load test一般不需要和prod同步。只要测试数据和prod data规模差不多就可以了。



楼主和楼上各位指教一下啊，非常感激，我对软件开发这个流程完全不了解，要是问了蠢问题，不要介意哦

还有就是想了解一下，当前比较流行哪些工具，来实现多个代码环境。

目前我接触到， USER -> GIT -> Gerrit/JENKINS, Gerrit 用来做code review, Jenkins用来推送代码到各个服务器。
这样的流程有什么更好的实现方式吗？其他产品工具？其他的流程图？

基本差不多，但是如果你code需要编译的话，需要有artifact server比如nexus这种。


我是想重新搭建一套，能有多条线的，然后方便程序猿测试的环境，想要了就起一套环境，用完了就随手摧毁掉。

（几分钟似乎夸张了，个人觉得实际环境中有很多要考虑的东西，一圈全走下来还是会远超过这个时间的）

几分钟我是指起一个ELB，一般re-boostrap一圈下来几十分钟还是需要的。


楼上谈到puppet，我个人觉得这个东西用来管理服务端的配置还是比较好，但是有几个较麻烦的地方：
服务端的配置一但需要变化，puppet里的config的书写和测试，是要花掉大量的时间的。原来的意图是通过中央管理config来节省时间，但是实际环境里，可能花在维护config的时间，还远大于手动一个个管理的时间。
PUPPET产品还没固定，有可能还会有很大的改变，比如之前从2到3.X，改了很多东西，以前的配置方式基本需要重写，而不是升级。

个人觉得，适用于部署大数量的，服务器之间硬件差别不大的，服务器端更新周期较长的。如果需要管理的服务器数量不多，最好不要上这个东西。

同意，有的时候，自动化一个任务本身还是比较花时间的。项目小、环境小的话，不需要DevOps

purplechilli

czy1024 发表于 2016-8-22 14:11
AWS是managed，有很多限制和意想不到的惊喜。

这句话怎么理解?

AWS的各种服务，跟日常使用的方式，有一些差别。一些后台的东西和细节，用户是接触不到的，这也算是managed的本来意图吧，后台藏起来，用户不用操心。

如果只是一般的使用，啪啪啪WEB界面，打开几个虚拟机，啪啪啪关上几个虚拟机，一切都很容易。

但是如果一开始加自定义的各种配置，比如起2个网卡啊，一个网卡上多个地址啊，内网外网啊，就开始有各种小地方需要调整了。又如什么防火墙，ACL，SUBNET分配，不同AZ的考虑，起来以后的测试，可以让人刷经验的地方还是不少的。

东西还是常用的那些东西，但是控制方式和平常不太一样，毕竟不是物理机，接个显示器键盘可以直接上，也不是自己的虚拟机，对于跑虚拟机的HOST没有权限。很多平日的系统控制方式，变成了一个WEB INTERFACE和命令行的组合。

而且后面有些潜规则，碰上了才知道，比如OUTGOING SMTP是默认限制的，起邮件服务要填个申请。又比如数据库服务是有读写限制的，具体怎么限制请参阅又臭又长的文档以及相关公式。总体来说，人家是拆虚拟机，带宽，磁盘各种资源来卖钱的，使用前仔细参观文档，有些东西在物理机上是一般不列入考虑范围的，都是顶着硬件性能往上跑的东西。

找工作的话，自己搭一套环境，照着生产环境弄，什么备份恢复冗余自动适配增长负载平衡监控报警数据分析安全审计啪啪啪的全部弄上去，这样简历上写自己曾经设计和deploy过什么什么样的生产环境的时候，也不会太心虚，人家问起来的时候，也可以聊上很多细节，感觉自己棒棒哒。

grandvalley

谢谢楼主分享，写的不错 一直是基于AWS做DevOps, 1和2都做过。现在看2确实要更火一些

jackliu2008

变汤不变药 静观dev ops 的 变化和趋势  静观产品竞争和市场重组  ....

iceman

anklos 发表于 2016-8-22 09:09
buildkite的CD功能也很弱啊

不是很明白你说的CD功能指的是什么？

iceman

heroxk 发表于 2016-8-22 14:07
没有完美的工具。

从CD的功能上讲，Bamboo还可以，支持多环境的持续部署，比如：

Bamboo 整体来说还不错，可是它提供了很多配置的功能，所以很多team就习惯在bamboo上进行配置，甚至写script，所以很难trace。所以好的实践最好是让bamboo就只是执行build的每一个plan，尽量弱化对环境的依赖，比如说用docker来encapsulate project的dependency。

heroxk

iceman 发表于 2016-8-22 21:02
Bamboo 整体来说还不错，可是它提供了很多配置的功能，所以很多team就习惯在bamboo上进行配置，甚至写scr ...

说的没错。实际中我们确实是让build过程docker化。当然这带来了更多shared responsibility的话题，因为docker image的开发任务是由OpsDev和DevOps共同承担的。

iceman

heroxk 发表于 2016-8-22 21:13
说的没错。实际中我们确实是让build过程docker化。当然这带来了更多shared responsibility的话题，因为do ...

我在组里尽量淡化这些role，全功能团队才是王道，呵呵