文章类型: 排序方式:
Docker Desktop不再对大企业免费 新增月费21美元的订阅
为探索可持续的商业模式,Docker 近日宣布限制个人或者小型企业使用免费版 Docker Desktop 工具,并推出了更贵的订阅选项。目前,Docker 已经将免费计划更名为“Personal”,现在要求拥有 250 名及以上员工,或年营收高于 1000 万美元的企业,如果他们需要 Docker Desktop,必须使用付费订阅。
基于Windows Server 2022 微软发布新Docker容器镜像
今天微软发布了 1 个 Windows Base OS 容器镜像,在现有的 Nano Server、Server Core 和 Windows 基础上新增了 Windows Server base OS 容器镜像。这个新镜像建立在 Windows Server 2022 with Desktop Experience,和当前的 Windows 镜像相比,全新的 Server 镜像主要提供以下内容:
Docker Desktop现已正式提供为Apple Silicon Mac打造的原生版本
对于热衷于长期使用 Apple Silicon Mac 的 Docker Desktop 开发者们来说,Docker 首席技术官 Justin Cormack 刚刚宣布了一个好消息。经过持续数月的 Beta 测试,M1 Mac 原生版 Docker Desktop 已于 4 月 15 日正式上线。与此前通过 Rosetta 转译的非原生版本相比,新软件能够带来更快、更安静的使用体验,并且同样易于安装和运行。
Docker Desktop 3.0.0发布:为M1 Mac设备引入初步支持
本周四,我们迎来了 Docker Desktop 的 3.0.0 版本。其最大的变化,就是提供了对 Apple Silicon 的支持。如果你想要在 13 英寸的 M1 MacBook Air / Pro 或 Mac mini 上使用 Docker Desktop,现无需担心在体验上有任何妥协。与此同时,Docker 最新预览版也引入了对 Windows Linux 子系统(WSL 2)的 GPU 支持。
Docker 禁止美国“实体清单”主体使用 其开源项目不受影响
Docker 公司最新的服务条款8月13日生效。条款引起关注的地方简单来说就是,Docker 公司提供的服务,禁止美国“实体清单”上的实体使用。Docker 公司相关条款写道:
Visual Studio Online更新 更好的Go、Python语言和Docker支持
在 2019 年 11月,公开预览版的 Visual Studio Online 正式上线。时隔多月,微软又发布了 Visual Studio Online 的最新更新。Visual Studio Online 的程序经理 Allison Buchholtz-Au 表示,“我们很高兴为您带来几个新功能,从增强的环境配置和自定义 Dockerfile 支持、到启用对环境的设置更改,一应俱全。”
微软Visual Studio Online更新,更好地支持Python语言和Docker
在 2019 年 11月,公开预览版的 Visual Studio Online 正式上线。时隔多月,微软又发布了 Visual Studio Online 的最新更新。Visual Studio Online 的程序经理 Allison Buchholtz-Au 表示,“我们很高兴为您带来几个新功能,从增强的环境配置和自定义 Dockerfile 支持、到启用对环境的设置更改,一应俱全。”为了更好地控制环境设置并提高可重复性,该团队启用了对 Docker 镜像和 Dockerfile 的支持,并通过新的 progress screen 提供了对环境创建的更多见解。用户还可以指定 GitHub 拉取请求或分支 URL,从而实现快速访问。利用带有新进度指示器的 Dockerfile 创建环境。同时,根据用户反馈,开发团队已经扩展了默认环境配置,以包括 PowerShell、Azure CLI、Go 和 C ++ 的本机调试,还有更新的 .NET Core SDK 和改进的 Python 支持。微软方面还表示,他们在此版本中启用了在创建后更改环境设置的功能。从而允许开发人员从用于编辑代码的标准实例开始,并能够在需要更多功能时升级到高级实例。用户还可以更改 suspension policy,以在环境的整个生命周期内更灵活地进行控制。用户可以从门户网站更改环境设置,也可以使用 Visual Studio Code 命令面板进行更改。而针对用户曾经创立了但现在又不再需要的计划;其除了可以转到 Azure 页面进行计划删除外,还可以通过浏览器和 Visual Studio Code 删除计划。此外,该团队目前已经在浏览器中启用了 Visual Studio Code Insiders,因此用户已可以在浏览器或本地计算机上试用 Visual Studio Code 的最新功能。
以Docker为代表的传统容器已到生死存亡之际
云原生是一座由精妙理论所构筑的摩天大厦,但其中的砖石还需加固。当云原生将容器技术作为下一代云计算的基础之一时,并不意味着容器本身停止了演化。事实上,以Docker为代表的传统容器在遇到多租户场景时,它的安全问题立刻暴露了出来,这时,人们才怀念起虚拟化的好处。于是,采用虚拟化技术的“安全容器”这一概念应运而生,而开启这一变革的,正是Kata Containers,前不久,它刚刚度过两周年。新的Kata Containers为我们带来虚拟机的安全性和隔离性、与容器兼容的API接口,同时还有与容器同一级别的性能,这意味着采用安全容器的时机已经成熟。与此相对的是,上个月,Docker的企业级业务被打包出售,据称出售价格甚至不及几轮下来的融资总额。所有在生产环境使用容器的公司,从现在开始都有必要审视自己的安全策略,并制定从容器到安全容器的迁移计划。这一切是怎么发生的呢?听我为你一一道来。Docker的溃败2019年11月13日,私有云基础设施公司Mirantis在其官方博客宣布,收购Docker公司企业级业务,包括接管它的700多个客户,这标志着Docker公司从2013年开始的商业化探索彻底失败。在不了解容器发展历史的人看来,这种结果很难理解,Docker是容器热潮的开创者,容器则是这一轮云计算技术演进的开启者,为什么明明站在风口上了,却仍然飞不起来?这与Docker创始人的一系列迷之操作固然脱不了干系,但其实,Docker今天的命运,在4年前就决定了。在2013年以前,业界其实一直都没有找到云计算原生的打开方式,GAE以及Cloud Foundry早期版本为代表的PaaS将大家都带到坑里,只留下一地鸡毛。直到Docker开源,大家才如梦方醒,原来不是方向不对,而是应用分发和交付的手段不行。然而,Docker公司将其核心代码开源的初心并不只是造福业界,它是想用这种方式吸引商业客户。Docker公司将Docker注册为商标,引起了社区的警觉,各种自创容器项目层出不穷。为了结束这种乱象,2015年6月,容器开放推进组织OCI成立,旨在围绕容器格式和运行时制定一个开放的标准,Docker作为创始成员,意图将这个标准制定权抓在手里。然而,大家实在是被Docker在商业化和社区两边左右摇摆的态度吓怕了,2014年Kubernetes发布后,迅速吸引了包括红帽在内的一批成员,并在短短一年之后的2015年7月,Kubernetes发布了1.0版本,随之而来的还有CNCF云原生计算基金会。CNCF的诞生宣告云计算技术演进的重心从容器转移到容器编排,随后的2016年,Kubernetes发布了容器运行时接口CRI,只要符合这个接口,Kubernetes就可以通过它来运行容器,是不是Docker已经无关紧要了。就这样,容器从Docker变成了一种标准接口实现,只要符合这个标准,不用管背后运行的是什么。结合容器和Kubernetes,大家在自己的集群上用得很愉快,但当云厂商试图向大众提供容器服务时,多租户安全问题出现了。AWS的选择要理解这个问题,我们首先要了解容器的原理。Linux容器的本质是一种进程隔离技术,通过cgroup和namespace,容器里的应用只使用给定的资源,不同容器之间互不侵犯。从容器里应用的角度来看,它只能看到给定的计算存储资源和为其定制的系统,但从容器外面的系统来看,它运行的是一个一个的进程。如果这些容器都属于同一个用户那还没什么,但如果是云服务,一台机器里面运行着不同用户的一个个进程,光是想一想就有一种四处漏风的感觉!从技术角度讲,AWS在它的官方博客中是这么描述这个安全隐患的:由于操作系统内核漏洞,Docker组件设计缺陷,以及不当的配置都会导致Docker容器发生逃逸,从而获取宿主机权限。由于频发的安全及逃逸漏洞,在公有云环境容器应用不得不也运行在虚拟机中,从而满足多租户安全隔离要求。而分配、管理、运维这些传统虚拟机与容器轻量、灵活、弹性的初衷背道而驰,同时在资源利用率、运行效率上也存浪费。这就是云原生里面的多租户问题,其本质是容器安全问题。前几年,云厂商在推出Kubernetes集群服务方面进展神速,但在提供单一容器托管方面却步伐迟缓,就是因为这个问题迟迟没有解决。并且,多租户问题不仅仅在公有云上存在,在公司内部的私有云上同样存在,不同部门、团队的应用,理应进行强隔离,以免一个业务出现问题影响整个公司。但过去,大家应用容器的势头很强,装作看不到这个问题罢了。对于多租户问题,虽然社区逐渐有了一些解决方案,但因为还不太成熟,也缺乏一个标志性事件把它们推到前台。终于,2018年12月,AWS出手了。众所周知,AWS是云计算行业的领头羊,但在容器到云原生这波浪潮里,AWS却变成了跟随者的角色,它肯定是不甘心的,最终,它在容器安全给出了自己的答案,重新走在了所有云厂商的前面。AWS的答案是Firecracker,一种轻量级虚拟机(MicroVM),这个轻量级是相对于全功能虚拟机来说的,后者的代表是QEMU,号称能模拟所有硬件设备。Firecracker将能省的地方都省了,最终留下一个极其精巧的运行时,只保护该保护的地方。从性能上来讲,Firecracker和容器已经很接近了,它最初的意图就是为AWS的Serverless服务Lambda提供保护,性能必须要跟上;从安全上来讲,在该保护的地方,它提供的是虚拟机级别的保护,无论是来自内部和外部的漏洞和攻击都能防护。AWS还推出了Firecracker的containerd实现,这意味着可以用标准容器的方法来驱动Firecracker,说明用虚拟机来解决容器安全这条道路是可行的。但是,AWS有自己的一套完整生态,Firecracker也是这个生态的一部分,虽然它开源了,社区并不能做到开箱即用,与Kubernetes有一些不兼容的地方。这时,就轮到Kata Containers出场了。面向云原生的虚拟化Kata Containers的前身是Hyper runV和Intel Clear Container,这两者都试图用虚拟化的技术来解决容器安全问题。两者都是2015年5月布的,后来发现彼此技术路径差不多,两边的创始人聚到一起一合计,要不合并吧,于是Kata Containers就诞生了。当时,正遭遇Kubernetes和CNCF强劲攻势的OpenStack基金会,一眼看出了Kata Containers的应用潜力,于是在将战略改为面向开放基础设施的同时,将Kata Containers接纳为第二个顶级开放基础设施项目,与OpenStack同级。但是,Kata Containers在诞生后一段时间里,却并不受社区的开发人员看好。其重要原因有二,第一个是,Kata虽然从第一天就将与Kubernetes集成作为最优先目标,但Kubernetes早期版本只考虑了如何运行容器,要让Kubernetes支持非容器技术需要额外做一些功夫,当时runC容器还如日中天,让Kubernetes管理虚拟机是一个比较另类的做法。第二,Kata虽然成功地让虚拟机兼容了容器的大部分接口,但是性能太差,其中一个主要原因在于,它在底层采用了上面提到的QEMU作为对接系统接口层,而QEMU是一个包含数百万行代码、数万个文件的项目,虽然Kata努力对其进行了精简,但带来额外的性能损耗,还是让对安全不太敏感的应用难以接受。事情的转机就在于AWS Firecracker的发布,当时,Firecracker只支持AWS自己的Serverless服务,但是明眼人都看得出来,Serverless都支持了,容器还远吗?Firecracker也让大家更加关注容器安全问题,Kata Containers开始受到更多的关注。同时,Kata也在利用包括Firecracker在内的最新开源社区进展,进一步降低开销:比如,支持Firecracker作为部分适用场景的VMM,以及研发自己的rust-VMM cloud-hypervisor,又将沙箱agent替换为轻量的rust-agent,让内存占用从十多MB降低到1.1MB,提升肉眼可见,并且,这个开销已经可以接受。另一方面,在Kata Containers和社区的推动下,Kubernetes开始接受安全容器了,在Kubernetes里运行Kata不再需要做额外处理。在Kata Containers的两周年之际,它给自己的定义是面向云原生的虚拟化。之所以要强调虚拟化,是因为它的本质是用的虚拟化技术,但与传统虚拟化相比,Kata Containers走的是一个完全不同的发展方向,是适合云原生场景下的虚拟化。但是为什么又叫它安全容器呢?现在回到我们开头介绍的多租户问题,使用Kata Containers后,当你启动一个容器,实际上是启动了一个虚拟机,但这个虚拟机的功能、生命周期、性能表现都和容器一模一样。鸭子测试说,如果一个动物走路像鸭子、说话像鸭子、长得像鸭子、啄食也像鸭子,那么我们就认为它是一只鸭子。放到Kata Containers也一样。Docker自身的技术路线,无法很好地解决安全问题,所以当CRI和安全容器出现之后,它的商业化探索已经注定不会有太好结局。Kata Containers与安全容器的未来软件世界里有很多不确定性,但我们可以确定的是,安全问题一定会发生。那么,如何应对安全问题呢?Linus说过这样一句话:安全问题的唯一正解在于允许那些(导致安全问题的)Bug发生,但通过额外的隔离层来阻挡住它们。—— LinuxCon NA 2015, Linus Torvalds要一劳永逸地解决容器安全问题,可能唯有为其添加额外的隔离层,这也是Kata Containers的思路。值得一提的是,安全容器并不是只有Kata Containers和Firecracker这一条路线,Google推出的gVisor是另一条路线,它是一个更纯粹的隔离层,上层应用对系统的所有访问都经过隔离层处理后,再将其中少数请求交给宿主机响应。Kata Containers经过两年耕耘,业界开始逐渐跟进,比如百度智能云,在函数计算、容器服务、边缘计算等方面开始尝试。2019年,Kata Containers创始人加入蚂蚁金服,蚂蚁并未干涉Kata Containers的发展路线,Kata仍是社区主导的开源项目,Kata Containers也开始在蚂蚁和阿里内部逐渐落地。Kata Containers未来仍会继续优化其性能,当然,更重要的是,容器和虚拟机就像是一座天平的两端,Kata Containers需要不断地摸索,去找到那个平衡点。AWS已经证明了安全容器是公有云落地Serverless的关键技术之一,与之类似,边缘计算也将成为安全容器的典型应用场景。随着AWS以及各家云厂商的跟进,可以预见,2020年将迎来安全容器落地的爆发。Kata Containers项目地址:https://github.com/kata-containers参考文章:Kata Containers:两年而立Kata Containers:面向云原生的虚拟化Kata Containers在百度智能云的应用实践深度解析 AWS Firecracker 原理篇 – 虚拟化与容器运行时技术
Docker Hub遭入侵 19万帐号被泄露
美国当地时间周五晚上,有开发者表示收到来自 Docker 的官方邮件,邮件内容显示由于 Docker Hub 遭受非法入侵,已导致 19 万个帐号的敏感数据被泄露,这些数据包括小部分用户的用户名和哈希密码,以及用于自动构建 Docker 镜像而授权给 Docker Hub 的 GitHub 和 Bitbucket token。