流年 ℃

Harbor是什么

Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。

作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。

为什么使用bitnami的镜像安装harbor

• 首先你可能无法正常访问github, 而harbor依赖于nginx、db、redis等多个软件平台，采用docker-compose安装相对优雅;
• 其次harbor官方并没有直接提供 docker-compose;
• bitnami是一个比较成熟知名的容器镜像提供商;
• 最后一点，也是我最看中的：因为bitnami有 arm 架构的镜像， 而我正好计划将harbor搭建在 orangepi里，使用bitnami镜像搭建就不用我在折腾去编译 arm 架构的镜像了!

bitnami官方文档安装harbor（不推荐，可能失败）

官方镜像地址：https://hub.docker.com/r/bitnami/harbor-portal

首先我们看一下bitnami的官方文档，仅需三行命令就可以安装harbor了。

$ curl -LO https://raw.githubusercontent.com/bitnami/containers/main/bitnami/harbor-portal/docker-compose.yml
$ curl -L https://github.com/bitnami/containers/archive/main.tar.gz | tar xz --strip=1 --wildcards '*-main/bitnami/harbor-portal/config' && mv bitnami/harbor-portal/config . && rm -rf bitnami
$ docker-compose up

官方文档错误情况

但我在mac系统下面测试，上面的命令可能会出现很多异常情况，比如

错误1：

tar: Option --wildcards is not supported

错误2：

……

什么是 LSM Tree ？

LSM Tree 全名：Log Structured Merge Tree ，是一种在机械盘时代大放异彩的存储架构设计。LSM Tree 是一个把顺序写发挥到极致的设计架构。它的核心之一就是 log 文件。

笔者以几个问答来看下它的设计思想：

问题一：LSM Tree 存储引擎到底是什么？

不就是一个 key/value 存储引擎嘛。

问题二：用户写是怎么一个流程？

用户递交数据流程分为两步：写 log 文件，修改内存。所以会看到， 写的流程是非常简单的，用户的时延正常情况下就只包含这两步。

问题三：用户的删是怎么一个流程？

LSM Tree 为了极致的写性能把所有的更新操作都化作顺序写。也就是说， 删除也是写入。往存储里面写一条带删除标记的记录，而不是直接更新原来的数据。

问题四：这是一个持久化的存储吗？能保证掉电不丢数据吗？

是持久化的，因为 log 持久化了嘛。掉电不会丢数据，因为可以从 log 文件中恢复出来。恢复很简单，其实就是遍历 log 文件，然后解析出来就好。

那既然说到解析 log 文件，那么问题又来了，log 文件越大解析时间会越长，无限制增长这个是无法忍受的。

……

前言

什么是架构？

通常情况下，人们对架构的认知仅限于在软件工程中的定义：架构主要指软件系统的结构设计，比如常见的 SOLID 准则、DDD 架构。一个良好的软件架构可以帮助团队更有效地进行软件开发，降低维护成本，提高系统的可扩展性和可维护性。这里的架构定义有更多元化的理解：架构不仅是对软件开发设计和流程规范的定义，也包含了参与架构设计的人员、以及项目过程中和架构有关的活动，都可以称为架构。

从广义角度来理解架构，意味着更全面的思考和新的融合。

按这张图理解，架构是指架构师以商业价值为导向、以用户为核心，在所处的商业、文化、技术环境中，利用有限的资源和成本，设计架构方案、组织或参与研发活动，从而达到既定目标的一项复杂且持续的活动。

架构师面对实际问题，在复杂的环境中如何做出正确的选择，如何确保架构活动顺利进行，保障项目落地，可以从目标、资源、行为、趋势这四个层面来梳理。

……

当今互联网到处存在着一些中间件(MIddleBoxes)，如NAT和防火墙，导致两个(不在同一内网)中的客户端无法直接通信。 这些问题即便是到了IPV6时代也会存在，因为即使不需要NAT，但还有其他中间件如防火墙阻挡了链接的建立。 目前部署的中间件多都是在C/S架构上设计的，其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求。 大多数中间件实现了一种非对称的通讯模型，即内网中的主机可以初始化对外的链接，而外网的主机却不能初始化对内网的链接， 除非经过中间件管理员特殊配置。

在中间件为常见的NAPT的情况下（也是本文主要讨论的），内网中的客户端没有单独的公网IP地址， 而是通过NAPT转换，和其他同一内网用户共享一个公网IP。这种内网主机隐藏在中间件后的不可访问性对于一些客户端软件如浏览器来说并不是一个问题，因为其只需要初始化对外的链接，从某方面来看反而还对隐私保护有好处。然而在P2P应用中， 内网主机（客户端）需要对另外的终端（Peer）直接建立链接，但是发起者和响应者可能在不同的中间件后面， 两者都没有公网IP地址。而外部对NAT公网IP和端口主动的链接或数据都会因内网未请求被丢弃掉。

本文讨论的就是如何跨越NAT实现内网主机直接通讯的问题。

网络模型

假设客户端A和客户端B的地址都是内网地址，且在不同的NAT后面。A、B上运行的P2P应用程序和服务器S都使用了UDP端口9982，A和B分别初始化了 与Server的UDP通信，地址映射如图所示:

                        Server S
                    207.148.70.129:9981
                           |
                           |
    +----------------------|----------------------+
    |                                             |
  NAT A                                         NAT B
120.27.209.161:6000                            120.26.10.118:3000
    |                                             |
    |                                             |
 Client A                                      Client B
  10.0.0.1:9982                                 192.168.0.1:9982

现在假设客户端A打算与客户端B直接建立一个UDP通信会话。如果A直接给B的公网地址120.26.10.118:3000发送UDP数据，NAT B将很可能会无视进入的 数据（除非是Full Cone NAT），因为源地址和端口与S不匹配，而最初只与S建立过会话。B往A直接发信息也类似。

假设A开始给B的公网地址发送UDP数据的同时，给服务器S发送一个中继请求，要求B开始给A的公网地址发送UDP信息。A往B的输出信息会导致NAT A打开 一个A的内网地址与与B的外网地址之间的新通讯会话，B往A亦然。一旦新的UDP会话在两个方向都打开之后，客户端A和客户端B就能直接通讯， 而无须再通过引导服务器S了。

UDP打洞技术有许多有用的性质。一旦一个的P2P链接建立，链接的双方都能反过来作为“引导服务器”来帮助其他中间件后的客户端进行打洞， 极大减少了服务器的负载。应用程序不需要知道中间件具体是什么（如果有的话），因为以上的过程在没有中间件或者有多个中间件的情况下 也一样能建立通信链路。

……

docker 运行时会产生日志，时间久了占用宿主机磁盘空间非常大，可以通过设置日志文件大小限制，也可以定期清除文件。

下面，清理 docker 运行占用的磁盘空间为例。

df 查看磁盘使用情况

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            924M     0  924M   0% /dev
tmpfs           188M  856K  188M   1% /run
/dev/vda1        40G   36G  1.7G  96% /
tmpfs           940M     0  940M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
overlay          40G   36G  1.7G  96% /var/lib/docker/overlay2/4d0744e41be2f1576b3c2a67d74af621738d37c85e305d75e0bf6fe2d2c3777f/merged
tmpfs            50M     0   50M   0% /usr/local/aegis/cgroup
overlay          40G   36G  1.7G  96% /var/lib/docker/overlay2/4a4a729a84a73b77b9a82daf2f2405412bb8e0a48ab41feda7ceca4438d375aa/merged
overlay          40G   36G  1.7G  96% /var/lib/docker/overlay2/6d4dd9f4a32de946509ed6d885d97660919dd60fff115ecbb322e9351f40cd36/merged
overlay          40G   36G  1.7G  96% /var/lib/docker/overlay2/4fb297559aa05464b68454b4bec76f57e7b61e30a4bfad4178a4a9c052650ade/merged
tmpfs           188M     0  188M   0% /run/user/0

查看docker容器占用情况

……