!4 修改众测检视意见part2

Merge pull request !4 from amyMaYun/DOC_CI

content/zh/docs/Administration/增加用户.md

@@ -28,7 +28,7 @@ useradd [options] user_name
 ```
 
 >![](public_sys-resources/icon-note.gif) **说明：**   
->没有任何提示，表明用户建立成功。这时并没有设置用户的口令，必须使用passwd命令修改用户的密码，没有设置密码的新账号将不能使用。  
+>没有任何提示，表明用户建立成功。这时并没有设置用户的口令，请使用passwd命令修改用户的密码，没有设置密码的新账号不能登录系统。  
 
 使用id命令查看新建的用户信息，命令如下：
 

content/zh/docs/Container/创建容器-29.md

@@ -168,7 +168,12 @@ docker run --name=container_registry -d -p 5000:5000 registry
     ```
 
 
-## 并发性能<a name="zh-cn_topic_0182302200_section4124524171619"></a>
+-   **容器基础镜像中systemd使用限制**
+
+    通过基础镜像创建的容器在使用过程中，容器基础镜像中的systemd仅用于系统容器，普通容器不支持使用。
+
+
+    ## 并发性能<a name="zh-cn_topic_0182302200_section4124524171619"></a>
 
 -   docker内部的消息缓冲有一个上限，超过这个上限就会将消息丢弃，因此在并发执行命令时建议不要超过1000条命令，否则有可能会造成docker内部消息丢失，从而造成容器无法启动等严重问题。
 -   并发创建容器并对容器执行restart时会偶现“oci runtime error: container init still running”报错，这是因为containerd对事件等待队列进行了性能优化，容器stop过程中执行runc delete，尝试在1s内kill掉容器的init进程，如果1s内init进程还没有被kill掉的话runc会返回该错误。由于containerd的GC（垃圾回收机制）每隔10s会回收之前runc delete的残留资源， 所以并不影响下次对容器的操作，一般出现上述报错的话等待4\~5s之后再次启动容器就可以了。

content/zh/docs/Container/卸载.md

 # 卸载<a name="ZH-CN_TOPIC_0184808050"></a>
 
-1. 卸载安装包：
+卸载iSulad的操作步骤如下：
 
-```
-$ sudo yum remove iSulad
-```
+1.  卸载iSulad及其依赖软件包
+    -   若使用yum方式安装，卸载的参考命令如下：
 
-2. 镜像、容器、volumes以及相关配置文件不会自动删除，需要手动删除：
+        ```
+        $ sudo yum remove iSulad
+        ```
+
+    -   若使用rpm方式安装，需卸载iSulad及其依赖包，卸载单个RPM包的参考命令如下：
+
+        ```
+        sudo rpm -ihv iSulad-xx.xx.xx-YYYYmmdd.HHMMSS.gitxxxxxxxx.aarch64.rpm
+        ```
+
+2.  镜像、容器、volumes以及相关配置文件不会自动删除，需要手动删除。参考命令如下：
+
+    ```
+    $ sudo rm -rf /var/lib/iSulad
+    ```
 
-```
-$ sudo rm -rf /var/lib/iSulad
-```
 

content/zh/docs/Container/存储驱动配置.md

-# 存储驱动配置<a name="ZH-CN_TOPIC_0184808208"></a>
-
-如果将overlay2作为graphdriver，在容器中第一次修改镜像中的文件时，若该文件的大小大于系统剩余的空间，修改将会失败。因为即使修改很小，也要把这个文件完整的拷贝到上层，剩余空间不足导致失败。
-
-overlay2文件系统相比普通文件系统天然存在一些行为差异，归纳如下：
-
-1.  内核版本
-    -   overlay2只兼容原生4.0以上内核，建议配合使用ext4文件系统.
-
-2.  Copy-UP性能问题
-    -   修改lower层文件会触发文件复制到upper层，其中数据块复制和fsync比较耗时。
-
-3.  rename目录问题
-    -   只有源路径和目标路径都在merged层时，才允许rename系统调用，否则rename系统调用会报错-EXDEV。
-    -   内核4.10引入了redirect dir特性来修复rename问题，对应内核选项为 CONFIG\_OVERLAY\_FS\_REDIRECT\_DIR。
-
-4.  Hard link break问题
-    -   当lower层目录中有多个硬链接，在merged层写入数据会触发Copy-UP，导致硬链接断开。
-    -   内核4.13引入了index feature来修复这个问题，对应内核选项为 CONFIG\_OVERLAY\_FS\_INDEX。注意这个选项没有前向兼容性，不支持热升级。
-
-5.  st\_dev和st\_ino变化
-    -   触发Copy-UP之后，用户只能看到merged层中的新文件，inode会变化。虽然attr和xattr可以复制，但st\_dev和st\_ino具有唯一性，不可复制。这会导致stat和ls查看 到相应的变化。
-
-6.  fd变化
-    -   Copy-UP之前，以只读模式打开文件得到描述符fd1，Copy-UP之后，打开同名文件得到文件描述符fd2， 二者实际指向不同的文件。向fd2写入的数据不会在fd1中体现。
-
-
-## 异常场景-挂载点被覆盖<a name="zh-cn_topic_0182217266_section03841042181112"></a>
-
-挂载关系：在问题容器的挂载点的下面，存在一个/var/lib/docker/overlay2的挂载点：
-
-```
-[root@localhost ~]# mount -l | grep overlay 
-overlay on /var/lib/docker/overlay2/844fd3bca8e616572935808061f009d106a8748dfd29a0a4025645457fa21785/merged type overlay (rw,relatime,seclabel,lowerdir=/var/lib/docker/overlay2/l/JL5PZQLNDCIBU3ZOG3LPPDBHIJ:/var/lib/docker/overlay2/l/ELRPYU4JJG4FDPRLZJCZZE4UO6,upperdir=/var/lib/docker/overlay2/844fd3bca8e616572935808061f009d106a8748dfd29a0a4025645457fa21785/diff,workdir=/var/lib/docker/overlay2/844fd3bca8e616572935808061f009d106a8748dfd29a0a4025645457fa21785/work) 
-/dev/mapper/dm-root on /var/lib/docker/overlay2 type ext4 (rw,relatime,seclabel,data=ordered)
-```
-
-此时，业务仍然可以正常运行，并不会影响业务。
-
-## 注意事项<a name="zh-cn_topic_0182217266_section171271749111218"></a>
-
--   部分容器生命周期管理的操作会报找不到相应的rootfs或者相关的可执行文件。
--   如果容器的健康检查配置的是执行容器内的可执行文件，也会报错，导致容器的健康检查失败。
-
-## 修复方案<a name="zh-cn_topic_0182217266_section1780415314132"></a>
-
--   修复方案一
-    1.  确定当前docker所使用graphdriver：
-
-        ```
-        docker info | grep "Storage Driver"
-        ```
-
-    2.  查询当前的挂载点：
-
-        ```
-        Devicemapper: mount -l | grep devicemapper 
-        Overlay2: mount -l | grep overlay2
-        ```
-
-        输出格式为： A on B type C \(D\)
-
-        -   A：块设备名称或overlay
-        -   B：挂载点
-        -   C：文件系统类型
-        -   D：挂载属性
-
-    3.  从下往上逐一umount这些挂载点B。
-    4.  然后全部docker restart这些容器，或者删除所有容器。
-    5.  重启docker。
-
-        ```
-        systemctl restart docker
-        ```
-
-
-
--   修复方案二
-    1.  业务迁移
-    2.  节点重启
-
-
+# 存储驱动配置<a name="ZH-CN_TOPIC_0215574099"></a>
\ No newline at end of file

content/zh/docs/Container/安装方法.md

 # 安装方法<a name="ZH-CN_TOPIC_0184808040"></a>
 
-iSulad可以通过以下两种方式进行安装：
+iSulad可以通过yum或rpm命令两种方式安装，由于yum会自动安装依赖，而rpm命令需要手动安装所有依赖，所以推荐使用yum安装。
 
--   执行以下命令进行安装\(推荐\)：
+这里给出两种安装方式的操作方法。
+
+-   （推荐）使用yum安装iSulad，参考命令如下：
 
     ```
     $ sudo yum install -y iSulad
     ```
 
 
--   下载iSulad及其所有依赖库的RPM包手动安装：
+-   使用rpm安装iSulad，需要下载iSulad及其所有依赖库的RPM包，然后手动安装。安装单个iSulad的RPM包（依赖包安装方式相同），参考命令如下：
 
     ```
-    $ sudo rpm -ihv iSulad-xx.xx.xx-YYYYmmdd.HHMMSS.gitxxxxxxxx.openEulerxxx.aarch64.rpm
+    $ sudo rpm -ihv iSulad-xx.xx.xx-YYYYmmdd.HHMMSS.gitxxxxxxxx.aarch64.rpm
     ```
 
 

content/zh/docs/Container/约束限制.md

@@ -25,11 +25,11 @@
 
     使用iSulad命令行接口时，其参数解析方式与docker略有不同，对于命令行中带参数的flag，不管使用长flag还是短flag，只会将该flag后第一个空格或与flag直接相连接的'='后的字符串作为flag的参数，具体如下：
 
-    1\) 使用短flag时，与破折号-连接的字符串中的每个字符都被当作短flag（当有=号时，=号后的字符串当成=号前的短flag的参数）。
+    1\) 使用短flag时，与“-”连接的字符串中的每个字符都被当作短flag（当有=号时，=号后的字符串当成=号前的短flag的参数）。
 
     lcrc run -du=root busybox 等价于 lcrc run -du root busybox 或 lcrc run -d -u=root busybox 或 lcrc run -d -u root busybox ，当使用lcrc run -du:root时，由于-:不是有效的短flag，因此会报错。前述的命令行也等价于lcrc run -ud root busybox，但不推荐这种使用方式，可能带来语义困扰。
 
-    2）使用长flag时，与双破折号--连接的字符串作为一个整体当成长flag，若包含=号，则=号前的字符串为长flag，=号后的为参数。
+    2）使用长flag时，与“--”连接的字符串作为一个整体当成长flag，若包含=号，则=号前的字符串为长flag，=号后的为参数。
 
     ```
     lcrc run --user=root busybox

content/zh/docs/Container/配置TLS认证与开启远程访问.md

@@ -2,7 +2,7 @@
 
 ## 描述<a name="zh-cn_topic_0183092517_section142111513104513"></a>
 
-iSulad采用C/S模式进行设计，在默认情况，iSulad守护进程lcrd只监听本地/var/run/lcrd.sock，因此只能在本地通过客户端lcrc执行相关命令操作容器。为了能使lcrc可以远程访问容器，lcrd守护进程需要通过tcp:ip的方式监听远程访问的端口。然而，仅通过简单配置tcp ip:port进行监听，这样会导致所有的ip都可以通过调用lcrc -H tcp://<remote server ip\>:port与lcrd通信，容易导致安全问题，因此推荐使用更加安全的方式TLS\(**Transport Layer Security - 安全传输层协议**）进行远程访问。
+iSulad采用C/S模式进行设计，在默认情况，iSulad守护进程lcrd只侦听本地/var/run/lcrd.sock，因此只能在本地通过客户端lcrc执行相关命令操作容器。为了能使lcrc可以远程访问容器，lcrd守护进程需要通过tcp:ip的方式侦听远程访问的端口。然而，仅通过简单配置tcp ip:port进行侦听，这样会导致所有的ip都可以通过调用lcrc -H tcp://<remote server ip\>:port与lcrd通信，容易导致安全问题，因此推荐使用较安全的TLS\(**Transport Layer Security - 安全传输层协议**）方式进行远程访问。
 
 ## 生成TLS证书<a name="zh-cn_topic_0183092517_section992244212139"></a>
 

content/zh/docs/Container/配置overlay2存储驱动.md

+# 配置overlay2存储驱动<a name="ZH-CN_TOPIC_0215574100"></a>
+
+本发行版docker支持overlay2和devicemapper两种存储驱动。由于overlay2较devicemapper而言，拥有更好的性能，建议用户在生成环境中优先考虑。
+
+## 配置overlay2存储驱动<a name="zh-cn_topic_0215573557_section1924141210352"></a>
+
+docker默认为使用overlay2存储驱动，也可以通过如下两种方式显示指定
+
+-   编辑/etc/docker/daemon.json，通过storage-driver字段显示指定
+
+```
+cat /etc/docker/daemon.json
+{
+    "storage-driver": "overlay2"
+}
+```
+
+-   编辑/etc/sysconfig/docker-storage，通过docker deamon启动参数显示指定
+
+```
+cat /etc/sysconfig/docker-storage 
+DOCKER_STORAGE_OPTIONS="--storage-driver=overlay2"
+```
+
+如果将overlay2作为graphdriver，在容器中第一次修改镜像中的文件时，若该文件的大小大于系统剩余的空间，修改将会失败。因为即使修改很小，也要把这个文件完整的拷贝到上层，剩余空间不足导致失败。
+
+overlay2文件系统相比普通文件系统天然存在一些行为差异，归纳如下：
+
+1.  内核版本
+    -   overlay2只兼容原生4.0以上内核，建议配合使用ext4文件系统。
+
+2.  Copy-UP性能问题
+    -   修改lower层文件会触发文件复制到upper层，其中数据块复制和fsync比较耗时。
+
+3.  rename目录问题
+    -   只有源路径和目标路径都在merged层时，才允许rename系统调用，否则rename系统调用会报错-EXDEV。
+    -   内核4.10引入了redirect dir特性来修复rename问题，对应内核选项为CONFIG\_OVERLAY\_FS\_REDIRECT\_DIR。
+
+        使用overlay2时，在文件系统中对于目录进行重命名时，因为EulerOS中/sys/module/overlay/parameters/redirect\_dir特性开关已设置为关闭状态，则会导致使用失败；如果用户要使用相关特性，需要用户手动设置/sys/module/overlay/parameters/redirect\_dir为“Y”。
+
+4.  Hard link break问题
+    -   当lower层目录中有多个硬链接，在merged层写入数据会触发Copy-UP，导致硬链接断开。
+    -   内核4.13引入了index feature来修复这个问题，对应内核选项为 CONFIG\_OVERLAY\_FS\_INDEX。注意这个选项没有前向兼容性，不支持热升级。
+
+5.  st\_dev和st\_ino变化
+    -   触发Copy-UP之后，用户只能看到merged层中的新文件，inode会变化。虽然attr和xattr可以复制，但st\_dev和st\_ino具有唯一性，不可复制。这会导致stat和ls查看 到相应
\ No newline at end of file