阅读 2165

一个非典型创业公司的DevOps架构

djwong.net/2018/03/14/…

简介

首先, 我们所有的服务都搭在阿里云VPC内网, 没绑公网IP. 所有人需先通过VPN连接到内网, 具体可以看 <记一次公司阿里云内网搭建>

我们的主要技术Stack是Node.js(TypeScript), Go, MySQL, Redis 和 etcd. Node.js做网关, Go来做微服务, Redis主要是用来做缓存和存放session之类的数据, 然后etcd用来做服务发现.

Docker

所有的服务都放在Docker容器里.

Docker容器管理我们用的是Rancher, 一个支持多种架构和网络的管理方案, 其中包括Swarm, k8s和rancher自己的cattle.

我们选用了cattle架构, 毕竟是人家自己的, 兼容性会更好一点.

网络方面选的是默认的IPSec, 每个容器会被从一个单独的网段分配ip, 比较适合不同的场景, 虽然性能上会有大概30%-50%的损失, 但是综合考量下来, 还是能承担的起(相比于其他方案所带来的运维复杂, 以及学习的时间成本).

代码管理

代码肯定都是放在gitlab上的.

我们的代码管理方案是最新的代码是在master上, 每次发布会打一个tag出来.

所有人都没有推master的权限, 必须通过Merge Request来提交代码, 此时通过webhook触发Jenkins跑测试. 这时通过钉钉GitLab Bot来通知到开发群里来提醒code review.

当所有的讨论被resolve之后(并且测试通过), 代码才会被mergemaster

每次Merge Request尽量保持minimum features, 这样方便大家code review, 并且不会太累.

其实code review是一个每家公司/团队都应该养成的好习惯. 一是可以提早揪出错误, 当局者迷, 旁观者清. 二是大家都能熟悉彼此的代码, 当自己更改的代码导致别人的部分需要变动/升级时, 便可一并改掉.

发布

发布反而是最简单的

每次打完release tag(发布生产)或mergemaster后(测试开发环境), webhook触发Jenkins构建, 然后发布到Docker Registry. 最后用到Jenkins Notification的插件来通知构建结果到钉钉群和其他各种方式. 如果构建成功, 则调用RancherWebhook来更新容器.

因为每次Docker Image都是打了tag, 所以有问题回滚, 只需上Rancher更新下容器版本即可.

Debug

用工具来减轻负担

我们来假设一个bug场景, 来看看各个环境的工具, 以及如何使用.

  1. 收到一个Sentry的邮件通知, 大量用户注册的时候报服务器错误
  2. 上到 Sentry看到用户调用注册接口的时候, API返回500服务器错误.
  3. 选取一次错误的请求会话, 看到API请求响应Headers中的tracing id
  4. 上到Kibana, 按tracing id搜索此次请求, 发现日志中有一个报错, 但不清楚是哪来的.
  5. 上到zipkin, 找到此次请求链, 发现是其中注册服务调用邮件服务时报了错.
  6. 根据报错的stack来修复错误.

Misc

其实IM想用Rocket的, CEO不给批服务器, :(

  1. Rocket这个东西还是很好的, 开源版的Slack, 在可扩展性和bot方面, 目前还是吊打钉钉的.
  2. Gitlab有条件可以上Enterprise Edition, 功能更强大. 例如可以强制Merge Request必须有2个approval才能merge进去, 适合公司人变多了之后, 作为一个强制性约束, 而不是靠人为的去约定.
  3. Artifactory是个很强大的仓库, 支持市面上所有主流的包管理工具, npm, docker registry, gem, maven, 等等. 可以用一个平台, 一个账号来完成所有的包的管理.
  4. 任务管理可以放在JIRA上, 配置比较麻烦一点, 收费贵, 但是好用. 或者可以使用monorepo, 直接用Gitlab自带的issues, milestones 等来做任务和版本的追踪, 也可以很方便的实现sprint

招人

其实我们是一家做教育游戏的公司

如果你

  • 有过Flash游戏开发经历
  • 使用Egret/白鹭至少完成过一个项目/作品
  • 喜欢挑战新技术

请直接私信我, 或者邮件到joesonw艾特funlearnworld.com

感谢阅读

关注下面的标签,发现更多相似文章
评论