無標題文檔

家里的内网开发环境(概述)

家里的开发环境越来越复杂了,所以需要复盘和回顾下目前的情况。这个得先从头开始说起:

Stage 1

Stage 1

应该说很上古的时期,和大部分开始的需求一样,需要离线跑些脚本。那时候我简单选用了台树莓派跑 NPM 的些代码。在很长的一段时期内它能很好的满足需求,因为只需要跑些爬虫和通知性质的脚本。

Stage 2

Stage 2

随着任务的增加,树莓派的性能瓶颈越发的明显,因为 NPM 的项目基本上都是些零散的小文件,tf 卡在 4k 的读取方面性能非常的弱。这时候开始考虑使用台「正儿八经」的 x86 小机子用来跑繁重的任务,技术栈这块也切换到了 Golang 以及 Python,而树莓派则退居二线作为通知和监控使用。

再后来数据量越来越「庞大」,达到了几百个 G 的级别,M93P 的硬盘容量明显不够了(SSD 256G、机械硬盘 1T)。加上对于数据安全性方面的考虑,购买了两块 2T 的硬盘以及 USB 的磁盘阵列盒子。

Stage 3

Stage 3

随着数据量的增加,我很快发现数据这块有了冷热的区别。同时,部署的环境也越来越复杂,虽然使用 Docker 搭配 docker─compose 也能很好的完成集成和部署,但在各个应用之间来回的切换 docker─compose 的目录让人感到非常的头痛和麻烦。

所以这时候在操作系统层面加上了 KVM 虚拟机这层,然后再再虚拟机上面跑 Docker。本来考虑上 K8S,但是其实各个应用之间是相对独立的关系,因此还是以单独虚拟机为单位分类各个应用的类别。

Stage 4

Stage 4

不过数据还是在不断的增加,我考虑到 USB 的磁盘阵列盒虽然能够满足目前的需求,但是横向的扩展性以及应用和数据分离做得还不够彻底,因此将数据这块单独部署了台 NAS 去处理

组装这台 NAS 其实走了很多弯路,硬件方面一开始用的是台盘位的 PC 机箱,但是很快发现非常不合适放在家里,一来机箱的体积太大了二来功耗也非常的大但是只能最多安装两到三块的硬盘。

和很多「垃圾佬」一样考虑过星际蜗牛的主机,四盘位的机箱加上 J1900 的四核低功耗的处理器,很适合用来做网络存储。但是还是考虑到数据的重要性,还是选择了单独的四盘位的机箱以及性能相对好点的 AMD 集成主板作为平台使用。

存储的选型方面一开始使用 CentOS + 阵列卡的形式,后面切换到了 FreeBSD + 直通卡配合 ZFS 的方式,各有优劣和千秋这里不展开详细的说明。

Stage 5

Stage 5

于是乎硬件和虚拟机的节点越来越多,怎么去治理和监控就成了纠结的事情了。还有因为国内网络环境的问题,所以我在网络这块考虑使用了 N1 作为旁路由和透明网关作为国际网络加速。原先的树莓派也替换为 N1 同时部署了 Grafana 以及 Prometheus 作为节点的监控和报警

服务发现这块选用了 Consul 和 DNSmasq 汇聚,这样子每个节点启动自举的时候,就可以在内网环境拿到对应的域名而不用去找 IP 地址,很方便。

Stage 6

Stage 6

基础环境搭建好了以后,逐渐的装了 Syncthing、Gitea、Drone 等用于数据同步以及测试代码的托管和 CI。由于测试数据的量逐渐的收敛了下来,所以很多时候 Runner 在空闲的状态,但随时可以调用很方便了。

硬件方面主要是有些补足的设备,例如我后面又购置了台瘦客户机装了 FreeBSD 用来实时给 macOS 做时间胶囊备份使用。

同时,买了两台 UPS 以及写了些对应的脚本,用于在断电的时候主动关机。

@TODO

@TODO

前几天从 @yff666 那边得到块星际蜗牛的「遗产」,组了台双盘位的 Raid1 小 NAS 主机,打算用来存冷数据,不过这块的数据需求还是要看目前的业务情况。

监控这块我觉得还有比较短板的地方,例如如果家里网络不通则无法收到通知邮件了,这里想考虑使用台 Android 手机配合 adb 发送短信,后面想好了再继续做吧。

- 待续 -

随忆 FreeBSD

Install FreeBSD

趁在隔离的空档期间组了台 NAS,自然而然的安装了 FreeBSD 和将数据拜托给了 ZFS。时间过得很快,回想接触这个系统已经有十几年的时间了。

初次接触 FreeBSD 还是在大学的时候,那时候自己的 MMX 166 笔记本装的还是 Slackware、实验室有台机子装的是 FreeBSD 4。由于次意外的断电,实验室的这台机器由于硬盘故障无法启动,当时作为兼职的运维只能我先去看看能不能解决。

那时候 FreeBSD 直观的印象其实很初步,就是配置方面和 Slackware 差不多,同时也体验到了 ports 的好处,就是至少不用像 Slackware 一样满世界的找 tar.gz 包了。

那时候「水云间」的 BSD 板块还是比较热闹的学术氛围浓厚,上面有各种各样的「奇迹淫巧」各种各样的 shell 脚本和配置文件。那时候的我们年轻而且还气盛,和争论 Vim、Emacs 哪个好一样,争论 GNU/Linux 和 BSD 之间孰优孰劣(现在是 Android 和 iOS 了吗?)也是个老生常谈的问题,热闹看得不亦乐乎。

再往后工作了以后就忙碌了很多,去「水云间」的日子也少了。在本世纪的头个十年,技术方面的发展非常的迅猛,「把玩」技术的时间也不会很多。我的主要系统也从 Slackware 往 Debian 上面迁移到后面买了台 Mac 就一直用 macOS 至今。

FreeBSD 的发展也是一路过来,版本从 4 一直到现在的 12,还是一路保持着 KISS(keep it simple, stupid)原则。当然FreeBSD 的「Simple」其实不是「简单」的意思,而是简洁。

安装好新的系统以及软件包以后,只需要拷贝应用的配置以及 /etc/rc.conf 还有 /boot/loader.conf 就可以直接投入使用。

开玩笑的说,这类的 BSD 系统是努力让管理员尽可能的快的遗忘掉它,因为知道使用 FreeBSD(以及 BSD 系列)的管理员,是知道拿它去做什么的。

所以这也是为什么眼看着份额却越来越低使用得人甚至讨论的人也是越来越少,而 FreeBSD 还存在的原因之一吧,哈哈。

的确 FreeBSD 从学院的背景走出来,很多地方不像 Linux 那么「分裂」以及「随意」,所以在 FreeBSD 安装盘里面有很多「年代感」的文件(所谓的传承?)。

FreeBSD 还是会时不时得给我些「小惊喜」。回到我的那台 NAS 上,我曾经需要给阵列卡加上监控和配置。LSI 厂商其实提供了 MegaRaid 等工具,在 FreeBSD 下其实官方已经提供了 mfiutil 这类的工具可以直接使用,同时参数和命令比 MegaRaid 更加的清晰。

FreeBSD 的在这个方面做得是两个极端,要么就是没有提供任何的支持,要么就是有非常完善的 Manual 以及 Handbook 说明。同理,对于 ZFS 方面的支持也是类似。除去协议方面的问题先不谈,我保守得至今还不敢在 Linux 生产环境下使用 ZFS,这已经是我的个固有的印象,而 FreeBSD 能做到开箱即用。

FreeBSD 的 slogan 现在变成了「The power to serve」。但 Linux 在应用层面 Docker 以及 K8S 等工具完全改变了传统运维的方式,这我在 FreeBSD 下是没有找到任何与之对比的杀手锏的(你问我 Jail?凑合吧…)。

在我看来,未来 FreeBSD 相对 Linux 应该更加下沉,无法让应用开发接触到了。它在底层存储、数据库、防火墙和网关还会继续占有一定的使用场景。对对,如果你说 macOS 甚至 Switch 也是 FreeBSD (或者和它有关系)的话。

FreeBSD 除了在特定场景下的优势,我个人对于 FreeBSD 的情感甚至可以说情怀,也是让我继续使用这个系统的原因。好比上面说的你十几年前的 rc.conf 不加修改扔到最新版本的 FreeBSD 还能兼容一样,当全部初始化时候出现 login 提示,这一切都给人感觉通过时间沉淀已经升华到另外一样东西了。

前几天,在之乎上看到个问题「现在使用 FreeBSD 是一种什么样的体验」、「现在学 FreeBSD 有必要吗」等等,只能轻轻的笑笑。其实,正式知道和使用 BSD 这些系统的人,基本上都是那些已经年过三十正在慢慢失去了折腾的时间和精力,或者已经在办公室里拿着保温杯泡着枸杞看着 KPI 担心脱发的那帮人了吧。

回想起如果那个下午没有意外的断电,可能就不会接触 FreeBSD 更不会有十几年的陪伴。但现在看过来,还是不后悔时间花在每次 /usr/ports 目录下等待 make install 完成屏幕暂停的时候吧。

因为,FreeBSD 以及 Slackware、Makefile、Vim… 等这些名词,毕竟是我的青春呀,笑(

- eof -

迁移到 Google Cloud Platform

Google Cloud Platform

好吧,又是个比较蛋疼的经历。后来由于发现 Azure 的香港线路非常不友好(电信),最后还是迁移到了 Google Cloud Platform,话说我真的不想再迁移了。

有国际信用卡还是方便的,根据我目前的配置 Google Cloud Platform 几乎可以实打实用一年。据说 Google Cloud Platform 的流量费用还是不便宜的,所以到时候做些必要的优化(虽然访问量其实不高)。后面的具体费用,等账单出来以后再观察。

Microsoft Azure

如果您能看到这篇博客,那么说明站点迁移到 Microsoft Azure 已经完成了。

其实并不是原先的 Linode 空间不好,而是某些不可抗力导致 Linode 日本节点在中国大陆的可用 IP 越来越少。顺便说一句,Vultr 更甚几乎可以说是全军覆没。

虽然相比 Linode,Azure 的性价比并不是很高,但是它有个「东亚」节点(其实就是香港)对于国内线路优化很好。如果不考虑性价比这块的话,Azure 其实也算是个很好的去处。

那么为什么不迁移到阿里云的香港节点呢?嗯,咱聊点别的吧…

基于「树莓派」的家庭网络服务

当初组建家庭网络的时候,就考虑到自己的需求:主要是网络存储、以及跑部分比较耗时的「定时任务」,例如爬虫和下载还有部分的数据处理等。

本来考虑部署一台性能相对比较好的服务器去处理,但这样子考虑到部署太过中心化不好管理,同时硬件的成本有些高而且占地的面积太大,因此就暂时被我搁置了。

后来想到 空帷 的朋友圈,使用「树莓派」这个方案相对比较轻量,同时多出来的「树莓派」还可以用来它用,因此考虑使用「树莓派」搭建自己的家庭网络服务。

下面是简单的网络拓扑图,同时主要说明下图中的内容:

网络拓扑图

顺便说下,基于「树莓派」我已经写好了几个 Docker 的镜像,主要是文件管理(Netatalk、Syncthing 等)。可以直接拿来部署使用,不用重复造轮子啦:

  1. https://github.com/mingcheng/raspberry-pi3-syncthing
  2. https://github.com/mingcheng/raspberry-pi3-netatalk

- 未完待续 -

再见,丁香园

已经正式从丁香园离开两个月,时间过得很快。

说起来离职的过程并不算是十分得愉快,然而两个月过去了心态也平静了很多,应该可以从初心上去写点文字回忆在丁香园的这段时期。

初心

2010 年的时候,@Fenng 来找我问有个项目你或许可以试试,这家公司的名字叫做丁香园。那时候个人个人在阿里的时候正处在转型期(瓶颈期?),所以抱着聊聊看的心态和创始人 李天天 一起吃了个吃饭。

印象很深,这顿饭吃完了以后,我自己就有感觉是应该为自己的理想和初心去实践些什么。后面的一来二回持续沟通了以后,就做下了这个决定:离开阿里去当时这个没任何名气的小公司见证团队从小到大的过程。

我当时在博客里说明了我离开阿里的想法,私底下很多朋友和同事很不解我的决定。毕竟,在阿里(淘宝)四年的时间不算短,无论个人发展方面还是待遇方面,当时的丁香园是没有任何优势的。

然而,时至今日我还是坚持我这个决定,并不后悔。

技术

在淘宝做了四年的前端,来到丁香园的时候整个公司的技术团队不足十人。技术方面,由于丁香园在前端方面是没有任何的框架以及代码规范可言,业务的高速发展对于优化和重构这块是势在必行的。

现在回过头来想,开始我可能过于理想化以及出于技术方面的思维惯性(说白了就是没经验),还是沿用了淘宝的技术架构。

在前端框架的选型上,使用了淘宝前端团队自己编写的 KISSY,这个后来是个大坑。KISSY 无论在框架的接受程度上还是可维护性、扩展性方面,相比当时业内的通用知名框架没有任何的优势可言。

甚至在一段时间内,我还在和团队的其他前端逐个在说明 KISSY 框架如何使用,乃至至一段时间内都影响到了业务的发展。

悬崖勒马,经过考虑团队还是重新选择到了 jQuery 框架。好在当时的业务高速发展,冗余代码迅速被迭代才没有被后来的绝大多数前端们发现竟然还有这段黑历史 :^)

然而由此带来的影响,再后来 node.js 等推出和成熟,在技术方面的由于前一次的“吃亏”,团队并没有坚持选择非常新的技术。

PHP 作为前端和后台的“粘合剂”,在丁香园的服务器中存在了很久一段时间(至今历史代码还在)。

疲于应付业务和需求技术方面在很长的一段时期是没有任何的规范可言,这可能是小团队的通病。

客户端的兴起,业务驱动个人逐渐技术方面转向了客户端这边。因此,比较遗憾的是前端这边并没有推动太多新的技术和流程,然后又要去挖移动端这个“坑”。

在丁香园的六年多,可以说有 70% 的时间都给了移动端这边:团队、技术、架构、甚至采购。这一切的内容对于我而言都是从零开始,而我也是乐在其中。

期间产品两个 iOS 和 Android 平台的版本分别获得了 App Store 以及豌豆荚的推荐和奖励,这在我个人职业生涯中也是莫大的鼓舞很肯定。

产品的迭代用户数量的攀升,带来了团队的壮大以及需求的不断增长,移动团队在公司十分被重视,各种资源都能够得到满足,有段时间内移动端团队相对于其他技术团队独立,这是好事也是坏事就不详细说。

说回到了技术方面,由于没有 QA 团队,所以在质量保证方面产品团员、开发、甚至运营都需要承担一部分的测试和质量保证工作。

“吃自己的狗粮”

这是团队的传统也是为什么不设 QA 这个职位的初衷。现在看来,这个话题还是颇有争议的,或许可以单独开一篇文章去讨论的。

业务的洗礼、QA 角色的“平均”,所以丁香园在技术方面的选型以及步进是偏向于保守的。

不过期间也做出过尝试,令人感到自豪和欣慰的是 iOS 端(2015年)开始逐渐的迁移到 Swift2,在一段时间内由于这块新技术调整造成产品迭代缓慢,产品和需求方都表示理解。

再后面,Android 也想考虑尝试下例如 Kotlin 等技术,比较遗憾我无法参与其中了,这是后话。

业务

写了一半,可能会招惹非议,略过吧。

团队

回到团队本身,如果说总分有十分,我完全毫无保留得给我们的团队打分九分,留一分让我剩下用岁月慢慢给到你们。

我爱这个团队,我爱团队的每个成员,我爱你们。

很多人崇尚的扁平化、足够的自由度,以及“漠视 KPI”,等看起来很美好的关键词,都或许在这个团队都得以实现。

同时,管理层面的 Sense 就是十分关注组员的成长,无论是技术还是个人方面。团队的信息透明也是我所推崇的,所有的信息都不会被二次咀嚼以后,再分别给到团队分别不同的人。

技术方面,能够给予足够的自由度以及尽可能的尝试,这里回过头来思考可能会抛出好几个问题。例如,如何保证团队的自我驱动能力?新技术的尝试如何保证项目本身的质量和进度?等等。

这些我问题坦白讲,我至今也在继续摸索和求证。

很是感谢在丁香园的几年,在管理方面的很多想法都能得到实践以及总结,团队从小到大的过程并不是所有管理者所能亲身经历。

Fenng 曾经和我说或许如果当时留在阿里待遇方面可能会更加可观,我可以很如实的回答,丁香园给予我的这些经历可能留在阿里这些年都无法换回,感谢这六年。

--

2016 年丁香园发生了些不愉快的事情,管理层的变更、团队的调动以及后续管理者的价值观、技术均无法认同,这是我离开团队的根本原因。

从丁香园离职了以后,我也有过抱着巨大的怨念去回忆以及诉说我的离职过程,现在回过头来想其实十分没必要以及幼稚。然而时至今日,还能听到很多或许有关于我以及团队的刺耳言论,个人有时还是无法控制自己的情感。

爱的深,可能就会更在乎它的每个细节。我现在已经可以自我调节和理智面对,对于那些信息的源头的始作俑者,我只想对你们说,你们是永远都不会 GET 和理解我对这个团队的情感以及初心。它对于我而言不仅仅是我一份工作的证明,怎么可能去伤害。

夏虫不可语冰

再见丁香园,曾经和现在都爱过的。

-- EOF --

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQGdyYWNlY29kZS5jb20K | base64 -d`

分类

搜索

文章