上周的文章聊了关于容器中的一号进程的一些概况后，在我师父某川(可以去 GitHub 找他玩，jschwinger23) 的指导与配合下，我们一起对目前主流的被广泛使用的两个容器中一号进程的实现 dumb-init 和 tini 做了一番探究，继续写个水文来爆论一番。 正文我们为什么需要一个一号进程，我们希望的一号进程需要承担怎样的职责？在继续聊关于 dumb-init 和 tini 的相关爆论之前，我们需要来 review 一个问题。我们为什么需要一个一号进程？以及我们所选择的一号进程需要承担怎么样的职责 其实我们在容器场景下需要一号进程托管在前面实际上有两种主要的场景， 对于容器内 Graceful Upgrade 二进制这种场景，主流的一种做法之一是 fork 一个新的进程，exec 新的二进制文件，新进程处理新链接，老进程处理老链接。（Nginx 就采用这种方案） 没有正确的处理信号转发以及进程回收的情况 一些如同 calico-node 的场景么，我们出于方便打包的考虑，将多个二进制运行在同一容器中 对于第一种其实需要说的没有太多，我们来看一下第二点的测试 我们先准 ...

新年了，决定趁着有时间的时候多写几篇技术水文。今天的话，准备来简单聊聊容器中我们每天都会接触，但是时常又会被我们忽略的一号进程 正文容器技术发展到现在，其实形态上已经发生了很大的变化。根据不同的场景，既有传统的 Docker1, containterd2 这样传统基于 CGroup + Namespace 的容器形态，也有像 Kata3 这样基于 VM 的新型的容器形态。本文主要着眼在传统容器中一号进程上。 我们都知道，传统容器依赖的 CGroup + Namespace 进行资源隔离，本质上来说，还是 OS 内的一个进程。所以在继续往下聊容器相关的内容之前，我们需要先来简单聊聊 Linux 中的进程管理 Linux 中的进程管理简单聊聊进程Linux 中的进程实际上是个非常大的话题，如果要展开聊，实际上这个话题可以聊一整本书= =，所以为了时间着想，我们还是把目光聚集在最核心的一部分上面（实际上是因为很多东西我也不懂。 首先来讲，在内核中利用一个特殊的结构体来维护进程有关的相关信息，比如常见的 PID，进程状态，打开的文件描述符等信息。在内核代码中，这个结构体是 task_str ...

这篇文章，实际上本应该在 2020 年结束时写完的。不过我是一个拖延症患者，而且写这篇文章时会想起一些已经离去的人，所以一直不愿动笔，拖到了现在。不过在农历新年的末尾，还是得写出来，给自己去过一年一个总结吧。 开篇怎么说呢，2020其实是很操蛋的一年，我无数次的在内心问候”2020，我日你仙人“（山本大佐表示很赞） 但是2020呢，其实又是挺好的一年，让我估计后面会无数次的从2020这一年里学到的东西中受益。 所以吧，我把这暂且称为薛定谔2020？（算了，这 TM 就是 Manjusaka 的2020 工作大年三十了，先说点难过的吧，熟悉我的朋友都知道，我其实2020的职业生涯从职级的角度上来说可以用职场败犬来形容 Yep，没错，我被降级了，而且晋升还他娘挂了。你说我气不气 你要说我心态没有炸实际上是不可能的，在19年调转时刚得知降级结果那段时间心态简直爆炸。当时我老板说了一句印象非常深刻的话”你怎么焦虑成这样了，我记得你当时刚进来时不是这样的啊？“ 在心里接受降级后，开始继续努力搬砖争取晋升回来后，然后，晋升又挂了。我？？？？？？ 不过说回来，其实这段经历，可能在刚刚发生那一会儿 ...

从去年调转到现在，做了一段时间的云原生，我突发奇想，想发表几个爆论来论述下我眼中的云原生来作为今年最后一篇技术博客。本文纯属个人向吐槽，与本人公司立场无关 概述云原生大概在 2014-2015 年开始左右，开始正式的提出了这个概念。2015 年 Google 主导成立了云原生计算基金会（Cloud Native Computing Foundation aka CNCF)。在 2018 年，CNCF 在 CNCF Cloud Native Definition v1.01 首次对云原生的概念有了一个认定 Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declara ...

上次写了一个水文简单聊聊进程中的信号处理 ，师父看了后把我怒斥了一顿，表示上篇水文中的例子太 old style, too simple ,too naive。如果未来出了偏差，我也要负泽任的。吓得我连和妹子周年庆的文章都没写，先赶紧来重新水一篇文章，聊聊更优秀，更方便的信号处理方式 前情提要首先来看看，之前那篇文章中的例子 1234567891011121314151617181920212223242526272829303132333435363738394041#include <errno.h>#include <signal.h>#include <stdio.h>#include <string.h>#include <sys/wait.h>#include <unistd.h>void deletejob(pid_t pid) { printf("delete task %d\n", pid); }void addjob(pid_t pid) { ...

我本来以为我不再会写水文了，但是突然发现自己现在也只能勉强写写水文才能维持生活这样子。那就继续写水文吧 某天，一个技术群里老哥提出了这样一个问题，为什么在一些情况下，Python 中的简单乘/除法比位运算要慢 首先秉持着实事求是的精神，我们先来验证一下 1234567891011In [33]: %timeit 1073741825*2 7.47 ns ± 0.0843 ns per loop (mean ± std. dev. of 7 runs, 10000 ...

最近在某个技术群里帮人分析了 Linux 编程下信号处理的一段代码。我自己觉得这段代码是挺不错的一个例子，所以写个简单的水文，用这段代码聊聊 Linux 中的信号处理 正文我们首先来看一看这一段代码 1234567891011121314151617181920212223242526272829303132333435363738394041#include <errno.h>#include <signal.h>#include <stdio.h>#include <string.h>#include <sys/wait.h>#include <unistd.h>void deletejob(pid_t pid) { printf("delete task %d\n", pid); }void addjob(pid_t pid) { printf("add task %d\n", pid); }void handler(int s ...

这段时间在不少群里争论过关于 Kubernetes 和容器化的一些事，干脆总结下一些碎碎念作为一个概括吧。本文仅代表个人立场，不代表商业观点 容器化目前很主流的一个观点，是能上容器尽可能上容器，说实话这个想法实际上是有一定的合理性的，去 review 这个想法，我们需要去看一下容器这个东西，给我们带来了什么样的改变 容器首先毫无疑问，会给我们带来非常多的好处： 真正意义上让开发与生产环境保持一致是一种非常方便的事，换句话说，开发说的“这个服务在我本地没啥问题”是一句有用的话了 让部署一些服务变的更为方便，无论是分发，还是部署， 能做到一定程度上的资源隔离与分配 那么，看起来我们是不是可以无脑用容器？不，不是，我们需要再来 Review 一下，容器化后我们所要面临的一些弊端： 容器安全性问题，目前最主流的容器实现（此处点名 Docker）本质上而言还是基于 CGroups + NS 来进行资源与进程隔离。那么其安全性将会是一个非常值得考量的问题。毕竟 Docker 越权与逃逸漏洞年年有，年年新。那么这意味着我们是需要去有一个系统的机制去规范我们容器的使用，来保证相关的越权点能被把 ...

好久没博客了，来写个简单的读论文笔记吧，这篇文章是来自 Google 2016 年发表的一篇论文 Maglev: A Fast and Reliable Software Network Load Balancer 分享了他们内部从08年开始大规模使用的软负载均衡系统的实现。里面很多很有趣的细节，我看我能写多少，算多少吧 背景负载均衡的概念大家肯定都比较熟悉了，再次不再赘述。现在我们需要考虑 Google 的场景。设计之初，Google 需要一种高性能的 LB 来承担 Google 一些重头服务的流量，比如 Google 搜索，Gmail 等等。由于流量非常庞大，那么 LB 需要非常强大的性能来处理大量的流量。 在这里，传统的想法可能说，我直接上专业的硬件负载均衡，能用钱解决的问题，都不算事（笑。但是这样的方案有着不小的问题 硬件负载均衡单点的性能决定了整个网络能承担的请求 在 HA 上存在缺陷。为了保证单点失效的时候，整个网络集群不陷入瘫痪。那么我们通常需要 1:1 的做冗余 灵活性和编程性欠缺，想做骚操作的时候没有切入点 太贵了。贵到 Google 都承受不了（逃 在这样一种 ...

在知乎上看到一个很有意思的问题，为什么TypeScript如此流行，却少见有人写带类型标注的Python？ 虽然我没忍住在知乎上输出了答案，但是为了以防万一，我在博客上扩展，与更新一下 BTW 最近上线真的心力憔悴，写个文章放松下 开始其实这个答案很简单，历史包袱与 ROI，在了解为什么有这样的现象之前，首先我们要去了解 Type Hint 能给我们带来什么，然后我们需要去了解 Type Hint 的前世今生 在现在这个时间点（2020.03）来看，Type Hint 能给我们带来肉眼可见的收益是 通过 annotation ，配合 IDE 的支持，能让我们在代码编辑的时候的体验更好 通过 mypy/pytype 等工具的支持，我们能在 CI/CD 流程中去集成静态类型检查 通过 pydantic 以及很多新式框架的支持，我们能够减少很多重复的工作 可能大家以为从 Python 3.5 引入 PEP 484 开始，Python Type Hint 便已经成熟。但是实际上，这个时间比大家想象的短的多 好了，我们现在要去回顾一下整个 Type Hint 发展史上的关键节点 PEP ...