这是我在EMEA红帽技术2017交流会议(Red Hat Tech Exchange 2017)上所做的文字记录,这是一个由所有的Red Hat解决方案架构师和顾问组成的会议。在创建将在OpenShift上运行的镜像时,需要对此进行考虑和良好实践。该内容由四篇帖子构成:
这是第一篇文章,我们将看到与使用容器镜像的使用相关的共同目标。这些目标将在镜像的设计阶段会被考虑到。
容器让人们充满兴趣的原因之一是,它允许将具有所有依赖项的应用程序打包到单个部署单元中。这个部署单元,就是镜像,可以从一个环境迁移到下一个环境。例如,您可以将其从集成环境迁移到UAT(User Acceptance Test:用户验收测试)或从分段环境迁移到生产环境。将所有依赖关系放在一个单元中,可以保证在前一阶段验证的内容也将被部署到下一个阶段。
在容器崛起之前,我看到很多公司在应用推广上苦苦挣扎。其中有些人已经编写了详细的安装程序,必须手动安装还有小心得遵守说明。其他人则根据Puppet,Chef或Python脚本的自动化构建方面投入了大量的精力。此外,最初的努力还需要大量的维护工作来应对演化和变化。他们中的大多数人都经历过各种各样的问题。容器带来的是一个标准和简单的方法。应用程序依赖关系(操作系统,系统运行时环境(JVM等),库以及一些配置信息和环境)是容器镜像的一部分,它只是用于在一个或另一个环境中启动容器实例。
随后的镜像创建应该产生相同的结果。这对于获得可用于补丁,升级和进一步演进的稳定参考非常重要。这要求用于创建容器镜像的依赖项(库或其他镜像)被唯一引用和版本化。
企业软件领域的同质化水平有明显的好处:
定义镜像范围时应该考虑到这几点。这就是说,严格执行和缓慢发展的 SOE(参与型系统:Systems of engagement) 有时成为企业快速反应的障碍。容器镜像可以帮助解决这方面的问题,通过可重用性和将中心更改应用于多个目标的易用性操作。
限制组件注入像框架,应用服务器,驱动程序和脚本等镜像中是非常重要的。这些可以用于基础功能,连接,监控,资产跟踪和管理,安全等。使用继承和组合的分层方法可能支持这一点。在这方面,考虑到全球的镜像范围而不是单一的镜像是很重要的。
上一节提到的中央注入点也是修补和升级的中心点。这些更改(可能由软件提供商提供的容器镜像)需要自动级联,以便进行维护。
在容器出现以前的时代,我看到很多公司都在努力保持他们Java或应用服务器的补丁版本和安全修复服务是最新的。容器技术结合了核心应用变化更新的可能性,并使这些应用在软件环境中毫不费力,也不需要停机的情况下更新。这在安全性和可靠性方面会产生巨大的影响。因此,镜像设计时需要考虑可维护性。
在创建应用程序时,资源(RAM,CPU,存储等)的最小消耗是一个明显的目标,用于打包的镜像。它意味着密度更高,成本更低。与虚拟机相比,容器具有共享相同内核而不是创建额外实例的优势。这可以通过使用容器共享层来进一步推动。这是通过以下几个已经提到的目标实现的:SOE(参与型系统:Systems of engagement)和可重用性。尽管大小确实影响推送和拉取镜像所需的时间,但它在最终的RAM和存储使用方面起着更大的作用。
除了保持操作系统,应用服务器和其他库及时修补最新的安全性补丁之外,在创建镜像时还需要考虑一些其他重要方面安全性的问题:
像Kubernetes和OpenShift这样的PaaS平台提供了监控和自我修复的机制。事先准备和活性探测服务确保了:
作为一名镜像设计师,您的责任是提供可用的事先准备和活性探测服务。
另一个方面是,当OpenShift想要终止一个容器时,它首先将容器从请求处理循环中移出并发送一个SIGTERM信号。它为应用程序在结束之前正常关闭提供了时间。如果允许的期限已经过期,则使用SIGKILL信号。在这方面,镜像内的应用程序应该完成处理正在进行的请求的处理,同时释放资源,并在接收到SIGTERM信号时终止。
容易使用(易用行)
可复用性已经被提及作为一个指标了。但是,只有在镜像容易使用的情况下,这才能达到一个良好的水平,易用性包括以下几个方面:
我希望你发现这第一部分很有趣。在下面的文章中,我们将会了解到实现这些目标的技术和方法。敬请关注!