1、检查linux 内核版本
uname -r 须大于3.0
2、安装依赖软件
yum install -y yum-utils
device-mapper-persistent-data lvm2
3、添加docker-ce阿里源
yum-config-manager --add-repo
4、更新yum缓存
yum makecache fast
5、安装docker-ce
yum -y install docker-ce
6、启动docker服务
systemctl start docker
7、查看docker信息
docker info
8、配置国内镜像源

9、一般启动程序
war包——》tomcat——》jdk——》环境变量——》os

docker把中间的三个都放到操作系统，直接用简单好用
常见名词
仓库：
存放模板的，分为公共仓库（dockerhub）和私有仓库

镜像：
只读模板

运行容器时，它使用隔离的文件系统。此自定义文件系统由容器映像提供。由于镜像包含容器的文件系统，它必须包含运行应用程序所需的一切——所有依赖项、配置、脚本、二进制文件等。镜像还包含容器的其他配置，例如环境变量、要运行的默认命令、和其他元数据。

容器：
实际使用的，如果说镜像是一个class，容器就是实例化对象obj

简单地说，容器只是你机器上的另一个进程，它与主机上的所有其他进程隔离开来

端口映射：把容器的端口转到宿主机的端口
10、常见
docker images :查看本地镜像

docker pull mysql:5.6：从仓库下载镜像到本地，
docker pull 镜像名字：tag

docker run ： docker运行容器
docker run -d -p 5306:3306 -e MYSQLOOT_PASSWORD=123456 mysql:5.6
-d 后台运行
-p 端口映射 宿主机端口：容器端口
-name 自定义名字
-v 文件挂载 宿主机目录:容器目录， 作用：让宿主机目录和容器目录指向硬盘同一地址

docker ps ：查看正在运行的容器

docker stop 停止正在运行的容器

进入到正在运行的容器
docker exec -it 容器id bash

11、场景2：
搭建一个tomcat容器，并运行war包
1、仓库中查找tomcat镜像
2、下载镜像到本地
3、通过镜像启动容器
最后一项是镜像
docker run -d -p 8082:8080 -v /root/webapps: --name tomcat01 tomcat:8.5

docker run --name bahasa -v $(pwd):/src/simple/app -e SIMPLE_ENV="test" -p 8000:8000 -d harbor.ppdaicorp.com/chatbot/bahasa:v1.0

12、查看本地镜像
docker images

初出茅庐：

image.png

PaaS 之所以能够帮助用户大规模部署应用到集群里，是因为它提供了一套应用打包的功能。可偏偏就是这个打包功能，却成了 PaaS 日后不断遭到用户诟病的一个“软肋”。

一旦用上了 PaaS，用户就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错

Docker 镜像解决的，恰恰就是打包这个根本性的问题。 所谓 Docker 镜像，其实就是一个压缩包。但是这个压缩包里的内容，比 PaaS 的应用可执行文件 + 启停脚本的组合就要丰富多了。实际上，大多数 Docker 镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的.

这就有意思了：假设你的应用在本地运行时，能看见的环境是 CentOS 7.2 操作系统的所有文件和目录，那么只要用 CentOS 7.2 的 ISO 做一个压缩包，再把你的应用可执行文件也压缩进去，那么无论在哪里解压这个压缩包，都可以得到与你本地测试时一样的环境。当然，你的应用也在里面！

更重要的是，这个压缩包包含了完整的操作系统文件和目录，也就是包含了这个应用运行所需要的所有依赖，所以你可以先用这个压缩包在本地进行开发和测试，完成之后，再把这个压缩包上传到云端运行。在这个过程中，你完全不需要进行任何配置或者修改，因为这个压缩包赋予了你一种极其宝贵的能力：本地环境和云端环境的高度一致！

这，正是 Docker 镜像的精髓。

那么，有了 Docker 镜像这个利器，PaaS 里最核心的打包系统一下子就没了用武之地，最让用户抓狂的打包过程也随之消失了。相比之下，在当今的互联网里，Docker 镜像需要的操作系统文件和目录，可谓唾手可得。

所以，你只需要提供一个下载好的操作系统文件与目录，然后使用它制作一个压缩包即可，这个命令就是：

docker build "我的镜像"

一旦镜像制作完成，用户就可以让 Docker 创建一个“沙盒”来解压这个镜像，然后在“沙盒”中运行自己的应用，这个命令就是：

docker run "我的镜像"\

所以，Docker 项目给 PaaS 世界带来的“降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。

而对于开发者们来说，在终于体验到了生产力解放所带来的痛快之后，他们自然选择了用脚投票，直接宣告了 PaaS 时代的结束。不过，Docker 项目固然解决了应用打包的难题，但正如前面所介绍的那样，它并不能代替 PaaS 完成大规模部署应用的职责。

崭露头角：

而 Docker 项目之所以能取得如此高的关注，
一方面正如前面我所说的那样，它解决了应用打包和发布这一困扰运维人员多年的技术难题；
而另一方面，就是因为它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了最广大的开发者群体手里

开发者：关注应用的开发与应用的运行情况；运维：关注容器的管理与维护，如：配置镜像；统一管理、分发；上线时直接部署验收完毕的镜像；测试人员：专注测试工作，不再因为环境差异而浪费时间

解决了应用打包这个根本性的问题，同开发者与生俱来的的亲密关系，再加上 PaaS 概念已经深入人心的完美契机，成为 Docker 这个技术上看似平淡无奇的项目一举走红的重要原因。

今天，我着重介绍了 Docker 项目在短时间内迅速崛起的三个重要原因：
1、Docker 镜像通过技术手段解决了 PaaS 的根本性问题；（Paas根本性问题是什么？如何给应用打包）
2、Docker 容器同开发者之间有着与生俱来的密切关系；（开发者只需要关注开发应用）
3、PaaS 概念已经深入人心的完美契机。（已教育的市场才能让同类项目快速崛起）

群雄并起：

用户们最终要部署的，还是他们的网站、服务、数据库，甚至是云计算业务。这就意味着，只有那些能够为用户提供平台层能力的工具，才会真正成为开发者们关心和愿意付费的产品。而 Docker 项目这样一个只能用来创建和启停容器的小工具，最终只能充当这些平台项目的“幕后英雄”。

（Docker是用来打包和启动、停止容器（应用）的，本质上和上一代PAAS的写打包脚本和起停脚本部署应用没有不同，只是做得更简单了。然后他们欠的债，比如应用启动后，相互之间的通信，存储的共享，权限问题等，这些问题仍没有解决。这是Docker公司需要继续解决的问题。）

我分享了 Docker 公司平台化战略的来龙去脉，阐述了 Docker Swarm 项目发布的意义和它背后的设计思想，介绍了 Fig（后来的 Compose）项目如何成为了继 Docker 之后最受瞩目的新星。同时，我也和你一起回顾了 2014~2015 年间如火如荼的容器化浪潮里群雄并起的繁荣姿态。在这次生态大爆发中，Docker 公司和 Mesosphere 公司，依托自身优势率先占据了有利位置。