Docker容器 虚拟化技术
Docker容器
1、容器化技术的由来
虚拟化技术发展已经非常强大了，那为什么还需要容器化技术呢？
如今的虚拟机解决了基础设计计算，网络，存储着几个方面的弹性，可以非常方便的扩展出应用的资源，但是仍然存在两个问题。
- 应用扩展问题： 拿双十一举例，应用在平常只需要10台机器，但是在双十一那天可能至少需要准备100台机器，就需要在非常短时间内快速完成部署应用
- 环境迁移： 应用开发过程包含了开发–》测试—》预发布—》线上等不同的环境，如何确保每套环境的一致性，这需要投入大量的人力成本，且经常出现因环境差异导致的问题
在云计算的时代，通常通过自动化脚本的方式解决上面的问题，但是环境差异，导致脚本维护要投入额外的人力，也有团队使用虚拟化镜像，但是镜像大且启动慢，没法满足时效性的要求。
于是，我们来看是否存在一种更加轻巧的虚拟化技术，更容易迁移和扩展应用层业务。-----------集装箱
正式借鉴了集装箱的解决方案，就有人提出了类似集装箱的方式应用以及他的运行环境，将应用和环境打包成一个轻量化，可移植，自包含的容器。
容器化技术的优势
更高效的系统资源利用率
相比虚拟化技术，不需要额外的hypervisor层，会有更高的心梗和效率，单台高配物理机可以跑上千个docker容器
启动非常快，秒级时间
这是由于直接运行与宿主机内核，需要启动完成的操作系统，因为可以做到秒级，升值毫秒级的启动时间
一致的运行环境
容器的镜像封装应用和应用依赖的环境，确保了应用环境的一致性，避免了开发环境、测试环境、生产环境不一致的问题
持续交付和部署
一次创建和配置之后，可以在任意地方运行，测试人员可以将容器与持续集成系统结合，在pipeline中自动化的完成集成测试，同时运维人员可以通过持续部署系统对应用自动完成部署
更易于迁移
不管你现在运行在哪里，都可以轻松迁移到物理机，虚拟机，公有云，私有云中，且不需要担心运行环境变化导致应用运行的问题
局限性
- 容器隔离性问题，也可是安全性问题，主要是由于共用内核和Namespace（命名空间）实现隔离的限制
- 容器里面不存放数据，容器中的数据会随容器消失而消失，特别是对有状态的应用需要做数据的持久化设置
- 容器的粒度更细，管理复杂度更大，在生产环境管理大量的容器带来了更大的跳转，依赖于KS8、Swarm等容器编排
2、什么是Docker
- Docker是一个开源的应用容器引擎，基于go语言开发并遵循apache2.0协议开源
- Docker是在linux容器里运行的开源工具，是一种轻量的虚拟机
- Docker的容器技术可以在一台主机上轻松为任何应用创建一个轻量级的、可移植的、自给自足的容器
- 目前Docker只能支持64位系统
总结
容器：提供在多台主机上运行程序相同的运行环境
docker容器可以看做运行在宿主机上的一个进程,容器共享宿主机的内核,容器间是通过namespace(命令空间)隔离资源,通过cgroups(资源配额)去限制资源。
3、Docker的设计宗旨
Docker 的Logo设计为蓝色鲸鱼，拖着许多集装箱，鲸鱼可以看作为宿主机，集装箱可以理解为相互隔离的容器，每个集装箱中都包含自己的应用程序
Docker的设计宗旨：Build、Ship and Run Any APP ，Anywhere
即通过对应用组件的封装，发布、部署、运行等生命周期的管理，达到应用组件级别的 一次封装，到处运行的 目的。这里的组件，既可以是一个应用，也可以是一套服务，甚至是一个完整的操作系统
4、Docker的优点
灵活： 即使是复杂的应用也可以集装箱化
轻量级： 容器利用并共享主机内核
可互换： 可以及时部署更新和升级
便捷式： 可以在本机构建，部署到云，并在任何地方运行
可扩展： 可以增加并自动分发容器副本
可堆叠： 可以垂直和及时堆叠服务
docker 和vm，解决了虚拟机的什么问题？
docker解决了vm的一个环境孤岛问题
docker可以自定义传参，（创建–创建镜像/容器，启动（基于镜像启动）之前）
5、Docker容器和虚拟机的区别
5.1 隔离和共享
虚拟机通过Hypervisor层（虚拟化中间层），虚拟出网卡，内存，cpu等虚拟硬件，再在其上建立虚拟机，每个虚拟机都有自己的系统内核
Dcoker容器则是通过隔离（namesapce）的方式，将文件系统、进程、设备、网络等资源进行隔离，再对权限，cpu资源等进行控制（cgroup），最终让容器之间互不影响，容器无法影响宿主机
容器与宿主机共享内核、文件系统，硬件等资源
5.2 性能与损耗
- 与虚拟机相比，容器资源损耗要小
- 同样的宿主机下，能够建立容器的数量要比虚拟机多
- 但是，虚拟机的安全性要比容器稍好，要从虚拟机攻破到宿主机或其它虚拟机，需要先攻破Hypervisor层，这是极其困难的
- 而Docker容器与宿主机共享概念股内核，文件系统等资源，更有可能对其它容器、宿主机产生影响
| 特性（不同点） | Docker容器 | 虚拟机 |
|---|---|---|
| 部署难度 | 非常简单 | 组件多，部署复杂 |
| 启动速度 | 秒级 | 分钟级 |
| 执行性能 | 和物理系统一致（共享内核） | VM会占用部分资源（50%损耗） |
| 镜像体积（磁盘占用） | MB级别 | GB级别 |
| 管理效率 | 简单 | 各组件相互依赖，管理复杂 |
| 可管理性 | 单进程 | 完整的系统管理 |
| 网络连接 | 弱 | 借助neutron可以灵活组件各类网络管理 |
| 系统支持量（单机） | 上千个 | 几十个 |
| 隔离性 | 进程级别 | 系统级别 |
| 封装程度 | 直达包项目代码和依赖关系，共享宿主机内核 | 完整的操作系统，与宿主机隔离 |
6、 namespace的隔离（命名空间）
Docker本质就是宿主机的一个进程，docker是通过namespace实现资源隔离，通过cgroup实现资源限制，通过写时复制技术copy-on-write实现了高效的文件操作。（类似于虚拟机的磁盘，比如分配了500G并不是实际占用物理磁盘500G）
| namespace | 系统调用参数 | 隔离内容（判断两个环境是否完全隔离） |
|---|---|---|
| utc | CLONE_NEWUTS | 主机名与域名（同一个环境里不能叫node1又叫node2） |
| ipc | CLONE_NEWWIPC | 信号量、消息队列和共享内存（不同的应用调用内存资源的时候应该使用不同的内存空间） |
| pid | CLONE_NEWPID | 进程编号 |
| network | CLONE_NEWNET | 网络设备、网格栈、端口等 |
| mount | CLONE_NEWNS | 挂载点（文件系统，不能重复挂载一个指定目录） |
| user | CLONE_NEWUSER | 用户和组（3.8以后的内核才支持） |
7、控制组（Control groups）
六种名称空间是由cgroup管理的
最后一种centos的cgroup管理版本是3.8版本，3.6和3.5用不了
- cgroup管理linux内核态中资源管理的模块
- cgroup管理一些系统资源
- 不是docker原生的
8、 Docker的三个核心概念
8.1 镜像
- Docker的镜像是创建容器基础， 类似虚拟机的快照，可以理解为一个面向Docker容器的引擎的只读模板
- 通过镜像启动一个容器，一个镜像是一个可执行的包，其中包括运行程序所需要的所有内容，包含代码、运行时间、库、环境变量和配置文件
- Docker镜像也是一个压缩包，只是这个压缩包不只是可执行文件，环境部署脚本，它还包含了完整的操作系统。因为大部分的镜像都是基于某个操作系统来构建的，所有很轻松的就可以构建本地和远程一样的环境，这也是docker镜像的精髓
8.2 容器
- Docker的容器创建的运行实例，它可以被启动、停止、和删除，所创建的每一个容器都是相互隔离，互不可见的，以保证平台的安全性
- 可以把容器看做一个简易版linux环境（包括root用户权限，镜像空间、用户空间和网络空间）和运行在其它的应用程序
8.3 仓库（Docker Hapu）
公共仓库：docker hub
私有仓库：harhor
- Docker仓库是用来集中保存镜像的地方，当创建了自己的镜像之后，可以使用push命令将它上传到公有仓库或私有仓库，当下次要在另外一台机器上使用这个镜像时，只需要从仓库获取
- Docker的镜像、容器、日志等全部内容都默认存储在/var/lib/docker目录下
9、 Docker Engine（引擎）
Dcoker Engine 是具有以下主要组件“客户端-服务端（C/S架构）”的应用程序
- server端： 服务器时一种长期运行的程序，称为守护进程（dockerd命令）
- client端： REST API，它指定程序可以用来与守护程序进行通信并指示其操作的接口。
- 命令行界面（cli）客户端（docker命令）
- 执行命令的是客户端、执行操作的服务端
10、 Docker运行流程
- 客户端发起各种命令到服务端的守护进程。
- 服务端的守护进程会调用镜像，如果本地存在，直接使用，运行为容器，如果本地没有，从仓库拉取镜像到本机再运行为容器
11、使用docker有什么意义
- docker 引擎 统一基础设施环境-docker容器环境（引擎）
- docker 引擎统一了程序打包（装箱）方式-docker镜像
- docker 引擎统一了程序部署（运行）方式-docker容器
- 镜像------》封装的某一个时刻的服务/应用状态
- 容器-----》应用跑起来的状态（正常提供服务的状态----运行时）
12、Docker的使用场景
- 打包应用程序部署简单
- 可脱离底层硬件任意迁移（实现了应用的隔离，将应用拆分并进行解耦）
例如：需要把服务器从腾讯云迁移到阿里云，如果采用的是docker容器技术，整个迁移的过程只需要在新的服务器上启动我们需要的容器上就可以了
- 适合做微服务的部署
- 适合持续集成和持续交付（CI/CD）：开发到测试到发布
基础了解
IAAS： 基础设施服务，（只提供基础设施，没有系统）
**SAAS： ** 软件即服务，（提供基础设施和系统）
PAAS： 平台即服务，（提供基础设施和系统和软件一个整体平台，拿来用就行）
DAAS： 数据库的平台，（收集大量数据，提供分析）开发的具体开发流程
获取项目需求---->分布开发------>测试（测试类型：运行测试、功能性测试、单元测试、回归测试、冒烟测试）----->线上运维。
一、虚拟化技术
1、虚拟化技术的由来
在早期的时候，我们想在线上部署一个应用，我们需要先购买服务器，然后安装操作系统以及各种依赖环境，最后进行应用的部署。
这种情况非常的麻烦......
- 部署应用上线的应用过程时间非常长
- 购买服务器的价格高昂
- 物理服务器的资源容易浪费
- 迁移和扩展比较困难
出现了以上问题后，后面就有人提出了 虚拟化技术。
虚拟化技术就是在操作系统上多加了一个虚拟化层（Hypervisor），可以将物理的CPU，内存，硬盘等资源进行虚拟化，再通过虚拟化出来的空间上安装操作系统，这就是我们通常说的虚拟机
比如：我们将一台32核CPU，64G内存、500磁盘的物理机进行虚拟化，可以创建8台4核CPU、8G内存的虚拟机安装任意的操作系统，这些机器提供给不同的应用去部署，如此提供了资源的利用率，常见的虚拟化技术有：VMWare、KVM、VirtualBox等。
虚拟化技术的优点
- 提升IT效率
- 降低运维成本
- 更快的部署工作
- 提高应用性能
- 提高服务器的可用性
- 消除服务器梳理剧增情况和复杂性
2、CPU的时间分片（CPU虚拟化）
Cpu分片前
正常每个人物以轮询的方式去处理，这时候一个CPU一个整体
CPU分片后
按时间划分，将1秒分成10个0.1秒，每个0.1秒可以全力处理10个任务。
虚拟化的作用：缓解/解决了资源利用率的问题。
3、 cpu 虚拟化性能瓶颈
cpu分片后每个任务处理性能会打折
如果是50M或50M以下的任务，虚拟化后，1s模拟成10个CPU，可以处理10个，虚拟化的性能更高。
如果是50M以上的任务，物理硬件的性能就会比虚拟化的性能该了，因为虚拟化会卡顿，它需要周期性去执行这个任务，消耗的时间也较久。
所以。在极度吃资源的情况系，例如mysql高并发这种，就不适合虚拟化了。
4、虚拟化的工作原理
逻辑分割系统物理资源抽象为可调用的虚拟化资源（KVM：逻辑分割的模块）
hypervisor虚拟资源管理器通过QEMU（I/O控制模块）使用接口与接的方式调用物理资源
然后hypervisor把调用的虚拟资源给到虚拟机
4.1 QEMU
- QEMU是I/O控制模块，可以理解成队列， 核心目的是调用资源内核中的资源 ，需要把KVM逻辑分割出来的有资源运输给QEMU，再个虚拟机
- QEMU它并不是直接调用，而是用I/O方式调用，QEMU把资源用来的过程借用ioctl（运输的作用），QEMU借助libvirt这个工具调用ioctl，再通过接口，给虚拟机程序
4.2 KVM
- 用来逻辑分割物理资源，抽象化为虚拟化资源，根据KVM里的配置，会逻辑分割出多少个G，给应用程序，并进行虚拟化
- 只接受来自QEMU的请求指令，对于应用程序直接归来的指令会拦截，然后通过接口发给QEMU，让QEMU判断是否需要执行，可以的话，再发给KVM，不可的话，返回。不执行该敏感指令
对于workstation而言——》硬件辅助虚拟化，表现形式在处理器里面有一个虚拟化引擎，可以勾取硬件辅助虚拟化，看到虚拟接口/dev/kvm，可以加强辅助调用，在应用程序需要频繁调用的时候，需要开启。比如openstack
4.3 虚拟化的类型
全虚拟化（寄居架构）：**将物理硬件资源全部通过软件的方式抽象化，最后进行调用
KVM----》产品vmware
半虚拟化（裸金属架构）：**裸金属虚拟化，需要修改操作系统
ESXI—>workstation、vsphere、xen
直通：直接使用物理硬件资源（需要支持，还不完善
其它容器Podman
Podman与Docker主要区别
docker在运行容器的时候，需要一个守护进程。其次需要root运行
podman不需要守护进程。也不需要root用户运行
docker需要多个daemon才能调用OCI实现运行
podman直接调用OCI，通过common做为容器的管理工具
在podman体系中，有个称之为common的守护进程，其运行路径通常是/usr/libexec/podman/conmon，它是各个容器进程的父进程，每个容器各有一个，common的父则通常是1号进程。podman中的common其实相当于docker体系中的containerd-shim