认识达内从这里开始

容器化技术随着互联网的不断发展而被广泛应用到软件编程开发项目之中，而本文我们就通过案例分析来简单了解一下，容器化技术应用注意事项分析。

1.实例是一次性的

你的应用的任何实例都不需要小心地保持运行。如果你的一个运行了许多容器的系统崩溃了，你还能够转移到其它可用的系统去创建新的容器。

2.重试而不是崩溃

当你的应用的一个服务依赖于另一个服务的时候，在另一个服务不可用的时候它应该不会崩溃。例如，你的API服务正在启动而且监测到数据库不能连接。你应该设计它使得其不断重试连接，而不是运行失败和拒绝启动。当数据库连接断开的时候API可以返回503状态码，告诉客户端服务现在不可用。应用应该已经遵守了这个实践，但是如果你正在一个一次性实例的容器环境中工作，那么对这个实践的需要会更加明显。

3.持久性数据是特殊的

容器是基于共享镜像启动，它使用了写时复制(COW)文件系统。如果容器的进程选择写入文件，那么这些写的内容只有在直到容器存在时才存在。当容器被删除的时候，写时复制文件系统中的那一层会被删除。提供给容器一个挂载的文件系统目录，使之在容器存活之外也能持久保存，这需要另外的配置，而且会额外消耗物理存储。明确的抽象定义了什么存储是持久的，催生出了实例是一次性的观点。拥有一个抽象层也使得容器编制引擎可以处理挂载和卸载持久卷的复杂请求，以便这些持久卷可以用于容器。

4.使用stdout而不是日志文件

现在你或许会思考，如果持久的数据是特殊的，那么我用日志文件来做什么事情?容器运行时环境和编制引擎项目所采用的方法是进程应该写入stdout/stderr，而且具有归档和维护容器日志的基础设施。

5.敏感信息(以及其它配置信息)也是特殊的

你绝不应该将敏感信息例如密码、密钥和证书硬编码到你的镜像中。通常在你的应用与开发服务、测试服务，或者生产服务相交互时，这些敏感信息通常都是不同的。大多数开发者并没有访问生产环境的敏感信息的权限，所以如果敏感信息被打包到镜像中，那么必须创建一个新的镜像层来覆盖这个开发服务的敏感信息。基于这一点来看，你再也不能使用与你们开发团队所创建的和质量测试所测试的相同的镜像了，而且也失去了不可修改的镜像的好处。相反的，这些值应该被存储在环境变量中文件中，它们会在容器启动时导入。

6.不要假设服务的协同定位

在一个编排好的容器环境中，你会希望让编排器将你的容器发送到任何适合的节点。适合意味着很多事情：它应该基于那个节点现在拥有多的空间、容器所需的服务质量、容器是否需要持久卷，等等。这可能意味这你的前端、API和数据库容器终都会放在不同的节点。尽管给每个节点强制分配一个API容器是可以做到的，但这种方式应该留给执行监控节点自身这类任务的容器。

7.冗余/高可用计划

即使你没有那么多负载需要高可用性的配置，你也不应该以单路方式编写服务，否则会阻止它运行多份拷贝。这将会允许你运用滚动式部署，使得将负载从一个节点移动到另外一个节点非常容易，或者将服务从一个版本更新到下一个版本而不需要下线。

8.实现就绪检查和灵活性检查

应用在响应请求之前会有一定的启动时间是一件很正常的事情，例如，一个API服务器需要填充内存数据缓存。容器编排引擎需要一种方法来检测你的容器是否准备好服务用户请求。为一个新的容器提供就绪检查可以允许我们进行滚动式部署，使得旧容器可以继续运行直到不再需要它，这可以防止服务宕机。类似的，一个存活检查也是一种容器编排引擎持续检查容器是否在健康可用状态的方法。决定容器健康或者说“存活”应该由容器应用的创建者说了算。一个不再存活的容器将会被结束，而且一个新的容器会被创建来替代它。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。