基于 Go/Grpc/kubernetes/Istio 开发微服务的最佳实际尝试 – 1/3
基于 Go/Grpc/kubernetes/Istio 开发微服务的最佳实际尝试 – 2/3
基于 Go/Grpc/kubernetes/Istio 开发微服务的最佳实际尝试 – 3/3
我的项目地址:https://github.com/janrs-io/Jgrpc
转载请注明起源:https://janrs.com/6rdh
在前两局部中,咱们创立了两个微服务:pingservice
和 pongservice
。在这一部分中,咱们将创立用于主动部署的 CICD pipeline
。
咱们假如您曾经部署了Jenkins/Gitlab/Harbor
和Kubenertes/Istio
。
我的项目构造
devops
├── README.md
├── ping
│ └── dev
│ ├── Deployment.yaml
│ ├── Dockerfile
│ ├── Jenkinsfile
│ └── Service.yaml
└── pong
└── dev
├── Deployment.yaml
├── Dockerfile
├── Jenkinsfile
└── Service.yaml
4 directories, 9 files
实际
在 Jenkins
上,为每个微服务项目创立一个目录,而后在该目录下创立 dev/test/prod
流水线。
在 Gitlab
上,设置三个分支爱护分支:dev/test/prod
。这三个分支用于 dev/test/production
环境。这三个分支只能合并不能提交。
如果有新的微服务要开发,在 dev
分支的根底上新建一个分支,名称格局为:dev-*
。例如:dev-ping、dev-pong
。
而后为每个分支设置 webhook
,主动触发 Jenkins pipeline
主动部署到 kubernetes
集群。
微服务本地开发须要调试. 能够应用 kubefwd 工具或者kubernetes
官网举荐的 telepresence。
大型开发实际
如果你的公司倒退到集团化规模,须要异地协同开发,能够将 devops
、istio-manifests
、kubernetes-manifests
离开,创立一个独立的 git-repo
进行治理。
并且还能够在 src/
目录下将不同的微服务离开,创立不同的 git-repos
进行治理。
不同团队须要将开发好的 grpc
接口文档化并公布到网上,所有人员依据网上的接口文档进行开发调试。
相干我的项目和材料
感激以下资源的贡献者:
- GoogleCloudPlatform/microservices-demo
- GitOps Decisions: Creating a Mature Pipeline
- buf build
- wire
- gRPC Ecosystem
转载请注明起源:https://janrs.com/6rdh