DevOps

  • 在之前的 CI&CD 实践中,我们一直使用的是 Shell runner,简单来说,就是在一台机器上配置好所有的环境,然后序列地去执行任务。

    很明显,好处是配置非常简单,也很容易 Debug,出了问题,登录到机器上去查找即可;然而坏处就是配置迁移麻烦,也非常容易被破坏环境,而且单台机器上并发比较麻烦,好些的方法是需要配置多个机器,只是这就有些有点浪费资源了。

    因此为了更快,我们需要并行地去执行 CI&CD 任务,这就需要换种更好些的方式了。

    选择其他 Runner

    因此在剩下的几个方式中:

    • Docker:最简单,从 Shell 迁移来说,工作量不大;
    • Docker Machi
  • 一直以来,我们会在项目中,使用 APM 去监控应用的状况,分析性能等,这些工具很有效,而且不侵入业务,不需要埋点。

    然而,有些需求,是 APM 的监控满足不了的,比如应用业务指标

    监控模式

    目前,采集指标有两种方式,一种是『推』,另一种就是『拉』:

    推的代表有 ElasticSearch,InfluxDB,OpenTSDB 等,需要你从程序中将指标使用 TCP,UDP 等方式推送至相关监控应用,只是使用 TCP 的话,一旦监控应用挂掉或存在瓶颈,容易对应用本身产生影响,而使用 UDP 的话,虽然不用担心监控应用,但是容易丢数据。

    拉的代表,主要代表就是 Prometheus,让我们不用担心

  • 不知道,你有没有遇到类似的情况:

    • 不重视测试,开发新功能都是手工测试
    • 每次开发新功能,都会懒得去做回归测试,线上经常出问题
    • 新同事来,不熟悉系统,提交的代码会把系统搞坏
    • 测试覆盖率一直非常低

    这时候,你需要个CI,也就是持续集成。

    我理想中的团队开发流程中,CI是最重要的一环,团队成员按照git flow开发,然后提交,等待CI测试通过,最后提交pull request,让同事Code Review。

    在以后,还可以加入CD,即当提交到master通过之后,构建并打包docker,部署到正式环境。

    好处:

    • 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  • 自从 上次 介绍了 Prometheus 之后,就想到要在 k8s 中使用了,不过,在这之前,先介绍下 k8s 的监控。

    k8s 的监控

    k8s 默认以及推荐的监控体系是它自己的一套东西:Heapster + cAdvisor + Influxdb + Grafana,具体可以看 这里 。

    包括 k8s 自身的 HPA (Horizontal Pod Autoscaler),默认从 Heapster 中获取数据进行自动伸缩。(顺便提一句,当你部署完 k8s 集群之后,如果从 Dashboard 中看不到监控数据,往往就是因为你没有部署 Heapster,或者网络层有问题, Dashboard

  • 自从 上次 简单提到应用配置管理的几种方式以来,我都在尝试不同的方式,到目前为止,仍觉得剥离单独管理加上动态配置服务器的方式最好用,接下来谈谈原因以及具体实践。

    原因

    记录变更与审计

    其实这个涉及到 CD,即持续交付的范畴,为了保证线上应用环境的稳定性,如果配置无法追踪的话,即意味着你不能在出问题的时候,快速定位原因,处理问题。

    因此,放到 CVS 系统中就可以非常方便审计,在更新提交历史中查找即可。

    自动化

    与 CD 配合,即你可以提交到 CVS 系统后,采用 CD 方式直接将各个不同环境中的配置更新。

    简单,直观,简洁

    在 CVS 中,可以直接看到修改的内容,同事也能知道你修改过什么。