浅谈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，全功能团队才是王道，呵呵

heroxk

iceman 发表于 2016-8-22 22:02
我在组里尽量淡化这些role，全功能团队才是王道，呵呵

OpsDev的设置是横向的，横跨多个Dev team，DevOps一般是纵向的，位于各个Dev team里面。比如出现系统级别的security bug，进行patch肯定是全局的，横跨整个企业系统的，所以一般又OpsDev去完成，不应该是每个dev team自己去负责。这样才能保证一定的统一性。

anklos

iceman 发表于 2016-8-22 20:56
不是很明白你说的CD功能指的是什么？

1. Pipeline 限制：Test -> Staging -> Production. 所有的软件包必须经过这个pipeline才可以最终到production。CI是没有这个限制的，CI生成的任何软件包可以直接部署到任何环境。

2. 权限限制。不是所有人都可以部署到production，以及看到production的相关配置。

3. 信息显示。很清楚的看到各个环境中部署的是什么版本。

heroxk

anklos 发表于 2016-8-23 10:14
1. Pipeline 限制：Test -> Staging -> Production. 所有的软件包必须经过这个pipeline才可以最终到produ ...

CI和CD很多时候是分离的，分割线就是Artifect。CD可以根据Env放不同的pipeline，给不同的用户不同的access，然后通过pipeline dependency来实现实现的。总归都有workaround。

lliu

楼主好，我是个小sys engineer， 就是你说的第二阶段。 想往devops发展，请问从哪里入手呢？

purplechilli

小妞爷他爸 发表于 2016-8-19 11:41
楼主有没有DevOps 相关的  wei ** xin ** 群？

足迹真不够大气，连微微微微微微微微微***********信 关 ...

来来来

heroxk

lliu 发表于 2016-8-25 14:59
楼主好，我是个小sys engineer， 就是你说的第二阶段。 想往devops发展，请问从哪里入手呢？ ...

你的职业目标是OpsDev，还是DevOps (CI/CD)？

heroxk

purplechilli 发表于 2016-8-26 10:47
来来来

加了，多谢兄弟。

richsea

又多了一个opsdev？这年头的概念太多了，吓人啊

lliu

heroxk 发表于 2016-8-26 21:58
你的职业目标是OpsDev，还是DevOps (CI/CD)？

OpsDev

sennylu

现在的IT搞得云里雾里的，自己在家搭环境费钱不说，关键是不一定靠得上工作实际情况。而且各种工具使用，都需要时间去学习，还有python这种语言也要逐渐熟练。入门门槛现在越来越高

小半个月亮

学习

heroxk

lliu 发表于 2016-8-26 22:06
OpsDev

从SysEng到OpsDev，其实最大的改变不是技术，而是思想。用一种软件开发的思路去管理系统。比如以前管理是每台主机登陆式管理，有bug一个一个登陆了去修复。而现在提倡的是像修复软件bug一样去修复一个系统，要能大批量的修复，修复要快速，修复出现问题可以轻松地回滚。这里所关注的不只是bug本身究竟修复了没有，更注重的是修复bug的过程。这也是OpsDev的涵义。此外还有一些理念，比如不怕系统有问题，Fail Fast, Fail Often，等等。多了解和体会DevOps文化，会有很大帮助。

heroxk

sennylu 发表于 2016-8-26 22:13
现在的IT搞得云里雾里的，自己在家搭环境费钱不说，关键是不一定靠得上工作实际情况。而且各种工具使用，都 ...

如果你指的是DevOps，没错，门槛不低。一般大多是一定基础和行业积累的人转去做DevOps。

而真正的DevOps，市场是还是非常缺的，所以现状就是，入行不容易，但行业又很难招到人。

ttma1046

heroxk 发表于 2016-8-13 09:07
再谈谈

2） DevOps (CI/CD)

我不是搞java的，不知道maven怎么编译打包的

如果没猜错是类似.net的nuget的吧？

maven是把git repo上的东西 拿过来 编译打包吗？

那个放错位置的patch，在git status的时候，是不是一个“untracked file”？

但是其实这个原来的文件被patch的话应该是一个“modified file” ？

整个issue不是应该一句git status就能看出来的吗？

iceman

ttma1046 发表于 2016-8-28 19:53
我不是搞java的，不知道maven怎么编译打包的

如果没猜错是类似.net的nuget的吧？

建议先去Google一下git和maven的基本概念

ttma1046

iceman 发表于 2016-8-28 20:26
建议先去Google一下git和maven的基本概念

那里说错了？求指教？

git天天用
maven是package manager.

sennylu

heroxk 发表于 2016-8-26 22:38
如果你指的是DevOps，没错，门槛不低。一般大多是一定基础和行业积累的人转去做DevOps。

而真正的DevOps ...

转行来做Sysops，没有coder背景，刚上手的那三个月，硬生生的手腕敲出了腱鞘炎复发，一边写脚本一边谷歌。。