Docker

title: 基础架构.
content: 专业名词Docker有两个意思:
title: Docker引擎.
content: Docker引擎(Docker Engine)是一个服务端-客户端结构的应用,主要有这些部分:Docker守护进程、Docker Engine AP、Docker客户端。
title: Docker注册中心.
content: Docker注册中心(Docker registry)是用于存储Docker的镜像。Docker Hub 是一个公共的注册中心,任何人都可以使用,默认配置下,Docker将会在这里寻找镜像。  另外,用户可以自行构建私有注册中心。Docker Datacenter (DDC)的用户,可以直接使用 Docker Trusted Registry (DTR)。
title: 对象.
content: Docker的对象是指Images、Containers、Networks、Volumes、Plugins等等。
title: 扩展架构.
title: Docker Compose.
content: Compose可译为组合物。Compose 是用于定义和运行 多个容器Docker应用程序 的工具。通过Compose,你可以使用YAML文件来配置应用程序需要的所有服务,然后通过使用一个命令,就可以创建并启动所有服务。Compose对应的命令为codice_5。
title: Swarm Mode.
content: 当说到 Docker Swarm 时,一般是指单独项目 Docker Swarm。而在Docker 1.12时,将swarm mode集成到Docker 引擎中,可用Docker引擎API 和 CLI 命令直接使用。官方推荐用户使用集成的 swarm mode 。  Swarm Mode 内置 kv 存储功能,提供了众多的新特性,比如:具有容错能力的去中心化设计、内置服务发现、负载均衡、路由网格、动态伸缩、滚动更新、安全传输等。使得 Docker 原生的 codice_6 集群具备与 Mesos、Kubernetes 竞争的实力。  cluster(中文:集群),Docker将集群定义为:一群共同作业并提供高可用性的机器 。swarm(中文:群),是指一个集群的Docker引擎以swarm mode形式运行。swarm mode是指Docker引擎内嵌的集群管理和编排功能。当你初始化了一个swarm(cluster)或者将节点加入一个swarm时,其Docker引擎就会以swarm mode的形式运行。
title: 原理.
content: swarm中的Docker机器中分为 managers(管理者) 和 workers(员工),管理者用于处理集群的关系和委派,员工则用于执行 swarm服务。 当你创建swarm服务时,你可以为其增加各种额外的状态(如:数量、网络、端口、存储资源等等)。Docker会去维持用户想要的状态。如:一个工作节点如果挂了,那么Docker会去把这个节点的任务给另外一个节点。此处的任务(task)是指:被swarm管理者管理的一个运行中的容器。  swarm服务比单独容器好在,修改swarm服务的配置之后不用重启。同时,Docker以swarm mode形式运行时,也可以选择直接启动单独的容器。另外,swarm mode下,你也可以通过 codice_7 使用 Compose file 部署应用栈。 swarm服务分为两种,一种是replicated services,可以指定节点任务的总数量;global services,则是每个节点都会运行一个指定任务。 swarm管理员使用 ingress 负载均衡使服务可被外部接触。 swarm管理员会自动地给服务分配PublishedPort(或者手动配置)。外部组件,如云负载均衡器能通过集群中任何节点上的PublishedPort去接入服务(不管该服务是否启动)。另外 swarm mode有内部DNS组件,它会为每个服务分配一个DNS条目。swarm管理员使用 internal load balancing 去分发请求时,就是依靠这个DNS组件。  swarm mode的功能是由swarmkit(一个独立项目)提供的,它实现了Docker的编排层。swarm可以直接被Docker使用。
title: 文件格式.
content: Docker有两种文件格式,Dockerfile和Compose file。Dockerfile定义了单个容器的内容和启动时候的行为。Compose file定义了一个多容器应用。
title: Dockerfile.
content: Docker 可以依照 Dockerfile 的内容,自动化地构建镜像。 Dockerfile 是包含着用户想要如何构建镜像的所有命令的文本。 FROM ubuntu:18.04 COPY. /app RUN make /app CMD python /app/app.py 关键词:
title: Compose文件.
content: Compose文件 是一个YAML文件,定义了服务(service)、网络、卷(volume)。  codice_23 命令中有一些选项,和 Dockerfile文件中的指令效果一样(如:codice_15, codice_28, codice_29, codice_30),如果Dockerfile文件中使用这些指令,那么这些指令就会被视为默认参数,所以开发者无需特意在 Compose文件中再指定一次。  Compose文件 可使用 Shell变量(Variable),如: db: Compose文件 可通过自身的codice_31变量,将参数传给Dockerfile的 codice_31 指令。
title: 网络.
content: 参考文档:Docker文档-网络概要
title: bridge.
content: 在Docker里,网桥网络 使用的是 软件形式的网桥。使用相同的网桥的容器连接进入该网络,而非该网络的容器刷故无法接入。Docker网桥驱动会自动地在Docker主机上安装规则,这些规则让不同桥接网络之间不能直接通信。 桥接经常用于:在单独容器上运行应用时,可通过 网桥 进行通信。 网桥网络 适用于容器运行在相同地Docker守护进程的主机上。不同Docker守护进程主机上的容器,它们之间的通信需要依靠操作系统层次的路由,或者你应该使用 overlay网络 进行代替。  codice_33 是网桥驱动,是Docker默认的网络驱动(接口名为 codice_34),当你不为容器指定一个网络时候,Docker将会使用该驱动。 可通过 codice_35 文件修改相关配置。  自定义网桥可通过 codice_36 命令进行配置。
title: host.
content: 主机模式  codice_37 用于单独容器,该网络下容器只能和Docker主机进行直接连接。codice_37 只适用于 Docker 17.06或以上版本的swarm服务。  host网络和VirtualBox的 仅主机网络(Host-only Networking) 类似。
title: overlay.
content: codice_39 (中文:覆盖网络)网络驱动将会创建分布式网络,该网络可以覆盖若干个 Docker守护进程主机。该网络是基于 主机特定网络(host-specific networks),允许 swarm服务 和 容器 进行安全通信(当加密功能开启时)。在该网络下,Docker能够清晰地掌握 数据包的路由 以及 发送接收容器。  codice_39 有两种网络类型网络:  在 codice_39 网络下,单独的容器 和 swarm服务 的行为和配置概念 是不一样。  该策略不需要 容器们 具有操作系统级别的路由,因为Docker负责路由。
title: macvlan.
content: codice_45 网络允许你赋予容器 MAC地址,在该网络里,容器会被认为是物理设备。Docker守护进程会路由
title: none.
content: 该策略下,容器不使用任何网络。codice_46 常常用于连接自定义网络驱动的情况下。
title: 其他.
content: 其他第三方插件。
title: 数据管理.
content: Docker默认下,所有文件将会存储在容器里的可写的容器层(container layer)。  容器有两种永久化存储方式:卷(volumes)和 绑定挂载(bind mounts)。另外,Linux用户还可使用 tmpfs 进行挂载;window用户还可以使用 命名管道(named pipe)。在容器中,不管是哪种永久化存储,表现形式都是一样的。
title: 卷.
content: 卷(volumes)是宿主机器的文件系统的一部分,由Docker进行管理( 在Linux,存储于codice_47)。非Docker程序不应该去修改这些文件。Docker推荐使用 卷 进行持久化数据。 卷 可支持 卷驱动(volume drivers),该驱动允许用户将数据存储到 远程主机 或 云服务商(cloud provider)或 其他。  没有名字的卷叫匿名卷(anonymous volume),有名字的卷叫命名卷(named volume)。匿名卷没有明确的名字,当被初始化时,会被赋予一个随机名字。
title: 绑定挂载.
content: 绑定挂载(bind mounts)通过将宿主机器的路径挂载到容器里的这种方式,从而数据持续化,因此绑定挂载可将数据存储在宿主机器的文件系统的任何地方。非Docker程序可修改这些文件。 绑定挂载是Docker早期就存在的,相比起卷,绑定挂载十分简单明了。 在开发Docker应用时,应使用命名卷(named volume)代替绑定挂载,因为用户不能对绑定挂载进行 Docker CLI 命令操作。  绑定挂载常用于:
title: tmpfs.
content: codice_49 挂载(tmpfs mounts),仅仅存储于内存中,并不操作 宿主机器的文件系统(不持久化于磁盘)。它可用于存储一些 非持久化状态、敏感数据。 举例,swarm服务 通过codice_49 将 secrets(密码、密钥、证书等)存储到swarm服务。
title: 命名管道.
content: 命名管道(named pipes),通过 codice_51 挂载的形式,使 Docker主机 和 容器 之间能互相通讯。常见用例是在容器内运行第三方工具,并使用命名管道连接到Docker Engine API。
title: 覆盖问题.
content: 当挂载 空的卷 至一个目录中,目录中的内容会被复制于卷中(不会覆盖)。如果挂载 非空的卷 或 绑定挂载 至一个目录中,那么该目录的内容将会被隐藏(obscured ),当卸载后内容将会恢复显示。
title: 日志.
content: 在Linux和UNIX中,常见的 I/O流() 分为三种:codice_52(输入 )、 codice_53(正常输出)、codice_54(错误输出)。  默认配置下,Docker的日志(如:codice_55、codice_56)所记载的是命令行的输出结果(codice_53和codice_54)。而codice_53 和 codice_54 对应的文件路径分别是 codice_61和codice_62。 另外,也可以在宿主主机上查看容器的日志,使用以下命令可以查看到容器的日志位置。 $ docker inspect --format=" $INSTANCE_ID
title: 历史.
content: Docker命令在过去的发展中诞生了40种以上的命令,过多的命令导致混论以及难以使用tab自动补充,因此在docker 1.13版本(2017.1.19)中,命令行被重构,根据逻辑对象进行划分。官方建议用户使用新的语法进行操作。
title: 已过时.
title: Docker Swarm.
content: 参考Swarm Mode章节。
title: Docker Machine.
content: Docker Machine 是一个工具,它允许你在虚拟宿主机上安装 Docker引擎,并使用 docker-machine 命令管理这些宿主机。你可以使用 Machine 在你本地的 Mac 或 Windows box、公司网络、数据中心、或像 AWS 或 Digital Ocean 这样的云提供商上创建 Docker 宿主机。  Docker Machine 最后更新时间是在0.16.0 (2018-11-08)版本。官方建议在1.12以及之后版本使用Docker Desktop for Mac和Docker Desktop for Windows进行代替。
title: Docker Toolbox.
content: Docker Toolbox是用于帮 Windows系统和Mac系统 安装Docker环境。新版本建议使用Docker Desktop for Mac和Docker Desktop for Windows进行安装。最后更新版本是 19.03.1(2019-08-01)。

Summary: Docker 是一个开放源代码软件,是一个开放平台,用于开发应用、交付(shipping)应用、运行应用。 Docker允许用户将基础设施(Infrastructure)中的应用单独分割出来,形成更小的颗粒(容器),从而提高交付软件的速度。

Docker (software): Docker is a set of platform as a service (PaaS) products that uses OS-level virtualization to deliver software in packages called containers. Containers are isolated from one another and bundle their own software, libraries and configuration files; they can communicate with each other through well-defined channels. All containers are run by a single operating system kernel and therefore use fewer resources than virtual machines.