年底了，惯例做个小回顾，对这一年做个总结，也对下一年大致做个规划。 不过今儿与往年不同的是昨晚突然发高烧，今儿都没能去上班，感谢我的小可爱在照顾我。这篇文章也是躺在床上用手机编辑的。 还是按照惯例从工作，生活两方面来说。先聊聊工作。 工作 现在在网易有道负责 DevOPS 实践落地及 k8s 容器化平台和自动化平台的规划建设等。 总体来说，现在的工作很开心，更能发挥我的所长，也遇到了不错的团队。 说到现在负责的工作，如果大致有些了解的就会知道这个过程比较漫长，推进起来也会有各种阻力。毕竟要改变很多人的思想和习惯，我也在尽量让这一过程变的更加平滑。 同时也在 push 一些理念到行业内，到社区中，不断的进行交流碰撞总结。 社区贡献 今年下半年的贡献和分享相比去年更多一些。主要的分享有: GITC - 《云原生时代下的 CI/CD 实践》 PyCon China - 《基于 Docker 的 CI/CD 实践》 DockerOne 社区 - 《基于 GitLab 的 CI 实践》 Tech Talk Time - 《Docker 实战和基础架构》 分享的主题基本都围绕在容器化和 CI/CD 方面，但每次分享内容却都不一样。 感谢我的小可爱，也感谢所有支持的朋友们。 社区中主要活跃在 Docker 和 Kubernetes 生态方向。维护一些官方镜像，做测试，解决问题，提交代码之类的，明年希望做的更多。 开了一个知乎专栏 『k8s生态』 明年会花更多时间进行建设。 写了一本掘金小册《Kubernetes 从上手到实践》。 其实这个名字并不能很好的概括小册里面的内容，其中也有源码分析之类的。要再次感谢小可爱，感谢编辑 Linmi ，感谢马达老板和何世友老板写的推荐语。也感谢所有人的支持，希望这本小册能对大家有所帮助。 写小册的过程其实也蛮辛苦的，一般要么晚上写，写到凌晨 2~3 点，要么早上 5~6 点钟左右起床，写到去上班。尤其要感谢小可爱，给了我很多支持。

时间飞逝，转眼已经到了圣诞节，今年又要结束了。感谢还在关注的小伙伴，今年确实更新很少，能不取关的都是真爱… 今年发生了很多事情，留着过几天年终总结的时候再说。有很大一部分的休息时间都用来完成了我的第一本掘金小册 《Kubernetes 从上手到实践》 小册已经正式上线，特意送上各位小伙伴一份礼物，小册 8 折优惠。直接扫码 或者点击此链接即可。 以下是关于小册的一些介绍： 随着容器化及微服务等概念的普及，各个公司都在围绕着如何打造生产环境可用的，高效的容器调度平台，应用快速部署，扩容等平台进行探索。Kubernetes 是 Google 在 2014 年基于其多年在 Borg 系统实践总结出的经验而开源出的一套标准化，可扩展的系统。 而发展至现在（2018年）Kubernetes 已经基本成为了容器编排领域事实上的标准，并且大量的公司都已在生产中使用，无论是国外的 Google， Amazon, GitHub 等，还是国内的阿里，腾讯，京东，滴滴及其他中小公司都在进行着大量的探索及实践。 之前在容器化尚未大量推进的时候，开发工程师只需要关注自己业务代码的实现，而运维工程师在反复的为部署，扩容所需的环境而费时费力。 为了解决环境一致性的问题，也为了能够提高资源的利用率，容器化开始逐步推进，开发工程师的交付由原先的交付代码变成了交付镜像，运维工程师可以将精力集中于保障服务的可高用上。 但为了能够快速的发版验证功能，不再受单体化架构的拖累，微服务的概念也在实践中逐步推进，从原先的单体集中式的服务，拆分为多个松耦合的微服务。到了这时，微服务 + 容器化已经大势所趋，生产中要大量使用，则容器编排变的愈发重要。Kubernetes 在容器编排领域目前已成为事实上的标准，大量公司均已在生产中推进，此时，无论是开发工程师还是运维工程师，皆需要了解并掌握 Kubernetes 的基础技能，才不至于丢失自己的竞争力。 Kubernetes 所涉及的知识点很多, 并且版本迭代也很快，本小册将集中于 Kubernetes 的基础技能，以最常见 Case 入手，帮助大家更快的掌握相关知识并将其用于生产实践中。同时在此过程中，也会深入至 Kubernetes 必要的原理中，同时也会提供相关涉及到的 Docker 及 Linux 内核知识的补充，以便让大家不仅知其然，而且知其所以然。 你会学到什么？ Kubernetes 基础架构 Kubernetes 的基础技能, 覆盖常见 Case 从零搭建 Kubernetes 集群 与 Kubernetes 相关的 Docker 和 Linux 内核知识补充 深入 Kubernetes 组件的原理和源码解析 了解 Kubernetes 进阶相关知识体系 适宜人群 了解 Docker，希望能进入 K8S 领域的各领域工程师； 正在或即将在生产环境使用 K8S 的后端工程师； 需要维护或在公司落地 K8S 的运维工程师； 想要走在技术前沿的前端/后端/运维工程师； 准备查缺补漏的容器相关开发工程师；

如果你在用 Docker 或者 Kubernetes 想必你对 容器运行时 这个概念应该不会太陌生。 在 Docker 中，当你使用 docker info 即可查看当前所使用的 runtime。 ➜ ~ docker info ... Server Version: 18.06.1-ce Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs ... Swarm: inactive Runtimes: nvidia runc Default Runtime: runc Init Binary: docker-init containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e runc version: 69663f0bd4b60df09991c08812a60108003fa340 init version: fec3683 Security Options: seccomp Profile: default ... 同时，你还可以自己在 /etc/docker/daemon.

使用 Docker 时，最常用的命令无非是 docker container 和 docker image 相关的子命令，当然最初没有管理类命令（或者说分组）的时候，最常使用的命令也无非是 docker run docker commit docker build 和 docker images 这些。 今天来聊一下和 Docker 中核心概念 image 相关的重要命令， docker build 或者说 docker image build 为了简便起见，下文的命令全部使用 docker build 。 Docker Image 先简单介绍下 Docker Image， 通常情况下我们将其称之为镜像，镜像是由多个层组成的文件，这些层用于在容器内执行代码（命令）等。每个镜像基本上都是根据应用程序完整的可执行版本进行构建的，并且需要注意的是，它会依赖于主机的系统内核。当用户在运行镜像时，这将会创建一个或者多个容器实例。 Dockerd Dockerd 是 Docker 的服务端，默认情况下提供 Unix Domain Socket 连接，当然也可以监听某个端口，用于对外提供服务。 所以有时候，我们也可以使用服务器上的 Docker daemon 来提供服务，以加快构建速度及解决一些网络问题之类的。 好的，基础概念了解了， 那我们开始进入正题。 使用 Dockerfile 我们知道构建镜像的方法有多种，本文中我们只介绍使用 Dockerfile 通过 docker build 的方式构建镜像。 为了简便，我们以一个简单的 Dockerfile 开始。构建一个容器内使用的 kubectl 工具 (当然选择它的原因在于 kubectl 足够大，并不考虑可用性，这个稍后解释)

继上次分享后，有读者留言问 dind 使用 insecure-registry 相关的问题。 请教个问题，基于gitlab CI做java项目持续集成，用到了docker in docker， docker build使用的Dockerfile中使用了一个insecure registry，在dind的容器中如何配置insecure registry 我的回复是： 首先, 不推荐使用 insecure registry 毕竟有其固有限制， 如果一定要用的话， 其实在 services 层配置一个 command 就可以，这也是最简单的， 例如： services: - name: docker:dind command: ["--insecure-registry=myregistry:5000"] 由于留言字数的限制，就单独写个小文来回复下。 这个做法实际效果如下： (Tao) ➜ kubernetes git:(master) ✗ sudo docker run -d --privileged --name dind docker:dind --insecure-registry="myregistry:5000" 8fb68865638ebc65255bb568fbe1fd6b4ed4fca771075d8e55ebbbbdf0aef6d2 (Tao) ➜ kubernetes git:(master) ✗ sudo docker top dind UID PID PPID C STIME TTY TIME CMD root 18270 18252 1 11:27 ?

上个月受 DockOne 社区邀请，做了一次 CI 实践方面的线上分享，在此记录下。 本文讲述 GitLab CI 的架构及其能力特性，分析它在 DevOps 实践中的作用。 通过分析 Docker In Docker 的技术细节，详细讲述 CI 实践以及在生产环境中的所做的优化，包括但不限于镜像仓库等，以达到数倍的性能提升。 本次分享内容以 GitLab Community Edition 11.0.4 edb037c 为例。 为何选择 GitLab CI 认识 GitLab CI 什么是 GitLab CI GitLab CI 是 GitLab 为了提升其在软件开发工程中作用，完善 DevOPS 理念所加入的 CI/CD 基础功能。可以便捷的融入软件开发环节中。通过 GitLab CI 可以定义完善的 CI/CD Pipeline。 优势 GitLab CI 是默认包含在 GitLab 中的，我们的代码使用 GitLab 进行托管，这样可以很容易的进行集成 GitLab CI 的前端界面比较美观，容易被人接受 包含实时构建日志，容易追踪 采用 C/S 的架构，可方面的进行横向扩展，性能上不会有影响 使用 YAML 进行配置，任何人都可以很方便的使用。 重点概念 Pipeline Pipeline 相当于一个构建任务，里面可以包含多个流程，如依赖安装、编译、测试、部署等。 任何提交或者 Merge Request 的合并都可以触发 Pipeline

拖了很久没有更新，抱歉啦~ 今天受邀写篇如何在 CentOS 7 上配置 Python 3 环境的文章。往常我都选择直接把我早年写的一篇文章源码编译MongoDB丢过去，让他们看其中的源码编译 Python 那一节，不过那节写的其实不太详细，而且最近被很多人催，所以还是单独写一篇好了。 当前最新的 CentOS 7.3 默认安装的是 Python 2 ，并且默认的官方 yum 源中不提供 Python 3 的安装包。有些用户想要升级使用 Python 3 但实际可能有各种各样的问题，导致出错，反观一下激进的 Fedora 社区，在23的时候，就将默认的版本修改成了 Python3 （如果我没记错的话）。 先说下我所使用的系统环境， 一个新创建的 Docker 容器。 使用 cat /etc/redhat-release 可以看到运行的是 CentOS 7.3 版本。 在纯净的 CentOS 系统上安装 Python 环境主要有两种办法。 一种是通过源码编译安装，另外一种就是安装已经打好的 RPM 包。依照个人习惯，我们先来看一下如何通过源码编译的方式安装 Python 3.6 并且配置虚拟环境。 使用源码进行编译安装 基础环境 先安装安装几个必须的包，以方便后续的操作 ➜ yum install wget gcc make ➜ # wget 用于下载源码包 ➜ # gcc 和 make 用于编译 上 Python的官网 下载源码包 ➜ wget https://www.

简介 Redis 的客户端和服务端之间采取了一种独立名为 RESP(REdis Serialization Protocol) 的协议，作者主要考虑了以下几个点： 容易实现 解析快 人类可读 注意：RESP 虽然是为 Redis 设计的，但是同样也可以用于其他 C/S 的软件。 数据类型及示例 RESP 主要可以序列化以下几种类型：整数，单行回复(简单字符串)，数组，错误信息，多行字符串。Redis 客户端向服务端发送的是一组由执行的命令组成的字符串数组，服务端根据不同的命令回复不同类型的数据，但协议的每部分都是以 “\r\n” (CRLF) 结尾的。另外 RESP 是二进制安全的，不需要处理从一个进程到另一个进程的传输，因为它使用了前缀长度进行传输。 在 RESP 中, 一些数据的类型通过它的第一个字节进行判断： 单行回复：回复的第一个字节是 “+” 错误信息：回复的第一个字节是 “-” 整形数字：回复的第一个字节是 “:” 多行字符串：回复的第一个字节是 “\$” 数组：回复的第一个字节是 “*” 单行回复 以 “+” 开头，以 “\r\n” 结尾的字符串形式。e.g. +OK\r\n 响应的客户端库，应该返回除 “+” 和 CRLF 以外的内容，例如上面的内容，则返回 “OK”. e.g. 127.0.0.1:6379> set name TaoBeier +OK\r\n # 服务端实际返回 --- OK # redis-cli 客户端显示 错误信息 错误信息和单行回复很像，不过是把 “+” 替换成了 “-“。而这两者之间真正的区别是，错误信息会被客户端视为异常，并且组成错误类型的是错误消息本身。e.

时间很快， 已经走到了 2016 的末尾， 惯例的做个小回顾。（注：这篇起笔的时间是圣诞节TAT） 年初定的目标除了没有能合理安排追番时间， 其他的都基本完成了！（话说今年追番的时间简直少的可怜QAQ） 2016 年发生了太多的事情，要回顾的事情很多，索性就不写那么多了, 只按时间序稍微列几件有趣的事情。 单表亿级数据量的 MongoDB 做在线实时的数据拆分 在之前做的一些应用性能分析的方案上做了一些额外的设计和开发（明年修改下开源出来） PyCon China 2016 一些预期的计划顺利推进、落地，产出了一些系统 看了很多源码，折腾了很多东西，如果以后有空就写点东西出来（我又在给自己挖坑了） 认识了很多有趣的小伙伴~ 全年的状态基本和上面的截图是一致的， 全年都在 coding （截图仅限 GitHub上的记录）倒也比较开心， 另外就是现在看到自己项目的 star/fork 数，文章的阅读/收藏/转发数之类的，也已经不像以前看到 star 数刚上百时候会有那种喜悦了，大概这也是另一种成熟？ 哈哈哈 另外写一下今年对我比较重要的几个数字： 1354 376 105 对这些数字的解释, 放在以后吧 :-) 2017 年，希望想做的事情都能基本完成，挖的坑慢慢填。 感谢一路上陪我走过的各位！ 可以通过下面二维码订阅我的文章公众号【MoeLove】

注：本篇不是入门教程，入门请直接查看官方文档。本篇的主要目标是通过实际问题来介绍 webpack 中容易被人忽略的细节, 以及源码分析(以最新发布的 release 版本1.14.0的源码为例), 并且提供几种解决方案。 随着前端技术的火热发展，工程化，模块化和组件化的思想已逐步成为主流，与之相应的，就需要有一整套工具流可以支撑起它。 现在比较热门的前端资源模块化管理和打包工具应该非 Webpack 莫属了。 Webpack 是什么 它可以将许多松散的模块按照依赖和规则打包成符合生产环境部署的前端资源。还可以将按需加载的模块进行代码分隔，等到实际需要的时候再异步加载。通过 loader 的转换，任何形式的资源都可以视作模块，比如 CommonJs 模块、 AMD 模块、 ES6 模块、CSS、图片、 JSON、Coffeescript、 LESS 等。 –引自 Webpack 中文指南 使用举例 我们来看一下官方文档中的最小用例，新建并写入以下内容到这两个文件： cats.js var cats = ['dave', 'henry', 'martha']; module.exports = cats; app.js (Entry Point) cats = require('./cats.js'); console.log(cats); 这个时候，就可以使用 webpack 进行打包了： webpack ./app.js app.bundle.js 我们来看一下发生了什么， 目录下生成了一个打包后的文件 app.bundle.js ，这就是最基础的打包过程。 提出问题 如何判断打包是否成功？ 通用方案 下面是我们常用的两种判断任务是否执行成功的方案 通过 return code 通过命令执行后的 return code 来判断（在 shell 中使用 $?