运维烂笔头

水一篇哈，这里从来没写过读后感，这次水一篇吧。:(

入职这家公司就知道有这么一篇文章要写，一直忙忙碌碌、忙东忙西也没来得及张罗这事。最近（双十一热身），乘着搞活动（满 200 减 100），把这本书买了。

看起来自然很快，一个多礼拜就看完了。

看完了有啥想法？没啥想法。：）

缘起

为了直接打通办公室内网和 AWS 内网，我搞了个“骨干网搭建”项目，其实就是打通办公室内网和 AWS 各个节点的内网。

• AWS 海外节点之间好弄，有 Transit Gateway
• AWS 北京到 AWS 海外直接也好弄，用 wireguard

难点在于办公室到 AWS 北京之间，因为我在办公室内网没有资源，于是只能求助集团的 IT 团队的网络组同事。结果歪打正着，人家打通到总部内网也是走的 IPsec 方案，于是直接可以依葫芦画瓢。

缘起

有人说：

职能团队不能说“不”（There is no “NO”.）。

意思是需求方提出的不管是什么需求，都要有解决方案。这不，公司由于业务需要，某些个团队有科学上网的需求（其实技术团队也有），提到运维这里了，我没法说搞不定呀，于是只能吭哧吭哧想办法解决，最早一版我自己用了好几年的方案被毙，理由是不要用，太复杂（其实也没有被毙，技术团队大多在用这个方案）。于是我就有整了个简单好用的方案，这几天正忙着方案落地呢。

在服务器上安装软件的时候，发现了这个问题。

Server side

environnement

• OS: Amazon Linux 2
• private IP: 10.0.0.1（bind at eth0）
• public IP: 2.2.2.2（supposed, 2.2.2.2 is belong to France TELECOM）
• network interface: eth0

缘起

没啥可说的，面试被问了几个问题，感觉当时答的不太好，事后查了下文档，特此记录下。

Docker 是基于什么

我理解是问 Docker 技术的底层原理是什么。

先看看 Docker 官方是怎么说的：

The underlying technology（(Docker 的）底层技术）

背景

最近几年一直在用 draw.io 来画一些工作中的架构图之类的各种图，这个工具对于 AWS、azure 甚至于 GCP 都支持，但惟独就是还不支持阿里云，而工作中有几家公司偏偏就是用的阿里云，其实也可以用 AWS 之类的图标来画，但强迫症让我必须用阿里云自己的图标。于是就有了本篇内容。

缘起

brew 升级 Joplin 的时候，由于大陆从 github 下载软件包太慢，所以几乎每次都无法完整下载软件包而 timeout 退出。

于是就找了个 github 的代理手工下载（二进制）软件包，然后想通过 brew 直接用本地的 .dmg 文件来升级。

这里的难点，也是本文要谈的问题，就是如何让 brew 直接使用本地下载好的 .dmg 文件升级 Joplin（其他软件也一样）而不是从网上（github）下载。

乍一看，题都不难，但手生了后好多不看 manual 都生写不出来。

没啥可说的，直接上问题。

缘起

最近又（为什么要说“又”呢？）在学着用 Python 来解决一些实际问题，希望能从真实应用场景中提升编码的能力。前面的 用 Kindle 追网文之二 是，现在的俄罗斯方块也是。

背景

前面的文章 用 kindle 追网文 提到了一种用 kindle 追网文的方式，正常工作过一段时间之后，情况又发生变化了：每个章节都被拆成两个页面。这样就导致我只抓了每个章节的第一个页面，第二个页面没抓，自然内容也就不完整了。这部分内容主要是对 用 kindle 追网文 的代码做了些简单的改动，以适应最新情况。