云原生开发将成为强大部署蓝图

这个例子以在内部部署服务器上工作的云原生开发人员开始，提供其代码解决方案，使用其容器工具启动构建其持续集成(CI)/持续交付(CD)工作流程。

在这个蓝图中，该工具将与OpenShift容器平台一起使用，因此将会看到一个OpenShift客户端用于持续集成(CI)/持续交付(CD)OpenShift平台中的初始构建。当开发人员对其代码感到满意时，就会发生这种情况。触发对持续集成(CI)/持续交付(CD)平台的构建和测试请求，将托管在OpenShift容器平台集群上：

• 使用git hooks，在提交到内部部署代码库时触发代码推送;
• 使用Maven插件，激活后触发对开发基础设施的推送;
• 使用oc客户端容器工具;

当将代码推送到其持续集成(CI)/持续交付(CD)平台时，开发团队可以自由使用最适合自己需求的方法。

持续集成(CI)/持续交付(CD)基础设施

从开发人员内部部署工作环境推送的代码由持续集成(CI)/持续交付(CD)平台获取，在这种情况下，大多数情况下是基于Jenkins的平台。例如，持续集成(CI)/持续交付(CD)平台可以使用“源到映像”工作流来构建容器映像、测试映像，并将其放入临时映像注册表中。此时，它被标记为appImage:dev并推送到OpenShift集群，该集群托管由Quay管理的企业映像注册表。

企业注册表

对于高级部署，将研究如何确保具有用于开发和测试不受信任的容器映像的沙箱注册表。appImage：dev映像已被推送到沙箱注册表，在其中找到了尚未针对内部安全性和认证要求进行测试的任何导入的第三方映像、外部映像和其他映像。

所有最终的开发标签的图像(例如appImage：dev容器图像)都将推送到开发基础设施中以进行进一步测试。当容器映像经过认证以符合安全性要求，并通过进一步的内部测试要求时，它们将移至第二个企业注册表。在这一点上，它们被认为是受信任的映像，并且可以在这个蓝图中进一步推送到测试和生产基础设施。

（编辑：泉州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!