标签：
1. Docker持续部署图文详解
要点: 本文演示了如果基于 docker 实现持续部署的过程. 主要最新的代码提交到 git, 自动会部署到线上, 这一切不是多数工程师一直向往的吗? 当然 demo 很简单, 真正用到线上还有很多工作, 比如自动化测试和分级发布等等, 不管怎么说, 文章提供了一种思路, 让我们从docker 的视角看待问题, 我人为这也是 docker 最最核心的竞争力所在.
2. Google宣布成立CNCF基金会，Kubernetes 1.0正式发布
要点: kubernetes 终于发布了1.0版本了, 意味着 kubernetes 宣称可以支持生产环境了, 不过 kubernetes发展太快了, 邮件组中每天有数千封邮件讨论 kubernetes 的相关问题, 要想用的化, 还是需要等功能逐渐稳定了之后吧.
3. 剖析Docker文件系统：Aufs与Devicemapper
http://www.infoq.com/cn/articles/analysis-of-docker-file-system-aufs-and-devicemapper
要点: 这不是一篇新文章, 如果稍微了解 docker 的话, 相信大家对 docker 依赖的 cgroup 和 namespace 技术比较容易理解, 但是cgroup 和 namespace 技术在比较早的 linux 内核版本中其实已经支持的比较好了, 为什么 docker 还要依赖比较高(linux 3.8以上)的 linux 内核版本呢? 主要是因为 docker 的分层特性. 为了减少存储空间, docker 镜像采用层次化结构, 高层次镜像可以共享低层镜像的文件, 同时要支持容器之间隔离, 容器中进程的文件写入不能被其他容器看到. 为了实现这个目标, docker 依赖于特殊文件系统的特性. 目前Docker支持Aufs，Devicemapper，Btrfs和Vfs四种文件系统, 这篇文章就是帮助我们理解 docker 是如何依赖 aufs 和 devicemapper 的. 但是这些文件系统都依赖相对高版本的 linux 内核, 其实我觉得在一定的限制条件下, 通过 mount 系统调用, 把依赖的底层镜像文件 mount 到高层镜像中, 也可以实现类似的功能, 摆脱这些文件系统对高版本内核的要求.
4. 深入理解docker ulimit
http://weibo.com/p/1001603867707551442110
要点: 文章中遇到的问题主要是与系统的启动顺序有关, 相信大家对 ulimit 都不陌生了, 但是如何正确的让 ulimt 生效并且理解其中的原理特别是针对 docker 中的镜像? 这篇文件就是非常好的选择.
1. 服务发现：六问四专家
要点: 服务发现系统是实现服务化的核心组件之一, 这篇文章介绍了4位云计算专家回答关于服务发现的技术和选型的问题.
2. 春晚微信红包，是怎么扛住一百亿次请求的？
要点: 文章介绍了春晚微信发红包的后台架构设计演化过程, 面临春晚这样的重大事件, 确保服务稳定高效的处理海量用户的爆发请求, 需要高技术含量的架构来支持.
3. SAMI：来自三星的基于Docker和Mesos的容器解决方案
要点: 这篇文章介绍了 SAMI 基于 mesos 和 docker 搭建的持续集成+持续部署的解决方案, 所有工作配置都存放在Git中, 把应用软件打包成Docker镜像，便于快速部署. 在配置管理方面, 大搜索也采用类似的机制, 所有配置文件都写入 svn, 但是带来的一个问题是不同的机房或者不同的环境, 对应的配置可能是不一样的, 所以我们目前采用的是模板机制, 服务部署时, 按照当前环境和模板生成对应的配置文件. 但是这也就带来了模块和环境的维护成本, 由于全靠人工维护, 也比较容易出错(比如新增了一个物理机房), 还没有想到更好的解决方法, 不知道 SAMI 是怎么解决这个问题的, 文章没有提.
4. 微服务架构成功之路
http://www.infoq.com/cn/news/2015/07/success-of-microservices#rd
要点: 前两期也分享过微服务相关的文章, 我觉得这篇文章写的比较有深意, 是否微服务不关键, 关键是"这些小型、跨职能的微服务团队看起来像是小型开源项目一样。大家一起工作，不怕与别人分享自己的观点；每个人都热衷于构建高质量软件，由于团队规模足够小并且聚焦，因此可以构建出模块化软件。他们是开发者、测试、运维，一切工作都有着相同的目标，而这正是DevOps与微服务的真谛之所在。"
1. Uber容错设计与多机房容灾方案
http://weibo.com/p/1001643867507730568365
要点: 本文介绍了 uber 在容灾方面的技术, 基本上也是单点故障容灾, 单个交换机容灾, 单个机房容灾这样来考虑的, 容灾一方面要快速服务故障, 另一方面要保证遇到灾难时能够有效的降级, 防止过载进而产生雪崩效益, 也就是 fail fast 的策略.
1. 从DO分离走向DO合作
要点: 文章中列举了很多导致研发和运维分裂的因素, 其实很多因素我们或多或少的也遇到过. 术业有专攻, 要想实现1+1>2, 就要拥抱彼此，互相合作，因为衡量我们标准只有一个，“用户说好，那才是真的好”，其他的还真的都是在扯淡。
2. 腾讯游戏运维服务建设之“版本服务”
要点: 本文介绍了腾讯游戏部门在新版本发布前后需要关注的内容, 运维人员不仅在版本发布后关注程序运行的状态和效果, 在开发过程中就会关注软件的质量和缺陷了, 并且推动开发人员去改善.
3. 现代告警平台的设计是模块化的
http://segmentfault.com/a/1190000003012335
要点: 面对众多的开源收集和监控平台, 比如 ELK, Nagios，Zabbix等等, 作者认为很多开源平台都在追求大而全, 实际上我们更需要的是一对小二精的组件拼装成一个个性化的解决方案. 文章中包含了作者演讲的视频. 我也比较赞同作者的观点, 毕竟在 IAAS 层, 不同公司面临的硬件和基础环境差异比较大, 一套"大而全"的系统往往不能解决全部问题, 而且为了使用这套"大而全"的系统还不得不同时运行多套小系统来满足差异化需求.
4. 运维的本质—可视化
要点: 没有比“可视化”更好的一个词能概括运维的本质，而“可视化”又应该分成两部分：可视化的服务交付和可视化的服务度量! 我们做架构的同学往往对可视化不是很重视, 认为这是锦上添花的东西, 有更好, 没有也无所谓. 但是从上半年 beehive 开始建设 dashboard 的过程中发现, 可视化是实现运维自动化的利器. 没有可视化, 就无法谈及运维自动化, 一方面因为自动化运维策略的制定来源于可视化的数据分析, 另一方面没有可视化的自动化运维, 我们也不敢使用, 因为看不到当前状态, 谁知道是正常还是异常呢.
1. YouCompleteMe
要点: ycm 应该是目前为止 vim 里最好用的自动补全插件了, 基于 llvm 通过实时编译来实现 c++程序的语义解析. 遗憾的是, 目前在 gcc 3.4.5上无法编译 llvm, 而且 llvm 发布的 prebuild 包里也没有 redhat 的版本, 需要自行编译. 如果大家使用 gcc 4.8.2 可以用一下试试.
2. 最佳日志实践
要点: 又是一篇关于日志的文章, 每次线上追查问题, 都被大量无效的日志折磨着, 所以每次看到写关于日志的文章, 都忍不住想转一下. 如何输出日志, 输出哪些内容, 都是非常有讲究的, 这些日志将成为我们日后追查问题的利器, 如果组织的不好, 就会给我们定位问题带来很大的阻碍. 除了日志内容之外, 选一个功能灵活, 性能优异的日志库也是非常重要的, 我期望的日志库具备的功能有: 日志文件按照时间和大小两个维度进行切割; 所有日志文件的 size 有一个 quota 可以限制, 超出之后自动删除最旧的文件; 日志的配置可以在运行时修改而不需要重启服务; 不同级别的日志输出到同一个文件里; 日志的输出具有异步的语义, 不会因为磁盘故障而阻塞服务(特别是对于无状态的服务). 目前看来似乎只有 log4cplus 满足我的需求.
3. 像 shell 的-x 参数一样追踪 python 的执行过程
要点: python 虽然比 shell 强大的多, 但是调试起来不太方便, 尤其是很多情况下只有运行起来之后才会发现错误. 使用 python 的 trace 模块可以让 python 像 shell 的-x 参数一样打印脚本执行过程, 方便调试
4. 15个对开发人员有用的Chrome扩展插件
http://info.9iphp.com/15-chrome-extensions-for-developers/
要点: 一些常用的 chrome 插件, 即使不做 web 开发, 像 JSONView 这样的插件也非常有帮助.
标签：
原文地址：http://www.cnblogs.com/zhengran/p/4676323.html
