QCon[上海站] 全球软件开发大会2016 基于云平台的 Docker多租户安全 SPEAKER 汤志敏 ’ alt=‘OCR图片’/> 关注InfoQ官方信息及时获取QCon软件开发者大会演讲视频信息 [北京站] 2016年12月2日-3日 咨询热线：010-89880682 QCon全球软件开发大会 [北京站] 2017年4月16日-18日 咨询热线：010-64738142 目录 Docker hub的Organization &team 云平台的主子账号和平行账号 LDAP&AD 4. 阿里云容器服务案例介绍 阿里云容器产品介绍 场景一：基于GPU安全隔离的深度学习方案 场景二：基于网络拓扑发现的运行时安全 ’ alt=‘OCR图片’/> 1 阿里云容器产品介绍 • 阿里云容器产品 • 容器镜像服务 • 容器服务 • 云市场-容器生态 • 支持公有云+金融云 云基础设施 全兼容开源标准 无缝集成云服务 DevOps赋能 ’ alt=‘OCR图片’/> 4.2 基于GPU安全隔离的深度学习方案 Step1:通过Docker Compose描述应用架构 ’ alt=‘OCR图片’/> 4.2 基于GPU安全隔离的深度学习方案 Step2:通过DevOpsSec流水线持续迭代 拉取镜像 阿里云容器服务 4.3 基于网络拓扑发现的运行时安全

◆ 分布式环境下开发的调测效率问题 ◆ 应对之道 ➢ 远程应用服务 ➢ 契约测试 ➢ 分布式消息服务 ➢ 分布式缓存 ➢ 分布式服务的“租户”隔离策略 ◆ 总体调测框架实践 ◆ 分布式环境下调测方法论 ## 应用的发展演变历史 ## 微服务  资源的“逻辑”隔离机制 ## 完整的调测框架 ## ●SDK ●测试骨架 ●多级开关控制 ●网络及故障模拟 ![Image](/uploads/documents/e/0/0/a/e00a136453b21

路由/无热点 设施的伸缩 区 存储/缓存 Message Driven 消息驱动 Dubbo/RPC服务 MetaQ异步 反应式架构理念 Responsive 响应性 复制/遏制隔离/委托 存储/缓存 业务方 VS 设备在线状态 面向用户 推模式 关注基础稳定和网络效率 请求应答 消息模型 长连通道 Resilient 抵御性 面向失败 拉模式 关注领域建模和消息驱动 电商消息核心模型 ## 核心设计理念： 1. 模型抽象：消息和会话，消息归属于会话 2. 用户维度：收件箱和会话视图 3，协议扩展：端到端模型协议和业务标识 4，业务隔离：模型中携带租户标识 基础能力 租户能力 ## 收件箱模型 会话能力 会话CID 消息Message模型 接收账号 扩展ext 收件箱状态 消息ID 变更时间 发送账号 扩展能力 消息ID 淘宝  namespace 业务租户 发送时间 namespace 会话CID 千牛 bizType业务标识 UI扩展 模板ID 消息结构体 业务扩展 ext扩展属性 天猫 ## UI模板定义 1. 单条消息免打扰/强提醒

系统架构与设计理念 ## 一 切服务皆应用 系统接口 通用的系统管理入口 高内聚 一切皆应用 所有应用自由安装卸载极简、高内聚、高度抽象提供最基础的核心能力 云内核驱动 容器管理、编排调度、资源隔离 驱动层实现资源抽象 运行不受限 ⾃由切换，到处运⾏ ## 云操作系统  core boot 租户管理 集群镜像 应用管理 > Kubernetes 计算驱动 网络驱动 裸金属 AWS Desktop ![Image](/uploads/documents/1/7/ 大道至简 ## sealos 的能力 ## 应用管理 10 秒上线一个自带域名和 https 的 nginx 应用 其它应用同理如博客系统 低代码平台等 ## 多租户管理 - 一个集群多个部门多个组织共同使用 - 相互安全隔离 - 支持共享与协作 ## 数据库 • 20 秒启动高可用 mysql/pgsql/mongo/redis 数据库 ## 自 ## 函数计算 • 写代码像写博客一样简单

为了保证MySQL的高可用，需要在Docker容器分配时如何保障主从不在同一宿主机上。我们通过自研Docker容器调度平台管理所有宿主机和容器，自定义Docker容器的分配算法。实现了MySQL的高密度，隔离化，高可用化部署。 调度规则： 1. 同一复制集群的实例在不同主机上。 2.优先分配CPU、内存、磁盘空间资源最空闲的主机。 3.根据IO需求调度容器创建在不同IO类型的主机。 4. 申请 服务镜像、监控服务端镜像 ## 资源隔离 CPU最大超卖3倍，通过cpu-period配合cpu-quota一起使用，来限制容器的CPU的使用量。比cpuset-cpus绑定CPU的方式灵活。 限制容器内存，且内存不超卖。通过—memory限制内存，同时结合MySQL自身参数控制几个内存大户(比如buffer_pool等)，最后配合lxcfs增强隔离性。 IO方面由于我们采用挂载宿主机本 备，还不能做到彻底隔离。所以对于高IO的实例使用的是PCIE-SSD。磁盘空间方面，我们在申请时会预估出一个量，使用超过80%的时候会结合本地磁盘空间评估是否有足够空间扩容，若宿主机剩余空间不足会启动迁移扩容流程 目前使用的host模式，无法隔离网络。但是考虑到10G接入，且单机密度可控的情况下，网络消耗不会过载。另外目前我们已经在线下尝试结合Ovs+DPDK的方案实现网络隔离。 PS：容器虚