如何优化 Linux系统（能够不说太具体）？
一、root，添加普通用户，经过sudo受权管理；二、更改默认的远程链接SSH服务端口及禁止root用户远程链接；三、自动更新服务器时间；四、配置国内yum源；五、关闭selinux及iptables（iptables工做场景若是有外网IP必定要打开，高并发除外）； 六、调整文件描述符的数量；七、精简开机启动服务（crond rsyslog network 会先找本机的host文件，再找本地设置的DNS服务器，若是也没有的话，就去网络中找根服务器，根服务器反馈结果，说只能提供一级域名服务器.cn，就去找一级域名服务器，一级域名服务器说只能提供二级域名服务器..cn，就去找三级域名服务器，三级域名服务器正好有这个网站， 而后发给请求的服务器，保存一份以后，再发给客户端。
答：RabbitMQ也就是消息队列中间件，消息中间件是在消息的传息过程当中保存消息的容器；消息中间件再将消息从它的源中到它的目标中标时充当中间人的做用；队列的主要目的是提供路由并保证消息的传递；若是发送消息时接收者不可用；消息队列不会保留消息，直到能够成功地传递为止，固然，消息队列保存消息也是有期限地。
优点：(1).RabbitMQ易于使用和部署，适宜于不少场景如路由、负载均衡或消息持久化等，用消息队列只需几行代码便可搞定。(2).对外提供客户端API，支持多种编程语言。(3).基于erlang语言开发具备高可用高并发的优势，适合集群服务器。(4). 健壮、稳定、易用、开源、跨平台、支持多种语言、文档齐全。(5). 有消息确认机制和持久化机制，可靠性高。
劣势：(1).这使得它的可扩展性差，速度较慢，由于中央节点增长了延迟，消息封装后也比较大。
Kafka：具备如下特性：快速持久化，能够在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既能够达到10W/s的吞吐速率；彻底的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，Kafka经过Hadoop的并行加载机制来统一在线和离线的消息处理。
优点:(1).经过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即便数以TB的消息存储也可以保持长时间的稳定性能。(2).高吞吐量：即便是很是普通的硬件kafka也能够支持每秒数十万的消息，适合产生大量数据的互联网服务的数据收集业务。(3).支持经过kafka服务器和消费机集群来分区消息。(4).支持Hadoop并行数据加载。
zookeeper=文件系统+通知机制；是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序能够基于它实现同步服务，配置维护和 命名服务等。Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，因为工程师不能很好地使用锁机制，以及基于消息的协调 客户机添加进组）。四、建立一个安装zabbix客户端的剧本。五、执行该剧本。六、验证。
怎么开启自定义监控：一、写一个脚本用于获取待监控服务的一些状态信息。二、在zabbix客户端的配置文件zabbix_agentd.conf中添加上自定义的“UserParameter”，目的是方便zabbix调用咱们上面写的那个脚本去获取待监控服务的信息。三、在zabbix服务端使用zabbix_get测试是否可以经过第二步定义的参数去获取zabbix客户端收集的数据。四、在zabbix服务端的web界面中新建模板，同时第一步的脚本可以获取什么信息就添加上什么监控项，“键值”设置成前面配置的“UserParameter”的值。五、数据显示图表，直接新建图形并选择上一步的监控项来生成动态图表便可。
zabbix 自定义发现是怎么作的？
一、首先须要在模板当中建立一个自动发现的规则，这个地方只须要一个名称和一个键值。二、过滤器中间要添加你须要的用到的值宏。三、而后要建立一个监控项原型，也是一个名称和一个键值。四、而后须要去写一个这样的键值的收集。
自动发现实际上就是须要首先去得到须要监控的值，而后将这个值做为一个新的参数传递到另一个收集数据的item里面去。
zabbix 是怎么实施监控的：
一个监控系统运行的大概的流程是这样的：agent须要安装到被监控的主机上，它负责按期收集各项数据，并发送到zabbix server端，zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展示和绘图。
【主动监测】通讯过程以下：
Agent打开TCP链接（主动检测变成Agent打开）
Agent开始收集数据
主动检测提交数据过程以下：
Server处理数据，并返回响应状态
【被动监测】通讯过程以下：
Agent接收到请求而且响应
Server处理接收到的数据
zabbix主被动模式有啥区别：zabbix有啥特色：
server不能及时获取到最新的数据。
主动模式：即由zabbix agent主动采集数据并返回给zabbix server，不须要zabbix server的另行干预，所以使用主动模式能在必定程序上减轻zabbix server的压力。zabbix可横向扩展、自定义监控项、支持多种监控方式、可监控网络与服务等。

王旭 蚂蚁金服资深技术专家，kata containers 架构委员会成员
刘奖 阿里云操作系统资深技术专家

本文根据云栖大会容器专场演讲内容整理，关注阿里巴巴公众号，回复“安全”获得本文 PPT

大家中午好，感谢大家在饥肠辘辘的中午不离不弃地来到我们的会场，我们带给大家的这段相声是关于安全容器技术的。我是王旭，半年前刚刚结束一段创业，和团队一起加入了蚂蚁金服，创业期间，2017 年，我们在德州奥斯汀，和 Intel OTC 一起发布了 Kata Containers 安全容器项目，是这个项目的创始人之一；和我一起的是阿里云智能的奖哥，他是阿里云容器服务 ECI 的台柱子，也是 rust-vmm 开源项目的积极维护者。

（图左为蚂蚁金服资深技术专家 王旭，图右为阿里云操作系统资深技术专家 刘奖）

我们见证了容器安全和安全容器技术在争议中的发展，今天想要结合社区里和阿里云上安全容器的沿革，谈谈对安全容器技术未来发展的思考。 这次的分享分为四个部分：

• 当前容器技术应用和安全问题的现状
• 阿里云内外的安全容器技术发展的历程
• 阿里云服务中的安全容器
• 我们乃至整个社区正在做的技术努力

本文根据云栖大会容器专场演讲内容整理，关注公众号，回复“安全”获得本文 PPT

众所周知，容器化、微服务化、云原生化是当前 IT 系统演进的趋势。根据 Portworks 和 Aqua Security 的调查报告显示，被调查的大多数企业都不是正在使用容器，就是考虑使用容器。 上午过来时和刚才演讲的 Chris 聊天的时候，他也提到，今年年底 San Diego 的 KubeCon 预计会有一万两千人来参会，他还特别提到一点：云原生化不仅是改变已有应用的架构，更是促进了更丰富的服务的开发，IT 系统的服务规模是在加速提升的。 不过，尽管容器技术炙手可热，但挑战还是存在的。这里需要引用一个 tripwire 调查报告，来源链接在。

可以看到，大概有半数的企业，尤其是运行了 100 个以上容器的企业，认为他们的容器是有安全漏洞的，当然，还有很大比例的人表示并不确认他们的容器是否有安全漏洞。我们都知道，安全不仅是个技术问题，也是个信心问题，粉红色字的这段就是这个意思，因为对容器安全的担心，42% 的受访者是无法全身心地拥抱容器生态的。 当然，我得说，关心安全问题是个好的信号，因为只有当你准备把一项技术真正用于生产环境的时候，才会从安全角度去认真审视它。和其他领域差不多，容器安全也是一项端到端的技术，从容器镜像本身的安全性和完整性，到运行容器的软硬件平台的基础设施安全性，再到容器运行时引擎的安全性都需要被照顾到，哪个都可能成为最短的那根板子。

说到容器的安全，我们可以回到容器的春秋战国时期了，不谈遥远的 FreeBSD Jail 和 Solaris Zone，我们从最终进入 Linux Kernel 的这组 Namespaces 和 cGroups 来看，这套容器技术实际上同样是从进程调度的角度入手，对内核进行的功能扩展，优势上来说，操作界面很 Linux、很方便，开销也很低，可以被用来无负担地套在已有应用外面来构建隔离的环境，并且它是纯软件方案，不和其他层面的物理机、虚拟机相冲突。

然而，它的问题也在于它仍然是 Linux Kernel 的一个部分，已有的 Linux 的隔离问题无法根除，甚至可能因为新加入功能而被放大。所以，2015 年西雅图的 LinuxCon 上，Linus 在 Keynote 上接受访问的时候，就直接说出，Bug 是没有办法的，要安全必须要有隔离层。（原文为: _The only

隔离层，这里所谓隔离层就是让应用容器运行在自己的内核之上，不和其他容器共享。这里面最简单的方案就是把容器放在虚拟机里跑（左1），这种方式不需要对软件栈做改动，只是让同一个用户的容器跑在自己的虚拟机里，但这样带来的问题，除了额外的开销之外，还有两层的维护复杂度。 另一种源远流长的独立内核的方案是 unikernel（右1），让应用自己带上自己的内核，这种方式的好处是最简化的 LibOS 不仅可以有更小的开销，也可以有更小的攻击面，但阻止它被更广泛应用的问题在于它往往需要修改应用，兼容性永远是平台技术被采纳的最大障碍。

所以，针对未修改的应用的安全容器方案就落在了中间两种方案——MicroVM 和进程虚拟化上，前者是使用了轻量级虚机和裁剪过的 Linux 内核，在保证兼容性的前提下尽量降低运行时和维护的开销，而后者则是使用一个特定的内核来提供 Linux ABI，直接虚拟化进程的运行环境，为 Linux 应用尽量提供最大兼容性。 Kata Containers 就是这样一个 MicroVM 不同它使用了硬件虚拟化能力，直接面对用户应用的不再是宿主机的内核，而是一个独立的装在虚拟机里的内核，即使有未知的安全漏洞导致这个内核被攻击，攻击者仍然无法轻易突破虚拟化技术构建的沙箱。

Kata Containers 项目由我们和 Intel 一起在 2017 年开源，去年 4 月份成为 OpenStack 基金会旗下的七年来第一个顶级开放基础设施项目。作为一个社区化项目，这个项目还有很多阿里云和蚂蚁以外的开发者，目前项目正在讨论 2.0 版本的路线图，也欢迎大家为项目贡献代码和需求。 从技术上说，在 Kubernetes 生态里，Kata 里面有多少容器，这对宿主机调度器也是比较友好的。

Shim 会通过 vsock 控制 MicroVM 里面的 agent 来管理 Pod 里面的 OCI 容器，这里，社区版本的 Kata 支持的 VMM 包括了 Qemu 和 AWS 开源的 FireCracker，前者功能更丰富、兼容性更好，后者更轻小，根据我们阿里巴巴的“既要、又要、还要”的精神，你不需要舍弃哪一个，用上 Kubernetes 的 RuntimeClass，你可以为每个 Pod 指定要用的 VMM。具体的 How to 类的细节，你可以看我们 GitHub 上的文档也可以在 Slack channel 里讨论，遇到问题别忘了开 issue，这也是对社区的巨大支持，不是只有写代码才算贡献开源的。

类似的基于 MicroVM 类技术的容器方案实际还有不少，耳熟能详的还有微软的  Hyper-V Container 和最近在 Windows 里集成的 WSL2，从数量上说，这类方案是目前的主流，最重要的原因就是对一般 Docker Image 的完美兼容性，而这种方案里最正统的开源方案当然就是我们 Kata 了。当然基于进程虚拟化的方案有很多亮点的，其中最大的亮点当然是 Google 开源的 gVisor 了，因为它开源的时候的 Google 的项目技术 Leader 就是现在我的老板，何征宇。

从 2013 年到 2019 年的 6 年时间里，容器技术及生态每年都往前迈进一大步，经历了从提出技术理念、构建合作生态到商业落地应用的飞速发展周期，到达了论坛开篇演讲中所提到的“拐点已至”的阶段。 让我们一起简要回顾一下阿里云安全容器与安全沙箱技术的发展历史。 

• Docker 理念被提出一年多之后，2015 年产业界开始共同推进容器技术及生态。阿里云、Hyper.sh 和 Intel 等都意识到 runC 的局限性，开始基于虚拟机技术构建容器的安全运行环境。
• 经过一年的研发期，2016 年安全容器技术开始进入生产环境。阿里云研发的 vLinux 技术在 MaxCompute 场景落地应用，Hyper.sh 也基于 runV 对外提供容器服务。这一年还发生一个非常重要的事情：K8s 定义了 CRI 接口规范，用于对接多种形态的容器运行环境，从而为安全容器和 K8s 生态的融合提供坚实的基础。
• 2017 年微软开放了 ACI 容器服务，阿里云也研发了基于虚拟机的容器服务。
• 2018 年阿里云开放基于虚拟机的容器服务，同时开始研发基于 MicroVM 路线的安全沙箱技术。这一年 Google 开源了 gVisor，AWS 开源了 firecracker。

 从 2017 年底开始，Kata、gVisor、Firecracker、Nabla、Cloud Hypervisor 等开源安全容器技术不断涌现，技术进入井喷期。非常高兴的是 Hyper 团队今年加盟阿里数字经济体，一起为我们的客户打造安全可靠的容器运行环境。 刚才介绍中提到了不同的容器 runtime 技术，可能大家心中会有个疑问，这些技术的关系和区别是什么呢？

我以生活中的常见租房为例来打个比方，方便大家理解容器 runtime 的区别。 

• runC 就类似群租房，装修简单、利用率高，但是隔音、安全和入住体验稍差
• 阿里云安全沙箱类似酒店式公寓，提供全功能的、标准化、带客房服务的入住体验
• VM + containerd 则类似租普通住房，公摊面积大，还可能需要自己装修
  

阿里云安全沙箱就是致力于打造酒店式公寓，为客户提供拎包入住式的容器服务。

 正如大家所了解的，阿里巴巴既有像淘宝、天猫、高德等众多面向个人消费领域的业务，也有阿里云、钉钉等面向企业服务的业务。作为底层基础技术的安全沙箱技术，需要支持多种应用场景。综合各种业务场景，大致能归纳出三种典型的应用模式： 

• 第一种是面向公共云服务的容器服务。这种应用场景下，我们既需要保证基础设施的安全性，也需要严格保证客户的数据安全以及租户之间的隔离性。我们需要提供酒店式公寓而不是群租房或合租房。
• 第二种是需要在一台服务器上同时执行可信代码和不可信代码的场景。比如，需要执行用户上传的代码、无源代码的可执行文件或未经审计的开源代码的情况。这是安全沙箱的最典型用法，通过安全沙箱构建一个带安全边界的执行环境，把不可信代码限定在这个受限的执行环境中，从而保护系统中的其它组件。
• 第三种是多种业务混合部署的场景。为了提高资源利用率，主流技术思路之一是把在线业务和离线业务混合部署在相同的服务器上，利用在线服务的剩余资源来为离线任务服务。这是相当挑战的一个任务，传统做法是通过为在线任务预留足够的资源来保证在线服务的服务体验。那么，混部的情况下如何保证在线任务的服务体验呢？思路也很简单，给予在线业务较高的优先级。但是这还不足够，由于共享内核，内存分配、IO 调度方面，离线任务还是会经常干扰在线任务。所以把离线任务放入独立的安全沙箱，实现资源隔离、故障隔离、环境隔离。

基于以上的业务需求，我们研发了阿里云安全沙箱技术，立足于阿里云成熟稳定的基础设施、基于 MicroVM 技术路线，为业务构建安全、可靠、轻量、生态兼容的容器 runtime。 阿里云安全沙箱是基于 MicroVM 构建的安全容器 runtime。首先它是一个基于硬件虚拟化技术的 MicroVM，采用了深度定制优化 hypervisor，极简的虚拟机设备模型，VMM 基本上不访问 guest memory。其次阿里云安全沙箱也是一个容器 runtime，提供镜像分发、镜像管理、容器网络、容器存储，完全兼容 OCI 和 CRI 规范。  

阿里云安全沙箱的安全来源于新型安全系统语言、极小而可控的源代码、极简的设备模型、深度定制的 Hypervisor以及安全加固的阿里云 Linux for Sandbox 系统。 那么，阿里云安全沙箱能给客户带来什么价值呢？除了安全可靠外，阿里云安全沙箱还会给客户带来极速启动、极致弹性和低资源开销。实际测试数据表明，去掉下载容器镜像的时间，阿里云安全沙箱启动容器实例耗时小于500毫秒，在 96CPU 的系统上每秒启动实例数量大于 200 个，平均每个 microvm 的内存资源好用小于 2.5M。 那么安全容器的下一步挑战是什么呢？用户理想中的容器运行 runtime 是什么样的呢？

• 像 runC 一样的兼容性和易用性

在过去，蚂蚁金服和阿里云就是安全容器的积极贡献者，在接下来的时间里，我们仍然会继续和开源社区紧密合作。我们会开放地和社区共同制定 Kata Containers 2.0 的路线图，把我们在容器和云服务领域的最佳实践反馈给社区，将通用性的技术贡献到 Kata Contaienrs 和 Rust-VMM 社区，保证阿里巴巴 CloudSandbox 和社区的一致性，和业界一起为广大用户打造一个安全、可靠、高效和兼容生态的容器 runtime。

作者简介：王旭，蚂蚁金服系统部容器和云原生基础设施方向的资深技术专家，OpenStack 基金会顶级项目 Kata Containers 的架构委员会创始成员。刘奖，现任职阿里云操作系统部资深技术专家，负责云原生底层系统架构设计与实现，长期致力于操作系统技术研发，是国内Linux、OpenSolaris 内核主要贡献者之一。

“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术公众号。”

LXC为Linux Container的简写。可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace。容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。

与传统虚拟化技术相比，它的优势在于：

（1）与宿主机使用同一个内核，性能损耗小；

（2）不需要指令级模拟；

（4）容器可以在CPU核心的本地运行指令，不需要任何专门的解释机制；

（5）避免了准虚拟化和系统调用替换中的复杂性；

（6）轻量级隔离，在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享。

总结：Linux Container是一种轻量级的虚拟化的手段。

Linux Container提供了在单一可控主机节点上支持多个相互隔离的server container同时执行的机制。Linux Container有点像chroot，提供了一个拥有自己进程和网络空间的虚拟环境，但又有别于虚拟机，因为lxc是一种操作系统层次上的资源的虚拟化。

docker并不是LXC替代品，docker底层使用了LXC来实现，LXC将linux进程沙盒化，使得进程之间相互隔离，并且能够课哦内阁制各进程的资源分配。

在LXC的基础之上，docker提供了一系列更强大的功能。

docker是一个开源的应用容器引擎，基于go语言开发并遵循了/

5、为什么docker越来越受欢迎

• 容器化越来越受欢迎，因为容器是：

• 灵活：即使是最复杂的应用也可以集装箱化。

• 轻量级：容器利用并共享主机内核。

• 可互换：您可以即时部署更新和升级。

• 便携式：您可以在本地构建，部署到云，并在任何地方运行。

• 可扩展：您可以增加并自动分发容器副本。

• 可堆叠：您可以垂直和即时堆叠服务。

8、容器在内核中支持2种重要技术

• cgroup的api以一个伪文件系统的实现方式，用户的程序可以通过文件系统实现cgroup的组件管理

• cgroup的组件管理操作单元可以细粒度到线程级别，另外用户可以创建和销毁cgroup，从而实现资源载分配和再利用

• 所有资源管理的功能都以子系统的方式实现，接口统一子任务创建之初与其父任务处于同一个cgroup的控制组

• 资源限制：可以对任务使用的资源总额进行限制

• 优先级分配：通过分配的cpu时间片数量以及磁盘IO带宽大小，实际上相当于控制了任务运行优先级

• 资源统计：可以统计系统的资源使用量，如cpu时长，内存用量等

• 任务控制：cgroup可以对任务执行挂起、恢复等操作

9、了解docker三个重要概念

• 发布服务不用担心服务器的运行环境，所有的服务器都是自动分配docker，自动部署，自动安装，自动运行

• 再不用担心其他服务引擎的磁盘问题，cpu问题，系统问题了

• 自动迁移，可以制作镜像，迁移使用自定义的镜像即可迁移，不会出现什么问题

• 面向开发：简化环境配置

• 面向架构：自动化扩容（微服务）

• image 负责与镜像源数据有关的存储、查找，镜像层的索引、查找以及镜像tar包有关的导入、导出操作

• reference负责存储本地所有镜像的repository和tag名，并维护与镜像id之间的映射关系

• layer模块负责与镜像层和容器层源数据有关的增删改查，并负责将镜像层的增删改查映射到实际存储镜像层文件的graphdriver模块

• graghdriver是所有与容器镜像相关操作的执行者

三、docker架构2各个模块的功能（带完善）