:::warning{title="注意"}
注意：docker commit 命令除了学习之外，还有一些特殊的应用场合，比如被入侵后保存现场等。

但是，不要使用docker commit定制镜像，定制镜像应该使用Dockerfile来完成
:::




现在我们定制一个web服务器的例子，来说明镜像是如何构建的：
```
$ docker run --name webserver -d -p 80:80 nginx
```
如果是在本机运行的docker，那么可以直接访问：http://localhost

![image.png](/static/img/1fdf2c852ec4f12df9ea20f0e010d272.image.png)

现在，假设非常不喜欢这个页面，我们希望改成欢迎docker的文字，可以使用docker exec命令进入容器，修改其内容：
```
$ docker exec -it webserver bash
root@3729b97e8226:/# echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
root@3729b97e8226:/# exit
exit
```
通过docker diff 命令看到具体的改动：
```
 docker diff webserver
C /root
A /root/.bash_history
C /run
C /usr
C /usr/share
C /usr/share/nginx
C /usr/share/nginx/html
C /usr/share/nginx/html/index.html
C /var
C /var/cache
C /var/cache/nginx
A /var/cache/nginx/client_temp
A /var/cache/nginx/fastcgi_temp
A /var/cache/nginx/proxy_temp
A /var/cache/nginx/scgi_temp
A /var/cache/nginx/uwsgi_temp
```

现在我们定制好了变化，我们希望能将其保存下来形成镜像

docker commit：可以将容器的存储层保存下来称为镜像。换句话说，就是在原有镜像的基础上，再叠加上容器的存储层，并构成新的镜像。

以后我们运行这个镜像的时候，就会拥有容器最后的文件变化

语法：
```
docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]
```
例如：
```
$ docker commit \
    --author "Tao Wang <twang2218@gmail.com>" \
    --message "修改了默认网页" \
    webserver \
    nginx:v2
sha256:07e33465974800ce65751acc279adc6ed2dc5ed4e0838f8b86f0c87aa1795214
```
* --author 是指定修改的作者
* --message 是记录本次修改的内容

docker images 查看新定制的镜像

---
我们还可以用docker history 具体查看镜像内的历史记录，如果比较nginx:latest的历史记录，我们会发现新增了我们刚刚提交的这一层
```
$ docker history nginx:v2
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
07e334659748        54 seconds ago      nginx -g daemon off;                            95 B                修改了默认网页
e43d811ce2f4        4 weeks ago         /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon    0 B
<missing>           4 weeks ago         /bin/sh -c #(nop)  EXPOSE 443/tcp 80/tcp        0 B
<missing>           4 weeks ago         /bin/sh -c ln -sf /dev/stdout /var/log/nginx/   22 B
<missing>           4 weeks ago         /bin/sh -c apt-key adv --keyserver hkp://pgp.   58.46 MB
<missing>           4 weeks ago         /bin/sh -c #(nop)  ENV NGINX_VERSION=1.11.5-1   0 B
<missing>           4 weeks ago         /bin/sh -c #(nop)  MAINTAINER NGINX Docker Ma   0 B
<missing>           4 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0 B
<missing>           4 weeks ago         /bin/sh -c #(nop) ADD file:23aa4f893e3288698c   123 MB
```

运行
```
docker run --name web2 -d -p 81:80 nginx:v2
```

## 慎用dockercommit
使用 docker commit 命令虽然可以比较直观的帮助理解镜像分层存储的概念，但是实际环境中并不会这样使用。

首先，如果仔细观察之前的 docker diff webserver 的结果，你会发现除了真正想要修改的 /usr/share/nginx/html/index.html 文件外，由于命令的执行，还有很多文件被改动或添加了。这还仅仅是最简单的操作，如果是安装软件包、编译构建，那会有大量的无关内容被添加进来，将会导致镜像极为臃肿。

此外，使用 docker commit 意味着所有对镜像的操作都是黑箱操作，生成的镜像也被称为 黑箱镜像，换句话说，就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像，别人根本无从得知。而且，即使是这个制作镜像的人，过一段时间后也无法记清具体的操作。这种黑箱镜像的维护工作是非常痛苦的。

而且，回顾之前提及的镜像所使用的分层存储的概念，除当前层外，之前的每一层都是不会发生改变的，换句话说，任何修改的结果仅仅是在当前层进行标记、添加、修改，而不会改动上一层。如果使用 docker commit 制作镜像，以及后期修改的话，每一次修改都会让镜像更加臃肿一次，所删除的上一层的东西并不会丢失，会一直如影随形的跟着这个镜像，即使根本无法访问到。这会让镜像更加臃肿。

利用commit理解镜像构成

gitlab-ci-delpoy的示范文件

.gitlab-ci.yaml的使用

## 3.1 慢查询分析
许多存储系统（例如MySQL）提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。

所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设阀值，就将这条命令的相关信息（例如：发生时间，耗时，命令的详细信息）记录下来，Redis也提供了类似的功能。




![image.png](/static/img/248fbef10dcfaa2886734f3a19d550b9.image.webp)

1) 发送命令
2) 命令排队
3) 命令执行
4) 返回结果

需要注意，慢查询只统计步骤3）的时间，所以没有慢查询并不代表客户端没有超时问题。

### 3.1.1 慢查询的两个配置参数


对于慢查询功能，需要明确两件事：
* 预设阀值怎么设置？
* 慢查询记录存放在哪？
Redis提供了slowlog-log-slower-than和slowlog-max-len配置来解决这两个问题。

从字面意思就可以看出，slowlog-log-slower-than就是那个预设阀值，它的单位是微秒（1秒=1000毫秒=1000000微秒），默认值是10000，

假如执行了一条“很慢”的命令（例如keys*），如果它的执行时间超过了10000微秒，那么它将被记录在慢查询日志中。

:::info{title="运维提示"}
如果slowlog-log-slower-than=0会记录所有的命令，

slowlog-log-slower￾than<0对于任何命令都不会进行记录。

:::
从字面意思看，slowlog-max-len只是说明了慢查询日志最多存储多少条，并没有说明存放在哪里？

实际上Redis使用了一个列表来存储慢查询日志，slowlog-max-len就是列表的最大长度。

一个新的命令满足慢查询条件时被插入到这个列表中，当慢查询日志列表已处于其最大长度时，最早插入的一个命令将

从列表中移出，例如slowlog-max-len设置为5，当有第6条慢查询插入的话，那么队头的第一条数据就出列，第6条慢查询就会入列。

在Redis中有两种修改配置的方法，
* 一种是修改配置文件，
* 另一种是使用config set命令动态修改。例如下面使用config set命令将slowlog-log-slowerthan设置为20000微秒，slowlog-max-len设置为1000：
```
config set slowlog-log-slower-than 20000
config set slowlog-max-len 1000
config rewrite
```
如果要Redis将配置持久化到本地配置文件，需要执行config rewrite命令，如图3-2所示。

![image.png](/static/img/45aa0f637314efe9686a19a85f37f566.image.webp)

虽然慢查询日志是存放在Redis内存列表中的，但是Redis并没有暴露这个列表的键，而是通过一组命令来实现对慢查询日志的访问和管理。下面介绍这几个命令。
>（1）获取慢查询日志
```
slowlog get [n]
```
下面操作返回当前Redis的慢查询，参数n可以指定条数：
```
127.0.0.1:6379> slowlog get
1) 1) (integer) 666
2) (integer) 1456786500
3) (integer) 11615
4) 1) "BGREWRITEAOF"
2) 1) (integer) 665
2) (integer) 1456718400
3) (integer) 12006
4) 1) "SETEX"
2) "video_info_200"
3) "300"
4) "2"
...
```
可以看到每个慢查询日志有4个属性组成，分别是慢查询日志的标识id、发生时间戳、命令耗时、执行命令和参数，慢查询列表如图3-3所示。

![image.png](/static/img/5a93226002319186d97eebd8aa7c9093.image.webp)

>（2）获取慢查询日志列表当前的长度
```
slowlog len
```
例如，当前Redis中有45条慢查询：
```
127.0.0.1:6379> slowlog len
(integer) 45
```
（3）慢查询日志重置
```
slowlog reset
```
实际是对列表做清理操作，例如：
```
127.0.0.1:6379> slowlog len
(integer) 45
127.0.0.1:6379> slowlog reset
OK
127.0.0.1:6379> slowlog len
(integer) 0
```

### 3.1.2 最佳实践
慢查询功能可以有效地帮助我们找到Redis可能存在的瓶颈，但在实际使用过程中要注意以下几点：
* slowlog-max-len配置建议：线上建议调大慢查询列表，记录慢查询时Redis会对长命令做截断操作，并不会占用大量内存。增大慢查询列表可以减缓慢查询被剔除的可能，例如线上可设置为1000以上。
* slowlog-log-slower-than配置建议：默认值超过10毫秒判定为慢查询，需要根据Redis并发量调整该值。由于Redis采用单线程响应命令，对于高流量的场景，如果命令执行时间在1毫秒以上，那么Redis最多可支撑OPS不到1000。因此对于高OPS场景的Redis建议设置为1毫秒。
* 慢查询只记录命令执行时间，并不包括命令排队和网络传输时间。因此客户端执行命令的时间会大于命令实际执行时间。因为命令执行排队机制，慢查询会导致其他命令级联阻塞，因此当客户端出现请求超时，需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞。
* 由于慢查询日志是一个先进先出的队列，也就是说如果慢查询比较多的情况下，可能会丢失部分慢查询命令，为了防止这种情况发生，可以定期执行slow get命令将慢查询日志持久化到其他存储中（例如MySQL），然后可以制作可视化界面进行查询，第13章介绍的Redis私有云CacheCloud提供了这样的功能，好的工具可以让问题排查事半功倍。


## 3.2 Redis Shell
### 3.2.1 redis-cli详解
第1章曾介绍过redis-cli，包括-h、-p参数，但是除了这些参数，还有很多有用的参数，要了解redis-cli的全部参数，

可以执行redis-cli -help命令来进行查看，下面将对一些重要参数的含义以及使用场景进行说明。

#### 1.-r
-r（repeat）选项代表将命令执行多次，例如下面操作将会执行三次ping
命令：
```
redis-cli -r 3 ping
PONG
PONG
PONG
```
#### 2.-i
-i（interval）选项代表每隔几秒执行一次命令，但是-i选项必须和-r选
项一起使用，下面的操作会每隔1秒执行一次ping命令，一共执行5次：
```
$ redis-cli -r 5 -i 1 ping
PONG
PONG
PONG
PONG
PONG
```
注意-i的单位是秒，不支持毫秒为单位，但是如果想以每隔10毫秒执行一次，可以用-i0.01，例如：
$ redis-cli -r 5 -i 0.01 ping
```
PONG
PONG
181
PONG
PONG
PONG
```
例如下面的操作利用-r和-i选项，每隔1秒输出内存的使用量，一共输出100次：
```
redis-cli -r 100 -i 1 info | grep used_memory_human
used_memory_human:2.95G
used_memory_human:2.95G
......................
used_memory_human:2.94G
```
#### 3.-x
-x选项代表从标准输入（stdin）读取数据作为redis-cli的最后一个参
数，例如下面的操作会将字符串world作为set hello的值：
```
$ echo "world" | redis-cli -x set hello
OK
```
#### 4.-c
-c（cluster）选项是连接Redis Cluster节点时需要使用的，-c选项可以防
止moved和ask异常，有关Redis Cluster将在第10章介绍。
#### 5.-a
如果Redis配置了密码，可以用-a（auth）选项，有了这个选项就不需要
手动输入auth命令。
#### 6.--scan和--pattern
--scan选项和--pattern选项用于扫描指定模式的键，相当于使用scan命令。
#### 7.--slave
--slave选项是把当前客户端模拟成当前Redis节点的从节点，可以用来获取当前Redis节点的更新操作，有关于Redis复制将在第6章进行详细介绍。

合理的利用这个选项可以记录当前连接Redis节点的一些更新操作，这些更新操作很可能是实际开发业务时需要的数据。

下面开启第一个客户端，使用--slave选项，看到同步已完成：
```
$ redis-cli --slave
SYNC with master, discarding 72 bytes of bulk transfer...
SYNC done. Logging commands from master.
```
再开启另一个客户端做一些更新操作：
```
redis-cli
127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> set a b
OK
127.0.0.1:6379> incr count
1
127.0.0.1:6379> get hello
"world"
```
第一个客户端会收到Redis节点的更新操作：
```
redis-cli --slave
SYNC with master, discarding 72 bytes of bulk transfer...
SYNC done. Logging commands from master.
"PING"
"PING"
"PING"
"PING"
"PING"
"SELECT","0"
"set","hello","world"
"set","a","b"
"PING"
"incr","count"
```
注意
PING命令是由于主从复制产生的，第6章会对主从复制进行介绍。
#### 8.--rdb
--rdb选项会请求Redis实例生成并发送RDB持久化文件，保存在本地。

可使用它做持久化文件的定期备份。有关Redis持久化将在第5章进行详细介绍。
#### 9.--pipe
--pipe选项用于将命令封装成Redis通信协议定义的数据格式，批量发送给Redis执行，有关Redis通信协议将在第4章进行详细介绍，例如下面操作同时执行了set hello world和incr counter两条命令：
```
echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\
n$7\r\ncounter\r\n' | redis-cli --pipe
```
#### 10.--bigkeys
--bigkeys选项使用scan命令对Redis的键进行采样，从中找到内存占用比较大的键值，这些键可能是系统的瓶颈。
#### 11.--eval
--eval选项用于执行指定Lua脚本，有关Lua脚本的使用将在3.4节介绍。
#### 12.--latency

latency有三个选项，分别是--latency、--latency-history、--latency-dist。
它们都可以检测网络延迟，对于Redis的开发和运维非常有帮助。
> （1）--latency

该选项可以测试客户端到目标Redis的网络延迟，例如当前拓扑结构如图3-4所示。客户端B和Redis在机房B，客户端A在机房A，机房A和机房B是跨地区的。


![image.png](/static/img/79e09503d86b2c6f8b073236b5e7ec26.image.webp)

客户端B：
```
redis-cli -h {machineB} --latency
min: 0, max: 1, avg: 0.07 (4211 samples)
```
客户端A：
```
redis-cli -h {machineB} --latency
min: 0, max: 2, avg: 1.04 (2096 samples)
```
可以看到客户端A由于距离Redis比较远，平均网络延迟会稍微高一些。
>（2）--latency-history

--latency的执行结果只有一条，如果想以分时段的形式了解延迟信息，可以使用--latency-history选项：
```
redis-cli -h 10.10.xx.xx --latency-history
min: 0, max: 1, avg: 0.28 (1330 samples) -- 15.01 seconds range…
min: 0, max: 1, avg: 0.05 (1364 samples) -- 15.01 seconds range
```
可以看到延时信息每15秒输出一次，可以通过-i参数控制间隔时间。
>（3）--latency-dist

该选项会使用统计图表的形式从控制台输出延迟统计信息。

#### 13.--stat
--stat选项可以实时获取Redis的重要统计信息，虽然info命令中的统计信息更全，但是能实时看到一些增量的数据（例如requests）对于Redis的运维还是有一定帮助的，如下所示：
```
redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys mem clients blocked requests connections
2451959 3.43G 1162 0 7426132839 (+0) 1337356
2451958 3.42G 1162 0 7426133645 (+806) 1337356 …
2452182 3.43G 1161 0 7426150275 (+1303) 1337356
```
#### 14.--raw和--no-raw
--no-raw选项是要求命令的返回结果必须是原始的格式，--raw恰恰相反，返回格式化后的结果。

在Redis中设置一个中文的value：
```
$redis-cli set hello "你好"
OK
```
如果正常执行get或者使用--no-raw选项，那么返回的结果是二进制格式：
```
$redis-cli get hello
"\xe4\xbd\xa0\xe5\xa5\xbd"
$redis-cli --no-raw get hello
"\xe4\xbd\xa0\xe5\xa5\xbd"
```
如果使用了--raw选项，将会返回中文：
```
$redis-cli --raw get hello你好
```



### 3.2.2 redis-server详解
redis-server除了启动Redis外，还有一个--test-memory选项。

redis-server --test-memory可以用来检测当前操作系统能否稳定地分配指定容量的内存给Redis，通过这种检测可以有效避免因为内存问题造成Redis崩溃，

例如下面操作检测当前操作系统能否提供1G的内存给Redis：
```
redis-server --test-memory 1024
```
整个内存检测的时间比较长。当输出passed this test时说明内存检测完毕，最后会提示--test-memory只是简单检测，如果有质疑可以使用更加专业的内存检测工具：
```
Please keep the test running several minutes per GB of memory.
Also check http:// www.memtest86.com/ and http:// pyropus.ca/software/memtester/
................忽略检测细节................
Your memory passed this test.
Please if you are still in doubt use the following two tools:
1) memtest86: http:// www.memtest86.com/
2) memtester: http:// pyropus.ca/software/memtester/
```
通常无需每次开启Redis实例时都执行--test-memory选项，该功能更偏向于调试和测试，例如，想快速占满机器内存做一些极端条件的测试，这个功能是一个不错的选择。


### 3.2.3 redis-benchmark详解

### 1.-c
-c（clients）选项代表客户端的并发数量（默认是50）。
#### 2.-n [requests]
-n（num）选项代表客户端请求总量（默认是100000）。
例如redis-benchmark-c100-n20000代表100各个客户端同时请求Redis，一共执行20000次。
    
redis-benchmark会对各类数据结构的命令进行测试，并给出性能指标：
```
====== GET ======
20000 requests completed in 0.27 seconds
100 parallel clients
3 bytes payload
keep alive: 1
99.11% <= 1 milliseconds
100.00% <= 1 milliseconds
73529.41 requests per second
```
例如上面一共执行了20000次get操作，在0.27秒完成，每个请求数据量是3个字节，99.11%的命令执行时间小于1毫秒，Redis每秒可以处理73529.41次get请求。
#### 3.-q

-q选项仅仅显示redis-benchmark的requests per second信息，例如：
```
$redis-benchmark -c 100 -n 20000 -q
PING_INLINE: 74349.45 requests per second
PING_BULK: 68728.52 requests per second
SET: 71174.38 requests per second…
LRANGE_500 (first 450 elements): 11299.44 requests per second
LRANGE_600 (first 600 elements): 9319.67 requests per second
MSET (10 keys): 70671.38 requests per second
```
#### 4.-r
在一个空的Redis上执行了redis-benchmark会发现只有3个键：
```
127.0.0.1:6379> dbsize
(integer) 3
127.0.0.1:6379> keys *
1) "counter:__rand_int__"
2) "mylist"
3) "key:__rand_int__"
```
如果想向Redis插入更多的键，可以执行使用-r（random）选项，可以向Redis插入更多随机的键。
```
$redis-benchmark -c 100 -n 20000 -r 10000
```
-r选项会在key、counter键上加一个12位的后缀，-r10000代表只对后四位做随机处理（-r不是随机数的个数）。例如上面操作后，key的数量和结果结构如下：
```
127.0.0.1:6379> dbsize
(integer) 18641
127.0.0.1:6379> scan 0
1) "14336"
2) 1) "key:000000004580"
2) "key:000000004519"
…
10) "key:000000002113"
```
#### 5.-P
-P选项代表每个请求pipeline的数据量（默认为1）。
#### 6.-k < boolean>
-k选项代表客户端是否使用keepalive，1为使用，0为不使用，默认值为1。
#### 7.-t
-t选项可以对指定命令进行基准测试。
```
redis-benchmark -t get,set -q
SET: 98619.32 requests per second
GET: 97560.98 requests per second
```
#### 8.--csv
--csv选项会将结果按照csv格式输出，便于后续处理，如导出到Excel等。
```
redis-benchmark -t get,set --csv
"SET","81300.81"
"GET","79051.38"
```

3.1 慢查询分析

2.6 有序集合