docker容器技术基础入门

最新推荐文章于 2023-05-29 17:40:19 发布

MD_雨落心尘.wyn

最新推荐文章于 2023-05-29 17:40:19 发布

阅读量77

点赞数

文章标签： docker

本文链接：https://blog.csdn.net/qq_58733916/article/details/126167400

版权

docker容器技术基础入门

文章目录

docker容器技术基础入门
docker基础用法

Linux容器技术

Linux容器其实并不是什么新概念。最早的容器技术可以追遡到1982年Unix系列操作系统上的chroot工具（直到今天，主流的Unix、Linux操作系统仍然支持和带有该工具）。

Linux Namespaces

命名空间(Namespaces)是Linux内核针对实现容器虚拟化而引入的一个强大特性。

每个容器都可以拥有自己独立的命名空间，运行其中的应用都像是在独立的操作系统中运行一样。命名空间保证了容器间彼此互不影响。

namespaces	系统调用参数	隔离内容	内核版本
UTS	CLONE_NEWUTS	主机名和域名	2.6.19
IPC	CLONE_NEWIPC	信号量、消息队列和共享内存	2.6.19
PID	CLONE_NEWPID	进程编号	2.6.24
Network	CLONE_NEWNET	网络设备、网络栈、端口等	2.6.29
Mount	CLONE_NEWNS	挂载点（文件系统）	2.4.19
User	CLONE_NEWUSER	用户和用户组	3.8

CGroups

控制组(CGroups)是Linux内核的一个特性，用来对共享资源进行隔离、限制、审计等。只有能控制分配到容器的资源，Docker才能避免多个容器同时运行时的系统资源竞争。

控制组可以提供对容器的内存、CPU、磁盘IO等资源进行限制。

CGroups能够限制的资源有：

blkio：块设备IO
cpu：CPU
cpuacct：CPU资源使用报告
cpuset：多处理器平台上的CPU集合
devices：设备访问
freezer：挂起或恢复任务
memory：内存用量及报告
perf_event：对cgroup中的任务进行统一性能测试
net_cls：cgroup中的任务创建的数据报文的类别标识符

具体来看，控制组提供如下功能：

资源限制（Resource Limitting）组可以设置为不超过设定的内存限制。比如：内存子系统可以为进行组设定一个内存使用上限，一旦进程组使用的内存达到限额再申请内存，就会发出Out of Memory警告 OOM 内存溢出
优先级（Prioritization）通过优先级让一些组优先得到更多的CPU等资源
资源审计（Accounting）用来统计系统实际上把多少资源用到合适的目的上，可以使用cpuacct子系统记录某个进程组使用的CPU时间
隔离（Isolation）为组隔离命名空间，这样一个组不会看到另一个组的进程、网络连接和文件系统
控制（Control）挂起、恢复和重启等操作

安装Docker后，用户可以在/sys/fs/cgroup/memory/docker/目录下看到对Docker组应用的各种限制项，包括

[root@localhost ~]# cd /sys/fs/cgroup/memory/
[root@localhost memory]# ls
cgroup.clone_children memory.kmem.slabinfo memory.memsw.limit_in_bytes memory.swappiness
cgroup.event_control memory.kmem.tcp.failcnt memory.memsw.max_usage_in_bytes memory.usage_in_bytes
cgroup.procs memory.kmem.tcp.limit_in_bytes memory.memsw.usage_in_bytes memory.use_hierarchy
cgroup.sane_behavior memory.kmem.tcp.max_usage_in_bytes memory.move_charge_at_immigrate notify_on_release
memory.failcnt memory.kmem.tcp.usage_in_bytes memory.numa_stat release_agent
memory.force_empty memory.kmem.usage_in_bytes memory.oom_control system.slice
memory.kmem.failcnt memory.limit_in_bytes memory.pressure_level tasks
memory.kmem.limit_in_bytes memory.max_usage_in_bytes memory.soft_limit_in_bytes user.slice
memory.kmem.max_usage_in_bytes memory.memsw.failcnt memory.stat

用户可以通过修改这些文件值来控制组限制Docker应用资源。

LXC

通过传统方式使用容器功能的话需要我们自己写代码去进行系统调用来实现创建内核，实际上拥有此能力的人廖廖无几。而LXC（LinuX Container）把容器技术做得更加易用，把需要用到的容器功能做成一组工具，从而极大的简化用户使用容器技术的麻烦程度。

LXC是最早一批真正把完整的容器技术用一组简易使用的工具和模板来极大的简化了容器技术使用的一个方案。

LXC虽然极大的简化了容器技术的使用，但比起直接通过内核调用来使用容器技术，其复杂程度其实并没有多大降低，因为我们必须要学会LXC的一组命令工具，且由于内核的创建都是通过命令来实现的，通过批量命令实现数据迁移并不容易。其隔离性也没有虚拟机那么强大。

后来就出现了docker，所以从一定程度上来说，docker就是LXC的增强版。

docker基本概念

docker是容器技术的一个前端工具，容器是内核的一项技术，docker只是把这一项技术的使用得以简化，使之普及而已。

LXC进行大规模创建容器很难，想在另一台主机上复刻一个一模一样的容器也很难，而docker就是从这方面着手去找解决方案。所以docker早期的版本其核心就是一个LXC，docker对其进行了二次封装，功能的实现是通过LXC做容器管理引擎，但是在创建容器时，不再是像LXC一样用模板去现场安装，而是事先通过一种类似镜像技术，就像在KVM中一样，将一个操作系统打包成一个镜像，然后将这个镜像拷贝到目标主机上直接部署启动。

我们可以尝试着把一个操作系统用户空间需要用到的所有组件，事先准备、编排好，编排好以后整体打包成一个文件，这个文件我们称其为镜像文件（image）。

docker的镜像文件是放在一个集中统一的互联网仓库中的，把一些人们常用的镜像文件放在互联网仓库中，比如最小化的centos系统，有时我们需要在操作系统上安装一些应用，比如nginx，我们就可以在一个最小化的centos系统中安装一个nginx，然后将其打包成镜像，将其放在互联网仓库中，当人们想启动一个容器的时候，docker会到这个互联网仓库中去下载我们需要的镜像到本地，并基于镜像来启动容器。

自docker 0.9版本起，docker除了继续支持LXC外，还开始引入自家的libcontainer，试图打造更通用的底层容器虚拟化库。如今的docker基本上都已经是使用libcontainer而非LXC了。

从操作系统功能上看，docker底层依赖的核心技术主要包括Linux操作系统的命名空间、控制组、联合文件系统和Linux虚拟网络支持。

docker工作方式

为了使容器的使用更加易于管理，docker采取一个用户空间只跑一个业务进程的方式，在一个容器内只运行一个进程，比如我们要在一台主机上安装一个nginx和一个tomcat，那么nginx就运行在nginx的容器中，tomcat运行在tomcat的容器中，二者用容器间的通信逻辑来进行通信。

LXC是把一个容器当一个用户空间使用，当虚拟机一样使用，里面可以运行N个进程，这就使得我们在容器内去管理时极为不便，而docker用这种限制性的方式，在一个容器中只运行一个进程的方式，使得容器的管理更加方便。
在这里插入图片描述

使用docker的优劣：

删除一个容器不会影响其他容器
调试不便，占空间(每个容器中都必须自带调试工具，比如ps命令)
分发容易，真正意义上一次编写到处运行，比java的跨平台更彻底
部署容易，无论底层系统是什么，只要有docker，直接run就可以了
分层构建，联合挂载

在容器中有数据称作有状态，没有数据称作无状态。在容器的使用中，我们应以有状态为耻，以无状态为荣。数据不应该放在容器中，而应放置于外部存储中，通过挂载到容器中从而进行数据的存储。

docker容器编排

当我们要去构建一个lnmp架构的时候，它们之间会有依赖关系，哪个应用应该在什么时候启动，在谁之前或之后启动，这种依赖关系我们应该要事先定义好，最好是按照一定的次序实现，而docker自身没有这个功能，所以我们需要一个在docker的基础上，能够把这种应用程序之间的依赖关系、从属关系、隶属关系等等反映在启动、关闭时的次序和管理逻辑中，这种功能被称为容器编排。

有了docker以后，运维的发布工作必须通过编排工具来实现容器的编排，如果没有编排工具，运维人员想去管理容器其实比直接管理程序要更加麻烦，增加了运维环境管理的复杂度。

常见的容器编排工具：

machine+swarm(把N个docker主机当一个主机来管理)+compose(单机编排)
mesos(实现统一资源调度和分配)+marathon
kubernetes --> k8s

docker基础用法

什么是docker

docker中的容器：

lxc --> libcontainer --> runC

OCI&OCF

OCI(保密中心)

Open Container-initiative( 开放容器倡议)

由Linux基金会主导于2015年6月创立
旨在围绕容器格式和运行时制定一个开放的工业化标准
contains two specifications （包含两种规格）
- the Runtime Specification（runtime-spec）（运行时规范（运行时规范））
- the Image Specification（image-spec）（图像规范（图像规范））

OCF（断续器）

Open Container Format（开放容器格式）

runC 是一个 CLI 工具，用于根据 OCI 规范生成和运行容器

容器作为 runC 的子进程启动，可以嵌入到各种其他系统中，而无需运行守护程序
runC 建立在 libcontainer 之上，同样的容器技术为数百万个 Docker 引擎安装提供支持

docker提供了一个专门容纳容器镜像的站点：https://hub.docker.com

docker架构

在这里插入图片描述

Docker使用了C/S体系架构，Docker客户端与Docker守护进程通信，Docker守护进程负责构建，运行和分发Docker容器。Docker客户端和守护进程使用REST API通过UNIX套接字或网络接口进行通信。

Docker Damon DockerD用来监听Docker API的请求和管理Docker对象，比如镜像、容器、网络和Volume Docker Client docker client是我们和Docker进行交互的最主要的方式方法，比如可以通过docker run来运行一个容器，然后我们的这个client会把命令发送给上面的DockerDocker Registry 用来存储Docker镜像的仓库，Docker Hub是Docker官方提供的一个公共仓库，而且Docker默认也是从Docker Hub上查找镜像的，当然你也可以很方便的运行一个私有仓库，当我们使用docker pull或者docker run命令时，就会从我们配置的Docker镜像仓库中去拉取镜像，使用docker push命令时，会将我们构建的镜像推送到对应的镜像仓库中 Images 镜像，镜像是一个制度模板，带有Docker容器的说明，一般来说的，镜像会基于另外的一些基础镜像上面安装一个Nginx服务器，这样就可以构建一个属于我们自己的镜像了 Containers 容器，容器是一个镜像的可运行的实例，可以使用Docker REST API或者CLI来操作容器，容器的实质是进程，但与直接在宿主执行的实例进程不同，容器进程属于自己的独立的命名空间。因此容器可以拥有自己的root文件系统、自己的网络配置、自己的进程空间、甚至自己的用户ID。容器内的经常是运行在一个隔离的环境里，使用起来，就好像在一个独立于宿主的系统下操作一样。这种特性使得容器封装的应用比直接在宿主运行更加安全

docker镜像与镜像仓库

为什么镜像仓库名字是Registry而不是repository？在docker中仓库的名字是以应用的名称取名的。
在这里插入图片描述

镜像是静态的，而容器是动态的，容器有其生命周期，镜像与容器的关系类似于程序与进程的关系。镜像类似于文件系统中的程序文件，而容器则类似于将一个程序运行起来的状态，也即进程。所以容器是可以删除的，容器被删除后其镜像是不会被删除的。

docker对象

使用 Docker 时，您正在创建和使用映像、容器、网络、卷、插件和其他对象。

图像
- 映像是一个只读模板，其中包含有关创建 docker 容器的说明。
- 通常，一个映像基于另一个映像，并具有一些额外的自定义。
- 您可以创建自己的映像，也可以仅使用其他人创建并在注册表中发布的映像。
器皿
- 控制器是映像的可运行实例。
- 您可以使用 Docker API 或 CLI 创建、运行、停止、移动或删除容器。
- 可以将容器连接到一个或多个网络，将存储附加到该容器，甚至可以基于其当前状态创建新映像。

安装及使用docker

docker安装

[root@localhost ~]# cd /etc/yum.repos.d/
[root@localhost yum.repos.d]# rm -rf *
[root@localhost yum.repos.d]# ls
[root@localhost yum.repos.d]#
[root@localhost yum.repos.d]# wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo
--2022-08-03 18:32:54--  https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo
Resolving mirrors.aliyun.com (mirrors.aliyun.com)... 58.49.248.231, 119.96.138.211, 119.96.138.216, ...
Connecting to mirrors.aliyun.com (mirrors.aliyun.com)|58.49.248.231|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2495 (2.4K) [application/octet-stream]
Saving to: ‘/etc/yum.repos.d/CentOS-Base.repo’

/etc/yum.repos.d/CentOS-Bas 100%[==========================================>]   2.44K  --.-KB/s    in 0s      

2022-08-03 18:32:54 (44.8 MB/s) - ‘/etc/yum.repos.d/CentOS-Base.repo’ saved [2495/2495]

[root@localhost yum.repos.d]# wget  https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
--2022-08-03 18:33:20--  https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
Resolving mirrors.aliyun.com (mirrors.aliyun.com)... 58.49.248.231, 119.96.138.211, 119.96.138.216, ...
Connecting to mirrors.aliyun.com (mirrors.aliyun.com)|58.49.248.231|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2081 (2.0K) [application/octet-stream]
Saving to: ‘docker-ce.repo’

docker-ce.repo              100%[==========================================>]   2.03K  --.-KB/s    in 0s      

2022-08-03 18:33:20 (66.2 MB/s) - ‘docker-ce.repo’ saved [2081/2081]

[root@localhost yum.repos.d]# yum -y install docker-ce
Repository extras is listed more than once in the configuration
CentOS-8.5.2111 - Base - mirrors.aliyun.com                                    3.6 MB/s | 4.6 MB     00:01    
CentOS-8.5.2111 - Extras - mirrors.aliyun.com                                   73 kB/s |  10 kB     00:00
......
Complete!
[root@localhost ~]# systemctl restart docker.service
[root@localhost ~]# systemctl enable docker.service
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service.

docker加速

docker-ce的配置文件是/etc/docker/daemon.json，此文件默认不存在，需要我们手动创建并进行配置，而docker的加速就是通过配置此文件来实现的。

docker的加速有多种方式：

docker cn
中国科技大学加速器
阿里云加速器（需要通过阿里云开发者平台注册帐号，免费使用个人私有的加速器）

[root@localhost ~]# mkdir -p /etc/docker
[root@localhost ~]# tee /etc/docker/daemon.json <<-'EOF'
> {
>    "registry-mirrors": ["https://cj9sucfo.mirror.aliyuncs.com"]
>  }
> EOF
{
   "registry-mirrors": ["https://cj9sucfo.mirror.aliyuncs.com"]
 }
[root@localhost ~]# systemctl daemon-reload
[root@localhost ~]# systemctl restart docker
[root@localhost ~]# docker version
Client: Docker Engine - Community
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:03:11 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:29 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.2
  GitCommit:        v1.1.2-0-ga916309
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
  
[root@localhost ~]# docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc version: v1.1.2-0-ga916309
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.18.0-257.el8.x86_64
 Operating System: CentOS Stream 8
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 1.748GiB
 Name: localhost.localdomain
 ID: 76JM:UBMZ:Q5UE:NONU:ZV43:ZTFB:HADV:QRCJ:KCNN:C6V3:QAQB:CVQ3
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Registry Mirrors:
  https://cj9sucfo.mirror.aliyuncs.com/
 Live Restore Enabled: false