[系统运维]docker容器介绍

传统虚拟化与容器的区别

虚拟化分为以下两类：

• 主机级虚拟化
  • 全虚拟化
  • 半虚拟化
• 容器级虚拟化

容器分离开的资源：

• UTS(主机名与域名)
• Mount(文件系统挂载树)
• IPC
• PID进程树
• User
• Network(tcp/ip协议栈)

Linux容器技术

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

Linux Namespaces

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

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

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警告
• 优先级（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 Containers的缩写方式，是一种运行system-level虚拟化方法，用于运行多个隔离的Linux系统，这些系统在单个控制主机上称为容器。由于LXC提供运行system-level虚拟化，它不是通过一个完整的虚拟机，而是它提供了自己的虚拟环境，它有自己的进程和网络空间。

LXC依赖于Linux内核cgroups(Control Groups)，它是作为LXC的一部分开发的，它是限制，计算和隔离进程组的资源使用(CPU，内存，磁盘I /O等)的功能。它还依赖于其他类型的namespace-isolation功能，这些功能是在主线Linux内核中开发和集成的。

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

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

什么是docker

docker是一个用Go语言实现的开源项目，可以让我们方便的创建和使用容器，docker将程序以及程序所有的依赖都打包到docker container，这样你的程序可以在任何环境都会有一致的表现，这里程序运行的依赖也就是容器就好比集装箱，容器所处的操作系统环境就好比货船或港口，程序的表现只和集装箱有关系(容器)，和集装箱放在哪个货船或者哪个港口(操作系统)没有关系。

因此我们可以看到docker可以屏蔽环境差异，也就是说，只要你的程序打包到了docker中，那么无论运行在什么环境下程序的行为都是一致的，程序员再也无法施展表演才华了，不会再有“在我的环境上可以运行”，真正实现“build once, run everywhere”。

此外docker的另一个好处就是快速部署，这是当前互联网公司最常见的一个应用场景，一个原因在于容器启动速度非常快，另一个原因在于只要确保一个容器中的程序正确运行，那么你就能确信无论在生产环境部署多少都能正确运行。官方网站

如何使用docker

docker中有这样几个概念：

• dockerfile
• image
• container

实际上你可以简单的把image理解为可执行程序，container就是运行起来的进程。

那么写程序需要源代码，那么“写”image就需要dockerfile，dockerfile就是image的源代码，docker就是"编译器"。

因此我们只需要在dockerfile中指定需要哪些程序、依赖什么样的配置，之后把dockerfile交给“编译器”docker进行“编译”，也就是docker build命令，生成的可执行程序就是image，之后就可以运行这个image了，这就是docker run命令，image运行起来后就是docker container。

具体的使用方法就不再这里赘述了，大家可以参考docker的官方文档，那里有详细的讲解。

docker是如何工作的

实际上docker使用了常见的CS架构，也就是client-server模式，docker client负责处理用户输入的各种命令，比如docker build、docker run，真正工作的其实是server，也就是docker demon，值得注意的是，docker client和docker demon可以运行在同一台机器上。

接下来我们用几个命令来讲解一下docker的工作流程：

1，docker build

当我们写完dockerfile交给docker“编译”时使用这个命令，那么client在接收到请求后转发给docker daemon，接着docker daemon根据dockerfile创建出“可执行程序”image。

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

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

2，docker run

有了“可执行程序”image后就可以运行程序了，接下来使用命令docker run，docker daemon接收到该命令后找到具体的image，然后加载到内存开始执行，image执行起来就是所谓的container。

3，docker pull

其实docker build和docker run是两个最核心的命令，会用这两个命令基本上docker就可以用起来了，剩下的就是一些补充。

那么docker pull是什么意思呢？

我们之前说过，docker中image的概念就类似于“可执行程序”，我们可以从哪里下载到别人写好的应用程序呢？很简单，那就是APP Store，即应用商店。与之类似，既然image也是一种“可执行程序”，那么有没有"Docker Image Store"呢？答案是肯定的，这就是Docker Hub，docker官方的“应用商店”，你可以在这里下载到别人编写好的image，这样你就不用自己编写dockerfile了。

docker registry 可以用来存放各种image，公共的可以供任何人下载image的仓库就是docker Hub。那么该怎么从Docker Hub中下载image呢，就是这里的docker pull命令了。

因此，这个命令的实现也很简单，那就是用户通过docker client发送命令，docker daemon接收到命令后向docker registry发送image下载请求，下载后存放在本地，这样我们就可以使用image了。

docker产生的背景

? 一款产品从开发到上线，从操作系统，到运行环境，再到应用配置。作为开发+运维之间的协作 我们需要关心很多东西，这也是很多互联网公司不得不面对的问题，特别是各种版本的迭代之后，不同版本环境的兼容，对运维人员是考验。Docker之所以发展如此迅速，也是因为他对此给出了一个标准化的解决方案。

? 环境配置如此麻烦，换一台机器，就要重来一次，费力费时。很多人想到，能不能从根本上解决问题，软件可以带安装环境？也就是说，安装的时候，把原始环境一模一样的复制过来。让开发人员利用Docker可以消除协作编码是“在我的机器上可正常工作”的问题。之前在服务器配置一个应用的运行环境，要安装各种软件，JAVA//TOMCAT/MYSQL等。安装和配置这些东西有多麻烦就不说了，它还不能跨平台。假如我们是在windonws上安装的这些环境，到了Linux又要重新安装。况且就算不夸操作系统，换另一台同样操作系统的服务器，要移植应用也是非常麻烦的。乱码是“在我的机器上可正常工作”的问题。之前在服务器配置一个应用的运行环境，要安装各种软件，JAVA//TOMCAT/MYSQL等。安装和配置这些东西有多麻烦就不说了，它还不能跨平台。假如我们是在windonws上安装的这些环境，到了Linux又要重新安装。况且就算不夸操作系统，换另一台同样操作系统的服务器，要移植应用也是非常麻烦的。

传统上认为，软件棉麻开发、测试结束后所产出的成果即使是程序或者是能够编译执行的二进制字节码等（java为例）。而为了让这些程序可以顺利执行，开发团队也得准备完整的部署文件，让运维团队得以部署应用程序，开发需要清楚的告诉运维部署团队，用的全部配置文件+所有软件环境。不过，即便如此，仍然常常发行部署失败的状况。

Docker镜像的设计，使得Docker得以打破过去[程序即应用]的观念。透过镜像（images）将作业系统核心除外，运作应用程序所需要的系统环境，有下而上打包，达到应用程序式跨平台之间的无缝接轨运作。

docker容器编排

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

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

常见的容器编排工具：

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