跳至主要内容

开篇不谈无线路由,先从DevOps聊起

一个玩路由器玩 NAS 的,第一篇不讲无线路由,不讲NAS(网络附加存储),偏偏开篇讲DevOps?!搞笑呢? 

对!先搞笑,再不搞笑就太搞笑了.

讲DevOps 因为和做路由器有很大关系,早期开发时就使用 Trac平台 [1],当时我还不知道这个概念,如果早知道,就会让当时购买我路由器的用户有更好的软件体验,所以计划写个路由+NAS系列,希望朋友们了解下 RTNAS 曾经走过的路,希望自己的经验能帮助到后面的人.无奈本人文笔奇差,很多词不达意,各位看官见谅.

言归正传,
什么是 DevOps? 如下图所示:

[2]


图很清晰,Dev和QA大家都知道,单说 Operations(运维),这一项很多同学不够熟悉,是因为学校不教什么Linux,并且大部分公司很少去安排程序员做运维相关事情.  这里的运维指的不单单是安装个 Linux 以及 Tomcat 等服务,而是能融会贯通整个业务环境,知晓如何 CI ( 持续集成)以及 CD (持续部署).


回想2011年,做DDNAS(无线路由器项目名称)时使用一款叫 Trac 的开源项目管理工具,只用到 Wiki 和 Issue(ticket)管理 以及结合 svn 做代码浏览,开发过程就是提交代码,觉得应该测试了,然后自己去编译出固件,然后人工刷机和测试下,没有实现自动化.大部分时间都是浪费在等待编译以及测试上面,苦不堪言....随着 RTNAS 队伍的扩大,这种情况更加明显...


2013,我去了上海入职了盛大旗下的魔锤网络去做无线路由,CEO黄冬(现任芒果TV CTO)嫌我手工编译代码很土鳖,于是他带领大家实现了编译自动化,测试半自动化.但由于产品没卖上量及各种原因,就没精力去实现 CI,CD了...[3]

2016年年中,我结识了几个大牛并加入了他们的团队,入职了一个纯技术团队,第一天,某大牛扔给我两本书,分别是《高效团队开发与方法》和《Docker:容器与容器云》,大牛喝着维他命水且斜着眼说:赶紧看,以后DevOps的事情就交给你了! 然后过了几天,另一大牛来教我如何使用 GitLab 以及开发注意事项...

读这两本书和接受大牛们的教育让我茅塞顿开,意识到我之前的软件项目开发知识都是土的不要不要的....(这2位大牛分别'号称'菊花厂18级和阿里 P8,另外几个大牛分别'号称'菊花厂17级、20级,不想被爆名字的,赶紧现在就用 Android 客户端打赏我几百块:-)




说说主角GitLab,这是一个功能强大的现代化软件开发平台,好用的功能都集成到这个平台中,代码管理,Issues,用户角色,Wiki,Todo,里程碑,可视化查看 CI、CD 进程...各种功能和先进的理念都在 GitLab 中存在...(你可能发现我忽略了 Git 特性:)

我们熟知的开发流程基本都如下图所示:


正常情况下,软硬件开发流程都基本是这个样子, 而DevOps不但要求开发人员编写代码,还要把 编译、测试、部署一系列流程串起来.

CI、CD 过程如下:


CI (Continuous integration):
集成就是 代码集中一处,对编译环境做统一部署,编译程序,然后测试.
持续的集成就是 CI(就是根据需要,不断的 Build、Test).

CD (continuous delivery) 
持续交付
在持续集成的基础上,能持续不断的自动化部署到生产环境上.

那么根据实际情来说CI:
开发每次提交代码并不会触发自动编译,而是根据特定情况来触发Build,比如只有从 develop分支 merge 到release分支时并且带上特定commit 描述才会 Build,然后把编译好的固件 scp 到设备上进行升级(这个过程是 CD,咦和 Web 服务不同? :),再结合测试用例进行黑盒测试得到 pass or fail的结果.

来看看 GitLab 的 CI过程(以路由器举例):

1 当开发从 develop 分支 merge 到 release 分支时触发了编译(GitLab 预先设定好了)
2 如果编译通过,会把程序 scp 到 路由器中,然后 执行刷机.
3 刷机完成会触发测试脚本进行测试.
4 完成测试报告并可以通过 Web 查看.

注:* 下图中展示的Build 机器是 Windows(当然也可以 linux或者 Mac OS) ,需要用安装一个 GitLab-runner 服务在 Windows 上.
下图示例不包含 scp 、自动刷机部分以及测试环境部署.

Build 触发:

编写 CI 文本:

编译过的任务在下图中有显示:
点进去可以看到编译过程:

测试用例报表:
'曾经,我开玩笑的对编写测试用例的同事说:测试工作就是喝咖啡看报表啊~答:喝咖啡前要吐血到死...'
[4]

以上路由器的例子是比较粗的,虽然没有数据库构建和数据加载、环境配置文件这种偏向 Web 服务的展示,更没有出现Docker 这种部署神器(实际上 GitLab-runner 有 Docker模式) 但是依然能体会到 CI、CD 的魅力: 让我们更加集中精力的去完善产品,比如写测试用例和修复 bug,而不是傻傻的等待编译信息刷屏..(编译 Android 的同学应该更深有体会吧..)


在逼呼上,有人说个人项目没必要搞 CI:

不完全同意,就是因为一个人精力实在是有限,所以只有通过自动化才能省心省力,就是通过平台写脚本而已.....而几个人的开发团队,就更要好好规划如何 CI、CD 了,几百人的?不知道,没待过这么大的团队.

DevOps方面我是一个没怎么上过战场的新手,我也不是一个程序员.只是以往的经验告诉我,曾经可以做的更好,曾经可以让队友们有更多的时间来完善产品和多陪陪家人、朋友.

这是开篇,算是挖个大坑...
坑如下:

1 2010年作为一个硬件白痴,如何做出一款无线路由器? DDNAS V1诞生历史到底有多青涩(or不堪回首)?我将诠释什么是无知者无畏 :(

2 DDNAS V2 是如何改名叫 RTNAS V2的? 为何玩无线路由器的人做了一款纯 NAS?  听说过黑群辉吗?  V1、 V2是黑 QNAP, RTNAS V3是黑群你信不信?

3 无线路由器到底有多难搞? 那么多互联网公司都折戟沉沙? 略略有话说.

4 路由器行业和 NAS 行业还有的玩吗? 

八卦信息:
(2011年期间,怎么做的路由器,做硬件期间经历了那些?软件上开发的成果那些是引以为豪的?为什么一开始叫 DDNAS,后来叫 RTNAS?一开始这个'团伙'有多少人,后来又是如何壮大的?他们是那些精英组成?后来这个团伙的 2500W 估值是什么情况?真金白银花了100多W 后,为啥 RTNAS 团队又不玩了? )

最后,自己在预览的时候发现我的订阅号叫 略略的什么路由值得买.
好吧,我会有空写写哪些无线路由器值得买....

注解和参考资料
[1] https://trac.edgewall.org/  前几年很多开源软件使用 Trac 平台
[2] https://zh.wikipedia.org/wiki/DevOps
[3] 老黄是我见过最优秀的 CTO,感谢老黄给我很多学习的机会.
[4] 路由器自动化测试用例报表.

评论

此博客中的热门博文

最强百元Wi-Fi 路由-----斐讯K2P

 最强百元级无线路由到来--斐讯K2P 先来王炸: 1 K2P闲鱼全新收购价在 100-140 2 K2P是全千兆有线,全千兆有线,全千兆有线!不要问为啥说三遍 3 SoC 是MT7621A 双核四线程 880Mhz 4 Wi-Fi 是单芯片MT7615DN,支持MU-MIMO特性,支持Beamforming 5 外置PA和LNA提升信号覆盖范围 6 众多第三方固件,实用性爆棚 以上六点,咱们一条一条解说。 没有对比,就没有伤害: 1 售价:小米3G,同样硬件的小米3G售价249。号称性价比、发烧的硬件都比这个贵100,还怎么玩? 2 看TP-LINK、FAST、水星的同售价产品,100多元的没千兆,有千兆的都200元起。百兆网口的东西我现在看都不看! 3 说实话,有比MT7621A 880Mhz 1004K核心更好的MIPS32 处理器,就是螃蟹家RTL8198C 1074Kc(8198C另外还多一颗500Mhz用来加速存储的核), 但是很难买到,比如这三款:ASUS RP-AC68U 、D-Link DIR-879、Edge-core ecw3350 。 PS:关于螃蟹 RTL8198C的故事有好几个段子,都是和原厂闲聊得来的...以后有时间再说,今天主角是MTK。 wiki数据: 1074K single core delivers a performance of 1.93 DMIPS/MHz and 3.49 Coremarks/MHz.  1004K single core delivers a performance of 1.6 DMIPS/MHz and 3.05 Coremarks/MHz.  24K core delivers a performance of 1.6 DMIPS/MHz and 3.1 Coremarks/MHz. 虽然只看 DMIPS和 Coremarks/MHz,觉得24Kc和1004Kc差不多,但是区别还是很大的,比如L2 Cache 24Kc就没有, 多线程多核也没有,而且7621A主频提升到了 880Mhz。 这些都是很大的进步。并非简单的胶水双核 :D...

用Gitlab搭建 Docker Hub Registry(不踩坑指南)

Docker大家基本都用过, Registry 就是服务,简单理解就是能让你 Docker pull 和push Image的地方。 Gitlab的 Registry 是自动化部署一个环节。计划从Gitlab的自动化集成、自动化部署,以及如何配合Kubernets(谷歌的平台简称K8s),这些属于Devops的应用。 之前写过一篇文章,感慨现在的云服务实在是太方便了:快速部署的目的是让创业公司专注自己的业务,而无需浪费人力去折腾基础服务. (原文连接:  后知后觉,云服务太方便了!  ) 那么为何不使用 Docker Hub 服务?反而要自己搭建呢? 几个原因: *  Docker Hub 访问实在是太慢,甚至是访问不了.  *  使用 Docker Hub必须开源自己的仓库, 很多用户比较敏感.(当然可以花钱购买私有仓库进行扩容) *  自己机器上数据和云服务数据同步,保证数据安全 --------------------------------------------------------- Gitlab 功能太多,我也是使用 CI 、CD 配合 Kubernetes(k8s)时候偶然发现竟然还集成了Docker Registry 的功能...这下爽了,终于不用看墙的脸色决定网速了~我自己的 Docker Hub,想怎么push、pull 都行~ --------------------------------------------------------- 我们这篇主要讲怎么 避免踩坑 , 具体服务怎么搭建回头找个机会,再整理下详细步骤. 我的环境是一台 DELL 16G 的1U 服务器,在 EXSI 6.5 上给 Ubuntu17.04 server 分配了4 Core 以及 6G内存.  只跑 Gitlab 基础 +   Registry 的服务, 和这个配套的 K8s 、Gitlab-runner 等服务在另外一个系统上跑(K8s 、CI CD、 Gitlab-runner 如何搭建以及应用,会以后讲). 以下注意几点: Registry 不支持自签(Self-...

Gitlab CI/CD 之 gitlab-runner 用 Docker 方式如何顺利工作

前阵子,k8s 是搭建起来了.但是这玩意更新太快,3个月后, 以前的方法不好使了...又有新坑了... 干脆就只跑 Docker 吧.... 我擦,Docker也跑不起来了...说 **docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.** 以前只要在 .gitlab-ci.yml 里面填写 标红的就可以了.但是现在不行,会报  Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? services:   - docker:dind variables:   DOCKER_DRIVER: overlay build:   stage: build   script:   - export DOCKER_HOST="tcp://localhost:2375" build-master:   stage: build   script:     - echo $CI_REGISTRY_PASSWORD |  docker login -u "$CI_REGISTRY_USER" $CI_REGISTRY --password-stdin     - docker build . (注意, $CI_REGISTRY 这些环境变量是要填写在 Gitlab web 环境变量中的) 研究后,要在 gitlab-run 的 文件中包含     volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"] sudo cat /etc/gitlab-runner/config.t...