精华内容
下载资源
问答
  • 容器平台技术包括容器编排引擎、容器管理平台和基于容器的 PaaS。 容器支持技术包括多主机管理、跨主机网络方案、监控和日志管理。 掌握了这三部分知识,就打下了在工作中应用容器的坚实基础。 前面...

    容器我们已经学了大半年,先回顾一下容器生态系统:

    容器生态系统包含三个部分:

    1. 容器核心知识,包括架构、镜像、容器、网络和存储。

    2. 容器平台技术,包括容器编排引擎、容器管理平台和基于容器的 PaaS。

    3. 容器支持技术,包括多主机管理、跨主机网络方案、监控和日志管理。


    掌握了这三部分知识,就打下了在工作中应用容器的坚实基础。

    前面我们已经完成了第1和第3部分,接下来将开始学习平台技术。

    容器编排引擎、容器管理平台和基于容器的 PaaS 在大规模生产部署中占有相当重要的位置。其中容器编排引擎是核心,而最重要的编排引擎则是 Kubernetes,这当然也是这个教程的重中之重。

    下面是本教程的推荐使用方法:

    1. 跟着教程进行操作,在实践中掌握核心技能。

    2. 在之后的工作中,可将本教程作为参考资料,按需查找相关知识点。


    CloudMan 将继续与大家一起实现和提升自我价值。

    下一节我们将从 Docker Swarm 开始。

    书籍:

    1.《每天5分钟玩转Docker容器技术》
    https://item.jd.com/16936307278.html

    2.《每天5分钟玩转OpenStack》
    https://item.jd.com/12086376.html

    展开全文
  • 美团容器平台架构及容器技术实践

    千次阅读 2018-11-16 10:54:09
    本文根据美团基础架构部/容器研发中心技术总监欧阳坚在2018 QCon(全球软件开发大会)上的演讲内容整理而成。 背景 美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”,它的这个特性和...

    本文根据美团基础架构部/容器研发中心技术总监欧阳坚在2018 QCon(全球软件开发大会)上的演讲内容整理而成。

    背景

    美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”,它的这个特性和容器的“弹性伸缩”很像,所以我们给这个平台起名为HULK。貌似有一些公司的容器平台也叫这个名字,纯属巧合。

    2016年,美团开始使用容器,当时美团已经具备一定的规模,在使用容器之前就已经存在的各种系统,包括CMDB、服务治理、监控告警、发布平台等等。我们在探索容器技术时,很难放弃原有的资产。所以容器化的第一步,就是打通容器的生命周期和这些平台的交互,例如容器的申请/创建、删除/释放、发布、迁移等等。然后我们又验证了容器的可行性,证实容器可以作为线上核心业务的运行环境。

    2018年,经过两年的运营和实践探索,我们对容器平台进行了一次升级,这就是容器集群管理平台HULK 2.0。

    • 把基于OpenStack的调度系统升级成容器编排领域的事实标准Kubernetes(以后简称K8s)。
    • 提供了更丰富可靠的容器弹性策略。
    • 针对之前在基础系统上碰到的一些问题,进行了优化和打磨。

    美团的容器使用状况是:目前线上业务已经超过3000个服务,容器实例数超过30000个,很多大并发、低延时要求的核心链路服务,已经稳定地运行在HULK之上。本文主要介绍我们在容器技术上的一些实践,属于基础系统优化和打磨。

    美团容器平台的基本架构

    首先介绍一下美团容器平台的基础架构,相信各家的容器平台架构大体都差不多。

    首先,容器平台对外对接服务治理、发布平台、CMDB、监控告警等等系统。通过和这些系统打通,容器实现了和虚拟机基本一致的使用体验。研发人员在使用容器时,可以和使用VM一样,不需要改变原来的使用习惯。

    此外,容器提供弹性扩容能力,能根据一定的弹性策略动态增加和减少服务的容器节点数,从而动态地调整服务处理能力。这里还有个特殊的模块——“服务画像”,它的主要功能是通过对服务容器实例运行指标的搜集和统计,更好的完成调度容器、优化资源分配。比如可以根据某服务的容器实例的CPU、内存、IO等使用情况,来分辨这个服务属于计算密集型还是IO密集型服务,在调度时尽量把互补的容器放在一起。再比如,我们可以知道某个服务的每个容器实例在运行时会有大概500个进程,我们就会在创建容器时,给该容器加上一个合理的进程数限制(比如最大1000个进程),从而避免容器在出现问题时,占用过多的系统资源。如果这个服务的容器在运行时,突然申请创建20000个进程,我们有理由相信是业务容器遇到了Bug,通过之前的资源约束对容器进行限制,并发出告警,通知业务及时进行处理。

    往下一层是“容器编排”和“镜像管理”。容器编排解决容器动态实例的问题,包括容器何时被创建、创建到哪个位置、何时被删除等等。镜像管理解决容器静态实例的问题,包括容器镜像应该如何构建、如何分发、分发的位置等等。

    最下层是我们的容器运行时,美团使用主流的Linux+Docker容器方案,HULK Agent是我们在服务器上的管理代理程序。

    把前面的“容器运行时”具体展开,可以看到这张架构图,按照从下到上的顺序介绍:

    • 最下层是CPU、内存、磁盘、网络这些基础物理资源。
    • 往上一层,我们使用的是CentOS7作为宿主机操作系统,Linux内核的版本是3.10。我们在CentOS发行版默认内核的基础上,加入一些美团为容器场景研发的新特性,同时为高并发、低延时的服务型业务做了一些内核参数的优化。
    • 再往上一层,我们使用的是CentOS发行版里自带的Docker,当前的版本是1.13,同样,加入了一些我们自己的特性和增强。HULK Agent是我们自己开发的主机管理Agent,在宿主机上管理Agent。Falcon Agent同时存在于宿主机和容器内部,它的作用是收集宿主机和容器的各种基础监控指标,上报给后台和监控平台。
    • 最上一层是容器本身。我们现在主要支持CentOS 6和CentOS 7两种容器。在CentOS 6中有一个container init进程,它是我们开发容器内部的1号进程,作用是初始化容器和拉起业务进程。在CentOS 7中,我们使用了系统自带的systemd作为容器中的1号进程。我们的容器支持各种主流编程语言,包括Java、Python、Node.js、C/C++等等。在语言层之上是各种代理服务,包括服务治理的Agent、日志Agent、加密Agent等等。同时,我们的容器也支持美团内部的一些业务环境,例如set信息、泳道信息等,配合服务治理体系,可以实现服务调用的智能路由。

    美团主要使用了CentOS系列的开源组件,因为我们认为Red Hat有很强的开源技术实力,比起直接使用开源社区的版本,我们希望Red Hat的开源版本能够帮助解决大部分的系统问题。我们也发现,即使部署了CentOS的开源组件,仍然有可能会碰到社区和Red Hat没有解决的问题。从某种程度上也说明,国内大型互联公司在技术应用的场景、规模、复杂度层面已经达到了世界领先的水平,所以才会先于社区、先于Red Hat的客户遇到这些问题。

    容器遇到的一些问题

    在容器技术本身,我们主要遇到了4个问题:隔离、稳定性、性能和推广。

    • 隔离包含两个层面:第一个问题是,容器能不能正确认识自身资源配置;第二个问题是,运行在同一台服务器上的容器会不会互相影响。比如某一台容器的IO很高,就会导致同主机上的其他容器服务延时增加。
    • 稳定性:这是指在高压力、大规模、长时间运行以后,系统功能可能会出现不稳定的问题,比如容器无法创建、删除,因为软件问题发生卡死、宕机等问题。
    • 性能:在虚拟化技术和容器技术比较时,大家普遍都认为容器的执行效率会更高,但是在实践中,我们遇到了一些特例:同样的代码在同样配置的容器上,服务的吞吐量、响应时延反而不如虚拟机。
    • 推广:当我们把前面几个问题基本上都解决以后,仍然可能会碰到业务不愿意使用容器的情况,其中原因一部分是技术因素,例如容器接入难易程度、周边工具、生态等都会影响使用容器的成本。推广也不是一个纯技术问题,跟公司内部的业务发展阶段、技术文化、组织设置和KPI等因素都密切相关。

    容器的实现

    容器本质上是把系统中为同一个业务目标服务的相关进程合成一组,放在一个叫做namespace的空间中,同一个namespace中的进程能够互相通信,但看不见其他namespace中的进程。每个namespace可以拥有自己独立的主机名、进程ID系统、IPC、网络、文件系统、用户等等资源。在某种程度上,实现了一个简单的虚拟:让一个主机上可以同时运行多个互不感知的系统。

    此外,为了限制namespace对物理资源的使用,对进程能使用的CPU、内存等资源需要做一定的限制。这就是Cgroup技术,Cgroup是Control group的意思。比如我们常说的4c4g的容器,实际上是限制这个容器namespace中所用的进程,最多能够使用4核的计算资源和4GB的内存。

    简而言之,Linux内核提供namespace完成隔离,Cgroup完成资源限制。namespace+Cgroup构成了容器的底层技术(rootfs是容器文件系统层技术)。

    美团的解法、改进和优化

    隔离

    之前一直和虚拟机打交道,但直到用上容器,才发现在容器里面看到的CPU、Memory的信息都是服务器主机的信息,而不是容器自身的配置信息。直到现在,社区版的容器还是这样,比如一个4c4g的容器,在容器内部可以看到有40颗CPU、196GB内存的资源,这些资源其实是容器所在宿主机的信息。这给人的感觉,就像是容器的“自我膨胀”,觉得自己能力很强,但实际上并没有,还会带来很多问题。

    上图是一个内存信息隔离的例子。获取系统内存信息时,社区Linux无论在主机上还是在容器中,内核都是统一返回主机的内存信息,如果容器内的应用,按照它发现的宿主机内存来进行配置的话,实际资源是远远不够的,导致的结果就是:系统很快会发生OOM异常。

    我们做的隔离工作,是在容器中获取内存信息时,内核根据容器的Cgroup信息,返回容器的内存信息(类似LXCFS的工作)。

    CPU信息隔离的实现和内存的类似,不再赘述,这里举一个CPU数目影响应用性能例子。

    大家都知道,JVM GC(垃圾对象回收)对Java程序执行性能有一定的影响。默认的JVM使用公式“ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)” 来计算做并行GC的线程数,其中ncpus是JVM发现的系统CPU个数。一旦容器中JVM发现了宿主机的CPU个数(通常比容器实际CPU限制多很多),这就会导致JVM启动过多的GC线程,直接的结果就导致GC性能下降。Java服务的感受就是延时增加,TP监控曲线突刺增加,吞吐量下降。针对这个问题有各种解法:

    • 显式的传递JVM启动参数“-XX:ParallelGCThreads”告诉JVM应该启动几个并行GC线程。它的缺点是需要业务感知,为不同配置的容器传不同的JVM参数。
    • 在容器内使用Hack过的glibc,使JVM(通过sysconf系统调用)能正确获取容器的CPU资源数。我们在一段时间内使用的就是这种方法。其优点是业务不需要感知,并且能自动适配不同配置的容器。缺点是必须使用改过的glibc,有一定的升级维护成本,如果使用的镜像是原生的glibc,问题也仍然存在。
    • 我们在新平台上通过对内核的改进,实现了容器中能获取正确CPU资源数,做到了对业务、镜像和编程语言都透明(类似问题也可能影响OpenMP、Node.js等应用的性能)。

    有一段时间,我们的容器是使用root权限进行运行,实现的方法是在docker run的时候加入‘privileged=true’参数。这种粗放的使用方式,使容器能够看到所在服务器上所有容器的磁盘,导致了安全问题和性能问题。安全问题很好理解,为什么会导致性能问题呢?可以试想一下,每个容器都做一次磁盘状态扫描的场景。当然,权限过大的问题还体现在可以随意进行mount操作,可以随意的修改NTP时间等等。

    在新版本中,我们去掉了容器的root权限,发现有一些副作用,比如导致一些系统调用失败。我们默认给容器额外增加了sys_ptrace和sys_admin两个权限,让容器可以运行GDB和更改主机名。如果有特例容器需要更多的权限,可以在我们的平台上按服务粒度进行配置。

    Linux有两种IO:Direct IO和Buffered IO。Direct IO直接写磁盘,Buffered IO会先写到缓存再写磁盘,大部分场景下都是Buffered IO。

    我们使用的Linux内核3.X,社区版本中所有容器Buffer IO共享一个内核缓存,并且缓存不隔离,没有速率限制,导致高IO容器很容易影响同主机上的其他容器。Buffer IO缓存隔离和限速在Linux 4.X里通过Cgroup V2实现,有了明显的改进,我们还借鉴了Cgroup V2的思想,在我们的Linux 3.10内核实现了相同的功能:每个容器根据自己的内存配置有对应比例的IO Cache,Cache的数据写到磁盘的速率受容器Cgroup IO配置的限制。

    Docker本身支持较多对容器的Cgroup资源限制,但是K8s调用Docker时可以传递的参数较少,为了降低容器间的互相影响,我们基于服务画像的资源分配,对不同服务的容器设定不同的资源限制,除了常见的CPU、内存外,还有IO的限制、ulimit限制、PID限制等等。所以我们扩展了K8s来完成这些工作。

    业务在使用容器的过程中产生core dump文件是常见的事,比如C/C++程序内存访问越界,或者系统OOM的时候,系统选择占用内存多的进程杀死,默认都会生成一个core dump文件。

    社区容器系统默认的core dump文件会生成在宿主机上,由于一些core dump文件比较大,比如JVM的core dump通常是几个GB,或者有些存在Bug的程序,其频发的core dump很容易快速写满宿主机的存储,并且会导致高磁盘IO,也会影响到其他容器。还有一个问题是:业务容器的使用者没有权限访问宿主机,从而拿不到dump文件进行下一步的分析。

    为此,我们对core dump的流程进行了修改,让dump文件写到容器自身的文件系统中,并且使用容器自己的Cgroup IO吞吐限制。

    稳定性

    我们在实践中发现,影响系统稳定性的主要是Linux Kernel和Docker。虽然它们本身是很可靠的系统软件,但是在大规模、高强度的场景中,还是会存在一些Bug。这也从侧面说明,我们国内互联网公司在应用规模和应用复杂度层面也属于全球领先。

    在内核方面,美团发现了Kernel 4.x Buffer IO限制的实现问题,得到了社区的确认和修复。我们还跟进了一系列CentOS的Ext4补丁,解决了一段时间内进程频繁卡死的问题。

    我们碰到了两个比较关键的Red Hat版Docker稳定性问题:

    • 在Docker服务重启以后,Docker exec无法进入容器,这个问题比较复杂。在解决之前我们用nsenter来代替Docker exec并积极反馈给RedHat。后来Red Hat在今年初的一个更新解决了这个问题。https://access.redhat.com/errata/RHBA-2017:1620

    • 是在特定条件下Docker Daemon会Panic,导致容器无法删除。经过我们自己Debug,并对比最新的代码,发现问题已经在Docker upstream中得到解决,反馈给Red Hat也很快得到了解决。https://github.com/projectatomic/containerd/issues/2

    面对系统内核、Docker、K8s这些开源社区的系统软件,存在一种观点是:我们不需要自己分析问题,只需要拿社区的最新更新就行了。但是我们并不认同,我们认为技术团队自身的能力很重要,主要是如下原因:

    • 美团的应用规模大、场景复杂,很多问题也许很多企业都没有遇到过,不能被动的等别人来解答。
    • 对于一些实际的业务问题或者需求(例如容器内正确返回CPU数目),社区也许觉得不重要,或者不是正确的理念,可能就不会解决。
    • 社区很多时候只在Upstream解决问题,而Upstream通常不稳定,即使有Backport到我们正在使用的版本,排期也很难进行保障。
    • 社区会发布很多补丁,通常描述都比较晦涩难懂。如果没有对问题的深刻理解,很难把遇到的实际问题和一系列补丁联系起来。
    • 对于一些复杂问题,社区的解决方案不一定适用于我们自身的实际场景,我们需要自身有能力进行判断和取舍。

    美团在解决开源系统问题时,一般会经历五个阶段:自己深挖、研发解决、关注社区、和社区交互,最后贡献给社区。

    性能

    容器平台性能,主要包括两个方面性能:

    • 业务服务运行在容器上的性能。
    • 容器操作(创建、删除等等)的性能。

    上图是我们CPU分配的一个例子,我们采用的主流服务器是两路24核服务器,包含两个Node,每个12核,算上超线程共48颗逻辑CPU。属于典型的NUMA(非一致访存)架构:系统中每个Node有自己的内存,Node内的CPU访问自己的内存的速度,比访问另一个Node内存的速度快很多(差一倍左右)。

    过去我们曾经遇到过网络中断集中到CPU0上的问题,在大流量下可能导致网络延时增加甚至丢包。为了保证网络处理能力,我们从Node0上划出了8颗逻辑CPU用来专门处理网络中断和宿主机系统上的任务,例如镜像解压这类高CPU的工作,这8颗逻辑CPU不运行任何容器的Workload。

    在容器调度方面,我们的容器CPU分配尽量不跨Node,实践证明跨Node访问内存对应用性能的影响比较大。在一些计算密集型的场景下,容器分配在Node内部会提升30%以上的吞吐量。按Node的分配方案也存在一定的弊端:会导致CPU的碎片增加,为了更高效地利用CPU资源。在实际系统中,我们会根据服务画像的信息,分配一些对CPU不敏感的服务容器跨Node使用CPU资源。

    上图是一个真实的服务在CPU分配优化前后,响应延时的TP指标线对比。可以看到TP999线下降了一个数量级,所有的指标都更加平稳。

    性能优化:文件系统

    针对文件系统的性能优化,第一步是选型,根据统计到的应用读写特征,我们选择了Ext4文件系统(超过85%的文件读写是对小于1M文件的操作)。

    Ext4文件系统有三种日志模式:

    • Journal:写数据前等待Metadata和数据的日志落盘。
    • Ordered:只记录Metadata的日志,写Metadata日志前确保数据已经落盘。
    • Writeback:仅记录Metadata日志,不保证数据比Metadata先落盘。

    我们选择了Writeback模式(默认是oderded),它在几种挂载模式中速度最快,缺点是:发生故障时数据不好恢复。我们大部分容器处于无状态,故障时在别的机器上再拉起一台即可。因此我们在性能和稳定性中,选择了性能。容器内部给应用提供可选的基于内存的文件系统tmpfs,可以提升有大量临时文件读写的服务性能。

    如上图所示,在美团内部创建一个虚拟机至少经历三步,平均时间超过300秒。使用镜像创建容器平均时间23秒。容器的灵活、快速得到了显著的体现。

    容器扩容23秒的平均时间包含了各个部分的优化,如扩容链路优化、镜像分发优化、初始化和业务拉起优化等等。接下来,本文主要介绍一下我们做的镜像分发和解压相关的优化。

    上图是美团容器镜像管理的总体架构,其特点如下:

    • 存在多个Site。
    • 支持跨Site的镜像同步,根据镜像的标签确定是否需要跨Site同步。
    • 每个Site有镜像备份。
    • 每个Site内部有实现镜像分发的P2P网络。

    镜像分发是影响容器扩容时长的一个重要环节。

    • 跨Site同步:保证服务器总能从就近的镜像仓库拉取到扩容用的镜像,减少拉取时间,降低跨Site带宽消耗。
    • 基础镜像预分发:美团的基础镜像是构建业务镜像的公共镜像,通常有几百兆的大小。业务镜像层是业务的应用代码,通常比基础镜像小很多。在容器扩容的时候如果基础镜像已经在本地,就只需要拉取业务镜像的部分,可以明显的加快扩容速度。为达到这样的效果,我们会把基础镜像事先分发到所有的服务器上。
    • P2P镜像分发:基础镜像预分发在有些场景会导致上千个服务器同时从镜像仓库拉取镜像,对镜像仓库服务和带宽带来很大的压力。因此我们开发了镜像P2P分发的功能,服务器不仅能从镜像仓库中拉取镜像,还能从其他服务器上获取镜像的分片。

    从上图可以看出,随着分发服务器数目的增加,原有分发时间也快速增加,而P2P镜像分发时间基本上保持稳定。

    Docker的镜像拉取是一个并行下载,串行解压的过程,为了提升解压的速度,我们美团也做了一些优化工作。

    对于单个层的解压,我们使用并行解压算法替换Docker默认的串行解压算法,实现上是使用pgzip替换gzip。

    Docker的镜像具有分层结构,对镜像层的合并是一个“解压一层合并一层,再解压一层,再合并一层”的串行操作。实际上只有合并是需要串行的,解压可以并行起来。我们把多层的解压改成并行,解压出的数据先放在临时存储空间,最后根据层之间的依赖进行串行合并。前面的改动(并行解压所有的层到临时空间)导致磁盘IO的次数增加了近一倍,也会导致解压过程不够快。于是,我们使用基于内存的Ramdisk来存储解压出来的临时文件,减轻了额外文件写带来的开销。做了上面这些工作以后,我们又发现,容器的分层也会影响下载加解压的时间。上图是我们简单测试的结果:无论对于怎么分层的镜像并行解压,都能大幅提升解压时间,对于层数多的镜像提升更加明显。

    推广

    推广容器的第一步是能说出容器的优势,我们认为容器有如下优势:

    • 轻量级:容器小、快,能够实现秒级启动。
    • 应用分发:容器使用镜像分发,开发测试容器和部署容器配置完全一致。
    • 弹性:可以根据CPU、内存等资源使用或者QPS、延时等业务指标快速扩容容器,提升服务能力。

    这三个特性的组合,可以给业务带来更大的灵活度和更低的计算成本。

    因为容器平台本身是一个技术产品,它的客户是各个业务的RD团队,因此我们需要考虑下面一些因素:

    • 产品优势:推广容器平台从某种程度上讲,自身是一个ToB的业务,首先要有好的产品,它相对于以前的解决方案(虚拟机)存在很多优势。
    • 和已有系统打通:这个产品要能和客户现有的系统很好的进行集成,而不是让客户推翻所有的系统重新再来。
    • 原生应用的开发平台、工具:这个产品要易于使用,要有配合工作的工具链。
    • 虚拟机到容器的平滑迁移:最好能提供从原有方案到新产品的迁移方案,并且容易实施。
    • 与应用RD紧密配合:要提供良好的客户支持,(即使有些问题不是这个产品导致的也要积极帮忙解决)。
    • 资源倾斜:从战略层面支持颠覆性新技术:资源上向容器平台倾斜,没有足够的理由,尽量不给配置虚拟机资源。

    总结

    Docker容器加Kubernetes编排是当前容器云的主流实践之一,美团容器集群管理平台HULK也采用了这样的方案。本文主要分享了美团在容器技术上做的一些探索和实践。内容主要涵盖美团容器云在Linux Kernel、Docker和Kubernetes层面做的一些优化工作,以及美团内部推动容器化进程的一些思考,欢迎大家跟我们交流、探讨。

    作者简介

    欧阳坚,2006年毕业于清华大学计算机系,拥有12年数据中心开发管理经验。曾任VMware中国Staff Engineer,无双科技CTO,中科睿光首席架构师。现任美团基础架构部/容器研发中心技术总监,负责美团容器化的相关工作。

    招聘信息

    美团点评基础架构团队诚招Java高级、资深技术专家,Base北京、上海。我们是集团致力于研发公司级、业界领先基础架构组件的核心团队,涵盖分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等技术领域。欢迎有兴趣的同学投送简历到 liuxing14@meituan.com

    展开全文
  • 传统的云计算是基于虚拟机技术的,而容器技术解决了虚拟机原来解决不了的问题。 云计算主要解决的是资源弹性的问题,感兴趣的可以看历史文章《不懂技术也能看懂云计算,大数据,人工智能》。 所谓资源,主要是指...

    在云计算领域有一个新的技术,称为容器。

    传统的云计算是基于虚拟机技术的,而容器技术解决了虚拟机原来解决不了的问题。

    云计算主要解决的是资源弹性的问题,感兴趣的可以看历史文章《不懂技术也能看懂云计算,大数据,人工智能》。

    所谓资源,主要是指计算,网络,存储。罗永浩在采访中说过,他要做最大的计算平台,当前是手机,其实大家买手机也是关心CPU,内存有多少,有多大的存储空间,3G还是4G网络的问题。

    云计算所能解决的是计算,网络,存储这三种资源想什么时候要什么时候要,想要多少要多少的问题。

    但是云计算解决不了的问题有两个:

    第一个问题是应用层的扩展性问题

    例如我开发一个电商应用,平时的时候10台机器能扛的住,双十一的时候需要100台才能抗的住。那怎么办?云计算平台可以实现一点90台新机器就出来了,但是机器是空的啊,上面什么应用都没安装,还需要人工登到每台机器上去一台一台的部署,非常麻烦。

    后来人们想了两种方式解决这个问题,第一种方式是采用自动化脚本来安装,不需要手动来,而是自动来,第二种方式是通过虚拟机的镜像,在虚拟机上把应用都安装好,然后像孙悟空一样,说“定”,虚拟机里面的状态就保存下来了,后面扩展的时候,通过这个镜像来完成。

    这两种方式部分的解决了第一个问题,随之而来的是第二个问题,迁移性问题

    软件往往是需要不断的在不同的环境里面安装的,例如开发人员自己会安装一套,测试人员会安装一套,线上环境也会安装一套。然而软件的安装是非常复杂的,牵扯到权限问题,配置问题,文件路径问题等,一不小心就会出错,出错了软件的行为就不对了,你上网买东西,用银行支付都可能出错,造成大麻烦。

    一开始人们还是想通过上面两种方式来解决这个问题的,但是都不太成功。一是通过自动化脚本,然而不同的环境千差万别,一个脚本往往在一个环境上运行正确,到另一个环境就不正确了。二是通过虚拟机镜像,然而虚拟机镜像太大了,动不动就几十个G,拷贝和下载都太费时间,而且大多数公有云平台都不提供虚拟机镜像的上传和下载,亚马逊上的虚拟机镜像,就没办法下载到你的数据中心里面来,也没法放到网易云上去。

    于是为了解决这两大问题,容器诞生了。

    容器是 Container,Container另一个意思是集装箱,其实容器的思想就是要变成软件交付的集装箱。集装箱的特点,一是封装,二是标准。

    在没有集装箱的时代,假设将货物从 A运到 B,中间要经过三个码头、换三次船。每次都要将货物卸下船来,摆的七零八落,然后搬上船重新整齐摆好。因此在没有集装箱的时候,每次换船,船员们都要在岸上待几天才能走。

    有了集装箱以后,所有的货物都打包在一起了,并且集装箱的尺寸全部一致,所以每次换船的时候,一个箱子整体搬过去就行了,小时级别就能完成,船员再也不用上岸长时间耽搁了。

    这是集装箱“封装”、“标准”两大特点在生活中的应用。

    那么容器如何对应用打包呢?还是要学习集装箱,首先要有个封闭的环境,将货物封装起来,让货物之间互不干扰,互相隔离,这样装货卸货才方便。好在 Ubuntu中的LXC技术早就能做到这一点。

    封闭的环境主要使用了两种技术,一种是看起来是隔离的技术,称为 Namespace,也即每个 Namespace中的应用看到的是不同的 IP地址、用户空间、程号等。另一种是用起来是隔离的技术,称为 Cgroups,也即明明整台机器有很多的 CPU、内存,而一个应用只能用其中的一部分。

    有了这两项技术,集装箱的铁盒子我们是焊好了,接下来就是决定往里面放什么。

    最简单粗暴的方法,就是将所有的都放到集装箱里面,就像虚拟机镜像一样,但是这样太大了!因为即使你安装一个干干静静的操作系统,什么都不装,就很大了。把操作系统装进容器相当于把船也放到了集装箱里面!传统的虚拟机镜像就是这样的,动辄几十G。答案当然是 NO!所以第一项操作系统不能装进容器。

    撇下第一项操作系统,剩下的所有的加起来,也就几百 M,就轻便多了。因此一台服务器上的容器是共享操作系统内核的,容器在不同机器之间的迁移不带内核,这也是很多人声称容器是轻量级的虚拟机的原因。轻不白轻,自然隔离性就差了,一个容器让操作系统崩溃了,其他容器也就跟着崩溃了,这相当于一个集装箱把船压漏水了,所有的集装箱一起沉。

    另一个需要撇下的就是随着应用的运行而产生并保存在本地的数据。这些数据多以文件的形式存在,例如数据库文件、文本文件。这些文件会随着应用的运行,越来越大,如果这些数据也放在容器里面,会让容器变得很大,影响容器在不同环境的迁移。而且这些数据在开发、测试、线上环境之间的迁移是没有意义的,生产环境不可能用测试环境的文件,所以往往这些数据也是保存在容器外面的存储设备上。这也是为什么人们称容器是无状态的。

    至此集装箱焊好了,货物也装进去了,接下来的问题就是如何将这个集装箱标准化,从而在哪艘船上都能运输。这里的标准一个是镜像,一个是容器的运行环境。

    所谓的镜像,就是将你焊好集装箱的那一刻,将集装箱的状态保存下来,就像孙悟空说:“定”,集装箱里面就定在了那一刻,然后将这一刻的状态保存成一系列文件。这些文件的格式是标准的,谁看到这些文件都能还原当时定住的那个时刻。将镜像还原成运行时的过程(就是读取镜像文件,还原那个时刻的过程)就是容器运行的过程。除了大名鼎鼎的 Docker,还有其他的容器,例如 AppC、Mesos Container,都能运行容器镜像。所以说容器不等于 Docker。

    总而言之,容器是轻量级的、隔离差的、适用于无状态的,可以基于镜像标准实现跨主机、跨环境的随意迁移。

    有了容器,使得 PaaS层对于用户自身应用的自动部署变得快速而优雅。容器快就快在两方面:第一,虚拟机启动的时候要先启动操作系统,容器不用启动操作系统,因为是共享内核的;第二,虚拟机启动后使用脚本安装应用,容器不用安装应用,因为已经打包在镜像里面了。所以最终虚拟机的启动是分钟级别,而容器的启动是秒级。容器咋这么神奇?其实一点都不神奇,第一是偷懒少干活了,第二是提前把活干好了。

    由于容器的粒度更加细,管理起来更难管,甚至是手动操作难以应对的。假设你有 100台物理机,其实规模不是太大,用 Excel人工管理是没问题的,但是一台上面开 10台虚拟机,虚拟机的个数就是 1000台,人工管理已经很困难了,但是一台虚拟机里面开 10个容器,就是 10000个容器,你是不是已经彻底放弃人工运维的想法了。

    所以容器层面的管理平台是一个新的挑战,关键字就是自动化:

    自发现:容器与容器之间的相互配置还能像虚拟机一样,记住 IP地址然后互相配置吗?这么多容器,一旦一台虚拟机挂了重启,IP改变,你怎么记得住应该改哪些配置,列表长度至少万行级别的啊。所以容器之间的配置通过名称来的,无论容器跑到哪台机器上,名称不变,就能访问到。

    自修复:容器挂了,或是进程宕机了,能像虚拟机那样登陆上去查看一下进程状态,如果不正常可以重启一下么?那你要登陆万台 Docker了。所以容器的进程挂了,容器就自动挂掉了,然后自动重启。

    弹性自伸缩 Auto Scaling:当容器的性能不足的时候,需要手动伸缩、手动部署么?当然也要自动来。

    当前火热的容器管理平台有三大流派:

    一个是 Kubernetes,我们称为段誉型。

    段誉(Kubernetes)的父亲(Borg)武功高强,出身皇族(Google),管理过偌大的一个大理国(Borg是 Google数据中心的容器管理平台)。作为大理段式后裔,段誉的武功基因良好(Kubernetes的理念设计比较完善),周围的高手云集,习武环境也好(Kubernetes生态活跃,热度高),虽然刚刚出道的段誉武功不及其父亲,但是只要跟着周围的高手不断切磋,武功即可飞速提升。

    一个是 Mesos,我们称为乔峰型。

    乔峰(Mesos)的主要功夫降龙十八掌(Mesos的调度功能)独步武林,为其他帮派所无。而且乔峰也管理过人数众多的丐帮(Mesos管理过 Tweeter的容器集群)。后来乔峰从丐帮出来,在江湖中特例独行(Mesos的创始人成立了公司 Mesosphere)。乔峰的优势在于,乔峰的降龙十八掌(Mesos)就是在丐帮中使用的降龙十八掌,相比于段誉初学其父的武功来说,要成熟很多。但是缺点是,降龙十八掌只掌握在少数的几个丐帮帮主手中(Mesos社区还是以 Mesosphere为主导),其他丐帮兄弟只能远远崇拜乔峰,而无法相互切磋(社区热度不足)。

    一个是 Swarm,我们称为慕容型。

    慕容家族(Swarm是 Docker家族的集群管理软件)的个人功夫是非常棒的(Docker可以说称为容器的事实标准),但是看到段誉和乔峰能够管理的组织规模越来越大,有一统江湖的趋势,着实眼红了,于是开始想创建自己的慕容鲜卑帝国(推出 Swarm容器集群管理软件)。但是个人功夫好,并不代表着组织能力强(Swarm的集群管理能力),好在慕容家族可以借鉴段誉和乔峰的组织管理经验,学习各家公司,以彼之道,还施彼身,使得慕容公子的组织能力(Swarm借鉴了很多前面的集群管理思想)也在逐渐的成熟中。

    三大容器门派,到底鹿死谁手,谁又能一统江湖,尚未可知。

    展开全文
  • Docker技术( 容器虚拟化技术 )

    万次阅读 多人点赞 2019-10-18 19:59:21
    Docker虚拟化容器技术 第一章 Docker简介诞生背景Docker 介绍虚拟机技术容器虚拟化技术官方网址第二章 Docker安装前提条件安装DockerDocker底层原理Docker结构图工作原理Docker为什么比VM快第三章 Docker常用命令...

    第一章 Docker介绍

    诞生背景

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

    环境配置如此麻烦,换一台机器,就要重来一次,费力费时。
    很多人想到,能不能从根本上解决问题,软件可以带环境安装?
    也就是说,安装的时候,把原始环境一模一样地复制过来。
    开发人员利用 Docker 可以消除协作编码时“在我的机器上可正常工作”的问题。

    开发需要清楚的告诉运维部署团队,用的全部配置文件+所有软件环境。
    不过,即便如此,仍然常常发生部署失败的状况。
    Docker镜像的设计,使得Docker得以打破过去"程序即应用" 的观念。
    透过镜像(images)将作业系统核心除外,运作应用程式所需要的系统环境,
    由下而上打包,达到应用程式跨平台间的无缝接轨运作。

    在这里插入图片描述

    Docker 介绍

    Docker的主要目标是“Build,Ship and Run Any App,Anywhere”,
    也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理,
    使用户的APP(可以是一个WEB应用或数据库应用等等)及其运行环境能够做到“一次封装,到处运行”。

    Linux 容器技术的出现就解决了这样一个问题,而 Docker 就是在它的基础上发展过来的。
    将应用运行在 Docker 容器上面,而 Docker 容器在任何操作系统上都是一致的,
    这就实现了跨平台、跨服务器只需要一次配置好环境,换到别的机子上就可以一键部署好, 大大简化了操作

    总结:
    Docker是解决运行环境和配置问题的软件容器 , 方便做持续集中并有助于整体发布的容器虚拟化技术

    在这里插入图片描述

    虚拟机技术与容器虚拟化技术

    虚拟机技术

    虚拟机(virtual machine)就是带环境安装的一种解决方案。
    可以在一种操作系统里面运行另一种操作系统,比如在Windows 系统里面运行Linux 系统。
    应用程序对此毫无感知,因为虚拟机看上去跟真实系统一模一样
    缺点 :1 资源占用多 2 冗余步骤多 3 启动慢

    在这里插入图片描述

    容器虚拟化技术

    Linux 容器(Linux Containers,缩写为 LXC)。
    Linux 容器不是模拟一个完整的操作系统,而是对进程进行隔离。
    有了容器,就可以将软件运行所需的所有资源打包到一个隔离的容器中。
    容器与虚拟机不同,不需要捆绑一整套操作系统,只需要软件工作所需的库资源和设置
    系统因此而变得高效轻量并保证部署在任何环境中的软件都能始终如一地运行。

    在这里插入图片描述
    二者区别

    1. 传统虚拟机技术是虚拟出一套硬件后,在其上运行一个完整操作系统,在该系统上再运行所需应用进程;
    2. 而容器内的应用进程直接运行于宿主机( 即:所在主机,下面统称宿主机 ) 的内核,容器内没有自己的内核,而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。
    3. 每个容器之间互相隔离,每个容器有自己的文件系统 ,容器之间进程不会相互影响,能区分计算资源。

    官方网址

    官方网址 : https://www.docker.com
    Docker社区官方:https://hub.docker.com/

    第二章 Docker安装

    Docker支持以下的CentOS版本:CentOS 7 (64-bit) ,CentOS 6.5 (64-bit) 或更高的版本

    前提条件

    目前,CentOS 仅发行版本中的内核支持 Docker。
    Docker 运行在 CentOS 7 上,要求系统为64位、系统内核版本为 3.10 以上。
    Docker 运行在 CentOS-6.5 或更高的版本的 CentOS 上,要求系统为64位、系统内核版本为 2.6.32-431 或者更高版本。

    # 查看内核版本
    uname -r 
    

    安装Docker

    Docker安装教程(CentOS 7)本人阿里云服务器装成功
    Docker安装教程(CentOS 7)本人腾讯云服务器装成功
    Docker安装教程(CentOS 6)

    Docker管理命令

    # 重新载入后台启动进程
    systemctl daemon-reload
    
    # 启动docker容器 ,每次关闭虚拟机/运服务器时需要启动( 重要!!! )
    sudo service docker start
    
    # 查看Docker容器状态
    sudo service docker status (should see active (running))
    
    # 运行hello-world镜像/测试Docker是否可以使用
    sudo docker run hello-world
    

    Docker底层原理

    Docker结构图

    在这里插入图片描述
    在这里插入图片描述

    工作原理

    Docker是一个Client-Server结构的系统,Docker守护进程运行在主机上,
    然后通过Socket连接从客户端访问,守护进程从客户端接受命令并管理运行在主机上的容器。
    容器,是一个运行时环境,就是我们前面说到的集装箱。

    在这里插入图片描述

    Docker为什么比VM快

    (1) docker有着比虚拟机更少的抽象层。
    由亍docker不需要Hypervisor实现硬件资源虚拟化,
    运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。
    因此在CPU、内存利用率上docker将会在效率上有明显优势。
    在这里插入图片描述

    (2) docker利用的是宿主机的内核,而不需要Guest OS。
    因此,当新建一个容器时,docker不需要和虚拟机一样重新加载一个操作系统内核。
    因而避免引寻、加载操作系统内核返个比较费时费资源的过程,
    当新建一个虚拟机时,虚拟机软件需要加载Guest OS,返个新建过程是分钟级别的。
    而docker由于直接利用宿主机的操作系统,则省略了返个过程,因此新建一个docker容器只需要几秒钟。
    通过下图着重了解二者的比较( 图很重要!!!)
    在这里插入图片描述

    第三章 Docker常用命令

    帮助命令

    # 查看docker版本信息
    docker version
    
    # 查看docker所有安装信息
    docker info
    
    # 查看docker帮助 ( 最为重要,学会利用帮助文档来学习 ,这是成为高手的必经之路!!! )
    docker --help
    

    镜像命令

    # 1.列出本地镜像(图1)
    docker images
    
    # option说明
     -a :列出所有镜像
     -q:只列出镜像id
     -digests :显示镜像的摘要信息
    --no-trunc :显示相信信息
    
    
    # 2.搜索某个镜像名字 (会在docker社区搜索相关的镜像, 而我们配置的阿里源只是帮我们同步了docker社区的镜像,图2)
    docker search 
    
    # option说明
    	- s显示收藏数不小于指定值的镜像
        --no-trunc :显示相信信息
        - automated :只列出automated类型的镜像
    
    # 3. 下载镜像(图3)
    docker pull 镜像的名字:[TAG](不写默认为 lasted)
    
    # 4. 删除镜像
    docker rmi  -f 镜像名/镜像id
    docker rmi -f $(docker images -qa )
       
    

    各个选项说明:
    REPOSITORY:表示镜像的仓库源
    TAG:镜像的标签
    IMAGE ID:镜像ID
    CREATED:镜像创建时间
    SIZE:镜像大小
    同一仓库源可以有多个 TAG,代表这个仓库源的不同个版本,我们使用 REPOSITORY:TAG 来定义不同的镜像。
    如果你不指定一个镜像的版本标签,例如你只使用 ubuntu,docker 将默认使用 ubuntu:latest 镜像

    图1
    在这里插入图片描述
    图2
    在这里插入图片描述

    图3
    在这里插入图片描述

    容器命令

    基本命令

    # 1. 新建并启动容器
    docker run [OPTIONS] IMAGE [COMMOND] [ARGS...]
    
    # OPTIONS 说明
    	--name="容器新名字": 为容器指定一个名称;
    	-d: 后台运行容器,并返回容器ID,也即启动守护式容器;
    	-i:以交互模式运行容器,通常与 -t 同时使用;
    	-t:为容器重新分配一个伪输入终端,通常与 -i 同时使用;
    	-P: 随机端口映射;
    	-p: 指定端口映射,有以下四种格式
    	      ip:hostPort:containerPort
    	      ip::containerPort
    	      hostPort:containerPort
    	      containerPort
    	      
    # eg: 使用镜像centos:latest以交互模式启动一个容器,在容器内执行/bin/bash命令。
    docker run -it centos /bin/bash 
    
     
    # 2. 查询当前正在运行的容器(类比虚拟中的查看进程)
    docker ps [OPTIONS] 
    
    # OPTIONS说明(常用):
    	-a :列出当前所有正在运行的容器+历史上运行过的
    	-l :显示最近创建的容器。
    	-n:显示最近n个创建的容器。
    	-q :静默模式,只显示容器编号。
    	--no-trunc :不截断输出。
    
    
    # 3. 退出容器
    exit  容器停止后退出
    ctrl+p+q  容器不停止退出
    
    # 4 .启动容器
    docker start 容器ID/容器名
    
    # 5. 重启容器 
    docker restart
    
    # 6. 停止容器
    docker stop 容器ID/容器名
    
    # 7. 强制停止容器
    docker kill 容器ID/容器名
    
    # 8. 删除已经停止的容器(如果没有停止,删除后悔停止)
    docker rm 容器ID
    删除多个容器(特别是第二种 ,先查询所有运行的进程, 然后通过管道传到后面的删除操作中)
    docker rm -f $(docker ps -a -q)
    docker ps -a -q | xargs docker rm
    

    重要命令

    # 1. 启动守护式容器(后台运行)
    docker -d 容器名
    
    # 使用镜像centos:latest以后台模式启动一个容器
    docker run -d centos
    
    问题:然后docker ps -a 进行查看, 会发现容器已经退出
    很重要的要说明的一点: Docker容器后台运行,就必须有一个前台进程.
    容器运行的命令如果不是那些一直挂起的命令(比如运行top,tail),就是会自动退出的。
    
    这个是docker的机制问题,比如你的web容器,我们以nginx为例,正常情况下,我们配置启动服务只需要启动响应的service即可。例如service nginx start
    但是,这样做,nginx为后台进程模式运行,就导致docker前台没有运行的应用,
    这样的容器后台启动后,会立即自杀因为他觉得他没事可做了.
    所以,最佳的解决方案是,将你要运行的程序以前台进程的形式运行
    
    # 2. 查看容器日志
    docker logs -f -t --tail 容器ID
    
    eg :(图1)
    docker run -d centos /bin/sh -c "while true;do echo hello testLogs;sleep 2;done"
    docker logs -tf --tail 10 02c81778b0e0
    
    -t 是加入时间戳
    -f 跟随最新的日志打印
    --tail 数字 显示最后多少条
    
    
    # 3. 查看容器内运行的进程(图2)
    docker top 容器ID
    
    # 4. 查看容器内部细节(图3)
    docker inspect 容器ID
    
    # 5.进入正在运行的容器并进行交互(图4)
    docker exec -it 容器ID bashShell
    
    # 6. 重新进入容器(图5)
    docker attach 容器ID bashShell(不写的话默认 /bin/bash下)
    
    # 比较5与6的区别
    attach 直接进入容器启动命令终端, 不会启动新的线程
    exec 是在容器中打开新的终端, 并且可以启动新的线程
    

    图1
    在这里插入图片描述

    图2
    在这里插入图片描述
    图3
    在这里插入图片描述
    图4
    在这里插入图片描述
    图5
    在这里插入图片描述

    Docker常用命令图解

    在这里插入图片描述

    第四章 Docker镜像

    镜像 / UnionFS(联合文件系统)

    Union文件系统(UnionFS)是一种分层、轻量级并且高性能的文件系统
    它支持对文件系统的修改作为一次提交来一层层的叠加,
    同时可以将不同目录挂载到同一个虚拟文件系统下。Union 文件系统是 Docker 镜像的基础。
    镜像可以通过分层来进行继承. 基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。

    特性
    一次同时加载多个文件系统,但从外面看起来,只能看到一个文件系统,
    联合加载会把各层文件系统叠加起来,这样最终的文件系统会包含所有底层的文件和目录

    在这里插入图片描述
    总结:
    镜像就像洋葱圈 ,就像莲花卷 ,一层套一层 ,对外只显示一个文件系统.
    而且, 这种分层镜像还可以复用

    特点

    Dcoker镜像都是只读的 , 当启动容器时, 一个新的可写层被加载到镜像的顶部
    这一层被称为"容器层", "容器层"执行的都称为"镜像层"

    Docker镜像加载原理:

    docker的镜像实际上由一层一层的文件系统组成,这种层级的文件构成文件系统UnionFS。
    在这里插入图片描述
    bootfs(boot file system) 主要包含bootloader和kernel,
    bootloader主要作用是引导加载kernel, Linux刚启动时会加载bootfs文件系统,Docker镜像的最底层是bootfs
    这一层与典型的Linux/Unix系统是一样的,包含boot加载器和内核。
    当boot加载完成之后整个内核就都在内存中了,此时内存的使用权已由bootfs转交给内核,此时系统也会卸载bootfs。

    rootfs (root file system) ,在bootfs之上。
    包含的就是典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。
    rootfs就是各种不同的操作系统发行版,比如Ubuntu,Centos等等。

    平时我们安装进虚拟机的CentOS都是好几个G,为什么docker这里才220M

    在这里插入图片描述
    对于一个精简的OS,rootfs可以很小,只需要包括最基本的命令、工具和程序库就可以了,
    因为底层直接用Host的kernel,自己只需要提供 rootfs 就行了。
    由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs。

    Docker镜像Commit操作

    # 提交容器副本实质成为一个新的镜像
    docker commit -m="提交的描述信息" -a="作者"	容器ID 要创建的目标镜像名:[标签名]
    
    
    eg: 同时docker运行tomcat案例
    # 1.  创建交互式界面 ( 相当于前台启动)
    docker run -it -p 8888:8080 tomcat   # 端口映射将8888作为docker的入口,映射到tomcat镜像的8080(图1,图2)
    docker run -it -P  tomcat  #自动端口映射(通过 docker ps查看端口, 图3)
    #后台启动(不会占用当前页面)
    docker run -d -p 8888:8080 tomcat 
    
    
    # 2. 进入tomcat (如果前置启动,另开一个窗口 ,后置启动则直接进入)
    # 查看运行容器ID
    docker ps  
    # 进入根目录
    docker exec -it 容器ID /bin/bash
    /usr/local/tomcat# rm -rf webapps/docs/ 
    # 删除后访问tomcat ,可以看到访问主页下的文档出现404(图4)
    
    # 3. 提交容器副本实使之为一个新的镜像
    # 查看运行容器ID
    docker ps  
    # 提交容器
    docker commit -m="del tomcat docs" -a="timepaus" 容器ID tomcat:v1.2
    # 查看镜像(图5)
    docker images
    
    # 4.同时启动新镜像并和原来的对比
    可以看到我们自己提交的新镜像也没有文档()
    但是我们重新下载的tomcat是有的
    

    图1
    在这里插入图片描述
    图2
    在这里插入图片描述
    图3
    在这里插入图片描述
    图4

    在这里插入图片描述
    图5
    在这里插入图片描述

    第五章 Docker容器数据卷

    简介

    类似Redis中的rdb文件和aof文件
    用于容器的持久化和荣期间的继承与共享数据

    容器内添加数据卷

    1.直接命令添加

    # 通过-v命令直接添加 (需要在根目录下创建 containerData  )
    # 创建后修改容器内containerData 会同步到hostData ,反之亦是如此
    docker run -it -v /hostData:/containerData  镜像名/ID
    
    # 创建只读权限的文件 , 容器内只能读取这个文件, 但是不能修改. ro: readonly
    docker run -it -v /宿主机绝路路径目录:/容器内目录:ro 镜像名
    

    2.Docker添加

    DockerFile的简单理解
    在这里插入图片描述

    # 1. 宿主机根目录下创建mydocker文件夹并进入
    
    
    # 2. 在mydocker文件想创建DockerFile文件并编辑,内容如下(图1)
    
    # volume test
    FROM centos
    VOLUME ["/dataVolumeContainer1","/dataVolumeContainer2"]
    CMD echo "finished,--------success1"
    CMD /bin/bash
    
    说明:
    出于可移植和分享的考虑,用-v 主机目录:容器目录这种方法不能够直接在Dockerfile中实现。
    由于宿主机目录是依赖于特定宿主机的,并不能够保证在所有的宿主机上都存在这样的特定目录。
    
    
    3. 使用docker build命令创建一个镜像, 并挂载指定宿主机指定文件
    docker build -f /mydocker/DockerFile -t 定义的新镜像名称
    
    4. 查看镜像
    docker images
    
    5.运行新镜像
    docker run -it 定义的新镜像ID /bin/bash
    
    6.通过镜像运行后生成的容器ID查看 (图2), 对应的主机映射的数据卷地址
    docker ps
    docker inspect 容器ID
    
    7.测试添加卷和主机是否互通有无
    在容器中创建文件, 看看主机中是否创建对应的文件
    
    注意: 
    Docker挂载主机目录(第3步)Docker访问出现cannot open directory .: Permission denied
    解决办法:在挂载目录后多加一个--privileged=true参数即可
    

    图1
    在这里插入图片描述

    图2, 查看运行的容器id相关信息 docker inspect 容器ID
    在这里插入图片描述
    对比与总结
    在这里插入图片描述

    数据卷容器

    命名的容器挂载数据卷,其它容器通过挂载这个(父容器)实现数据共享,
    挂载数据卷的容器,称之为数据卷容器

    实现步骤

    # 1. 以上一步所建镜像为模板 ,首先启动一个父容器dc01 ,在创建容器的数据卷文夹中创建一个文件(图1)
    docker run -it --name 	dc01 zzyy/centos
    touch dc01_add.txt
    
    # 2. 创建子容器dc02,dc03继承自dc01 , 在创建容器的数据卷文夹中创建一个文件(图2)
    docker run -it --name dc02 --volumes-from dc01 zzyy/centos
    touch dc02_add.txt
    docker run -it --name dc03 --volumes-from dc01 zzyy/centos
    touch dc01=3_add.txt
    
    
    # 3. 回到dc01可以看到所有数据都被共享了(图3)
    # 4. 删除dc01, dc02修改后dc03是否可访问,可以 (图4)
    # 5. 删除dc02dc03是否可以访问, 可以(图5)
    # 6. 新建dc04继承dc03是否可以访问, 可以(图6)
    
    结论
    容器之间配置信息的传递, 数据卷的生命周期一直持续到没有容器使用它为止
    

    图1
    在这里插入图片描述
    图2
    在这里插入图片描述
    图3
    在这里插入图片描述
    图4
    在这里插入图片描述

    图5
    在这里插入图片描述
    图6
    在这里插入图片描述

    第六章 DockerFile解析

    介绍

    Dockerfile是用来构建Docker镜像文件 ,是有一系列命令和参数构成的脚本

    构建步骤

    1.编写Dockerfile文件
    2.docker build
    3.docker run

    格式

    以centos的文件为例

    FROM scratch
    ADD centos-8-container.tar.xz /
    
    LABEL org.label-schema.schema-version="1.0" \
        org.label-schema.name="CentOS Base Image" \
        org.label-schema.vendor="CentOS" \
        org.label-schema.license="GPLv2" \
        org.label-schema.build-date="20190927"
    
    CMD ["/bin/bash"]
    

    语法

    1. 每条保留字指令都必须为答谢字母且后面至少跟一个参数
    2. 指令从上到下, 顺序执行
    3. #表示注释
    4. 每条指令都会创建一个一个新的镜像层, 并提交

    Docker执行DockerFile的大致流程

    1. docker从基础镜像运行一个容器
    2. 执行一条指令并对容器做出修改
    3. 执行类似docker commit 的操作提交一个新的镜像层
    4. docker 再基于刚提交的镜像运行一个新容器
    5. 执行dockerfile 中的下一条执行, 直至所有指令都完成

    从应用软件的角度来看,Dockerfile、Docker镜像与Docker容器分别代表软件的三个不同阶段,

    • Dockerfile是软件的原材料
    • Docker镜像是软件的交付品
    • Docker容器则可以认为是软件的运行态。

    Dockerfile面向开发,Docker镜像成为交付标准,
    Docker容器则涉及部署与运维,三者缺一不可,合力充当Docker体系的基石。

    在这里插入图片描述

    1 Dockerfile,需要定义一个Dockerfile,Dockerfile定义了进程需要的一切东西。Dockerfile涉及的内容包括执行代码或者是文件、环境变量、依赖包、运行时环境、动态链接库、操作系统的发行版、服务进程和内核进程(当应用进程需要和系统服务和内核进程打交道,这时需要考虑如何设计namespace的权限控制)等等;
    2 Docker镜像,在用Dockerfile定义一个文件之后,docker build时会产生一个Docker镜像,当运行 Docker镜像时,会真正开始提供服务;
    3 Docker容器,容器是直接提供服务的

    DockerFile保留字指令

    查看tomcat的DockerFile文件 ,更好理解保留字
    在这里插入图片描述

    保留字整合案例

    自定义镜像

    我们安装的centos精简版是没有vim和ifconfig命令的支持的
    我们可以通过编写Dockerfile令其支持这些功能

    # 1.搜索centos镜像并下载
    docker search centos
    docker pull centos
    
    # 2.编写创建一个文件( /mydoker/dockerfile_centos ),编写Dockerfile ,内容如下
    --------------------------------------------------------------------
    FROM centos
    MAINTAINER timepause<qq_43371556@csdn.net>
    
    ENV MYPATH /usr/local
    WORKDIR $MYPATH
    
    RUN yum -y install vim
    RUN yum -y install net-tools
    
    EXPOSE 80
    
    CMD echo $MYPATH
    CMD echo "install vim and ifconfig commond plug-in components success"
    CMD /bin/bash
    -----------------------------------------------------------------------
    
    
    
    # 3. 编译运行centos( 注意最后的空格和点号,图1 )
    docker build -f /mydoker/dockerfile_centos -t mycentos:1.3 .
    
    # 4. 测试功能( 图2 )
    # 查看是否新增镜像
    docker ps
    # 运行新镜像 
    docker run -it mycentos:1.3
    # 在容器中使用vim 与if config命令
    
    

    图1
    在这里插入图片描述

    图2
    在这里插入图片描述

    自定义tomcat9

    # 1. 创建存放生成镜像文件的目录
    mkdir -p /myuse/mydocker/tomcat9
    
    # 2.创建相关文件(c.txt用于测试)
    touch c.txt 
    
    
    # 3.上传tomcat和jdk(一定要注意版本, 根据版本修改Dockerfile文件, 图1)
    
    #. 4.创建并编辑Dockerfile(需要提前下载centos)
    vim Dockerfile
    ---------------------Dockerfile-------------------------------
    FROM         centos
    MAINTAINER    chy<chy@qq.com>
    #把宿主机当前上下文的c.txt拷贝到容器/usr/local/路径下
    COPY c.txt /usr/local/cincontainer.txt
    #把java与tomcat添加到容器中
    ADD jdk-8u11-linux-x64.tar.gz /usr/local/
    ADD apache-tomcat-9.0.27.tar.gz /usr/local/
    #安装vim编辑器
    RUN yum -y install vim
    #设置工作访问时候的WORKDIR路径,登录落脚点
    ENV MYPATH /usr/local
    WORKDIR $MYPATH
    #配置java与tomcat环境变量
    ENV JAVA_HOME /usr/local/jdk1.8.0_11
    ENV CLASSPATH $JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
    ENV CATALINA_HOME /usr/local/apache-tomcat-9.0.27
    ENV CATALINA_BASE /usr/local/apache-tomcat-9.0.27
    ENV PATH $PATH:$JAVA_HOME/bin:$CATALINA_HOME/lib:$CATALINA_HOME/bin
    #容器运行时监听的端口
    EXPOSE  8080
    #启动时运行tomcat
    # ENTRYPOINT ["/usr/local/apache-tomcat-9.0.8/bin/startup.sh" ]
    # CMD ["/usr/local/apache-tomcat-9.0.8/bin/catalina.sh","run"]
    CMD /usr/local/apache-tomcat-9.0.27/bin/startup.sh && tail -F /usr/local/apache-tomcat-9.0.27/bin/logs/catalina.out
    ---------------------Dockerfile-------------------------------
    
    
    
    
    # 5.构建镜像(在存放这些文件的目录下,图2)
    # 如果Dockerfile文件名称就是Dockerfile,可以省略参数 -f /Dockerfile所在位置的书写
    docker build -t mytomcat9 .
    
    # 6.查看镜像并运行镜像( 图3)
    docker images
    # 运行镜像 (后台启动, 成功后如图4)
    docker run -d -p 8080:8080 --name myt9 -v /myuse/mydocker/tomcat9/test:/usr/local/apache-tomcat-9.0.27/webapps/test -v /myuse/mydocker/tomcat9/tomcat9logs/:/usr/local/apache-tomcat-9.0.27/logs --privileged=true  mytomcat9
    
    # 注意这里配置了容器卷的映射,宿主机的test文件夹映射到tomcat的webapps目录下的test文件,且二者可以互通有无. 
    docker exec -it 容器ID /bin/bash #进入容器根目录 ,可以访问相关页面
    
    # 7. 访问成功后, 添加jsp文件与web.xml文件( a.jsp用于访问测试 ,web.xml用于令jsp页面可以编译)
    vim a.jsp
    mkidr WEB-INF
    vim /WEB-INF/web.xml
    ------------------------------------------a.jsp---------------------------
    <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    <html>
      <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Insert title here</title>
      </head>
      <body>
    
        -----------welcome------------
        <="i am in docker tomcat self "%>
        <br>
        <br>
        <% System.out.println("=============docker tomcat self");%>
      </body>
    </html>
    ------------------------------------------a.jsp---------------------------
    
    
    
    ------------------------------------------web.xml-----------------------------------
    <?xml version="1.0" encoding="UTF-8"?>
    
    <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                          http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
      version="4.0"
      metadata-complete="true">
    </web-app>
    ------------------------------------------web.xml-----------------------------------
    
    # 8. 重启服务, 访问a.jsp(图5)
    # 查看当前容器id
    docker ps (查看当前容器ID)
    docker ps -a (查看所有运行过的容器ID)
    # 重启服务
    docker restart 容器ID
    # 访问a.jsp页面
    

    图1
    在这里插入图片描述
    图2
    在这里插入图片描述

    图3
    在这里插入图片描述
    图4

    在这里插入图片描述
    图5

    在这里插入图片描述

    第七章 通过Docker安装软件

    MySQL

    # 1. 以安装mysql5.6为例(不知道什么原因5.7下不来)
    docker pull mysql:5.6
    
    # 2. 运行镜像,启动容器(端口3306,root用户密码:root,运行镜像:mysql5.6)
    docker run -p 3306:3306 --name mysql -v /datebase/mysql/conf:/etc/mysql/conf.d -v /datebase/mysql/logs:/logs -v /datebase/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -d mysql:5.6
    
    # 3. 进入msql内部测试登陆
    docker ps
    ## 进入mysql的当前目录下
    docker exec -it MySQL运行成功后的容器ID/name     /bin/bash
    ## 输入账号密码
    mysql -u 账号 -p(然后根据提示输入密码)
    
    
    # 4.连接数据库的图形化界面
    ## Mysql 解决连接客户端时出现1251 client does not support ...问题
    ALTER USER  'root'@'%' IDENTIFIED WITH mysql_native_password BY 'mysql密码';
    ALTER USER  'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mysql密码';
    
    # 5. 备份数据库数据,之后我们可以通过直接读取这个sql文件恢复数据
    docker exec myql服务容器ID sh -c ' exec mysqldump --all-databases -uroot -p"root" ' > /datebase/all-databases.sql
    

    在这里插入图片描述

    Redis

    # 1.下载最新版redis镜像
    docker pull redis
    
    # 2.运行镜像(redis端口2333, -d后的redis不加参数默认为redis:latest)
    # 注意本地数据卷与容器内数据卷目录的对应
    docker run -p 2333:6379 -v /myuse/myredis/data:/data -v /myuse/myredis/conf/redis.conf:/usr/local/etc/redis/redis.conf  -d redis redis-server /usr/local/etc/redis/redis.conf --appendonly yes
    
    # 3.上传redis.conf到本地数据卷所在目录
    本地数据卷坐在目录 : /myuse/myredis/conf
    文件地址(太大了 ,这里放不下) : https://download.csdn.net/download/qq_43371556/11889084
    
    # 4. 运行redis的cil----shell命令行
    docker exec -it 运行着Rediis服务的容器ID redis-cli
    # 远程连接 docker redis
    docker exec -it redis_s redis-cli -h 192.168.1.100 -p 6379 -a your_password //如果有密码 使用 -a参数
    
    

    RabbitMQ

    # 1.下载镜像
    docker pull rabbitmq:3.7.7-management
    
    # 2.运行镜像
    docker run -d --name rabbitmq3.7.7 -p 5672:5672 -p 15672:15672 -v `pwd`/data:/var/lib/rabbitmq --hostname myRabbit -e RABBITMQ_DEFAULT_VHOST=/ -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin df80af9ca0c9
    
    -d 后台运行容器;
    --name 指定容器名;
    -p 指定服务运行的端口(5672:应用访问端口;15672:控制台Web端口号);
    -v 映射目录或文件;
    --hostname  主机名(RabbitMQ的一个重要注意事项是它根据所谓的 “节点名称” 存储数据,默认为主机名);
    -e 指定环境变量;(RABBITMQ_DEFAULT_VHOST:默认虚拟机名;RABBITMQ_DEFAULT_USER:默认的用户名;RABBITMQ_DEFAULT_PASS:默认用户名的密码)
    
    
    # 3.访问 (如下图)
    http://ip:15672
    账号 :admin
    密码: admin
    

    在这里插入图片描述

    MongoDB

    # 1.查看docker+MongoDB版本(图1)
    docker search
    
    # 2.下载最新的MongoDB
    docker pull mongo
    
    # 3.将镜像运行成容器
    docker run -itd --name mongo -p 27017:27017 mongo --auth
    ## 参数说明:
    -p 27017:27017 :映射容器服务的 27017 端口到宿主机的 27017 端口。外部可以直接通过 宿主机 ip:27017 访问到 mongo 的服务。
    --auth:需要密码才能访问容器服务。
    
    # 4.使用以下命令添加用户和设置密码,并且尝试连接。
    $ docker exec -it mongo mongo admin
    # 创建一个名为 admin,密码为 123456 的用户。
    >  db.createUser({ user:'admin',pwd:'123456',roles:[ { role:'userAdminAnyDatabase', db: 'admin'}]});
    # 尝试使用上面创建的用户信息进行连接。
    > db.auth('admin', '123456')
    

    图1
    在这里插入图片描述

    安装vsftpd+Nignx(图片服务器)

    环境搭建

    通过搭建Nginx和vfstpd 实现文件服务器

    # 1. 安装docker-compose . 实现对相关软件的配置
    curl -L https://get.daocloud.io/docker/compose/releases/download/1.25.4/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
    chmod +x /usr/local/bin/docker-compose
    
    # 2. 编写docker-compose.yml 配置文件
    ## 需要需要修改的地方的是: 
    ## /data/ftp:/home/vsftpd/ftpuser(20行), /data/ftp 是ftp中图片存放的地址
    ## /data/ftp:/home/images(11行) , /data/ftp 是Nginx来对应ftp中图片存放的地址
    ## FTP_USER,FTP_PASS 代表ftp用户的账号和密码, 需要在Linux中提前添加用户 
    ## 添加用户命令 a. useradd ftpuser,b. passwd ftpuser 然后输入自定义密码  
    ## ~/pic/nginx/conf/nginx.conf(9行), 注意! 需要提前准备Nginx的配置文件nginx.conf, ~ 代表home目录
    ## PASV_ADDRESS: 192.168.40.21, PASV_ADDRESS后面填写的是ftp服务器的ip
    ----------------docker-compose.yml---------------------
    version: '2'
    services:
      nginx-image:
        image: nginx:1.15.8
        ports:
          - "80:80"
        volumes:
          - ~/pic/nginx/html:/usr/share/nginx/html
          - ~/pic/nginx/conf/nginx.conf:/etc/nginx/nginx.conf
          - ~/pic/nginx/logs:/var/log/nginx
          - /data/ftp:/home/images
        restart: always
      vsftpd:
        image: fauria/vsftpd
        ports:
          - "20:20"
          - "21:21"
          - "21100-21110:21100-21110"
        volumes:
          - /data/ftp:/home/vsftpd/ftpuser
        environment:
          FTP_USER: ftpuser
          FTP_PASS: 1q2w3e4r
          PASV_ADDRESS: 192.168.40.21
          PASV_MIN_PORT: 21100
          PASV_MAX_PORT: 21110
          LOCAL_UMASK: 022
        restart: always
    -------------------------------------
    
    # 3. 分享上面需要nginx.conf文件放在下面了
    vim /home/pic/nginx/conf/nginx.conf
    
    # 4. docker-compose执行, 需要在docker-compose.yml所在的目录下执行
    docker-compose up -d
    
    # 5. docker ps(查看容器是否执行, 下图1)
    

    图1
    在这里插入图片描述

    上面第三步所需的nginx.conf配置文件

    # root   /data/ftp/, /data/ftp/代表的是我们上面配置的ftp图片存放的地址, 只需要修改这一处
    location / { root   /data/ftp/;i ..... }
    

    完整配置文件

    #user  nobody;
    worker_processes  1;
    
    #error_log  logs/error.log;
    #error_log  logs/error.log  notice;
    #error_log  logs/error.log  info;
    
    #pid        logs/nginx.pid;
    
    
    events {
        worker_connections  1024;
    }
    
    
    http {
        include       mime.types;
        default_type  application/octet-stream;
    
        #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
        #                  '$status $body_bytes_sent "$http_referer" '
        #                  '"$http_user_agent" "$http_x_forwarded_for"';
    
        #access_log  logs/access.log  main;
    
        sendfile        on;
        #tcp_nopush     on;
    
        #keepalive_timeout  0;
        keepalive_timeout  65;
    
        #gzip  on;
    
        server {
            listen       80;
            server_name  localhost;
    
            #charset koi8-r;
    
            #access_log  logs/host.access.log  main;
    
            location / {
                root   /data/ftp/; # /data/ftp/代表的是我们上面配置的ftp图片存放的地址, 只需要修改这一处
                index  index.html index.htm;
            }
    
            #error_page  404              /404.html;
    
            # redirect server error pages to the static page /50x.html
            #
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }
        }
    
    
    
    }
    
    

    代码测试

    1. 添加依赖
    <!--文件上传与下载-->
             <dependency>
                 <groupId>commons-net</groupId>
                 <artifactId>commons-net</artifactId>
                 <version>3.3</version>
             </dependency>
             <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
                <version>1.7.7</version>
                <scope>compile</scope>
            </dependency>
    
    1. 工具类代码
    package com.clife.common.utils;
    
    import org.apache.commons.net.ftp.FTP;
    import org.apache.commons.net.ftp.FTPClient;
    import org.apache.commons.net.ftp.FTPFile;
    import org.apache.commons.net.ftp.FTPReply;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import org.springframework.beans.factory.annotation.Value;
    
    import java.io.*;
    
    /**
     * ftp上传下载工具类
     */
    public class FtpUtil {
    
    	private static   String hostname="192.168.40.21";
    	private static   int port=21;
    	private static   String ftpusername="ftpuser";
    	private static   String ftppassword="ftpuser";
    	private static   String basePath="/data/ftp";
    	private static   String filePath="";
    
    	//日志打印
    	private static Logger logger = LoggerFactory.getLogger(FtpUtil.class);
    
    	/**
    	 * 文件上传封装方法
    	 * @param sourceFileName 本地文件绝对地址,目录+文件名, eg:D:\\1.jpg
    	 * @param targetFileName 上传到ftp服务器/data/ftp/目录下的文件名
    	 * @return
    	 * @throws FileNotFoundException
    	 */
    	public static boolean ftpUploadFile(String sourceFileName, String targetFileName) throws FileNotFoundException {
    		FileInputStream in=new FileInputStream(new File(sourceFileName));
    		boolean b = uploadFile(hostname, port, ftpusername, ftppassword, basePath, filePath, targetFileName, in);
    		return b;
    	}
    
    	/**
    	 * Description: 向FTP服务器上传文件
    	 * @param host FTP服务器hostname
    	 * @param port FTP服务器端口
    	 * @param username FTP登录账号
    	 * @param password FTP登录密码
    	 * @param basePath FTP服务器基础目录
    	 * @param filePath FTP服务器文件存放路径。例如分日期存放:/2015/01/01。文件的路径为basePath+filePath
    	 * @param filename 上传到FTP服务器上的文件名
    	 * @param input 输入流
    	 * @return 成功返回true,否则返回false
    	 */
    public static boolean uploadFile(String host, int port, String username, String password, String basePath,
    			String filePath, String filename, InputStream input) {
    		boolean result = false;
    		FTPClient ftp = new FTPClient();
    		try {
    			int reply;
    			ftp.connect(host, port);// 连接FTP服务器
    			logger.info("连接ftp成功...");
    			// 如果采用默认端口,可以使用ftp.connect(host)的方式直接连接FTP服务器
    			ftp.login(username, password);// 登录
    			logger.info("ftp用户登陆成功!!!");
    			reply = ftp.getReplyCode();
    			if (!FTPReply.isPositiveCompletion(reply)) {
    				ftp.disconnect();
    				return result;
    			}
    			//切换到上传目录
    			if (!ftp.changeWorkingDirectory(basePath+filePath)) {
    				//如果目录不存在创建目录
    				String[] dirs = filePath.split("/");
    				String tempPath = basePath;
    				for (String dir : dirs) {
    					if (null == dir || "".equals(dir)) {continue;}
    					tempPath += "/" + dir;
    					if (!ftp.changeWorkingDirectory(tempPath)) {
    						if (!ftp.makeDirectory(tempPath)) {
    							return result;
    						} else {
    							ftp.enterRemotePassiveMode();
    							ftp.changeWorkingDirectory(tempPath);
    						}
    					}
    				}
    			}
    			//设置上传文件的类型为二进制类型
    			ftp.setFileType(FTP.BINARY_FILE_TYPE);
    			//上传文件
    			if (!ftp.storeFile(filename, input)) {
    				logger.info("文件 {} 上传失败!",filename);
    				return result;
    			}
    			input.close();
    			ftp.logout();
    			result = true;
    			logger.info("文件 {} 上传成功!",filename);
    		} catch (IOException e) {
    			e.printStackTrace();
    		} finally {
    			if (ftp.isConnected()) {
    				try {
    					ftp.disconnect();
    				} catch (IOException ioe) {
    				}
    			}
    		}
    		return result;
    	}
    
    
    
    	public static void main(String[] args) {
    		//FileInputStream in=new FileInputStream(new File("D:\\1.jpg"));
    		//boolean flag = uploadFile("192.168.40.21", 21, "ftpuser", "ftpuser", "/data/ftp","", "123.png", in);
    		boolean flag = false;
    		try {
    			flag = ftpUploadFile("D:\\11.jpg", "6666.jpg");
    			System.out.println(flag);
    		} catch (FileNotFoundException e) {
    			e.printStackTrace();
    		}
    
    
    	}
    }
    
    
    1. 图片访问
      http://192.168.40.21/6666.jpg

    第八章 发布镜像到阿里云

    步骤

    # 1.登陆阿里云, 进入容器镜像服务(可以通过下方地址注册登录跳转到容器镜像服务)
    https://cr.console.aliyun.com/cn-hangzhou/instances/repositories
    
    # 2. 创建镜像仓库(图1)
    # 3. 在docker中登陆 ,根据图2,图3中的操作指南进行操作
    
    # 5. 将正在运行的容器创建成一个镜像(图4)
    docker commit 
    
    OPTIONS说明:
    -a :提交的镜像作者;
    -m :提交时的说明文字;
    
    # 4.将镜像推送到阿里云的镜像仓库(最好是根据阿里云上的操作指南)
    docker tag [ImageId] registry.cn-hangzhou.aliyuncs.com/timepause/mydocker:[镜像版本号]
    sudo docker push registry.cn-hangzhou.aliyuncs.com/timepause/mydocker:[镜像版本号]
    
    # 5. 搜索镜像 ,下载镜像(图5,图6)
    docker pull 复制的镜像地址
    

    图1
    在这里插入图片描述
    图2
    在这里插入图片描述
    图3

    在这里插入图片描述

    图4
    在这里插入图片描述
    图5
    在这里插入图片描述
    图6
    在这里插入图片描述


    点击本博客相关学习视频地址
    图片服务器参考博客

    展开全文
  • 覆盖应用开发、应用交付、上线运维等环节,包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关...
  • 容器核心技术

    2021-01-07 11:08:10
    1.什么是容器容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。 2.为什么使用容器容器使软件具备了超强的可移植能力,docker为代码提供了一个基于容器的标准化...
  • Kubernetes容器平台技术方案

    千次阅读 2020-09-25 07:00:00
    在移动互联网时代,新的技术需要新技术支持环境、新的软件交付流程和IT架构,从而实现架构平台化,交付持续化,业务服务化。容器将成为新一代应用的标准交付件,容器云将帮助企业用户构建研发流程和...
  • 概要简述 时至今日,企业IT领域中最主要的问题在于如何解决不同功能部门之间的固有摩擦。一方面,业务线的主要诉求是在市场上实现差异性竞争...在多数组织成员看来,容器技术能够切实解决双方之间所存在的各类矛盾
  • 容器技术介绍

    千次阅读 2018-12-01 23:12:19
    容器技术 基于 Linux 内核的cgroup,namespace,以及 AUFS 类的 Union FS 等技术,对进程进行封装隔离,属于操作系统层面的虚拟化技术。 容器技术与传统虚拟机技术比较 容器技术和传统虚拟机技术都属于操作系统级别...
  • 深入理解分布式技术 - 容器技术

    千次阅读 2021-02-11 20:58:08
    相比传统虚拟化技术,容器技术是一种更加轻量级的操作系统隔离方案,可以将应用程序及其运行依赖环境打包到镜像中,通过容器引擎进行调度,并且提供进程隔离和资源限制的运行环境。 虚拟化技术 虚拟化技术通过 ...
  • 我们为什么使用容器? 我们为什么使用虚拟机(云主机)? 为什么使用物理机? 这一系列的问题并没有一个统一的标准答案。因为以上几类技术栈都有自身最适用的场景,在最佳实践之下,它们分别都是不可替代的。 原本...
  • 内容摘要 近年来,容器技术及相关应用得到了国内外越来越多的关注度,研发和应用...其主要内容包括: 一、针对容器技术现状进行研究和分析。一是梳理了容器技术从开始到现在的发展历程,对现有容器发展的生态结构进行
  • Docker 容器技术介绍(一) 之 虚拟化技术 Docker 容器技术介绍(二) 之 Docker 简介 Docker 容器技术介绍(三) 之 Docker 组件 Docker 容器技术介绍(四) 之 Docker的安装与启动 Docker 容器技术...
  • Docker容器技术概述

    2019-08-24 22:49:55
    容器生态系统包括容器技术和容器平台技术(容器编排引擎、容器管理平台、基于容器的paas)。 容器技术是学习容器的核心知识;容器编排引擎在大规模生产部署中非常重要;容器管理平台是架构在容器编排引擎之上,抽象...
  • 容器VS虚拟机容器和虚拟机作为虚拟化技术,为我们提供了一个隔离的、独立的运行环境,但两者最大的不同之处是容量具有轻量级的优势,上图可以看到,每个虚拟机内部都有完整的操作系统,但一个主机上运行的多个容器是...
  • 容器技术详解

    千次阅读 2018-11-21 21:03:59
    IT里的容器技术是英文单词Linux Container的直译。container这个单词有集装箱、容器的含义(主要偏集装箱意思)。不过,在中文环境下,咱们要交流要传授,如果翻译成“集装箱技术” 就有点拗口,所以结合中国人的...
  • 嵌入式Linux容器技术

    千次阅读 2019-08-13 14:59:21
    嵌入式Linux容器技术 一、Linux容器技术 Linux Container容器是一种内核虚拟化技术,可以提供轻量级的虚拟化,以便隔离进程和资源。 LXC为Linux Container的简写。可以提供轻量级的虚拟化,以便隔离进程和资源,...
  • 文章目录资源隔离的两种主要方案虚拟机VS容器容器技术的资源隔离从容器到Docker 资源隔离的两种主要方案   在服务器或者大型计算机集群中,往往需要运行大量作业和应用,为保证这些作业和应用的进程之间互不干扰,...
  • 容器技术概述

    千次阅读 2019-06-06 10:27:39
    -----容器技术概述----- 容器技术是这两年热门的话题,因为容器技术给我们带来了很多方便的地方,节约了不少成本,不管是在运维还是开发上。而如今最热门的开源容器工具就是docker了,虽然不少人已经使用过docker,...
  • 容器技术之发展简史

    千次阅读 2020-10-16 13:36:20
    云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。”聊容器技术避不开云原生,聊云原生也避不开容器技术容器技术和云原生就是一对双螺旋体,容器技术催生了云原生思潮,云原生生态推动了...
  • 同步类容器和并发类容器

    万次阅读 多人点赞 2019-07-31 19:22:20
    为什么会出现同步容器? 在Java的集合容器框架中,主要有四大类别:List、Set、Queue、Map。 注意Collection和Map是顶层接口,而List、Set、Queue接口则分别继承了Collection接口,分别代表数组、集合和队列这三大...
  • 容器技术的概念

    千次阅读 2019-11-18 16:58:04
    容器技术是英文单词Linux Container的汉译。Linux Container两个单词,第一个Linux表明了容器技术一般是应用在Linux操作系统上面;Container意思有:容器,集装箱,货柜的意思,为了方便理解,这里采用集装箱的汉译...
  • 容器平台使用体验:DaoCloud

    万次阅读 2016-09-06 13:58:41
    容器技术风起云涌,在国内也涌现出了很多容器技术创业公司,本文介绍容器厂商DaoCloud提供的容器云平台,通过使用容器云平台,可以让大家更加了解容器,并可以学习不同容器云平台的优势。  1. 首先我们进行注册:...
  • 容器技术docker

    2018-08-20 11:49:11
    容器技术docker是什么? Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。 容器是完全使用沙箱机制,相互之间不会有任何...
  • 本文个人博客地址为:http://www.huweihuang.com/article/kubernetes/paas-based-on-docker&amp;kubernetes/本文个人博客地址为:...amp;kubernetes/【编者的话】目前很多的容器平台通过Doc...
  • docker容器核心技术

    千次阅读 2019-09-05 18:30:45
    容器技术的核心功能,就是通过约束和修改进程的动态表现,创造出一个“边界”,通过“障眼法”让人觉得它是一个独立的系统。大多数容器都是使用 Cgroups 技术来约束进程,通过 Namespace 技术来修改进程的视图。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 334,364
精华内容 133,745
关键字:

容器平台技术包括