2017年是容器领域交战非常激烈的一年，容器编排领域逐渐形成一超多强的局面，各种容器解决方案变得越来越成熟，传统的中间件（监控、日志、报警）对容器化场景支持逐渐完善。到了今年，如果一家公司还没有开始对Docker进行关注，真的不好意思说是在互联网的圈子里了。

　　2017年是容器领域交战非常激烈的一年，容器编排领域逐渐形成一超多强的局面，各种容器解决方案变得越来越成熟，传统的中间件（监控、日志、报警）对容器化场景支持逐渐完善。到了今年，如果一家公司还没有开始对Docker进行关注，真的不好意思说是在互联网的圈子里了。

　　越来越多的企业开始在生产环境中使用容器技术进行架构，在各种互联网大会上，也有越来越多的嘉宾开始分享他们在使用容器上的心得。但是选择容器技术进行整体的技术架构转型实际上需要极大勇气的，在几年前，容器的解决方案还不完善，第一批吃螃蟹的企业和开发者都头破血流的搭建容器的集群、修改可选项不多的开源工具、适应着整个流程的变更。今天，容器架构的技术债务已经基本还清，k8s、swarm、prometheus、grafana等等一系列容器相关的开源工具都被越来越多的企业与开发者证明他们的稳定，选择容器化已经没有那么痛苦。但是，我们发现依旧有很多大型的企业在进行容器化转型前有所犹豫，那么大家的犹豫的点在什么。

　　很多大型企业对容器的认知是清晰的，容器能够带来的好处是显而易见的，但是同样也会带来一些成本。如果投入和产出的边际效益并不可观，那么会让很多企业没有动力使用容器。总结起来这些根本的因素并不是架构的变更带来的技术成本，而是使用容器后对于现有流程的冲击，而这个冲击并不是指技术的投入，真正的冲击是对人的冲击，是使用容器后对于人的学习成本与习惯成本的冲击。如果使用容器需要让所有的开发者都成为Docker的专家，这样的成本我想大部分的公司都无法接受。容器技术或者容器平台缺乏一个桥梁，可以无缝将提供的服务与开发者的本地代码连接起来，这个才是对于容器化而言的最大痛点。

　　于是基于这一点，在今年的杭州云栖大会上，阿里云容器团队开源了阿里云容器迁移工具Derrick。Derrick的idea在早在去年3月就开始酝酿，当时mesos、k8s、swarm还在群雄割据，使用容器的开发者的关注点还在到底该选用哪个编排工具以及相应的上下游的解决方案支持。很多时候当一个大型企业下定决心选择了容器编排工具以及上下游方案后发现团队中大部分开发人员连完整的Dockerfile都没有办法完整写出来，更别提如何进行容器化架构改造带来的其他技术成本了。为了解决这个问题，我们为客户编写了大量的Dockerfile，包括Java、Python、C++、NodeJs等常见语言、常见框架的都做了支持。在支持客户的过程中发现大部分的Dockerfile的编写工作是由运维人员或者开发Team中的极少数人编写的，大部分的开发者倾向于对Docker是无感知的，而是通过Jenkins或者自动化流程来进行自动部署。从中我们可以发现三件事情：1.一个公司应用编程框架是可复制的，一个Dockerfile可以在多个团队间共享。2.使用容器的公司或者团队一定会有少数几个人员会成为Docker的专家。3.直接在测试环境容器化验证会导致持续集成的流程变得更长，更难排查问题。

　　为了解决这个问题我们萌发了构建一个自动化工具的想法，通过自动化工具将一些预定好的Dockerfile挖坑，通过探测或者开发者填写信息，然后转变为Dockerfile。最开始的思路比较简单，只需要一个类似yeoman的工具，可以将不同的语言或者Kaiyun官方网站框架定义成模板，然后开发者自己填写参数进而进行预定的Dockerfile以及相关文件的渲染，再通过封装Docker命令屏蔽开发者本地验证的学习成本。按照这个想法做出了雏形之后，我们发现真实的情况是有所出入的，一个从零开始的项目会能够快速的进行容器化流程开发，但是对于大部分企业而言如何迁移一个应用是更常见的场景。因此，就按照这个想法借鉴Buildpack的思维，构建了现在的Derrick，目前支持NodeJs与Java两种语言，通过代码的探测、分析可以在几秒钟内完成一个应用高质量的容器化过程。

　　此时在项目的根目录下已经生成了Dockerfile、docker-compose.yml等文件了，而这些配置文件则会成为后续整个DevOps流程的基础配置信息，此时执行derrick up的结果如下。

　　通过docker ps，我们可以找到此时映射的端口，通过访问端口，即可在本地验证应用容器化的效果。

　　Derrick目前暂时只支持NodeJs、Python、Java三种语言，但是Derrick的强大之处在于他的插件体系，开发者可以定义自定义插件的方式来实现自己特定场景的探测。在下一篇文章中会讲解下如何通过自定义插件的方式来实现自定义业务的容器化。

　　126. [HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战：电商应用商品筛选侧边栏 进阶篇

　　在基础篇中，我们已经实现了电商应用商品筛选侧边栏的基本布局和功能。在本篇教程中，我们将深入探讨如何通过状态管理和数据绑定，实现更加复杂的交互功能，提升用户体验。

　　125.[HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战：电商应用商品筛选侧边栏 基础篇

　　在现代电商应用中，商品筛选功能是提升用户购物体验的关键元素。HarmonyOS NEXT提供的`SideBarContainer`组件非常适合实现这类功能，它可以创建一个可显示和隐藏的侧边栏，用于放置各种筛选条件，帮助用户快速找到心仪的商品。

　　124.[HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战：新闻阅读应用侧边栏布局 进阶篇

　　在基础篇中，我们学习了如何使用HarmonyOS NEXT的`SideBarContainer`组件创建新闻阅读应用的基本侧边栏布局。本篇教程将深入探讨如何为新闻阅读应用添加更多交互功能和状态管理，提升用户体验。

　　123. [HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战：新闻阅读应用侧边栏布局 基础篇

　　在现代移动应用和平板应用中，侧边栏导航已经成为一种常见且实用的UI设计模式。HarmonyOS NEXT提供了专门的`SideBarContainer`组件来实现这一功能，它能够轻松创建可显示和隐藏的侧边栏布局，非常适合新闻阅读、电子商务、文件Kaiyun官方网站管理等应用场景。

　　近年来，容器技术以其轻量、高效、可移植的特性成为云原生时代的基石，推动应用开发和部署方式革新。随着容器化应用规模扩大，传统运维手段逐渐力不从心。AI技术的引入为容器化生态带来新活力，实现智能监控、自动化故障诊断与修复及智能资源调度，提升运维效率和可靠性。同时，AI驱动容器化创新应用，如模型训练、边缘计算和Serverless AI服务，带来更多可能性。未来，AI与容器技术的融合将更加紧密，推动更智能、高效的运维平台和丰富的创新应用场景，助力数字化转型。

　　针对本地存储和 PVC 这两种容器存储使用方式，我们对 ACK 的容器存储监控功能进行了全新升级。此次更新完善了对集群中不同存储类型的监控能力，不仅对之前已有的监控大盘进行了优化，还针对不同的云存储类型，上线了全新的监控大盘，确保用户能够更好地理解和管理容器业务应用的存储资源。

　　使用阿里云容器服务Jenkins 2.0实现持续集成之Pipeline篇(updated on 2016.12.23)

　　Rocket框架JWT鉴权实战:保护Rust Web API的安全方案

　　Argo Workflows 加速在 Kubernetes 上构建机器学习 Pipelines

　　Serverless 容器从入门到精通: - Serverless Kubernetes