开发测试和生产最好保持一致。商用的最好还是一些主流大厂比较好,偏门的化万一没了自己的技术积累又需要重新开始,不太划算。 如果是自己学习和了解就最好两个都学一下,毕竟最后学习的目的也是为了上生产。
很好的问题,本人参与过国内大客户的一些云平台的自研,自研的话首先是需要有个专门的团队针对平台进行开发和运维,另外需要有些团队进行平台的推广和项目的迁移工作,以为Kubernetes社区是一个比较活跃,同时涉及的技术面相
目前看到更多的是研发部门牵头,因为上容器云更多的需求是为了实现应用的快速迭代和支持业务敏捷创新,因此开发和发布效率这块是一个比较关键的指标,而且也是容易收到立竿见影的效果的。为保障容器云的生产运维,也需要去构
可以通过模板的方式,比如OpenShift提供了template的功能,容器对接组可以针对这一类型的项目,比如基于Spring Boot或者tomcat类型,订制一个模板,然后项目组直接填入参数,就可以在Openshift上部署了。
挺好的问题,我觉得几个方面:1.需要做一些普及性的宣传和广告,告诉他们新的平台的好处,比如你不用再申请虚拟机,物理机了,然后你的应用写个Dockerfile就可以一键上云了什么的。2.需要设立项目对接组,在推广的初期是需要帮项目
有的银行的做法是在DevOps的CICD通到开发和测试环境,提升应用的开发测试效率。当然要求DevOps平台的部署机要和开发和测试环境打通。而对于生产环境,通过把镜像和部署模板等工件移交部署组,由部署组在自己的部署平台上做
技术上可以实现,但仍然会带来客户感知。因为动态扩展也需要阈值触发和扩展时间的影响。如果是确定的交易促销或者固定的高峰,建议提前预备更多的节点资源,同时扩大容器实例来应对。偶发性的高峰需要预留机器的资源,比如保
目前看到更多的是在应用层面去监控,比如对于微服务架构的应用,可以通过微服务架构中的能力去做请求调用的监控,比如istio, 但系统层面的流量监控可以通过一些专业的工具比如 Dynatrace 进行分析 。
可以参考 https://www.openshift.com/blog/deploying-jenkins-on-openshift-part-1 另外还有两种方式:ocp4 的开发者 console 里面catalog仍然有 jenkins 组件。在 operatorhub 里面应该有一个 jenkins operator. J
Openshift 上有个项目 cnv, 对应着社区版本的 kubevirt, 就是通过 Kubernetes 去管理虚拟机的,也就是会把你的虚拟机包装成一个 pod, 在 Openshift 平台上进行管理,而用户使用的模式和虚机一样,固定ip,任何修改给你持久
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30