OpenShift之应用环境变量篇
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Michael Blog！
相关推荐
2020-05-20
OpenShift中etcd集群的某个etcd服务文件损坏，导致节点故障，恢复过程
问题etcd集群中某个etcd出现故障，使用docker ps -a | grep etcd | grep -v POD查看etcd节点，发现它异常退出。 123$ docker logs -f <etcd-container-id>....etcdserver : open wal error: wal: file not found 恢复步骤大方向步骤：一、将问题etcd节点从etcd集群剥离；二、将恢复的新的etcd节点添加到etcd集群。具体步骤如下： 查看etcd状态 1234$ etcdctl2 cluster-health$ ## 获取问题节点的member ID$ etcdctl2 member remove <member ID>$ ## 将问题etcd服务从etcd集群中删除 停止问题节点上的etcd服务 12$ mkdir -p /etc/origin/node/pods-stopped$ mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/ 删除问题节点上的...
2020-05-20
Openshift生产环境部署配置事项
1. 主机配置推荐 master 16核 32GB 网卡带宽不低于1Gb。CPU x86_64架构，核数和主机数线性递增，每增加一台主机增加0.1核。5台主机4.5核，总的核数为4+0.1 * 主机数内存与主机数线性递增，每增一台主机增加200M内存，5台8G，总的内存数为7+0.2 * 主机数 node 40核 256GB 网卡带宽不低于1Gb根据应用场景估算 2. 磁盘目录挂载 master磁盘格式：xfs ftype=1/ : 10GB/var/log ：50GB/var/lib/docker：100GB 做raid高可用/var/lib/etcd [ssd]：20GB 做raid高可用/var ：50GB 可根据实际进行调整，主要emptyDir的存储在/var/lib/origin目录下 node磁盘格式：xfs ftype=1/ : 10GB/var/log ：50GB/var...
2020-05-20
容器平台武林盟主争夺大战
容器技术是继虚拟化技术后又一革命性的后台技术，厂商为了争夺容器PaaS的话语权，必将发起一场声势浩大的战争。谁也没想到挑起这场革命性战争的竟然是一家仅3年的创业公司——dotCloud。 2013年前：大战前夕——一片祥和 虚拟化技术已经深入人心，以aws与openstack为主的云平台已经非常成熟。 PaaS理念也得到了普及，cloud foundry成为当时PaaS的标准 cloud foundry吸引了包括百度、京东、华为、IBM 等一大批国内外技术厂商，开启了以开源 PaaS 为核心构建平台层服务能力的变革。“PaaS 的时代就要来了！” PaaS公司有：Cloud foundry、Heroku、Pivotal、Red Hat PaaS 项目被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力。 2013年容器武林大战——一鸣惊人 2013年3月：一家创业公司dotCloud开源了它的产品Docker，解决应用构建、分发与发布的问题，它的最大改进是引入了镜像构建。 Cloud Foundry 的首席产品经理 James Bayer 做了一次详细对比...
2020-05-20
Jira容器化-+-Openshift-Jira模板创建
因为应用容器化部署已经是标准化的流程，无需再详篇介绍具体的部署流程。所以本文只提供相关的配置文档。如果对部署过程不了解的同学，请先自学容器基础。镜像已经创建好了，如下 12docker.io/xhuaustc/jira-software:7.11.0docker.io/xhuaustc/atlassian-mysql:5.7 镜像构建配置Jira容器构建 1git clone https://github.com/cptactionhank/docker-atlassian-jira-software 将setenv.sh与atlassian-extras-3.2.jar拷贝到docker-atlassian-jira-software 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919...
2020-05-20
混沌工程详细介绍——Netflix持续交付实践探寻
本篇来自于本人6月-7月参加的“DevOps案例深度研究”活动Netflix案例研究的第五部分，详细介绍了Netflix的混沌工程。经过一个月的战斗，四个版本的迭代，Netflix战队最后交付了让所有人满意的战果，并获得了全场唯一的案例研究最佳小组奖杯。感谢我们的战友，还有指导老师，姚冬老师和徐磊老师。 Netflix实施混沌工程的背景 08年Netflix决定把它的业务迁移到aws上，从自身运维的角度考虑，它有很多担忧的地方。 很长时间内有两套系统在同时运行，运维的复杂度更高了。 NetFlix的用户量已经达到了1亿，对应用稳定性依赖很高，如果出现故障对用户的影响非常大，甚至是致命的。 它的业务不断复杂，引入微服务架构，对应用的高可用性要求越来越高。 生产环境非常复杂，是多样性的，很难在测试环境中完全模拟生产的状态。 因此Netflix决心探索一种在生产环境验证应用高可用性的一种方法，这就是现在大家所熟知的混沌工程。 混乱工程的发展 2010年，捣乱猴子诞生 2011年，猴子军团，有了更多场景下的工具集 2012年，开源了捣乱猴子的代码，建立社区，影响了越来...
2020-05-20
OpenShift-Service的域名
正常情况下Service的域名格式为：service-name.project-name.svc.cluster.local对应的IP是Service Cluster IP 设置Service的clusterIP=NoneService的域名格式为：service-name.project-name.svc.cluster.local对应的IP是后台对应的Pod的容器的IP同时后台对应的Pod都有DNS记录，格式为Pod-name.service-name.project-name.svc.cluster.local