查看容器的编译信息

① Docker常用命令，值得收藏

使用指定的镜像来运行容器，并可选地在容器中运行指定的命令。

分离模式 ：通过 -d 选项指定；容器会在任务（进程）结束时退出。
前台模式 ：可以将控制台连接到容器中进程的标准输入、输出、错误；通过 -t 选项可以为其分配一个伪终端；通过 -i 选项可以保持标准输入处于打开状态。

--rm 选项能够在容器退出时自动删除容器。

罗列容器。

-a 选项可以列出所有的容器。

查看容器的详细信息。

查看容器中运行的进程。

持续输出容器的资源使用情况。

查看容器的端口映射。

查看容器的日志（标准输出、错误的内容）。

-f 选项可以持续输出容器的日志。

将本地终端的标准输入、输出、错误连接到容器。

在运行的容器中执行指定的命令。

使用 freezer cgroup 挂起容器中的所有进程（进程对挂起操作是无感知的）。

恢复容器中挂起的进程。

停止容器，终止容器中的进程：首先发送 SIGTERM 信号给容器中的进程，一段时间之后发送 SIGKILL 信号。

启动停止的容器（还是运行之前给定的命令）。

删除指定的容器。

--force 选项可以强制性删除运行的容器。

在容器和主机之间拷贝文件、目录。

将容器的文件系统（不包括卷的内容）导出为 tar 文件，后续可通过 docker import 来加载镜像。

查看所有的顶层镜像。

-a 选项可以查看所有的镜像。

搜索 docker hub。

拉取镜像。

基于源镜像创建一个包含 tag 的镜像。

推送镜像。

从 tar 文件中加载镜像。

保存镜像为 tar 文件，后续可通过 docker load 来加载。

可通过 -o 选项将镜像保存至指定的文件，默认输出到标准输出。

从标准输入或 tar 文件中加载镜像。

-i 选项指定从 tar 文件中加载镜像。

删除本地镜像。如果 IMAGE 包含了 tag，且该镜像具有多个 tags，则此命令只是移除该 tag，而不会删除镜像。

-f 选项可强制删除运行容器所用的镜像。

② docker的容器常规操作

解释：创建一个容器，但容器处于停止状态

解释：启动容器

解释：
-t : 让Docker分配一个伪终端并绑定到容器的标准输入上
-i: 让容器的标准输入保持打开
-d: 让Docker容器在后台以守护态运行

解释：
-details:打印详细信息
-f,-follow:保持持续输出
-since string:输出从某个时间开始的日志
-tail string:输出最近的若干日志
-t,-timestamps:输出时间戳信息
-until string:输出某个时间之前的日志

解释：暂停容器，暂停后，容器处于paused状态

解释：将paused状态的容器恢复至运行状态

解释： 终止一个运行状态的容器，但是这个终止不是立即执行的。该命令会先向容器发送一个SIGTERM信号，等待一段超时时间（默认为10s）后,再发送SIGKILL信号终止容器，而终止容器的关键就在于SIGKILL信号。

解释： 终止一个运行状态的容器，但是这个终止是立即执行的。该命令直接发送SIGKILL信号强行终止容器。

解释： 重启容器

解释：进入容器。使用这个命令有时候并不方便，当多个窗口同时attach到同一个容器的时候，所有窗口都会同步显示；当某个窗口因命令阻塞时，其他窗口也无法执行操作；默认使用CTRL+q或者CTRL+p退出容器

解释：
-d,--detach:在容器中后台执行命令
--detach-keys="":指定将容器切回后台的案件
-e,--env=[]:指定环境变量列表
-i,--interactive=true|false:打开标准输入接收用户输入命令，默认值为false
--privileged=true|false:是否给执行命令以高权限，默认值为false
-t,--try=true|false:分配伪终端，默认值为false
-u，--user=""：执行命令的用户名或ID

解释：
删除处于退出或者终止状态的容器
-f,--force=false:是否强行终止并删除一个处于运行状态的容器
-l,--link=false:删除容器的链接，但保留容器
-v,--volumns=false:删除容器挂载的数据卷

解释：导出容器。导出一个已经创建的容器到文件，不管此时这个容器是否处于运行状态。在这里如果把export换成save，再把af18换成镜像名称：tag，就是导出镜像的命令了。但是这两个命令的区别在于：docker export命令丢弃了原容器的历史信息及元数据,而docker save命令会保留原文件的历史信息。

解释：将导出的文件变成镜像。当然，这个也可以用docker load命令来执行。

解释：查看容器具体信息，比如：容器ID,创建时间，路径，状态，镜像，配置等

解释： 查看容器内进程信息

解释：查看容器的内存、CPU、存储、网络等使用情况
-a,-all:输出所有容器统计信息
-format string: 格式化输出信息
-no-stream:不持续输出，默认会自动更新持续实时结果
-no-trunc:不截断输出信息

解释：第一行命令为将test容器的temp文件夹复制到主机的data文件夹下
第二行的命令为将主机的data文件夹复制到test容器的tmp文件夹下

解释：查看容器内的数据修改

解释：查看test容器的端口映射情况

解释：修改容器的一些运行时配置。主要是一些资源限制配额。

③ 很多应用容器都是默认后台运行的，怎么查看它们的输出和日志信息

使用docker logs，后面跟容器的名称或者ID信息，我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。 如果我的回答能够对您有帮助的话，求给大大的赞。

④ Docker检查运行中的容器的详细信息

查看容器中详细信息，命令很简单，dcoker inspect id

首先用docker ps查看所有启动的镜像，

[root@bogon ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
44ab452b47fe docker.io/ubuntu:latest "/bin/bash" About a minute ago Up About a minute prickly_blackwell
[root@bogon ~]#

可以看到id是 44ab。。。。

利用命令查看容器的详细信息
[root@bogon ~]# docker inspect 44ab452b4
[
{
"Id": "",
"Created": "2016-01-12T13:46:16.365773903Z",
"Path": "/bin/bash",
"Args": [],
"State": {

输出太多了 我只截取了一部分。

⑤ Docker：容器管理（启动参数，查看容器和日志，进入和修改容器）

摘要： Docker

容器是一个精简版的操作系统，一般一个容器只运行一个应用，容器通过镜像创建，使用 docker run 命令创建，容器起到了 隔离 作用，容器和容器之间独享空间和网络等

容器的基本操作包括创建（启动），停止，重启，查看，检查等，容器通过镜像创建，使用 docker run 命令创建，需要指定run参数，镜像名，容器执行命令，语句格式如下

在实际使用中启动一个镜像，例如

-e 设置环境变量，格式是 -e k1=v1 -e k2=v2 ，使得在docker镜像中的程序能够直接访问到环境变量，同时可以作为配置参数放在docker run启动镜像的时候设置，而不是写死在dockerfile在build的过程中，-e和dockerfile中的 ENV 变量作用相同，当变量重名时-e替换ENV，下面测试一些-e参数，在Dockerfile指定环境变量

直接构建成容器

开启一个终端启动容器内部，打印指定的环境变量a

此时在run指令中增加-e设置环境变量，可见-e替换了Dockerfile中指定的环境变量

因为一个镜像可以启动多个容器，所以可以通过设置不同-e达到设置不同配置参数的目的，比如下一个例子在Dockerfile中设置和将环境变量写入yaml文件再供Python调用，执行的内容为打印yaml配置文件的参数内容，比如下面这个例子先看下目录结构

其中config.yml是一个空配置文件，在run.sh中先使用echo写入追加配置参数到config.yml在执行Python脚本

Dockerfile中启动run.sh脚本作为容器执行命令

在启动容器时，使用-e指定环境变量，在run.sh中echo将环境变量拿到和写入配置文件，测试多次以不同的配置参数启动容器如下

-v 设置挂载运行，将宿主机当前目录下的文件挂载到容器中/home目录下，例如

如果挂载的目录和Dockerfile中的COPY的目录不一致， -v会替代COPY或者ADD ，例如现在Docker中COPY一个文件到容器/home目录下

同目录下start.sh内容是打印1

构建镜像结束后，指定-v启动，起始挂载另外一个目录，目录下start.sh内容是打印2

docker run参数中最后的COMMAND会覆盖Dockerfile中指定的 CMD ，例如执行echo 2替换原始Dockerfile中的CMD echo 1，输出结果是2且执行完毕后退出

对于Dockerfile中的 ENTRYPOINT 指定的启动命令docker run的COMMAND不会覆盖，如果要覆盖Docker中的ENTRYPOINT需要指定docker run中的 --entrypoint 参数，格式是

测试一个Dockerfile输出1

在docker run中使用--entrypoint覆盖Dockerfile中的ENTRYPOINT

容器启动后通过 docker ps 或者 docker container ls 查看容器，可以增加额外参数比如 -a 显示所有容器，默认只显示运行的容器，可以增加 --no-trunc 参数使得显示结果不截断，例如

显示结果分别显示了容器的ID，镜像，执行命令，创建时间，状态，端口映射（宿主机->容器）和容器名称。对于已经运行的容器可以使用 docker stop 停止，如果在docker run时增加--rm参数则停止的容器保留不会自动删除，例如

除了docker stop命令还有一种停止容器的命令 docker kill ，相比于docker stop，docker kill是 强制立即停止 ，而docker stop是先给了容器10秒（默认）的时间，使得容器有一定的时间处理、保存程序执行现场， 优雅的退出程序 ，例如

在容器停止之后可以使用 docker start 再启动一个停止的容器，例如

除此之外可以使用 docker restart ，此时容器可以使停止的也可以是在运行中的，例如

查看容器详情使用 docker inspect ，比如

在以上截取的内容中展示了容器详情，包括容器id，创建时间，执行命令和参数，执行状态，容器pid，落脚点，环境变量，网络设置，端口映射等，也可以使用Go语言风格输出指定的详情，比如分别只看容器的pid和容器的执行命令

容器是一个操作系统，可以进入这个操作系统查看容器的运行情况，有多种方式进入容器，其中主要是使用 docker exec 进入容器，在一个运行中的容器中执行一个命令，使用 -it 并带有 /bin/bash 命令就可以进入容器，比如

除了/bin/bash也可以是其他命令挂载exec后面则可以直接对一个运行中的容器执行命令，比如查看容器的进入落脚点路径，容器中的内存情况

当容器以后台 -d 运行时，日志运行在容器内部，可以进入容器内部查看日志，也可以使用 docker logs 查看日志，以一个flask api接口的容器为例，日志写入文件，同时也会输出在flask的控制台

创建Dockerfile以及构建镜像，启动容器

启动一个脚本不断请求api接口

进入容器内部查看日志

另一种方式是直接使用 docker logs 命令，比如使用 -f 追踪输出，并且从最后的第1行开始输出

此时宿主机的logs目录下为空，容器中的logs目录下存在detail.log文件，如果使用 -v 将宿主机目录挂载到容器作为容器写入的目录，则容器中数据的变动会同步到本地，这样可以直接在本地查看日志，修改容器启动为 -v 挂载的形式

此时本地logs目录下开始产生日志，且这个日志和容器内的logs目录下一致

如果容器内的内容改变了，此时删除容器从镜像重新启动容器则改动的内容将不会存在，如果相对修改过的容器保留下来则可以从容器生成新的镜像，先测试以下容器内修改在删除的容器后将不再生效，在已有容器中使用pip安装Python包

此时退出容器，并且删除容器，最后从镜像重新生成容器

此时进入容器检查，并不存在pymongo包

如果要容器变化保存下来需要以这个新容器生成一个镜像，使用 docker commit ，语法如下

以新安装pymongo的容器为例，对新容器使用docker commmit

新生成的镜像叫做xiaogp/my_image_test:v2

从新镜像启动容器并进入容器查看存在新安装的pymongo

⑥ 网站中的jsp无法运行

网站中的jsp无法运行，表示当前的web容器可能编译或者执行出错，需从一下几方面检查。
1、web项目中jsp是否页签完整，包括一些标签前后结束，是否编码不支持中文等。
2、web容器是否已经配置正确，是否成功加载了web项目。
3、web容器加载项目成功，查看控制台或者tomcat容器下的log文件夹下的catalina.out文件，检查日志信息。
4、如果成功运行web项目，只是部分jsp不能运行，可以直接到web容易编译的目录查看具体哪个文件哪一行发生错误。

⑦ 如何查看c++ vector容器源代码

1）.#include <iostream>
#include <vector>using namespace std;int main()
{
int a[7]={1,2,3,4,5,6,7};
vector<int> va(a,a+7); for(int i=0;i<va.size();i++)
cout<<va[i]<<" ";
} 这个是简单的遍历向量，输出向量全部元素。 2).这是简单的从向量 test.txt 文本文件中提取数据到向量 vector<string> va 中，然后在输出。test.txt 的文本内容如下： 运行结果如下：//程序代码如下：#include <iostream>
#include <vector>
#include <fstream>
#include <string>using namespace std;int main()
{
vector<string> va;
ifstream in("test.txt");
for(string s;in>>s;)
va.push_back(s);
for(int i=0;i<va.size();i++)
cout<<va[i]<<" ";
}

⑧ 如何查看一个jar文件是用什么版本jdk编译的

1.步骤如下：

在jar包中，用winrar解压一个类文件，然后在命令行下面输入
javap -verbose classname
会输出一些信息，大致如下:

Compiled from "HtmlCrawer.Java"
public class org.eagleeye.html.HtmlCrawer extends java.lang.Object
SourceFile: "HtmlCrawer.java"
minor version: 0
major version: 50
Constant pool:
const #1 = class #2; // org/eagleeye/html/HtmlCrawer
const #2 = Asciz org/eagleeye/html/HtmlCrawer;
const #3 = class #4; // java/lang/Object
const #4 = Asciz java/lang/Object;
const #5 = Asciz client;
....

后面省略了，可以看到前面有两行:
minor version: 0
major version: 50

2.解决问题：

我们在尝鲜 JDK1.5 的时候，相信不少人遇到过 Unsupported major.minor version 49.0 错误，当时定会茫然不知所措。因为刚开始那会儿，网上与此相关的中文资料还不多，现在好了，网上一找就知道是如何解决，大多会告诉你要使用 JDK 1.4 重新编译。那么至于为什么，那个 major.minor 究竟为何物呢？这就是本篇来讲的内容，以使未错而先知。

我觉得我是比较幸运的，因为在遇到那个错误之前已研读过《深入 Java 虚拟机》第二版，英文原书名为《Inside the Java Virtual Machine》( Second Edition)，看时已知晓 major.minor 藏匿于何处，但没有切身体会，待到与 Unsupported major.minor version 49.0 真正会面试，正好是给我验证了一个事实。

首先我们要对 Unsupported major.minor version 49.0 建立的直接感觉是：JDK1.5 编译出来的类不能在 JVM 1.4 下运行，必须编译成 JVM 1.4 下能运行的类。(当然，也许你用的还是 JVM 1.3 或 JVM 1.2，那么就要编译成目标 JVM 能认可的类)。这也解决问题的方向。

3.major.minor 栖身于何处

何谓 major.minor，且又居身于何处呢？先感性认识并找到 major.minor 来。

写一个 Java Hello World! 代码，然后用 JDK 1.5 的编译器编译成，HelloWorld.java

public class HelloWorld

{

public static void main(String[] args)

{

System.out.println("Hello, World!");

}

}

public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } }

用 JDK 1.5 的 javac HelloWorld.java 编译出来的字节码 HelloWorld.class 用 UltraEdit 打开来的内容如图所示：

从上图中我们看出来了什么是 major.minor version 了，它相当于一个软件的主次版本号，只是在这里是标识的一个 Java Class 的主版本号和次版本号，同时我们看到 minor_version 为 0x0000，major_version 为 0x0031，转换为十制数分别为0 和 49，即 major.minor 就是 49.0 了。

4.何谓 major.minor 以及何用

Class 文件的第 5-8 字节为 minor_version 和 major_version。Java class 文件格式可能会加入新特性。class 文件格式一旦发生变化，版本号也会随之变化。对于 JVM 来说，版本号确定了特定的 class 文件格式，通常只有给定主版本号和一系列次版本号后，JVM 才能够读取 class 文件。如果 class 文件的版本号超出了 JVM 所能处理的有效范围，JVM 将不会处理该 class 文件。

在 Sun 的 JDK 1.0.2 发布版中，JVM 实现支持从 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 发布版中的 JVM 都能够支持版本从 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能够支持从版本 45.0 到46.0 的 class 文件格式。

1.0 或 1.2 版本的编译器能够产生版本号为 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 编译器默认产生版本号为 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 标志，1.2 版本的编译器将产生版本号为 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能运行使用-target 1.2 标志所产生的 class 文件。

JVM 实现的 第二版中修改了对 class 文件主版本号和次版本号的解释。对于第二版而言，class 文件的主版本号与 Java 平台主发布版的版本号保持一致(例如：在 Java 2 平台发布版上，主版本号从 45 升至 46)，次版本号与特定主平台发布版的各个发布版相关。因此，尽管不同的 class 文件格式可以由不同的版本号表示，但版本号不一样并不代表 class 文件格式不同。版本号不同的原因可能只是因为 class 文件由不同发布版本的 java 平台产生，可能 class 文件的格式并没有改变。

上面三段节选自《深入 Java 虚拟机》，啰嗦一堆，JDK 1.2 开启了 Java 2 的时代，但那个年代仍然离我们很远，我们当中很多少直接跳在 JDK 1.4 上的，我也差不多，只是项目要求不得不在一段时间里委屈在 JDK 1.3 上。不过大致我们可以得到的信息就是每个版本的 JDK 编译器编译出的 class 文件中都带有一个版本号，不同的 JVM 能接受一个范围 class 版本号，超出范围则要出错。不过一般都是能向后兼容的，知道 Sun 在做 Solaris 的一句口号吗？保持对先前版本的 100% 二进制兼容性，这也是对客户的投资保护。

四：编译器比较及症节之所在

现在不妨从 JDK 1.1 到 JDK 1.7 编译器编译出的 class 的默认 minor.major version 吧。（又走到 Sun 的网站上翻腾出我从来都没用过的古董来）

JDK 编译器版本 target 参数 十六进制 minor.major 十进制 minor.major jdk1.1.8 不能带 target 参数 00 03 00 2D 45.3 jdk1.2.2 不带(默认为 -target 1.1) 00 03 00 2D 45.3 jdk1.2.2 -target 1.2 00 00 00 2E 46.0 jdk1.3.1_19 不带(默认为 -target 1.1) 00 03 00 2D 45.3 jdk1.3.1_19 -target 1.3 00 00 00 2F 47.0 j2sdk1.4.2_10 不带(默认为 -target 1.2) 00 00 00 2E 46.0 j2sdk1.4.2_10 -target 1.4 00 00 00 30 48.0 jdk1.5.0_11 不带(默认为 -target 1.5) 00 00 00 31 49.0 jdk1.5.0_11 -target 1.4 -source 1.4 00 00 00 30 48.0 jdk1.6.0_01 不带(默认为 -target 1.6) 00 00 00 32 50.0 jdk1.6.0_01 -target 1.5 00 00 00 31 49.0 jdk1.6.0_01 -target 1.4 -source 1.4 00 00 00 30 48.0 jdk1.7.0 不带(默认为 -target 1.6) 00 00 00 32 50.0 jdk1.7.0 -target 1.7 00 00 00 33 51.0 jdk1.7.0 -target 1.4 -source 1.4 00 00 00 30 48.0 Apache Harmony 5.0M3 不带(默认为 -target 1.2) 00 00 00 2E 46.0 Apache Harmony 5.0M3 -target 1.4 00 00 00 30 48.0
上面比较是 Windows 平台下的 JDK 编译器的情况，我们可以此作些总结：

1) -target 1.1 时 有次版本号，target 为 1.2 及以后都只用主版本号了，次版本号为 0
2) 从 1.1 到 1.4 语言差异比较小，所以 1.2 到 1.4 默认的 target 都不是自身相对应版本
3) 1.5 语法变动很大，所以直接默认 target 就是 1.5。也因为如此用 1.5 的 JDK 要生成目标为 1.4 的代码，光有 -target 1.4 不够，必须同时带上 -source 1.4，指定源码的兼容性，1.6/1.7 JDk 生成目标为 1.4 的代码也如此。
4) 1.6 编译器显得较为激进，默认参数就为 -target 1.6。因为 1.6 和 1.5 的语法无差异，所以用 -target 1.5 时无需跟着 -source 1.5。
5) 注意 1.7 编译的默认 target 为 1.6
6) 其他第三方的 JDK 生成的 Class 文件格式版本号同对应 Sun 版本 JDK
7) 最后一点最重要的，某个版本的 JVM 能接受 class 文件的最大主版本号不能超过对应 JDK 带相应 target 参数编译出来的 class 文件的版本号。

上面那句话有点长，一口气读过去不是很好理解，举个例子：1.4 的 JVM 能接受最大的 class 文件的主版本号不能超过用 1.4 JDK 带参数 -target 1.4 时编译出的 class 文件的主版本号，也就是 48。

因为 1.5 JDK 编译时默认 target 为 1.5，出来的字节码 major.minor version 是 49.0，所以 1.4 的 JVM 是无法接受的，只有抛出错误。

那么又为什么从 1.1 到 1.2、从 1.2 到 1.3 或者从 1.3 到 1.4 的 JDK 升级不会发生 Unsupported major.minor version 的错误呢，那是因为 1.2/1.3/1.4 都保持了很好的二进制兼容性，看看 1.2/1.3/1.4 的默认 target 分别为 1.1/1.1/1.2 就知道了，也就是默认情况下1.4 JDK 编译出的 class 文件在 JVM 1.2 下都能加载执行，何况于 JVM 1.3 呢？（当然要去除使用了新版本扩充的 API 的因素）

5：找到问题解决的方法

那么现在如果碰到这种问题该知道如何解决了吧，还会像我所见到有些兄弟那样，去找个 1.4 的 JDK 下载安装，然后用其重新编译所有的代码吗？其实大可不必如此费神，我们一定还记得 javac 还有个 -target 参数，对啦，可以继续使用 1.5 JDK，编译时带上参数 -target 1.4 -source 1.4 就 OK 啦，不过你一定要对哪些 API 是 1.5 JDK 加入进来的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就会 method not found。目标 JVM 是 1.3 的话，编译选项就用 -target 1.3 -source 1.3 了。

相应的如果使用 ant ，它的 javac 任务也可对应的选择 target 和 source

<javac target="1.4" source="1.4" ............................/>

如果是在开发中，可以肯定的是现在真正算得上是 JAVA IDE 对于工程也都有编译选项设置目标代码的。例如 Eclipse 的项目属性中的 Java Compiler 设置，如图

自已设定编译选项，你会看到选择不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在变，你也可以手动调整那两项，手动设置后你就不用很在乎用的什么版本的编译器了，只要求他生成我们希望的字节码就行了，再引申一下就是即使源代码是用 VB 写的，只要能编译成 JVM 能执行的字节码都不打紧。在其他的 IDE 也能找到相应的设置对话框的。

其他时候，你一定要知道当前的 JVM 是什么版本，能接受的字节码主版本号是多少（可对照前面那个表）。获息当前 JVM 版本有两种途径：

第一：如果你是直接用 java 命令在控制台执行程序，可以用 java -version 查看当前的 JVM 版本，然后确定能接受的 class 文件版本

第二：如果是在容器中执行，而不能明确知道会使用哪个 JVM，那么可以在容器中执行的程序中加入代码System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，获得 JVM 版本和能接受的 class 的版本号。

最后一绝招，如果你不想针对低版本的 JVM 用 target 参数重新编译所有代码；如果你仍然想继续在代码中用新的 API 的话；更有甚者，你还用了 JDK 1.5 的新特性，譬如泛型、自动拆装箱、枚举等的话，那你用 -target 1.4 -source 1.4 就没法编译通过，不得不重新整理代码。那么告诉你最后一招，不需要再从源代码着手，直接转换你所正常编译出的字节码，继续享用那些新的特性，新的 API，那就是：请参考之前的一篇日志：Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行，我就是这么用的，做好测试就不会有问题的。

6：再议一个实际发生的相关问题

这是一个因为拷贝 Tomcat 而产生的 Unsupported major.minor version 49.0 错误。情景是：我本地安装的是 JDK 1.5，然后在网上找了一个 EXE 的 Tomcat 安装文件安装了并且可用。后来同事要一个 Tomcat，不想下载或安装，于是根据我以往的经验是把我的 Tomcat 整个目录拷给他应该就行了，结果是拿到他那里浏览 jsp 文件都出现 Unsupported major.minor version 49.0 错误，可以确定的是他安装的是 1.4 的 JDK，但我还是有些纳闷，先前对这个问题还颇有信心的我傻眼了。惯性思维是编译好的 class 文件拿到低版本的 JVM 会出现如是异常，可现并没有用已 JDK 1.5 编译好的类要执行啊。

后来仔细看异常信息，终于发现了 %TOMCAT_HOME%commonlib ools.jar 这一眉目，因为 jsp 文件需要依赖它来编译，打来这个 tools.jar 中的一个 class 文件来看看，49.0，很快我就明白原来这个文件是在我的机器上安装 Tomcat 时由 Tomcat 安装程序从 %JDK1.5%lib 目录拷到 Tomcat 的 lib 目录去的，造成在同事机器上编译 JSP 时是 1.4 的 JVM 配搭着 49.0 的 tools.jar，那能不出错，于是找来 1.4 JDK 的 tools.jar 替换了 Tomcat 的就 OK 啦。

⑨ 如何编译Docker源码

本文根据docker官方给出的docker代码编译环境搭建指南做更深入的分析。官方给出的指导比较简单，但是由于国内的网络问题经常会编译失败，了解了编译步骤后，也可以结合自身遇到的网络问题进行“规避”。
docker的编译环境实际上是创建一个docker容器，在容器中对代码进行编译。 如果想快速的查看编译环境搭建指导，而不关注环境搭建的机制和细节，可以直接跳到最后一章“总结”。

前提
机器上已经安装了docker，因为编译环境是个docker容器，所以要事先有docker（daemon），后面会创建个编译环境容器，在容器里面编译代码。本文中使用物理机，物理机上运行着docker （daemon）。
机器（物理机）上安装了git 。 后续使用git下载docker源码
机器（物理机）上安装了make。
下载ubuntu 14.04的docker镜像

下载docker源码
git clone
会把代码下载到当前目录下，后面会把代码拷贝到容器中。

编译前分析
官方给的编译方法是make build 和 make binary等。下面先分析Makefile，看懂Makefile后，编译环境的准备流程就比较清楚了。

Makefile
在下载的docker源码中可以看到它的Makefile，Makefile中比较关键的几个参数：
DOCKER_MOUNT := $(if $(BIND_DIR),-v "$(CURDIR)/$(BIND_DIR):/go/src/github.com/docker/docker/$(BIND_DIR)") DOCKER_MOUNT 表示创建容器时的mount参数。因为编译环境是一个容器，在后续的步骤中启动容器时使用DOCKER_MOUNT参数，会将物理机上的目录mount给容器容器，容器中该目录是编译生成docker二进制文件的目录。
DOCKER_FLAGS := docker run --rm -i --privileged $(DOCKER_ENVS) $(DOCKER_MOUNT) 这是后面创建docker容器时的命令行的一部分，其中包含了前面的DOCKER_MOUNT参数。
DOCKER_IMAGE := docker-dev$(if $(GIT_BRANCH),:$(GIT_BRANCH)) 这是docker image参数，镜像的名字是docker-dev，以当前git中docker版本作为tag名。这个镜像是在make build一步做出来的。
DOCKER_RUN_DOCKER := $(DOCKER_FLAGS) "$(DOCKER_IMAGE)" 创建docker容器的命令行，组合了前面的DOCKER_FLAGS 和 DOCKER_IMAGE 。 从命令行中可以看出，启动容器使用的参数有 --rm -i --privileged，使用了一些环境变量，还有使用了-v参数把物理机上目录mount给容器，在容器中编译好二进制文件后放到该目录中，在物理机上就能获得docker二进制文件。启动的的docker 容器镜像名字是docker-dev。下文会介绍docker-dev镜像是怎么来的。
由于官方给出的“构建编译环境”的方法是执行 make build，下面在Makefile中看到build分支是这样的：

make build时会调用 docker build -t "$(DOCKER_IMAGE)" . 去制作一个叫做DOCKER_IMAGE的镜像。
进行源码编译的方式是执行 make binary来编译代码，在Makefile中make binary的分支如下：

make binary除了进行 make build以外，会执行$(DOCKER_RUN_DOCKER)，即上文提到的docker run命令行。由于执行过了build，会build出来docker-dev镜像，所以在docker run时直接使用前面build出来的镜像。docker run时的命令行参数是hack/make.sh binary。make binary的过程实际上是创建一个容器，在容器中执行hack/make.sh binary脚本。接下来会详细介绍make build和make binary所做的内容。
make build
根据官方的指导，先执行make build来搭建编译环境。上面分析了，make build实际上是制作了一个镜像，这个镜像里会包含编译代码所需的环境。下面来介绍下这个镜像。

Dockerfile
在和Makefile相同的目录下（源码的根目录），有Dockerfile。执行make build 相当于调用docker build，使用的就是该Dockerfile。Dockerfile中的几个主要步骤（有些步骤这里略过）：
FROM ubuntu:14.04 使用ubuntu 14.04作为基础镜像；在宿主机上，要事先下载好ubuntu 14.04镜像。
安装一些编译需要的软件；
用git下载lvm2源码，并编译安装；
下载并安装GO 1.5.1；
安装GO相关的tools 可以做code coverage test 、 go lint等代码检查
安装registry和notary server；
安装docker-py 后面跑集成测试用的
将物理机的contrib/download-frozen-image.sh 脚本拷贝到镜像中/go/src/github.com/docker/docker/contrib/
运行contrib/download-frozen-image.sh 制作镜像 实际上这一步只是下载了3个镜像的tar文件。注意：docker build相当于创建一个临时的容器（在临时的容器中执行Dockerfile中的每一步，最后在保存成镜像），“运行contrib/download-frozen-image.sh 制作镜像”这个动作出现在Dockerfile中，相当于在docker build所创建的临时的容器中下载docker镜像，有docker-in-docker容器嵌套的概念。下一小节会对download-frozen-image.sh脚本做详细分析。
ENTRYPOINT ["hack/dind"] 做出来的镜像，使用它启动的容器可以自动运行源码目录中的hack/dind脚本。 dind这个脚本是a wrapper script which allows docker to be run inside a docker container 。后面的小节会对hack/dind脚本做详细的分析。
COPY . /go/src/github.com/docker/docker 把物理机上的docker源码文件打入到镜像中
download-frozen-image.sh脚本
上一小节里提到，在Dockerfile中，有一步会调用contrib/download-frozen-image.sh ，它主要作用是下载3个镜像的tar包，供后续docker load。在Dockerfile中的调用方式如下：

download-frozen-image.sh脚本中会依次解析参数，其中/docker-frozen-images作为base dir，后面下载的东西全放到这里。之后的3个参数是镜像，里面包含了镜像名（例如busybox）、镜像tag（例如latest）、镜像id（例如），后面会在循环中依次下载这3个镜像的tar文件。
download-frozen-image.sh脚本中会通过curl从registry上获取如下信息：
token：获取token，后面curl获取的其他信息时都需要使用token。例如本例中 token='signature=,repository="library/busybox",access=read'
ancestryJson：把镜像相关联的历史层次的id也都获取到，因为每一层的tar都需要下载。本例中 ancestryJson='["", ""]'
这里可以看到这个镜像只有2层，两层的id这里都列了出来。 每个镜像包含的层数不同，例如。第三个镜像jess/unshare共有10层。
VERSION、json、tar: 每一层镜像id的目录下，都下载这3个文件，其中VERSION文件内容目前都是“1.0”，json文件是该层镜像的json文件，tar文件是该层镜像的真正内容，以.tar保存。
下载好的各层镜像目录结构如下：
$ls

$tree

hack/dind脚本
在Dockerfile中，ENTRYPOINT ["hack/dind"] ，表示在镜像启动后，运行该脚本，下面分析一下这个脚本的功能。
脚本在代码根目录下的hack目录中，作者对脚本的描述是 DinD: a wrapper script which allows docker to be run inside a docker container.
就是可以在docker容器中创建docker容器。它就做了一个事，那就是在容器中创建好cgroup目录，并把各个cgroup子系统mount上来。
为了方便理解，我们可以先看看物理机。在宿主机上如果创建docker容器，需要宿主机上必须事先mount cgroup子系统，因为cgroup是docker容器的一个依赖。同理docker-in-docker也要求外层的docker容器中有cgroup子系统，dind脚本在容器启动后，先去/proc/1/cgroup中获取cgroup子系统，然后依次使用mount命令，将cgroup mount上来，例如mount -n -t cgroup -o "cpuset" cgroup "/cgroup/cpuset"
最终在运行make build后，会制作出一个叫docker-dev的镜像。
make binary
执行make binary 就可以编译出docker二进制文件。编译出来的二进制文件在源码目录下的bundles/1.10.0-dev/binary/docker-1.10.0-dev ，其中还包含md5和sha256文件。

Makefile中的binary
Makefile中关于make binary流程是

先执行build，即上一节介绍的，制作docker-dev编译环境镜像。
再执行DOCKER_RUN_DOCKER，创建容器，DOCKER_RUN_DOCKER就是执行docker run，使用docker-dev镜像启动容器，并且会mount -v 将容器生成二进制文件的路径与宿主机共享。DOCKER_RUN_DOCKER在“编译前分析”一章中有介绍。启动的容器运行的命令行是 hack/make.sh binary 。docker run完整的形式如下：
docker run --rm -i --privileged -e BUILDFLAGS -e DOCKER_CLIENTONLY -e DOCKER_DEBUG -e DOCKER_EXECDRIVER -e DOCKER_EXPERIMENTAL -e DOCKER_REMAP_ROOT -e DOCKER_GRAPHDRIVER -e DOCKER_STORAGE_OPTS -e DOCKER_USERLANDPROXY -e TESTDIRS -e TESTFLAGS -e TIMEOUT -v "/home/mu/src/docker/docker/bundles:/go/src/github.com/docker/docker/bundles" -t "docker-dev:master" hack/make.sh binary
hack/make.sh脚本
上一节提到的make binary中创建的容器启动命令是hack/make.sh binary，运行容器中的（docker源码目录下的）hack/make.sh脚本，参数为binary。
make.sh中根据传入的参数组装后续编译用的flags（BUILDFLAGS），最后根据传入的参数依次调用 hack/make/目录下对应的脚本。例如我们的操作中传入的参数只有一个binary。那么在make.sh的最后，会调用hack/make/binary脚本。
hack/make/binary脚本中，就是直接调用go build进行编译了，其中会使用BUILDFLAGS LDFLAGS LDFLAGS_STATIC_DOCKER等编译选项。
如果最终生成的docker二进制文件不在bundles/1.10.0-dev/binary/目录下，那么可能是编译参数BINDDIR设置的不正确，可以在执行make binary时增加BINDDIR参数，例如
make BINDDIR=. binary , 将BINDDIR设置为当前目录。
总结
编译步骤总结：
1、编译前在物理机上安装好make、git，并下载好docker代码。下载好ubuntu:14.04镜像
2、执行make build 。这步执行完会在物理机上创建出一个docker-dev的镜像。
3、执行make binary 。 这步会使用docker-dev镜像启动一个容器，在容器中编译docker代码。编译完成后在物理机上直接可以看到二进制文件。默认二进制文件在 bundles/1.10.0-dev/binary/目录下
4、docker代码里有很多test，可以使用此套编译环境执行test，例如 make test 。 更多参数可以看Makefile
搭建环境心得：
1、在make build时，使用Dockerfile创建制作镜像，这个镜像有40多层，其中一层失败就会导致整个build过程失败。由于Dockerfile中很多步骤是要连到国外的网站去下载东西，很容易失败。好在docker build有cache机制，如果前面的层成功了，下次重新build时会使用cache跳过，节省了很多时间。所以如果make build中途失败（一般是由于国内连国外的网络原因），只要重新执行make build就会在上次失败的地方继续，多试几次可以成功。
2、如果其他人已经build出了docker-dev镜像，可以把它下载到自己的环境上。这样在自己make build时，会跳过那些已经在本地存在的层，可以节省时间。
3、每一次编译会自动删除掉前面已经生成的二进制文件，所以不用担心二进制文件不是最新的问题。

⑩ 如何查看 Docker 新版本中容器的名字空间

熟悉 Linux 技术的人都知道，容器只是利用名字空间进行隔离的进程而已，Docker 在容器实现上也是利用了 Linux 自身的技术。
有时候，我们需要在宿主机上对容器内进行一些操作，当然，这种绕过 Docker 的操作方式并不推荐。
如果你使用的是比较新的 Docker 版本，会尴尬的发现，直接使用系统命令，会无法访问到容器名字空间。
这里，首先介绍下“ ip netns” 系列命令。这些命令负责操作系统中的网络名字空间。
首先，我们使用 “add” 命令创建一个临时的网络名字空间。
ip netns add test

然后，使用 show 命令来查看系统中的网络名字空间，会看到刚创建的 test 名字空间。
ip netns show test

另外，一个很有用的命令是 exec，会在对应名字空间内执行命令。例如
ip netns exec test ifconfig

使用 del 命令删除刚创建的 test 名字空间。
ip netns del test

接下来运行一个 Docker 容器，例如
docker run -it ubuntu

再次执行 ip netns show命令。很遗憾，这里什么输出都没有。
原因在于，Docker 启动容器后仍然会以进程号创建新的名字空间，但在较新的版本里面，默认删除了系统中的名字空间信息文件。
网络名字空间文件位于 /var/run/netns 下面，比如我们之前创建的 test 名字空间，则在这个目录下有一个 test 文件。诸如 netns 类似的系统命令依靠这些文件才能获得名字空间的信息。
在容器启动后，查看这个目录，会发现什么都没有。
OK，那让我们手动重建它。
首先，使用下面的命令查看容器进程信息，比如这里的1234。
docker inspect --format='{{. State.Pid}} ' container_id 1234

接下来，在 /proc 目录（保存进程的所有相关信息）下，把对应的网络名字空间文件链接到 /var/run/netns 下面
ln -s /proc/1234/ns/net /var/run/netns/

然后，就可以通过正常的系统命令来查看或访问容器的名字空间了。例如
ip netns show 1234 ip netns exec 1234 ifconfig eth0 172.16.0.10/16...