DevOps工具和技能大整理！DevOps2015热血青年Day2笔记也来了最新消息

图片来源:

林小草

作者：网络行动科技NETivim工程师郑富源和“林小草的光影切片”网站，本文经作者授权转载。原文网站链接

DevOps2015第一天也有超详细笔记，点我开始看

第二天在开场致词时，iThome 电脑报总编辑吴其勋提到，这天会比较 focus 在工具与技能，因为这场研讨会可以报名单天的场次，所以他也略提了前一天的议程，包括：直井久和先生的经验分享中，不仅是导入 CI/CD 会遇到流程面的问题，可能根本在 CI server 就出问题了，应如何解决；趋势科技提到怎么做大量资料的转移。

iThome 新闻主编王宏仁则想强调 DevOps 是 IT 人的新技能、新文化。1998 年，是世纪末最大的流星雨，当时王主编在天文所工作，将流星以数位摄影拍摄后，要分析流星的位置。当时最大的障碍是，raw data 一张照片就是数百 mega bytes，当时的主流硬盘约 40GB，而网络带宽也不及现在，要如何将美国夏威夷观测的硬盘资料传回台湾？就成为彼时的技术瓶颈。虽然有为了跨国传输拉了专线，但传完大概要一周，当时最快速的传输工具是：DHL 航空快递！有时解决问题，选定的工具技术新旧不是重点，重点是如何挑选能够解决当下的主要问题。

开场也再次回顾了前一天有提到的 2014 年 DevOps 大调查，几乎都是 DevOps 从业人员来参与填写，增添了这份报告的可信度。可以从中发现反而是非资讯科技业的公司、小公司，会大量导入 DevOps 相关技术，尤其是金融业，常常会走在技术的最前端。有兴趣看报告的人可以到 puppet labs 看看：

2014 State of DevOps Report
2015 State of DevOps Report

进正题啰！

【DevOps in the Cloud：Google 云端平台 Developer Advocate -- Ian Lewis】

Ian's Twitter: https://twitter.com/IanMLewis
Ian's Speaker Deck: https://speakerdeck.com/ianlewis
Ian's Google Plus: https://plus.google.com/+IanLewis-hoge

企业必须变得更敏捷、快速、有效率，所以要找对的工具。他放了一张讽刺漫画，内容是原始人以人力拉着货往前进，后头的人拿轮子出来想要建议拉着货的人为货箱装上轮子，但推货的人却回头说：“不用了，我们太忙了！”正是目前导入时常见的迷思：太忙了，没时间导入使用对的工具。

这场我觉得没有特别提到什么概念，总之就是要选用对的产品、更敏捷的因应问题，主要就是谈 Google 的云端平台如何解决问题。

〖演讲后的 Q&A〗

Q: 在 DevOps 的工具选用上，虚拟化或是 container 比较好？

A: 对 Google Cloud 而言，container 是个比较好的选择。
Q: 怎么把 application 转移到 container 上？有建议的最佳做法吗？

A: 坦白说这没有明确的答案。

（备注：因为搞不懂 container 是什么，上网找了一下，从这篇《DevOps: 快速的布署测试与上线环境 (Docker + Puppet + Vagrant)》看起来，container 相对于 VM 的映象档，似乎是一个比较小的 package？）

【厨师与服务器 (Dancing with Chef)：趋势科技资深工程师蔡宗城】

系统管理者一天会面到各种问题：例如 OpenSSL 又被发现新的弱点，要把所有的 patch 上到 server 上；需求来得又快又急，要把 build 上到 server 上；台湾时间到了夜半，美国的 user 却很活跃，网络服务出问题，就被挖起来加机器；web service 时好时坏，检查后才发现是手动修改了 config 后，忘记重开机器⋯⋯

这一场的目的就是让大家舒适愉快的面对工作～

过去我们都是参考手册去人工作业建机器，但是可能在操作过程中漏了步骤、或是文件本身就不完全，以至于每个人做出来的机器都不一样。理想的状况应该是把它写成 script，该开的资料夹、该做的设定，都由 script 一键完成。

在 chef 里，有 cookbook 的概念，里头会定义以下的东西：

Recipe: resouce 在何时产生
Template: 过去 config 都是写死的，现在可以用程式动态去产生 config 内容
Attribute: 细节的设定

（现场有 live demo 但是我好想建议讲师不要冒险啊～虽然大家每次都笑说 live demo 才是真男人但是几乎每个场子里 live demo 都会挂啊啊啊，而且后来果不其然的因为网络问题而挂了 XD）

过程中讲者也分享他维护的经验：AWS CloudFormation 不容易 debug，Stackoverflow 反而比 AWS 的官方文件还可靠（因为 AWS 更新频繁，官方文件很容易就过时了）。

Chef server 一定要灌在 Linux 上，chef client 则是跨平台的，Linus & Windows 皆可。

〖演讲后的 Q&A〗

Q: 为什么要用 CHEF 不用别的？

A: 当时都有 survey Puppet, Ansible，CHEF 目前放在一百多台 server 上运作，都跑得很好；但是跨平台表现，CHEF 在 Linux 表现比较好，启动很快就会启动好，但是 Windows 大概要花三分钟时间启动，时间上差三倍，启好以后两边执行后续 script 的速度倒是一样。

【Yahoo行动App开发在持续整合与持续交付的经验分享：Yahoo 亚太区产品研发工程部软件工程师李卿澄】

Website http://qcl.github.io/
blog http://blog.qcl.tw/
slideshare http://www.slideshare.net/qingchenglitw

导入持续交付 (CD, Continuous Delivery) 是希望能够短时间提交高品质的产品，透过自动化，让品质更安全稳定。在 Yahoo，程式码提交 (commit) 之后，一路到上正式环境 (production) 都不会有人为介入的空间。（中间的测试也都是自动化的）

如果在测试过程里，发现测试无法通过，会停下手边开发的工作，尽快修复该版本的修正，才继续写新功能。尽量立即处理错误。

在 Yahoo 有个 dashboard，可以让大家即时看到是否有错误发生，不过通常大家虽然会把浏览器停在 dashboard 画面上，但专心开发时，并不会注意 mail 或 dashboard。所以就像前一天天应百怡的分享，会在各 team 摆一个实体的灯具，只要有问题就会立即亮出特殊色的灯号，所有路过的人都会看到。

Continuous Delivery pipeline
Commit Stage: 确保程式可以 build
Acceptance Test Stage: 确认新 feature 不会让旧 feature 坏掉之类的
Non-functional Testing

在提交程式码之前 (Pre Commit)，有些事要先搞定：

在本机要先确认过可以 compile 通过
在本机做好 unit test 等种种测试

Pull commit 之后，要做 code review，人工检验程式码是否合乎 quality，也不要没有做过 code review 就直接 merge 程式码到 code base 里。

除了人工的 code review，也会透过 CI 等机制做简单的测试，确保程式可以正常 build、也可以通过基本的自动化测试，以避免少量的错漏字（例如 JSON 里中间的元素少打一个逗点，或特殊的注解文字造成后续都被注解掉）。

确认程式的健康度：

测试的涵盖率
检查有无重复的 code
检查错误的数量

也会做 Smoke Test，确认 APP 打开有没有 crash，透过 UI automation 来测试是否程式反应与表现如预期。

Non-functional Testing

做一些 UI 之外的事，例如稳定性或效能测试
效能测试由 Monkey Test 来做测试，请花果山的猴子们随便乱玩一下：写一支 script 随机滑动

实务上要注意一些例外的情况可能会让测试没有执行到，以 iOS 为例，打开飞航模式后，没有网络，所有与网络有关的功能都不能 work；从上面滑下来的通知中心，也会让操作跳出要测试的 APP。到最后，仍然会有需要人工测试介入的部分，譬如说金流之类的内容需要人工来输入验证。

〖演讲后的 Q&A〗

Q: 程式 commit 到 version control 之后，可以自动触发测试吗？

A: 会把新的 unit test 放进Jenkins 里

（备注：因为我个人对 Yahoo 的 APP 相关议题有兴趣，所以找到赛拉维之前讲的这个：《当网页遇上原生 APP》，一并收起来。 :)）

When Web meet Native App from Yu-Wei Chuang

【Ansible实战：Top-down观点 (Practical Ansible: A Top-down Introduction)：Gogolook 架构师叶秉哲】

Ansible 实战：top down 观点 from William Yeh

这场是唯一一场在一开始就告诉大家简报档放在网络上的！已喷泪～（而且我觉得简报放在 slideshare 或是 speakerdeck，比放在 dropbox, google doc 或是网站空间好得多了，因为这样要整理成文章的话比较好嵌入啊⋯⋯我自己其实不太喜欢一直要另开视窗去读东西，不方便卷回来比对前后文章）

为了让大家可以跟上来、也可以回家自己玩，叶大有做 ansible 的 lab：https://github.com/william-Yeh/practical-ansible

ansible 是个功能多、轻巧、好扩充的组态管理工具，用了三年觉得很好用，在现场 demo 给大家看。lab 的内容就是昨天的架构来实做：先收 http / https request，Load Balance 是 HA proxy，然后后端会有 node.js 处理，再丢到 redis 做 database 处理。除了 Application server 用 Ubuntu 14.04，前面的 load balance、后端的 database 都用 CetOS 7.1。

DEMO 流程计划是这样来（但后来时间不够所以有些就带过了）：

先用牛刀杀鸡，让大家感受 ansible 的重要观念
规划
部署
组态的测试（确保部署上去没问题）

某个 service 挂掉的时候，通常我们会 ssh 进去重启服务，最笨的做法就是一台一台连，进阶一点会用 sshx 一口气对多台操作，透过 ansible 可以更轻松完成这样的操控。只要主机有开 SSH、有 Python 2.5 以上版本，就可以透过 ansible 操控。

透过 ansible 也可以管理云端主机，先将主机分群（标上 tag or label），到时候就很容易管理。ansible 新版可以 pull，写在 cron job 就可以让 ansible 定时去 pulling。

Ansible Galaxy 可以想成是 Ansible 里的 github，里面充满了别人写好的指令，需要的时候可以直接在 playbook 里设定，不用自己慢慢试慢慢学。

Continuous Delivery 这本书里的第十章，有提到 Rolling Back Deployments and Zero-Downtime Releases，上版遇到有问题时可以顺畅的退版，可以运用 Ansible 来实现这样的部署。（备注："Continuous Delivery" 有中文版欸，后来得宽科技的陈正玮有介绍这本，提到中文版是简体翻繁体的，如果觉得翻不好还是建议买原文 kindle 版，不到 10 元美金。）

Ansible 还可以支援其他更新情境：

blue-green deployment: 假设十台机器里，有特定几台想要放新版程式、其他台都维持在旧版
rolling upgrade: 滚动式的更新，一次做一台、做成功了再做下一台。在 playbook 里加上 serial: 1，就可以一次对一台主机执行脚本，有任何一台有问题就会停止（心脏够大颗、机器又很多的时候，也可以一次十台十台的做）

Test kitchen 可以用来模拟测试组态。

（备注：讲者另外在其他活动有讲过《安装 Nginx 的 101 种方法／Ansible 简介》，我之后想来研究一下 Nginx⋯⋯）

【从DevOps观念看Web前端开发测试先行：资深架构工程师戚务汉】

From devOps to front end Ops, test first from Caesar Chi

Caesar’s bog: http://blog.caesarchi.com/
Caesar’s slideshare: http://www.slideshare.net/clonncd

没有做测试的布署，就像是在裸奔，没有任何的防备与预先规划，上线后可能会遇到种种问题。测试有做比没做好（先不考虑涵盖率），上线之前要有“测试先行”的概念。

有时大家的 BDD 不是行为驱动开发 (behavior driven development)，而是 Boss Driven Development（老板驱动开发），我们希望所有的流程架构都自动化，而不是老板或主管来驱动测试。

将前端拆解开来，用了再多的 framework / library，其实元素也就是 HTML + CSS + JavaScript，再依架构应该可以把这些元素从这三个构面看待：

convention: 所有人的 code 应该都长得一样才对 e.g. 透过 JSCS 来验证 JavaScript，HTML 会使用 jade (采用缩排与断行产制 HTML，会符合标准格式，不会再有忘记结尾的 tag、或属性多了或少了双引号) ；SaSS 来处理 CSS。再在 git 做版控时加入 ghooks & precommit-hook 等 validate plugin，让 local 端只能上传格式正确、完整正确的 code
controller: 指 user interface，将 web components 拆解成 UI event & logic function 两个构面，logic function 可以使用 mocha 或 chai 这些 testing framework，让程式获得验证。Angular 用的测试前端是 Karma、后端是 Jasmine。
compresser: 通常会用 gulp / grunt 来处理，把前面的验证都再测试一次。

UI event 的测试，Caesar 推荐用 Phantom JS 这个架构来测，它不必开 browser 就能测试。

Protractor 可以拿来验证，UI test 则用 Selenium HQ。

虽然需求一直改，但是前端常会被改动的是物件的位置与外观，通常 data / behavior 不会变，例如登入模组，可能会被改变按纽与输入框的颜色，但账号值、账号验证等通常不变，因此可以把测试抽出来处理。

每个单元的测试应该尽可能小（先求有再求好），不必设想所有的可能性，一样一样来。

作为一个工程师最好是

要做测试
分享好的概念
建立 jenkins server
准时交差
洗老板的脑

Google 了一下发现讲者在前阵子有在别的研讨会谈团队经营。

From devOps to front end Ops, test first from Caesar Chi

【在DevOps丛林里的小队游击战术 (The Survival Guide for Small Team in DevOps Jungle)：得宽科技DevOps Engineer陈正玮】

DevOps丛林里的小队游击战术 (@ iThome DevOps 2015) from Chen Cheng-Wei

陈正玮的个人网站: http://chengweichen.com/
陈正璋的 slideshare: http://www.slideshare.net/warfan

刚入行时什么都要处理，经验过各式各样的问题处理，连电锅不会热都要去处理。曾经在工作上遇过董事长还会要资讯人员 survey 长辈可以用的手机⋯⋯标准的有电的地方就是资讯人的事。 XD

得宽科技 (The Qwan technology) 是以网站建置为主业，为部落客建置过购物平台、社群网站分享内容的功能、珠宝的工厂后台等。得宽科技只有四五个人，不是大公司，但却有一位专职的 DevOps Engineer，是因为导入 DevOps 可以让这样的小公司更有效率的运作。

进入丛林应该要有个生存手册，懂得如何野外求生，导入 DevOps 也应该要有一些基本认知：

Lean: Lean Enterprise
Agile
Continuous Integration (CI)
Continuous Delivery (CD)

讲者推荐阅读 The IT Revolution DevOps Guide。他认为 DevOps 对公司的好处是：即使 DevOps Engineer 人在这里分享，但因为公司里每个人的技能略有重复，即使 DevOps Engineer 不在，仍能无后顾之忧。

选择 DevOps 工具时会从几个角度选择：

符合需求（不会因为 docker 很潮就选 docker XD）
学习成本（要花多久时间才能学会？要多久才能教会其他同事？）
设计逻辑
价格
售后服务
商业支援（工具是否能长治久安的维护下去）
教学资源
有无热络的社群
生态系

他们参考 "Continous Delivery" 一书的目录来调整了得宽科技的流程。

version control 用 git & bitbucket
上线用到 Packer
组态管理也用到 Ansible

【不只自动化而且更敏捷的Android开发工具Gradle（A Productive Android Development with Gradle）：HTC 技术副理邱炫儒】

不只自动化而且更敏捷的Android开发工具 gradle from 炫儒邱

讲者出版过《CI (Continuous integration) 关键技术：使用 Jenkins》，这场要介绍 Gradle。

开始讲之前先看了一段 NetScape 要 release source code 作为 Mozilla 开源专案的记录片。

从 Mozilla 的例子鉴古知今，在软件交付中可能会遇到一些问题，使用 Gradle 这样的 CI 工具可以解决一些问题。

convention 1: 消除沟通的嫌隙

套用最近流行的一句话惹毛 XXX 的 pattern，一句话惹毛 DevOps:“我电脑没这个问题呀！”build 失败 / 被发 issue，但是 developer 却表示在开发阶段没有遇到这样的问题。Gradle 希望能够作为设定的中控管理，让 IDE、测试环境、正式环境等都能尽可能接近，避免在不同主机上会出现不同的状况。
convention 2: product flavor and multiple APK

Product Flavor 是 Gradle 上客制化 APK 的功能，让开发阶段的程式能够接近实际的状态，像 versionCode，如果由人工维护就很混乱，可以透过设定让 Gradle 自动产制（计算 versionCode 的动作也可以放在 Jenkins 里做）
convention 3: 有条不紊的程式码管理

Gradle 的目的是要建立可重复且可靠的流程，所以在 souce control 阶段，产出的暂存档与执行档就不应该放到版控里，应该编辑忽略清单 (ignore) 来略过这些档案，让程式码布署到其他主机也能直接编译执行。

Gradle 管理套件的相依性，预设会假设套件都是向前相容的，当遇到相同套件时会选最新版本的为主，但这个 policy 也可以关掉，只要一有版本不相同的同名套件就让 build failed。可以设定 CI，若有违背架构原则就让建置失败，例如，规范不可以有版本相依套件等。

【Chef与Devops技能：Chef 全球传教士 Michael Ducy】

这场的重点就是 live demo，所以先简单介绍 Chef 可以做哪些调整，接下来就直接进 live demo 了。

Food Critic，可以用来测试 cookbook 的设定是否正确
RuboCop
ChefSpec，模拟 Chef
Test Kitchen，模拟 chef 用

小结这两日的我个人心得：

这一场办在平常日，我觉得对象应该是上班族，可是官方网站把议程内容放在特殊 port，我看了一下，不只是我啊，别的公司果然也被挡了；还有便当有点让我想回去办公室好好上班XD
活动有收费，所以当 live demo 卡住又没有备案而任由时间空转时，我忍不住会好奇现场有多少人瞬间打开问卷填不满意？XD
私以为这个活动的设计比较适合 MIS / OP。不知道是不是我懂的太少，觉得这些东西在分工清楚的架构下，developer 好像都不太有机会碰？

〖相关连结〗