php仿百度网站源码,怎么建设一个淘宝客网站谁知道,响应式网站手机端,手机网站开发用什么0. 容器简介 从生活上来说#xff0c;容器是一种工具#xff0c;可以装东西的工具#xff0c;如衣柜、背包、行李箱等等。 从IT技术方面来说#xff0c;容器是一种全新的虚拟化技术#xff0c;它提高了硬件资源利用率#xff0c;结合k8s还可以让企业业务快速横向扩容、业…0. 容器简介 从生活上来说容器是一种工具可以装东西的工具如衣柜、背包、行李箱等等。 从IT技术方面来说容器是一种全新的虚拟化技术它提高了硬件资源利用率结合k8s还可以让企业业务快速横向扩容、业务宕机自愈 。 1. Docker简介
1.1 Docker是什么
官方简介文档CHANGELOG.mod Docker是一个在2013年开源的PAAS平台即服务级别的应用程序基于GO语言编写而成。 Docker是基于Linux内核实现的容器运行最早采用LXC技术Linux ContainerLXC是linux原生支持的容器技术可以提供轻量级的虚拟化。 2016年4月13日Docker版本为1.11.0时Dokcer使用自己研发并开源的runc容器技术。 1.2 Docker的特点 Docker相比虚拟机的交付速度更快资源消耗更低Docker采用客户端、服务端的架构使用远程API来管理和创建Docker容器可以创建一个轻量级的基础镜像体积小、可移植的有docker环境的都能run、自给自足根据不同需求内置的不同运行环境如java的容器。 Docker的三大理念是build构建镜像、ship分发镜像、run运行并遵从Apache·2.0协议并通过namespace和cgroup来提供容器的资源隔离和安全保障所以Docker容器在运行时不会有类似虚拟机空运行的虚拟机占用一定性能开销的额外开销因此可以大幅提高资源利用率。 1.3 Docker的组成
Docker官方文档https://docs.docker.com/get-started/overview/ Docker官方镜像仓库https://hub.docker.com/ Docker宿主机HOST一个物理机或虚拟机用于运行Docker服务进程和容器。 Docker服务端ServiceDocker守护进程运行docker容器。 Docker客户端Client客户端使用docker命令或其他工具调用docker API。 Docker仓库Registry保存镜像的仓库类似于git或者svn这种的版本控制工具。 Docker镜像Images镜像可以理解成创建实例使用的模板。 Docker容器Container容器是从镜像生成的对外提供服务的一个或一组服务。 1.3.1 重要组件 1docekrd 为客户端提供RESTful API响应来自客户端的请求采用模块化的架构通过专门的Engine模块来分发管理各个来自客户端的任务。可以单独升级 2docker-proxy 是dockerd的子进程当需要进行容器端口映射时docker-proxy完成网络映射配置 3containerd 是dockerd的子进程提供gRPC接口响应来自dockerd的请求对下管理runC镜像和容器环境。可以单独升级 4containerd-shim 是containerd的子进程为runC容器提供支持同时作为容器内进程的根进程。 5runC 是Docker引擎容器的创建运行销毁等等操作最终都将通过调用runC完成。 1.4 Docker对比虚拟机 资源利用率更高一台物理机可以运行数百个容器但是运行虚拟机的话一般只能运行数十个。 开销更小不需要启动单独的虚拟机占用硬件资源。 启动速度更快可以在数秒内完成启动。 1.4.1 Docker容器对和VM虚拟机的不同之处 如下图传统虚拟机技术是虚拟出一套硬件后在其上运行一个完整操作系统在该系统上再运行所需应用进程; 而容器内的应用进程直接运行于宿主的内核容器内没有自己的内核且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。 并且每个容器之间互相隔离每个容器有自己的文件系统容器之间进程不会相互影响能区分计算资源。 1.4.2 为什么docker容器比VM虚拟机更快 1因为docker不需要Hypervisor(虚拟机)实现硬件资源虚拟化,运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上docker将会在效率上有明显优势。 2当新建一个容器时,docker不需要和虚拟机一样重新加载一个操作系统内核。进而避免引寻、加载操作系统内核返回等比较费时费资源的过程,当新建一个虚拟机时,虚拟机软件需要加载OS,返回新建过程是分钟级别的。而docker由于直接利用宿主机的操作系统,则省略了返回过程,因此新建一个docker容器只需要几秒钟。 1.5 使用Docker面临的问题 如上图一个宿主机运行了多个容器多个容器带来的以下问题怎么解决 1怎样保证每个容器都有不同的文件系统并且能互不影响 2一个docker主进程内的各个容器都是其子进程那么同一个主进程下不同类型子进程如何实现资源隔离各个进程间通信能相互访问内存数据吗 3每个容器怎么解决IP及端口分配的问题 4多个容器的主机名能一样吗 5每个容器要不要有root用户怎么解决账户重名问题 1.6 Linux Namespace技术
简单来说Linux Namespace是Linux提供的一种内核级别环境隔离的方法。 官方文档https://lwn.net/Articles/531114/ Linux Namespace是Linux提供的一种内核级别环境隔离的方法。很早以前的Unix有一个叫chroot的系统调用通过修 改根目录把用户jail到一个特定目录下chroot提供了一种简单的隔离模式chroot内部的文件系统无法访问外部的内容。 Linux Namespace在此基础上提供了对UTS、IPC、mount、PID、network、User等的隔离机制。 举个例子我们都知道Linux下的超级父亲进程的PID是1所以同chroot一样如果我们可以把用户的进程空间jail到某个进程分支下 并像chroot那样让其下面的进程 看到的那个超级父进程的PID为1于是就可以达到资源隔离的效果了不同的PID namespace中的进程 无法看到彼此 隔离类型功能系统调用参数内核版本MNT Namespace(mount ns)提供磁盘挂载点文件系统的隔离能力CLONE_NEWNSLinux 2.4.19IPC Namespace(Inter-Process Communication)提供进程间通信隔离能力CLONE_NEWIPCLinux 2.6.19UTS Namespace(UNIX Timesharing System)提供主机名和域名隔离能力CLONE_NEWUTSLinux 2.6.19PID Namespace(Process Identification)提供进程隔离能力CLONE_ NEWPIDLinux 2.6.24Net Namespace(network)提供网络隔离能力CLONE_NEWNETLinux 2.6.29User Namespace(user)提供用户隔离能力CLONE_NEWUSERLinux 3.8
1.6.1 MNT Namespace
实现文件系统隔离 使用 MNT Namespace 可以实现容器内只能看到自己的挂载信息在容器内的挂载操作不会影响主机的挂载目录。 每个容器都要有独立的根文件系统、有独立的用户空间以实现在容器里面启动服务并且使用容器的运行环境。 即有一台服务器安装的操作系统是Ubuntu的操作系统我可以在上面启动一个以centos为运行环境的容器 并在容器里再启动一个nginx服务此nginx运行时使用的运行环境就是centos系统目录的运行环境但是在 容器里面是不能访问宿主机的资源的因为早期宿主机会使用一种叫chroot的技术现在是mnt ns把容器锁定到一个指定的运行目录里面。 如 /var/lib/docker/containerd/io.containerd.runtime.v1.linux/moby/容器ID 为什么我们可以访问容器为什么容器可以访问互联网
[roottest01 ~]# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 4 packets, 208 bytes)pkts bytes target prot opt in out source destination7 416 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCALChain INPUT (policy ACCEPT 4 packets, 208 bytes)pkts bytes target prot opt in out source destinationChain OUTPUT (policy ACCEPT 26 packets, 1787 bytes)pkts bytes target prot opt in out source destination0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCALChain POSTROUTING (policy ACCEPT 28 packets, 1891 bytes)pkts bytes target prot opt in out source destination0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0 # 上网是这里所有从容器发起的请求都会转换成0.0.0.0/00 0 MASQUERADE tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:80Chain DOCKER (2 references)pkts bytes target prot opt in out source destination0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/02 104 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:172.17.0.2:80 # 这条目的地址转换策略把所有进来访问80的请求都转换成了容器的IP:端口- Docker MNT NameSpace实现过程 Docker使用Linux内核提供的Mount Namespace来实现容器级文件系统隔离具体实现过程如下 1在创建Docker容器时Docker会调用Linux内核的Clone系统调用来创建一个新的进程并指定CLONE_NEWNS标志来创建一个新的Mount Namespace。 2Docker会将Docker容器的根文件系统挂载到容器的根目录上并为容器中的各个进程创建相应的挂载点。 3Docker可以使用Dockerfile或docker run命令中的“-v”选项将主机的文件系统挂载到Docker容器的指定挂载点上。这些挂载点是Docker运行时为容器创建的文件夹可以在容器中通过路径访问它们。 4在Docker容器中运行的应用程序会被限制在Docker容器的Mount Namespace中只能看到在该Namespace下挂载的文件系统无法访问主机或其他Docker容器的文件系统。 通过使用Mount NamespaceDocker容器的文件系统可以与主机或其他容器的文件系统进行隔离使得容器应用程序在运行过程中可以获取到独立的文件系统环境。这大大增强了Docker容器的可移植性和安全性。 除了上述这些我们在运行了docker容器的机上执行命令也可以看到相关进程。如下图 - containerd-shim -namespace moby -workdir 这段命令是用来启动containerd-shim进程并指定进程所在的Mount Namespace和工作目录的。具体含义如下 containerd-shim是Docker所有容器运行时的核心组件之一负责在容器中创建进程、管理标准输入/输出、加载应用程序等操作。 -namespace moby指定containerd-shim进程所在的Mount Namespace这样进程就可以使用独立的Mount Namespace来挂载文件系统防止与其他容器或主机中的文件系统发生干扰。moby是Docker的项目名称因此这里使用了moby作为命名空间的名称。 -workdir指定containerd-shim进程的工作目录即在容器中的工作目录。这个目录是通过Mount Namespace挂载到容器中的容器中的应用程序可以在这个目录中进行读写操作不会影响主机上的文件系统。 因此这个命令的功能是启动一个独立的containerd-shim进程并为它创建一个独立的Mount Namespace和工作目录以实现容器级别的文件系统隔离和运行时环境隔离。 1.6.2 IPC Namespace
实现容器进程间的通信隔离 IPC Namespace是Linux操作系统的一种Namespace类型它用于隔离进程间通信IPC机制。在同一个IPC Namespace中运行的进程可以 通过共享内存、消息队列、信号量等方式进行相互通信而不会影响到其他IPC Namespace中运行的进程。 在Docker中默认情况下每个容器都会拥有独立的IPC Namespace。这样的好处是避免了容器之间进行进程通信时可能出现的冲突和干扰。 例如如果在主机上运行了多个容器它们共享同一个IPC Namespace则一个容器中的消息队列可能会影响到其他容器中的应用程序。 而在单个容器内部IPC Namespace的隔离可以帮助不同的进程进行相互隔离和保护。例如在一个Web应用程序的容器中Web服务器进程 与后台处理进程可以运行在不同的IPC Namespace中这样可以避免Web服务器进程直接与后台进程进行通信提高了容器内部的安全性。 - Docker IPC NS实现过程 Docker运行容器时会使用Linux内核提供的clone()系统调用创建一个新的进程。这个新进程的IPC Namespace会被设置为一个全新的IPC Namespace与本机的IPC Namespace完全隔离。在这个新进程内Docker使用了两个系统调用来实现IPC Namespace的隔离 1unshare()系统调用用于将当前进程支离出一个独立的IPC Namespace。 2setns()系统调用将当前进程加入到一个已经存在的IPC Namespace内。 对于Docker中的容器使用的是第一种方式。当Docker创建一个新容器时它会使用unshare().CLONE_NEWIPC系统调用生成一个新的IPC Namespace的实例并将容器中的所有进程都添加到这个IPC Namespace中。这样该IPC Namespace内的进程就与主机上其他进程隔离开来了从而保证了容器间的IPC机制不相互干扰。在容器的IPC Namespace中容器内的进程通过IPC机制进行通信时只会在该IPC Namespace内部发生对主机上其他IPC Namespace完全无感知。 需要注意的是在Docker容器内部IPC Namespace不能跨越多个容器/主机间进行分享。也就是说在一个容器内部访问另一个容器/主机的IPC机制是不可能的。而且Docker也不支持动态地将容器内的IPC Namespace与主机上的IPC Namespace进行交叉共享这也保证了每个容器运行时IPC Namespace的独立性和安全性。 - Docker 为什么需要使用IPC Ns Docker需要使用IPC Namespace主要是为了隔离容器内的进程间通信其主要的优点包括 1隔离通过IPC NamespaceDocker为每个容器分配了独立的IPC资源避免了容器间资源的干扰和冲突有效保证了容器的可靠性和安全性。 2提高资源利用率IPC Namespace提高了容器内IPC资源的利用率不同的容器可以共享不同的IPC资源减少了资源浪费。 3改进容器可用性如果一个容器因进程间通信问题挂起或崩溃它将不会影响其他容器或宿主机中的进程。容器内的进程仅共享与容器内一致的IPC结构和数据从而改善了容器的可用性。 综上所述使用IPC Namespace可以提高容器的可靠性和安全性同时还可以有效提高IPC资源的利用率。因此Docker非常适合使用IPC Namespace隔离容器内IPC资源。 1.6.3 UTS Namespace
隔离宿主机、不同容器间的主机名和域名 UTS Namespace是Linux命名空间Namespace的一种类型用来隔离主机节点的主机名和域名。UTS是Unix Time-Sharing SystemUnix的分时系统的缩写Unix系统中的主机名和域名通常被称为UTS名称。在同一个UTS Namespace中运行的进程共享相同的主机名和域名而在不同的UTS Namespace中运行的进程拥有独立的主机名和域名。 在Docker中每个容器默认都有自己的UTS Namespace。这意味着每个容器具有独立的主机名和域名。这种隔离可以帮助用户在多个应用程序/服务之间进行快速切换并降低这些应用程序/服务之间的干扰。这个主机名标识独立于宿主机系统和其他容器。 - Docker UTS Namespace 实现过程 Docker在创建容器时会使用Linux内核提供的clone()系统调用生成一个新的进程。这个新进程的UTS Namespace会被设置为一个全新的UTS Namespace与本机的UTS Namespace完全隔离。在这个新进程内Docker使用了两个系统调用来实现UTS Namespace的隔离 1unshare()系统调用用于将当前进程支离出一个独立的UTS Namespace。 2setns()系统调用将当前进程加入到一个已经存在的UTS Namespace内。 对于Docker中的容器使用的是第一种方式。当Docker创建一个新容器时它会使用unshare()系统调用生成一个新的UTS Namespace的实例并将容器中的所有进程都添加到这个UTS Namespace中。这样容器内的所有进程就共享相同的主机名和域名而且与主机节点上的UTS Namespace完全隔离避免了容器与宿主机之间的UTS Namespace冲突。 需要注意的是在Docker容器内部UTS Namespace不能跨越多个容器/主机间进行分享。也就是说在一个容器内部访问另一个容器/主机的UTS Namespace是不可能的。而且Docker也不支持动态地将容器内的UTS Namespace与主机上的UTS Namespace进行交叉共享, 这也保证了每个容器运行时UTS Namespace的独立性和安全性。 - Docker为什么要使用UTS NameSpace Docker需要使用UTS Namespace主要是为了隔离容器中的主机名和域名。每个UTS Namespace内有一个hostname和一个domainname通过这两个参数可以唯一标识这个Namespace。当Docker容器创建时会使用unshare()系统调用创建一个新的UTS Namespace与宿主机的UTS Namespace完全隔离然后在这个新的UTS Namespace中启动容器内部的进程。 这种使用UTS Namespace的方式提供了多个优点 1隔离UTS Namespace提供了隔离容器与宿主机之间主机名和域名避免了容器与宿主机之间的命名空间冲突。 2独立性每个容器都有自己的UTS Namespace容器内的进程共享相同的主机名和域名但不会影响其他容器或宿主机中的进程。 3可配置性Docker允许用户在创建容器时定义自己的主机名和域名方便用户对容器设置自定义的主机名和域名 1.6.4 PID Namespace
容器PID和宿主机PID隔离 PID Namespace是Linux内核中的一种机制用于隔离进程IDPID命名空间每个PID Namespace都有一个独立的PID号码空间从而可以让不同的进程在不同的PID Namespace中具有相同的PID从而隔离了不同PID Namespace之间的进程。 - Docker PID Namespace 实现过程 在Docker中每个容器运行在一个独立的PID Namespace中实现步骤如下 1创建PID Namespace 当我们启动Docker容器时Docker会为该容器创建一个独立的PID Namespace。 2分配PID号码在PID Namespace中Docker会分配唯一的PID号码给每个容器内的进程并且这些PID号码在该Namespace中是唯一的。 3跟踪进程Docker会在宿主机上创建一个Daemon进程该进程负责跟踪容器内的进程并将其PID号码转换为在宿主机上的PID号码。这对于容器内的进程与宿主机环境的交互非常重要。 4进程绑定Docker会使用Linux内核提供的clone()系统调用将PID Namespace与容器内的进程进行绑定使得这些进程只能在该Namespace中运行。当容器内的进程退出时在进程树的根进程退出后容器的PID Namespace也会被销毁从而清理PID号码空间中的任何资源。 - Docker为什么要使用PID Namespace Docker使用PID Namespace主要是为了实现进程的隔离和统一管理。在Docker中每个容器都运行在一个独立的PID Namespace中其主要作用有 1隔离性由于每个容器都有自己独立的PID Namespace因此不同容器内的进程PID号码不会冲突互相独立运行提高了系统运行的稳定性和安全性。 2安全性使用PID Namespace可以将容器内的进程与宿主机上的进程进行隔离从而可以避免容器内的进程对宿主机上的进程造成影响。 3更好的管理使用PID Namespace可以方便容器内进程的管理和监控通过查看容器的PID Namespace可以快速了解容器内的进程状态。 4资源利用率使用PID Namespace可以提高系统资源的利用率多个容器可以共享同一个PID Namespace减少了系统资源的浪费。 下图是容器内使用top命令看到的pid为1的进程是nginx 容器内的Nginx主进程和工作进程 宿主机的PID究竟和容器内的PID是什么关系
- 容器进程与宿主进程间的关系 1.6.5 Net Namespace
网络隔离 Net Namespace是Linux内核中的一个功能可以帮助我们隔离网络资源的使用。它通过创建虚拟网络设备和IP地址来隔离应用程序对网络的访问使得在同一主机上运行的多个应用程序之间不会出现网络冲突并且应用程序可以使用不同的网络配置进行通信。 在Docker中每个容器都运行在自己的Net Namespace中这样就可以保证容器内的网络隔离性。具体实现过程如下 1创建Net Namespace当我们启动Docker容器时Docker会为该容器创建一个独立的Net Namespace。 2虚拟网络设备Docker会为该容器创建一个虚拟的网络设备比如veth x这个设备与宿主机上的一个设备相连。同时Docker会为该容器分配一个IP地址和IP路由表等网络资源。 3路由规则Docker会在容器所在的Net Namespace中创建一组路由规则这些规则定义了如何将容器的网络流量路由到宿主机上的网络设备。 4端口映射如果我们在容器中使用了端口映射Docker会为该容器配置iptables规则将容器端口与宿主机的端口进行映射。 - Docker Net Namespace 实现过程 1创建Net Namespace当我们启动Docker容器时Docker会为该容器创建一个独立的Net Namespace。 2虚拟网络设备Docker会在容器所在的Net Namespace中为该容器创建一个虚拟的网络设备比如veth x。该设备与宿主机上的一个网络设备连接在一起它们一端连接到容器另一端连接到宿主机上的一个bridge device。Docker会为该虚拟设备分配一个名字并且配置一个IP地址可以使用“ip addr”命令来查看。 3网络路由Docker还通过配置路由规则将容器内部的网络流量路由到与容器相连的虚拟网络设备上。Docker会为容器创建一个网络命名空间Net Namespace并且在这个命名空间中配置一组路由规则以及IP地址。 4iptables规则如果我们在容器中使用了端口映射Docker会为该容器配置iptables规则将容器内部的端口映射到主机上的特定端口上。 - Docker为什么要使用Net Namespace Docker使用Net Namespace来实现容器的网络隔离主要有以下几个原因 1隔离性使用Net NamespaceDocker可以为每个容器创建独立的网络命名空间每个容器拥有自己的独立网络配置、IP地址和路由表。这种方式防止了不同容器之间的网络干扰和冲突。 2安全性通过网络隔离Docker可以为每个容器提供与主机不同的网络配置和访问权限可以限制容器对网络资源的访问提高容器的安全性。 3灵活性使用Net Namespace可以为容器定义独立的网络配置包括IP地址、路由规则等使得应用程序可以直接访问网络资源而不需要额外的配置和管理。 4跨主机使用Net Namespace可以方便跨主机的容器通信和管理因为网络命名空间可以在不同主机之间转移和迁移。 综上所述Docker使用Net Namespace可以为容器提供独立的网络隔离和配置提高容器应用程序的灵活性和安全性并且方便跨主机管理和通信。 - 查看宿主机网卡信息 - 容器网络逻辑图 1.6.5.3 宿主机iptables规则 1.6.6 User Namespace
用户与用户组隔离 User Namespace是Linux内核提供的一种安全机制用于隔离用户UID/GID级别的权限。具体来说User Namespace提供了将特权用户映射成非特权用户从而允许在容器中运行的进程以非特权用户的身份运行保护宿主机的安全。 在Docker中User Namespace允许容器中的进程以非特权用户的身份运行从而大大减少了潜在的安全风险。通过将容器内的特权用户映射为宿主机上的非特权用户可以限制容器对宿主机的访问权限同时提高容器应用程序的安全性。 具体来说Docker使用User Namespace实现容器内部的用户隔离主要通过以下两种途径 1映射用户ID使用映射UIDuser ID和GIDgroup ID的方式将容器内的特权用户如root映射为宿主机上的非特权用户如nobody从而限制容器对宿主机的访问权限。 2创建新的用户在容器中创建新的用户使得容器的运行进程不会使用宿主机上已有的用户ID从而实现了容器内用户的隔离。 简而言之使用User Namespace可以提高Docker容器的安全性通过限制容器对宿主机的访问权限使得容器内的进程以非特权用户身份运行从而避免了潜在的安全隐患。 - Docker User Namespace 实现过程 Docker使用User Namespace来实现容器内的用户隔离具体实现过程如下 1配置Docker Daemon在Docker Daemon配置文件中需要开启User Namespace的支持。主要是通过设置“userns-remap”选项将容器内的特权用户映射为宿主机上的非特权用户。 2映射UID和GIDDocker会为每个容器生成一个映射表来存储User Namespace的映射配置。这个映射表将Linux用户ID和组ID映射到新的UID和GID从而实现容器内用户的隔离。 3容器进程启动当Docker启动一个容器时它会在容器中运行的进程上使用新的UID和GID。Docker会自动在容器中为用户创建一个新的UID和GID并将它们映射到宿主机上的非特权用户。这样容器内的进程就可以在USR Namespace中以非特权用户的身份运行。 4组权限管理除了UID和GID以外Docker还实现了组权限管理使得容器内的进程可以完整地使用Linux用户权限和组权限。 综上所述Docker使用User Namespace来隔离容器内的用户权限通过映射UID和GID将特权用户映射为宿主机上的非特权用户从而实现容器内用户的隔离。这种机制确保了容器集中的进程以更高的安全性运行并保护了宿主机免受恶意容器进程的攻击。 - Docker 为什么要使用User Namespace Docker使用User Namespace来提高容器的安全性主要由以下几方面原因 1隔离性使用User NamespaceDocker可以隔离容器内的用户身份将容器内的特权用户映射为宿主机上的非特权用户从而避免了对宿主机资源的非授权访问。 2安全性使用User Namespace可以避免恶意容器或者攻击者利用Docker容器漏洞进行提权攻击。通过映射UID/GID使得容器内的特权用户对宿主机没有访问权限从而提高了容器应用程序的安全性。 3灵活性使用User Namespace可以为容器定义独立的用户ID和组ID使得应用程序可以直接访问本地资源而不需要其他权限和管理软件。 4可移植性使用User Namespace可以保证Docker容器在同一主机上运行时的可移植性从而为容器的部署和管理提供了便利。 1.6.7 关于NameSpace的三个系统调用 1clone()实现线程的系统调用用来创建一个新的进程并可以通过设计上述参数达到隔离。 2unshare()使某进程脱离某个namespace。 3setns()把某进程加入到某个namespace。 - clone() Linux系统调用clone()是一种具有针对性的系统调用它可以用于创建一个新进程该进程与父进程共享某些资源同时对其他资源进行剥离其中一个使用场景就是在Docker容器中实现隔离性。在Docker中容器启动时就是使用了clone()系统调用特性来实现创建隔离的进程。 典型的clone()系统调用可以使用位掩码参数来指定创建的新进程与父进程共享的资源其中包括进程空间、虚拟内存、文件系统和网络等资源。下面是一些常用的位掩码参数 CLONE_NEWNS创建新的文件系统挂载点mount namespace使得根文件系统的挂载点不同于宿主机和其他容器从而实现隔离的文件系统。 CLONE_NEWUTS创建新的UTS namespace隔离hostname和domain name空间。 CLONE_NEWIPC创建新的IPC namespace隔离进程间通讯的资源例如消息队列、共享内存、信号量等。 CLONE_NEWPID创建新的PID namespace隔离进程ID空间使得容器内进程看起来跟宿主机中的进程ID没有任何关系。 CLONE_NEWNET创建新的network namespace隔离网络资源包括网络接口、路由表、ARP等。 在Docker中clone()的具体使用方式通常结合多个参数来实现容器的隔离性而没有显式的调用clone()函数。Docker利用namespaces和cgroups等技术创建出独立的进程空间并隔离进程间的资源从而使得容器的应用程序得到更好的隔离安全和可靠性。 总的来说clone() 作为一个基础的系统调用函数对于Docker容器的隔离性至关重要它通过利用namespaces和cgroups技术帮助Docker实现容器的隔离并协助在Docker容器内创建独立的进程空间从而保证了应用程序的安全性、可靠性和灵活性。 - unshare() Docker利用Linux的Namespaces机制来实现容器的隔离性而unshare()是Linux内核提供的一个系统调用函数可以使当前进程脱离某些或者全部的namespaces。 具体来说unshare()函数是在某个进程内部调用的它可以使这个进程“unshare”脱离某个或者多个namespaces从而使这个进程变得与拥有该namespace的进程不再相关。 在Docker中unshare()函数被用于创建容器时调用以便在容器实例中实现各种namespace的Isolation隔离性。例如Docker利用unshare()函数来创建新的mount namespace和network namespace以隔离容器的文件系统和网络和宿主机分离。 通过使用unshare()函数Docker可以实现一个更加安全和独立的runtime环境同时也可以确保容器与主机之间的隔离从而提高了容器的安全性和可靠性。 - setns() Linux内核提供的setns()系统调用可以将一个进程加入一个已经存在的namespace中从而实现不同进程之间共享一个namespace的效果。在Docker中setns()系统调用被用于在运行中的Docker容器中进入/退出namespace。 具体来说当Docker启动一个容器时它会创建一个新的Namespace并在其中运行容器进程这个容器进程在这个Namespace中享有完整的隔离性。而当我们使用Docker exec命令来进入一个正在运行的container中时其实就是利用了setns()系统调用将当前进程加入到容器中的namespace中去从而使得在该容器中可以执行命令操作。 setns()系统调用正是通过改变调用者进程的namespace文件句柄将调用者进程从一个namespace转移到另一个namespace中去。在Docker中它确保了在container内部的进程能够与主机上的进程隔离开并通过container namespace隔离文件系统、网络、用户等的权限因此应用程序可以在被容器隔离的环境中运行而不会对主机产生影响。 总的来说setns()是一个非常基础且重要的系统调用因为它提供了进程隔离性的核心机制之一可以确保不同进程具有一定的隔离性从而保证应用程序的安全可靠性。在Docker中结合运行时创建和进入container过程中的setns()彻底实现了container及其内部进程的隔离性及安全性。 1.7 Linux control groups
对容器进行资源限制 在一个容器内如果不对其做任何资源限制则宿主机会允许其占用无限大的内存和cpu有时候会因为代码的BUG导致程序一直申请内存直到系统OOM。 为了避免此类问题的出现宿主机有必要对容器进行资源分配限制比如cpu、内存等。 Linux Cgroups的全称是 Linux control groups它主要的作用就是限制一个进程能使用的资源上限包括cpu、内存、磁盘、网络带宽等此外还能对进程进行优先级设置以及将进程挂起和恢复等操作。 1.7.1 验证系统cgroups Cgroups在内核层默认已经开启了从CentOS和Ubuntu对别结果来看显然是内核较新的Ubuntu支持的功能更多。 1.7.1.1 CnetOS 7 Cgroups 1.7.1.2 Ubuntu Cgroups 1.7.1.3 Cgroups中的内存模块
[roottest01 ~]# cat /boot/config-3.10.0-1062.el7.x86_64 |grep MEMCG
CONFIG_MEMCGy
CONFIG_MEMCG_SWAPy
CONFIG_MEMCG_SWAP_ENABLEDy
CONFIG_MEMCG_KMEMy1.7.1.4 Cgroups的具体实现 blkio块设备IO限制。 cpu使用调度程序为cgroup任务提供的cpu的访问。 cpuacct产生cgroup任务的cpu资源报告。 cpuset如果是多核心的cpu这个子系统会为cgroup任务分配单独的cpu和内存。 devices允许或拒绝cgroup任务对设备的访问。 freezer暂停和恢复cgroup任务。 memory设置每个cgroup的内存限制以及产生内存资源报告。 net_cls标记每个网络包以供cgroup方便使用。 ns命名空间子系统。 perf_event增加了对每group的监测跟踪能力可以监测属于某个特定的group的所有线程以及运行在特定cpu上的线程。 1.7.1.5 Docker使用cgroups实现容器隔离和资源控制的步骤 1创建cgroup并将容器进程加入其中。 Docker创建容器时首先创建一个cgroup用于隔离容器内部资源。 然后将容器中的所有进程加入到该cgroup中使得cgroup能够控制这些进程的资源使用。 2在cgroup中设置容器的资源限制。 Docker通过cgroups设置容器的资源限制包括CPU、内存和磁盘等。 通过设置cgroup参数可以限制容器中进程所使用的资源。例如可以限制容器中进程使用的CPU和内存大小。 3监控cgroup中的资源使用情况。 Docker可以通过查询cgroups中的统计信息来监控容器的资源使用情况。 例如可以查看容器中进程的CPU使用率、内存使用量等信息以快速检测容器内部的资源使用情况。 总的来说Docker使用cgroups实现容器资源控制主要分为三个步骤即创建cgroup并将容器进程加入其中设置容器的资源限制以及监控cgroup中的资源使用情况。利用cgroups特性Docker可以实现对容器内部资源的隔离和管理确保应用程序的性能和稳定性。 1.7.1.6 查看系统cgroups
[rootlocalhost ~]# ll /sys/fs/cgroup/
total 0
drwxr-xr-x 5 root root 0 Mar 9 06:21 blkio
lrwxrwxrwx 1 root root 11 Mar 9 06:21 cpu - cpu,cpuacct
lrwxrwxrwx 1 root root 11 Mar 9 06:21 cpuacct - cpu,cpuacct
drwxr-xr-x 5 root root 0 Mar 9 06:21 cpu,cpuacct
drwxr-xr-x 3 root root 0 Mar 9 06:21 cpuset
drwxr-xr-x 5 root root 0 Mar 9 06:21 devices
drwxr-xr-x 3 root root 0 Mar 9 06:21 freezer
drwxr-xr-x 3 root root 0 Mar 9 06:21 hugetlb
drwxr-xr-x 5 root root 0 Mar 9 06:21 memory
lrwxrwxrwx 1 root root 16 Mar 9 06:21 net_cls - net_cls,net_prio
drwxr-xr-x 3 root root 0 Mar 9 06:21 net_cls,net_prio
lrwxrwxrwx 1 root root 16 Mar 9 06:21 net_prio - net_cls,net_prio
drwxr-xr-x 3 root root 0 Mar 9 06:21 perf_event
drwxr-xr-x 5 root root 0 Mar 9 06:21 pids
drwxr-xr-x 5 root root 0 Mar 9 06:21 systemd有了以上的chroot、namespace、cgroups就具备了基础的容器运行环境但是还需要有相应的容器创建与删除的管理工具、以及怎样把容器运行起来、容器数据怎么处理、怎么进行启动与关闭等问题需要解决于是容器管理技术出现了。1.8 容器管理工具
目前主要还是用的是docker早期有使用lxc。
1.8.1 lxc
LXC为LinuxContainer简写提供轻量级的虚拟化以便隔离进程和资源官网https://linuxcontainers.org/
LXC仅做了解即可。1.8.2 docker Docker启动一个容器也需要一个模板就是我们称之为镜像的东西镜像本身其实是个tar文件所以可以被tar解压docker的镜像可以保存在一个公共的地方共享使用只要把镜像拉取下来就可以使用最主要的是可以在镜像基础之上做自定义配置并且可以再把其提交为一个镜像一个镜像可以被启动为多个容器。 Docker的镜像是分层的镜像底层为库文件且只读既不能写入也不能删除数据从镜像加载启动为一个容器后会在上层生成一个可写层其写入的数据会复制到容器目录但是容器内的数据在容器被删除后也会被随之删除。 1.8.3 阿里巴巴的pouch
https://www.infoq.cn/article/alibaba-pouch https://github.com/alibaba/pouch
1.9 Docker的优缺点
1.9.1 Docker的优点 快速部署短时间内可以部署成百上千个应用更快速交付到线上。 高效虚拟化不需要额外的hypervisor支持直接基于linux实现应用虚拟化相比虚拟机大幅提升性能和效率。 节省开支提高服务器利用率降低IT支出。 简化配置将运行环境打包保存至容器使用时直接启动即可。 快速迁移和扩展可跨平台运行在物理机、虚拟机、公有云等环境良好的兼容性可以方便将应用从A宿主机迁移到B宿主机甚至是A平台迁移到B平台。 1.9.2 Docker的缺点 隔离性各应用之间的隔离性不如虚拟机彻底。 安全性root用户创建的容器将普通用户加入docekr组后可以把root创建的容器给删除掉。 2. Docker容器的核心技术
2.1 容器规范 容器技术除了docker之外还有coreOS的rkt、阿里巴巴的Pouch为了保证容器生态的标准性和健康可持续发展包括linux基金会、docker、微软、红帽、谷歌、ibm等在2015年6月共同成立了一个叫open container(OCI)的组织其目的就是制定开放的标准的容器规范。 目前OCI一共发布了两个规范分别是runtime spec容器运行时和image format spec镜像格式有了这两个规范不同的容器公司开发的容器只要兼容这两个规范就可以保证容器的可移植性和相互可操作性。 2.1.1 runtime规范容器运行时 runtime spec runtime是真正运行容器的地方因此为了运行不同的容器runtime需要和操作系统内核紧密合作相互支持以便为容器提供相应的运行环境。 主流的三种runtime 1Lxclinux上早期的runtimedocker早期就是采用lxc作为runtime。已废弃 2runc目前docker默认的runtimerunc遵守OCI规范因此可以兼容rkt。 3rkt是CoreOS开发的容器runtime也符合OCI规范所以使用rktruntime也可以运行docker容器。 runtime主要定义了以下规范并以json格式保存在/run/docker/runtime-runc/moby/容器ID/state.json文件此文件会根据容器的状态实时更新内容 1版本信息存放OCI标准的具体版本号。 2容器ID通常是一个哈希值可以在所有state.json文件中提取出容器ID对容器进行批量操作关闭、删除等此文件在容器关闭后会被删除容器启动后会自动生成。 3PID在容器中运行的首个进程在宿主机上的进程号即将宿主机的那个进程设置为容器的守护进程。 4容器文件目录存放容器rootfs及相应配置的目录外部程序只需要读取state.json就可以定位到宿主机上的容器文件目录。 5容器创建创建包括文件系统、namespace、cgroups、用户权限在内的各项内容。 6容器进程的启动运行容器启动进程该文件在/run/containerd/io.containerd.runtime.v1.linux/moby/容器ID/config.json。 7容器生命周期容器进程可以被外部程序关停runtime规范定义了对容器操作信号的捕获并做相应资源回收的处理避免僵尸进程的出现。 2.1.2 镜像规范image format spec
OCI容器镜像主要包含以下内容
1文件系统定义了以layer保存的文件系统在镜像里面是layer.tar每层都是一个layer.tar每个layer保存了和上层之间的变化的部分image format spec定义了layer应该保存哪些文件怎么表示增加、修改和删除的文件操作。
2manifest文件描述有哪些layertag标签以及config文件名称。
3config文件是一个以hash命名的json文件保存了镜像平台容器运行时需要的一些信息比如环境变量、工作目录、命令参数等。
4index文件可选的文件指向不同平台的manifest文件这个文件能保证一个镜像可以跨平台使用每个平台拥有不同的manifest文件使用index作为索引。
5父镜像大多数层的元信息结构都包含一个parent字段指向该镜像的父镜像。6参数
ID镜像ID每一层都有ID。
tag标签标签用于将用户指定的、具有描述性的名称对应到镜像ID。
仓库Repository镜像仓库。
os定义系统类型。
architecture定义CPU架构。
author作者信息。
create镜像创建日期。
[roottest01 ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 904b8cb13b93 11 days ago 142MB解压镜像查看
[roottest01 ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 904b8cb13b93 11 days ago 142MB
[roottest01 ~]# docker save 904b8cb13b93 nginx/nginx.image
[roottest01 ~]# cd nginx/
[roottest01 nginx]# ls
nginx.image
[roottest01 nginx]# tar xf nginx.image
tar: manifest.json: implausibly old time stamp 1970-01-01 08:00:00
[roottest01 nginx]# ll
total 142848
drwxr-xr-x 2 root root 50 Mar 2 02:43 022c07a52a220a5b0aa85c3a824850ce1fb0f626ad37987bed0d12cf4b5cb75f # 这些目录记录每一层的详情
drwxr-xr-x 2 root root 50 Mar 2 02:43 2bed87a39fb052307bc9771710f277c1ea99a45a1ae2401a224571349acf0a4f
drwxr-xr-x 2 root root 50 Mar 2 02:43 840c8426c9fb38d180b7707e5a7c604bc6123f94426de0cac0162628e0949ee8
-rw-r--r-- 1 root root 7656 Mar 2 02:43 904b8cb13b932e23230836850610fa45dce9eb0650d5618c2b1487c2a4f577b8.json
drwxr-xr-x 2 root root 50 Mar 2 02:43 9966e75239f521d16163dc5d699d3d46cd2e101adb83f18454112c8ad543aac7
drwxr-xr-x 2 root root 50 Mar 2 02:43 d92404db1780f763711ef26c68784b25309566e2b4c5bd13dea8f40479a13389
drwxr-xr-x 2 root root 50 Mar 2 02:43 db7652f1b7d48578873762fa2ebee6860f0596fd5e95f63411a4b815a16ab48e
-rw-r--r-- 1 root root 574 Jan 1 1970 manifest.json
-rw-r--r-- 1 root root 146263552 Mar 13 15:17 nginx.image[roottest01 nginx]# cd db7652f1b7d48578873762fa2ebee6860f0596fd5e95f63411a4b815a16ab48e
[roottest01 db7652f1b7d48578873762fa2ebee6860f0596fd5e95f63411a4b815a16ab48e]# ll
总用量 60764
-rw-r--r-- 1 root root 482 3月 2 02:43 json # 该层的描述信息
-rw-r--r-- 1 root root 62213632 3月 2 02:43 layer.tar # 这个tar包就是该层的具体内容
-rw-r--r-- 1 root root 3 3月 2 02:43 VERSION[roottest01 db7652f1b7d48578873762fa2ebee6860f0596fd5e95f63411a4b815a16ab48e]# cat json
{id:db7652f1b7d48578873762fa2ebee6860f0596fd5e95f63411a4b815a16ab48e,parent:2bed87a39fb052307bc9771710f277c1ea99a45a1ae2401a224571349acf0a4f,created:1970-01-01T08:00:0008:00,container_config:{Hostname:,Domainname:,User:,AttachStdin:false,AttachStdout:false,AttachStderr:false,Tty:false,OpenStdin:false,StdinOnce:false,Env:null,Cmd:null,Image:,Volumes:null,WorkingDir:,Entrypoint:null,OnBuild:null,Labels:null},os:linux}
# 格式转化下
{id:db7652f1b7d48578873762fa2ebee6860f0596fd5e95f63411a4b815a16ab48e,parent:2bed87a39fb052307bc9771710f277c1ea99a45a1ae2401a224571349acf0a4f, # 父镜像ID也就是该层的上一层created:1970-01-01T08:00:0008:00,container_config:{ # 容器配置Hostname:,Domainname:,User:,AttachStdin:false,AttachStdout:false,AttachStderr:false,Tty:false,OpenStdin:false,StdinOnce:false,Env:null,Cmd:null,Image:,Volumes:null,WorkingDir:,Entrypoint:null,OnBuild:null,Labels:null},os:linux
}上面的这些文件我们不要去动只要了解就行了2.2 容器管理工具
管理工具连接runtime与用户对用户提供图形或命令方式操作然后管理工具将用户操作传递给runtime执行。
lxc是lxd的管理工具。
Runc的管理工具是docker enginedocker engine包含后台deamon和cli两部分我们经常提到的docker就是指docker engine。
Rkt的管理工具是rkt cli。2.3 容器定义工具
容器定义工具允许用户定义容器的属性和内容以便容器能够被保存、共享和重建。
Docker image是docker容器的模板runtime依据docker image创建容器。
Dockerfile包含N个命令的文本文件通过dockerfile创建出docker image。
ACIApp container image与docker image类似是CoreOS开发的rkt容器的镜像格式。2.4 Registry
统一保存镜像而且是多个不同镜像版本的地方被称为镜像仓库。
Image registrydocker官方提供的私有仓库部署工具。
Docker hubdocker官方的公共仓库已经保存了大量的常用镜像可以直接拉取使用。
Harborvmware提供的自带web界面、自带认证功能的镜像仓库目前有很多公司使用。2.5 容器编排工具
2.5.1 为什么需要容器编排工具 当多个容器在多个主机运行的时候单独管理容器是相当复杂而且很容器出错的并且也无法实现某一台主机宕机后容器自动迁移到其他主机从而实现高可用的目的也无法实现动态伸缩的功能因此需要有一种工具可以实现统一管理、动态伸缩、故障自愈、批量执行等功能这就是容器编排引擎。 容器编排通常包括容器管理、调度、集群定义和服务发现等功能。 2.5.2 容器编排工具介绍 1Docker swarmdocker开发的容器编排引擎。 2Kubernetesgoogle领导开发的容器编排引擎内部项目为Borg且同时支持docker和CoreOS也是现在主流的容器编排工具。 3MesosMarathon通用的集群调度平台mesos资源分配与marathon容器编排平台一起提供容器编排功能。 3. Docker容器的依赖技术
3.1 容器网络 docker自带的网络docker networkdocker 0仅支持管理单机上的容器网络当多主机运行的时候需要使用第三方的开源网络软件如calico三层、flannel二层等。 docker 0是我们安装完docker并启动后产生的一块网卡它是不具备跨宿主机通信的能力的如果硬是要在局域网内使用这个IP一定要改。 [rootlocalhost ~]# ifconfig docker0: flags4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::42:92ff:fec1:111 prefixlen 64 scopeid 0x20 ether 02:42:92:c1:01:11 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5 bytes 446 (446.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 3.2 服务发现 容器的动态扩容特性决定了容器IP也会随之变化因此需要有一种机制可以自动识别并将用户请求动态转发到新建的容器上kubernetes自带服务发现功能需要结合kube-dns现在基本是使用coredns服务解析内部域名。 3.3 容器监控 可以通过原生命令docker ps/top/stats 查看容器运行状态另外也可以还是用 heapster/prometheus等第三方的监控工具来监控容器的运行状态。 3.4 数据管理 容器的动态迁移会导致其在不同的Host之间迁移因此如何保证与容器相关的数据也能随之迁移或随时访问可以使用逻辑卷/存储卷的方式解决。 3.5 日志收集
docker原生的日志查看工具docker logs但是容器内部的日志需要通过ELK等专门的工具进行收集分析和展示工具处理。为什么我们可以通过docker logs查看容器日志
[rootlocalhost ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8f3944218613 605c77e624dd /docker-entrypoint.… 5 days ago Up 31 minutes 0.0.0.0:80-80/tcp sweet_nightingale
[rootlocalhost ~]# docker exec -it 8f3944218613 /bin/bash
root8f3944218613:/# ls -l /var/log/nginx/access.log
lrwxrwxrwx 1 root root 11 Dec 29 2021 /var/log/nginx/access.log - /dev/stdout # 是以为在容器中把日志重定向到了标准输出中所以可以在宿主机上通过docker logs查看日志。4. Docker安装及基础命令
Docker官网www.docker.com
4.1 宿主机系统版本选择 Docker目前已经支持多种操作系统的安装运行比如Ubuntu、CentOS、Redhat、Debian、Fedora甚至还支持了Mac和windows在linxu系统上需要内核版本在3.10或以上docker版本号之前一直是0.x版本或1.x版本但是从2017年3月1号开始改为每个季度发布一次稳定版其版本号规则也统一变更为YY.MM例如17.09表示是2017年9月发布本次学习使用CentOS 7.9内核版本3.10.0。 4.2 Docker版本选择 Docker早期是没有区分版本的但是2017年初推出将docker更名新的项目Mobygithub地址github.com/moby/mobyMoby项目属于Docker项目的全新上游Docker将是一个隶属于的Moby子产品而且之后的版本开始区分为CE版本社区版和EE版本企业收费版CE社区版本和EE企业版本都是每个季度发布一次新版但是EE版本提供后期安全维护1年而CE版本是4个月。 与kubernetes结合使用的时候要安装经过kubernetes官方测试通过的docker版本避免出现不兼容等未知的及不可预估的问题发生kubernetes测试过的docker版本可以在github查询地址如下找了半天没找着 4.3 下载docker安装包并安装
4.3.1 下载docker的rpm包
官方rpm包下载地址https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ 二进制包下载地址https://download.docker.com/https://mirrors.aliyun.com/docker-ce/linux/static/stable/x86_64/ 阿里云镜像下载地址https://mirrors.alivyun.com/docker-ce/linux/centos/7/x86_64/stable/Packages/
4.3.2 YUM安装docker
清华源地址https://mirrors.tuna.tsinghua.edu.cn/
1如果你之前安装过 docker请先删掉没有安装过可以不执行这一步
[rootlocalhost ~]# yum remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine
Loaded plugins: fastestmirror
No Match for argument: docker
No Match for argument: docker-client
No Match for argument: docker-client-latest
No Match for argument: docker-common
No Match for argument: docker-latest
No Match for argument: docker-latest-logrotate
No Match for argument: docker-logrotate
No Match for argument: docker-engine
No Packages marked for removal2安装依赖
[rootlocalhost ~]# yum install -y yum-utils device-mapper-persistent-data lvm23添加repo文件
[rootlocalhost ~]# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
Loaded plugins: fastestmirror
adding repo from: https://download.docker.com/linux/centos/docker-ce.repo
grabbing file https://download.docker.com/linux/centos/docker-ce.repo to /etc/yum.repos.d/docker-ce.repo
repo saved to /etc/yum.repos.d/docker-ce.repo4把软件仓库地址替换为 TUNA
[rootlocalhost ~]# sed -i sdownload.docker.commirrors.tuna.tsinghua.edu.cn/docker-ce /etc/yum.repos.d/docker-ce.repo
[rootlocalhost ~]# yum makecache fast
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
docker-ce-stable | 3.5 kB 00:00:00
Metadata Cache Created5安装docker
# 这里默认是安装最新的可以通过命令来选择要安装的版本
[rootlocalhost ~]# yum list docker-ce --showduplicates | sort -r
Loading mirror speeds from cached hostfile
Loaded plugins: fastestmirror
docker-ce.x86_64 3:23.0.1-1.el7 docker-ce-stable
docker-ce.x86_64 3:23.0.0-1.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.9-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.8-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.7-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.6-3.el7 docker-ce-stable
……省略部分输出6选择指定版本安装
[rootlocalhost ~]# yum install docker-ce-20.10.5 docker-ce-cli-20.10.5 -y7启动
[rootlocalhost ~]# systemctl start docker
[rootlocalhost ~]# docker version
Client: Docker Engine - CommunityVersion: 20.10.5 # 这里注意服务端版本和客户端版本要相同API version: 1.41Go version: go1.13.15Git commit: 55c4c88Built: Tue Mar 2 20:33:55 2021OS/Arch: linux/amd64Context: defaultExperimental: trueServer: Docker Engine - CommunityEngine:Version: 20.10.5 # 这里注意服务端版本和客户端版本要相同API version: 1.41 (minimum version 1.12)Go version: go1.13.15Git commit: 363e9a8Built: Tue Mar 2 20:32:17 2021OS/Arch: linux/amd64Experimental: falsecontainerd:Version: 1.6.18GitCommit: 2456e983eb9e37e47538f59ea18f2043c9a73640runc:Version: 1.1.4GitCommit: v1.1.4-0-g5fd4c4ddocker-init:Version: 0.19.0GitCommit: de40ad04.3.3 二进制安装docker
官网文档https://docs.docker.com/engine/install/binaries/
# 1下载二进制安装包
## 版本选择https://download.docker.com/linux/static/stable/x86_64/
[rootlocalhost ~]# wget https://download.docker.com/linux/static/stable/x86_64/docker-19.03.13.tgz#2解压
[rootlocalhost ~]# ls
anaconda-ks.cfg docker-19.03.13.tgz update.sh
[rootlocalhost ~]# tar xf docker-19.03.13.tgz
[rootlocalhost ~]# ls docker
containerd containerd-shim ctr docker dockerd docker-init docker-proxy runc# 3复制相关文件到bin
[rootlocalhost ~]# cp docker/* /usr/bin/ # 做这一步是为了让普通用户也能使用docker命令#4systemd 管理docker
[roottest01 ~]# vim /etc/systemd/system/docker.service
[Unit]
DescriptionDocker Application Container Engine
Documentationhttps://docs.docker.com
Afternetwork-online.target firewalld.service
Wantsnetwork-online.target
[Service]
Typenotify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart/usr/bin/dockerd
ExecReload/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILEinfinity
LimitNPROCinfinity
LimitCOREinfinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMaxinfinity
TimeoutStartSec0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegateyes
# kill only the docker process, not all processes in the cgroup
KillModeprocess
# restart the docker process if it exits prematurely
Restarton-failure
StartLimitBurst3
StartLimitInterval60s
[Install]
WantedBymulti-user.target[roottest01 ~]# chmod x /etc/systemd/system/docker.service
[roottest01 ~]# systemctl daemon-reload
[roottest01 ~]# systemctl start docker[roottest01 ~]# docker version
Client: Docker Engine - CommunityVersion: 19.03.13API version: 1.40Go version: go1.13.15Git commit: 4484c46Built: Wed Sep 16 16:58:04 2020OS/Arch: linux/amd64Experimental: falseServer: Docker Engine - CommunityEngine:Version: 19.03.13API version: 1.40 (minimum version 1.12)Go version: go1.13.15Git commit: 4484c46Built: Wed Sep 16 17:04:43 2020OS/Arch: linux/amd64Experimental: falsecontainerd:Version: v1.3.7GitCommit: 8fba4e9a7d01810a393d5d25a3621dc101981175runc:Version: 1.0.0-rc10GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dddocker-init:Version: 0.18.0GitCommit: fec36834.3.4 docker的存储引擎
docker支持的存储引擎的选择https://docs.docker.com/storage/storagedriver/select-storage-driver/ 目前docker的存储引擎为overlay2不同的存储引擎需要相应的系统内核支持如果需要磁盘分区的时候传递d-type文件分层功能即需要传递内核参数开启格式化磁盘的时候指定功能。 4.3.4.1 AUFS AUFS (Another UnionFS是一种 Union FS是文件级的存储驱动。所谓UnionFS 就是把不同物理位置的目录合并mount到同一个目录中。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的只有最上层的文件系统是可写的。当需要修改一个文件时AUFS创建该文件的一个副本使用Cow将文件从只读层复制到可写层进行修改,结果也保存在可写层。在Docker中底下的只读层就是image可写层就是Container是Docker 18.06及更早版本的首选存储驱动程序在内核3.13上运行Ubuntu 14.04时不支持overlay2。 4.3.4.2 Overlay Overlay是一种Union FS文件系统Linux内核3.18后支持。 4.3.4.3 overlay2 overlay2是Overlay的升级版到目前为止所有Linux发行版推荐使用的存储类型docker官方推荐。 4.3.4.4 devicemapper devicemapper是CentOS和RHEL的推荐存储驱动程序因为之前的内核版本不支持overlay2但是当前较新版本的CentOS和RHEL现在已经支持overlay2因此推荐使用overlay2。 4.3.4.5 ZFS/btrfs ZFS(Sun-2005年推广使用)/btrfs(Oracle-2007年推广使用):目前没有广泛使用。 4.3.4.6 vfs vfs用于测试环境适用于无法使用copy-on-write文件系统的情况。此存储驱动程序的性能很差,通常不建议用于生产。 4.3.4.7 使用存储引擎注意事项
Docker官方推荐首选存储引擎为overlay2, devicemapper存在使用空间方面的一些限制,虽然可以通过后期配置解决但是官方依然推荐使用overlay2,以下是网上查到的部分资料:https://www.cnblogs.com/youruncloud/p/5736718.html 上图的ftype1表示开启镜像分层功能7.3及以上的系统基本都是自动开启的。
如果docker数据目录是一块单独的磁盘分区而且是xfs格式的那么需要在格式化的时候加上参数-n ftype1否则后期在启动容器的时候会报错不支持d-type。下图是CentOS 7.2 Centos 7.2报错界面
CentOS7.3修复此问题
4.3.5 docker服务进程
通过查看docker进程了解docker的运行及工作方式
4.3.5.1 查看宿主机进程树
[rootlocalhost ~]# docker version
Server: Docker Engine - CommunityEngine:Version: 19.03.13API version: 1.40 (minimum version 1.12)Go version: go1.13.15Git commit: 4484c46Built: Wed Sep 16 17:04:43 2020OS/Arch: linux/amd64Experimental: false4.3.5.2 查看containerd进程关系
有四个进程
dockerd:被docker-client直接访问其父进程为宿主机的systemd守护进程。
docker-proxy:实现容器通信主要维护IPtables规则其父进程为dockerd
containerd:被dockerd进程调用以实现与runc交互来创建容器。
containerd-shim:真正运行容器的载体其父进程为containerd。4.3.5.3 containerd-shim命令使用
这个一般不直接使用都是由docker命令来进行容器操作
[rootlocalhost ~]# containerd-shim -h
Usage of containerd-shim:-address stringgrpc address back to main containerd-containerd-binary containerd publishpath to containerd binary (used for containerd publish) (default containerd)-criu stringpath to criu binary-debugenable debug output in logs-namespace stringnamespace that owns the shim-runtime-root stringroot directory for the runtime (default /run/containerd/runc)-socket stringabstract socket path to serve-systemd-cgroupset runtime to use systemd-cgroup-workdir stringpath used to storge large temporary data4.3.5.4 容器的创建与管理过程
通信流程 我们通过docker命令访问dockerddockerd通过grpc协议和containerd模块通信(runc)交换dockerd和containerd通信的socket文件:/run/containerd/containerd.sock。 containerd在 dockerd 启动时被启动,然后containerd启动grpc请求监听containerd 处理grpc请求,根据请求做相应动作。 dockerd靠 /usr/bin/dockerd -H fd:// --containerd/run/containerd/containerd.sock来和containerd通信 若是创建容器containerd拉起一个container-shim 容器进程并进行相应的创建操作。 container-shim被拉起后, start/exec/create 拉起runC进程,通过exit、control文件和containerd通信,通过父子进程关系和 SIGCHLD(信号)监控容器中进程状态。 5.在整个容器生命周期中containerd通过epoll监控容器文件监控容器事件。 4.3.5.5 docker信息验证
[roottest01 ~]# docker info
Client:Debug Mode: false # 客户段是否开启debug模式Server:Containers: 1 # 当前主机上的容器总数Running: 1 # 有几个容器是正在运行的Paused: 0 # 暂停的容器数量Stopped: 0 # 已停止的容器数量Images: 3 # 本地主机上镜像的数量Server Version: 19.03.13 # Docker引擎的版本号服务端Storage Driver: overlay2 # Docker宿主机上使用的存储驱动程序Backing Filesystem: xfs # 后端文件系统即服务器的磁盘文件系统Supports d_type: true # 是否支持d_typeNative Overlay Diff: true # 是否支持差异数据存储Logging Driver: json-file # 日志类型Cgroup Driver: cgroupfs # cgroups类型Plugins: # 本地主机上可用的Docker插件列表Volume: local # 卷Network: bridge host ipvlan macvlan null overlay # docker支持的网络类型Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog # 日志类型Swarm: inactive # 本地主机上Swarm模式的状态信息Runtimes: runc # 本地主机上支持的运行时列表Default Runtime: runc # 默认的容器运行时Init Binary: docker-init # 初始化容器的守护进程即pid为1的进程containerd version: 8fba4e9a7d01810a393d5d25a3621dc101981175 # containerd组件的版本号runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd # runc组件的版本号init version: fec3683 # 器初始化组件的版本号Security Options: # Docker宿主机上的安全选项seccomp # 审计Profile: default # 默认的配置文件Kernel Version: 3.10.0-1062.el7.x86_64 # 宿主机内核版本Operating System: CentOS Linux 7 (Core) # 宿主机操作系统OSType: linux # 宿主机操作系统类型Architecture: x86_64 # 宿主机架构CPUs: 2 # 宿主机CPU数量Total Memory: 3.701GiB # 宿主机总内存Name: test01 # 宿主机主机名ID: NFCG:7O4K:ZAIA:PJNQ:EBFF:47RQ:ETQ7:4CZY:W6LP:UL6G:XGUM:L37O # 宿主机IDDocker Root Dir: /var/lib/docker # docker在宿主机上的数据目录Debug Mode: false # 是否开启debugRegistry: https://index.docker.io/v1/ # 默认的镜像仓库地址Labels: # 其他标签Experimental: false # 是否为测试版Insecure Registries: # 非安全的镜像仓库127.0.0.0/8Registry Mirrors: # 自定义的镜像仓库地址https://carcbv39.mirror.aliyuncs.com/Live Restore Enabled: false # 是否开启活动重启(重启docker-daemon不关闭容器)Product License: Community Engine # 产品许可信息4.3.6 重点知识总结
1namespace和cgroup。# 面试
2docker的各种安装方式。
3docker镜像操作命令。
4docker进程对应关系。
5docker存储引擎。
7Union File system联合文件挂载。4.4 docker安装后的配置优化
4.4.1 配置镜像下载加速
docker默认下载镜像是从国外下载的有时候会很慢这个时候我们可以添加国内的下载地址来进行加速。
4.4.1.1 获取加速地址
阿里云镜像加速文档https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
# mkdir -p /etc/docker 这个目录安装启动完docker后就自动创建好了
[rootlocalhost ~]# tee /etc/docker/daemon.json -EOF
{registry-mirrors: [https://carcbv39.mirror.aliyuncs.com]
}
EOF
[rootlocalhost ~]# cat /etc/docker/daemon.json
{registry-mirrors: [https://carcbv39.mirror.aliyuncs.com]
}[rootlocalhost ~]# systemctl daemon-reload
[rootlocalhost ~]# systemctl restart docker
[rootlocalhost ~]# docker info|grep Registry M -A 1 # 这里可以看到镜像加速配置成功了Registry Mirrors:https://carcbv39.mirror.aliyuncs.com/4.4.2 修改存储引擎
注意修改存储引擎会有数据丢失请先做好备份。谨慎操作
操作前备份数据
换存储引擎会导致已有的容器和镜像及容器数据全部丢失所以做之前一定要备份。
备份镜像、数据容器里面的、找到容器的启动命令4.4.2.1 操作前检查
# 这里可以看到有一个容器和一个镜像
[rootlocalhost ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8853c279fda nginx /docker-entrypoint.… 56 minutes ago Up 17 seconds 0.0.0.0:8080-80/tcp nginx-test
[rootlocalhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB[rootlocalhost ~]# docker info|grep Storage Driver: # 这里默认的存储引擎是overlay2Storage Driver: overlay24.4.2.2 修改存储引擎为overlay
[rootlocalhost ~]# dockerd -h|grep storage-driver # 可以通过dockerd -h来查看可变更的地方-s, --storage-driver string Storage driver to use # 这就修改存储引擎的参数方式1添加参数到docker.service启动配置中 不推荐该方式
[rootlocalhost ~]# vim /etc/systemd/system/docker.service
[Unit]
DescriptionDocker Application Container Engine
Documentationhttps://docs.docker.com
Afternetwork-online.target docker.socket firewalld.service
Wantsnetwork-online.target[Service]
Typenotify
ExecStart/usr/bin/dockerd --storage-driver overlay # --storage-driver overlay添加到ExecStart这一行的末尾
ExecReload/bin/kill -s HUP $MAINPID
LimitNOFILE1048576
LimitNPROCinfinity
LimitCOREinfinity
TasksMaxinfinity
TimeoutStartSec0
Restarton-abnormal[Install]
WantedBymulti-user.target[rootlocalhost ~]# systemctl daemon-reload
[rootlocalhost ~]# systemctl restart docker
[rootlocalhost ~]# docker info | grep Storage Driver: Storage Driver: overlay #这里可以看到存储引擎已经被修改# 下面可以看到容器和镜像全部没有了
[rootlocalhost ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
[rootlocalhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE方式2添加参数到daemon.json中 推荐该方式
# 操作前复原删除在启动配置文件中添加的配置
[rootlocalhost ~]# grep ExecStart /etc/systemd/system/docker.service
ExecStart/usr/bin/dockerd # 这里添加的配置我已经删除了[rootlocalhost ~]# cat /etc/docker/daemon.json
{registry-mirrors: [https://carcbv39.mirror.aliyuncs.com],storage-driver: overlay2 # 修改存储引擎的配置
}[rootlocalhost ~]# systemctl restart docker
[rootlocalhost ~]# systemctl status docker
[rootlocalhost ~]# docker info | grep Storage Driver: Storage Driver: overlay24.4.3 修改docker数据存储目录
注意该操作也会有数据丢失操作前做好备份。 数据目录默认在/va/lib/docker下 这个操作不是必须的主要是看盘的大小。 如果只有一块盘且空间比较大可以不用修改。 如果只有一块盘磁盘空间还很小就需要添加一块数据盘修改docker数据存储到数据盘上。
[rootlocalhost ~]# dockerd -h | grep data-root--data-root string Root directory of persistent Docker state (default /var/lib/docker) # 使用该参数修改数据存储目录[rootlocalhost ~]# docker info|grep Docker Root DirDocker Root Dir: /var/lib/docker # 修改前# 开始修改
[rootlocalhost ~]# cat /etc/docker/daemon.json
{registry-mirrors: [https://carcbv39.mirror.aliyuncs.com],storage-driver: overlay2,data-root: /data/docker # 修改数据存储目录
}[rootlocalhost ~]# mkdir -p /data/docker
[rootlocalhost ~]# systemctl daemon-reload
[rootlocalhost ~]# systemctl restart docker[rootlocalhost ~]# docker info|grep Docker Root DirDocker Root Dir: /data/docker # 修改后[rootlocalhost ~]# ll /data/docker/ # dockr重启后在指定的目录生成了新的数据
total 0
drwx------ 2 root root 24 Mar 16 00:24 builder
drwx--x--x 4 root root 92 Mar 16 00:24 buildkit
drwx--x--x 3 root root 20 Mar 16 00:24 containerd
drwx------ 2 root root 6 Mar 16 00:24 containers
drwx------ 3 root root 22 Mar 16 00:24 image
drwxr-x--- 3 root root 19 Mar 16 00:24 network
drwx------ 3 root root 40 Mar 16 00:24 overlay2
drwx------ 4 root root 32 Mar 16 00:24 plugins
drwx------ 2 root root 6 Mar 16 00:24 runtimes
drwx------ 2 root root 6 Mar 16 00:24 swarm
drwx------ 2 root root 6 Mar 16 00:24 tmp
drwx------ 2 root root 6 Mar 16 00:24 trust
drwx------ 2 root root 25 Mar 16 00:24 volumes4.4.4 开启内核转发功能必做
# 容器要想访问外部网络需要本地系统的转发支持。在Linux 系统中检查转发是否打开。
$sysctl net.ipv4.ip_forward
net.ipv4.ip_forward 1# 如果为 0说明没有开启转发则需要手动打开。
sysctl -w net.ipv4.ip_forward1如果在启动 Docker 服务的时候设定 --ip-forwardtrue , Docker 就会自动设定系统的ip_forward 参数为 1。4.5 docker镜像管理 Docker镜像含有启动容器所需要的文件系统及所需要的内容因此镜像主要用于创建并启动docker容器。 Docker镜像含里面是一层层文件系统,叫做Union File System (Union FS联合文件系统)2004年由纽约州立大学石溪分校开发联合文件系统可以将多个目录挂载到一起从而形成一整个虚拟文件系统该虚拟文件系统的目录结构就像普通linux的目录结构一样,docker通过这些文件再加上宿主机的内核提供了一个linux的虚拟环境,每一层文件系统我们叫做一层 layer联合文件系统可以对每一层文件系统设置三种权限只读readonly) 、读写(readwrite)和写出(whiteout-able)但是docker镜像中每一层文件系统都是只读的,构建镜像的时候,从一个最基本的操作系统开始,每个构建的操作都相当于做一层的修改增加了一层文件系统,一层层往上叠加,上层的修改会覆盖底层该位置的可见性这也很容易理解就像上层把底层遮住了一样,当使用镜像的时候我们只会看到一个完全的整体不知道里面有几层也不需要知道里面有几层结构如下: 联合文件系统演示
# cd /opt/
# mkdir a b system # 这里可以把a理解成镜像层、b理解可写层、system理解为容器的文件系统
# touch a/a.txt b/b.txt
# mount -t aufs -o dirs./a:./b none ./system/ # 把a和b挂载到system下4.5.1 镜像结构
关于镜像结构描述官方文档https://docs.docker.com/storage/storagedriver/ 一个典型的Linux文件系统由bootfs和rootfs两部分组成,bootfs(boot filesystem)主要包含bootloader和 kernel, bootloader主要用于引导加载kernel,当kernel被加载到内存中后bootfs会被umount掉,rootfs (root file system)包含的就是典型Linux系统中的/dev/proc/bin/etc等标准目录和文件下图就是docker image 中最基础的两层结构不同的 linux发行版(如ubuntu和CentOS )在rootfs这一层会有所区别。 但是对于docker镜像通常都比较小官方提供的centos基础镜像在20OMB左右一些其他版本的镜像甚至只有几MB, docker镜像直接调用宿主机的内核镜像中只提供rootfs也就是只需要包括最基本的命令、工具和程序库就可以了比如alpine镜像在5M左右。 下图就是有两个不同的镜像在一个宿主机内核上实现不同的rootfs
容器、镜像父镜像
查看镜像层次
[roottest01 ~]# docker save nginx:latest nginx.image
[roottest01 ~]# mkdir nginx
[roottest01 ~]# tar xf nginx.image -C nginx
[roottest01 ~]# cd nginx
[roottest01 nginx]# cat manifest.json
[{Config:605c77e624ddb75e6110f997c58876baa13f8754486b461117934b24a9dc3a85.json,RepoTags:[nginx:latest],Layers:[5df3f744c961b85bb93947d6a4288543c06e64b3130562ae7be85fdc9f7a5691/layer.tar,0cb59b23812a64ae9115a5cf081f05d3d1915c5d7d2304c64b1c3a07629122a9/layer.tar,728205feeb04d15cbf0b889a9336e553bf6d472a311724e567a156afe3cb105d/layer.tar,0e9f59de25dca39e1cc33d1b7a83f27668c800221d7f1062a5da0df9ba684f44/layer.tar,7e8578b7bc47a5f07742264aace8ee761078c30c1c2c2dafbc79a8ebd340c191/layer.tar,8c46511b06be8a5ed3d1478039cd8e3bcb0842b8a68c42babb5e9c4b6dc6beeb/layer.tar]}]命令行查看镜像是如何构成的
[roottest01 ~]# docker history nginx
IMAGE CREATED CREATED BY SIZE COMMENT
605c77e624dd 14 months ago /bin/sh -c #(nop) CMD [nginx -g daemon… 0B # 最后一步
missing 14 months ago /bin/sh -c #(nop) STOPSIGNAL SIGQUIT 0B
missing 14 months ago /bin/sh -c #(nop) EXPOSE 80 0B
missing 14 months ago /bin/sh -c #(nop) ENTRYPOINT [/docker-entr… 0B
missing 14 months ago /bin/sh -c #(nop) COPY file:09a214a3e07c919a… 4.61kB
missing 14 months ago /bin/sh -c #(nop) COPY file:0fd5fca330dcd6a7… 1.04kB
missing 14 months ago /bin/sh -c #(nop) COPY file:0b866ff3fc1ef5b0… 1.96kB
missing 14 months ago /bin/sh -c #(nop) COPY file:65504f71f5855ca0… 1.2kB
missing 14 months ago /bin/sh -c set -x addgroup --system -… 61.1MB
missing 14 months ago /bin/sh -c #(nop) ENV PKG_RELEASE1~bullseye 0B
missing 14 months ago /bin/sh -c #(nop) ENV NJS_VERSION0.7.1 0B
missing 14 months ago /bin/sh -c #(nop) ENV NGINX_VERSION1.21.5 0B
missing 15 months ago /bin/sh -c #(nop) LABEL maintainerNGINX Do… 0B
missing 15 months ago /bin/sh -c #(nop) CMD [bash] 0B
missing 15 months ago /bin/sh -c #(nop) ADD file:09675d11695f65c55… 80.4MB # 第一步[roottest01 ~]# docker history alpine # 像这种操作系统体积小层数也很少因为里面就一个操作系统
IMAGE CREATED CREATED BY SIZE COMMENT
c059bfaa849c 15 months ago /bin/sh -c #(nop) CMD [/bin/sh] 0B
missing 15 months ago /bin/sh -c #(nop) ADD file:9233f6f2237d79659… 5.59MB4.5.2 镜像相关命令
4.5.2.1 搜索镜像
在官方的docker仓库中搜索指定名称的docker镜像也会有很多镜像。 官方镜像仓库https://hub.docker.com/ 推荐在官方搜索展示更直观
[roottest01 ~]# docker search nginx # 不指定版本默认搜最新版
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
nginx Official build of Nginx. 18236 [OK]
linuxserver/nginx An Nginx container, brought to you by LinuxS… 188
bitnami/nginx Bitnami nginx Docker Image 153 [OK]
ubuntu/nginx Nginx, a high-performance reverse proxy we… 79
privatebin/nginx-fpm-alpine PrivateBin running on an Nginx, php-fpm Al… 72 [OK]
bitnami/nginx-ingress-controller Bitnami Docker Image for NGINX Ingress Contr… 23 [OK]
rancher/nginx-ingress-controller 11
……省略部分输出[roottest01 ~]# docker search nginx:1.18 # 指定版本搜索
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
sspilchin/nginx-waf Nginx from upstream nginx:1.18 with added mo… 0
royye/php7.3 php:7.3.27-fpm-alpine3.12 extensions: redis … 0
biggerwing/nginx1.18.0 nginx:1.18.0 0
benzoasis/rsmall-frontend - php:lastest - node:lastest - nginx:1.18.0-… 0# 参数说明
NAME: 镜像仓库源的名称
DESCRIPTION: 镜像的描述
OFFICIAL: 是否 docker 官方发布。有[OK]的就是官方的。
stars: 类似 Github 里面的 star表示点赞、喜欢的意思。
AUTOMATED: 自动构建。4.5.2.2 下载镜像
# 命令格式
docker pull 仓库服务器:端口/项目名称/镜像名称:tag(版本)号
# 如harbor.test.com/test/nginx-ubuntu:20230316_152540[roottest01 ~]# docker pull tomcat4.5.2.3 镜像下载状态
参数描述Downloading正在下载镜像文件Extracting正在解压镜像文件Verifying Checksum正在校验下载的镜像文件的正确性。Pull complete镜像下载完成Image already exists本地已经存在相同的镜像无需下载。Error镜像下载出现错误。
4.5.2.4 查看镜像
下载完成的镜像比下载的大因为下载完成后会解压
[roottest01 ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB
tomcat latest fb5657adc892 14 months ago 680MB
alpine latest c059bfaa849c 15 months ago 5.59MB# 参数
REPOSITORY #镜像所属的仓库名称
TAG #镜像版本号(标识符)默认为 latest
IMAGE ID #镜像ID镜像的唯一标识符
CREATED #镜像创建时间
SIZE #镜像大小4.5.2.5 镜像导出
可以将镜像从本地导出问为一个压缩文件然后复制到其他服务器进行导入使用。 方法1
[roottest01 ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB
tomcat latest fb5657adc892 14 months ago 680MB
alpine latest c059bfaa849c 15 months ago 5.59MB
[roottest01 ~]# docker save -o /tmp/alpine-latest.image alpine:latest # alpine:latest也可以换成镜像ID
[roottest01 ~]# ll -rt /tmp/
total 5740
drwxr-xr-x 2 root root 6 Mar 16 17:15 hsperfdata_root
-rw------- 1 root root 5875712 Mar 16 17:41 alpine-latest.image方法2
[roottest01 ~]# docker save alpine:latest /opt/alpine-latest-image.tar.gz # 这个后缀 可以自定义
[roottest01 ~]# ll -rth /opt/
total 5.7M
drwx--x--x 4 root root 28 Mar 15 14:59 containerd
drwxr-xr-x 2 root root 6 Mar 16 13:37 system
drwxr-xr-x 2 root root 19 Mar 16 13:38 b
drwxr-xr-x 2 root root 19 Mar 16 13:38 a
-rw-r--r-- 1 root root 5.7M Mar 16 17:50 alpine-latest-image.tar.gz4.5.2.6 镜像导入
方式1
[roottest01 ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB
tomcat latest fb5657adc892 14 months ago 680MB
alpine latest c059bfaa849c 15 months ago 5.59MB
[roottest01 ~]# docker rmi c059bfaa849c # 因为我只开了一台虚拟机 所以要先删除再做导入测试
[roottest01 ~]# cd /tmp/
[roottest01 tmp]# ls
alpine-latest.image hsperfdata_root
[roottest01 tmp]# docker load -i alpine-latest.image # -i从指定文件中导入镜像
8d3ac3489996: Loading layer [] 5.866MB/5.866MB
Loaded image: alpine:latest
[roottest01 tmp]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB
tomcat latest fb5657adc892 14 months ago 680MB
alpine latest c059bfaa849c 15 months ago 5.59MB方式2
[roottest01 tmp]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB
tomcat latest fb5657adc892 14 months ago 680MB
alpine latest c059bfaa849c 15 months ago 5.59MB
[roottest01 tmp]# docker rmi c059bfaa849c
Untagged: alpine:latest
Deleted: sha256:c059bfaa849c4d8e4aecaeb3a10c2d9b3d85f5165c66ad3a4d937758128c4d18
Deleted: sha256:8d3ac3489996423f53d6087c81180006263b79f206d3fdec9e66f0e27ceb8759
[roottest01 tmp]# docker load /tmp/alpine-latest.image
8d3ac3489996: Loading layer [] 5.866MB/5.866MB
Loaded image: alpine:latest
[roottest01 tmp]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 605c77e624dd 14 months ago 141MB
tomcat latest fb5657adc892 14 months ago 680MB
alpine latest c059bfaa849c 15 months ago 5.59MB4.5.2.7 删除镜像
[roottest01 tmp]# docker rmi c059bfaa849c # 通过id删除或者容器名删除都可以但是更推荐通过id删除这样更加安全。
Untagged: alpine:latest
Deleted: sha256:c059bfaa849c4d8e4aecaeb3a10c2d9b3d85f5165c66ad3a4d937758128c4d18
Deleted: sha256:8d3ac3489996423f53d6087c81180006263b79f206d3fdec9e66f0e27ceb8759# 参数
- -f, --force强制删除镜像即使有容器正在使用该镜像也会被强制删除。 # 不推荐使用该参数
- -no-prune不会删除与底层镜像关联的任何镜像和容器。
- -quiet, --quiet: 安静地删除不打印任何输出。4.5.2.8 批量清理未使用的docker镜像
工作中镜像长时间不清理磁盘空间会越来越小所以需要定期进行清理
docker image prune -a -f# 参数
- docker image prune用于清理 Docker 系统中未被使用的镜像。
- -a指定清理所有无用镜像包括被容器使用的和没有被使用的镜像。
- -f强制执行清理操作不需要确认删除操作5. 总结
