在我的网络配置中，部分 Docker 容器的服务需要用 Anycast 的方式实现高可用，例如 DNS。 在之前的文章中 ，我的做法是，创建了一个 Busybox 容器运行 tail -f /dev/null 这条命令，永久挂起，不占用 CPU 也永远不会退出，来维持一份网络命名空间给服务程序和 BIRD 共享。 用人话说就是：我自己发明了一遍 Kubernetes 的 Pod。 我不使用 K8S，因为我的节点都是独立的，不组成集群，因此不使用 K8S 的集群功能，另外它的配置也比较复杂。 但是我转念一想，为了网络命名空间建一个 Busybox 容器好像有些大材小用，我还需要手动配置一个 Entrypoint。如果有一个极小的 Docker 镜像，唯一干的事情是等待，那就更好了。 方案一：直接用 Musl + 静态编译做一个 最容易想到的方法就是写一个死循环的 C 程序，不断的用 sleep 之类命令等待。Linux 系统中，Glibc、Musl 等 C 语言运行库提供了一个 pause 函数，暂停程序运行直到程序收到了外部信号。...

Docker 镜像中存储的，可以看作是一个个小型 Linux 系统。它们大都以 Debian、Ubuntu 或是 Alpine 作为基础，再在上面安装额外的软件而成。 以完整的 Linux 作为基础的好处就是镜像中会自带常用的命令（ ls ， cat 等），在镜像构建过程中常常用到。另外它们也带有完善的包管理机制，简单使用 apt-get 就能装好软件，做出一份能用的镜像。但当镜像做出之后，上面这些工具就用不到了，占用了不必要的磁盘空间。另外，完整的操作系统也会带有 SystemD、OpenRC 等管理后台服务的程序，而 Docker 容器常常只用来运行一个程序，后台管理程序就多余了。 虽然 Docker 镜像采用分层设计，将基础的系统镜像（例如 Debian）和上层修改（例如安装的 nginx）分开存储并进行去重，从而减少了重复的空间占用，但没有完全解决问题。例如假设我先基于 Debian 构建了一个镜像 A，过了一个月又构建了镜像 B。但在这一个月中，Debian 的基础镜像进行了升级，...

x32 架构是怎么回事呢？x86、x86_64 架构相信大家都很熟悉，但是 x32 是怎么回事呢，下面就让小编带大家一起了解吧。 x32 架构，其实就是 x86 和 x86_64 架构拼在一起，大家可能会很惊讶 x86 和 x86_64 架构怎么会拼在一起呢？但事实就是这样，小编也感到非常惊讶。 x86 及 x86_64 的历史，以及 x32 ABI 我们现在使用的个人计算机及服务器绝大多数都使用 x86_64 架构，该架构由 AMD 于 2000 年发布规范，2003 年发布第一块处理器。x86_64 是一个 64 位的架构，意味着在 x86_64 中，CPU 的每个寄存器都能保存 64 bit 的数据（即 8 个字节）。在 x86_64 流行之前，多数电脑都使用 Intel 处理器以及相应的 x86 架构/指令集，这是一个 32 位的架构，每个寄存器可以保存 32 bit 的数据（即 4 个字节）。 64 位架构的一个显著好处是内存寻址能力的提升。计算机在访问内存时通常按照这样一个流程：将要访问的内存地址写入寄存器，...

正好一年前，我 在 DN42 网络内用 Docker 建立了 Anycast 服务 。当时我的方法是，自定义容器的镜像，在其中安装一个 Bird，然后加入 OSPF 协议的配置文件来广播 Anycast 路由。但是随着时间推移，这套方案出现了以下问题： 安装 Bird 本身是个较花时间的过程。我的 Bird 不是用 apt-get 装的，因为 我的 Dockerfile 需要支持多种 CPU 架构 ，而 Debian 有些架构的软件源里没有 Bird。而又因为我的构建服务器是 AMD64 架构， 使用 qemu-user-static 支持其它架构的镜像运行 ，为其它架构制作镜像、编译程序时就涉及到大量的指令集翻译，效率非常低。构建一个镜像在不同架构下的版本可能需要 2 小时以上，而安装应用本身的 apt-get 流程只需要几分钟。 自己定制镜像也比较花时间。因为容器中需要同时运行目标应用（例如之前的 PowerDNS）和 Bird，就不能直接把目标应用作为 ENTRYPOINT 了，...

由于我有多种架构的设备运行 Docker（包括 x86_64 的电脑和服务器，ARM32v7 的 Tinker Board 和 ARM64v8 的树莓派 3B），我的每个 Docker 镜像都要构建多种版本。最初我 给每个架构单独写一份 Dockerfile ，但是很明显这样难以统一管理，在软件更新修改 Dockerfile 时经常漏改文件。之后，我用的是 Docker 的构建参数功能 ，即 --build-arg 参数，根据参数来调用不同的基础镜像、下载不同文件。 但是这样还是有很大的局限性。首先，不同项目对不同架构的称呼是不一样的。例如，我们平时说的 x86 32 位架构，i386，就被 Go 以及众多使用 Go 的项目叫做 386。类似的，ARM32v7 也可以叫做 ARMHF，而 ARM64v8 有三种写法（ARM64v8，ARM64，AARCH64）。之前，我就不得不用 bash 脚本转换出不同的称呼组合在不同的地方使用，但是这样做就需要设置很多的变量，非常麻烦。 另外，有些镜像在特定架构下需要特殊处理。例如，...

由于我有多种架构的设备运行 Docker（包括 x86 服务器，树莓派，Tinker Board），对于每个常用的软件，我 需要为每种不同架构都构建一份镜像 。之前，我采用的方式是每个架构都有一个独立的 Dockerfile， 类似于这样 ： 可以看到每份 Dockerfile 除了 FROM 调用的镜像不一样，其它几乎完全相同。用这种方式管理，好处是写构建脚本（travis.yml）的时候简单，直接一个个 docker build 过去即可，但是坏处也很明显，每次软件有版本更新，或者我决定添加或删除一个功能，我都要改好几份 Dockerfile。 前两天我查资料时，发现了 Docker 的一个功能：构建参数（Build args），就是可以填入一些参数供构建过程使用。于是我就决定修改构建脚本，将不同架构的 Dockerfile 合并。 使用构建参数 Dockerfile 中使用 ARG 命令就可以定义一个构建参数，它可以像 ENV 定义出的环境变量一样使用： # 定义一个名为 THIS_ARCH 的参数 ARG THIS_ARCH # 或者给它定义上默认值：...

一般情况下，Docker 的镜像都是在一个已有的镜像内，一步步运行给定的命令，从而生成一个新的镜像。这样的步骤在大多数人使用的 x86 架构计算机上都不是问题，由于架构互相兼容，一台计算机上生成的镜像往往可以被直接复制到其它计算机上运行，除非镜像中的程序使用了 AVX 等较新的指令集。 但是，还有一批基于 ARM 架构的主机也可以运行 Docker，并运行专门编译的 ARM 架构的镜像。这些主机包括树莓派系列，和其它类似树莓派的主机，例如 Cubieboard，Orange Pi，Asus Tinker Board 等等。另外，Scaleway 等主机商也提供基于 ARM 架构的独立服务器。 由于 ARM 架构的系统无法在 x86 架构计算机上运行，因此无法在 x86 计算机上直接通过 Dockerfile 生成 ARM 架构的镜像，一般采用的方法是直接找一台 ARM 主机来 docker build。 但是我在为我的树莓派制作 nginx 的 Docker 镜像时发现这并不是一个很好的方法。由于树莓派的内存只有 1GB，...

自从放弃 OpenVZ 架构的 VPS 并购买 KVM 架构的 VPS 以来，我一直使用 Docker 部署 nginx、MariaDB、PHP 等网站需要的程序，不仅方便平时单个服务的重启和配置管理（把配置目录全部用 volume 映射到一起管理），而且方便了服务的升级。 例如，我现在博客所在的 VPS 因为配置不高，内存占用最近一直在 80% 左右。我要更新 nginx 或者向 nginx 里加模块时，如果直接在这台 VPS 上编译 nginx，不仅速度慢，而且有可能因为内存不足而把网站也崩掉。使用 Docker 后，我就可以在其它的空闲资源较多的 VPS 或者在我自己的电脑上构建镜像，push 到 Docker Hub，再在 VPS 上 pull 下来运行。 不过，一直以来，我的 nginx 镜像大小都在 200 MB 左右（Docker Hub 显示大小，不包含基础镜像大小，比一般 docker image 显示的要小），明显大于它应该有的容量，不过因为 VPS 的硬盘暂时足够，而且前段时间我也没什么时间，我就没有管这个问题。现在有了空，...

距离我之前给 nginx 启用 TLS 1.3 已经过了 11 个月了。快一年过后，许多与 nginx 相关的程序、补丁都有了很大的变化： OpenSSL 已经在发布 1.1.1 的测试版，写本文时最新版本是 1.1.1-pre8（也就是 Beta 6）。 nginx 已经更新到 1.15.1。 nginx 的 HPACK 补丁（HTTP 头压缩补丁）的 bug 已经有另外的补丁的补丁修复，使用原先的 HPACK 补丁会导致网站访问不正常，体现为每个网站只能打开一个页面，第二个页面开始就出现协议错误。 有大佬 发布了 OpenSSL 的补丁 ，可以让最新版 OpenSSL 同时支持 TLS 1.3 的 draft 23，26，28 三个版本。 Lets Encrypt 证书已经自带 Certificate Transparency 信息了，不需要 nginx-ct 了。 2018 年 7 月 1 日起，TLS 1.0 不再被建议使用。 因此我重新调整了 nginx 的编译和运行配置，以适应 8102 年的需要。 Dockerfile 我依然使用 Docker 部署 nginx。与之前的 Dockerfile 相比，新的 Dockerfile 只是改了下版本号，...

前言 多台 Docker 服务器上的容器互通是一个不好解决的问题。如果自建一个 Overlay 网络，就需要在一台服务器上建立 etcd 之类的服务。但如果 etcd 所在的服务器挂了，整个网络就 GG 了。我用的便宜 VPS 有偶尔网络中断的情况，我自己搞崩也服务器是常有的事，所以我不能采取这种方式。 Docker 也有其它的基于 Overlay 的商业化组网方案，例如 Weave，但是对于个人用户来说这些方案的价格太高了（我只是搞来玩玩），所以也不考虑。 在这些网络结构上，etcd 或者 Weave 之类的中心服务器记录了每个容器所在的服务器和内部 IP，所以在任何容器上都可以直接 DNS 解析到其它容器。也就是说，假如我设置了 lantian-nginx 和 lantian-phpfpm 两个容器，在 nginx 的配置文件里我可以直接把 php-fpm 的地址填成 lantian-phpfpm:[端口号]，方便配置。 但我好像可以放弃这个功能啊？我的容器数量并不多，而且只有几个 MariaDB 需要跨服务器连接，做数据库主从备份，...