SRE现网管控建设做到位后，考虑用一条流水线实现从源码到发布的全流程自动化。
定时每晚2点
基于master分支
升级测试环境
人工卡点 等待审批
升级生产环境
集成分支代码回合至主分支
1-是否提测的代码已经提pr， 2-是否已经合入。
data-service 数据服务api总入口
PV
ingress-nginx
PVC
测试环境
es-dev 1个节点
线上环境
es-new 3个节点
Kibana
elasticsearch
rocketmq（测试环境独有）
几十个grpc服务
apiserver
抖音
支付接口
- 支付宝
- 云账户
- 微信
istio-system
kube-system
友盟
快递100
b站
ERP
云片
小红书
快手
SLB
6443 端口
微博
微信客服
mail邮箱服务
canal
snowflake
mongodb
rocketmq
mysql
nas
oss
sls
redis
安装
brew install kubectl
自动补全配置
为了在所有的 Shell 会话中实现此功能，请将下面内容加入到文件 ~/.zshrc 中。
source <(kubectl completion zsh)
比如直接执行
echo "source <(kubectl completion bash)" >> ~/.zshrc
当我输入kubectl命令，背后发生了什么
好用的提速kubectl的工具kubectx kubens
https://github.com/ahmetb/kubectx
多集群，多namespace管理的时候，尤其好用，避免了很多的重复指定-n dev这种操作。
安装完fzf后，只敲命令不跟参数，则会自动进入fzf模糊搜索模式。
//阻塞式命令，拿来控制流程
kubectl wait --for=condition=Ready pods --all --timeout=1200s
//获取指定label的pod信息
kubectl get pod --show-labels |grep app-ch
kube-apiserver
负责分配调度pod到集群内的节点，监听kube-apiserver，查询还未分配node的pod，然后根据调度策略为这些pod分配节点（更新pod的NodeName字段）
安装
brew install kubectl
自动补全配置
为了在所有的 Shell 会话中实现此功能，请将下面内容加入到文件 ~/.zshrc 中。
source <(kubectl completion zsh)
比如直接执行
echo "source <(kubectl completion bash)" >> ~/.zshrc
当我输入kubectl命令，背后发生了什么
好用的提速kubectl的工具kubectx kubens
https://github.com/ahmetb/kubectx
多集群，多namespace管理的时候，尤其好用，避免了很多的重复指定-n dev这种操作。
安装完fzf后，只敲命令不跟参数，则会自动进入fzf模糊搜索模式。
//阻塞式命令，拿来控制流程
kubectl wait --for=condition=Ready pods --all --timeout=1200s
//获取指定label的pod信息
kubectl get pod --show-labels |grep app-ch
etcd
kube-controller-manager
监控
kube-scheduler
coreDNS
metric-server
node节点
前端请求
阿里云SLB
阿里云DNS
阿里云ALB
后面换成了SLB HTTP协议监听 443，80端口
自部署的ingress-nginx
nodeport的方式暴露
TCP协议 30001端口
ingress-nginx的svc将请求分发至ingress-nginx-controller这个pod
公网流量
前端界面
js，html，css等静态资源走oss
api请求走*.yingtu.co
ingress-nginx-controller pod根据path路由，转发请求至业务的svc
可以exec至pod，查看nginx.conf配置。
此处的配置，由ingress资源对象中配置：
kubectl get ing -n dev
https://github.com/ingtube/yamls/blob/a700d95b330de07097e884baa8ff72dc34241093/backend/app/ingress.ingress.yaml#L3
ingress作用：7层负载均衡，例如根据不同path，将请求转发至不同apiserver的svc
各个apiserver的svc将流量分发至对应pod，pod内运行着各个微服务，也是go的grpc server端
大部分微服务，除了server端注册到apiserver上以外，还需要去调用其他微服务，所以也有client端
目前微服务之间的服务发现的方法是，用etcd client去获取其他svc的地址。
redis
mysql + rocketmq
构建以及lint检查
升级测试环境
升级生产环境
构建以及lint检查
本地bugfix代码合并至master分支并push到远程
代码push至待集成分支
选择待集成分支，运行流水线
人工卡点
检查清单
- 确保上一级调测阶段一切正常
- 打开release分支，看其是否hehind落后于master分支。
- #todo-技术 在人工卡点后，再加一个执行环节，检测当前release分支是否未merge master最新代码。
- 大致看一眼『运行分支』，也就是本次发布，merge了几个feature，每个feature中的commit信息都要有tapd的单号跟踪。
权限列表
测试等环境owner，才有权限部署升级测试环境。
人工卡点
上线线上前检查清单
- 确保测试环境完全正常
- 其他现网和测试环境不一样的地方检查
- 打开release分支，看其是否hehind落后于master分支。
- #todo-技术 在人工卡点后，再加一个执行环节，检测当前release分支是否未merge master最新代码。
权限列表
生产环境的owner，sre，轮值sre才有权限部署。现网变更失败的话，需要回滚并第一时间问责。
暂时也让测试团队来审批。
维敏如何判断开发。 开发运行流水线，选集成哪几个feat分支，流水线自动创建release分支merge。 release分支唯一对应一次流水线运行版本。
版本号规划。 希望和产品的版本号，有配套关系。helm的包版本可以一一对应。镜像的版本先还是沿用原来的方案。
以前华为每次版本上线现网，会做全量回归和验证。 现在，