青云卷

为啥不给扩容？已经影响到业务了

Sun, 09 Jul 2023 15:02:04 +0800

正常云厂商 kubernetes 集群的节点池（也叫节点组或 NodeGroup）都是由另一款较老的产品 弹性伸缩 来实现的，当然啦，不同云厂商有不同叫法，这儿就不细说了。也正是由于这种不那么紧密的关系使得集群弹性伸缩对于异常情况的处理显得有些欠火候，用户也是叫苦连天。

cluster-autoscaler 中有一个超时参数在很多地方都有用到 --max-node-provision-time，默认为 15min，下面会大量用到。

扩容逻辑在另一篇文章中有讲，所以本文会略过，主要讲一下当 pending 的 pod 已经触发扩容后失败的情况。

创建节点失败

正常来说，经过一系列的逻辑处理，有了扩容方案后，CA 会调用底层弹性伸缩的接口调整节点的的期望实例数触发扩容，同时通过 ScaleUpRequest 缓存该事件，在以后的每次的循环中查看该事件的完成情况，如果扩容完成了就会清理掉该事情。

CA 判断底层有没有将节点扩出来的标准是看通过 (cloudprovider.NodeGroup).Nodes() 查到的节点数量是不是小于 (cloudprovider.NodeGroup).TargetSize()，如果小于，那就说明还在扩。

但事情往往总会发生点意外：

如果 CA 调用底层弹性伸缩的接口失败了该怎么办？
如果底层一直建不出机器怎么办？

针对情况 1，CA 会立即将对应的节点池 backoff 掉，并报告事件 FailedToScaleUpGroup；情况 2，CA 的等待会有一个超时时间（--max-node-provision-time指定），时间一到也会将其 backoff 掉并报告事件 ScaleUpTimedOut。

然而，针对情况 2，仅仅是 backoff 掉没有扩出来的节点池还是不够的，因为弹性伸缩的期望实例数并不等于当前实例数，这在 CA 看来就是有扩容中的节点从而不会触发新扩容，而且后面确实有可能被弹性伸缩再扩出来（比如在弹性伸缩在超过--max-node-provision-time指定的时间的重试中又给扩出来了）。此时就引出了 CA 的修正逻辑，当 CA 观察到伸缩组已经没有在扩容了，并且长时间（--max-node-provision-time指定）期望实例数小于当前实例数且数量一直不曾改变时，就会将期望实例数调整与当前实例数保持一致。

情况 1 多见于 IaaS 层故障，并不多见，且我们也无能为力。但是针对于情况 2，扩容要 15min（--max-node-provision-time默认）超时才算作失败，且在超时 15min 后还得观察 15min 修正后才会触发新的扩容，里外里足足 30 分钟¹，这哪个客户受得了，一般扩容都是十万火急的场景。

也因为这个原因，CA 社区又给提供了第三种失败，即在每一次循环中查询失败的节点，如果看到有失败的节点就 backoff 节点池，并报告事件 ScaleUpFailed，紧接着立即删除失败的节点。这就使得 CA 能在最短的时间内响应扩容失败并立即触发其它节点池扩容。

既然这个特性这么好，是不是各厂商都用起来了呢？其实并没有，大多厂商的弹性伸缩并不会保存创建失败节点。这里列一下已经支持的厂商：

gce，原本就在 MIG 中保留了失败的节点，所以先天支持，也是目前支持的最好的
aws，大概一年前支持的，通过 mock 创建中的节点来实现的
tke原生节点，原生节点失败的 machine 会被保留下来，所以也是先天支持

不过，总结来说，创建失败一定跟 弹性伸缩 有关。

节点池的 backoff 机制

--initial-node-group-backoff-duration，初始 backoff 时间
--max-node-group-backoff-duration，最大 backoff 时间
--node-group-backoff-reset-timeout，backoff 重置时间

假设节点池一直扩不出来 5m 10m 20m 30m 30m … 每次 backoff 时间不超过 3h，3h 后又会按 5m 开始

异常分析

这里假设只能通过超时来发现扩容失败，同时也从侧面讲一下循环中查询扩容失败的必要性。

场景 1：集群 pod 触发节点池 A 扩容 2 个节点，15min 过后节点没扩出来，节点池 A 被 backoff, 5min 后节点池 A 退出 backoff 状态，后续一直没有再触发节点池 A 产生新的扩容，15min 后触发修正逻辑，将节点池 A 的期望实例数减 2，由于在之前节点池 A 就已经退出了 backoff 状态，所以这次扩容还有可能扩到节点池 A，如果再次扩节点池 A，过 15min 后，再次被 backoff，此次 10min 退出 backoff 状态，15min 后第二次修正节点池 A，同理，第三次扩容还有可能扩到节点池 A，又过 15min 后，继续 backoff，这次 20min 才能退出，由于还处理 backoff 状态中，所以再过 15min 第三次修正后，可以确保不会触发节点池 A 扩容。至此，当节点池 A 持续不可用时，可能需要 15x6=90min（实际不止这么多，因为还有--scan-interval指定的循环间隔需要被算入）才能切换到其它节点池扩容。
场景 2：在场景 1 中，如果在扩容的 15min 内又有新的 pod pending，并且还是触发节点池 A 的扩容，那么超时时间会被重置，那么无法扩出的时间可能比 90min 还会更长。
场景 3：当前节点池是一个异常状态，没有节点在集群中，并且当前实例数小于期望数，CA 由于重启或者其它原因并没有该节点池的 ScaleUpRequest 缓存，这种情况下，CA 将无法获取到异常节点池的修正信息，从而不会触发修正，而又由于节点池的期望实例没有修正会被 CA 认为是有节点池节点正常加入中，而不会触发新的扩容。这种情况下要人工介入修正节点数才能解决。

如果云厂商提供了在查询扩容失败的解决路径，那么以上三种情况都可解决。

注册节点失败

如果有节点被创建出来了，长时间（--max-node-provision-time指定）没有注册，也会被删除并上报事件 DeleteUnregistered。这种一般是由于集群的节点添加流程出现了问题。

不满足前置条件

集群健康

如果 CA 的日志中出现 Cluster is not ready for autoscaling，那说明集群当前状态异常，这样 CA 唯一能进行的写操作是移除长时间未注册的节点（这有可能使集群状态恢复正常），而不会再触发扩缩容，满足下述条件时，集群会被认为异常：

集群中未就绪节点数²达到--ok-total-unready-count指定值（默认是3），其占比达到max-total-unready-percentage指定值，默认是45

节点池健康

当节点池被认为不健康或已经 backoff 时，不会触发该节点池扩缩，即当出现下述情况之一时：

当集群中没有该节点池节点，但节点池的期望实例数又不为 0 时，此时 CA 日志中会出现Failed to find readiness information
当前节点池中已就绪实例数比该节点池期可接受的最小实例数³还小时，且其差值大于--ok-total-unready-count，并且在节点池中的占比超过max-total-unready-percentage

参数限制

达到下面这些参数限制时，不会触发扩缩容：

--max-nodes-total，限制集群最大节点数
--cores-total，限制集群最大核心数
--memory-total，限制集群最大内存数
--gpu-total，限制集群最大 gpu 数

实际应该是超过 90 分钟，具体待测试，在异常分析场景 2 中有介绍 ↩︎
未就绪节点的定义方式在系列文章中有提到，可以自行查阅 ↩︎
当节点池正在扩容时，这个值为期望实例数-正在扩容节点数；当其正在缩容时，这个值为期望实例数 ↩︎

通过 kubeadm 安装 kubernetes 1.26

Sat, 18 Mar 2023 18:04:55 +0800

环境准备

master 节点使用 cri-o、worker 节点使用 containerd 作为运行时

master 节点

操作系统：Ubuntu Server 22.04 LTS
规格：2c4g
cloud-master1 10.67.3.9
cloud-master2 10.67.3.13
cloud-master3 10.67.3.15

worker 节点

操作系统：Ubuntu Server 22.04 LTS
规格：2c2g
VM-2-42-ubuntu 10.67.2.42

负载均衡

43.135.64.117

节点配置

所有节点都需要的初始化配置，含 master 和 worker 节点

安装 kubeadm、kubelet、kubectl

更新 apt 包索引并安装使用 Kubernetes apt 仓库所需要的包：

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

下载 Google Cloud 公开签名秘钥：

sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

添加 Kubernetes apt 仓库：

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

更新 apt 包索引，安装 kubelet、kubeadm 和 kubectl，并锁定其版本：

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

配置操作系统

转发 IPv4 并让 iptables 看到桥接流量

执行下述指令：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

*# 设置所需的 sysctl 参数，参数在重新启动后保持不变*
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

*# 应用 sysctl 参数而不重新启动*
sudo sysctl --system

通过运行以下指令确认 br_netfilter 和 overlay 模块被加载：

lsmod | grep br_netfilter
lsmod | grep overlay

通过运行以下指令确认 net.bridge.bridge-nf-call-iptables、net.bridge.bridge-nf-call-ip6tables 和 net.ipv4.ip_forward 系统变量在你的 sysctl 配置中被设置为 1：

sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward

创建高可用控制面

配置负载均衡器

43.135.64.117:443 → 10.67.3.9:6443、10.67.3.13:6443、10.67.3.15:6443

配置 master 运行时

查看默认 cgroup 驱动

stat -fc %T /sys/fs/cgroup/

安装 CRI-O

root 执行

export OS=xUbuntu_22.04
export VERSION=1.26

echo "deb [signed-by=/usr/share/keyrings/libcontainers-archive-keyring.gpg] https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
echo "deb [signed-by=/usr/share/keyrings/libcontainers-crio-archive-keyring.gpg] https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

mkdir -p /usr/share/keyrings
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | gpg --dearmor -o /usr/share/keyrings/libcontainers-archive-keyring.gpg
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/Release.key | gpg --dearmor -o /usr/share/keyrings/libcontainers-crio-archive-keyring.gpg

apt-get update
apt-get install cri-o cri-o-runc

CRI-O 默认也使用 systemd cgroup 驱动

启动 CRI-O

systemctl enable crio
systemctl start crio

配置控制面

初始化 master1

sudo kubeadm init --control-plane-endpoint "43.135.64.117:443" --upload-certs

成功后得到如下输出：

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

 export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of the control-plane node running the following command on each as root:

 kubeadm join 43.135.64.117:443 --token 3639bw.3f5i3dooplnd982i \
 --discovery-token-ca-cert-hash sha256:e66819320b79ccab1ca6f570db82fd67d1d17c2f59e8091779a4c99a3c0f37c6 \
 --control-plane --certificate-key 30c003d1c1d480f0c4c6df6bdba9d097b2e771013e11430bec4a4151afd730fc

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 43.135.64.117:443 --token 3639bw.3f5i3dooplnd982i \
 --discovery-token-ca-cert-hash sha256:e66819320b79ccab1ca6f570db82fd67d1d17c2f59e8091779a4c99a3c0f37c6

要重新上传证书并生成新的解密密钥，请在已加入集群节点的控制平面上使用以下命令：
```
kubeadm token create --print-join-command
```

初始化其它 master

命令来自于前面初始化得到的输出：

kubeadm join 43.135.64.117:443 --token 3639bw.3f5i3dooplnd982i \
 --discovery-token-ca-cert-hash sha256:e66819320b79ccab1ca6f570db82fd67d1d17c2f59e8091779a4c99a3c0f37c6 \
 --control-plane --certificate-key 30c003d1c1d480f0c4c6df6bdba9d097b2e771013e11430bec4a4151afd730fc

创建计算节点

配置 worker 运行时

查看默认 cgroup 驱动

stat -fc %T /sys/fs/cgroup/

安装 containerd

sudo apt-get update
sudo apt-get install \
 ca-certificates \
 curl \
 gnupg \
 lsb-release
sudo mkdir -m 0755 -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo chmod a+r /etc/apt/keyrings/docker.gpg
sudo apt-get update
sudo apt-get install containerd.io

安装 cni

wget https://github.com/containernetworking/plugins/releases/download/v1.2.0/cni-plugins-linux-amd64-v1.2.0.tgz
sudo mkdir -p /opt/cni/bin
sudo tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v1.2.0.tgz

安装 containerd

wget https://github.com/containerd/containerd/releases/download/v1.6.16/containerd-1.6.16-linux-amd64.tar.gz
sudo tar Cxzvf /usr/local/ containerd-1.6.16-linux-amd64.tar.gz

配置 containerd

containerd config default > /etc/containerd/config.toml

结合 runc 使用 systemd cgroup 驱动，在 /etc/containerd/config.toml 中设置：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
 ...
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
 SystemdCgroup = true

安装 CNI

wget https://github.com/containernetworking/plugins/releases/download/v1.2.0/cni-plugins-linux-amd64-v1.2.0.tgz
sudo mkdir -p /opt/cni/bin
sudo tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v1.2.0.tgz

配置 CNI

sudo mkdir /etc/cni/net.d/
sudo cat << EOF > /etc/cni/net.d/100-containerd-bridge.conflist
{
 "cniVersion": "1.0.0",
 "name": "containerd",
 "plugins": [
 {
 "type": "bridge",
 "bridge": "cni0",
 "isGateway": true,
 "ipMasq": true,
 "hairpinMode": true,
 "ipam": {
 "type": "host-local",
 "routes": [
 { "dst": "0.0.0.0/0" },
 { "dst": "::/0" }
 ],
 "ranges": [
 [{ "subnet": "10.85.0.0/16" }],
 [{ "subnet": "1100:200::/24" }]
 ]
 }
 }
 ]
}
EOF

systemd 启动

systemctl enable containerd
systemctl start containerd

加入集群

sudo kubeadm join 43.135.64.117:443 --token 3639bw.3f5i3dooplnd982i \
 --discovery-token-ca-cert-hash sha256:e66819320b79ccab1ca6f570db82fd67d1d17c2f59e8091779a4c99a3c0f37c6

一文让你搞明白集群弹性伸缩是如何运作的

Mon, 06 Mar 2023 21:52:50 +0800

功能简介

弹性伸缩 可以根据用户实际需求调整计算资源（算力）的多寡，可以说这是每个厂商必备的能力，比如腾讯云 AS、Amazon EC2 Auto Scaling、Azure Autoscale、Google MIG、阿里云 ESS 等等。集群弹性伸缩 作用于 kubernetes 集群中，功能上与弹性伸缩保持一致，两者最大的差异是衡量资源需求量的标准。弹性伸缩常常以实际负载作为扩缩依据，而集群弹性伸缩是以资源分配占比作为依据，为 workload 分配资源往往需要我们对自身的业务具有相对合理的认识。

CA 可以根据集群实际使用情况，为集群增加或者减少节点：

当有 pod 由于资源不足而不可调度时，考虑扩容
当有节点资源利用率不足时，考虑缩容

与 HPA、HPC 的关系

在 kubernetes 中有关 HPA 的介绍可以移步官方文档，HPA 可以根据实际负载调整 workload 的副本数，即 Pod 数量，如果调升后计算资源不足就会导致 Pod Pending，调降后资源过剩就会导致节点闲置。尽量保证 Pending 的节点得到调度，闲置的节点得到释放，就是 CA(cluster-autoscaler 简称) 的作用。CA + HPA 与云厂商的弹性伸缩功能大致相当。

根据负载得到的资源需求往往具有一定的滞后性，触发扩容时或多或少都已经影响到了业务，所以云厂商提供的弹性伸缩一般还具有定时伸缩的能力。TKE 团队提供的 HPC 可以定时调整 workload 的副本数，其与 CA 配合就可以达到集群节点定时伸缩的效果了。

使用须知

CA 一般基于云厂商提供的弹性伸缩功能实现 NodeGroup，但其伸缩机制有冲突，故不可在集群中的启用原弹性机制
开启集群弹性伸缩的集群中的 workload 务必指定 request
NodeGroup 中配置的机型资源充足
当单节点池配置了多可用区的子网时，含可用区亲和性调度的扩容会有异常
不支持单节点池多规格机型

实现逻辑

CA 的代码主体是一个无限循环，通过一次次的扫描集群，根据集群当前状态决策和执行扩缩容。具体的循环间隔通过 --scan-interval 参数控制，默认为 10s，一张图带你理解扩缩容全流程：

集群快照ClusterSnapshot中，会存储所有节点和非低优的 Pod
生成加工出来的模板用于扩容，将在后续扩容专题中细讲
更新集群状态的主要目的是：
- 找出已经触发扩容但还没有注册的节点
- 为扩容超时节点对应的节点池设置 backoff
- 查询创建失败的节点，设置对应节点池为 backoff
- 找出当前已注册节点数不在可接受区间内的节点池
- 清理 backoff
长时间没有注册上的节点会被删除，时间由 --max-node-provision-time 指定，默认为 15min
只有当集群是健康时，CA 才会实际扩缩容，否则循环会直接返回
删除在更新集群状态时找到的创建失败的节点
当已经注册的实例数长时间小于期望实例数时，会将节点池的期望实例数调整为已注册实例数，时间由 --max-node-provision-time 指定，默认为 15min
过滤掉一些不需要触发扩容的 pod
- 不考虑优先级太低的 Pod，--expendable-pods-priority-cutoff 指定，默认为 -10
- 过滤掉有 NominatedNodeName 属性的 Pod
- 过滤掉可调度到已有节点和 upcoming 节点上的 Pod
- 过滤掉创建时间过短的节点，时间由 --new-pod-scale-up-delay 指定，默认为 0，即不过滤
- 过滤掉创建时间短于 2s 的 pod，或者短于 30s 的 gpu pod
扩容将在后续扩容专题中细讲
缩容将在后续缩容专题中细讲

集群健康认定

当集群同时满足下述两个条件时，集群会被认为是异常的，反之健康：

未就绪的 Node 数大于启动参数中 —-ok-total-unready-count 指定值（默认 3）
未就绪的 Node 数占总 Node 数百分比大于 —-max-total-unready-percentage 指定值（默认 45）

当集群不健康时，在会在 kube-system 下记录一个 ClusterUnhealthy 的事件。

扩容中节点（Upcoming Nodes）

扩容中实例数 = 期望实例数 - (就绪实例数 + 未就绪实例数 + 长时间未注册的实例数)

期望实例数：节点池当前期望的实例数
就绪实例数：节点池在集群中已经就绪可用的实例数
未就绪实例数：已经注册到集群但还不可用的实例数
未注册实例数：通过 cloudprovider 可以查到，但是在集群中还查不到的实例数
已删除的实例数：被打上 ToBeDeletedByClusterAutoscaler 污点的实例数
长时间未注册的实例数：存在时间超过 —-max-node-provision-time 的未注册实例数

Pyflink in Kubernetes

Wed, 06 Jan 2021 15:00:43 +0800

pyFlink on kubernetes

在 TKE 环境下

准备工作

为 flink 创建专用的命名空间、ServiceAccount，并设置好资源配额

kubectl create ns flink
kubectl -n flink create sa flink
kubectl -n flink create role flink --verb=* --resource=*.*
kubectl -n flink create rolebinding flink --role=flink --serviceaccount=flink:flink
cat << EOF > apiserver.crt # base 集群 apiserver 证书
-----BEGIN CERTIFICATE-----
MIICyDCCAbCgAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIwMDMwNTA4MjYzOFoXDTMwMDMwMzA4MjYzOFowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMq/
6ae6qIZbchBK7b0AaP2714K+tuxtGnl7p3yNwlCgVEnZjfytAr8cvkIzxCBH8xBc
vqV2vtDOy0r6HecbIPTkd0bGn6BXjqPp6XZY0ffFgyBhGv6/DD7x7aJIG+A8uSVk
/yTGcahGQ9WOQ6CDWDjZvC+K9zkeNqhtj1wm9P/hQcECAQkQbkIqLUF/P8SF4b8N
QlodYsrZIg9MDqgQDq744AoFPm/F6G2GfHs1DfesYMoSYQs6ECec0+N/Nf5Kx7XX
KW+ARAGEZxC3X7bJmxWr5JSRmmS46rmrN/MUDpMBaWUwtxubVxtIwt1FIFlFqCYz
MR9UtvZkTaL6oSd6Q18CAwEAAaMjMCEwDgYDVR0PAQH/BAQDAgKUMA8GA1UdEwEB
/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBABXd9WbwOlhlqyFsr/2s9wgf86+/
oo05gZhybHtuKHYvSwzoxAeyaMFGn4b7S2okcLoo3EwjmAN2Pup/qhTtiqM9xNfa
+GuN+NX4zjkra+T2NEywIykwhodaFiYB+r6xM0LIHANlKKT7kRtgzkq/s8ui6Wkt
b94T8BpE5U3f6YGz/4NtbqpYS6XVjIIjfP5MxoHRCh8H2LXmWs9A2RlmuZAwo0M2
FJjxcfIgvHrgCerPogVcXYT23BavOhMFlx7Jck2GAbDg0HYTabZuLNkj9T1//raL
aknXJxuLYHbZe6I1cbsIdXJjav5c83YgqGDKetcJdkQqMgk8lVWW7RIdLb0=
-----END CERTIFICATE-----
EOF
kubectl config --kubeconfig=flink-kubeconfig set-cluster base --server=https://cls-xxxxxxx.ccs.tencent-cloud.com --certificate-authority=apiserver.crt --embed-certs=true
kubectl config --kubeconfig=flink-kubeconfig set-credentials flink --token=$(kubectl -n flink get sa flink -o=jsonpath={.secrets[0].name} | xargs kubectl -n flink get secrets -o=jsonpath={.data.token} | base64 -d)
kubectl config --kubeconfig=flink-kubeconfig set-context default --user=flink --cluster=base --namespace=flink
cat << EOF | kubectl create -f -
apiVersion: v1
kind: ResourceQuota
metadata:
 name: flink-rq
 namespace: flink
spec:
 hard:
 limits.cpu: "20"
 limits.memory: 40Gi
 requests.cpu: "10"
 requests.memory: 20Gi
EOF

配置 flink 环境

登录工作服务器，将上述生成的文件拷贝到~/.kube/目录下，并更名为config，此外还需要满足以下依赖条件：

－该服务器需与目标集群网络内网互通－已安装kubectl工具－已安装 Java 版本 8 或 11（官方推荐）

修改/etc/hosts文件

sudo sed -i '$a 10.1.192.48 cls-xxxxxxx.ccs.tencent-cloud.com' /etc/hosts

安装 Flink 工具包

wget https://www.apache.org/dyn/closer.lua/flink/flink-1.12.0/flink-1.12.0-bin-scala_2.12.tgz
tar zxf flink-1.12.0-bin-scala_2.12.tgz
export PATH=$PATH:`pwd`/flink-1.12.0/bin

部署应用

构建 docker base 镜像

不依赖 flink 环境

git clone https://github.com/apache/flink-docker.git
cd flink-docker/1.12/scala_2.12-java11-debian
docker build -t alphajc/flink:1.12-scala_2.12-java11 .
docker tag alphajc/flink:1.12-scala_2.12-java11 alphajc/flink:1.12-scala_2.12
docker tag alphajc/flink:1.12-scala_2.12-java11 alphajc/flink:1.12-java11
docker tag alphajc/flink:1.12-scala_2.12-java11 alphajc/flink:1.12
docker push -a alphajc/flink # 需要先使用 docker login 登录 docker hub，alphajc 为我的账号

上述镜像现在可直接使用

制作 pyFlink 1.12 的 docker 镜像

不依赖 flink 环境

创建下述 Dockerfile 文件：

FROM alphajc/flink:1.12

# install python3 and pip3
RUN apt-get update -y && \
apt-get install -y python3.7 python3-pip python3.7-dev && rm -rf /var/lib/apt/lists/*
RUN ln -s /usr/bin/python3 /usr/bin/python

# install Python Flink

RUN pip3 config set global.index-url https://mirrors.aliyun.com/pypi/simple/ \
 && pip3 install apache-flink==1.12.0

构建并提交：

docker build -t alphajc/pyflink:1.12 .
docker push alphajc/pyflink:1.12

运行一个 python 的批处理程序word_count

依赖 flink 环境

flink run-application \
 --target kubernetes-application \
 --parallelism 8 \
 -Dkubernetes.cluster-id=word-count \
 -Dtaskmanager.memory.process.size=4096m \
 -Dkubernetes.namespace=flink \
 -Dkubernetes.jobmanager.service-account=flink \
 -Dkubernetes.taskmanager.cpu=2 \
 -Dtaskmanager.numberOfTaskSlots=4 \
 -Dkubernetes.container.image=alphajc/pyflink:1.12 \
 --pyModule word_count \
 --pyFiles /opt/flink/examples/python/table/batch/word_count.py

这是一个批处理程序，运行完就没了，可以使用kubectl get po -w持续观察 Pod 的变化：

自定义镜像创建一个需要连接 mysql 和 kafka 的流处理应用(test)

不依赖 flink 环境

git clone ssh://git@github.com:xxxx/flink_test.git # 克隆 flink 测试库
cd flink_test

创建下述的 Dockerfile 文件：

FROM alphajc/pyflink:1.12

ADD --chown=9999:9999 https://repo.maven.apache.org/maven2/org/apache/flink/flink-sql-connector-kafka_2.11/1.12.0/flink-sql-connector-kafka_2.11-1.12.0.jar /opt/flink/lib/
ADD --chown=9999:9999 https://repo.maven.apache.org/maven2/org/apache/flink/flink-connector-jdbc_2.11/1.12.0/flink-connector-jdbc_2.11-1.12.0.jar /opt/flink/lib/
ADD --chown=9999:9999 https://repo.maven.apache.org/maven2/mysql/mysql-connector-java/8.0.22/mysql-connector-java-8.0.22.jar /opt/flink/lib/

ADD --chown=9999:9999 examples_112 /app/flink_test

构建发布镜像：

docker build -t alphajc/flink_test .
docker push alphajc/flink_test

运行 test 应用

依赖 flink 环境

flink run-application \
--target kubernetes-application \
--parallelism 8 \
-Dkubernetes.cluster-id=test \
-Dkubernetes.container.image=alphajc/flink_test \
-Dkubernetes.namespace=flink \
-Dkubernetes.jobmanager.service-account=flink \
-Dtaskmanager.memory.process.size=4096m \
-Dkubernetes.taskmanager.cpu=2 \
-Dtaskmanager.numberOfTaskSlots=4 \
-Dkubernetes.container.image.pull-secrets=qcloudregistrykey \
-Dexecution.attached=true \
-Dkubernetes.container.image.pull-policy=Always \
--pyModule test \
--pyFiles /app/flink_test/test.py

一些提示＆一些坑

jobmanager 的日志中可以看到 jar 包有没使用成功

2021-01-05 02:00:00,510 INFO org.apache.flink.runtime.entrypoint.ClusterEntrypoint [] - Classpath: /opt/flink/lib/flink-csv-1.12.0.jar:/opt/flink/lib/flink-json-1.12.0.jar:/opt/flink/lib/flink-shaded-zookeeper-3.4.14.jar:/opt/flink/lib/flink-table-blink_2.12-1.12.0.jar:/opt/flink/lib/flink-table_2.12-1.12.0.jar:/opt/flink/lib/log4j-1.2-api-2.12.1.jar:/opt/flink/lib/log4j-api-2.12.1.jar:/opt/flink/lib/log4j-core-2.12.1.jar:/opt/flink/lib/log4j-slf4j-impl-2.12.1.jar:/opt/flink/lib/flink-dist_2.12-1.12.0.jar:::

缺少 kafka connector 插件

Caused by: org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'kafka' that implements 'org.apache.flink.table.factories.DynamicTableFactory' in the classpath.

缺少 jdbc 插件

Caused by: org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'jdbc' that implements 'org.apache.flink.table.factories.DynamicTableFactory' in the classpath.

缺少 mysql 插件

java.io.IOException: unable to open JDBC writer
at org.apache.flink.connector.jdbc.internal.AbstractJdbcOutputFormat.open(AbstractJdbcOutputFormat.java:61) ~[flink-connector-jdbc_2.11-1.12.0.jar:1.12.0]
at org.apache.flink.connector.jdbc.internal.JdbcBatchingOutputFormat.open(JdbcBatchingOutputFormat.java:114) ~[flink-connector-jdbc_2.11-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.api.functions.sink.OutputFormatSinkFunction.open(OutputFormatSinkFunction.java:65) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:102) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.table.runtime.operators.sink.SinkOperator.open(SinkOperator.java:63) ~[flink-table-blink_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.runtime.tasks.OperatorChain.initializeStateAndOpenOperators(OperatorChain.java:401) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.runtime.tasks.StreamTask.lambda$beforeInvoke$2(StreamTask.java:507) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.runtime.tasks.StreamTaskActionExecutor$1.runThrowing(StreamTaskActionExecutor.java:47) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.runtime.tasks.StreamTask.beforeInvoke(StreamTask.java:501) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:531) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:722) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:547) ~[flink-dist_2.12-1.12.0.jar:1.12.0]
at java.lang.Thread.run(Unknown Source) ~[?:?]
Caused by: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
at jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source) ~[?:?]
at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source) ~[?:?]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:?]
at java.lang.Class.forName0(Native Method) ~[?:?]
at java.lang.Class.forName(Unknown Source) ~[?:?]
at org.apache.flink.connector.jdbc.internal.connection.SimpleJdbcConnectionProvider.getConnection(SimpleJdbcConnectionProvider.java:52) ~[flink-connector-jdbc_2.11-1.12.0.jar:1.12.0]
at org.apache.flink.connector.jdbc.internal.AbstractJdbcOutputFormat.establishConnection(AbstractJdbcOutputFormat.java:66) ~[flink-connector-jdbc_2.11-1.12.0.jar:1.12.0]
at org.apache.flink.connector.jdbc.internal.AbstractJdbcOutputFormat.open(AbstractJdbcOutputFormat.java:59) ~[flink-connector-jdbc_2.11-1.12.0.jar:1.12.0]
... 13 more

记一次 IPVS 引起的 kubernetes 服务异常

Sun, 06 Dec 2020 17:14:02 +0800

问题描述

在我们的环境中，业务 A 会访问业务 B（也即 B 是 A 的上游服务），当 B 发版时，A 的请求偶尔会出现 timeout。现象看起来是流量路由到了已经不能提供服务的老的 pod 中。

问题处理

排查点一

当 pod 下线时，endpoint controller 未及时将 pod 从 endpoint 中取出，导致流量进入了旧的 pod。

由于集群 master 是托管部署的，所以我们没有办法查看相关日志和负载，求助于腾讯云的同时，自己这边也在排查。排查分两步进行，监控服务 B endpoint 的变化，同时滚动重启该服务。

监控 ep 变化

watch -n 1 kubectl -n production describe ep wk-dispatcher

重启服务

kubectl -n production rollout restart deployment wk-dispatcher

通过排查发现，跟 endpoint controller 并没有关系，因为 ep 变化很及时，加上至少 30 秒的优雅终止时间，基本可以确定在服务结束前，pod 是从 ep 中移除了的。

那不是这个原因，又会是什么原因呢？既然 ep 已经及时卸载了 pod，那是不是 kube-proxy 没有及时将相关规则改掉呢？

排查点二

kube-proxy 没有及时将相关规则改掉

虽然按照我的理解，这么长的优雅终止时间，怎么着规则都应该同步了才对，那可能同步时间加上请求处理时间超过了优雅终止时间，如果这样也还是有可能的，无论如何观察一下总是好的。

查看 ipvs 规则变化

CLUSTERIP=`kubectl -n production get svc wk-dispatcher -o=jsonpath={.spec.clusterIP}`
PORT=`kubectl -n production get svc wk-dispatcher -o=jsonpath={.spec.ports[0].port}`
watch -n 1 ipvsadm -Ln -t $CLUSTERIP:$PORT

同时也需要重启服务

kubectl -n production rollout restart deployment wk-dispatcher

这时候发现 ipvs 规则变化也很快（随着一些新的 rs 加入，老的 rs 的权重会变为0），虽然权重很快变为 0，但是老的 rs 并不会立即消失，直到 ActiveConn ＋ InActConn = 0，老的 rs 才会真正移除。

既然 endpoint 的变化和 ipvs 规则同步都很快，那问题极有可能出现在权重变为 0 到真正消失的之段时间。

排查点三

流量路由到了权重为 0 的 rs

带着这样的疑惑，我们找到了 TKE 团队。在 TKE 的指导下，我们查询了一下net.ipv4.vs.conn_reuse_mode，发现其值为 0。随后他们给了我们个关键 issue。

ipvs 相关内核参数的说明如下：

conn_reuse_mode - INTEGER

1 - default

Controls how ipvs will deal with connections that are detected port reuse. It is a bitmap, with the values being:

0: disable any special handling on port reuse. The new connection will be delivered to the same real server that was servicing the previous connection. This will effectively disable expire_nodest_conn.
禁用对端口重用的任何特殊处理。新连接将被传递到为先前连接提供服务的同一台真实服务器。这将有效地禁用expire_nodest_conn。

bit 1: enable rescheduling of new connections when it is safe. That is, whenever expire_nodest_conn and for TCP sockets, when the connection is in TIME_WAIT state (which is only possible if you use NAT mode).
NAT 模式下，连接处于 TIME_WAIT 状态时，新的连接请求将会重新调度而不再复用。

bit 2: it is bit 1 plus, for TCP connections, when connections are in FIN_WAIT state, as this is the last state seen by load balancer in Direct Routing mode. This bit helps on adding new real servers to a very busy cluster.

expire_nodest_conn - BOOLEAN

0 - disabled (default)
not 0 - enabled

The default value is 0, the load balancer will silently drop packets when its destination server is not available. It may be useful, when user-space monitoring program deletes the destination server (because of server overload or wrong detection) and add back the server later, and the connections to the server can continue.

If this feature is enabled, the load balancer will expire the connection immediately when a packet arrives and its destination server is not available, then the client program will be notified that the connection is closed. This is equivalent to the feature some people requires to flush connections when its destination is not available.

有关 ipvs 超时时间的说明：

ipvs default timeouts (900s for TCP, 120s for TCPFIN and 300s for UDP) are very high, especially in conjonction with conn_reuse_mode=0 (increased chances of bad port reuse). We can definitely decrease them but it’s not perfect.
The better option would be to set weight to 0 on backend removal from endpoint and delete the realserver when the pod is completely deleted, but this would require modifying the endpoint controller and the associated API.

原因分析

我们 kubernetes 节点机sys.net.ipv4.vs.conn_reuse_mode值为 0，ipvs 中，系统使用conntrack跟踪连接，conntrack使用三元组（即源IP、源端口、协议）定位具体连接，当客户端产生大量短连接时，其本身可能与之前的端口复用，而 TCP 在conntrack中的超时时间达 900s，也就是说conntrack中记录的连接可能存在很长时间，客户端过来的新连接极有可能复用老连接，此时已经 TIME_WAIT 的老连接无法响应请求，从而导致超时。可通过设置sys.net.ipv4.vs.conn_reuse_mode的值为 1 来解决，但这有可能引入一个一秒延时的问题。

最终解决

一秒延时问题:

当sys.net.ipv4.vs.conn_reuse_mode的值为 1 时，SYN 包到达conntrack时发现该连接处于 TIME_WAIT 状态，将会直接丢弃包，直至超时重发，这个时间大概一秒，打了补丁后包不会被丢弃而是在新进程中新建连接。

将节点的操作系统升级到打了补丁（解决一秒延时问题）的版本，同时将sys.net.ipv4.vs.conn_reuse_mode的值调整为 1。

使用LDAP的各种客户端进行统一身份认证

Sat, 30 Nov 2019 14:20:59 +0800

本文主要讲客户端的配置及部署，不含服务器，这里的一切都是以服务器端正确配置为前提的，有关内容后续会一步步完善，将包括 Linux 登录、gitlab、sonarqube、habor、nginx、pypiserver、verdaccio 等等。

Linux 篇

前提

一个或一组完备的 LDAP 服务端

步骤

在 linux 上配置 LDAP 认证其实有很多种方式，这里我仅挑一种我认为最简单的方式。以 CentOS 为例:

安装依赖

yum install libselinux-python nss-pam-ldapd -y

客户端配置
```
authconfig --enableshadow \
--disablesssd \
--disablesssdauth \
--enableldap \
--enableldapauth \
--ldapserver=LDAP_SERVER \
--ldapbasedn="BASE_DN" \
--enableldaptls \
--enablecache \
--enablelocauthorize \
--enablemkhomedir \
--updateall
```
注：将 LDAP_SERVER 替换为真实的地址，如果需要配置多个，则以半角逗号(,)隔开，确保 BASE_DN 为祖先结点，如我们的用户信息存在于ou=People,dc=example,dc=com下，用户分组信息位于ou=Group,dc=example,dc=com下，仔细观察会发现我们需要的认证信息都位于dc=example,dc=com下，所以dc=example,dc=com作为 BASE_DN 是个不错的选择。--enableldaptls视自己的服务端是否配了证书而定。
单独配置 sudo
```
cat << EOF >> /etc/sudo-ldap.conf
uri <LDAP_SERVER>
sudoers_base <SUDOER_BASE>
EOF
```
默认安装的 LDAP Server 中，没有 sudoer 的 schema，需要手动导入，真实配置了ou=SUDOer,dc=example,dc=com才会有效，并将<SUDOER_BASE>替换为ou=SUDOer,dc=example,dc=com。
配置命名交换文件

在文件中加入或者修改这么一行：
```
sudoers: files ldap
```
以确保在使用 sudo 权限的时候，ldap 会成为其验证来源

启动 nslcd

CentOS6

service nslcd start
chkconfig nslcd --add
chkconfig nslcd on --level 2,3,4,5

CentOS7

systemctl enable nslcd
systemctl start nslcd

使用 cert-manager 自动管理 tls 证书

Sat, 09 Nov 2019 08:49:39 +0800

http 协议是一个全明文传输的协议，不加任何处理的 http 报文将在因特网中裸奔，只要有人对监听你的报文，你所有隐私将被人一览无余。Let’s Encrypt 是一家免费、开放、自动化的证书颁发机构（CA），为公众的利益而运行。它是一项由 Internet Security Research Group（ISRG）提供的服务。本着想要创建一个更安全，更尊重隐私的 Web 环境的初衷，Let’s Encrypt 以尽可能对用户友好的方式免费提供为网站启用 HTTPS（SSL/TLS）所需的数字证书。

但是 Let’s Encrypt 颁发的证书有个特点，有效期只有三个月。这意味着我们需要频繁续期证书，倘若手动续期，无疑会增加运维成本。有什么方式可以为我们自动颁发证书吗？当然有！ACME 无疑就是我们的最佳选择。

有一款很好用的 ACME 客户端叫 Certbot，可以帮助自动颁发、续期证书。在 kubernetes 的生态中有没有什么好的工具能帮助我们非常方便地使用证书么？当然有，那就是本期主题——cert-manager。

cert-manager 是本地 Kubernetes 证书管理控制器。它可以帮助从各种来源颁发证书，例如 Let’s Encrypt，HashiCorp Vault，Venafi，简单的签名密钥对或自签名。它将确保证书有效并且是最新的，并在到期前尝试在配置的时间续订证书。

原理比较简单，本文就不讲了，主要谈谈来安装和使用。

安装

YAML 安装

创建 namespace
```
kubectl create namespace cert-manager
```
安装 crd 和 cert-manager
```
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v0.11.0/cert-manager.yaml
```
值得说明的是：在 kubernetes 1.15 以前的版本需要在执行kubectl apply时添加一个参数--validate=false，否则在创建 CustomResourceDefinition 资源时会收到与 x-kubernetes-preserve-unknown-fields 字段有关的验证错误。

helm 安装

依次执行下述命令：

# Install the CustomResourceDefinition resources separately
kubectl apply --validate=false -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.11/deploy/manifests/00-crds.yaml

# Create the namespace for cert-manager
kubectl create namespace cert-manager

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install \
 --name cert-manager \
 --namespace cert-manager \
 --version v0.11.0 \
 jetstack/cert-manager

确认安装

kubectl get pods --namespace cert-manager
NAME READY STATUS RESTARTS AGE
cert-manager-5c6866597-zw7kh 1/1 Running 0 2m
cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m

使用

创建 issuer

在建好 cert-manager 后，我们需要继续创建 issuer 才能颁发证书。有两种 issuer 可供我们选择：ClusterIssuer 和 Issuer，两都配置方式都是一样的，所不同的是作用域。ClusterIssuer，顾名思义是在集群中使用，作用域为所有命名空间，相对应的 Issuer 只作用于所在的命名空间。一般用 ClusterIssuer 比较方便。这里也通过 ClusterIssuer 举例。

证书的验证方式也有两种，一个是 http-01，另一个是 dns-01，由于 dns-01 需要域名解析服务商的支持，所以，在这里就没有使用了。有关这两种方式的详细说明参照 https://letsencrypt.org/zh-cn/docs/challenge-types/。

创建一个名叫letsencrypt-staging.yaml的文件，内容是：

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
spec:
 acme:
 # You must replace this email address with your own.
 # Let's Encrypt will use this to contact you about expiring
 # certificates, and issues related to your account.
 email: user@example.com
 server: https://acme-staging-v02.api.letsencrypt.org/directory
 privateKeySecretRef:
 # Secret resource used to store the account's private key.
 name: example-issuer-account-key
 # Add a single challenge solver, HTTP01 using nginx
 solvers:
 - http01:
 ingress:
 class: nginx

通过kubectl安装：

kubectl apply -f letsencrypt-staging.yaml

确保创建成功

kubectl describe clusterissuer letsencrypt-staging
...
Status:
Acme:
Uri: https://acme-staging-v02.api.letsencrypt.org/acme/acct/7571319
Conditions:
Last Transition Time: 2019-01-30T14:52:03Z
Message: The ACME account was registered with the ACME server
Reason: ACMEAccountRegistered
Status: True
Type: Ready

Let’s Encrypt 不支持通过 HTTP-01 的方式颁发通配符证书。要颁发通配符证书，必须使用DNS-01。

单独颁发

单独颁发证书，其实是一种手动的方式，一般不这么使用，但这却能加深我们对这整套流程的理解。颁发证书即创建并处理 Certificate 资源的过程。

有如下certificate-example.yaml文件：

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
 name: acme-crt
spec:
 secretName: acme-crt-secret
 dnsNames:
 - foo.example.com
 issuerRef:
 name: letsencrypt-stagging
 kind: ClusterIssuer

使用kubectl创建 Certificate：
```
kubectl apply -f certificate-example.yaml
```
注：这前提是域名得配置好了
静待 1-2 分钟：

执行下述命令，静待READY值变成True
```
kubectl get certificate acme-crt -w
```
错误排查：

如果整个颁发过程出现问题导致证书颁发失败，可以利用kubectl describe查看对应的 order 进行排查。order是一个订单，记录了这笔交易（虽然我们并未花钱），这可以告诉我们失败的原因。
```
kubcectl describe order acme-crt
```

指定 issuer 颁发

更多的时候我们不需要手动创建 Certificate，只需要在创建 Ingress 时作好对应的注释，cert-manager 就将自动为我们创建。对应的 yaml 文件大致是长这样的：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 annotations:
 acme.cert-manager.io/http01-edit-in-place: "true"
 cert-manager.io/cluster-issuer: letsencrypt-stagging
 kubernetes.io/ingress.class: nginx
 name: example
spec:
 rules:
 - host: foo.example.com
 http:
 paths:
 - backend:
 serviceName: example
 servicePort: 9000
 path: /
 tls:
 - hosts:
 - foo.example.com
 secretName: acme-crt-secret

这将自动创建一个与上一步骤中相同的 Certificate。

注：acme.cert-manager.io/http01-edit-in-place: "true"这明 http-01 验证将就在这个 Ingress 中进行而不会另行创建。

配置默认 issuer

在 cert-manager 的启动命令中加上这么两句：

--set ingressShim.defaultIssuerName=letsencrypt-stagging \
--set ingressShim.defaultIssuerKind=ClusterIssuer

这就为 cert-manager 设置了一个默认的 Issuer 了，设置成功后，我们就可以把 Ingress 资源中的cert-manager.io/cluster-issuer: letsencrypt-stagging改成kubernetes.io/tls-acme: "true"效果是完全一样的。

自动化运维之自动构建

Sat, 09 Nov 2019 08:32:31 +0800

版本说明

gitlab: 11.4.5
sonarqube: 8.0-community-beta
helm: v3.0.0-rc.2
sonar-gitlab-plugin: 4.1.0-SNAPSHOT
chart: 3.2.2

预处理

可用的 ingress controller
域名：确保对应的域名sonar.example.com 能够访问到 ingress
已经有 gitlab，并且配置好了一个全局可用的 Kubernetes 环境的 runner

安装 sonarqube

没有已经存在的数据库用于相关数据存取，所以在安装 sonarqube 的同时，还将根据依赖安装 postgresql。

自定义变量

进入stable/sonarqube，创建 custom.yaml 文件：

image:
 tag: 8.0-community-beta
ingress:
 enabled: true
 hosts:
 - name: sonar.example.com
 annotations:
 kubernetes.io/ingress.class: nginx # 选择指定的 ingress controller
 cert-manager.io/cluster-issuer: letsencrypt-stagging # 使用提前创建好的可用的 Issue/ClusterIssue
 acme.cert-manager.io/http01-edit-in-place: "true" # 颁发证书时依托原原有的 ingress 而不新建
 tls:
 - hosts:
 - sonar.example.com
 secretName: sonar-tls

persistence:
 enabled: true
 accessMode: ReadWriteOnce
 size: 10Gi

plugins:
 install: # 预装 sonar-gitlab-plugin 插件
 - "https://github.com/gabrie-allaigre/sonar-gitlab-plugin/releases/download/4.1.0-SNAPSHOT/sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar"
postgresql:
 enabled: true
 postgresUser: "sonar" # 供 sonarqube 的 JDBC 使用
 postgresqlUsername: "sonar" # postgresql chart
 postgresPassword: "pg-pass" # 供 sonarqube 的 JDBC 使用
 postgresqlPassword: "pg-pass" # postgresql chart
 postgresDatabase: "sonar" # 供 sonarqube 的 JDBC 使用
 postgresqlDatabase: "sonar" # postgresql chart

注：如上配置，由于国内访问 https://kubernetes-charts.storage.googleapis.com/ 时会存在困难，此处我直接将 postgresql 的 chart 软链到了 sonarqube 的 charts 目录下，省去了依赖安装的步骤，但由此带来的问题是版本配置的不兼容。为了兼容，同一配置出现了两个配置项，为了能够正常使用，不得不确保相同配置项的一致性。

依赖软链

mkdir charts
cd charts
ln -s ../../postgresql ../../mysql . # 虽然 mysql 没用上，但由于在 requirements.yaml 中存在也一并处理了
cd ..

helm 安装

helm install -g -n kube-public -f custom.yaml . # 此处使用的是 helm3

检测安装

证书是否颁发成功
```
kubectl -n kube-public get certificate sonar-tls
```
READY 如果为 true 的话说明证书颁发成功
检测服务是否可用

这有两种方式，一个是看 pod 是否为 ready 状态；另一个是看 svc 是否有对应的 endpoint。具体要根据 helm 部署的 release 的名字来看。
检测没有问题后，可以在浏览器中输入域名试一下。

配置

gitlab 配置

登入 sonarqube 系统，依次点击 Administration -> Configuration -> General Settings -> Gitlab

配置项

GitLab url

例如：gitlab.example.com
GitLab User Token
1. 登入 gitlab 系统，依次点击右上角头像 -> Settings -> Access Tokens
2. Scopes 勾选 api，Name随便填，点击Create personal access tokens即可创建。
3. 将复制好的 Token 填入。
Global template

对于 commit 的评论分为全局评论和行内评论，该配置项为全局评论设定模版，模板有多种方式，可参照全局配置。
Inline template

这个配置项为行内评论设置模板，具体配置可参照行内配置。

中文配置（可选）

登入 sonarqube 系统，依次点击 Administration -> Marketplace，搜索chinese，可以找到一款名为Chinese Pack的插件，点击install安装。

插件下载完成后会进入 pending 状态，这时需要如图所示点击重启。

注：安装所有插件都需要重启生效，重启时，正在进行的分析会停止。

编程语言插件

这个必须正确安装才能进行代码分析，同样是在Marketplace中进行安装，但凡语言组件会有一个LANGUAGES的标签，这需要根据自己代码的实际情况酌情安装。常见的有：

SonarJS
SonarJava
SonarPython
SonarGo
SonarHTML
SonarCSS
…

部分语言社区版是不支持的，如：SQL、C 等等

使用

由于我们是非 Java 项目，所以使用 SonarScanner。

sonar-scanner命令有三种配置方式：环境变量、命令行参数、配置文件。

环境变量——我所知道的环境变量有两个：SONAR_TOKEN的SONAR_HOST_URL，但在使用插件的时候，环境变量有坑，所以不建议使用，后面会提到；
命令行参数——可以定义和配置文件一样的配置，一些敏感或可变的配置项可以采用这种方式注入；
配置文件——分为全局配置文件和项目配置文件，容器环境中，一般不使用全局配置。推荐配置一些常规又繁琐基本不会改变的项。

示例：

下载示例代码：

git clone https://github.com/SonarSource/sonar-scanning-examples

在 gitlab 中创建 sonar-scanning-examples 项目:
- 确保 runner 可用
- 为 runner 配置好 values，也就是环境变量
  - PRIVATE_TOKEN，也就是Gitlab User Token
  - SONAR_TOKEN，需要在 sonarqube 控制台创建
    
    点击Administration -> Security -> Users，在此处为指定用户生成 Token
  - SONAR_HOST_URL，sonarqube 的地址

添加 .gitlab-ci.yml 文件

cd sonarqube-scanner
cat > .gitlab-ci.yml << EOF
stages:
 - quality

sast:
 image:
 name: sonarsource/sonar-scanner-cli:latest
 entrypoint: [""]
 stage: quality
 script:
 - sonar-scanner -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.gitlab.project_id=$CI_PROJECT_ID -Dsonar.login=$SONAR_TOKEN -Dsonar.gitlab.user_token=$PRIVATE_TOKEN
 only:
 - merge_requests
 - branches
EOF

提交代码

git init
git remote add origin git@gitlab.example.com/examples/sonar-scanning-examples
git add .
git commit -m "Initial commit"
git push -u origin master

查看效果

行内注释

全局注释

sonarqube 控制台列表

sonarqube 控制台详情

那些坑

sonar-scanner在使用环境变量SONAR_TOKEN的时候似乎存在问题，所以后来我是在命令行中使用的该变量
gitlab 的 token 在 sonarqube 控制台中的配置似乎并没有效果，我在实际使用sonar-scanner的过程中还需要再次配置
sonar-gitlab-plugin插件版本不对，起初用的4.0.0的版本，会报一个奇怪的错误，换了4.1.0-SNAPSHOT后，问题得到了解决

跨 VPC 部署 zookeeper observer

Sat, 02 Nov 2019 09:15:21 +0800

场景说明

某云提供商网络技术更新迭代，遗留下了基础网络和 VPC 网络两种网络架构，我们公司目前的服务器还大多都在基础网络中。我在新环境中搭建了 kubernetes 集群，并在上面部署了高可用的 zookeeper 集群。配置中心方案是一个全局方案，公司大大小小的项目陆陆续续都会上，为了便于维护与迁移，我们采用一套环境统一管理。此时，集群内的 zookeeper 已经由 helm 部署完成。

需求

一台已经安装了 docker 和 docker-compose 的位于基础网络服务器（作为 zookeeper observer，为避免单点故障最好备两台及以上)
已经安装好三个结点的 zookeeper 的 kubernetes 的集群

操作流程

1. 基础网络互通

这个步骤具体怎么做我就不提了，每个云服务商可能不同，但并不是什么难点。达到的效果就是将 kubernetes 集群所在的 VPC 和 observer 服务器可以互联互通

2. 向内网暴露 zk 集群相关服务

利用 statefulSet 会为每个 pod 生成的一个特殊的 label，为每一个 zookeeper 的 pod 建立内网 LB 类型的 Service。
这里有一个创建其中一个 svc 的例子：

apiVersion: v1
kind: Service
metadata:
 annotations: # 这里边是与云服务商强相关的一些配置，不具备通用性但仍然具有参考价值，这里需要配置不然默认是公网 LB
 service.kubernetes.io/qcloud-loadbalancer-clusterid: cls-xxxxxx # 确定 tke 集群
 service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxx # 确定子网
 name: zk0
 namespace: kube-public # zk 所在的 ns
spec:
 ports:
 - name: tcp-2888-2888 # 数据同步端口
 port: 2888
 protocol: TCP
 targetPort: 2888
 - name: tcp-3888-3888 # 选举端口
 port: 3888
 protocol: TCP
 targetPort: 3888
 selector:
 app: zookeeper
 component: server
 release: xxx
 statefulset.kubernetes.io/pod-name: xxx-zookeeper-0 # 有了这个其实其它 label 可以省略
 type: LoadBalancer # service 类型

创建完成后，可以通过命令查看 LB 的 ip 地址：

[root@VM_64_11_centos zookeeper]# kubectl -n kube-public get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
zk0 LoadBalancer 172.16.255.8 10.1.0.12 2888:30734/TCP,3888:30513/TCP 2d15h
zk1 LoadBalancer 172.16.255.66 10.1.0.13 2888:32569/TCP,3888:32718/TCP 2d14h
zk2 LoadBalancer 172.16.255.105 10.1.0.6 2888:32189/TCP,3888:30692/TCP 2d14h

EXTERNAL-IP 即为 LB 的 ip 地址，我们可以通过这个地址访问到对应的 pod 在 2888 和 3888 两个端口上提供的服务。记录下这三个 IP 地址，在配置 observer 的时候会用到。

3. 创建 observer 所需环境

根据上一步得到的 ip，创建配置文件。

mkdir -p /data/zookeeper/
cd /data/zookeeper/
cat > zoo.cfg << EOF
clientPort=2181
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/log
tickTime=2000
initLimit=5
syncLimit=10
maxClientCnxns=60
minSessionTimeout=4000
maxSessionTimeout=40000
autopurge.snapRetainCount=3
autopurge.purgeInteval=0
peerType=observer
4lw.commands.whitelist=*
server.1=10.1.0.12:2888:3888
server.2=10.1.0.13:2888:3888
server.3=10.1.0.6:2888:3888
server.4=localhost:2888:3888:observer
EOF

创建存储

docker volume create zookeeper_data
mkdir -p /var/lib/docker/volumes/zookeeper_data/_data/data/version-2/ /var/lib/docker/volumes/zookeeper_data/_data/log/version-2/
echo 4 > /var/lib/docker/volumes/zookeeper_data/_data/data/myid
chown 1000:1000 /var/lib/docker/volumes/zookeeper_data/_data/data/version-2/ /var/lib/docker/volumes/zookeeper_data/_data/log/version-2/

创建 docker-compose.yaml

cat > docker-compose.yaml << EOF
version: "3"
services:
 zookeeper:
 image: zookeeper
 ports:
 - "2181:2181"
 volumes:
 - "./zoo.cfg:/conf/zoo.cfg"
 - "data:/var/lib/zookeeper"
 exporter:
 depends_on:
 - zookeeper
 image: josdotso/zookeeper-exporter:v1.1.2
 ports:
 - "9141:9141"
 command:
 - -bind-addr=:9141
 - -metrics-path=/metrics
 - -zookeeper=zookeeper:2181
 - -log-level=info
 - -reset-on-scrape=true

volumes:
 data:
EOF

4. 启动 observer

docker-compose up -d

至此 zookeeper observer 已经启动

5. 为 observer 配置监控

思路：将集群外的 observer 以无 selector 的 service 的形式挂到 kubernetes 集群中，打好 label 供 serviceMonitor 匹配即可

创建文件 zk-ob-external.yaml

apiVersion: v1
kind: Service
metadata:
 labels:
 app: zookeeper
 release: xxx
 position: external
 name: xxx-zookeeper-external
spec:
 ports:
 - name: zookeeperxp
 port: 9141
 protocol: TCP
 targetPort: zookeeperxp
---
apiVersion: v1
kind: Endpoints
metadata:
 labels:
 app: zookeeper
 release: xxx
 position: external
 name: xxx-zookeeper-external
subsets:
- addresses:
 - ip: 10.104.170.174
 - ip: 10.104.42.205
 ports:
 - name: zookeeperxp
 port: 9141
 protocol: TCP

注意 label 要与对应 serviceMonitor 中 selector.matchLabels 匹配，端口名要一致

其它

超级管理员

在给 zookeeper 配置权限时，由于需要加密的缘故，很多新手都容易配错，配错后对应的结点就无法删除了。在 zookeeper 中并没有什么超管可以无视 ACL 删除结点，所以我遍寻 zookeeper 的超级管理权限不得法。想要无视 ACL 对 Zookeeper 数据进行操作，只需找一个 zk 服务在配置文件中加入skipACL=yes并重启服务即可，操作完成后记得注释掉这个配置并重启服务，因为没有 ACL 的 zk 很不安全。为了降低重启服务所带来的风险，建议在 observer 上进行该操作。

Kubernetes 中部署高可用的 Zookeeper

Sat, 02 Nov 2019 08:01:06 +0800

本文主要使用 helm chart 进行 zookeeper 的高可用部署。

环境说明

本文使用的是 TKE 托管环境，在该环境中安中了 cbs-csi 的 operator，为了方便持久卷备份，后文中的持久化存储会统一采用。CSI的解决方案在各种环境中都会有，我仅描述 cbs。

kubernetes 版本：v1.14.3-tke.4
helm 版本：v2.10.0（TKE控制台支持的版本）
按步骤安装好的 cbs-csi

值得说明的是 cbs 存储不可跨可用区挂载，默认情况下先建存储再建 pod 的方式无法满足生产需要，所以才引入的 cbs-csi。但在建立 storageClass 时要注意加入 volumeBindingMode: WaitForFirstConsumer 以保证 pod 完成调度之后再创建卷，从而使得存储不用影响 pod 的调度。sc 参考如下：
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
 storageclass.beta.kubernetes.io/is-default-class: "true"
name: cbs-csi-topo
parameters:
 diskType: CLOUD_PREMIUM
provisioner: com.tencent.cloud.csi.cbs
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
```
已经部署好了的 prometheus 的监控方案，包括 serviceMonitor 这样的 CRD

部署

下载 chart：

git clone git@github.com:helm/charts.git

确定部署参数：

部署时传参有命令行和文件两种方式，这里创建一个 custom.yaml 的文件，填入想要修改的变量

exporters:
jmx:
 enabled: true # jmx 监控
zookeeper:
 enabled: true # zookeeper 应用级监控
prometheus:
 serviceMonitor:
 enabled: true # 使用 serviceMonitor 作为 prometheus 的配置方案
 selector:
 release: monitor # 这需要与 promethus 的 serviceMonitorSelector.matchLabels 匹配，否则 promethus 无法获取该配置
persistence:
 storageClass: cbs-csi-topo # 符合需求的 sc
 size: 10Gi # zookeeper 持久卷的大小，视数据大小而定
image:
 tag: 3.5.6 # zookeepr 的镜像版本，从 https://hub.docker.com/_/zookeeper 选择自己需要的
# 如果以上这些参数还满足不也自己的需求，就在 values.yaml 中找

安装
```
helm install --namespace <NS> -f custom.yaml incubator/zookeeper
```
这会生成一个名字随机的 Release，解决了取名字的烦恼，也可以通过 --name 指定名字，如果是二次安装，环境对原来的名字形成了依赖，则需要指定原来的名字。

自动化运维之自动构建

Sun, 08 Sep 2019 18:37:36 +0800

本文供自己记录学习，我会尽量保证文章准确无误，但因本人水平有限，如果不幸产生任何错误，望读者不吝赐教。

浅析 gitlab-runner 相关配置

在 gitlab-runner 中每个 runner 都需要指定 executor，executor 有以下几种类型：

SSH
Shell
Parallels
VirtualBox
Docker
Docker Machine (auto-scaling)
Kubernetes
Custom

我们会将 gitlab-runner 部署在 kubernetes 集群中，所以此处选用 kubernetes 作为 executor。有关该 executor 的配置方式，在官方文档中有详细说明，此处就此次配置所需要的进行简单说明，其它的再视情况进行补充。

与其它类型的 executor 一样，kubernetes 也需要根据 gitlab 仓库的 url 和 token 对 runner 进行注册方可使用。注册后会有一个常驻的 pod （我姑且叫它 runner 服务端）对来自于 gitlab 的 pipeline 任务进行监听，当监听到有新的任务需要执行时，就会创建新的 pipeline 跑 .gitlab-ci.yml 上对应的job。所以 runner 服务端相关联的 ServieAccount 一定需要具备对应的 namespace 的 pod 的创建的权限。

配置一个 runner 有多种方式，包括启动参数、环境变量、配置文件等。这其中配置文件的功能最强，参数可配置项较环境变量稍多（或许它们具有相同的能力，只是我没有发现，如果你知道欢迎帮忙补充）。通过gitlab-runner help register命令我们可以找到所有的启动参数和环境变量，参数与环境变量之间的关系请参照参数与环境变量对照表。

runner 的集群中权限

前面已经谈到 runner 服务端在注册成功监听到新的任务后，需要以 Pod 的形式创建 Worker 对新对任务进行处理。这里我们需要考虑几种权限：Pod 的操作权限、Worker 镜像的拉取权限以及在 Worker 中构建镜像时对私有镜像的拉取权限。

Pod 的操作权限通过 kubernetes 中的 ServiceAccount 来实现，我们需要赋予对应的 ServiceAccount 对指定命名空间的 Pod 的操作权限，相关的参数有--kubernetes-namespace和--kubernetes-service-account以及他们环境变量的开关参数--kubernetes-namespace_overwrite_allowed和--kubernetes-service_account_overwrite_allowed。这里指定的 ServiceAccount 一定要在指定的 Namespace 中有 Pod 的操作权限，否则 gitlab 在跑 pipeline 的时候会报权限错误。有关 ServiceAccount 的权限配置是通过 RBAC 实现的，详情参照kubernetes 中 RBAC 认证的文档。

对于 Worker 镜像的拉取权限，一般都是在集群创建时预先配置好的，此处无需另行配置。而 Worker 中构建镜像时对私有镜像的拉取和推送权限是在 .gitlab-ci.yml中进行配置的，这里不要搞混。

runner 的持久化存储

runner 可以使用 hostPath 和 PVC 做持久化存储，跟 Kubernetes 中的概念完全一样。用法参照使用卷，参考配置如下：

concurrent = 4

[[runners]]
 # usual configuration
 executor = "kubernetes"
 [runners.kubernetes]
 [[runners.kubernetes.volumes.host_path]]
 name = "hostpath-1"
 mount_path = "/path/to/mount/point"
 read_only = true
 host_path = "/path/on/host"
 [[runners.kubernetes.volumes.host_path]]
 name = "hostpath-2"
 mount_path = "/path/to/mount/point_2"
 read_only = true
 [[runners.kubernetes.volumes.pvc]]
 name = "pvc-1"
 mount_path = "/path/to/mount/point1"
 [[runners.kubernetes.volumes.config_map]]
 name = "config-map-1"
 mount_path = "/path/to/directory"
 [runners.kubernetes.volumes.config_map.items]
 "key_1" = "relative/path/to/key_1_file"
 "key_2" = "key_2"
 [[runners.kubernetes.volumes.secret]]
 name = "secrets"
 mount_path = "/path/to/directory1"
 read_only = true
 [runners.kubernetes.volumes.secret.items]
 "secret_1" = "relative/path/to/secret_1_file"
 [[runners.kubernetes.volumes.empty_dir]]
 name = "empty_dir"
 mount_path = "/path/to/empty_dir"
 medium = "Memory"

在 runner 中构建镜像

在 runner 中构建 Docker 镜像有两种方式，最常见的是使用docker build命令，另一种是使用谷歌推出的kaniko。相较于docker build，kaniko无需 Docker Daemon 即可工作，因此 Worker 无需在特权模式下工作，这种方式不会挑战 Kubernetes 集群的安全性。下面将具体谈谈两种方式：

docker build

使用这种方式构建 Docker 镜像我们不得不为执行该 Job 的 Worker 开启特权模式，这会带来安全性问题。如果你对此不以为然的话，就可以进行接下来的步骤了。

尽管这种方式本身就是不安全的，但是如果做好以下几点，依然可以有效降低安全风险：

将特权模式的 runner 打上专用标签，仅供使用对应标签的 job 调用；
创建这种类型的 runner 服务端时，使用 Taint 标记 Node，告诉其它应用这个结点的污点，在部署 runner 或其它可以容忍这个安全问题的应用时设置对应的 Toleration。

这可以确保特权模式不被滥用，亦可对应用的安全性负责。

以特权模式运行的docker: dind容器会在2375/tcp端口上进行监听，我们可以通过 TCP 协议对 Docker 进行操作。

image: docker:latest

variables:
 DOCKER_HOST: tcp://localhost:2375 # 在 Kubernetes 中 service 会以 sidecar 的形式插到 Pod 中，同一 Pod 中的网络使用 localhost 访问即可
 DOCKER_DRIVER: overlay2

services:
 - docker:18-dind

before_script:
 - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY

build-master:
 stage: build
 script:
 - docker build --pull -t "$CI_REGISTRY_IMAGE" .
 - docker push "$CI_REGISTRY_IMAGE"

注：docker 宿主机的版本与dind的版本最好一致。比如我宿主机使用的18.03的版本，那么镜像就应该使用docker:18-dind，如果直接使用docker:dind会使用最新版本的 docker。我当时遇到的一个问题是在 dind 容器中只监听了2376端口，没有2375。2376端口是做了加密的，至少需要配置证书都能使用，2375端口不能正常使用，不知道是因为版本不一致，还是本来就只会监听2376，我看 Dockerfile 中，两个端口都有暴露，时间关系我就没有进一步细研了。当我换作docker:18-dind后，问题都解决了。

kaniko

用法如下：

build:
 stage: build
 image:
 name: gcr.io/kaniko-project/executor:debug
 entrypoint: [""]
 script:
 - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
 - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG

使用 helm 安装 gitlab-runner

使用 gitlab 官方 chart 库进行 gitlab-runner 的安装。因为官方的 chart 使用参数和环境变量注册 gitlab-runner，在使用上会有一定的局限性，可能需要一些修改才能进行高级配置。以下是使用官方 chart 部署 gitlab-runner 的步骤：

前提

安装了 tiller 的 kubernetes 的集群
初始化完成了的 helm 命令行工具

1. 添加 gitlab 官方 chart 仓库

helm repo add gitlab https://charts.gitlab.io/
helm repo update

2. 在 gitlab 代码仓库中找到 url 和 runner 的 token

3. 安装 gitlab-runner

我们可以通过参数以及配置文件的形式为 helm 添加自定义配置。该 Chart 的可配置项可以查阅官方库对于 values.yaml 文件的注释，这里把关键配置提出来说明一下：

gitlabUrl：gitlab 服务的地址，形如：https://gitlab.xxx.com；
runnerRegistrationToken：上一步中得到的 token；
rbac.create：我是没有遇到过没有 rbac 的 kubernetes 集群，所以记得一定填 true，否则创建出的 gitlab-runner 将无权对集群进行操作；
rbac.clusterWideAccess：如果涉及到在不同的 namespace 跑 job，设置为 true，否则置为 false（这只能操作同一 namespace）；
rbac.serviceAccountName：如果不设置默认使用 default，如果 sa 专用则建议另起一个名字，以避免 default 权限过大，其它用 default 的 pod 滥用；
runners.image：默认镜像，在 gitlab-ci.yml 中的 job 未配置 image 时将自动选用；
runners.privileged：一般在该 runner 需要跑 docker:dind 镜像时使用；
runners.namespace: Job 运行的 namespace；
runners.imagePullSecrets：在创建 job 时使用的镜像如果来自于私有仓库则需要配置该字段。注意使用前需要提前创建好对应的 secret；
runners.cache：如果要使用 runner 的 cache 功能，需要对此选项进行配置，不同的持久化方式配置不同，有些方式甚至需要对 chart 进行改造。

注：该 Chart 的多 runner 注册功能受限，对 kubernetes 的高级功能配置支持也有限，后期我将对这个 Chart 进行改造，使其支持。

浅析 `.gitlab-ci.yml` 相关配置

有关 .gitlab-ci.yml 更详细的配置参照官方文档，在此仅挑部分有特点的东西记录一下。

image 将确定 job 运行的环境，script 将在该环境中运行；
service 是环境的依赖，如docker:dind 一般以这种方式注入，具体在 kubernetes 集群中会以 sidecar 的形式与主环境放在一个 pod 中，所以如果 service 提供的是 socket 服务，在主环境中使用 localhost 即可访问；
注意 only/except 的高级用法，可以服务于多种场景；
使用 rules 对 job 进行合理控制；
environment 跟持续部署相关，主要用于前端项目；
cache 用于在多个 job 间缓存数据；
artifacts 将对指定文件（一般是编译产物）进行打包，并上传至 gitlab，供下载使用，这也会在界面进行展示，配合 dependencies 使用，可以在不同 stage 的 job 间进行传递；
使用 coverage 抓取测试覆盖率

配置 `.gitlab-ci.yml`

stages:
 - build

.build-common: &build-common
 image: docker:latest
 variables:
 DOCKER_HOST: tcp://localhost:2375 # kubernetes 集群中使用 localhost 访问
 DOCKER_DRIVER: overlay2
 services:
 - name: docker:18-dind # 匹配环境中 docker 的版本
 command: ["--registry-mirror=https://mirror.ccs.tencentyun.com"] # 这是我找到的在编译镜像时，配置镜像加速器的最好办法
 before_script:
 - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY

build-master:
 <<: *build-common
 stage: build
 script:
 - docker build -t "$CI_REGISTRY_IMAGE" .
 - docker tag "$CI_REGISTRY_IMAGE" "$CI_REGISTRY/$CI_REGISTRY_IMAGE"
 - docker tag "$CI_REGISTRY_IMAGE" "$CI_REGISTRY/$CI_REGISTRY_IMAGE:${CI_COMMIT_SHA:0:9}"
 - docker push "$CI_REGISTRY/$CI_REGISTRY_IMAGE"
 - docker push "$CI_REGISTRY/$CI_REGISTRY_IMAGE:${CI_COMMIT_SHA:0:9}"
 only:
 - master

build:
 <<: *build-common
 stage: build
 script:
 - docker build -t "$CI_REGISTRY_IMAGE:${CI_COMMIT_SHA:0:9}" .
 - docker tag "$CI_REGISTRY_IMAGE:${CI_COMMIT_SHA:0:9}" "$CI_REGISTRY/$CI_REGISTRY_IMAGE:${CI_COMMIT_SHA:0:9}"
 - docker push "$CI_REGISTRY/$CI_REGISTRY_IMAGE:${CI_COMMIT_SHA:0:9}"
 except:
 - master

修改 Git 的历史提交

Sun, 11 Aug 2019 16:29:00 +0800

现在工作生活中，基本都使用 Git 用作代码的版本控制。我们应该为自己的每次 commit 提供一个合理的 log，以让自己或其他开发者明白对应的 commit 都干了些什么，但有时我们不可避免地会出错，然后就需要修改某些该死的提交。我们大可以新建一个 commit 来干这个事情，但这对于有洁癖的我来讲实在太 low 了，也不利于代码维护。Git 作为一个强大的工具，当然有解决办法啦，下面就让我们来一起探讨该如何修改过去的提交。

环境说明

我这里有一个 git 项目，进行过 3 次代码提交，日志如下：

commit 5ae91d0efae757087386c0c4b80e660e97627d22 (HEAD -> master)
Author: Jerry Chan <jerry@mydream.ink>
Date: Sun Aug 11 20:04:43 2019 +0800
third commit
commit 6df839cab26ce48a561192933dc28c0d9fe302db
Author: Jerry Chan <jerry@mydream.ink>
Date: Sun Aug 11 19:57:46 2019 +0800
second commit
commit 61aa39cfbcbab89d8e0d44c03f01f65402bd20e6
Author: Jerry Chan <jerry@mydream.ink>
Date: Sun Aug 11 19:56:23 2019 +0800
fist commit

第一次，提交的时候我建了个文件test.txt，并写了一行内容：
```
这是我第一次不应该提交的内容，但是却提交了的内容。
```
第二次，我新建了一个文件test2.text，也写下了一行内容：
```
这是第二次提交的内容
```
第三次，我对前面两次创建的文件分别进行了重命名：
```
mv test.txt test1.txt
mv test2.text test2.txt
```

现在的问题在于我第一次就提交错了，正确的内容应该是：

这是我第一次原本应该提交的内容

操作步骤

我们要回到第一次提交去进行修改。因为第一次提交前没有提交，所以没有办法指定 commit 作为基来对第一次提交进行操作。此时，我们需要使用以下命令对第一次提交进行操作：

git rebase -i --root

此时，我们将看到如下信息：

pick 61aa39c fist commit
pick 6df839c second commit
pick 5ae91d0 third commit
# 变基 5ae91d0 到 64b66ae（3 个提交）
#
# 命令:
# p, pick <提交> = 使用提交
# r, reword <提交> = 使用提交，但修改提交说明
# e, edit <提交> = 使用提交，进入 shell 以便进行提交修补
# s, squash <提交> = 使用提交，但融合到前一个提交
# f, fixup <提交> = 类似于 "squash"，但丢弃提交说明日志
# x, exec <命令> = 使用 shell 运行命令（此行剩余部分）
# b, break = 在此处停止（使用 'git rebase --continue' 继续变基）
# d, drop <提交> = 删除提交
# l, label <label> = 为当前 HEAD 打上标记
# t, reset <label> = 重置 HEAD 到该标记
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . 创建一个合并提交，并使用原始的合并提交说明（如果没有指定
# . 原始提交，使用注释部分的 oneline 作为提交说明）。使用
# . -c <提交> 可以编辑提交说明。
#
# 可以对这些行重新排序，将从上至下执行。
#
# 如果您在这里删除一行，对应的提交将会丢失。
#
# 然而，如果您删除全部内容，变基操作将会终止。
#
# 注意空提交已被注释掉

注释里面写得很清楚，我们需要修改第一次提交，所以我们得将pick 61aa39c fist commit改成edit 61aa39c fist commit，然后保存并退出。

此时使用git status，我们可以看到如下内容：

交互式变基操作正在进行中；至 64b66ae
最后一条命令已完成（1 条命令被执行）：
edit 61aa39c fist commit
接下来要执行的命令（剩余 2 条命令）：
pick 6df839c second commit
pick 5ae91d0 third commit
（使用 "git rebase --edit-todo" 来查看和编辑）
您在执行将分支 'master' 变基到 '64b66ae' 的操作时编辑提交。
（使用 "git commit --amend" 修补当前提交）
（当您对您的修改满意后执行 "git rebase --continue"）
无文件要提交，干净的工作区

在这一步，我们需要把内容修改成我们想要的样子。将 test.txt 的内容改为：
```
这是我第一次原本应该提交的内容
```
暂存变更
```
git add test.txt
```

把暂存区中的内容变成自己想要的样子后，对本次提交进行修补

执行命令git commit --amend，我们将得到以下内容

fist commit
# 请为您的变更输入提交说明。以 '#' 开始的行将被忽略，而一个空的提交
# 说明将会终止提交。
#
# 日期： Sun Aug 11 19:56:23 2019 +0800
#
# 交互式变基操作正在进行中；至 64b66ae
# 最后一条命令已完成（1 条命令被执行）：
# edit 61aa39c fist commit
# 接下来要执行的命令（剩余 2 条命令）：
# pick 6df839c second commit
# pick 5ae91d0 third commit
# 您在执行将分支 'master' 变基到 '64b66ae' 的操作时拆分提交。
#
#
# 初始提交
#
# 要提交的变更：
# 新文件： test.txt
#

你可能需要修改日志，但如果不需要的话，保存并退出即可。

[分离头指针 3baa727] fist commit
Date: Sun Aug 11 19:56:23 2019 +0800
1 file changed, 1 insertion(+)
create mode 100644 test.txt

看到上面的信息后表示，我们对本次提交的更改就已经完成了。

我们得到满意的提交后，执行git rebase --continue，回到当前 HEAD 下。

注意

当我们做这种操作时，修改了的提交之后的所有的提交都会发生改变，我们必须确保这些提交没有正在被别人使用。如果你还有什么问题欢迎留言。

在 Mac 上使用 Docker 自带的 Kubernetes

Fri, 12 Jul 2019 20:23:13 +0800

Mac 安装 Docker 的方法不再赘述，很简单，官方下载安装即可。

安装完成后，kubectl的二进制文件就已经存在了。我们仅需要下载镜像，开启 kubernetes。

下载镜像

查看一下你的 Docker 和 Kubernetes 版本：

使用以下脚本，记得将镜像版本改成你所需要的🍁

#!/bin/bash

set -e
KUBE_VERSION=v1.10.11
KUBE_PAUSE_VERSION=3.1
ETCD_VERSION=3.1.12
DNS_VERSION=1.14.8
DOCKER_TOOL_VERSION=v0.4.12

GCR_URL=k8s.gcr.io
ALIYUN_URL=registry.cn-hangzhou.aliyuncs.com/google_containers

images=(kube-proxy-amd64:${KUBE_VERSION}
kube-scheduler-amd64:${KUBE_VERSION}
kube-controller-manager-amd64:${KUBE_VERSION}
kube-apiserver-amd64:${KUBE_VERSION}
pause-amd64:${KUBE_PAUSE_VERSION}
etcd-amd64:${ETCD_VERSION}
k8s-dns-sidecar-amd64:${DNS_VERSION}
k8s-dns-kube-dns-amd64:${DNS_VERSION}
k8s-dns-dnsmasq-nanny-amd64:${DNS_VERSION})

for image in ${images[@]} ; do
 docker pull ${ALIYUN_URL}/${image}
 docker tag ${ALIYUN_URL}/${image} ${GCR_URL}/${image}
 docker rmi ${ALIYUN_URL}/${image}
done

# 拉取 Docker 相关镜像
docker pull docker/kube-compose-api-server:${DOCKER_TOOL_VERSION}
docker pull docker/kube-compose-controller:${DOCKER_TOOL_VERSION}

执行该脚本，将从阿里镜像库获得所需镜像。

启动 Kubernetes 功能

打开 Docker 配置面板，请至少勾选 Enable Kubernetes 以开启 Kubernetes 服务。

开启片刻后，你将看到 Docker Engine 和 Kubernetes 同时处于running状态。

查看 Kubernetes 服务

输入kubectl get pods --all-namespaces，你将看到：

➜ ~ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
docker compose-74649b4db6-bjw57 1/1 Running 0 1m
docker compose-api-597cc7786b-vpnnk 1/1 Running 0 1m
kube-system etcd-docker-for-desktop 1/1 Running 0 2m
kube-system kube-apiserver-docker-for-desktop 1/1 Running 0 2m
kube-system kube-controller-manager-docker-for-desktop 1/1 Running 0 2m
kube-system kube-dns-86f4d74b45-n55kv 3/3 Running 0 2m
kube-system kube-proxy-dgwfm 1/1 Running 0 2m
kube-system kube-scheduler-docker-for-desktop 1/1 Running 0 1m

至此，你就可以尽情享受 Kubernetes 带给你的乐趣了🎉🌴🎉

在 CentOS7 上安装新版 Docker CE（使用国内源）

Fri, 12 Jul 2019 10:46:25 +0800

卸载老版本

$ sudo yum remove docker \
 docker-client \
 docker-client-latest \
 docker-common \
 docker-latest \
 docker-latest-logrotate \
 docker-logrotate \
 docker-engine

如果曾经安装过，/var/lib/docker/中会有原来的镜像、容器、卷以及网络残留，如果不需要可将之一并删除。

安装 Docker CE

安装 Docker 国内源

安装 yum 配置管理工具

$ sudo yum install -y yum-utils \
device-mapper-persistent-data \
lvm2

安装清华大学的 Docker 安装源（本网站有效，该命令就有效）

$ sudo yum-config-manager \
--add-repo \
https://mydream.ink/utils/container/docker-ce.repo

你可能会遇到如下问题：

 adding repo from: https://mydream.ink/utils/container/docker-ce.repo
grabbing file https://mydream.ink/utils/container/docker-ce.repo to /etc/yum.repos.d/docker-ce.repo
Could not fetch/save url https://mydream.ink/utils/container/docker-ce.repo to file /etc/yum.repos.d/docker-ce.repo: [Errno 14] curl#60 - "Peer's Certificate has expired."

出现该问题一般是由于本地时间不正确（经常挂起的虚拟机很容易出现），使用date命令核对一下时间即可，若确认是这个问题，则：

$ sudo ntpdate pool.ntp.org # ntpdate 可使用 yum install ntpdate 进行安装

安装 Docker CE

安装最新版的 Docker CE
```
$ sudo yum install docker-ce docker-ce-cli containerd.io
```
如果弹出导入 Key 的问题，请接受
镜像加速

新建或修改/etc/docker/daemon.json，加入：
```
{
 "registry-mirrors": [
 "https://dockerhub.azk8s.cn",
 "https://reg-mirror.qiniu.com"
 ]
}
```
一定要确保格式没有问题，否则 docker 无法启动，修改完成后执行以下命令：
```
$ sudo systemctl daemon-reload
```
启动 Docker
```
$ sudo systemctl start docker
```

卸载 Docker CE

卸载安装包
```
$ sudo yum remove docker-ce
```
如果你觉得曾经的数据没用了，就一并删除吧
```
$ sudo rm -rf /var/lib/docker
```

初尝创业

Mon, 01 Jul 2019 17:58:19 +0800

本文记录了自己的个人生活经历及其感悟，以回忆为主，文中所有姓名均为化名，无心对任何人或者是公司造成影响，如果可能发生，请联系我进行修改

正如我告诉别人的那样，我也这样告诉自己：我从未怀疑过这辈子可以取得成功，不过同时我也非常清楚的是成功之路将充满坎坷与艰辛！

尝试

上一份工作于我而言确实是一个比较大的打击，我会因此感到郁闷，但很快也就过去了『👊沉浸于过去的悲痛是无能的表现』。对于实现自己的梦想，我最初的想法是，先认真工作几年，工作过程中多少会认识些志同道合的伙伴，然后就可以一起去做一些了不起的事情了。然而，两份工作都始终没有发现一个这样的伙伴，我觉得我快失去前进方向了，我特别好奇到底是哪里没对。因此，我特想看看自己离梦想有多远，现在好了，都不用选择就可以离开舒适区了。而这一次的尝试，无论结果如何，都是一种收获：要么创造奇迹，要么认清自己。

我是一个山里长大的孩子，泥巴就是我从小到大的玩具。深耕互联网，心系乡土情，我觉得利用互联网促进我国小农经济发展像是我的一种使命。我认为，农者，国之根本也。有关该项目详情就不在此赘述了，相关资料有点多。

创业，一个感觉上多么超凡脱俗的名词啊。它因大多数人不愿企及而神圣，然只有亲历者才知其艰辛，我曾想象过前路坎坷，但未曾想到还未出发便遭遇阻力。追逐自己的梦想本是一件无可厚非的事，但创业似乎就成了一件千夫所指之事。亲人、朋友、爱人，不是所有人都能理解你的雄心壮志，更不是所有人都支持你的所作所为。在这条道路上，我最先感受到的是孤独，所以，拥有战友在我看来是件多么可贵的事。

我妈妈是残疾人，老爸能力有限，而我是祖上五代往下数第一个大学生。可以想象他们是经历了怎样的艰辛才把我送进大学校园，读的几乎最贵的软件工程专业。当辛苦供养出来的大学生决定创业时，妈妈便再也坐不住了。她不求我大富大贵，但求我一生顺遂，所以每次电话都无法抑制住内心的恐惧😢。

然而，为了自己的梦想，背负着父母的期待和女友的等待，我还是自私地出发了。我知道我除了自己什么都没有，所以目标也比较明确，边寻找创业伙伴，边打磨自己的 idea，只要找到战友，我就有理由相信这件事情能成。一方面，我开始不断地参加各种线上线下的交流活动，想尽可能地去认识一些以梦想为轴的人，希望能够找到合适的创业伙伴；另一方面，与各行各业的朋友交流我的想法，在此过程中，我们经常发现项目中还有很多缺陷，所以，找到问题并提出相应的解决方案，便成为了那时候我最为享受的事了。为了得到政策支持，我曾多次拜访省农业厅，给他们出示并讲解我的计划。为了更了解这个行业，我曾跟种植大户深入交流。

每日醒来沐浴着清晨的第一缕阳光时，我会觉得一切都充满了希望，因为梦就在前方，不过很快又会回到现实中打滚。当事情毫无进展时，我会非常怀疑自己，偶尔还能和上妈妈“不怀好意”的问候，让自己切实体会一把什么是在夹缝中求生存。为了检验一下我想做的东西是否是伪需求，也为了证明自己还活着😱，我学着做了款微信小程序并给种子用户进行试用。为了给自己找个伙伴，我几乎去了活动行和 Meetup 上所有免费的活动。不放过任何机会的我还在国内外各大专业论坛和职场交友网站发帖，希望能求得一志趣相投的伙伴，还因为这个天真的行动被诸多网友讽刺得不要不要的，不过还好我有心里准备。很快，为梦想而努力的那种快感生生地被淹没在了现实的残酷之中。因为寻找创业伙伴的事情，一直没有进展。

三月中旬，我偶然发现有人曾引用了我关于梦想的描述，莫非是有『共鸣』之人？此人35岁，传统行业人士，不懂技术，却是一个足以让我感到热血沸腾的人。我把自己的项目放在一边，加入了他已经有了一定投入的项目；我把他的项目看做自己的，帮他重写之前的商业计划书，并作为技术负责人验收、整理他曾外包出去的项目，我在 Github 上建了个组织，现在还管理着他的项目呢。自始自终，我从未提过利益分配的问题，这源于我对于一个热血团队的渴望。然而，跟他共事了一个月之久，我居然摸不透他哪句话是真哪句话是假，所以我最后还是选择了离开。

重新回到了一个人，此时，我已经深刻地明白，想要通过这样的方式在短时间内找到创业伙伴根本就不可能了。『路遥知马力，日久见人心。』很真实的一堂课，且不说，满足自己期望的人少有，就算是有也不会是通过三两次的吃饭、聊天或者喝茶结交的。所以，后来当同样的机会摆在我面前的时候，我拒绝了。没有人脉、没有伙伴也没有金钱，我缺乏了太多的资源了。最终，我认清了我自己，积累资源成为了我所能够倚仗的唯一途径。

抉择

之前想要不计一切后果去创业的时候，认为自己本来也都一无所有，所以也不怕失去什么。可真正走到那一步时，我才发现我有亲人、有爱人，发现我除了梦想，还有一份责任。我在做任何决定的时候也必须为他们考虑些什么。我有责任让我的父母不再为我操心，也有责任许我女友一个美好的未来，一个真正成功的男人应当学会责任与梦想一肩挑。创业是一辈子的事情，我无需急于这一时，我本来起跑线就落后了别人一大截，更应该先积累一定的社会地位，也不至于让父母为我操心、让女友为我等待。既然已经认清了自己的方向，那就应当坚定不移地走下去。如何积累资源便成为了我首先需要考虑的问题。

『不积跬步无以至千里』

我曾考虑过很多种未来的可能性，最终还是认为从技术做起才是最适合我的。如今，我也为此正准备着。💪💪💪

第二份工作

Mon, 01 Jul 2019 17:56:50 +0800

找工作

为什么这段经历要从找工作说起呢？我主要是回忆起了那时候的彷徨与迷茫。从上一家公司离职后，我有点不知所措。就像我之前所诉一样，我不知道我能够匹配什么样的工作，明明感觉自己充满能量，但又觉得前路黯淡。

我明白我的特点是技术广度、快速上手能力以及发散性思维，其实这样的特点在什么岗位都是比较实用的，这在解决问题上是一把好手，不过这样的能力很难通过面试发现，我需要突出这一点。

我一共找了两周的工作，根据先前的工作经验，我是 Node.js 开发、项目经理、运维开发的综合体😕，这太难了😂。不知道是简历写得不好还是履历本来就不够吸引人，或许两者都有吧，我鲜有面试机会。正当我要放弃找工作打算先疯狂学习一阵做几个开源项目再找的时候，七陌电话邀我去面试。跟我约的时间是周五（也就是那两周的最后一个工作日），所以我就抱着最后试一试的心态去了。

这原本是一个运维岗，去了以后我从面试官也就是运维总监那里得知他们的业务越来越复杂，正在向微服务转型，当时差不多已经拆成有大大小小 60 多个服务，在考虑上容器了，甚至考虑为此组建一个部门。听到这个后，我显得比较兴奋，因为这正是我想做的事。我也表明了我的态度：“如果让我来做这个的话，我愿意一试，并且我有信心做成。”。公司的 CTO 张总正在做容器化相关的调研，他对于这方面比较了解，所以面试官拨通了张总的电话，让他对我进行专业的面试。我们互相都比较满意，所以没过多久我就得到了 HR 的通知。

新的起点

之前的公司10个人，新公司有200多人，从规模上讲，已经翻了好几倍了。现在还记得面试时，让我填的「职业生涯规划」，我有很认真的填写我要成为部门 Leader，结果我的部门就两个人，从编制上讲，还挂靠在别的部门😐。我心想我现在也刚进，以后肯定会招人的，先把自己事情做好就行，所以也就没想太多了。

带我的人叫石冷，我去之前，架构部门就他一个人，因此他一向比较忙，平日里都戴着个耳机也不多话，我找他基本都是发 QQ 消息😓。为了快速融入到公司环境中，借着团建做主持的机会，我用了不到两周时间就把成都分公司这边近80号人都认识了。

容器化方案

这是我在这个公司最重要的事，至少在进公司前我都是这么认为的。刚进去那会儿，不了解公司业务、不了解公司组织架构、不知道测试环境、不知道开发环境、不知道生产环境，总之是啥都不了解，石冷不爱说话，也从不安排任务，所以我基本上是被晾在那儿了😁。不过没有状况本身也是一种状况，我能做的就是在不浪费时间的前提下尽可能独立解决问题。首先认清目标，我来公司的目的就是出具并实施容器化解决方案的。

然后，我给自己设立了阶段性目标：

理清公司微服务架构的业务逻辑「我的天，60多个服务，分别是干啥的，他们之间如何协同工作的，没有文档，也不清楚」
学习 Docker、Kubernetes 相关技术「以前用的容器是 Zone，虽然接触过这俩，但并不多，想根据其能力出具解决方案还差远了」

针对第一点，我必须问，有时候会不好意思，但也不得不问，因为那是我开展工作的必要条件。至于第二点，翻阅官方文档进行学习，为此我还找石冷要了3台测试服务器。整个进展都比较顺利，我估计花了一个月的样子就出具了第一套过渡方案。主要策略是将原系统的中 Consul 和 Kubernetes 中的 etcd 的服务注册与发现的能力以及配置能力进行同步。我跟石冷讲了这个方案，他觉得还不错，我们就正式跟领导层进行了一场方案探讨的会议。可是，张总认为公司大部分研发人员连 Docker 都不了解，如果直接把 kubernetes 用起来有点太重了，难以落地，所以予以否决了『张总的考虑确实有道理，不过我觉得一个好的架构对于研发人员来讲应该是无觉察的，不知是否应当如此？😀』。尽管方案并没有落地实施，公司管理层对我的能力还是予以了充分肯定。

此事过去后不久，公司把我和石冷分别临时下放到了运维部和云客服部，说是让我们能够更好地了解业务以便设计出更接地气的架构。

去了庞然（运维部经理）那儿后，帮他协助私有云部门为私有云客户部署基础服务「MongoDB、Redis、Elasticsearch、Consul、Open office、Solr」，他们之前本来是脚本部署的，还要拷贝好多文件，特麻烦。为了简化流程，我把它们全部抬到了 Ansible 上来，感觉舒服多了「技能库里又多了件宝贝，开心😄」。本来待满一个月我就要回架构部了的，张总突然找到我说私有云部门的阿伟离职了，人手不够需要我，并且那边容器化方案更容易落地。于是乎，我就成了私有云老大湛成的手下。

去到私有云

私有云部门是一个业务部门，主要是为大客户提供自建云客服系统以及可能存在的定制开发服务。私有云项目从服务器批下来到最终完成交付大致会经历 PoC 测试和定制开发（如果需要）两个阶段。所以私有云下又有实施和开发两大模块，服务器给到公司后，会先由运维团队搭建基础服务（也就是我之前在庞然的团队所做的事情），然后由我部门实施人员搭建业务服务并做基本调通，没有问题后移交技术支持与售前。阿伟走后，湛成成了唯一一个具有实施能力的私有云成员，但私有云的工作量不降反升，所以这才把我调了过去。湛成来了成都后，组建实施团队便成了我的任务之一。最终我招募了两位小伙伴，并带他们参与实施工作。实施过程中最难的地方莫过于调通了，像 Consul、Nginx、MongoDB 都很容易出问题，有时调试时，需要用到各种前后端的编程知识，也只能自己去解决。

我们部署项目需要两个自主开发的部署工具：

vole —— node 编写的 Web 工具，用于录入配置并生成配置文件
lever —— python 编写的命令行工具，依赖于 Ansible，用于部署业务服务

两个工具都还有这样那样的问题，功能也不全，可能也就支持20来个服务吧。将实施任务交给两个新伙伴后，我开始了两个部署工具的改造之旅，我新加了些项目支持，修复了一些 BUG，甚至还改了下界面，也正是因为在这里更加真切地感受到了这些痛点问题，使得我对于容器化的解决方案又有了一些新的想法。在湛成的支持下，我又开始了我的容器化之旅。我还是用的 Kubernetes，不过这次我落地实施了。我用双容器 Pod 捆绑 Nginx 解决了程序中访问服务写死 127.0.0.1的问题，并用 Endpoint 直接挂载 Kubernetes 集群以外的 Consul 服务和由 consul-template 渲染出来的 Nginx 代理服务；利用 namespace 解决了环境区分问题；利用 Configmap 解决了每个服务的配置问题；利用 secrets 解决 tls 证书存储问题；利用 Ingress 解决了外部访问的问题，同时有一种非常方便的方式添加或删除 tls 证书；利用「nfs provisioner」 + storageClass 解决共享存储的问题。最后，我将60多个服务编成镜像放到 Harbor 仓库中，利用 Helm 将所有服务加到一个 application 中，解决批量布署的问题（以前部署一套环境两天，我将其缩短到了两分钟）；利用 Telepresence 解决了远程调试问题。不用修改一点代码就将服务布署到了 Kubernetes 集群中。

这60多个项目，大多都是老项目，代码用 SVN 管理的，我没有 SVN 的管理权限没有办法添加 hook，所以我将所有项目都迁移到了 gitlab 上，利用 gitlab-runner 进行 CI/CD，自动化编译和部署，好不方便！新版的 gitlab 对 DevOps 支持就更好了。

公有云那边项目越来越多，再加上公司跟腾讯加强了合作，需要在除阿里云外的腾讯云上再建一套云客服系统。这时候石冷那边一个人忙不过来了，而我在私有云的事情基本告一段落了，于是湛成问我，要不要考虑回去，那里更能体现我的价值，于是乎，我又回去了。「😑老天仿佛跟我开了个玩笑，绕了一圈我又回到了这里」

回到架构部

回到架构部后，除了日常维护私有云团队的 Kubernetes 集群外，我还做了3件事：

开发 MongoDB 迁移工具；
为日志管理系统开发新的功能；
设计开发平台管理系统。

离开

是的，我确实有想要离开的想法，在一个公司来回折腾了几个部门，最后又回到了原来的地方，直到我离开之前，石冷还告诉我，等架构部门的事情做完后，我有计划被调到运维部去和庞然一起调研负载均衡方案。能被组织需要本身是一件特别幸运的事情，但我失去了归属感，觉得这可能与我职业生涯规划的理念相悖。当然了，公司有公司的想法，这本就无可厚非，只是公司在面试时问我要了而我也给了我的职业生涯规划，我觉得这在人事调动的时候还是可以稍微考虑一下的。

尽管我没有跟任何人讲过，并且很长一段时间我也不愿意提起，但我当时并非完全自愿离开的。

公司的代码库做了防火墙，直接锁死只有公司的 ip 能够通过公网进行访问，开发人员如果想在自己家中提交代码，就必须连上 VPN，并且在 git 项目中修改 git 仓库的 url，使用内网地址进行访问。我想到了一个解决办法，就是如果连上 VPN 后，访问 git 的公网 ip 走 VPN 服务器那条线，那就可以合理避免开发人员频繁修改仓库 url 的操作了。VPN 服务器在有客户端连接时，会将路由策略分发至各客户端，客户端根据该策略设置路由，只需要在路由分发上添加一条记录即可实现。我将我的想法进行了测试，保证确实可行没有问题后，我便添加到了 VPN 服务器上。我正为又解决了开发人员一大痛点而感到满足时，公司群里在讨论生产环境服务连接中断的问题。时间有点太凑巧了，但我一直觉得不可能是我的操作导致的，因为我操作的是开发环境的 VPN 服务器啊😳。

整个故障持续了一个多小时。由于我在操作前有向上头报备，运维总监很快找到了我，真是不敢相信😮。那时我才得知，原来生产环境的每一台服务器都连接着开发环境的 VPN，这还不算完，VPN 上 ip 地址分配策略居然跟阿里云的 ip 分配策略是冲突的，所以生产环境上的每一个 ip 地址都是根据阿里云的 ip 分配策略手动分配的，也就是说，ip 如果发生变动将导致网络紊乱😫。我知道了事情发生的详细情况，意识到自己踩了雷，便也不做辩解，当即表示愿意接受任何处罚。

第二天，我发现我所有公司账户都被冻结了，我就大概知道结果了，老实说我并不甘心。在结果下来后，我告诉了湛成，挺对不起他的，因为我很多工作都跟私有云部门亲密合作，很多计划将因此破产，让大家的心血付诸流水，当时也还在帮他做一个运营管理平台的框架搭建，因为我的离开这个项目也搁浅了。

下脚前，没有注意到那个位置有雷，我确有失察之过，假如我在决定操作或在重启 VPN 服务前，认真检查一下跟服务器连接的客户端分别是什么用途，也许就能避免了。为了走得体面一点，我甚至没有要一丁点的赔偿，而选择自愿辞职，若非今日忆起，我可能不会跟任何人讲。走的那天，张总给我来了个电话告诉我：“这件事情你本没有错，怪只能怪你运气不好，埋雷的人是公司创始人，他犯了天大的错，我们也只能削减他的股份，不可能让他走人，只是公司必须给客户和全体员工一个交待，牺牲你是一个让人心痛却又不得不做的决定。”听他说这些，我姑且就相信了吧，毕竟这能让自己心里好受些。后来，运维总监在微信里跟我也说了差不多类似的话，让我不要记恨公司。

心高气傲的我，曾经想象过多种离开的方式，唯独没想过会这样。一个人骑着自行车走在成都的大街上，明明灯火通明，却感觉漆黑一片，眼看着就要过年了，这时候失去了工作，我不知道我该如何告知我的家人、朋友还有我的爱人，也不知找下一份工作时，如何告知面试官我曾被选择😲。

或许，我真应该像我要离开时石冷告诉我的那样『决不做非自己职责范围内的事』吧？不过我真正学到的是，不管做什么样的事不可盲目自信，应当做好万全的考虑，以后无论做什么，我必将更加小心慎重。我还是那个我，初心不改，但挫折必将让我学会成长。如今，我不愿逃避，将此事记录下来，正视自己的错误，愿意面对并承担由此带来的一切后果。『👏我相信』

第一份工作

Mon, 01 Jul 2019 17:56:47 +0800

初入创业公司

公司原本只有三个人，我本以为他们三个是联合创始人，但到后来我发现创始人只有朱总一个。朱总曾先后在多家大型外企工作（我记得的就有惠普和甲骨文），有很多年的技术经验，在「去 IOE」的大背景下，希望基于 PostgreSQL 研发自主可控的国产数据库。CTO ——范畴，在华为研究所里开发了多年的缓存，后来去过中东做市场，也是一个非常有想法的人，最初也是他找到了我。另一个叫何敏，2012年西安电子科技大学毕业，原本供职于深圳国家电网，在那里做 C#，因为公司数据库选型和朱总结识。除了他们，其他人都跟我一样，是应届大学生。除了前端的邵梦，我们都是 C 语言开发入职的，按照最初的计划，进公司后是要从事数据库开发的。

范畴为我们进行了为期数日的 C 语言岗前培训，同时，朱总还为我们进行了数据库相关知识培训。老实说，那段时间学到了蛮多东西。公司有个项目叫 EcoX，是朱总以前用 Perl 脚本写的 PostgreSQL 高可用集群管理系统，因为要商用，所以范畴那段时间一直在用 C++ 重新实现。那时候公司还没有任何基础设施建设，他维护代码特别麻烦，所以让我给解决一下。svn、samba、ldap，这些我以前听都没听过的东西，也还包括一些其它基础服务，我都给搭了一遍。当时我本来想推荐 git 而不用 svn 的，但是我那时项目做得少，最多也就是用过 Github，没有其它解决方案，索性也就搭的 svn。直到后来在西科大做了很多项目的研究生建平过来带来了 gitlab 的解决方案，我们才正式使用 git 的。不得不说，那确实是个好东西，直至今日我做自动化运维还用它✨✨✨。

鸿鹄系列

我们的数据库称作 鸿鹄数据库，PG 是 OLTP 的一把好手，为了丰富应用场景，使其更好地支持 OLAP ，他第一步想要做的是加入列存。自主研发数据库门槛特别高，然而我们都是新人，大多数人连数据库原理都不懂，这可如何开始？我给范畴推荐了「中国大学 MOOC」上哈工大战德臣教授数据库系统的系列课程，这是我当时备战秋招的时候学过的，觉得还不错，后来他也在上面学习，还推荐给了大家。只是可惜的是，我后来一直没有在做数据库。

刚进公司那会儿，公司有三台服务器（两台二手 hp，一台华为），我们自用的服务器都是从华为那台虚拟出来的。宿主机是 SmartOS 系统，它支持多种虚拟化技术：zone、基于 zone 改造的 lxc 以及从 linux 移植过来的 KVM ，前两种就是我们当前总在讲的容器化技术，使得运行在上面的应用有可以利用裸机的 IO 能力，在传统虚拟化技术面前有着非常大的优势。而支持 KVM 可以让用户将原本运行在虚拟机中的服务迁移过来；其次，SmartOS 原生支持 ZFS 文件系统。ZFS 作为最先进的文件系统之一，自带存储解决方案，服务器上的磁盘甚至不需要做阵列。这种技术特别适合数据库这种对 IOPS 要求很高的应用。朱总希望将其改造成自主可控的国产数据中心产品，所以做一个管理系统将这种能力管理起来成为了我们另一个项目，后来朱总给它取名叫 鸿鹄彩云「😅老实说，我对这个名字存有保留意见」。

数据中心国产化之路

由于数据库产品的门槛实在过高，「鸿鹄彩云」便成为了我们的当务之急。范畴主要负责架构设计，我和常齐负责技术选型。因为采用 SOA 架构，所以选择一种较为合理的服务间通信方式是我们技术选型的头等任务。我们决定消息队列直接采用 OpenStack 在用的 RabbitMQ；Protobuf 以二进制流方式进行网络传输，作为序列化技术远比 XML 和 JSON 的效率高，只使用相对复杂，基于 Protobuf 的 gRPC 还是 Beta 版本，当时我们还在考虑要不要采用来着😯。因为大家都是新手，所以也没做什么详尽的测试，就都用了一下。不过，很快事情就变得不一样了。

某天，朱总跟我演示了一样东西——Triton「Joyent 旗下的数据中心产品」，它基于 SmartOS「SmartOS 也是 Joyent 公司的产品」，它拥有几乎所有我们想要的功能，并且还经市场检测过的。没经过太多犹豫，我们就放弃原来的工作，一门心思放到了 Triton 上来。这是一个开源产品，我们计划先进行界面改造，然后再深入底层开发，实际上我们也这么做了。adminui 这是一个纯前后端分离的项目，但是我们前端开发只有一个，还是一个新手，所以我们连学带用的也加入到了前端开发的阵营。为了简化开发测试流程，我利用 gitlab runner 建了一套自动化运维系统，用以实现持续集成和持续部署。最后完成了一个 1.0 版本，只是确实有点丑😰。

朱总应该发现了效果不怎么好，所以又找了一个有经验的前端开始 2.0 版本的开发。由于一直以来我表现都非常突出，加之强烈的责任心，因此深受朱总信赖，他把整个项目全权交由我来负责，命我做项目经理，当时我们这个项目组无疑成为了撑起公司的希望「前端：尹月、前端+文案：邵梦、后端：常齐+我+齐政+范畴、测试：灿灿」。

齐政当时还在成都的 Veritas 上班，在我们公司兼职，基本上有事就可以找他支援。后来 Veritas 散伙后，直接来了我们公司，不过来的时候我已经快离开了。

当时，我将前端所有部分交由尹月负责，毕竟，她在我们所有人中前端经验是最丰富的，她可以安排邵梦跟她分工协作。邵梦还有一个任务就是完成用户说明文档，优先级在前端任务之后，说明文档以 Markdown 的形式书写，用 Gitbook 整理，把项目框架搭好后给到她。灿灿主要就负责测试。我记得我们在底层加了两个功能：IaaS 层的虚拟机迁移和 PaaS 层的 RDS。虚机迁移完全是利用 ZFS 的能力完成的，我们将这套流程加到 Triton 的 Workflow 中，使其可以利用前端界面进行管理。在做 RDS 时，我们使用 Triton 带的系统组件 Zookeeper 实现服务的注册与发现，以自动实现主备切换。我们后端几人任务分配方式基本都是按模块，一个模块就是一个微服务，使用 RESTful 对接。

运维

一进公司，我一心为公司发展的一片赤子之心便展露无遗，当然了，仅仅有心还不够，还得有能力「我的特点是：超强的学习能力、快速的上手能力以及问题的分析解决能力」，这使得我很快得到了朱总和范畴的认可，几乎把公司所有的基建都交给了我……搭建😂 是的，会的、不会的、见过的、没见过的，只要有需求，我就得满足😩。我前后为公司搭建了 SVN、LDAP、Samba、Bind9、Gitlab 等多种服务。

为验证 triton 软件定义数据中心的能力，公司前前后后又买了两台满配的 Dell 服务器、一台 Dell 的万兆三层交换机、两台 Dell 的千兆三层交换机。另外，朱总让我非常佩服的地方在于他总能跟各种公司借到想要设备。这其中包括了从宝德借来的一台 x86 服务器，从 Cavium 借来了一台 ARM 服务器，还从 Mellanox 借来了两块 infiniband 的网卡想把 RDMA 技术放到自研数据库中。有幸管理和使用这些设备着实让我硬件知识提升了不少，以前仅仅在书上看到的东西在这里都尝试了一把😄。还记得当时照着手册给交换机配置 VLAN 可真是把我折腾惨了😨。

出差

作为公司颜值担当和实力担当的我（不好意思，我膨胀了🙈），实习期就开始出差了。玩笑归玩笑，不过说真的，那时我确实是全公司最了解 Triton 的人。当时我们在川内有个项目要做 PoC，公司派我过去的，他们的服务器又老又旧，可难受死我了。他们那机器用的 LSI 的磁盘驱动器，但是 SmartOS 并没有内置该驱动，我们当时花了好长时间才发现这个问题，最后朱总亲自重新编译了内核，问题才得以解决；翌日安装完成后，我又发现计算节点的 PXE 启动有问题，系统初始化一直不能成功，而这些问题在自己机房是从未出现过的，我只能通过微服务日志跟踪的方式寻找原因，当时现场有10来个人看我直播排错来着，可把我惊出一身冷汗，庆幸的是，我找到了原因，客户现场的路由器时间有问题，引发服务器使用 NTP 服务出错，Triton 不允许在时间不同步的情况下进行初始化。

此外，还去北京参加过一次数据库大会，毕竟我们也是中国少有的几家能够提供 PostgreSQL 专业服务的公司。当然，我们也趁着这个机会推销了一下公司的鸿鹄彩云。🐾🐾🐾另外去北京、上海各一次，都是为了去宣传我们的「鸿鹄彩云」。

数据库大会的时候，我负责宣传我们的「鸿鹄彩云」，敏哥负责「EcoX」，在那之前，公司在招了一个销售叫 Sott，当时负责招揽意向客户。

Scott 是一个有近20年工作经验的前辈，也是我见过少有的能够为了梦想豁出自己的人，也是一个特别热心的人，不过由于跟朱总理念不合，没过多久就离开了。我们一直都还有联系，后来还帮了我不少忙。

纪律

公司管理特别放松，本来人也少，不打卡、不考核，秉承着革命靠自觉的管理方式，本意是觉得大家都是高素质人才，只要大家把工作完成好了就行。刚开始的时候，大家确实都还蛮自觉的，然而随着时间的推移，情况变得越来越糟。数据中心产品始终没有办法变现，办公室里终日人心惶惶。每天九点、十点、十一点来上班的人都有，更有甚者过来直接就到饭点了😟，但是下班基本都比较准时，过了 18:10 几乎很难看到公司还有其他人。平常在公司里，看球赛的看球赛、看电视的看电视，也没有人管，我几乎不敢相信这是一家创业公司，感觉国企也不能这样吧？朱总平时都不在办公室里，对公司的情况并不了解，我看在眼里，痛在心里，我知道这是主人翁意识在“作祟”。

我们大多数人都是刚出校门的学生，没有形成什么职业素养，很容易受环境所累。公司产品销路一直有问题，所以在当时，公司正处于一种内忧外患的境地。为此，我跟朱总探讨了上班打卡的可能性，朱总最终决定使用钉钉打卡，尽管如此，还是不计入考评（准确来讲是没有考评😂）。从那以后，每天的上下班时间都有记录了，碍于情面，出勤效果改善了不少。但是后来有人来晚了就直接选择忘记打卡😥。为了给公司营造一个良好的工作氛围，我后来还建议朱总加入绩效考评，这在我离开公司那会儿得到了采用，可能也是我觉得当时我所还能够给公司带来的吧。

离开

不论到哪儿，我都会问自己的一个问题是：我可以为这里带来些什么？

价值体现 大概是我职业生涯最在乎的东西了。公司发展一直都比较缓慢，又内外交困，我隐隐觉得看不到未来。我希望凭借自己的努力可以让公司变得越来越好，因为我与公司荣辱与共。我每天都在不断地思考着，除了跟朱总一起探讨办公室氛围问题，关于公司发展，我也会出谋划策。我不见得说的都对，但我的立场和出发点完全都是在为公司考虑，朱总看到眼里也记在心里，因而一直都挺欣赏我的，也愿意跟我一起探讨。

朱总每天或每周偶尔来一下办公室，因此，范畴就是实际意义上的办公室领袖，有什么问题我们都找他解决，特别是刚去公司那会儿，那时的他跟招我时一样干劲十足。在工作过程中，我的能力慢慢展现出来，范畴和朱总都有心提拔我，慢慢把「鸿鹄彩云」的控制权交到了我手里。自那以后，范畴主要和建平一起做数据库方面的一些东西，偶尔帮衬一下我们。可是过了一段时间，我发现范畴有点魂不守舍的，来得越来越晚了不说，还经常请假，当时我们已经在打卡了，他也经常不打。老实说，我觉得他有些无视纪律，恣意妄为。其实不单是我，大家都有发现，只是敢怒不敢言而已。可是作为办公室领袖如此行事，影响相当恶劣。范畴似乎早已看出了我们的不满，就在一次请假的假期结束之后单独找我聊天。从聊天我得知了他刚离婚的消息，看得出来他十分爱他的前妻，请假是因为悲伤过度，实在无心工作。他让我不要告诉大家，不想因为自己影响大家。他原计划当时就离去的，但是答应朱总的两年期限未满不能也不愿违背承诺，同时也不想动摇军心，过年前他会努力做好考勤的，事实上，他确实做到了。后来，我一直都跟大家讲的是范畴可能有什么苦衷，让大家给他点时间，直至最后范畴离开真相大白的时候，大家都说范畴平时都嘻嘻哈哈的，一点看不出来。或许这就是一个成熟男人吧👊👊👊。

这件事情之后，我就在想如果解决不了公司的困境，我不得不为自己的未来早做打算。一方面，我仍旧试图帮助公司扭转局面，作为研发人员的我还跟朱总一起去外勤，但非常遗憾的是那时的我并不具备任何销售能力，眼见帮不上什么忙，我内心心急如焚；另一方面，我觉得我的未来特迷茫，研发我觉得自己不够深入，运维有点浪费能力，想做项目经理吧，我又没有走过标准化流程，真心纠结😖，但我心里很清楚，倘若我继续待下去，情况并不会有所改观，反而随着年龄增大压力会越来越大，我想要改变🏃‍♂️。

朱总的挽留并没有让我留下，因为我觉得自己无能为力。我一直都特别感激朱总的赏识，觉得自己的离开有点辜负了他，所以我把所有工作做好后才离开的，并没有提前找好工作，这算是对这份工作的一种敬畏吧🙏。

我走的时候尹月不知道，因为那时候她请假了。直到我去公司拿「离职证明」时她才知道，我现在还记得特清楚她当时微信里“质问”我：“你是不是觉得在这里学不到什么东西啦，所以你要离开？”“不是的”，我并没有想好要怎样回答。她随后说道：“工作找好了吗？我相信你到哪里都可以一样优秀的。”“还没呢，谢谢祝福！”我内心非常感激，我也一样相信 我的未来不是梦！

大学

Mon, 01 Jul 2019 17:29:58 +0800

前言

早前基本不怎么接触过计算机的我，大学志愿毫不犹豫地全部填写了计算机相关专业。我很庆幸，当时的自己看到了未来，也很庆幸，我所学即我所爱。最后到了南昌航空大学攻读软件工程专业，只是学费真的好贵💔。

大一

入学

上大学是我第一次出远门，也是第一次坐火车，我还记得那趟火车是T126，从成都开往东莞的，坐了大概19+小时。路上遇到一个从成都回襄樊过中秋节的老大哥，他说他是九几年毕业于哈工大一个汽车相关的专业，好像是内燃机啥的，我也记不太清楚了。从来没有讲过普通话的我，在车上跟他聊天，感觉特别扭，并不好意思讲。他跟我讲，我必须要克服，因为我到了学校还是得面对，逃避解决不了问题。所以，我在到学校前就把普通话讲顺畅了。临走时，他还给了我一本《读者》，为啥我还记得呢？也许是因为那是我唯一一本杂志的缘故吧😋。

刚入学那会儿，住在一个临时宿舍，离学院大部队有点距离，我们有4个人，江西吉安的邹智彬，不会蒙语的内蒙人吴子贺，还有一个不跟我们一个班但跟我是四川老乡却不吃辣的莫天。我们都是外地人，所以虽然在一块儿没待多久，但是整个大学期间关系都非常不错。两周后一方向重新分班，我们仨都觉得微软不错，所以都选了它。我们分班后，便搬离了那里，我们三个还在一个班。邹智彬去了我对面宿舍；莫天回到了他原班级宿舍，与我们隔着几层楼。我和子贺呢，就多了俩新室友，江西吉安的胖子李忠，南昌本地人陈俊刚。莫天和邹智彬后面也经常来我们宿舍玩。

注：我们软件学院共有6个方向，1方向（也就是我所在的方向）就叫软件工程，2方向是航空信息化，3方向是会计，4方向是嵌入式，5方向是测控（莫天所在），6方向是飞控。1方向在军训结束后，又分成了3个小方向：测试、Java、微软定向。

初入大学第一天就被骗😱。入学手续差不多办好后，都晚上了。我一个人走在学校食堂旁边，来了一个女孩，说她是一个大四学生，从内蒙过来找她同学的，钱包手机都被偷了，连吃饭的钱都没有了，让我借钱给她吃顿饭。我的天，一顿吃了我17块大洋，要知道我大一每顿自己就花1.1元（一个素菜0.8元，一份饭0.3元），所以当时吃得我特心痛。吃完饭后，她又管我要200块，说是要去南大后街住一晚，我表示没有，她还不死心，说要是不信的话，可以跟她一起过去。可那时候两百块是我一个月的生活费，所以任她说破天，我也不可能给的😝。我只能说，她看出了我是新生，却没看出我穷😆。最终，她放弃了，临走前还记了我电话号码，说是第二天要还我钱。不过，我心里也明白，基本没啥可能，而事实也确实如此。

大一的我是一个特别自卑的存在，因为自己是从村里来的，见识短浅，怕稍有不慎闹了笑话，暴露了自己乡野匹夫的身份😅，一直不敢在公众场合讲话。别说大学了，初中高中都是如此，但也因此我特别在意自己的格局和视野。那时咱们班上竞选班干部，其实我特想选个班长啥的，奈何我始终没有勇气上台。当时，我们的军训教官（也是我们学长）似乎看出了我的心思，干脆让大家不论参选与否都上台讲几句。然而尽管如此，我还是憋到了最后一个上场，并且待了半天硬是说不出一个字。从那以后，我心里暗自发誓，我需要在公众场合正确地表达自己，甚至于成为一个极具魅力的演说家。

一直以来，我都害怕考试，害怕在公众场合发言，但我非常清楚这是多么不利于自己发展，因此解决这个问题也成了我的一大目标。为此，我便加入了校团委，和我一道的还有子贺。此外，为了让自己保持良好的生活习惯，我还加入了学校的知行班，每日六点集合跑五公里。

组建团队

到了大一下学期，我们开始有专业课了。有一天，莫天突然找到我，说想组建一个团队，一起成长、一起学习，说不定将来还能一起成就一番伟业。说到我心坎儿里了。他做队长，我做副队。我们印了传单，一起在住宿楼的楼道里分发，告诉学院的小伙伴，我们将组建一个了不起的团队，期待志同道合的小伙伴加入。会议当天，我们租了个大音响，然而来的人并不多。不过，我们也正式成立了我们9个人的小分队「莫天、我、文博、彭星、佳莹、郑朋、汤洋、王同、秦风」。我们每天早上6点整集合，跑步到图书馆门口做早操，带着非常夸张的动作高喊三遍：『左脚！右脚！啊！这是多么美好的一天啊，充满了爱、热情、效益、感恩、Power！』💪💪💪，然后进行英语晨读，结束后再一起去食堂吃早餐，为此我退出了知行班；平时有时间就组队去图书馆学习，周末我们就一起去机房练习编码。在早上练习英语时，我们吸引到了第一位女同学韩婷的加入；紧接着，我班上学委慧慧也通过我加入了我们。有个周末，我们如同往常一样，一起去机房进行编程练习。韩婷碰见了她班上的同学奚心，刚好那天奚心有个问题不能解决，韩婷就带她问了莫天，莫天圆满地搞定了。至此，我们又多了一个成员，我们的团队定格在九男三女共十一人。

注：莫天成绩一直都是不错的，是他们52班的第一名；而奚心，后来我们了解到，她是11班的第一名；

小美好

有一天，莫天让我去参加一个活动，说是可以提升自我。那是一个演讲训练营，我怀着一颗期待的心过去，果然被感染到了。平时都不舍得花钱的我，也没怎么犹豫就直接支付了300块用于报名参加了一个清明假期的演讲训练营。后来莫天跟我讲，本来只是让我体验下那种氛围的，没成想我会报班😂。

2014年4月4日晚，我正式加入了训练营，我依稀记得我们好像是3队「与我同校的信工学院的大二妹子李真，南昌大学大三的谢文春，江西财经大学大二的汤洋洋，江西农业大学大一的妹子廖美琴，南昌工学院大一的妹子刘蕖」。那时候的我还特腼腆，知道自己位置后，一个人傻坐在位置上，也不跟人交流。突然有个妹子走过来坐我旁边跟我打招呼，搞得我的脸一下就红了，场面一度很尴尬，可能就这么一见钟情了吧😍。据她介绍，她叫刘蕖，跟我是一队的，至于我当时有没有反过来自我介绍，已经不记得了，应该有吧？😥 选队长的时候，我一如既往地在心里想了想，然后把机会留给了别人（😹感觉自己特无私的，有没有？），最后，汤洋洋成为了我们的队长。

在这里的三个日夜，想哭就哭、想笑就笑、想说就说，我从未如此毫无顾忌地展示自己，可即便如此，我仍然决定将自己心中对刘蕖的那份爱意埋藏起来直至忘却。😳为何会如此？三天三夜的启发已经让我发生了蜕变，从那时起，我告诉自己：『去做所有我认为是正确的事情，不论我是否做过、会不会做、敢不敢做、想不想做』。在我看来那不是一个正确的时间，那时候的日子过得实在寒酸，我认为自己还没有能力拥有一份爱情，所以基本没想要去争取。同时，我知道同队的谢文春也喜欢她，并且已经展开攻势了，我还想办法撮合他们来着😬。

训练营结束后，我们团队组织了一次聚餐，我也去了，整个团队都知道谢文春在追她，都想撮合他俩，所以我基本上是计划去当观众的。饭局当天，她来得稍晚一点，大家都把谢文春旁边的位置给她留着（虽然自己并不计划去争取，但看着大家都想成全他们，心中难免还是有些失落，情绪不太高）。然而，等她到了后，她随便找了个理由，非常可爱地拒绝了谢文春的殷勤，还坐到了我旁边来。我是有点愣住了，不过喜欢的女孩坐自己身旁，心情肯定是不错的，那顿饭也是吃得有滋有味的😋。

后来用 QQ 跟她网上聊天，具体聊的啥，我不太记得了。不过，通过交流我得知，原来她早就知道我对她有意思，刚好她对我也有意思。我问她是否介意我当时的情况，得到她的答复后，我们就在一起了。那是2014年4月24日，我们认识的第20天。所以，我的初恋就这么来了，像做梦一般，以前从不敢想。

三小项目

所谓三小呢，就是：小发明、小制作、小创作。得益于莫天的班主任杨丰玉是学院带项目的老师，我们有一个做项目的机会。项目组有4个人「莫天、我、秦风、李磊」，我们用ege做了一套 C 指针动态演示系统帮助教学。项目经费下来后，杨老师给我们买了一些书，其中包括一些ACM的，只是我不知道后来为何不了了之了。只怪自己当初了解太少，不然说什么也要参加比赛才是。

总有那么几个人在跨进大学校门前就接触过编程了，李磊就是其中一个，同时他是41班的No.1，一起做项目让我学到了很多，后来他被保送到了厦门大学深造。

暑假工

跟女朋友一起去东莞去做车辆模型制作的车间工人，每天都是重复的工作，38℃的高温，每天顶着一个巨型电风扇吹，还是觉得身上黏乎乎的。

大二

团队问题

在经历了大半学期的坚持后，有人早上起不来了，为了团队纪律，我提出了迟到罚款的规定，纪律算是得到了有效控制。一周后郑朋和王同觉得自己不再适合待下去，索性请求离开了，我们剩下的九个人一如既往的在一块儿学习。值得一提的是，此前莫天和奚心走到了一起。

莫天和奚心出现了问题，奚心说为了团队不受影响，她不得不退出。然而，莫天从此一蹶不振，不理朝事。一日，他把我们都召集到了一起，宣布了他要解散团队的决定。作为他的朋友也是团队发起人之一，我心里很不是滋味，不知道如何面对我们的队员，因为当初的承诺都还没能兑现，如今主心骨突然要退出，实在是有些手足无措。莫天走后，我问队员的想法，问他们是否还想继续，除了秦风要退出，其他人都愿意跟我一起继续下去。只可惜当时的自己眼界有限，并不能为他们带来什么。大三我去了沈阳后，这件事情落下了个不了了之，这是我整个大学阶段无论如何都挥之不去的遗憾，我一直期待着某天还能有机会弥补。

转专业

原计划大三就要去微软技术中心实训了，然而到了大二结束前的两周，我们被告知项目破产，没办法前去了。原本就觉得在学校学不到什么东西的我，就像是听到了一个噩耗。这时候我得知如果成绩足够优秀可以转专业到四方向，那可以去沈阳东软实训，我不由得动了这个念头，只是我需要考虑的是不得不跟女朋友异地恋了。莫天也想要转过去（我知道他是想逃避一些事情），所以他极力劝我跟他一起。思虑再三，为了自己的前途，我还是决定转过去。

暑假工

这一年的暑假，我们去了重庆。本来还想进厂找工作的，但是厂里不要暑假工，我们在沙坪坝待了几天，一直也没有办法。没钱住宿，我们只能去网吧，希望省点钱。不幸的是，屋漏偏逢连夜雨，我们在网吧睡觉的时候，女朋友手机被偷了。手机有防盗功能，所以我们有嫌疑人照片，以及实名认证的电话号码，我们报了警，并将信息提供给了派出所，其实只要派出所肯查，肯定能找到的，但我们失败了。

要是手机没被偷，我们找不到工作，或许就回去了吧？但当时的情况，如果就那样走了，我们不甘心。离开了沙坪坝，我们去了九龙坡，在谢家湾找到了一份烤肉店服务员的工作。之后，我们用挣来的钱给女朋友又重新买了一部手机。

大三

友情

到了沈阳后，好长一段时间嘴唇都干巴巴的，没有一点知觉，跟女朋友异地，经常吵架，自己情绪变得特别不稳定。对莫天的不满也在这个时候彻底暴发了出来，于是我们决裂了，这种关系一直持续到毕业（毕业回南昌的火车上，我让我后来的室友金辉帮我将他约出，已是离别时，所有恩怨终是虚无，最终，我们冰释前嫌了，现在都在成都，仍是好友。）。

我到了新的宿舍，认识了新的室友「姜伟、姜兴、金辉，他们都来自南昌」，这是一群非常有意思的小伙伴，我很快便平复心情，投入到新的征程中去了。在新的班级，我又认识了眭彬橙，他就坐我旁边。跟他交流是一件非常愉快的事，从技术到思想，总能碰撞出很多有意思的东西。

眭彬橙是一个高中就自学编程的家伙，上大学之前就已经靠编程赚钱的主，毕业后去了B站，前些天刚得知现在已经到了阿里巴巴。

选择

大四那年秋天，一开始我就回到了成都准备秋招的事情。那时候，整日跟川大、电子科大的本科及硕士研究生同台竞技，我的笔试成绩比较好，基本都能获得面试机会。然而，我却被从Oracle出来，一心想做国产数据库的朱贤文吸引了。

为了实现自己的梦想，放弃了给自己履历镀金的机会，加入一家创业公司实习并作为第一份工作。在现在看来，很难说这是一个明智的选择。但也没啥好后悔的，我做了自己想做的事，成就了今天的自己。整个大四我基本都在这里实习。我将在第一份工作中详细介绍。

总结

大一、大二，学习一直跟着学校的节奏在走，尽管学习进度上有所超前，但是没有将时间很好地利用起来。暑假都用来打暑假工了，没有合理利用起来，太奢侈了，觉悟得太晚。团队的不了了之，是我对不起我的队员们，希望将来还有机会弥补。这些无一例外地都让我意识到了格局的重要性。

一个人的视野和格局决定了他成就的高低，这是我从小到大最切身的感受。小学初中在乡下不知乡镇以外是何处，高中在市里发现城里人真的挺会玩，大学让我体会到了原来知识不仅是知识，出了社会后方知天外有天。学校的不同其实质就是平台所能给的视野和格局的差异。在格局不断变大的同时，人也会变得更加自信，我便是如此。

GNU sed用户手册

Sun, 11 Mar 2018 08:49:39 +0800

1 简介

sed是一个流编辑器（Stream EDitor）。流编辑器对输入流（文件或者是来自于管道的输入）进行基本的文件转换。虽然在某些方面类似于脚本化编辑器（例如ed），但是sed通过对输入进行一次遍历来工作，因此更高效。比较大的区别是sed能在管道中筛选文本。

2 运行

2.1 概述

一般的sed用法：

sed SCRIPT INPUTFILE...

例，将input.txt中的‘hello’全部替换成‘world’：

sed 's/hello/world/' input.txt > output.txt

如果已没有指定INPUTFILE或者INPUTFILE是-，sed将处理标准输入的内容，下述命令是等价的：

sed 's/hello/world/' input.txt > output.txt
sed 's/hello/world/' < input.txt > output.txt
cat input.txt | sed 's/hello/world/' - > output.txt

sed默认是将处理结果写到标准输出。使用-i参数则是直接修改文件。另见W和s///w命令将输出写入到其他文件。下述命令将会修改file.txt文件而不会产生任何输出：

sed -i 's/hello/world' file.txt

默认情况下，sed打印所有的输入（修改和删除除外，比如命令d）。用-n限制输出，p打印特定行。以下命令只打印输入文件的第45行：

sed -n '45p' file.txt

sed将多个输入文件作为一个长的输入流，在下述例子中，将打印第一个文件（one.txt）的第一行和第三个文件（three.txt）的最后一行。可用-s反转。

sed -n '1p ; $p' one.txt two.txt three.txt

若没有指定-e或者-f选项，sed使用第一个非选项参数作为执行脚本，接下来的非选项参数作为输入文件。如果使用-e或者-f指定一个执行脚本，其它所有的非参数选项将作为输入文件。-e和-f可以结合使用，并且可以多次出现（最终的执行脚本是这些单独脚本连接后的结果）。下述例子是等价的：

sed 's/hello/world/' input.txt > output.txt

sed -e 's/hello/world/' input.txt > output.txt
sed --expression='s/hello/world/' input.txt > output.txt

echo 's/hello/world/' > myscript.sed
sed -f myscript.sed input.txt > output.txt
sed --file=myscript.sed input.txt > output.txt

2.2 命令行选项

调用sed的完整格式是：

sed OPTIONS... [SCRIPT] [INPUTFILE...]

有如下的命令行选项：

--version 打印sed的版本和版权信息，然后退出

--help 打印一个使用信息，简要总结这些命令行选项和错误报告地址，然后退出。

-n --quiet --slient 默认情况下，sed在每个循环结束时通过脚本打印出模式空间（请参阅参考资料）。这些选项禁用了这种自动打印功能，sed只有在通过p命令明确告知时才会产生输出。

-e script --expression=script 将脚本中的命令添加到处理输入时要运行的一组命令中。

-f script-file --file=script-file 将包含在文件脚本文件中的命令添加到处理输入时要运行的一组命令中。

-i[SUFFIX] --in-place[=SUFFIX] 此选项指定编辑源文件。 sed通过创建临时文件并将输出发送到此文件而不是标准输出来完成此操作。

这个选项意味着-s。

到达文件末尾时，临时文件将被重命名为输出文件的原始名称。扩展名（如果提供）用于在重命名临时文件之前修改旧文件的名称，从而创建备份副本2）。
该规则如下：如果扩展名不包含_，则将其作为后缀追加到当前文件名的末尾;如果扩展名包含一个或多个_字符，则每个星号都将替换为当前的文件名。这使您可以将前缀添加到备份文件中，而不是后缀，甚至将原始文件的备份副本放到另一个目录（假定该目录已经存在）。

如果没有提供扩展名，原始文件将被覆盖而不进行备份。

-l N --line-length=N 指定每行默认换行长度，长度为0表示用不换行，默认值为70。

--posix GNU sed包括POSIX sed的几个扩展。为了简化书写便携式脚本，这个选项禁用了本手册文档中的所有扩展，包括附加的命令。大多数扩展接受不在POSIX规定的语法之外的sed程序，但其中的一些（如Reporting Bug中描述的N命令的行为）实际上违反了标准。如果只想禁用后一种扩展，则可以将POSIXLY_CORRECT变量设置为非空值。

-b --binary 此选项在每个平台上都可用，但仅在操作系统区分文本文件和二进制文件的情况下才有效。当与MS-DOS，Windows的情况一样时，Cygwin文本文件由回车符和换行符分隔的行组成，sed不会看到结尾的CR。当指定这个选项时，sed将以二进制模式打开输入文件，因此不要求这个特殊处理，并且考虑以换行结束的行。

--follow-symlinks 此选项仅在支持符号链接的平台上可用，并且仅在指定选项-i时才有效。在这种情况下，如果命令行中指定的文件是符号链接，sed将跟随链接并编辑链接的最终目标。默认行为是破坏符号链接，以便链接目标不会被修改。

-E -r --regexp-extended 使用扩展正则表达式而不是基本正则表达式。扩展的正则表达式是那些egrep接受的;通常有较少的反斜杠，表达更清楚。从历史上看，这是一个GNU扩展，但是-E扩展已经被添加到POSIX标准，因此使用-E来实现可移植性。GNU的sed已经接受-E作为未记录选项， BSD 的sed也已经接受-E很长一段时间了，但使用-E的脚本可能无法移植到其他较老的系统。请参阅扩展正则表达式。

-s --separate 默认情况下，sed会将命令行中指定的文件视为一个连续的长流。这个GNU的sed的扩展允许用户将它们视为单独的文件：范围地址（如’/abc/,/def/’）不能跨越多个文件，行号是相对于每个文件的开始，$是指到每个文件的最后一行，并且从R命令调用的文件在每个文件的开始处倒回。

--sandbox 在沙箱模式下，e/w/r命令被拒绝——包含它们的程序将被中止而不运行。沙箱模式可确保sed仅在命令行上指定的输入文件上运行，并且不能运行外部程序。

-u --unbuffered 缓冲输入和输出尽可能最小。（如果输入来自tail -f之类的输入，那么这个特别有用，而且希望尽快看到转换后的输出。）

-z --null-data --zero-terminated 将输入视为一组行，每个行以零字节（ASCII’NUL’字符）而不是换行符结尾。这个选项可以用于像sort -z和find -print0这样的命令来处理任意文件名。如果命令行中没有给出-e，-f，--expression或--file选项，则命令行上的第一个非选项参数将被视为要执行的脚本。如果在处理完上面的命令行参数后仍然存在，则这些参数将被解释为要处理的输入文件的名称。文件名“-”是指标准输入流。如果没有指定文件名称，标准输入将被处理。

2.3 退出状态

零退出状态指示成功，非零值表示失败。 GNU sed退出状态，但返回以下错误值： 0 成功完成 1 命令无效，语法无效，正则表达式无效或与--posix一起使用的GNU sed的扩展命令。 2 命令行上指定的一个或多个输入文件无法打开（例如，如果找不到文件，或者读权限被拒绝）。处理继续与其他文件。 4 一个I/O错误或运行时严重的处理错误，GNU sed立即中止。另外，命令q和Q可以用来以一个自定义的退出代码值来终止sed（这是一个GNU sed扩展）：

$ echo | sed 'Q42' ; echo $?
42

3 `sed`脚本

3.1 `sed`脚本概述

一个sed程序由一个或多个sed命令组成，这些命令由一个或多个-e，-f，–expression和–file选项传入，或者如果没有这些选项，则由第一个非选项参数传入。本文档当中所有的 sed脚本 均表示所有传入脚本连接后的结果。 sed命令语法如下：

[addr]X[options]

X是单字符的sed命令。[addr]是一个可选的行地址。如果[addr]被指定，则X命令只在指定行执行。[addr]可以是一个行号，一个正则表达式也可是一个行范围（参见sed地址）。其它选项被用于某些sed命令。下述的例子将在输入文件中删除第30至35行。30,35是地址范围。d是删除命令：

sed '30,35d' input.txt > output.txt

以下示例将打印所有输入，直到找到以“foo”开头的行。如果找到这一行，sed将以状态42退出。如果没有找到这样的行（并且没有发生其他错误），则sed将以状态0退出。/^foo/是一个正则表达式地址，q是退出命令，42是命令选项。

sed '/^foo/q42' input.txt > output.txt

脚本或脚本文件中的命令可以用分号（;）或换行符（ASCII 10）分隔。可以使用-e或-f选项指定多个脚本。以下例子都是等价的。它们执行两个sed操作：删除与正则表达式/^foo/匹配的所有行，并用‘world’替换所有出现的字符串‘hello’：

sed '/^foo/d ; s/hello/world/' input.txt > output.txt

sed -e '/^foo/d' -e 's/hello/world/' input.txt > output.txt

echo '/^foo/d' > script.sed
echo 's/hello/world/' >> script.sed
sed -f script.sed input.txt > output.txt

echo 's/hello/world/' > script2.sed
sed -e '/^foo/d' -f script2.sed input.txt > output.txt

命令a，c，i由于它们的语法，所以不能使用作为命令分隔符的分号，因此应该用换行符结尾或是放在脚本或脚本文件的末尾。命令也能以可选的不重要的空白字符开头。请参阅多命令语法。

3.2 `sed`命令汇总

GNU sed支持以下命令。有些是标准的POSIX命令，而另一些是GNU扩展。每个命令的详细信息和示例在以下部分。（助记符）显示在括号内。

a\
text 在一行之后追加文本。

a text 在一行之后追加文本（替代语法）。

b label 无条件地分支标签。标签可以省略，在这种情况下下一个周期开始。

c\
text 用文本替换（更改）行。

c text 用文本替换（更改）行（替代语法）。

d 删除模式空间;立即开始下一个周期。

D 如果模式空间包含换行符，则删除模式空间中的文本直到第一个换行符，然后用结果模式空间重新启动循环，而不读取新的输入行。如果模式空间不包含换行符，就像d命令一样，开始一个正常的新周期。

e 执行在模式空间中找到的命令，并用输出替换模式空间；尾随的换行符被压制。

F （filename）打印当前输入文件的文件名（带有换行符）。

g 用占位空间的内容替换模式空间的内容。

G 向模式空间的内容追加换行符，然后将保留空间的内容追加到模式空间的内容。

h （hold）将保持空间的内容替换为模式空间的内容。

H 追加一个换行符到保存空间的内容，然后将模式空间的内容追加到保存空间的内容。

i\
text 在一行之前插入文本。

i text 在一行之前插入文本（替代语法）。

l 以确定的形式打印模式空间

n （next）如果未禁用自动打印，请打印模式空间，然后用下一行输入替换模式空间。如果没有更多的输入，那么sed退出而不处理任何更多的命令。

N 向模式空间添加换行符，然后将下一行输入添加到模式空间。如果没有更多的输入，那么sed退出而不处理任何更多的命令。

p 打印模式空间

P 打印模式空间，直到第一个<换行符>。

q[exit-code] （quit）退出sed而不处理任何更多的命令或输入。

Q[exit-code] （quit）该命令与q相同，但不会打印模式空间的内容。像q一样，它提供了将退出代码返回给调用者的功能。

r filename 读文本文件的一个文件。

R filename 在当前周期结束时排队读取一行文件名并将其插入到输出流中，或读取下一个输入行时。

s/regexp/replacement/[flags] （substitue）匹配正则表达式和模式空间的内容。如果找到，用替换替换匹配的字符串。

t label （test）分支只有在自上次输入行被读取或进行了条件分支以来已成功进行替换时才进行标记。标签可以省略，在这种情况下下一个周期开始。

T label （test）分支只有在自上一条输入行被读取或条件分支被采用以来没有成功的替换时才被标记。标签可以省略，在这种情况下下一个周期开始。

v [version] （version）这个命令什么都不做，但是如果不支持GNU sed扩展，或者如果请求的版本不可用，sed会失败

w filename 将模式空间写入文件名。

W filename 写入给定的文件名模式空间的部分直到第一个换行符

x 交换持有和模式空间的内容。

y/src/dst/ 将模式空间中所有与任何源字符匹配的字符与目标字符中的对应字符进行替换。

z （zap）该命令清空模式空间的内容。

# 注释，直到下一个换行。

{ cmd ; cmd ... } 将几个命令一起分组。

= 打印当前输入行号（带有换行符）。

: label 指定分支命令（b，t，T）的标签位置。

3.3 `s`命令

s命令（替换）在sed中可能是最重要的，并且有很多不同的选项。

s命令的语法是s/regexp/replacement/flags。

它的基本概念很简单：s命令尝试将模式空间与提供的正则表达式regexp进行匹配；如果匹配成功，则匹配的那部分模式空间被replacement替换。

有关regexp语法的详细信息，请参阅正则表达式地址。

replacement可以包含\n（n是从1到9的数字，包括1和9），它是指包含在第n个（及其匹配的\）之间的匹配部分。此外，replacement可以包含引用模式空间的整个匹配部分的非转义＆字符。在任何给定的s命令中，/字符可以被任何其他单个字符统一替换。 /字符（或任何其他替代字符）可以出现在regexp或replacement中，只要前面有一个\字符。最后，作为一个GNU sed扩展，你可以包含一个由反斜杠和字母L，l，U，u或E中的一个组成的特殊序列。含义如下： \L 替换为小写，直到找到\U或\E， \l 将下一个字母转为小写， \U 替换为大写，直到找到\L或\E， \u 将下一个字符转为大写， \E 停止由\L或者\U开始的大小写转换使用g标志时，大小写转换不会从正则表达式的一次出现传播到另一次。例如，当在模式空间中使用a-b-执行以下命令时：

s/\(b\?\)-/x\u\1/g

输出是axxB。当替换第一个’-时，\u序列只影响\1的空白替换。它不会影响用xB替换b-时添加到模式空间的x字符。另一方面，如果\l和\u之后是空替换，确实会影响替换文本的其余部分。在模式空间中使用a-b-，使用以下命令：

s/\(b\?\)-/\u\1x/g

将用X（大写）替换-和用Bx代替b-。如果这种行为是不可取的，那么在这种情况下，可以通过在\1之后添加一个\E序列来阻止它。要在最终替换中包含文字\，＆或换行符，请务必在所需的\，＆或换行符之前加上转义符\。 s命令后面可以跟零个或多个以下flags：

g 将所有匹配的替换应用于正则表达式，而不仅仅是第一个。

number 只替换正则表达式的第number个匹配。 s命令中的交互注意：POSIX标准没有规定当你将g和number修饰符混合时会发生什么，而且目前在sed实现中没有统一的意见。

对于GNU sed，交互被定义为：在第number之前忽略匹配，然后匹配并替换第number后的所有匹配。 p 如果进行替换，则打印新的模式空间。注意：当指定p和e选项时，两者的相对顺序会产生非常不同的结果。一般来说，ep（评估然后打印）是你想要的，但是反过来操作对于调试是有用的。由于这个原因，当前版本的GNU sed特别解释了在e之前和之后的p选项的存在，在评估之前和之后打印模式空间，而s命令的一般标志只显示其效果一次。这种行为虽然有文件记录，但在将来的版本中可能会发生变化。

w filename 如果进行了替换，则将结果写入指定的文件。作为一个GNU sed扩展，支持两个特殊的filename值：/dev/stderr，将结果写入标准错误，/dev/stdout写入标准输出。 e 这个命令允许将命令从shell命令输入到模式空间。如果已经进行替换，则会执行在模式空间中找到的命令，并将模式空间替换为其输出。尾随的换行符被压制；如果要执行的命令包含NUL字符，则结果是不确定的。这是一个GNU sed扩展。

I
i 用于正则表达式匹配的I修饰符是一个GNU扩展，它以不区分大小写的方式使sed匹配正则表达式。

M
m 正则表达式匹配的M修饰符是一个GNU sed扩展，它指示GNU sed在多行模式下匹配正则表达式。该修饰符使^和$分别匹配（除了正常行为）换行之后的空字符串和换行之前的空字符串。有特殊的字符序列（\` 和\'）总是匹配缓冲区的开始或结束。此外，句点字符在多行模式下与换行字符不匹配。

使用 kubeadm 安装 Kubernetes 1.10.0

Fri, 09 Mar 2018 00:00:00 +0000

kubernetes可以使用多种容器runtime，此处使用当前最常见的docker。

安装docker

在各种机器上安装docker的方式不同，我曾翻译过一篇ubuntu安装docker的文章，还有一些没来的及翻译的，可以参考官方文档。推荐的docker版本为v1.12，v1.11, v1.13 和 17.03 也行，其它的官方就没测试过了，不过我使用当前最新的v18.03也行。

docker官方

使用Ubuntu安装docker-ce
Mac和Windows桌面安装docker-ce
- 下载Mac版本的docker-ce，执行即安装
- 下载Windows版本的docker-ce，执行即可安装
CentOS安装docker-ce
Fedora安装docker-ce
二进制安装方式

kubernetes推荐

Ubuntu/Debian/HypriotOS 从Ubuntu的库安装

apt-get update
apt-get install -y docker.io

使用docker库安装v17.03

apt-get update
apt-get install -y \
 apt-transport-https \
 ca-certificates \
 curl \
 software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
add-apt-repository \
 "deb https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \
 $(lsb_release -cs) \
 stable"
apt-get update && apt-get install -y docker-ce=$(apt-cache madison docker-ce | grep 17.03 | head -1 | awk '{print $3}')

CentOS/RHEL/Fedora

yum install -y docker
systemctl enable docker && systemctl start docker

Container Linux

systemctl enable docker && systemctl start docker

如果安装速度太慢建议翻墙先把安装包下载回来。文末附了红帽离线包供下载。

安装kubeadm、kubectl和kubelet

Ubuntu/Debian/HypriotOS

apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl

CentOS/RHEL/Fedora

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
setenforce 0
yum install -y kubelet kubeadm kubectl
systemctl enable kubelet && systemctl start kubelet

确保net.bridge.bridge-nf-call-iptables值为1

cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sysctl --system

Container Linux 先安装CNI插件

CNI_VERSION="v0.6.0"
mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz

安装 kubeadm, kubelet, kubectl 并添加kubelet systemd服务：

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"

mkdir -p /opt/bin
cd /opt/bin
curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
chmod +x {kubeadm,kubelet,kubectl}

curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

enable并启动kubelet

systemctl enable kubelet && systemctl start kubelet

在主节点上配置kubelet使用的cgroup驱动程序

确保docker使用的cgroup驱动和kubelet一样

docker info | grep -i cgroup
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

如果不同则，使kubelet与docker的cgroup驱动相同

sed -i "s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

重启kubelet

systemctl daemon-reload
systemctl restart kubelet

文末附了红帽离线包供下载。

创建集群

离线安装

yum安装离线资源 docker load 装载离线的docker镜像

资源

CentOS安装kubeadm需要的相关资源：（链接: https://pan.baidu.com/s/1r7-LqH1Ju-5YTAIvRTcIUg 密码: c2nf）
安装kubernetes需要的Docker镜像：（链接: https://pan.baidu.com/s/1fGQtWnuvxJ7pXK5attP8Jw 密码: mty5）

Node使用RabbitMQ：远程过程调用（RPC）

Fri, 16 Feb 2018 08:52:19 +0800

前提条件

本教程假定RabbitMQ已安装并在标准端口（5672）上的本地主机上运行。如果您使用不同的主机，端口或凭据，连接设置将需要调整。

（使用amqp.node客户端）

在第二个教程中，我们学习了如何使用工作队列在多个Worker之间分配耗时的任务。但是如果我们需要在远程计算机上运行一个函数并等待结果呢？那么，这是件不同的事。这种模式通常被称为远程过程调用或RPC。在本教程中，我们将使用RabbitMQ构建一个RPC系统：一个客户端和一个可扩展的RPC服务器。由于我们没有任何值得分发的耗时任务，所以我们将创建一个返回斐波那契数列的虚拟RPC服务。

回调队列

一般来讲，通过RabbitMQ使用RPC是非常容易的。客户端发送请求消息，服务器回复响应消息。为了收到回应，请求时，我们需要发送一个callback队列地址。我们可以使用默认队列。让我们试试看：

ch.assertQueue('', {exclusive: true});

ch.sendToQueue('rpc_queue',new Buffer('10'), { replyTo: queue_name });

# ... then code to read a response message from the callback queue ...

消息属性 AMQP 0-9-1协议预定义了一组与消息一起的14个属性。除了以下属性，大多数属性很少使用： persistent：将消息标记为persistent（值为true）或transient（false）。您可能会从第二个教程中了解到这个属性。 content_type：用于描述编码的MIME类型。例如，对于经常使用的JSON编码，将此属性设置为application/json是一个很好的习惯。 reply_to：通常用于命名回调队列。 correlation_id：用于将RPC响应与请求相关联。

关联标识（correlation id）

在上面介绍的方法中，我们建议为每个RPC请求创建一个回调队列。这是非常低效的，但幸运的是有一个更好的方法——让我们创建一个单一的客户端回调队列。这引发了一个新的问题，在该队列中收到回复，不清楚回复属于哪个请求。什么时候使用correlation_id属性？我们将把它设置为每个请求的唯一值。之后，当我们在回调队列中收到一条消息时，我们将查看这个属性，并基于这个属性，我们可以将响应与请求进行匹配。如果我们看到一个未知的correlation_id值，我们可以放心地丢弃这个消息——这不属于我们的请求。您可能会问，为什么我们应该忽略回调队列中的未知消息，而不是失败并报一个错误？这是由于在服务器端的竞争条件的可能性。虽然不太可能，但在发送给我们答复之后，在发送请求的确认消息之前，RPC服务器可能会死亡。如果发生这种情况，重新启动的RPC服务器将再次处理该请求。这就是为什么在客户端，我们必须优雅地处理重复的响应，理想情况下RPC应该是幂等的。

总结

我们的RPC调用像这样：当客户端启动的时候，它创建一个匿名的独占式回调队列。对于一个RPC请求，客户端会发送具有这两个属性的消息：reply_to，用于设置回调队列；correlation_id，作为请求标识。请求被发送到一个rpc_queue队列。 RPC Worker（又名：服务器）在队列上等待请求。当出现一个请求时，它执行这个工作，并使用reply_to字段中的队列将结果发送回客户端。客户端在回调队列中等待数据。出现消息时，会检查correlation_id属性。如果它匹配来自请求的值，则返回对应用程序的响应。

全部代码

斐波那契函数：

function fibonacci(n) {
 if (n == 0 || n == 1)
 return n;
 else
 return fibonacci(n - 1) + fibonacci(n - 2);
}

我们声明斐波那契函数。它只假定有效的正整数输入（不要指望这个函数可以使用大数字，因为这可能是最慢的递归实现）。我们的RPC服务器rpc_server.js的代码如下所示：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'rpc_queue';

 ch.assertQueue(q, {durable: false});
 ch.prefetch(1);
 console.log(' [x] Awaiting RPC requests');
 ch.consume(q, function reply(msg) {
 var n = parseInt(msg.content.toString());

 console.log(" [.] fib(%d)", n);

 var r = fibonacci(n);

 ch.sendToQueue(msg.properties.replyTo,
 new Buffer(r.toString()),
 {correlationId: msg.properties.correlationId});

 ch.ack(msg);
 });
 });
});

function fibonacci(n) {
 if (n == 0 || n == 1)
 return n;
 else
 return fibonacci(n - 1) + fibonacci(n - 2);
}

服务器代码非常简单:

像往常一样，我们首先建立连接，通道和声明队列。
我们可能想要运行多个服务器进程。为了在多个服务器上平均分配负载，我们需要在通道上设置prefetch设置。
我们使用Channel.consume来消费队列中的消息。然后我们进入回调函数，在那里做工作，并发回响应。

我们的RPC客户端rpc_client.js的代码：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

var args = process.argv.slice(2);

if (args.length == 0) {
 console.log("Usage: rpc_client.js num");
 process.exit(1);
}

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 ch.assertQueue('', {exclusive: true}, function(err, q) {
 var corr = generateUuid();
 var num = parseInt(args[0]);

 console.log(' [x] Requesting fib(%d)', num);

 ch.consume(q.queue, function(msg) {
 if (msg.properties.correlationId == corr) {
 console.log(' [.] Got %s', msg.content.toString());
 setTimeout(function() { conn.close(); process.exit(0) }, 500);
 }
 }, {noAck: true});

 ch.sendToQueue('rpc_queue',
 new Buffer(num.toString()),
 { correlationId: corr, replyTo: q.queue });
 });
 });
});

function generateUuid() {
 return Math.random().toString() +
 Math.random().toString() +
 Math.random().toString();
}

我们的RPC服务已经准备就绪。我们可以启动服务器：

./rpc_server.js
# => [x] Awaiting RPC requests

运行客户端去请求一个斐波那契数字：

./rpc_client.js 30
# => [x] Requesting fib(30)

这里介绍的设计不是RPC服务的唯一可能的实现，但它有一些重要的优点：

如果RPC服务器速度太慢，可以通过运行另一个来扩展。尝试在新的控制台中运行第二个rpc_server.js。
在客户端，RPC需要发送和接收一条消息。因此，RPC客户端只需要一次网络往返就可以获得一个RPC请求。

我们的代码仍然非常简单，并不试图解决更复杂（但重要）的问题，如：

如果没有服务器运行，客户端应该如何应对？
客户端是否应该对RPC有某种超时？
如果服务器发生故障并引发异常，是否应将其转发给客户端？
在处理之前防止无效的传入消息（例如检查边界，类型）。

Node使用RabbitMQ：主题交换器

Thu, 15 Feb 2018 08:52:19 +0800

前提条件

本教程假定RabbitMQ已安装并在标准端口（5672）上的本地主机上运行。如果您使用不同的主机，端口或凭据，连接设置将需要调整。

（使用amqp.node客户端）

在之前的教程中，我们改良了我们的日志系统。我们没有使用只有虚拟广播的fanout交换器，而是使用direct交换器，提供了有选择性地接收日志的可能性。虽然使用direct交换器改良了我们的系统，但是他还是存在一些限制——它不能根据多种标准路由。在我们的日志系统中，我们可能不仅想要订阅基于严重性级别的日志，可能还有基于日志出处的。你可能从syslog unix工具知道这个概念，它根据严重性（info/warn/crit …）和设备（auth/cron/kern …）来路由日志。这会给我们很大的灵活性——我们可能想要获取来自’cron’的严重错误，而且还要听取来自’kern’的所有日志。为了在我们的日志系统中实现这一点，我们需要了解更复杂的主题（topic）交换器。

主题交换器

发送到主题交换的消息不能有任意的routing_key——它必须是由点分隔的单词列表。单词可以是任何东西，但通常它们指定连接到消息的一些功能。一些有效的路由键例子： stock.usd.nyse，nyse.vmw，quick.orange.rabbit。在路由选择键中可以有许多单词，最多255个字母。绑定键也必须有相同的形式。主题交换器背后的逻辑类似于直接的——使用特定的路由键发送的消息将被传送到与匹配的绑定键绑定的所有队列。但是绑定键有两个重要的特殊情况：

*（星号）可以代替一个单词。
#（井号）可以代替另个或者多个单词。

举个简单的例子：

在这个例子中，我们将发送所有描述动物的信息。消息将使用由三个单词（两个点）组成的路由键发送。路由键中的第一个单词将描述速度，第二个颜色和第三个种类：<speed>.<color>.<species>。我们将创建三个绑定：Q1的绑定键是*.orange.*，Q2是*.*.rabbit和lazy.#。什么含义呢？

Q1对所有橘色动物感兴趣。
Q2想要监听所有的兔子和和所有懒惰的动物。

一条路由键为quick.orange.rabbit将会被分发到两个队列，同样的，lazy.orange.elephant也将被分发到两个队列。而quick.orange.fox只会被发送到第一个队列中，lazy.brown.fox只会被发送到第二个。lazy.pink.rabbit虽然匹配第二个队列中的两个绑定键，但是它只会被发送一次。auick.brown.fox不匹配任何绑定键所以会被直接取消并且被丢掉。如果违反我们的约定，发送一个或四个单词，如orange或quick.orange.male.rabbit的消息会发生什么？它们也将因为不匹配绑定键而被丢掉。另一方面，lazy.orange.male.rabbit即使有四个单词，也会匹配最后一个绑定键，并被传递到第二个队列。

主题交换器 主题交换器功能强大能够拥有其它交换器的功能。当一个队列使用“＃”（井号）绑定键绑定时，它将接收所有的消息，而不管路由键如何——类似于fanout交换器。当在绑定中不使用特殊字符“*”（星号）和“＃”（井号）时，主题交换器将像直接交换器一样。

全部代码

我们将在我们的日志系统中使用主题交换器。我们首先假定日志的路由键有两个单词：<facility>.<severity>。这个代码和前一个教程基本一样。 emit_log_topic.js：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var ex = 'topic_logs';
 var args = process.argv.slice(2);
 var key = (args.length > 0) ? args[0] : 'anonymous.info';
 var msg = args.slice(1).join(' ') || 'Hello World!';

 ch.assertExchange(ex, 'topic', {durable: false});
 ch.publish(ex, key, new Buffer(msg));
 console.log(" [x] Sent %s:'%s'", key, msg);
 });

 setTimeout(function() { conn.close(); process.exit(0) }, 500);
});

receive_logs_topic.js：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

var args = process.argv.slice(2);

if (args.length == 0) {
 console.log("Usage: receive_logs_topic.js <facility>.<severity>");
 process.exit(1);
}

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var ex = 'topic_logs';

 ch.assertExchange(ex, 'topic', {durable: false});

 ch.assertQueue('', {exclusive: true}, function(err, q) {
 console.log(' [*] Waiting for logs. To exit press CTRL+C');

 args.forEach(function(key) {
 ch.bindQueue(q.queue, ex, key);
 });

 ch.consume(q.queue, function(msg) {
 console.log(" [x] %s:'%s'", msg.fields.routingKey, msg.content.toString());
 }, {noAck: true});
 });
 });
});

接受所有日志：

./receive_logs_topic.js "#"

从kern中接受所有日志：

./receive_logs_topic.js "kern.*"

或者，你只想监听critical的日志：

./receive_logs_topic.js "*.critical"

你也可以创建多个绑定：

./receive_logs_topic.js "kern.*" "*.critical"

发送kern.critical类型的日志：

./emit_log_topic.js "kern.critical" "A critical kernel error"

请注意，代码不会对路由或绑定键作任何假设，您可能需要使用两个以上的路由键参数。接下来，在教程6中找出如何做一个远程过程调用的往返消息。

Node使用RabbitMQ：路由

Wed, 14 Feb 2018 08:52:19 +0800

前提条件

本教程假定RabbitMQ已安装并在标准端口（5672）上的本地主机上运行。如果您使用不同的主机，端口或凭据，连接设置将需要调整。

（使用amqp.node客户端）

在之前的教程中，我们构建了一个简单的日志系统我们能够将日志消息广播给许多接收者。在本教程中，我们将添加一个功能——只订阅一部分消息。比如说，我们只把最严重的错误输出到日志文件（写到盘），而在控制台上打印所有的日志信息。

绑定

在前面的教程中我们已经创建过绑定了，这里我们可以重新使用：

ch.bindQueue(q.queue, ex, '');

一个绑定将一个交换器和一个队列关联起来。我们可以这样简单理解：队列将会对该交换器里的消息感兴趣。绑定可以采用额外的绑定键参数（上面代码中的空字符串）。这是我们如何创建一个带key的绑定：

ch.bindQueue(queue_name, exchange_name, 'black');

绑定键的含义取决于交换类型。我们之前使用的fanout交换机，简单地忽略了它的值。

直接交换器（Direct exchange）

我们在前面的教程中创建的日志系统将广播所有的信息给消费者。我们希望扩展这个功能，以便根据消息的严重性来过滤消息。例如我们可能希望将日志写入磁盘的脚本只接收到严重的错误，而不会浪费磁盘去存储info和warning的日志。我们之前使用了一个fanout交换器，这并没有给我们太大的灵活性——它只能够无意识地广播。现在我们使用direct交换器代替。direct交换器背后的路由算法很简单——消息将进入binding key与消息的routing key完全匹配的队列。为了阐释清楚，我们可以参考一下示意图：

如图，我们可以看到direct交换器X绑定了两个队列。第一个队列的绑定键是orange，第二个队列有两个绑定，两个绑定键分别是black和green。此图中，发布一个路由键为orange的消息到交换器中，将被路由到Q1队列中。路由键为black或者是green的消息将路由到Q2队列中。所有其他消息将被取消。

多绑定

相同的绑定键绑定多个队列是完全合法的。在上述例子中，我们完全可以使用绑定键black绑定X和Q1。如此一来这个直接交换器就跟删除交换器一样将会把消息广播给匹配的队列。带有路由键black的消息将被同时推送到Q1和Q2。

发送日志

我们将使用我们的日志系统模型，以直接交换器代替删除交换器，以日志的严重性级别作为路由键。这样接收脚本可以选择自己想接收的级别的日志。我们先关注发送日志。我们总需要首先去创建一个交换器：

var ex = 'direct_logs';

ch.assertExchange(ex, 'direct', {durable: false});

然后准备发送一个消息：

var ex = 'direct_logs';

ch.assertExchange(ex, 'direct', {durable: false});
ch.publish(ex, severity, new Buffer(msg));

为了简化事情，我们将假定“严重性”可以是info，warning，error之一。

全部代码

emit_log_direct.js脚本的代码：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var ex = 'direct_logs';
 var args = process.argv.slice(2);
 var msg = args.slice(1).join(' ') || 'Hello World!';
 var severity = (args.length > 0) ? args[0] : 'info';

 ch.assertExchange(ex, 'direct', {durable: false});
 ch.publish(ex, severity, new Buffer(msg));
 console.log(" [x] Sent %s: '%s'", severity, msg);
 });

 setTimeout(function() { conn.close(); process.exit(0) }, 500);
});

receive_logs_direct.js的代码：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

var args = process.argv.slice(2);

if (args.length == 0) {
 console.log("Usage: receive_logs_direct.js [info] [warning] [error]");
 process.exit(1);
}

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var ex = 'direct_logs';

 ch.assertExchange(ex, 'direct', {durable: false});

 ch.assertQueue('', {exclusive: true}, function(err, q) {
 console.log(' [*] Waiting for logs. To exit press CTRL+C');

 args.forEach(function(severity) {
 ch.bindQueue(q.queue, ex, severity);
 });

 ch.consume(q.queue, function(msg) {
 console.log(" [x] %s: '%s'", msg.fields.routingKey, msg.content.toString());
 }, {noAck: true});
 });
 });
});

如果只想保存“警告”和“错误”（而不是“信息”），则将消息记录到文件中，只需打开控制台并输入:

./receive_logs_direct.js warning error > logs_from_rabbit.log

如果您想要在屏幕上查看所有日志消息，请打开一个新终端并执行以下操作:

./receive_logs_direct.js info warning error
# => [*] Waiting for logs. To exit press CTRL+C

而且，例如，要输出错误日志消息，只需键入：

./emit_log_direct.js error "Run. Run. Or it will explode."
# => [x] Sent 'error':'Run. Run. Or it will explode.'

转到教程5，了解如何根据模式来侦听消息。

Node使用RabbitMQ：发布与订阅

Tue, 13 Feb 2018 08:52:19 +0800

前提条件

本教程假定RabbitMQ已安装并在标准端口（5672）上的本地主机上运行。如果您使用不同的主机，端口或凭据，连接设置将需要调整。

（使用amqp.node客户端）

在前面的教程中，我们创建了一个工作队列，假设每个任务只被传递给一个Worker。在这一部分，我们将做一些完全不同的事情——我们会向多个消费者传递信息。这种模式被称为“发布与订阅”。为了说明这个模式，我们将建立一个简单的日志系统。它将包含两个程序 - 第一个将发送日志消息，第二个将接收并打印它们。在我们的日志系统中，接收程序的每个运行副本都会收到消息。这样我们就可以运行一个接收器并将日志定向到磁盘，同时将能够运行另一个接收器并输出到屏幕上以便查看日志。本质上，发布的日志消息将被广播给所有的接收者。

交换器（exchange）

在本教程的前面部分，我们发送和接收来自队列的消息。现在是时候在Rabbit中引入完整的消息模型了。让我们快速回顾一下前面的教程中介绍的内容：

生产者（producer）是发送消息的用户应用程序。
队列（queue）是存储消息的缓冲区。
消费者（consumer）是接收消息的用户应用程序。

RabbitMQ中消息传递模型的核心思想是生产者永远不会将任何消息直接发送到队列中。实际上，生产者通常甚至不知道邮件是否会被传送到任何队列中。生产者只能将消息发送给交换器。交换器非常简单，它一面接受来自生产者的消息，一面将接收到的消息推送给队列。交换器必须知道如何处理接收到的消息：是否应该附加到特定的队列？是否应该附加到许多队列？还是应该丢弃。这些规则是由交换类型定义的。

有几种可用的交换类型：direct，topic，headers和fanout。我们将关注最后一个 ——fanout。让我们创建一个这种类型的交换器，并将其称为logs：

ch.assertExchange('logs', 'fanout', {durable: false})

fanout交换非常简单。正如你可能从名字中猜到的那样，它只是将所有收到的消息广播到它所知道的所有队列中。这正是我们日志系统所需要的。

列出交换器 要列出服务器上的交换，您可以运行有用的rabbitmqctl：
sudo rabbitmqctl list_exchanges
在这个列表中将会有一些amq.*交换和默认（未命名）交换。这些是默认创建的，但目前不太可能需要使用它们。 默认交换器 在本教程的以前部分，我们对交换器一无所知，但仍能够将消息发送到队列。这是可能的，因为我们正在使用一个默认的交换，这是由空字符串（""）标识。回顾一下我们之前如何发布消息：

ch.sendToQueue('hello', new Buffer('Hello World!'));

这里我们使用默认的或无名的交换：消息被路由到队列中，如果它存在的话，该消息被指定为第一个参数。

现在，我们可以发布到我们的命名交换：

ch.publish('logs', '', new Buffer('Hello World!'));

作为第二个参数的空字符串意味着我们不想将消息发送到任何特定的队列。我们只想将其发布到我们的logs交换器。

临时队列

正如你以前可能记得我们使用的是具有指定名称的队列（请记住hello和task_queue？）。给队列命名是很重要的——我们需要给Workers指定相同的队列。当你想在生产者和消费者之间共享队列时，一定要给队列命名。但是我们的日志系统并不是这样。我们想要监听所有日志消息，而不仅仅是其中的一部分。我们也只对目前流动的消息感兴趣，而不是旧消息。要解决这个问题，我们需要两件事。首先，每当我们连接到Rabbit，我们需要一个新的、空的队列。要做到这一点，我们可以创建一个随机名称的队列，或者最好是让服务器为我们选择一个随机队列名称。其次，一旦我们断开消费者，队列应该被自动删除。在amqp.node客户端中，当我们将队列名称作为空字符串提供时，我们使用生成的名称创建一个非持久队列：

ch.assertQueue('', {exclusive: true});

当方法返回时，队列实例包含由RabbitMQ生成的随机队列名称。例如，它可能看起来像amq.gen-JzTY20BRgKO-HjmUJj0wLg。当声明它的连接关闭时，队列将被删除，因为它被声明为独占（exclusive）。

绑定

我们已经创建了一个扇出交换器和一个队列。现在我们需要告诉交换器把消息发送到我们的队列。交换器和队列之间的关系被称为绑定。

ch.bindQueue(queue_name, 'logs', '');

此后，logs交换器将把消息附加到我们的队列中。

列出绑定 你可以通过以下方式列出所有的绑定：
rabbitmqctl list_bindings

全部代码

发出日志消息的生产者程序与前面的教程没有什么不同。最重要的变化是，我们现在要发布消息到我们的logs交换器，而不是无名的。发送时我们需要提供一个路由键，但是对于扇出交换器，它的值将被忽略。这里是emit_log.js脚本的代码：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var ex = 'logs';
 var msg = process.argv.slice(2).join(' ') || 'Hello World!';

 ch.assertExchange(ex, 'fanout', {durable: false});
 ch.publish(ex, '', new Buffer(msg));
 console.log(" [x] Sent %s", msg);
 });

 setTimeout(function() { conn.close(); process.exit(0) }, 500);
});

如你所见，建立连接后，我们声明交换器。这一步是必要的，因为不允许发布到一个不存在的交换器。如果没有队列绑定到交换机上，消息将会丢失，但对我们来说没关系；如果没有消费者正准备接收，我们可以放心地丢弃消息。 receive_logs.js的代码：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var ex = 'logs';

 ch.assertExchange(ex, 'fanout', {durable: false});

 ch.assertQueue('', {exclusive: true}, function(err, q) {
 console.log(" [*] Waiting for messages in %s. To exit press CTRL+C", q.queue);
 ch.bindQueue(q.queue, ex, '');

 ch.consume(q.queue, function(msg) {
 console.log(" [x] %s", msg.content.toString());
 }, {noAck: true});
 });
 });
});

如果您想将日志保存到文件中，只需打开一个控制台并输入：

./receive_logs.js > logs_from_rabbit.log

如果你想看到屏幕上的日志，开启一个新的终端，并运行：

./receive_logs.js

发送日志，需要输入：

./emit_log.js

使用rabbitmqctl list_bindings，你可以验证代码实际上是否创建了绑定和队列。若有两个receive_logs.js程序运行，你应该看到如下结果：

sudo rabbitmqctl list_bindings
# => Listing bindings ...
# => logs exchange amq.gen-JzTY20BRgKO-HjmUJj0wLg queue []
# => logs exchange amq.gen-vso0PVvyiRIL2WoV3i48Yg queue []
# => ...done.

结果的解释很简单：logs交换器中的数据发送到两个带有服务器分配名称的队列中。这正是我们想要的。关于如何监听消息子集，我们可以继续阅读教程4。

Node使用RabbitMQ：工作队列

Mon, 12 Feb 2018 08:52:19 +0800

前提条件

本教程假定RabbitMQ已安装并在标准端口（5672）上的本地主机上运行。如果您使用不同的主机，端口或凭据，连接设置将需要调整。

（使用amqp.node客户端）

在第一个教程中，我们编写了用于从命名队列发送和接收消息的程序。在这一个中，我们将创建一个工作队列，用于在多个Worker之间分配耗时的任务。工作队列（又名：任务队列）主要目的是避免立即执行资源密集型任务，避免必须等待任务完成。取而代之的是，安排稍后完成任务。我们把一个任务封装成一个消息并发送给一个队列。在后台运行的工作进程将弹出任务并最终执行作业。当你运行许多Worker时，任务将在他们之间共享。这个概念在web应用程序中特别有用，在短的HTTP请求窗口中不可能处理复杂的任务。

准备

在本教程的前一部分，我们发送了一个包含“Hello World！”的消息。现在我们将发送代表复杂任务的字符串。我们没有真正的任务，比如图像被重新调整大小或者渲染PDF文件，所以让我们假装我们忙——通过使用setTimeout方法。我们稍微修改前面例子中的send.js代码，以允许从命令行发送任意消息。这个程序将安排任务到我们的工作队列，所以让我们把它命名为new_task.js：

var q = 'task_queue';
var msg = process.argv.slice(2).join(' ') || "Hello World!";

ch.assertQueue(q, {durable: true});
ch.sendToQueue(q, new Buffer(msg), {persistent: true});
console.log(" [x] Sent '%s'", msg);

我们旧的receive.js脚本也需要进行一些更改：它需要伪造邮件正文中每个点的第二个工作。它将从队列中弹出消息并执行任务，所以我们称之为worker.js：

ch.consume(q, function(msg) {
 var secs = msg.content.toString().split('.').length - 1;

 console.log(" [x] Received %s", msg.content.toString());
 setTimeout(function() {
 console.log(" [x] Done");
 }, secs * 1000);
}, {noAck: true});

请注意，我们的假任务模拟执行时间。按照教程1运行它们：

# shell 1
./worker.js

# shell 2
./new_task.js

循环调度

使用任务队列的优点之一是能够轻松地平行工作。如果我们积压工作，我们可以增加更多的工人，这样可以轻松扩展。首先，我们试着同时运行两个worker.js脚本。他们都会从队列中得到消息，但究竟是如何？让我们来看看。您需要打开三个控制台。两个将运行worker.js脚本。这些控制台将是我们的两个消费者——C1和C2。

# shell 1
./worker.js
# => [*] Waiting for messages. To exit press CTRL+C

# shell 2
./worker.js
# => [*] Waiting for messages. To exit press CTRL+C

在第三个，我们将发布新的任务。一旦你开始了消费者，你可以发布一些消息：

# shell 3
./new_task.js First message.
./new_task.js Second message..
./new_task.js Third message...
./new_task.js Fourth message....
./new_task.js Fifth message.....

让我们看看交给我们工人的东西：

# shell 1
./worker.js
# => [*] Waiting for messages. To exit press CTRL+C
# => [x] Received 'First message.'
# => [x] Received 'Third message...'
# => [x] Received 'Fifth message.....'

# shell 2
./worker.js
# => [*] Waiting for messages. To exit press CTRL+C
# => [x] Received 'Second message..'
# => [x] Received 'Fourth message....'

默认情况下，RabbitMQ将按顺序将每条消息发送给下一个使用者。平均而言，每个消费者将获得相同数量的消息。这种分发消息的方式称为循环法（round-robin）。试试三个或更多的Worker。

消息确认

做任务可能需要几秒钟的时间。你可能会想知道如果其中一个消费者开始一个长期的任务，并且只是部分完成就死掉了会发生什么。使用我们当前的代码，一旦RabbitMQ向客户发送消息，立即将其标记为删除。在这种情况下，如果你杀死了一个Worker，我们将失去刚刚处理的信息，也将失去所有派发给这个特定工作人员但尚未处理的消息。但我们不想失去任何任务。如果一个Worker死掉，我们希望将任务交付给另一个Worker。为了确保消息永不丢失，RabbitMQ支持消息确认。消费者发回确认（告知）告诉RabbitMQ已经收到，处理了一个特定的消息，并且RabbitMQ可以自由删除它。如果消费者死掉（其通道关闭，连接关闭或TCP连接丢失），RabbitMQ将认为消息未被完全处理，并将重新排队。如果同时有其他消费者在线，则会迅速重新发送给另一个消费者。这样，即使Worker死掉，也可以确保没有任何信息丢失。没有任何消息超时；当消费者死掉时，RabbitMQ将重新传递消息。即使处理消息需要非常长的时间也没关系。在前面的例子中，消息确认是被关闭的。现在使用{noAck：false}来打开它们（您也可以完全删除选项），并在完成任务后从Worker发送正确的确认。

ch.consume(q, function(msg) {
 var secs = msg.content.toString().split('.').length - 1;

 console.log(" [x] Received %s", msg.content.toString());
 setTimeout(function() {
 console.log(" [x] Done");
 ch.ack(msg);
 }, secs * 1000);
}, {noAck: false});

使用这段代码，我们可以确定，即使在处理消息的时候使用CTRL+C来杀死一个Worker，也不会丢失任何东西。Worker死后不久，所有未确认的消息将被重新发送。

忘记确认 丢掉ack是一个常见的错误。这个错误很容易发生，但是后果很严重。当你的客户退出时（这可能看起来像随机的重新传递），消息将被重新传递，但是RabbitMQ将会消耗越来越多的内存，因为它将不能释放任何未被确认的消息。

为了调试这种错误，你可以使用非rabbitmqctl打印messages_unacknowledged字段：

sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged

在Windows上去掉sudo：

rabbitmqctl.bat list_queues name messages_ready messages_unacknowledged

消息持久性

我们已经学会了如何确保即使消费者死掉，任务也不会丢失。但是如果RabbitMQ服务器停止，我们的任务仍然会丢失。除非我们设置好，否则当RabbitMQ退出或崩溃时，它会忘记队列和消息。需要做两件事来确保消息不会丢失：我们需要将队列和消息标记为持久。首先，我们需要确保RabbitMQ永远不会失去队列。为了做到这一点，我们需要宣布它是持久的：

ch.assertQueue('hello', {durable: true});

虽然这个命令本身是正确的，但是在我们目前的设置中不起作用。这是因为我们已经定义了一个名为hello的队列，这个队列并不具有持久性。RabbitMQ不允许你使用不同的参数重新定义一个已经存在的队列，并且会向任何尝试这样做的程序返回一个错误。但有一个快速的解决方法——声明一个不同名称的队列，例如task_queue：

ch.assertQueue('task_queue', {durable: true});

这个durable的选项更改需要应用于生产者和消费者代码。此时我们确信，即使RabbitMQ重新启动，task_queue队列也不会丢失。现在我们需要将消息标记为持久的——通过使用Channel.sendToQueue持久选项。

ch.sendToQueue(q, new Buffer(msg), {persistent: true});

注意消息持久性 将消息标记为永久并不能完全保证消息不会丢失。尽管它告诉RabbitMQ将消息保存到磁盘，但是当RabbitMQ接收到消息并且还没有保存消息时，仍然有一个很短的时间窗口。此外，RabbitMQ不会为每个消息执行fsync(2)——它可能只是保存到缓存中，而不是写入磁盘。持久性保证不强，但对于我们简单的任务队列已经足够了。如果您需要更强大的保证，那么您可以使用发布者确认。

公平调度

您可能已经注意到调度仍然不能按照我们的要求工作。例如在有两个Worker的情况下，当所有第奇数个消息都很重且第偶数个消息都很轻的时候，一个Worker就会一直很忙，而另一个Worker几乎不会做任何工作。然而，RabbitMQ不知道任何有关的信息，并将仍然均匀地发送消息。发生这种情况是因为RabbitMQ只在消息进入队列时调度消息。它没有考虑消费者未确认消息的数量。它只是盲目地把第n条消息分发给第n个消费者。

为了解决这个问题，我们可以使用值为1的prefetch方法。这告诉RabbitMQ一次不能给一个Worker多个消息。或者换句话说，在处理完前一个消息之前，不要向Worker发送新消息，它会将新消息分派给下一个还不忙的Worker。

ch.prefetch(1);

关于队列大小的说明 如果所有的Worker都很忙，你的队伍就可能填满了。你可能想要会增加更多的Worker，或者有其他的策略。

全部代码

new_task.js的最终代码：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'task_queue';
 var msg = process.argv.slice(2).join(' ') || "Hello World!";

 ch.assertQueue(q, {durable: true});
 ch.sendToQueue(q, new Buffer(msg), {persistent: true});
 console.log(" [x] Sent '%s'", msg);
 });
 setTimeout(function() { conn.close(); process.exit(0) }, 500);
});

work.js

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'task_queue';

 ch.assertQueue(q, {durable: true});
 ch.prefetch(1);
 console.log(" [*] Waiting for messages in %s. To exit press CTRL+C", q);
 ch.consume(q, function(msg) {
 var secs = msg.content.toString().split('.').length - 1;

 console.log(" [x] Received %s", msg.content.toString());
 setTimeout(function() {
 console.log(" [x] Done");
 ch.ack(msg);
 }, secs * 1000);
 }, {noAck: false});
 });
});

使用消息确认和prefetch可以设置一个工作队列。即使RabbitMQ重新启动，持久性选项也能让任务继续存在。有关Channel方法和消息属性的更多信息，可以浏览amqplib文档。现在我们可以继续阅读教程3，并学习如何向许多消费者传递相同的消息。

Node使用RabbitMQ：入门篇

Sun, 11 Feb 2018 08:52:19 +0800

前提条件

本教程假定RabbitMQ已安装并在本地主机的标准端口（5672）上运行。如果您使用不同的主机，端口或凭据，连接设置将需要调整。

简介

RabbitMQ是一个消息broker：它接受和转发消息。你可以把它想象成一个邮局：当你把邮件放在邮箱里时，你可以确定邮差先生最终会把邮件发送给你的收件人。在这个比喻中，RabbitMQ是整个邮政系统即信箱、邮局和邮递员。 RabbitMQ与邮局的主要区别是它不处理纸张，而是接受，存储和转发数据的二进制数据块——消息。 RabbitMQ和一般的消息传递使用了一些术语。

生产（producing）只不过是发送而已。一个发送消息的程序是一个生产者（producer）：

队列（queue）是RabbitMQ内部的邮箱名称。尽管消息流经RabbitMQ和您的应用程序，但它们只能存储在队列（queue）中。队列（queue）只受主机的内存和磁盘限制，实质上是一个大的消息缓冲区。许多生产者（producer）可以发送消息到一个队列（queue），许多消费者（consumers）可以尝试从一个队列（queue）接收数据。这就是我们代表队列（queue）的方式：

消费（consuming）与接受有类似的意义。消费者（consumer）是主要等待接收消息的程序：

请注意，producer，consumer和broker不必在同一主机上；事实上在大多数应用程序中都不会。

(使用amqp.node客户端)

在本教程的这一部分，我们将用Node编写两个小程序；发送单个消息的生产者，以及接收消息并将其打印出来的消费者。我们将详细介绍amqp.node API中的一些细节，将注意力集中在这个非常简单的事情上，以便开始。这是一个消息传递的“Hello World”。在下图中，“P”是我们的生产者，“C”是我们的消费者。中间的盒子是一个队列——RabbitMQ消费者的消息缓冲区。

amqp.node客户端库 RabbitMQ提供多种协议。本教程使用AMQP 0-9-1，这是一个开放，通用的消息传递协议。 RabbitMQ有许多不同的语言客户端。我们将在本教程中使用amqp.node客户端。首先，使用npm安装amqp.node：

npm install amqplib

现在我们安装了amqp.node，我们可以写一些代码。

发送端

我们将调用我们的消息发布者（发送者）send.js和我们的消息使用者（接收者）receive.js。发布者将连接到RabbitMQ，发送一条消息，然后退出。在send.js中，我们需要首先需要库：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

然后连接到RabbitMQ服务器

amqp.connect('amqp://localhost', function(err, conn) {});

接下来我们创建一个频道（channel），这是大部分API所需要做的：

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {});
});

发送，我们必须申报队列给我们发送；然后我们可以发布消息到队列中：

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'hello';

 ch.assertQueue(q, {durable: false});
 // Note: on Node 6 Buffer.from(msg) should be used
 ch.sendToQueue(q, new Buffer('Hello World!'));
 console.log(" [x] Sent 'Hello World!'");
 });
});

声明一个队列是幂等的——只有当它不存在时才会被创建。消息内容是一个字节数组，所以你可以使用任何编码。最后，我们关闭连接并退出：

setTimeout(function() { conn.close(); process.exit(0) }, 500);

所以，整个代码如下：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'hello';
 var msg = 'Hello World!';

 ch.assertQueue(q, {durable: false});
 // Note: on Node 6 Buffer.from(msg) should be used
 ch.sendToQueue(q, new Buffer(msg));
 console.log(" [x] Sent %s", msg);
 });
 setTimeout(function() { conn.close(); process.exit(0) }, 500);
});

发送端故障 如果这是您第一次使用RabbitMQ，并且您没有看到“已发送”消息，那么您可能会不知所措。也许broker启动没有足够的可用磁盘空间（默认情况下，它至少需要200 MB空闲空间），因此拒绝接受消息。检查代理日志文件以确认并在必要时减少限制。配置文件文档将告诉你如何设置disk_free_limit。

接收端

这是我们的接收方。消费者获取从RabbitMQ推送的消息，因此与发布单个消息的发布者不同，我们将持续运行以监听消息并将其打印出来。

代码（在receive.js中）和send有相同的要求：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

设置与发布者相同；我们打开一个连接和一个通道，并声明我们将要使用的队列。注意这与sendToQueue发布到的队列相匹配。

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'hello';

 ch.assertQueue(q, {durable: false});
 });
});

请注意，我们在这里也声明队列。因为我们可能会在发布者之前启动消费者，所以我们希望确保队列存在，然后再试图使用消息。我们即将告诉服务器将队列中的消息传递给我们。由于它会异步推送消息，因此我们提供了一个回调函数，当RabbitMQ向消费者推送消息时，将执行回调函数。这是Channel.consume所做的。

console.log(" [*] Waiting for messages in %s. To exit press CTRL+C", q);
ch.consume(q, function(msg) {
 console.log(" [x] Received %s", msg.content.toString());
}, {noAck: true});

完整receive.js如下：

#!/usr/bin/env node

var amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function(err, conn) {
 conn.createChannel(function(err, ch) {
 var q = 'hello';

 ch.assertQueue(q, {durable: false});
 console.log(" [*] Waiting for messages in %s. To exit press CTRL+C", q);
 ch.consume(q, function(msg) {
 console.log(" [x] Received %s", msg.content.toString());
 }, {noAck: true});
 });
});

执行

现在我们可以运行这两个脚本。在终端中，运行发布者：

./send.js

然后运行接收者：

./receive.js

消费者将通过RabbitMQ打印从发布者处获得的消息。消费者将继续运行，等待消息（使用Ctrl-C停止它），所以尝试从另一个终端运行发布者。

列出队列 你可能想看看RabbitMQ有什么队列，有多少条消息。您可以作为特权用户使用rabbitmqctl工具执行此操作：
sudo rabbitmqctl list_queues
在Windows上，省略sudo：
rabbitmqctl.bat list_queues

详解VMware vCenter Server

Thu, 25 Jan 2018 08:52:19 +0800

作为vSphere的核心主键之一的 vCenter Server 可以部署在Linux上或者是Windows上，在Linux上被称为 vCenter Server Appliance。根据 Platform Services Controller 所部署的位置的不同，有以下几种部署类型：

部署类型	描述
具有嵌入式 Platform Services Controller 部署的 vCenter Server	与 Platform Services Controller 捆绑在一起的所有服务与 vCenter Server 服务一起部署在同一虚拟机或物理服务器上。
Platform Services Controller	只有与 Platform Services Controller 捆绑在一起的服务会部署在虚拟机或物理服务器上。
具有外部 Platform Services Controller 的 vCenter Server （需要外部 Platform Services Controller）	只有 vCenter Server 服务会部署在虚拟机或物理服务器上。必须向之前部署或安装的 Platform Services Controller 实例注册此类 vCenter Server 实例。

vSphere 和 vCenter Server

Tue, 23 Jan 2018 08:52:19 +0800

VMware vSphere 是一套虚拟化应用程序，包括 ESXi 和 vCenter Server。 vSphere 使用虚拟化执行以下任务：

在一台物理机上同时运行多个操作系统。
回收闲置资源并在多台物理机之间平衡工作负载。
处理硬件故障和预定维护。

熟悉构成 vSphere 环境的组件有助于理解设置过程，并最终理解使用 VMware vCenter Server 管理主机和运行虚拟机的过程。除了 ESXi 主机和 vSphere Client 之外，vSphere 还包括以下组件：

vSphere Web Client vSphere Web Client 是连接到 vCenter Server 和多主机环境的接口。另外，它还提供对虚拟机的控制台访问。借助 vSphere Web Client，您可以使用浏览器内界面执行所有管理任务。

VMware vCenter Server vCenter Server 将各台主机中的资源统一在一起，使这些资源可以在整个数据中心的虚拟机之间共享。其实现原理是：根据系统管理员设定的策略，管理主机的虚拟机分配，以及给定主机内虚拟机的资源分配。 vCenter Server 允许使用 vSphere 的高级功能，如 vSphere Distributed Resource Scheduler (DRS)、vSphere High Availability (HA)、vSphere vMotion 和 vSphere Storage vMotion。

数据中心 数据中心是一种结构，在该结构中，可以向清单中添加主机及其相关虚拟机。

主机主机是使用 ESXi 虚拟化软件来运行虚拟机的计算机。主机为驻留在其上的虚拟机提供 CPU 和内存资源、对存储器的访问以及网络连接。

虚拟机 与物理机一样，虚拟机是运行操作系统和应用程序的软件计算机。多个虚拟机可在同一主机上同时运行。由 vCenter Server 管理的虚拟机也可在主机群集上运行。下图显示了 vSphere 基本组件之间的关系，以及如何使用 vCenter Server 管理主机和运行虚拟机。

vSphere 组件

vCenter Server 组件和服务

Sun, 21 Jan 2018 08:52:19 +0800

摘自于VMware官方文档，移至自己博客方便阅读，如有侵权，请联系我删除

vCenter Server 为虚拟机和主机的管理、操作、资源置备和性能评估提供了一个集中式平台。安装具有嵌入式 Platform Services Controller 的 vCenter Server 或部署具有嵌入式 Platform Services Controller 的 vCenter Server Appliance 时，vCenter Server、vCenter Server 组件以及 Platform Services Controller 中包含的服务将部署在同一个系统上。安装具有外部 Platform Services Controller 的 vCenter Server 或部署具有外部 Platform Services Controller 的 vCenter Server Appliance 时，vCenter Server 和 vCenter Server 组件将部署在一个系统上，而 Platform Services Controller 中包含的服务将部署在另一个系统上。以下组件包含在 vCenter Server 和 vCenter Server Appliance 安装中：

VMware Platform Services Controller 基础架构服务组包含 vCenter Single Sign-On、License Service、Lookup Service 和 VMware Certificate Authority。
vCenter Server 服务组包含 vCenter Server、vSphere Web Client、vSphere Auto Deploy 和 vSphere ESXi Dump Collector。适用于 Windows 的 vCenter Server 还包含 VMware vSphere Syslog Collector。vCenter Server Appliance 还包含 VMware vSphere Update Manager 扩展服务。

注：从 vSphere 6.5 开始，所有 vCenter Server 服务和部分 Platform Services Controller 服务作为 VMware Service Lifecycle Manager 服务的子进程运行。

随 VMware Platform Services Controller 一起安装的服务

vCenter Single Sign-On

vCenter Single Sign-On 身份验证服务为 vSphere 软件组件提供了安全身份验证服务。使用 vCenter Single Sign-On，vSphere 组件可通过安全的令牌交换机制相互通信，而无需每个组件使用目录服务（如 Active Directory）分别对用户进行身份验证。vCenter Single Sign-On 可构建内部安全域（如 vsphere.local），vSphere 解决方案和组件将在安装或升级期间在该域中进行注册，从而提供基础架构资源。vCenter Single Sign-On 可以通过其自己的内部用户和组对用户进行身份验证，或者可以连接到受信任的外部目录服务（如 Microsoft Active Directory）。然后，可以在 vSphere 环境中为经过身份验证的用户分配基于注册的解决方案的权限或角色。 vCenter Server 需要 vCenter Single Sign-On。

vSphere License Service

vSphere License Service 为连接到单个 Platform Services Controller 或多个链接的 Platform Services Controller 的所有 vCenter Server 系统提供公共许可证清单和管理功能。

VMware Certificate Authority

默认情况下，VMware Certificate Authority (VMCA) 将使用以 VMCA 作为 root 证书颁发机构的签名证书置备每个 ESXi 主机。以显式方式将 ESXi 主机添加到 vCenter Server 时进行置备，或在 ESXi 主机安装过程中进行置备。所有 ESXi 证书都存储在本地主机上。有关所有 Platform Services Controller 服务和功能的信息，请参见Platform Services Controller 管理。

随 vCenter Server 一起安装的服务

安装 vCenter Server 时，将以静默方式安装这些附加组件。这些组件不能单独安装，因为它们没有其自己的安装程序。 PostgreSQL VMware 分发的用于 vSphere 和 vCloud Hybrid Service 的 PostgreSQL 数据库捆绑版本。 vSphere Web Client 通过 vSphere Web Client，可以使用 Web 浏览器连接到 vCenter Server 实例，以便管理 vSphere 基础架构。 vSphere Client 通过新用户界面，可以使用 Web 浏览器连接到 vCenter Server 实例。术语、拓扑及工作流与 vSphere Web Client 用户界面的相同方面和元素保持高度一致。

注：在 vSphere 6.5 版本中，并未针对 vSphere Client 实现 vSphere Web Client 中的所有功能。有关不受支持的功能的最新列表，请参见《vSphere Client 功能更新指南》，网址为 https://www.vmware.com/info?id=1413。

vSphere ESXi Dump Collector

vCenter Server 支持工具。可以将 ESXi 配置为在系统发生严重故障时将 VMkernel 内存保存到网络服务器而非磁盘。vSphere ESXi Dump Collector 将通过网络收集这些内存转储。

VMware vSphere Syslog Collector

Windows 上的 vCenter Server 支持工具，支持网络日志记录，并可将多台主机的日志合并。您可以使用 vSphere Syslog Collector 将 ESXi 系统日志定向到网络服务器而非本地磁盘。对于支持的从中收集日志的主机，建议的最大数目为 30 个。有关配置 vSphere Syslog Collector 的信息，请参见 https://kb.vmware.com/kb/2021652。 vCenter Server Appliance 使用 Linux OS 内置的 Rsyslog 服务。有关如何通过设备管理界面将日志文件重定向到其他计算机的信息，请参见vCenter Server Appliance 配置。

vSphere Auto Deploy

vCenter Server 支持工具，能够使用 ESXi 软件置备大量物理主机。可以指定要部署的映像以及要使用此映像置备的主机。也可以指定应用到主机的主机配置文件，并且为每个主机指定 vCenter Server 位置（文件夹或群集）。

VMware vSphere Update Manager 扩展

Update Manager 可让 VMware vSphere 执行集中式自动修补程序和版本管理，并提供对 VMware ESXi 主机、虚拟机和虚拟设备的支持。VMware vSphere Update Manager 扩展是单独使用的 vCenter Server Appliance 6.5 的可选服务。

Ironic裸机服务——OpenStack

Mon, 11 Dec 2017 08:54:08 +0800

OpenStack为用户提供裸机服务（区别于虚拟机），该服务在OpenStack项目中被称作ironic。它可以独立使用或者作为OpenStack Cloud的一部分使用，并与OpenStack认证（keystone），计算（nova），网络（neutron），图像（glance）和对象存储（swift）服务集成。当裸机服务适当配置了计算和网络服务时，可以使用计算服务的API来配置裸机。不过，由于物理服务器和交换机硬件的特性不同，对于裸机实例的操作很有限。例如，实时迁移不能在裸机实例上执行。为了涵盖广泛的硬件，OpenStack社区利用开源技术（例如，PXE和IPMI）的参考驱动程序。 Ironic的可插拔驱动架构还允许硬件供应商编写和提供驱动程序来提高性能或补充社区驱动程序未提供的功能。

为何提供裸机？

以下是在云上裸机（物理服务器）的一些案例，当然有许多其它更有趣的：

高性能计算集群
使用无法虚拟化的设备
数据库托管（某些数据库在hypervisor中效果不好）
单租户，专用硬件的性能，安全性，可靠性和其他监管要求
快速部署云基础架构

概念架构

下图显示了配置物理服务器期间的关系以及所有服务如何发挥作用。（注：Ceilometer和Swift也可以和Ironic一起使用，此处未标出）

逻辑架构

下图显示了逻辑体系结构。它显示了构成Ironic服务的基本组件，Ironic服务与其他OpenStack服务的关系以及引导实例请求导致物理服务器供应的逻辑流程。

Ironic由以下组件构成：

一个RESTful API服务，管理员或者其他服务可以通过这个服务与被管理的裸机进行交互。
一个Conductor服务，主导大部分工作。通过API服务暴露功能，Conductor和API通过RPC通信。
各种支持异构硬件的驱动。
一个消息队列。
用于存储包括Conductor状态，节点（物理服务器）和驱动程序等资源信息的数据库。

如Figure 1.2所示，用户请求通Nova API和Nova Scheduler启动Nova 计算服务的一个实例。计算服务将此请求移交给Ironic服务，在Ironic服务中，请求从Ironic API传递到Conductor，再传递给驱动程序，为用户成功配置物理服务器。就像Nova计算服务通知诸如Glance、Neutron、Swift等不同的OpenStack服务去创建一个虚拟机实例一样，此处Ironic服务也通知相同的网络、镜像以及其他的一些服务去创建一个裸机实例。

Ironic的关键技术

预启动执行环境（PXE）

PXE是由英特尔和微软开发的Wired for Management（WfM）规范的一部分。PXE使系统的BIOS和网络接口卡（NIC）从网络而非磁盘引导计算机。Bootstrapping是系统将OS加载到本地内存以便处理器执行的过程。该功能简化了管理员的服务器部署和管理。

动态主机配置协议（DHCP）

DHCP是在IP网络上使用的标准化网络协议，用于动态分配网络配置参数，例如接口或者服务的IP地址。使用PXE，BIOS使用DHCP获取网络接口的IP地址，并找到存储网络引导程序（NBP）的服务器。

网络引导程序（NBP）

NBP相当于GRUB（GRand Unified Bootloader）或LILO（LInux LOader）—— 用于本地启动的传统加载器。像硬盘环境中的引导程序一样，NBP负责将OS内核加载到内存中，以便可以通过网络引导操作系统。

简单文件传输协议（TFTP）

TFTP是一种简单的文件传输协议，通常用于在本地环境中的机器之间自动传输配置或启动文件。在PXE环境中，TFTP使用来自DHCP服务器的信息通过网络下载NBP。

智能平台管理接口（IPMI）

IPMI是系统管理员用于计算机系统的带外管理和操作监控的标准化计算机系统接口。这是一种通过仅使用硬件的网络连接而不是操作系统来管理可能无响应或断电的系统的方法。

Ironic部署架构

Ironic RESTful API服务用于注册Ironic将管理的硬件。云管理员通常会注册硬件，指定其属性（如MAC地址和IPMI凭证）。可以有多个API服务实例。在Ironic中Conductor负责大部分的工作。出于安全原因，建议将Conductor服务放置在隔离的主机上，因为这是唯一需要访问数据平面和IPMI控制平面的服务。可以有多个Conductor服务实例来支持各种类型的驱动程序，也可以管理故障转移。Conductor服务的实例应该位于不同的节点上。每个Conductor本身可以运行多个驱动器来操作异构硬件。如下图所示。该API公开了支持的驱动程序的列表以及为其服务的指挥主机的名称。

了解裸机部署

启动实例请求进来时会发生什么？下图说明了配置裸机实例过程中涉及的步骤。在部署过程之前必须满足这些条件：

在裸机服务节点上配置从属软件包，其中的Ironic的Conductor正在运行，如tftp-server，ipmi，syslinux等，用于裸机配置。
Nova必须配置为使用裸机服务端点，并且应将在Nova计算节点上为计算驱动程序配置使用Ironic驱动程序。
为可用的硬件创建flavor，Nova必须知道从哪个flavor启动。
要在Glance中提供的可用镜像。下面列出的是成功部署裸机所需的一些镜像类型：
- bm-deploy-kernel
- bm-deploy-ramdisk
- user-image
- user-image-vmlinuz
- user-image-initrd
要通过Ironic RESTful API服务注册的硬件。

LXC介绍

Sat, 11 Nov 2017 08:56:06 +0800

什么是LXC？

LXC是Linux内核中拥有容器功能的用户空间接口。通过强大的API和简单的工具，它可以让Linux用户轻松创建并管理系统或应用程序容器。

特征

当前的LXC使用以下的内核特性来封装进程

Kernel namespaces (ipc, uts, mount, pid, network and user)
Apparmor and SELinux profiles
Seccomp policies
Chroots (using pivot_root)
Kernel capabilities
CGroups (control groups)

LXC容器通常被认为是chroot和一个完整的虚拟机。 LXC的目标是尽可能创造一个环境到一个标准的Linux安装，但不需要单独的内核。

组件

LXC目前由几个单独的组件组成：

liblxc库
API的几种语言绑定
- python3 (in-tree, long term support in 1.0.x and 2.0.x)
- lua (in tree, long term support in 1.0.x and 2.0.x)
- Go
- ruby
- python2
- Haskell
一套控制容器的标准工具
分发容器模板

LXC简介

Sun, 05 Nov 2017 08:56:09 +0800

LXC

LXC是著名的经过严格测试的底层Linux容器运行库。从2008年开始发展，现已在世界各地的关键生产环境中得到证明。其中一些核心贡献者是帮助在Linux内核中实现各种知名集装箱功能的人员。

系统容器

LXC的主要重点是系统容器。也就是说，提供尽可能接近VM但没有运行单独内核并模拟所有硬件的开销的容器。这是通过内核安全功能（如命名空间，强制访问控制和控制组合）实现的。

非特权容器

非特权容器是没有任何权限运行的容器。这需要对内核中运行容器的用户名空间的支持。用户命名空间合并到主线内核之后，LXC是第一个支持非特权容器的运行库。实质上，用户名空间隔离给定的UID和GID集合。这通过在主机上的一系列UID和GID之间建立到容器中UID和GID的不同（非特权）范围之间的映射来实现。内核将以这样一种方式转换此映射，即在容器内部，所有UID和GID按照您期望的从主机显示，而在主机上，这些UID和GID实际上是无特权的。例如，在容器内作为UID和GID 0运行的进程可能在主机上显示为UID和GID 100000。可以从相应的用户命名空间手册页中收集实现和工作细节。由于非特权容器是一种安全增强功能，因此它们自然会受到内核强制执行的一些限制。为了提供一个功能齐全的非特权容器LXC与3个setuid代码交互：

lxc-user-nic（setuid帮助器创建一个veth对，并在主机上桥接它）
newuidmap（从shawdow库中，设置一个uid映射）
newgidmap（从shawdow库中，设置一个gid映射）

一切都是以您自己的用户身份运行，也可以作为用户拥有的uid运行。一般来说，LXC的目标是利用内核中可用的每个安全功能。这意味着LXC的配置管理将使经验丰富的用户根据自己的需要对LXC进行复杂的调整。有关LXC安全性的更详细的介绍可以在以下链接中找到：

https://linuxcontainers.org/lxc/security/

移除特权

LXC在没有正确的配置这些工具的情况下是可以运行的。只不过你这种容器的用途通常是非常有限的。这里突出两个最常见的问题：

网络：没有依赖一个setuid帮助器为非特权用户设置适当的网络设备（参见LXC的lxc-user-nic二进制文件），唯一的选择是与主机共享网络命名空间。虽然原则上应该是安全的，但共享主机的网络命名空间仍然是减少隔离的一个步骤，并增加攻击向量。此外，当主机和容器共享相同的网络命名空间时，内核将拒绝任何sysfs挂接。这通常意味着容器内的init二进制文件将无法正确启动。
用户命名空间：如上所述，用户名空间是一个很大的安全性增强。但是，不依赖特权帮助者，主机上无权限的用户只能将自己的UID映射到容器中。然而，标准的POSIX系统需要65536个UID和GID来保证完整的功能。

配置

LXC通过一些简单的关键字配置，例如：

lxc.rootfs.path
lxc.mount.entry

LXC通过使用单点命名空间配置关键字。这意味着复杂的配置关键字（如lxc.net.0）会展示各种子项，例如lxc.net.0.type，lxc.net.0.link，lxc.net.0.ipv6.address等一些更精细的配置。 LXC被用作LXD的默认运行库，LXD是容器管理程序，它暴露出设计良好且稳定的REST-api。

内核需求

LXC在2.6.32以上的任何内核上运行。所有它需要的是一个功能C编译器。 LXC适用于提供必要内核功能的所有架构。这包括（但不限于）：

i686
x86_64
ppc,ppc64,ppc64le
s390x
armvl7,arm64

LXC至少还支持以下C标准库：

glibc
musl
bionic(Android’s libc)

向后兼容

LXC一直专注于强大的向后兼容性。事实上，API从1.0.0版起没有被破坏。主LXC目前处于版本2。

SDN发展必然

Sun, 22 Oct 2017 08:54:08 +0800

现在很多人认为云可能是虚拟化的终极。但是，ICT（Information Communications Technology，信息通信技术）当然还有许多要素才开始感受到虚拟化的影响，更不用说实际上被虚拟化了。网络是突出的例子。现在的首选术语是“软件定义网络”或SDN而不是V首字母缩略词，尤其是因为虚拟网络和VPN仍将存在于新的软件定义的世界，这肯定是正确的跨越所有ICT。当光纤到桌面/家庭是可行，4G速度将很快在千兆位时，为什么我们需要虚拟化网络？开放网络基金会（ONF）刚刚两年多，已经成为了像ICT这样独立基础的领先机构，直白的说，今天的“传统网络架构不能满足企业、运营商和终端用户的需求”。即使硬件工程不断发展和进步，可是标准和协议的不足限制我们充分利用基础架构的能力。视频、图像、移动数据以及即将到来的“物联网”当然也还包括大数据的数据量可能会让因特网无法承受，这也就使得虚拟化网络变得更加重要了。基因组学、天文学、天体物理学、气象学和许多其他科学领域可以注重网络与数据量而不用管传统的分层交换架构。

传输和控制层面

SDN的概念很简单：如果数据或业务承载层和控制层被去耦合，则以前的静态网络可以变得智能、响应、可编程和集中控制。所有这些都可以根据逻辑规则自动响应流量模式、流量类型或紧急情况。网络设备，特别是交换机和路由器，通常涉及一些来自多个制造商不同的内置的智能，通常是专有的内部代码。现在，网络工程师几乎都在抱怨虚拟机只需要点几下，几分钟就能让它运行起来，但是网络设备却要花费数十天的时间来正确配置和测试与网络的接口。 OpenFlow是ONF为SDN设置的主协议集，采用了斯坦福大学和伯克利分校开发的标准，几年前由谷歌和后来的Facebook接受。如今已经广泛采用，如果您今天订购网络交换机或路由器，交付的产品几乎肯定会具有OpenFlow兼容性内置或将提供升级。另一方面，谨慎的网络设备制造商可能没有勉强地采用SDN，因为这威胁到了其Ethernet/IP的环境。但是，他们确实认识到SDN的必然性，因为它将为从WAN到数据中心到运营商的所有功能带来明确的下一代功能。这并不是我们这些用户和单个消费者能决定的，都是市场的驱动。

架构依赖

曾在IBM，HP和Nortel专注网络技术的专家，现任ONF执行董事Dan Pitt 说：“我们依赖于同样的网络架构，已经超过45年，其中有些仍然显示出原始Arpanet的特征。最初，互联网的目标是生存性，所有的数据都必须存在于每一个节点上，但也意味着只有这么多的数据可以存在于每一个设备上。SDN原则上满足了现在和将来的需求，这是ICT工程文化的一个全面变化，也是民主化的一个可喜的选择，使得网络本身具有可编程性和适应性。” 来自ICT部门的受访者Pitt认为，SDN将需要两三年或更多的时间，成为所有网络和软硬件运行和管理的缺省设置。“今天的例子比Google更加明显和开放，SDN已经成为了规范，并展示了应对网络上各种需求的优势。” 他提到了SDN一个大的应用场景。加州大学从教职工到学生再到安全和维护人员超过12万用户，这其中95%的人携带着自己的设备，他们高度分散。它拥有从电子邮件和文本到全动态高清视频和大数据处理几乎所有已知的数据流量和容量。这意味着它甚至比全球大多数企业面临更多的ICT复杂性和网络性能问题。Pitt说，SDN是管理所有这一切并且在整个校园提供高服务质量和满意度水平的最成功的工具。

复杂易错

如今的网络管理起来复杂、耗时、易错而且还成本巨大。Dan Pitt 解释说,完全灵活和动态网络管理控制的简单的用户界面可以是我们的一个终极愿景。“它们将是基础设施的象征，但不需要特殊技能，我们可以预见用简单语言编写的策略和业务规则，甚至可以使用符号和图形独立的语言来控制网络中没有按照已有策略自动化的所有元素。” 思科在网络的任何发展中都很重要，作为技术领导者，同时也可能是安装系统数量最多的供应商，尤其是硬件。从概念上讲，它必然算是参与SDN运动的ONF的一个成员。思科开放网络环境被描述为一种“网络编程策略”，并在协议和行业标准中提供选择。这对于ONF来讲可能不是一个福音，但重要的一点是，在这个早期的采用阶段，行业领先的网络系统供应商是广泛共识的一部分。思科英国和爱尔兰首席技术官Ian Foddering 说：“一年多以来，我们一直在跟客户谈论SDN。目前，我们看到ONF模式可能是控制层和数据层的经典且简单的分离，但我们相信，在真实的市场世界中，混合SDN解决方案是多数组织最适合和实际使用的方法。他们希望利用他们已经拥有的东西，但要有新的集中控制。”他坚持认为，思科致力于开放标准，并提到上个月刚刚成立的OpenDaylight联盟。该联盟处于Linux基金会之下，其中包括ONF的大部分成员，Citrix，IBM，HP，Juniper Networks，VMware 等也随着Cisco一起加入。尽管该联盟似乎将使用openFlow，但ONF本身并不是该联盟的一部分。

发展

Foddering谈到，现实点讲，在SDN在市场上想要达到任何规模至少需要3年的时间。他相信，数据中心和云服务提供商以及一些大型全球企业将引领这一方向。“SDN将协助创建大规模可扩展的数据中心和更高水平的自动化，同时具有经济和效率方面的优势。我们最近在爱尔兰和英国进行的一项调查表明，人们对于SDN所提供的服务的了解已经到达了一种几乎让人吃惊的程度。人们知道它是什么，它将走向何处以及潜在的好处。我们都在探索如何走向SDN。” 他说，简单的使用和管理是关键，网络复杂性完全隐藏在后端。“在某些方面，SDN应该真正被称为‘用户定义的网络’，这将为网络管理带来更多的敏捷性和响应性，我们也将它视为将网络智能暴露给应用程序，再次增加了协调和自动化。更深入的网络智能被引入一类新的分析应用程序，可以促进更复杂的网络策略并支持驱动网络的业务逻辑，”Foddering说。“这最终使得网络更有价值，并且可以支持更多的创新和创收服务。”

过去的困境

VMware的首席技术专家Joe Baguley认为：“网络在过去一直停滞不前，我们在服务器虚拟化和云计算方面取得了长足的进步，今天为新的虚拟机或应用程序的配置网络和安全性仍然是涉及人，键盘和CLI的大量的手动工作。“与ICT中的其他形式的虚拟化一样，自动化的关键是将软件从硬件中抽象出来。软件定义的数据中心的愿景是下一代ICT的核心，在这一阶段，网络是阻碍我们基础设施中几乎所有其他方面发展的障碍。 “ICT发展的总体趋势是明确的，”Baguley说。“我们正在转向一种逻辑可行且最终灵活的软件定义和控制的环境，当然了其本质还是在硬件上运行。管理一个组织中的数千台服务器必须成为编程式，并转向策略驱动的自动化，使其无论是在规模上，还是在应对不断变化的流量需求方面实现高效性和灵活性。” 他补充说，所有这些都将推进内部计算与私有云和公共云之间的关系。随着时间的推移，组织将更加清晰地建立起核心，而不是数据、应用程序和其他所有东西。SDN以及所有其他形式的虚拟化，都将能够根据组织的策略和当前的需求，实现工作负载的自由而无缝移动。“非常严格的sla和安全肯定会适用，”Baguley说，“事实上，在一个虚拟的和软件定义的ICT世界中，一些服务提供商无疑会开始根据他们的物理资产来区分他们自己。关键是，我们对公共云进行全面分析，以根据用户的策略和业务规则来处理所有工作负载。”

炒作之后

“我们在最近几十年里清楚地看到，ICT实际上从未成熟，当然也从未停止，”Citrix的云平台组总监Damian Saunders说。 “我们可以回顾一下那些在他们的时代引起了大量炒作的新技术，并清楚地看到那些成功的技术都是建立在良好的科学基础上的。虚拟化当然是一个很好的例子，从它所运行的硬件中抽象出软件和控制。现在，作为一个行业，我们已经把这个概念带到了网络上，并且已经得到了很多相关的专业知识和技术。” Saunders是另一个相信“user defined networking” 的人，在很多方面都是一个更有意义的术语，因为SDN提供的不仅仅是虚拟化，从现在起它将把策略驱动的灵活性带到我们管理企业计算的方式中。例如，它将使更灵活的软件许可条款，并将整个基础设施变成一个可编程的平台，供用户和信息使用。我们需要为数据中心设计更多的复杂性，以及在下一代ICT中为用户呈现简单性的智能。”

弹性能力

新时代下，弹性是一个关键的概念。Saunders说，“传统上，我们必须提前对硬件能力进行预测和计划，通常是为资产的可能生命周期做准备。当然，资源是可以增加的，但总的来说，我们总是在购买更多，而我们实际上知道我们不太可能使用这么多。“爆裂”是一个几乎不可能的概念。那是旧模式。现在，我们根据需求提供资源，如有必要就将其收回，并遵循业务和使用的正常的衰落和流动——更不用提收入了。服务条款和软件许可也可以遵循用户定义的需求和更好的条款。这都是真正的变革。” 惠普仍然是世界上最大的多产品、多服务ICT巨头之一，也同时参与了ONF和Open Daylight联盟。Bruno Hareng是惠普分管SDN的首席技术经理，他解释说，SDN是一种不可避免的回应，因为各种各样的网络都面临着各种各样的挑战，比如大数据和移动消费者和商业设备的指数需求。“传统网络面临着应用程序范围，流量类型和数据量的问题，” 他说，“我们需要将服务器，存储和网络集成到一个通用的平台中，集中智能地控制，以识别和满足所有不同和不断变化的应用程序和工作负载的需求，刚性架构不能这样做。”

多种实现

Hareng承认，在市场上有许多不同的方法，但他说，惠普正在采用OpenFlow的定义和逻辑，在网络架构中对控制和数据层进行耦合。“这是相当通用的，允许跨ICT和电信的互操作性。在组织内部，可以采用其他方法来实现相同的SDN特性，并在基础设施中得到结果，尤其是应用程序感知和用户定义的灵活性。就像其他许多ICT一样，现实生活很可能会产生混合或融合的解决方案，我们当然还需要管理现有的网络设备。” Hareng指出了通用通信迅速成长为协作的关键元素，并在网络语音和视频造成实时需求的例子。“即使普通用户现在也能理解管理网络流量的困难，以确保通用通信的优先级和QoS。”但他们也很欣赏这种价值。SDN为应用程序提供了相同的功能，使网络能够动态地响应每个应用程序的需求。例如，已经证明了SDN已经极大地改善了Hadoop的性能。”

家庭领域

在这里，爱尔兰的网络专家Data Edge首席技术官Paul Phelan表示,现在全球拥有基础架构和带宽，也就拥有真正利用SDN的潜力。“我们不得不花费几代技术学习我们的方式，但SDN使现在成为一个网络拥有大脑的时代。传统上，离散组件的智能有限，这样做：配置一个大路由器确实仍然是ICT中最危险的工作之一，错误和错误配置有巨大的可能性，一位数字的输入错误可能会导致整个网络丢失。” 相当正确的是，在Phelan的意见中，应用程序正在跨越ICT占据首席地位，这是一个自然而然的演进。“从某种意义上说，我们可以问为什么现在还没有发生这样的事情，但实际上近年来，已经有了一种ICT的达尔文进化，我们已经开发出了强大和成熟的技术，由于一些专有的因素输家已经走了。最近，虚拟化和相关技术已经足够强大，足以应对网络的复杂性，尤其是控制层。” 即使SDN技术尚未成为市场的主流，SDN技术已经到位并进行了良好的测试。 “自从2010年以来，Google一直在SDN上运行，OpenFlow的标准和性能和设备测试也是我们所参与的一个领域 - SDN然后提供几乎无限的灵活性和可扩展性，突发和激增？看到服务提供商和运营商按需提供带宽，竞争将同事推动软件控制能够提供性能和经济性。”

Ubuntu安装 Docker 社区版

Sun, 22 Oct 2017 08:54:08 +0800

准备

系统要求

要安装Docker CE，我们需要这些64位版本的Ubuntu：

Artful 17.10 (Docker CE 17.11 Edge and higher only)
Zesty 17.04
Xenial 16.04 (LTS)
Trusty 14.04 (LTS)

在Ubuntu x86_64、armhf、s390x（IBM Z）和ppc64le（IBM Power）架构上支持Docker CE。

ppc64le和s390x限制：IBM Z和Power体系结构的软件包仅在Ubuntu Xenial及更高版本上可用。

卸载旧版本

老版本的Docker被称为docker或者docker-engine。如果安装了这些，请将其卸载：

sudo apt-get remove docker docker-engine docker.io

如果apt-get报告没有安装这些软件包，则可以直接跳过这一步。

/var/lib/docker/的内容（包括映像，容器，卷和网络）将被保留。 Docker CE包现在称为docker-ce。

安装Docker CE

您可以根据您的需要以不同的方式安装Docker CE：

大多数用户设置Docker的存储库并从中进行安装，以方便安装和升级任务。这是推荐的方法。
有些用户下载deb软件包手动安装，并完全手动管理升级。这很适合在诸如没有互联网访问的封闭系统上安装Docker。
在测试和开发环境中，有些用户选择使用自动便捷脚本来安装Docker。

使用软件仓库安装

首次在新的主机上安装Docker CE之前，需要设置Docker软件仓库。之后，您可以从该库安装和更新Docker。

设置软件仓库

更新apt包索引：
```
sudo apt-get update
```

安装软件包以允许apt通过HTTPS使用存储库：

sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
software-properties-common

添加Docker的官方GPG密钥：
```
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
```
通过查看指纹的最后8个字符，确认您现在已经拥有指纹9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88的密钥。
```
sudo apt-key fingerprint 0EBFCD88
```
pub 4096R/0EBFCD88 2017-02-22
Key fingerprint = 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
uid Docker Release (CE deb) docker@docker.com
sub 4096R/F273FCD8 2017-02-22
使用以下命令来设置stable存储库。即使您想从edge或test存储库安装构建，也总是需要stable存储库。要添加edge或test存储库，请在下面的命令中在单词stable之后添加edge或test（或两者）。

注意：下面的lsb_release -cs子命令返回你的Ubuntu发行版的名字，比如xenial。有时候，在像Linux Mint这样的发行版中，您可能必须将$(lsb_release -cs)更改为您的父级Ubuntu发行版。例如，如果您使用Linux Mint Rafaela，则可以使用trusty。
- Duplicate Widget
- Remove Widget
x86_64 / amd64

armhf

IBM Power (ppc64le)

IBM Z (s390x)

x86_64 / amd64
```
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
armhf
```
sudo add-apt-repository \
"deb [arch=armhf] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
IBM Power (ppc64le)
```
sudo add-apt-repository \
"deb [arch=ppc64le] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
IBM Z (s390x)
```
sudo add-apt-repository \
"deb [arch=s390x] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```

SDN的定义

Sat, 21 Oct 2017 09:54:08 +0800

SDN（Software-Defined Networking，软件定义网络）的定义

什么是SDN？

转发层与网络控制层的物理分离以及控制多设备的控制层

软件定义网络（SDN）是一种新兴的体系结构，具有动态，可管理性，成本效益和适应性，使其成为当今应用的高带宽，动态性能的理想选择。该架构解耦了网络控制和转发功能，使网络控制成为可直接编程的，底层基础设施将被抽象出来，用于应用和网络服务。OpenFlow®协议是构建SDN解决方案的基础元素。 SDN架构是：

可直接编程：网络控制是直接可编程的，因为它与转发功能分离开来。
敏捷：来自转发的抽象控制使管理员可以动态调整网络流量，以满足不断变化的需求。
集中管理：网络智能（在逻辑上）集中在基于软件的SDN控制器中，其维护网络的全局视图，其将应用和策略引擎看作是单个逻辑交换机。
编程配置：SDN使网络管理员通过动态，自动化的SDN程序非常快速地配置，管理，保护和优化网络资源，他们可以自己编写，因为程序不依赖于专有软件。
开放标准和厂商中立：通过开放标准实现，SDN简化了网络设计和操作，因为SDN控制器提供了指令，而不是多个供应商特定的设备和协议。 ![image](https://images.weserv.nl/?url=https://www.opennetworking.org/images/stories/sdn-resources/meet-sdn/sdn-3layers.gif

计算趋势正在推动网络变革

SDN解决了传统网络的静态架构不适合当今数据中心、校园和运营商环境的动态计算和存储需求的事实。推动新网络范式需求的关键计算趋势包括：

改变传输模式：通过公共和私有云通常访问地理分布式数据库和服务器的应用程序需要极其灵活的流量管理和按需访问带宽。
“消费化信息技术”：BYOD（Bring Your Own Device，携带您自己的设备）趋势需要既灵活又安全的网络。 - 云服务的兴起：用户期望按需访问应用程序，基础架构和其他IT资源。
大数据意味着更大带宽：处理今天的大型数据集需要大量的并行处理，这将加剧对额外容量和任何到任何连接的不断需求。为了满足不断变化的计算趋势所带来的网络需求，网络设计师发现自己受到当前网络的限制：
过于复杂：添加或移动设备和实施全网络策略是复杂，耗时的，主要是手动尝试风险的服务中断，阻止网络更改。
无法缩放：链接超额订购对提供可扩展性的历史悠久的方法对于虚拟化网络中的动态流量模式是无效的，这是在整个计算池中具有大规模并行处理算法和相关数据集的服务提供商网络中更为显着的问题。
厂商依赖：冗长的供应商设备产品周期和缺乏标准的开放接口限制了网络运营商将网络定制到各自环境的能力。

SDN架构组件

Sat, 21 Oct 2017 08:54:08 +0800

架构组件

以下定义并解释了各架构组件：

SDN应用程序

SDN应用程序是通过北向接口（NBI）显式，直接和编程地将其网络要求和所需网络行为传达给SDN控制器。此外，他们可能会为了内部决策而消耗网络的抽象视图。SDN应用程序由一个_SDN应用程序逻辑_和一个或多个_NBI驱动程序_组成。SDN应用程序本身可能会暴露另一层抽象网络控制，从而通过各自的_NBI代理_提供一个或多个更高级别的NBI。

SDN控制器

SDN控制器是一个逻辑上集中的实体，负责将SDN应用程序的要求转换为SDN数据路径，以及向SDN应用提供网络的抽象视图（可能包括统计信息和事件）。SDN控制器由一个或多个_NBI代理_，_SDN控制逻辑_和控制层到数据层接口（CDPI）驱动器组成。作为逻辑集中式实体的定义既不规定也不排除实施细节，例如多个控制器的联合，控制器的分层连接，控制器之间的通信接口，以及虚拟化或网络资源的切片。

SDN数据路径

SDN数据路径是一种逻辑网络设备，可以对其广告转发和数据处理功能进行可见性和无争议的控制。逻辑表示可以包括物理底物资源的全部或子集。SDN数据路径包括_CDPI代理_和一组一个或多个流量转发引擎和零个或多个流量处理功能。这些引擎和功能可能包括数据通路的外部接口或内部流量处理或终止功能之间的简单转发。一个或多个SDN数据路径可以包含在单个（物理）网络元件中——作为单元管理的通信资源的集成物理组合。SDN数据路径也可以跨多个物理网元进行定义。这种逻辑定义既不规定也不排除实现细节，例如物理映射的逻辑映射，共享物理资源的管理，SDN数据通路的虚拟化或分片，与非SDN网络的互操作性，以及数据处理功能，可以包括OSI 4-7层功能。

控制层到数据层接口

SDN CDPI是在SDN控制器和SDN数据路径之间定义的接口，其至少提供： 1. 对所有转发操作的编程控制， 2. 能力广告， 3. 统计报告， 4. 事件通知。 SDN的一个价值在于期望CDPI以开放，供应商中立和可互操作的方式实施。

SDN北向接口

SDN NBI是SDN应用程序和SDN控制器之间的接口，通常提供抽象网络视图，并能够直接表达网络行为和要求。这可能发生在任何抽象级别（纬度）和不同功能集（经度）之间。SDN的一个价值在于期望这些接口以开放，供应商中立和可互操作的方式实现。

OpenFlow简介

Wed, 11 Oct 2017 08:54:08 +0800

OpenFlow

来源于维基百科——自由百科全书 OpenFlow 是一种通信协议，可以通过网络访问网络交换机或路由器的转发平面。

描述

OpenFlow允许网络控制器确定网络交换机网络的路径。控制器与交换机不同。控制与转发的分离允许使用可行的比访问控制列表（ACL）和路由协议更复杂的流量管理。此外，OpenFlow允许使用单一的开放协议远程管理来自不同供应商的交换机（通常每个都有自己的专有接口和脚本语言）。协议的发明人认为OpenFlow是软件定义网络（SDN）的推动者。 OpenFlow允许通过添加，修改和删除数据包匹配规则和操作来远程管理第3层交换机的数据包转发表。这样，路由决策可以由控制器定期或临时进行，并转换成具有可配置寿命的规则和动作，然后将其部署到交换机的流表中，以匹配的速度将匹配的分组实际转发到交换机这些规则的持续时间。由交换机无法匹配的数据包可以转发给控制器。然后，控制器可以决定修改一个或多个交换机上的现有流表规则，或者部署新的规则，以防止交换机与控制器之间的流量结构性流动。它甚至可以决定转发流量本身，只要它告诉交换机转发整个数据包，而不是只是他们的header。 OpenFlow协议分层在传输控制协议（TCP）之上，并规定了传输层安全性（TLS）的使用。控制器应该在TCP端口6653上侦听想要建立连接的交换机。早期版本的OpenFlow协议非官方使用端口6633.

历史

开放网络基金会（ONF）是一个致力于促进和采用软件定义网络（SDN）的用户主导的组织， ONF将OpenFlow定义为在SDN架构的控制层和转发层之间定义的第一个标准通信接口。 OpenFlow允许直接访问和操纵诸如交换机和路由器的网络设备的转发平面，包括物理设备和虚拟设备（基于虚拟机管理程序）。没有一个开放接口的转发平台，导致了如今的网络设备的现状，如单一，封闭和专用。需要像OpenFlow这样的协议，将网络控制从专有网络交换机转移到开源和本地管理的控制软件。许多网络交换机和路由器供应商已经宣布意图支持或正在运送支持OpenFlow的交换机，包括阿尔卡特朗讯, 大交换机网络，博科通信， Radisys， Arista Networks， Pica8，NoviFlow，华为，思科，戴尔EMC，Extreme Networks， IBM，瞻博网络， Digisol， Larch Networks，Hewlett-Packard， NEC和MikroTik。一些网络控制平面实现使用协议来管理网络转发元素。OpenFlow主要用于安全通道上的交换机和控制器之间。有关OpenFlow相关产品的相当全面的列表可以在ONF网站和SDNCentral网站上找到。