英语网站案例,深圳网站建设厂家,wordpress 模板框架,申请学校网站建设申请书一、简介 docker容器技术从2013年开始火了以后#xff0c;2014年左右当时有幸在学校能和学院教授一起做些项目以及学习。其中docker技术在当时来说还算是比较新的技术#xff0c;国内关于这块的资料以及使用也才刚刚开始#xff0c;讨论docker技术#xff0c;算是相对时髦的…一、简介 docker容器技术从2013年开始火了以后2014年左右当时有幸在学校能和学院教授一起做些项目以及学习。其中docker技术在当时来说还算是比较新的技术国内关于这块的资料以及使用也才刚刚开始讨论docker技术算是相对时髦的话题。 现在回头望去已经10年有余很佩服当时带领我们学习新技术的教授导师看到这个技术的前景所以接触的相对早对后面我的工作起到了相当大的帮助。当时我还写了一篇关于如何通俗理解docker的博客文章也得到了大多数朋友的支持和点赞~。 附上原文地址入门的同学可以看下。 原文链接: docker通俗理解 Docker并没有创造了什么新的技术所有用到的技术都是已经存在的 docker将这些技术进行了很好地组合与融汇 降低了开发者使用容器技术的门槛。 核心来讲, Docker使用了: 1、Linux 提供的namespace隔离技术(解决了进程视野隔离问题 进程之间互不影响达到隔离的目的) 2、Linux提供的cgroups资源限制技术(可以针对进程进行资源限制) 还未入门和使用过Docker的同学建议熟练使用docker后再回头看这篇文章要不然效果适得其反~ 本章针对namespace做个剖析 看下背后实现的基本原理。
二、Namespace隔离技术
1、为什么需要Namespace隔离技术? Docker本质上是一种虚拟化技术属于进程级别的虚拟化。 既然是进程级别的虚拟化那就是运行在不同容器的进程彼此之间资源以及视野(进程所处上下文环境)是不同的。 例如我在A容器运行一个p1进程 同时在B容器运行一个p2进程 此时分别在A和B容器运行 ps aux 看到的内容是不一样的。 如果没有namespace技术做隔离那么我们运行的这些进程彼此之间可以感知看到的视野也是一样的那就无法做到隔离的效果。
2、Namespace隔离进程的本质 运行容器以后, 需要运行一个”主进程”, 这个进程本质上和宿主机的其他进程没太多差别 只是这个进程看到的“视野”被namespace框住了只看到自己namespace里面的东西看不到宿主机上的东西(因为例如在容器和宿主机执行 ls、ifconfig命令两者命令所处的mount namespace、net namespace不同所以看到的内容自然不同)。 简单理解 Linux的某种namespace例如在【视觉】上 类似给某个人带了VR眼镜 VR眼镜可以将人的视野框起来现实中你是在床上睡觉(房间就是宿主机) 但是你为了玩游戏感觉更加逼真 带上VR眼镜眼镜的视野就可以身临其境。 但是只有【视觉】身临其境好像还差点意思此时再给你的【触觉】带上MR混合虚拟设备这时候就有了模拟触觉体验会更棒这又是附加了另外一种namespace隔离。
3、Linux提供了哪些类型的Namespace 为了让被虚拟的进程更加身临其境 Linux内核提供了6种namespace隔离类型与系统调用: 例如主机和域名隔离、信号量隔离、进程PID隔离、网络隔离、挂载隔离、用户信息隔离等。给你的进程套上虚拟设备 这样你的进程看到的视野和其他进程的视野就不一样。 我们运行了一个简单的docker容器,我们可以查看到 这个命令虽然在Docker容器内运行 但是宿主机对应路径/proc/$pid/ns中就被分配了各种namespace: 两个进程所处的nemspace不同也就意味着这两个进程看到的“视野”不同这个概念很重要. 那反过来讲如果我们要2个进程可以看到相同“视野”那么有没有某种机制让一个进程共享或者切换自己的namespace到目标进程的namespace呢? 这样原进程就可以看到和目标进程一样的“视野”了. 答案是存在的 Linux中存在一个系统调用函数 setns 可以通过系统调用让某个原进程的namespace切换为目标进程的namespace . 其实docker exec -it /bin/sh 进入一个容器本质上就是docker cli运行命令 内部调用setns系统调用(system call) 指定 目标进程id namespace路径: /proc/$pid/ns/ 下的namepscae和要执行的命令/bin/sh传递进去. 这样这个docker cli就能和目标容器看到的“视野”是一样的.
4、验证docker exec /bin/sh/bin/sh的namespace和容器进程tail 的 namespace是否一致
1、运行一个busybox的容器 主进程是 tail -f /dev/null 2、宿主机ps aux | grep ‘tail’ 看下这个容器启动进程在宿主机的实际pid是多少?
拿到实际进程PID: 29493 3.此时我们进入/proc/29493/ns/, 查看下namespace的信息先做下记录后续用到. 4.docker-compose exec bb /bin/sh运行进入容器此时查看宿主机真实进程pid信息: 10325是docker-compose 子进程是docker cli(10333), 最后, /bin/sh进程pid应该是10372.
5. 查看下/proc/10372/ns的namespace内容, 经过和步骤3的图(容器tail真实进程pid下的ns目录内容)对比,完全一致. 此时通过docker-compose exec bb /bin/sh进入容器后例如执行ps aux,那么看到的“视野”和容器内部进程的“视野”是一样的就达到了进入容器查看的目的. 容器内执行ps axu
