docker菜鸟教程是什么？

docker菜鸟教程是什么？

Doc

Docker镜像操作常用指令有哪些？

docker version：查看docker版本;docker info：查看docker详细信息;docker –help：查看docker命令;镜像命令docker images：列出本地主机上的镜像，REPOSITORY：表示镜像的仓库源;TAG：镜像的标签;IMAGE ID：镜像ID;CREATED：镜像创建时间;SIZE ：镜像大小，同一个仓库源可以有多个TAG，可以表示仓库源的不同版本，使用REPOSITORY：TAG来定义不同的镜像;docker images -a：列出本地所有的镜像;docker images -p：只显示镜像ID;docker images –digests：显示镜像的摘要信息;docker images –no-trunc：显示完整的镜像信息;docker search tomcat：从Docker Hub上查找tomcat镜像;容器命令docker run [OPTIONS] IMAGE：根据镜像新建并启动容器，IMAGE是镜像ID或镜像名称;docker ps：列出当前所有正在运行的容器;exit：退出并停止容器;docker start 容器ID或容器名称：启动容器;docker restart 容器ID或容器名称：重新启动容器;docker stop 容器ID或容器名称：停止容器;docker kill 容器ID或容器名称：强制停止容器;docker rm 容器ID或容器名称：删除容器;docker rm -f $(docker ps -a -q)：删除多个容器。

Docker自学教程

Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上, 基于go语言并遵从Apache2.0协议开源。Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。

一个完整的Docker有以下几个部分组成：Docker核心解决的问题是利用LXC来实现类似VM的功能，从而利用更加节省的硬件资源提供给用户更多的计算资源。

同VM的方式不同, LXC 其并不是一套硬件虚拟化方法 – 无法归属到全虚拟化、部分虚拟化和半虚拟化中的任意一个，而是一个操作系统级虚拟化方法, 理解起来可能并不像VM那样直观。所以我们从虚拟化到docker要解决的问题出发，看看他是怎么满足用户虚拟化需求的。 用户需要考虑虚拟化方法，尤其是硬件虚拟化方法，需要借助其解决的主要是以下4个问题： Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。

容器与镜像的关系类似于面向对象编程中的对象与类形 Docker面向对象容器对象镜像类Docker采用 C/S架构 Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。 客户端和服务端既可以运行在一个机器上，也可通过 socket 或者RESTful API 来进行通信。 Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。

Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。 Docker 特性 在docker的网站上提到了docker的典型场景： 由于其基于LXC的轻量级虚拟化的特点，docker相比KVM之类最明显的特点就是启动快，资源占用小。因此对于构建隔离的标准化的运行环境，轻量级的PaaS(如dokku), 构建自动化测试和持续集成环境，以及一切可以横向扩展的应用(尤其是需要快速启停来应对峰谷的web应用)。

Docker并不是全能的，设计之初也不是KVM之类虚拟化手段的替代品，简单总结几点： 针对1-2，有windows base应用的需求的基本可以pass了; 3-5主要是看用户的需求，到底是需要一个container还是一个VM, 同时也决定了docker作为 IaaS 不太可行。 针对6,7虽然是docker本身不支持的功能，但是可以通过其他手段解决(disk quota, mount –bind)。总之，选用container还是vm, 就是在隔离性和资源复用性上做权衡。

另外即便docker 0.7能够支持非AUFS的文件系统，但是由于其功能还不稳定，商业应用或许会存在问题，而AUFS的稳定版需要kernel 3.8, 所以如果想复制dotcloud的成功案例，可能需要考虑升级kernel或者换用ubuntu的server版本(后者提供deb更新)。这也是为什么开源界更倾向于支持ubuntu的原因(kernel版本)Docker并非适合所有应用场景，Docker只能虚拟基于Linux的服务。Windows Azure 服务能够运行Docker实例，但到目前为止Windows服务还不能被虚拟化。 可能最大的障碍在于管理实例之间的交互。

由于所有应用组件被拆分到不同的容器中，所有的服务器需要以一致的方式彼此通信。这意味着任何人如果选择复杂的基础设施，那么必须掌握应用编程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets以确保机器按照预期运转并支持故障切换。 Docker在本质上是一个附加系统。使用文件系统的不同层构建一个应用是有可能的。

每个组件被添加到之前已经创建的组件之上，可以比作为一个文件系统更明智。分层架构带来另一方面的效率提升，当你重建存在变化的Docker镜像时，不需要重建整个Docker镜像，只需要重建变化的部分。 可能更为重要的是，Docker旨在用于弹性计算。每个Docker实例的运营生命周期有限，实例数量根据需求增减。

在一个管理适度的系统中，这些实例生而平等，不再需要时便各自消亡了。 针对Docker环境存在的不足，意味着在开始部署Docker前需要考虑如下几个问题。首先，Docker实例是无状态的。

这意味着它们不应该承载任何交易数据，所有数据应该保存在数据库服务器中。 其次，开发Docker实例并不像创建一台虚拟机、添加应用然后克隆那样简单。为成功创建并使用Docker基础设施，管理员需要对系统管理的各个方面有一个全面的理解，包括Linux管理、编排及配置工具比如Puppet、Chef以及Salt。

这些工具生来就基于命令行以及脚本。

云计算核心技术Docker教程：Docker存储写入时复制（CoW）策略

【点击右上角加’关注’，全国产经信息不错过】 写时复制是一种共享和复制文件的策略，可最大程度地提高效率。如果文件或目录位于映像的较低层中，而另一层（包括可写层）需要对其进行读取访问，则它仅使用现有文件。

另一层第一次需要修改文件时（在构建映像或运行容器时），将文件复制到该层并进行修改。

这样可以将I / O和每个后续层的大小最小化。这些优点将在下面更深入地说明。 共享可以提升较小的图像 当您用于docker pull从存储库中下拉映像时，或者当您从本地尚不存在的映像中创建容器时，每个层都会被分别下拉，并存储在Docker的本地存储区域中，该区域通常/var/lib/docker/在Linux主机上。在此示例中，您可以看到这些层被拉出： $ docker pull ubuntu:18.04 18.04: Pulling from library/ubuntu f476d66f5408: Pull complete 8882c27f669e: Pull complete d9af21273955: Pull complete f5029279ec12: Pull complete Digest: sha256:ab6cb8de3ad7bb33e2534677f865008535427390b117d7939193f8d1a6613e34 Status: Downloaded newer image for ubuntu:18.04 这些层中的每一层都存储在Docker主机的本地存储区域内的自己的目录中。

要检查文件系统上的各层，请列出的内容/var/lib/docker/。本示例使用overlay2 存储驱动程序： $ ls /var/lib/docker/overlay2 16802227a96c24dcbeab5b37821e2b67a9f921749cd9a2e386d5a6d5bc6fc6d3 377d73dbb466e0bc7c9ee23166771b35ebdbe02ef17753d79fd3571d4ce659d7 3f02d96212b03e3383160d31d7c6aeca750d2d8a1879965b89fe8146594c453d ec1ec45792908e90484f7e629330666e7eee599f08729c93890a7205a6ba35f5 l 目录名称与层ID不对应（自Docker 1.10开始就是如此）。 现在，假设您有两个不同的Dockerfile。

您使用第一个创建名为的图像acme/my-base-image:1.0。 # syntax=docker/dockerfile:1 FROM ubuntu:18.04 COPY . /app 第二acme/my-base-image:1.0层基于，但具有一些附加层： # syntax=docker/dockerfile:1 FROM acme/my-base-image:1.0 CMD /app/hello.sh 第二个图像包含第一个图像的所有层，再加上带有CMD指令的新层，以及一个可读写容器层。Docker已经具有第一个映像中的所有层，因此不需要再次将其拉出。

这两个图像共享它们共有的任何图层。 如果从两个Dockerfile构建映像，则可以使用docker image ls和 docker history命令来验证共享层的密码ID是否相同。 1.创建一个新目录cow-test/并更改到该目录中。

2.在中cow-test/，创建一个hello.sh具有以下内容的新文件： #!/bin/sh echo “Hello world” 保存文件，并使其可执行： chmod +x hello.sh 3.将上面第一个Dockerfile的内容复制到一个名为的新文件中 Dockerfile.base。 4.将上面第二个Dockerfile的内容复制到一个名为的新文件中 Dockerfile。 5.在cow-test/目录中，构建第一个映像。不要忘记.在命令中包含final 。

设置了PATH，它告诉Docker在哪里寻找需要添加到映像中的任何文件。 $docker build -t acme/my-base-image:1.0 -f Dockerfile.base . 6.建立第二张镜像。 $docker build -t acme/my-final-image:1.0 -f Dockerfile . 7.检查镜像的大小： $docker image ls 8.检出构成每个镜像的图层： $docker history bd09118bcef6 请注意，除了第二个图像的顶层以外，所有层都是相同的。所有其他层在两个图像之间共享，并且仅在中存储一次/var/lib/docker/。

实际上，新层根本不占用任何空间，因为它不更改任何文件，而仅运行命令。