UPX 是一个可执行文件压缩工具不同于其他的压缩软件，它：
- 只压缩可执行文件
- 压缩后的可执行文件依然是可以直接执行的文件，功能和没压缩的一样
- 不需要额外的解压缩工具，因为压缩可执行文件相当于给可执行文件套了个壳儿，解压缩的功能已经在压缩后的文件里面了
用途：
- 给病毒文件加壳
- 压缩二进制文件，方便下载
- 压缩docker镜像中的可执行文件，提高镜像分发效率
阿里云SLB之内网调用问题
阿里云内网SLB使用：
ECS（A） —–> SLB(TCP) —–> ECS(B)
我们来看看数据包路径：
ECS（A）【 IP(A) –> IP(SLB) 】 ======> SLB (目的地址转换，源地址不转换） ========> ECS（B）【 IP(A) —-> IP(B) 】
那么， ECS（B）该如何回包呢？
因为ECS（B）认为数据包是从ECS（A）过来的，自然回包给ECS（A），而事实上ECS（B）是可以直接访问到ECS（A）的，于是乎，不经过SLB就直接回包了； 那么，数据包到了ECS（A）能被认可吗？
当然不会，因为ECS（A）只知道给SLB发送过请求，不知道给ECS（B）发送过请求。
所以， 对于这种情况，SLB的TCP模式是行不通的。同理，UDP模式也是不行的。
只要回包离开了ECS(B)，就会被SLB看到，就会被地址转换后在发送给ECS(A)， 所以，这种场景是没问题的。
下面场景是有问题的：(如果SLB后面有多台机器，SLB就可以把来自A的请求转发到非A的机器上，自然也就没问题了)
ECS（A） —–> SLB(TCP) —–> ECS(A)
问题：
对于第一种场景，如果ECS（A）和ECS（B）不在同一个网段（似乎不行）也就算了，当ECS（A）通过SLB（tcp）访问ECS（B）时，会不会影响到ECS（B）上记录的ECS（A）的mac地址？
实际情况却是：
node-1(172.16.31.99) 和 node-2（172.16.31.100）以及gateway的mac地址都是一样的； 如此看来，阿里的网络设备甚至操作系统都是定制的了？
bash 之变量声明周期
有些时候，我们通过如下方式执行命令：
|
1 |
var=1 cmd.sh |
这样，cmd.sh 中就能看到变量var ； 但是千万别写成：
|
1 |
var=1 cmd.sh $var |
这里的 $var 绝对不是1； 因为$var 是在var=1被解释之前解释的
如下：
如何从容器内部获取容器ID
办法1：
|
1 |
cat /proc/self/mountinfo |
或
|
1 |
cat /proc/self/mounts |
或
|
1 |
cat /proc/self/cgroup |
谁在占用带宽（h3c路由器）
通过路由器的 ip flow-ordering （IP 流量排名）来监视：
在接口上添加：
ip flow-ordering internal 或
ip flow-ordering external
再设置统计周期：
ip flow-ordering stat-interval 10 #10s
通过 display ip flow-ordering statistic external 或
display ip flow-ordering statistic internal 来查看
如：
参考：
docker 之 容器隔离
情景： 拿容器当虚拟机用，容器有内存也有swap
问题：
有些程序（Java）只用内存，swap闲着也不用，当内存用完时，由于有大量空闲的swap，所以不会oom，但是进程申请内存被阻塞，该进程的cmdline读取不了，就影响宿主机ps，top
如何删除docker镜像中已配置的volume
场景： 有个同学不知道因为啥，将容器内部的 /sys/fs/cgroup 挂载到了外面的某个目录； 但是这个目录是很有用的，不想随便被挂载，如何从image中去掉呢？
docker没有给出一个方便的方法， https://github.com/gdraheim/docker-copyedit 给了一个办法，原理如下：
每个image都是有一个manifest.json 文件的，相关配置信息都在这里了，但是你看不到image文件，更无从去谈修改manifest.json 文件了，所以：
- 先通过docker save 命令将image导出成tar文件：
1docker save docker-registry.i.bbtfax.com/bee_centos7 -o /data1/centos7.tar - 在用tar命令解压文件
1tar xf /data1/centos7.tar -C /data1/centos7/ - 在解压后的文件中找到manifest.json 文件，这个文件可能不是你最终要修改的，里面的Config标识了配置文件的位置，应该就是该文件旁边的一个json文件
- 修改配置文件
- 重新打包image
1cd/data1/centos7/ ; tar cf ../centos7.modify.tar . - 导入image
123# docker load -i centos7.modify.tarThe image phpor.net/bee_centos7:latest already exists, renaming the old one with ID sha256:b14fe97b3bc959677c252e74e0ae318fa26028ac78d236a0973c3e235bf7a68b to empty stringLoaded image: phpor.net/bee_centos7:latest
我这里因为已经存在了同名的image，所以，旧的image的名字就被抢走了，但是ID没有变，新导入的image有自己新的ID
linux命令 之 pgrep
每次查找关心的进程都去ps 再 grep显得好麻烦，而且这是一个非常常用的操作，所以，熟练使用pgrep将有效提高工作效率。
如果不看文档直接去pgrep 你关心的东西，可能得不到想要的效果，因为你关心的是进程的参数，而不是进程名，而且只输出pid，似乎也用处不大，所以，你可能非常关心两个选项：
-f: 模拟情况下，只匹配进程名(/proc/$pid/comm)，使用-f选项可以匹配整个命令行(/proc/$pid/cmdline)；
-a: 默认只输出pid， 使用-a选项可以输出pid 和整个命令行
所以，pgrep的正确姿势为：
|
1 |
pgrep -af $pattern |
高级用法：
当我们想在 a.sh 中判断a.sh脚本是否已经在执行时，我们可以通过 -o 选项来实现：
|
1 |
pgrep -of a.sh |
如果得到的pid就是自己，则说明没有已经在运行的a.sh；
按照ppid来查找：
|
1 |
pgrep -P $pid |
Docker 不能访问外网的问题
往常，我使用docker的network=none ，然后使用pipework给容器添加一个外部可访问的IP，然后，容器就能访问外网了；
后来，我在openstack上创建的centos7虚拟机上安装docker，同样的方式启动的容器却无法访问外网，首先，centos7虚拟机的网卡去掉任何安全组，并设置为非管理状态； 检查centos7的ip_forward 是打开的，最终，发现差别就在于，原来的iptables规则中 FORWARD 的策略是ACCEPT ，而现在是FORWARD 策略是 DROP的；
问题： iptables的 FORWARD 的DROP策略是在哪个环节设置的呢？
参考docker 源码发现如下逻辑：
基本逻辑为：
如果本来是开启着ip转发的，就不会去设置iptables 的forward链的默认策略了；
如果本来没有开启ip转发的，就会去设置iptables 的forward链的默认策略。
显然，曾经的机器在docker启动前就已经设置了ip转发了， 而后来的机器在docker启动前还设置ip转发，虽然最终是都设置了IP转发，但是结果却不同；如果直接让docker来管理容器的网络，则docker会按照要求自动添加forward规则，然而，现在我们用的是pipework，就需要自己添加forward规则了，势必会麻烦一些；流氓一些的做法就是直接修改FORWORD 的默认策略。
bash 之变量与函数
bash中有个export，可以导出变量给子进程使用； 但是函数没法导出给子进程使用，如下：
