写点什么

直播回顾 | 传统应用进行容器化改造,如何既快又稳?

作者:BoCloud博云
  • 2022 年 6 月 13 日
  • 本文字数:3990 字

    阅读完需:约 13 分钟

当前,容器云技术方兴未艾,越来越多的应用都运行在了容器上。因为底层技术模式的不同,不同于传统的虚拟化云平台,应用上容器云需要做更多的更改。


对于容器云的建设部门来说,认真规划和考虑业务应用容器化改造是非常有必要的。从某种意义上来说,协助业务部门做好应用的容器化改造,让业务应用既快又稳地迁移上云,是 IT 云原生转型成败的关键。


让应用上云需要一个综合解决方案,本期分享我们将从应用迁云流程,应用上云调查评估,应用改造策略,以及容器云对原有运维的影响等几个方面来探讨传统应用如何进行容器化改造。


本文是 6 月 9 日“CloudTech 博云说”第四期分享内容《传统应用进行容器化改造,如何既快又稳?》的回顾整理。扫描上方海报二维码点击文章末尾的阅读原文,回看精彩视频!


01 应用迁云的流程

应用迁云流程与应用上虚拟化技术的云平台的过程是类似的。主体流程包括调研评估,方案设计,流水线制作,上线试运行,培训和总结。每个主步骤的细化步骤参考如下图:



这些步骤很容易理解,我们就不一一展开解释了。总的来说,我们需要遵循一定的流程,这样才能避免顾此失彼,达到业务应用稳定迁移的目标。由于每个业务应用有自己的特点和要求,在做具体的应用改造方案时,需要按照“一业务一方案”的原则进行应用 PaaS 平台迁移/部署。


02 应用上云的调研


在应用上容器前,每个应用都要进行评估,以便确定是否适合上云及适合哪一种上云形式。在评估之前,我们需要制作评估调研表格,让业务人员来填写,方便了解业务应用的现状。调研表主要包含如下几方面内容:


  • 应用基本信息类:如架构、开发语言、数据库、中间件等

  • 应用部署信息类:如部署数量、部署模式、数据持久化、日志路径等

  • 应用资源信息类:如服务所需 CPU、内存、磁盘,日志存储空间等


具体到每个用户,可以根据自己企业的实际情况,对表格内容进行修改。核心目的就是要掌握每个业务应用的基本信息和特点,为评估改造的代价和策略提供依据。


03 应用容器化改造的原则与策略

本节从技术上描述如何进行应用容器化改造,我们遵循的应用上云改造总的原则有:


  • 应用最好是微服务架构

  • 应用需要是无状态

  • 应用上云有实际的需求

  • 尽量少涉及代码修改


在改造前,我们首先需要了解传统应用特点,在应用容器化的过程中需要考虑解决以下这些问题:


  • 大而全:传统应用为了调试和编程方便,都是尽可能让一个应用系统包含绝大多数模块,尽可能减少模块外部的交互。

  • 单一数据库:为了减少数据同步和交付,单一数据库会被很多应用系统共享,数据库变得大而全。

  • 因环境而变化:应用开发时考虑了不同环境,比如操作系统,虚拟化技术,网络环境,存储系统等,应用对环境依赖性非常大。不同的环境之间,同一个配置的 value 可能都不一致。

  • 有状态:有些是有状态的,比如对于 session 的依赖,非幂等接口等。

  • 配置固化在程序中:模块之间的交互基本上配置固定,例如 ip:port 信息基本上配置固定,不会轻易改变。因为这些原因,程序员为方便,直接将配置固化在程序中。

  • 应用增量升级:应用的增量升级,例如为了保证应用的稳定性,可能会采取替换文件的方式进行。


以上的传统应用特点在容器云中都需要做些更改,具体更改方式和具体应用有关系,可以与相关的应用架构师进行交流,制定细化的应用更改方案。


04 应用容器化改造的三个过程

应用的容器化改造可分为三个过程:应用整体容器化、应用配置容器化和应用依赖管理。


1. 应用整体容器化

应用整体容器化是指把编译以后的应用程序包 .war 或者其他程序包,加入到运行服务环境(tomcat)等的过程,能够让应用初步容器化,并且容器化的应用,能够通过已经配置好的端口直接进行访问,且服务正常的过程。


应用配置容器化是在应用整体容器化的基础上,把配置信息抽象化,例如 jdbc 的链接地址:jdbc:192.168.1.218:3306 可以抽象为 jdbc:${MYSQL_SERVER_IP}:3306 的方式,类似这样完成应用配置容器化,同时打包成新的 image。


2. 应用配置容器化

应用配置容器化需要处理应用配置的变更,指一些应用为了适配不同业务场景或环境,设置一些可以变更的参数。需要将这些配置跟程序分离,独立管理。


应用配置容器化还需要考虑多环境问题处理,可直接通过环境变量赋值的方式进行,不同环境中共同存在的 key 值可以提升到环境管控的级别。


3. 应用依赖管理

很多分布式应用以及大量的独立中间件的使用都会导致应用依赖非常复杂。应用依赖的管理可通过编排工具来完成。注意需要先后启动关系的应用,可以在运行容器组件的时候指定要执行的 sql 脚本完成数据初始化工作,配置第三方服务组件,比如缓存等。


05 应用容器化改造的最佳实践

在大量的容器化改造项目实践中,我们总结了一些应用容器化的最佳实践。


1. 同一组织机构使用相同的标准的基础镜像

同一个组织机构在构建应用镜像的时候推荐使用同一个标准的基础镜像,基础镜像可以从官方镜像的仓库拉取下来或者组织结构自己制作,基础镜像需通过镜像扫描工具的安全扫描并且解决相关的安全漏洞,应用容器在制作过程中需基于此基础镜像进行构建。在容器云中可以事先将基础镜像拉取到各个容器节点上,这样可以加速使用该基础镜像的应用镜像的拉取的速度。


2. 不使用 root 用户起进程

在制作镜像的时候默认使用的是 root 用户,如果使用 root 用户可能会带来一些安全隐患,推荐在制作镜像的时候使用 USER daemon ,用 daemon 用户取代 root 用户。


3. 容器镜像大小控制在 2GB 以内

通过合理的规范的书写 Dockerfile,优化容器镜像的大小,推荐控制在 2GB 以内,在大规模的容器云中,如果同时发布大量的实例,会对容器仓库的读写以及环境网络带宽传输产生比较大的影响,越是小的镜像,在分发(节点拉取镜像)的时候越有优势,同时也会加速应用的发布过程。


4. 容器中的应用启动时间控制在 5 分钟以内

通过优化应用,控制应用的启动时间,虽然过长的启动时间可以通过容器云的健康检查以及设置合理的负载的策略去避免外部用户访问被分发到未完全启动的容器上去,但是过长的启动时间不能发挥容器快速敏捷的特性。


5. 实现应用状态外部化,实现应用实例的无状态化

应用状态信息存储于数据库或者缓存等外部系统,应用实例本身已经实现无状态化。虽然现在的容器平台已经可以支持部分有状态的应用,但是有状态的应用容器在构建,使用和维护过程中难度系数比较大,无疑无状态的应用更适合应用于容器平台中。


6. 构建清晰的可自动化的编译和构建流程

对于期望应用于持续集成,持续交付的应用来说,在容器化之前该应用已经实现了 Maven,Make 或者 shell 等工具的自动化构建编译,这样在迁入容器云中,可以非常方便利用容器云的 CI/CD 能力进行自动化的部署和发布,加速应用的交付能力。


7. 实现应用配置参数外部化

在容器中发布的应用,应用已经将配置参数到外部的配置文件或者环境变量中,以便于应用容器可以适配到不同的环境中去,不会因为环境的变化而需要将应用重新容器化。发布于不同环境中的应用,只需修改发布时的环境变量或者配置文件地址就可以实现不同环境中的迁移。可在代码层面写入各环境的配置地址,发布时通过环境变量识别不同的配配置。


8. 已提供可靠的合理的健康检查接口

容器平台可以通过检查应用提供的应用健康检查接口检查容器的状态,通过状态的变化容器平台判断容器是否加入到负载提供服务,或者容器台可以尝试重启修复健康检查失败的容器。


9. 不涉及底层的操作系统依赖和复杂的网络通信机制

应用以处理业务为主,不强依赖于底层的操作系统以及组播等复杂的网络通信, 并且不要强依赖于固定的 IP 地址,提高应用的可移植性。


06 容器对部署运维的变化


1. 部署流程变化

传统的运维模式是先申请并确认资源,然后再部署应用。而在 Docker 类应用部署过程中,资源分配是由系统自动完成的。只要整个 Docker 集群仍有剩余资源,是不需要申请资源的。或者说只需要申请部署即可,因为部署和资源获得是一个步骤自动完成的。


2. 资源与应用绑定模式的变化

传统的运维管理中,资源与应用是绑定的,可以清楚的规划每台机器跑哪些应用,包括每个应用占用多少资源,包括应用的 IP 地址都是提前规划好的。而 Docker 化之后,资源与应用已经解绑,无法严格进行资源和应用的绑定规划,如 IP 地址与应用的绑定,物理机与应用的绑定等,传统的运维方式和习惯需要进行相应的调整。


3. 问题解决方式的变化

基于 Docker 的特性,在系统出现问题的时候,最合适的方式就是重新启动一个新的 Docker(很多时候由系统自动启动),先解决问题。然后再去找系统出现问题的原因并解决。另外,传统的登陆到系统内部(比如 ssh)查看相关信息的习惯也面临挑战,当然我们也提供 ssh 到 docker 内部的方案。


4. 应用扩展的变化

过去应用扩展需要经历资源分配,安装,测试,上线的过程,而使用容器之后,一方面可以自动根据负载进行应用扩展,另一方面也可手动一键方式完成应用的扩展。


5. 应用配置的变化

在容器环境中,要做到应用配置动态生效,则应用配置和程序需要是分离的。在发布版本时,应用配置和程序要分别发布,在容器平台上可直接修改应用配置,这需要改变和适配原有的层层审批,不同部门执行各自操作的模式。


6. 升级回滚方式的变化

过去的升级主要基于脚本来完成,周期长,风险大。在使用 Docker 后,基于与持续集成和自动部署的能力,可实现系统的一键自动升级,而系统的回滚也只需要一键即可完成。


07 总结

应用迁移上容器云是需要在管理流程,开发改造,以及运维方式上做些变化。我们需要在容器云建设阶段就要尽量按照以上规范的流程综合设计和规划应用上云。记住,做好应用上云,是容器云建设的重要组成部分


近日,博云正式发布了《应用上容器指南》(2022 年版),这是博云聚焦应用容器化改造,旨在为应用真正实现容器化改造的提供清晰明了且具备实践操作指导的方法论。该指南从行业与企业所关心的应用容器化改造的相关问题入手,真正深入理解企业应用容器化改造的需求与难题,提炼总结出具有可真正落地实现的方法指南。欢迎大家下载完整版指南~↓↓↓↓↓



发布于: 刚刚阅读数: 3
用户头像

BoCloud博云

关注

微信ID:beyondcent 2019.04.09 加入

微信订阅号:beyondcent 微信服务号:bocloudresearch 企业级PaaS及多云管理服务商。

评论

发布
暂无评论
直播回顾 | 传统应用进行容器化改造,如何既快又稳?_云原生_BoCloud博云_InfoQ写作社区