查看原文

Minikube 可以在单机一键搭建整个 Kubernetes 环境，相当方便。

• brew cask install minikube
• minikube start
• minikube stop

在 start / stop 中间可以用 kubectl 自由的玩耍。

查看原文

使用 Travis CI 可以自动在推送数据到 GitHub 仓库后构建整个静态网站。这个技巧对于自动化很有帮助。具体的做法是在 .travis.yml 中至少运行如下命令：

git push -fq https://${GH_TOKEN}@github.com/$(TRAVIS_REPO_SLUG).git gh-pages > /dev/null

同时，要么在 .travis.yml 中，要么在 Travis CI 网站 Settings 里面，配置 GH_TOKEN，记得将其设为 encrypted.

这样每当 master 有代码推送，Travis CI 就能自动构建，并将构建好的东西推回 gh-pages 分支，进而触发 GitHub …

查看原文

miniast 是一款可以生成 Python AST 的库。在它提供的示例中，可以看到一个等价的 Python 类被转化为被 miniast 提供的几个标记可以表示出来的 Python 代码。miniast 的实例可以用 miniast.sourcify 将其转为 Python 字符串。

衍生思考：这个类很大的意义在于安全地生成代码。由于缺失像 Lisp 的 Macro 一样的东西，一般在做 Python 元编程的时候，我们需要手动拼装 Python 字符串，再使用 eval 来执行。这里面存在被注入攻击的风险。使用像 miniast 这样的工具，可以降低被注入攻击的风险。

查看原文

本文介绍了如何为 Python Apps 写 Dcokerfile，并应用这个文件构建适用于不同 Stage 的镜像。

• 开发环境使用 debian 作为 base image, 生产环境使用 alpine 作为 base image
• Gunicorn 在 dev 模式中开启 hot reloading
• 静态资源经过 bundle 以后，使用 flask static / template folders 提供
• 使用 multi-stage alpine build 减小最终部署到生产环境的镜像大小

一些 Tricks：

• Dockerfile 中 COPY src /app, 运行的时候，在 dev mode …

查看原文

Steve Yegge 认为：Kubernetes 就是 Google 内部的 Borg 系统的简化版，但它也强迫你学习各种概念，相比 Amazon Fargate 或者 HashiCorp Nomad，k8s 的设计有点过度工程化。它还认为 container orchestration 的最优解决方案不一定会是 k8s。

查看原文

本文真正的 Title 是“我为什么要关心 Kubernetes, Docker 和容器编排？”。理由是它让我们 once for all 的做了以下这些事情：

• OS 版本，编程语言的版本及其依赖。
• 代码打包，代码的依赖，以及可能的补丁。
• 简单地运维，扩容（docker run / kubectl apply xyz.yml)
• Dockerfile 声明了应用所需要的东西，K8S YAML 生命了端口，replica 数量，名字，环境变量等等。

查看原文

本文介绍了 StashAway 这家公司如何使用 k8s 及其工具链搭生产环境。

• Service Discovery。由于节点创建和销毁很容易，每个容器配置的是动态 IP 地址，所以每个容器都需要被注册，这样其它容器才能访问到它。Kubernetes 提供的两种 SD 方法：环境变量 和 DNS-based。需要注意的是，一些 DNS 客户端会把 DNS cache TTL 调的很大，甚至默认永不过期。
• Service Addressing。由于 DNS-based SD 只能让服务在 Kubernetes 集群内部访问，我们若有外部访问的需求，则可以使用 ExternalDNS annotations，当有新的 k8s 服务创建，它会自动注册一个子域名。
• Routing。节点来来去去，会导致 Routing …

查看原文

Calico 是构建数据中心网络的技术，它不使用 Overlay Network 技术，而采用 Pure Layer 3 的方式，可以做到更简单，更大容量，性能更好更高效。具体做法是用 BGP 做路由，用纯 IP 网络排线。它可以和 OpenStack & Docker 这些编排系统无缝结合。他不需要在 Layer 2 的数据报文里面再额外封装东西(Packet encapsulation)。也不需要再做 NAT，隧道，VRF 表等等等等。

普通的 Overlay Network 要在实际的 payload 外面包上好些个信息，例如 Outer MAC, Outer IP, Outer UDP, VXLAN …

查看原文

本文给 Python async 框架做了一个 higher-level overview。

首先要理解的两个世界：同步的世界和异步的世界。他们截然不同，库不同，调用方式也不同，虽然可能会共用一些东西。同步的代码只能同步调用，异步的代码只能异步调度。如果非要在同步的代码里调用异步的，或者反之，那么就需要显式地添加胶水代码。

异步的代码在 event loop 中调用，代码被封装称 coroutines 来运行，coroutines 里面会一直同步运行直到运行到 await，然后暂停，被切出，event loop 会运行别的 coroutines。<= 这套技术叫做 cooperative multitasking。其最大的麻烦点主要在于代码运行失败会是 silent failure。

一般我们这么区分代码：async def 的是异步，除此之外的是同步；__init__ 一定要同步。

函数调用分四种：

• 同步调同步：没啥好说 …

查看原文

@mipsytipsy 认为所谓工程不仅要开发服务更要维护服务，当然 on-call 不应该影响生活。作者认为很多公司 on-call 都做的很糟糕，不要学。团队之间应该互相帮助，提高软件质量，将职责完全推到另外一个工种那里不可取。例如，开发者自己出错，增加了别人的工作量，这个算谁的锅呢？

On-call 可以有一套流程来运作，例如额外工资，5-10 人的轮换阵容，只响应特定类型告警，on-call time 轮流休息，问题搞不定了 Escalate，开发团队有义务尽快修复，等等。其中，特别是 Paid On-Call 是构建稳定服务的重要制度，因为公司不可能不付出什么，就享受高稳定的服务。