CentOS
$ sudo yum install yum-utils device-mapper-persistent-data lvm2 $ $ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo $ sudo yum install docker-ce $ $ sudo systemctl enable docker $ sudo systemctl start docker
Ubuntu
$ sudo apt-get install apt-transport-https ca-certificates curl software-properties-common $ $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" $ sudo apt-get update $ sudo apt-get install docker-ce $ $ sudo systemctl enable docker # 开机自启动 $ sudo systemctl start docker
在安装 Docker 完成之后，我们需要先启动 docker daemon 使其能够为我们提供 Docker 服务，这样我们才能正常使用 Docker。
在我们通过软件包的形式安装 Docker Engine 时，安装包已经为我们在 Linux 系统中注册了一个 Docker 服务，所以我们不需要直接启动 docker daemon 对应的 dockerd 这个程序，而是直接启动 Docker 服务即可。启动的 Docker 服务的命令其实我已经包含在了前面谈到的安装命令中，也就是
sudo systemctl start docker
查看版本号
sudo docker version
了解更多信息使用命令：sudo docker info
配置国内镜像源
修改/etc/docker/deemon.json (文件不存在就创建它)
{ "registry-mirrors": [ "https://registry.docker-cn.com" ] }
重启docker
service docker restart
验证是否成功
sudo docker info |grep Registry -C 3
WARNING: No swap limit support
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Registry Mirrors:
https://registry.docker-cn.com/ 这里ok
Live Restore Enabled: false
镜像与容器
可以将 Docker 镜像理解为包含应用程序以及其相关依赖的一个基础文件系统，在 Docker 容器启动的过程中，它以只读的方式被用于创建容器的运行环境。
Docker 镜像其实是由基于 UnionFS 文件系统的一组镜像层依次挂载而得，而每个镜像层包含的其实是对上一镜像层的修改，这些修改其实是发生在容器运行的过程中的。所以，我们也可以反过来理解，镜像是对容器运行环境进行持久化存储的结果。
镜像的实现：
Docker 的镜像我们必须通过 Docker 来打包，也必须通过 Docker 下载或导入后使用，不能单独直接恢复成容器中的文件系统。
对于每一个记录文件系统修改的镜像层来说，Docker 都会根据它们的信息生成了一个 Hash 码，这是一个 64 长度的字符串，足以保证全球唯一性。这种编码的形式在 Docker 很多地方都有体现。由于镜像层都有唯一的编码，我们就能够区分不同的镜像层并能保证它们的内容与编码是一致的，这带来了另一项好处，就是允许我们在镜像之间共享镜像层。
举一个实际的例子，由 Docker 官方提供的两个镜像 elasticsearch 镜像和 jenkins 镜像都是在 openjdk 镜像之上修改而得，那么在我们实际使用的时候，这两个镜像是可以共用 openjdk 镜像内部的镜像层的。
这带来的一项好处就是让镜像可以共用一些存储空间，达到 1 + 1 < 2 的效果，为我们在同一台机器里存放众多镜像提供了可能。
事实上，这个优势是更为明显的。一个虚拟机镜像的占用空间往往用 GB 来衡量，在同一台物理机上存放几个就已经是了不起的事情了。而 Docker 管理之下的镜像，占用空间是以 MB 为单位进行衡量的，加之镜像之间还能够共享部分的镜像层，也就是共享存储空间，所以我们在常见的硬盘里放下几十、数百个镜像也不是什么难事
查看镜像：
如果要查看当前连接的 docker daemon 中存放和管理了哪些镜像，我们可以使用 docker images 这个命令 ( Linux、macOS 还是 Windows 上都是一致的 )。
可以看到有镜像ID（IMGE ID）构建时间（CRETAED ），占用空间（SIZE）
为了避免屏幕的空间都被这些看似“乱码”的镜像 ID 所挤占，所以 Docker 只显示了镜像 ID 的前 12 个字符
镜像命名：
镜像层的 ID 既可以识别每个镜像层，也可以用来直接识别镜像 ( 因为根据最上层镜像能够找出所有依赖的下层镜像，所以最上层进行的镜像层 ID 就能表示镜像的 ID )，但是使用这种无意义的超长哈希码显然是违背人性的，所以这里我们还要介绍镜像的命名，通过镜像名我们能够更容易的识别镜像。
在 docker images 命令打印出的内容中，我们还能看到两个与镜像命名有关的数据：REPOSITORY 和 TAG，这两者其实就组成了 docker 对镜像的命名规则。
feisky/nginx
feisky是username
nginx是储藏名称
准确的来说，镜像的命名我们可以分成三个部分：username、repository 和 tag。
- username： 主要用于识别上传镜像的不同用户，与 GitHub 中的用户空间类似。
- repository：主要用于识别进行的内容，形成对镜像的表意描述。
- tag：主要用户表示镜像的版本，方便区分进行内容的不同细节
对于 username 来说，在上面我们展示的 docker images 结果中，有的镜像有 username 这个部分，而有的镜像是没有的。没有 username 这个部分的镜像，表示镜像是由 Docker 官方所维护和提供的，所以就不单独标记用户了。
镜像的标签是对同一种镜像进行更细层次区分的方法，也是最终识别镜像的关键部分。
通常来说，镜像的标签主要是为了区分同类镜像不同构建过程所产生的不同结果的。由于时间、空间等因素的不同，Docker 每次构建镜像的内容也就有所不同，具体体现就是镜像层以及它们的 ID 都会产生变化。而标签就是在镜像命名这个层面上区分这些镜像的方法。
与镜像的 repository 类似，镜像 tag 的命名方法也通常参考镜像所关联的应用程序。更确切的来说，我们通常会采用镜像内应用程序的版本号以及一些环境、构建方式等信息来作为镜像的 tag。
例如，我们之前示例的结果中就分别有包含 Redis 3.2 版本和 4.0 版本的两个镜像：redis:3.2 和 redis:4.0。
除了单纯使用应用程序版本来作为镜像的标签外，有时候我们也会在其中包含一些构建方式的区别。例如 php:7.2-cli 和 php:7.2-fpm 两个镜像分别表示只包含控制台命令的 PHP 镜像以及包含 PHP-FPM 功能的 PHP 镜像，而他们对应 PHP 版本都是 7.2。
通过组合应用程序和它的版本号来命名镜像，大大方便了我们在 Docker 区别和使用镜像的门槛，与其说我们在使用 Docker 进行来启动容器，这个过程倒更像我们在运行指定版本的应用程序。
另外，Docker 中还有一个约定，当我们在操作中没有具体给出镜像的 tag 时，Docker 会采用 latest作为缺省 tag。这也就带来了一个共识，也就是绝大多数镜像提供者在提供镜像时，会在 latest 对应的镜像中包含软件最新的版本。这带来了一项小便利，就是我们在不需要了解应用程序迭代周期的情况下，可以利用 latest 镜像保持软件最新版本的使用。