gogs创建用户
/opt/gogs/gogs admin create-user –name=root –password=123456 –admin=true --email=abc@123.com –config=/etc/gogs/conf/app.ini
123oc project cicd &&gogspodname=$(oc get pod | grep gogs | grep -v postgresql| awk '{print $1}')oc rsh $gogspodname /opt/gogs/gogs admin create-user --name=root --password=123456 --admin=true --email=abc@123.com --config=/etc/gogs/conf/ ...
ansible通过跳板机管理另一个网络下的主机集群
原文地址:http://wooooe.com/2018/07/31/remote_forwarding/
ssh端口映射例子
因为公司的网络比较深所以经常需要跳转多次。所以这次做个记录
需求: 需要从your host跳到client中间隔了两层跳板机。
如果单纯用代理方法只能跳一层
所以如果用端口映射+代理方式就可以跳两层了
映射命令
1ssh -g -f -NL 127.0.0.1:44010:172.16.3.14:22 -p 3391 jump_host1_username@222.222.222.222
意思就是将172.16.3.14的22端口映射到127.0.0.1的44010端口,222.222.222.222是中间的代理机,3391是222.222.222.222的ssh端口。
映射完成之后。执行
1ssh -p 44010 jump_host2_username@127.0.0.1
就可以直接跳转到jump_host2上
ssh走代理方法
第一种:
1ssh -o ProxyCommand="ssh -W %h:%p -p 3391 - ...
《凤凰项目—一个IT运维的传奇故事》整理
###《凤凰项目》三位作者
Gene Kim: Tripwire有限公司创始人,一直热衷于研究如何提高IT组织的效率
Kevin Behr:创建了信息技术流程研究院
George Spafford:行业分析师
向他们致敬。
故事内容雨前龙井整理的非常详细,可阅读它写的博客 凤凰项目 http://ijyun.github.io/2016/04/23/phoenix-project.html
书中的核心概念
三步工作法
本书中阐述了一个原理:所有开发运维模式都来自“三步工作法”,可以说它是我们平台开发运维的指导思想。
第一工作法是关于从开发到技术运营,再到客户的整个自左向右的工作流。为了使流量最大化,我们需要小的批量规模和工作间隔,绝不让缺陷流向下游工作中心,并且不断为了整体目标(相对于开发功能完成率、测试发现/修复比例或运维有效性等局部目标)进行优化。流程自动化
实践:持续构建、持续集成、持续部署,按需创建环境、限制半成品,构建起能够顺利变更的安全系统和组织。
第二工作法是关于价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防止问题再次发生,或者更快地发现和 ...
《启示录:打造用户喜爱的产品》读书笔记
好产品具备三个基本条件:价值、可用性、可行性,三者缺一不可。产品没有价值,开发团队再优秀也无济于事。
第一篇:人员现代软件产品团队成员
产品经理职责:评估产品机会;定义要开发的产品。
用户体验设计师交互设计师:负责深入理解目标用户,设计有价值的,可用的功能,以及用户导航和产品使用流程。视觉设计师:根据交互设计原型,制作美观的产品界面
项目管理人员产品经理完成产品定义后,开发团队开始开发产品。项目经理核心任务:制订计划和跟踪进度。
开发团队职责:负责产品的技术开发。
运维团队职责:互联网服务产品通常运行在服务器上,保证服务正常运行。
产品营销人员职责:负责对外发布信息、宣传产品,为扩展市场销售渠道、组织重点营销活动、促进产品销售提供支持
第二篇:流程11. 评估产品机会——确定待解决的问题只讨论待解决的问题,不应涉及具体解决方案。产品经理需要回答如下十个问题:
产品要解决什么问题?(产品价值)
为谁解决这个问题?(目标市场)
成功的机会有多大?(市场规模)
怎样判断产品成功与否?(度量指标或收益指标)
有哪些同类产品?(竞争格局)
为什么我们最适合做这个产品?(竞争优势)
...
《持续交付发布可靠软件的系统方法》读书笔记
基础篇第一章:软件交付的问题第二章:配置管理第三章:持续集成第四章:测试策略的实现
部署流水线第五章:部署流水线解析第六章:构建与部署的脚本化第七章:提交阶段第八章:自动化验收测试第九章:非功能需求的测试第十章:应用程序的部署与发布
交付生态圈第十一章:基础设施与环境管理第十二章:数据管理第十三章:组件和依赖管理第十四章:版本控制进阶第十五章:持续交付管理
为啥新环境的Kafka性能这么差?
本故事纯属虚构,如有雷同,纯属巧合,一笑了之。公司分配给了A和B一个任务,测试容器化Kafka集群的性能。之前B在老机器上已经测试过一个版本,并写了完整的报告,算是有经验的老鸟了。现在到了一批新机器,需要在它们上面重新测试一下Kafka的性能,A主动承担这个该任务,要知道新机器不管从cpu核数还是内存大小都是老机器的两倍,而且新机器用的是SSD盘,而老机器用的是机械盘。A信心满满,认认真真地按照之前B写的文档操作。可测试结果让他大吃一惊,新机器的性能竟然不到老机器的一半。
网络问题?
A:这个Kafka集群压测数据怎么这么差?会不会是网络问题呢?B:之前我们用的是万M网卡,你这个是多少?A:网卡速度怎么看?B:用ethtool命令,后面加对应的网络接口名,看Speed值,就能知道是万M还是千M网卡了。
123456$ ethtool eth0Settings for em0:Supported ports: [ TP ]...Speed: 1000Mb/s...
A:这是千M网卡,怪不得性能会这么差呢。B:你确定是网卡的问题吗?你压测的时候用nload命令查看一下网络的带宽有没有跑 ...
创建自签证书步骤
根证书创建
123$ openssl genrsa -out ca.key 2048$ openssl req -new -x509 -days 36500 -key ca.key -out ca.crt -subj "/C=CN/ST=shanxi/L=taiyuan/O=cn/OU=test/CN=example.com"$ #或者 openssl req -new -x509 -days 36500 -key ca.key -out ca.crt 手动输入配置
创建证书并使用根证书签发
123$ openssl genrsa -out app.key 2048$ openssl req -new -key app.key -out app.csr$ openssl x509 -req -in app.csr -CA ca.crt -CAkey ca.key -out app.crt -days 3650 -CAcreateserial
使用 Openssl 工具查看证书信息
123$ openssl x509 -in app.crt -noout -dat ...
将字符串进行压缩后保存该如何做?
如何将zip文件挂载到容器Pod中呢?Prometheus operator中看到的一个特殊玩法。它将prometheus.yml进行压缩成.gz后再保存到secret中。可参考它来实现对数据的压缩与加密。具体的操作如下:
12$ echo "abc" | gzip | base64H4sIAAAAAAAAA0tMSuYCAE6BiEcEAAAA
解密操作:
1$ echo "H4sIAAAAAAAAA0tMSuYCAE6BiEcEAAAA" | base64 -d | gunzip
大家可以尝试下。另外需要注意的是,将该数据挂载到POD的文件中,文件是压缩后的gz文件。
性能测试方案设计与测试过程
性能测试过程
性能测试计划
按照模板生成性能测试计划
指标设计(并发数、在线数、TPS、请求超时)挑选典型交易(20%交易,覆盖80%流量)环境、数据准备(与生产环境尽量一致)场景设计(基础场景、专项场景)测试进度安排
需求分析、调研
了解业务需求
环境、数据准备:
系统部署
真实含义的业务数据
数据量为生产数据量三年以后的数据量。
场景分析设计
挑选交易,典型交易:高频交易,逻辑复杂的交易,集中时间段的场景
单交易运行——>单交易负载场景
混合场景设计:混合容量设计,浪涌设计(20->100,100->20)
稳定性场景设计(48小时、72小时持续压力验证)
场景执行、应用监控
执行测试场景
问题定位、分析优化
分析问题
回归验证
性能测试报告
测试结果汇总形成报告
性能测试方案扩展引入多样化的性能监控工具(prometheus/JVM/pinpoint/skywalking)丰富性能场景设计(扩展性场景、可靠性场景、网络异常等情况)可持续性能压测(Jmeter进行自动化性能测 ...
持续交付发布可靠软件的系统方法(交付生态圈)第十三章:组件和依赖管理
《持续交付发布可靠软件的系统方法》读书笔记
持续交付让应用程序处于随时可发布的状态。在大型重构或添加复杂功能时,要继续保持应用的可发布状态,需要对大型应用组件化。组件是指应用程序中的一个规模相当大的代码结构,它具有一套定义良好的API,而且可以被另一种实现方式代替。一个基于组件的软件系统,通常其代码库被分成多个相互分离的部分,每个部分通过有限的定义良好的接口提供一些服务与其他组件进行有限的交互。有人把组件称为模块。基于组件的设计是一种良好的架构,具有松耦合性。
保持应用程序可发布团队不断地增加新特性,可以给每次新特性创建新的分支,当新特性完成后,再将它合并到主分支。这将会导致合并周期变长,无法做到持续集成,这种方法不是最好的。提倡每个人都应该提交到主干。可是这样又该如何保证主干一直保持可发布状态呢?有如下四种策略:
将新功能隐藏起来,直到它完成为止。一种方法是把新功能直接放进主干,但对用户不可见,比如通过单独的URL来访问,通过Web服务器配置不允许访问其入口;另一种方法是通过配置项开关来管理。把功能半成品与系统其他部分一同发布是一个好实践。
将所有的变更都变成一系列的增量小修改,而 ...







