关于Docker
Docker 简介
Docker现在是Github社区最火的项目之一，Docker是个容器，或许你听过lxc，你可能知道Tomcat这个Web容器，容器是什么概念，意会就好。问个问题，你想在一台机子上运行一个java6的应用，又想运行一个java8应用怎么办；或者说你开发出一个软件，mac版、windows版本，我都想运行，怎么办？装虚拟机？不不不，虚拟机太浪费资源了，Docker这时候就派上用场了，在电脑上，你可以同时装一个mac的容器和windows的容器哦。一个虚拟机可能会消耗2到3G的内存，一个容器仅仅只消耗几百M的资源哦。
Docker 安装
具体安装细节，可以参照https://docs.docker.com，文档说得很清楚了。 Docker原本是开发在Linux上的，Windows下是采用Docker machine的方式，起一个虚拟机在虚拟机里面跑Docker。本来呢Mac也是采用虚拟机的方式，后来有了Docker for mac，采用HyperKit，一种更轻量级的虚拟化方式。当然，你还是可以用Docker machine的方式运行。
Docker 基础
搞清楚两个概念，容器与镜像。打个比方吧。装机，容器就是装完成后的系统，镜像就是ISO安装盘，系统镜像。
作为一个合格的程序员，你一定用过Git的吧，pull，commit，push……写代码过程就是这样，先拉取代码pull，然后是在一个基础的文本上不断地增加commit，加积木一样，一层层叠加，累积上去，最后再push上去。没错Docker就是采用这种形式。
简单介绍下Docker命令：
-
Docker version / Docker info 查看基本信息，遇到使用问题或者BUG，可以到社区里报告，记得带着这些信息哈。
-
Docker pull 拉取镜像。
-
Docker run 从镜像创建一个容器并运行指定的命令常用参数-i -d，建议用—-name命名这个容器，命名后可以使用容器名访问这个容器。
-
Docker attach（不推荐使用）。
-
Docker exec -ti CONTAINER /bin/bash 连接到容器上运行bash
-
Docker logs CONTAINER 查看日志，如run命令后的运行结果，Docker logs -f 查看实时的日志。
-
Docker kill 杀死Docker容器进程，你可以使用Docker kill $(Docker ps -aq)杀死所有的Docker进程，后者打印出所有的容器的容器id（包括正在运行的，和没有运行的）。
-
Docker rm CONTAINER 删除一个容器，记得要先停止正在运行的容器，再去删除它。
-
Docker exec -it <container_id> bash -c 'cat > /path/to/container/file' < /path/to/host/file/容器外向容器内复制文件（也可以用挂载的形式哦）。
-
Docker commit -a “mike” -m “镜像的一些改动” CONTAINER 当你在容器内做了某种操作后，如增加了一个文件，你可以用这个命令把修改提交，重新打包为镜像。
-
Docker push 推送镜像。。到这里是不是觉得跟Git的模式已经有点像了呢。
-
Docker history IMAGES 查看镜像的修改历史。
-
Docker ps -a | grep "Exited" | awk '{print $1 }'| xargs Docker rm 删除exited的容器。
-
Docker rmi $(Docker images | awk '/^<none>/ {print $3}') 删除tag为NONE的容器。
Dockerfile基础
Dokcerfile，是的，你还是要稍微掌握下Dockerfile的写法。
-
From 每个Dockerfile镜像的构建都会基于一个基础镜像，这是你一来的基础镜像name:tag，git。
-
MAINTAINER （不用记，作者签名）。
-
ENV 配置环境变量。
-
COPY 复制本地。
-
EXPOSE 暴露容器的端口。
-
WORKDIR 后续命令的执行路径。
-
RUN important！，执行相应的命令，这一步是在容器构建这一步中执行的命令，一般用作安装软件，操作的结果是持久化在容器里面保存下来的。
Tips：每次执行RUN的时候都是再默认路径执行的，如果要到固定路径下执行命令请在之前加WORKDIR，或者使用RUN (cd workpath && echo "mike")这样把cd命令跟相应的执行命令用括号括起来。
-
ENTRYPOINT 容器启动后执行的命令。
我们把Jenkins和Docker结合起来。Jenkins本身版本比较老，虽然插件多，但许多插件没有人在维护更新，环境本身还是比较旧的，且各式各样的工程如果都用插件来安装，这样的插件不一定满足要求，所以建议配合Docker来搭建测试环境。
如果说好处的话，还有比较激进的一段话（建议略过哈）：
我们把一个工程代码开发后的测试流程简单分为编译、部署（事实上可能更多，如项目代码有多个工程，工程间有相互依赖）。如果我们想在一个slave节点上既运行Java7应用,又运行Java8应用，哦，Jenkins有相应的插件解决？那如果是NodeJs4应用和NodeJs5应用呢？JAVA升级到9了，插件没更新？像一些复杂的工程，如JDK自身的编译、如Docker项目的编译，我需要安装各种依赖，就可能会污染全局空间，这时候就建议把编译过程放到容器里，或者说我要在Linux上编译部署一个Windows应用，在一个Windows容器里部署就可以了。
再比如，如果我们用omad部署web应用可能要考虑端口冲突，部在Docker容器里，工程代码的端口，都不用变。还有，容器作测试环境的话，如果要保证线上，线下环境一致，甚至可以复制一个线下容器，直接在线上跑容器的。还有......
大致的想法是，我们用Jenkins来做节点控制、版本管理、流程设置、触发Job，用Docker来搭建编译部署环境。把这一切连接起来的就是流程脚本和Dockerfile的编写。
实现细节可以参照下面的示例。
触发条件：由Jenkins控制，如设置定时执行，或者github中的每一个commit，或者每一个PR执行一次。
构建流程：各个环节，Job，之间用Pipeline来实现整个构建流程的控制。
构建Job：这里，我觉得可以分为两种情况，一种是把拉取代码的过程和构建编译环境的过程都放到Dockfile里面，这适用于比较复杂的编译环境，如Docker本身的编译需要安装许多的依赖，对依赖的版本都有不同的要求，还是建议把编译环境放在容器的里面。另一种情况，为求省事方便，如java工程，编译一般用maven等构建工具来完成的话，大可以放在外面，只是把运行环境搬到Docker容器里。
Dockerfile：
配置基础运行环境。
如果需要编译，配置编译环境，可以在容器内拉取代码，执行编译。
web应用暴露端口。
配置应用启动命令。
另外，容器里你都可以配置成8080端口，暴露8080端口，只要再Docker run -p *:8080，运行时改下相应的端口映射就可以了。
原文：https://blog.csdn.net/jek123456/article/details/56677408