Michael Blog

设备与网络准备 网络要求 能够访问OpenShift Infrastructure Providers以下载安装程序 能访问quay.io以获取安装群集所需的软件包 能访问Red Hat’s software as a service page以获取相关订阅 准备节点 1 bootstrap节点 RHCOS，引导计算机部署集群，在完成部署后该机器可被删除 3 master节点 RHCOS 2 compte节点 RHCOS or RHEL 7.6 部署前准备 外部负载均衡器 配置主机端口 配置DNS 确保网络连接 以下端口必须能被集群中的所有机器访问 端口 说明 2379-2380 etcd server, peer, and metrics ports 6443 Kubernetes API 9000-9999 Host level services, including the node exporter on ports 9100-9101 and the Cluster Version Operator on port 9099. 102 ...

参考文章https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_health_checks.html#day-two-guide-router-and-registry-health

Nginx是最常用的代理软件，也是最常用的WebServer，怎样很方便地在openshift上部署呢？同时又能很方便地对它自定义进行配置？直接使用docker的nginx会有以下问题： 启动时权限问题。默认openshift的应用会使用类似10000100的user_id启用docker，但是官方nginx镜像会使用root启用；还有nginx默认会启用80端口这个也是需要root权限的。 无法动态更新nginx配置。nginx配置在镜像中设置，如果需要更新配置的话，需要重新编译镜像。 应用代码更新。如果用户的代码，如静态代码，版本更新，是否可以不更新镜像，而完成版本的升级？ 在Openshift上部署一个nginx应用如何解决以上3个问题。 权限问题 解决办法: 制作专用nginx镜像，1. 更改特殊文件夹的权限为777；2.将默认端口设置为8080default.conf 123456789101112server{ listen 8080; server_name _; location /{ root /u ...

上篇介绍了如果在openshift上部署zalenium及python对应用功能进行测试的方法。该篇介绍如何通过Jenkins的Slave容器配合上篇中的zalenium实现自动化功能测试，并生成测试报告。虽然只是一个小例子，但是麻雀虽小，五脏俱全。同时所有的操作及工具都建立在Openshift上。下图为各工具之间的关系： ###具体操作： 启动Jenkins需要添加环境变量JENKINS_JAVA_OVERRIDES => -Dhudson.model.DirectoryBrowserSupport.CSP=该环境变量使得HtmlReporter页面展示正常 Jenkins系统管理->系统设置中创建新的Kubernetes Pod Template基础镜像jenkins-slave-python-centos7:3.10，Dockerfile安装需要的python依赖包 123# DockerfileFROM informaticsmatters/jenkins-slave-python-centos7RUN pip install selen ...

API经济3scale做了什么？关注指标 支持应用数据 完整用例的数量 用户数量 资金价值 开发速度 部署速度 迁移工作量 已有问题 完整的API管理不仅仅只是创建与发布，还需要配套全方位的运维 创建与发布API 度量和计费 安全 & 认证 API文档Portal 扩展性 & 集中策略 API监控 版本控制 生命周期 配置 & 告警 API测试 3scale架构（可容器化部署） 实验内容github.com/hgueere

Openshift All In One工具制作的初衷： 工作中为了测试各种情况，比如备份恢复等，经常需要部署一套全新的Openshift环境，虽然镜像与安装包都是现成，但是部署过程中还是很容易出错，毕竟还是有些复杂的。竟然部署过程是一致的，那就干脆用脚本化，一键到位得了。 Openshift3.9部署手册，这是我之前整理的一篇单机部署Openshift 3.9的手册，有一些朋友看了后，按照上面的操作还是会遇到一些问题，毕竟步骤有那么多，差了一步，就很容易就会失败。有了这个脚本工具后，想要部署测试Openshift的朋友就很容易去部署测试了，而不是在部署这一步就放弃了。 有些厂商提供了Openshift的解决方案，但是做支持的厂商朋友并不太熟悉容器平台环境，也想在自己的环境下部署一套Openshift来测试，最后往往困难重重，从展望到放弃。 做个自动化工具，让所有关心Openshift/K8s的朋友就可以跳过部署的步骤，快速进入到Paas这个神奇的世界，去了解到自己真正关心的内容。 进入正题 什么是正题？直接上工具git地址OpenshiftOneClick：https:/ ...

使用F5与Openshift集成目的外部流量访问应用时，通过F5 BIG-IP硬件设备直接代理到集群中的Pod。这样做的好处，很明显。 使用硬件负载均衡器替换掉软件负载均衡器，提高性能。 F5有更灵活的配置，可以实现更复杂的流量控制 Openshift操作Openshift通过BIG-IP Controller来控制BIG-IP设备。由于Openshift是基于Kubernetes的，所以它们使用同一个Controller（k8s-bigip-ctlr）。BIG-IP Controller为集群中的应用配置BIG-IP对象，提供南北流量的服务。 BIG-IP Controller有两种方式来使用F5 BIG-IP设备 为Openshift中的Service提供代理流量 为Openshift中的Route提供代理流量 为Openshift中的Service提供代理流量_(不介绍具体部署操作)_这种方式，我们测试下来发现，需要为对外提供服务的Service绑定到F5的不同端口，同时外部访问应用时需要指定端口号。如：app1.openshift.example.com:8000, a ...

上篇：Openshift-F5集成（南北流量走F5）中介绍了如何实现使用F5替换掉Openshift中的Route，但是它的可控性是弱的。本篇则通过手动创建VS及iRule来实现更强的流量控制，实现识别客户端IP来访问相应的服务。 为什么要使用灰度发布 什么是灰度发布灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。ABtest就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 灰度发布的价值使用灰度发布可以在产品正式上线前针对特定一些目标用户进行开放，获得这些目标用户的反馈，及早发现问题，修复问题，完善产品的不足。如果发现新的版本价值不大，能够及早更换思路，避免产品直接上线后产生不好的影响。 Openshift Route自带的灰度发布功能 Openshift Route自带的灰度发布，是通过Route下“挂载”两个或两个以上Service，并调整各个Service的权值进行控制流量的分布。 例如应用有 ...

这篇文章来自9月份自己在F5年度会议上分享的PPT，感谢过程中帮忙一起联调的小伙伴。PPT也分享出来，地址如下：openshift与F5的联合解决方案Openshift-F5集成（南北流量走F5）Openshift-F5集成（续）——实现灰度发布 Openshift的基础概念Openshift简介红帽® OpenShift 是一款性能强大的开源企业级PaaS产品。不仅是企业级的Kubernetes，可以构建、部署与管理容器应用，还提供从开发到投入生产的整个应用生命周期内使用的完整解决方案，帮助客户享受快速创新带来的收益，同时保持企业级平台的稳定性、可靠性和安全性。Openshift支持多种环境下部署，无论是在企业内部，公共云，或是托管环境中。 Openshift Pod Pod是Openshift调度的最小单元 一个Pod包含一个或多个容器 Pod内的容器共享网络，IP不固定 实例： 12345678910111213apiVersion: v1kind: Podmetadata: name: MyApp labels: app: MyApp spec: ...