2021-01-06

最新推荐文章于 2023-10-11 09:43:39 发布

wubaoyu123

最新推荐文章于 2023-10-11 09:43:39 发布

阅读量2.8k

点赞数

原文链接：https://www.cnblogs.com/kevinwan/p/14239061.html

版权

博客园Logo
首页
新闻
博问
专区
闪存
班级
代码改变世界
搜索
注册
登录
Kevin Wan’s Doodle
–The more we do, the more we can do.
博客园首页新随笔联系订阅订阅管理随笔 - 96 文章 - 0 评论 - 234
从代码到部署微服务实战（一）
当前微服务已经成为服务端开发的主流架构，而Go语言因其简单易学、内置高并发、快速编译、占用内存小等特点也越来越受到开发者的青睐，微服务实战系列文章将从实战的角度和大家一起学习微服务相关的知识。本系列文章将以一个“博客系统”由浅入深的和大家一起一步步搭建起一个完整的微服务系统

该篇文章为微服务实战系列的第一篇文章，我们将基于go-zero+gitlab+jenkins+k8s构建微服务持续集成和自动构建发布系统，先对以上模块做一个简单介绍：

go-zero 是一个集成了各种工程实践的 web 和 rpc 框架。通过弹性设计保障了大并发服务端的稳定性，经受了充分的实战检验
gitlab 是一款基于 Git 的完全集成的软件开发平台，另外，GitLab 且具有wiki以及在线编辑、issue跟踪功能、CI/CD 等功能
jenkins 是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能
kubernetes 常简称为K8s，是用于自动部署、扩展和管理容器化应用程序”的开源系统。该系统由Google设计并捐赠给Cloud Native Computing Foundation（今属Linux基金会）来使用。它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台
devops1

实战主要分为五个步骤，下面针对以下的五个步骤分别进行详细的讲解

第一步环境搭建，这里我采用了两台ubuntu16.04服务器分别安装了gitlab和jenkins，采用xxx云弹性k8s集群
第二步生成项目，这里我采用go-zero提供的goctl工具快速生成项目，并对项目做简单的修改以便测试
第三部生成Dockerfile和k8s部署文件，k8s部署文件编写复杂而且容易出错，goctl工具提供了生成Dockerfile和k8s部署文件的功能非常的方便
Jenkins Pipeline采用声明式语法构建，创建Jenkinsfile文件并使用gitlab进行版本管理
最后进行项目测试验证服务是否正常
experiment_step
环境搭建
首先我们搭建实验环境，这里我采用了两台ubuntu16.04服务器，分别安装了gitlab和jenkins。gtilab使用apt-get直接安装，安装好后启动服务并查看服务状态，各组件为run状态说明服务已经启动，默认端口为9090直接访问即可

gitlab-ctl start // 启动服务

gitlab-ctl status // 查看服务状态

run: alertmanager: (pid 1591) 15442s; run: log: (pid 2087) 439266s
run: gitaly: (pid 1615) 15442s; run: log: (pid 2076) 439266s
run: gitlab-exporter: (pid 1645) 15442s; run: log: (pid 2084) 439266s
run: gitlab-workhorse: (pid 1657) 15441s; run: log: (pid 2083) 439266s
run: grafana: (pid 1670) 15441s; run: log: (pid 2082) 439266s
run: logrotate: (pid 5873) 1040s; run: log: (pid 2081) 439266s
run: nginx: (pid 1694) 15440s; run: log: (pid 2080) 439266s
run: node-exporter: (pid 1701) 15439s; run: log: (pid 2088) 439266s
run: postgres-exporter: (pid 1708) 15439s; run: log: (pid 2079) 439266s
run: postgresql: (pid 1791) 15439s; run: log: (pid 2075) 439266s
run: prometheus: (pid 10763) 12s; run: log: (pid 2077) 439266s
run: puma: (pid 1816) 15438s; run: log: (pid 2078) 439266s
run: redis: (pid 1821) 15437s; run: log: (pid 2086) 439266s
run: redis-exporter: (pid 1826) 15437s; run: log: (pid 2089) 439266s
run: sidekiq: (pid 1835) 15436s; run: log: (pid 2104) 439266s
jenkins也是用apt-get直接安装，需要注意的是安装jenkins前需要先安装java，过程比较简单这里就不再演示，jenkins默认端口为8080，默认账号为admin，初始密码路径为/var/lib/jenkins/secrets/initialAdminPassword，初始化安装推荐的插件即可，后面可以根据自己的需要再安装其它插件

k8s集群搭建过程比较复杂，虽然可以使用kubeadm等工具快速搭建，但距离真正的生产级集群还是有一定差距，因为我们的服务最终是要上生产的，所以这里我选择了xxx云的弹性k8s集群版本为1.16.9，弹性集群的好处是按需收费没有额外的费用，当我们实验完成后通过kubectl delete立马释放资源只会产生很少的费用，而且xxx云的k8s集群给我们提供了友好的监控页面，可以通过这些界面查看各种统计信息，集群创建好后需要创建集群访问凭证才能访问集群

若当前访问客户端尚未配置任何集群的访问凭证，即 ~/.kube/config 内容为空，可直接将访问凭证内容并粘贴入 ~/.kube/config 中

若当前访问客户端已配置了其他集群的访问凭证，需要通过如下命令合并凭证

KUBECONFIG=_{/.kube/config:}/Downloads/k8s-cluster-config kubectl config view --merge --flatten > ~/.kube/config
export KUBECONFIG=~/.kube/config
配置好访问权限后通过如下命令可查看当前集群

kubectl config current-context
查看集群版本，输出内容如下

kubectl version

Client Version: version.Info{Major:“1”, Minor:“16”, GitVersion:“v1.16.9”, GitCommit:“a17149e1a189050796ced469dbd78d380f2ed5ef”, GitTreeState:“clean”, BuildDate:“2020-04-16T11:44:51Z”, GoVersion:“go1.13.9”, Compiler:“gc”, Platform:“linux/amd64”}
Server Version: version.Info{Major:“1”, Minor:“16+”, GitVersion:“v1.16.9-eks.2”, GitCommit:“f999b99a13f40233fc5f875f0607448a759fc613”, GitTreeState:“clean”, BuildDate:“2020-10-09T12:54:13Z”, GoVersion:“go1.13.9”, Compiler:“gc”, Platform:“linux/amd64”}
到这里我们的试验已经搭建完成了，这里版本管理也可以使用github

生成项目
整个项目采用大仓的方式，目录结构如下，最外层项目命名为blog，app目录下为按照业务拆分成的不同的微服务，比如user服务下面又分为api服务和rpc服务，其中api服务为聚合网关对外提供restful接口，而rpc服务为内部通信提供高性能的数据缓存等操作

├── blog
│ ├── app
│ │ ├── user
│ │ │ ├── api
│ │ │ └── rpc
│ │ ├── article
│ │ │ ├── api
│ │ │ └── rpc
项目目录创建好之后我们进入api目录创建user.api文件，文件内容如下，定义服务端口为2233，同时定义了一个/user/info接口

type UserInfoRequest struct {
Uid int64 form:"uid"
}

type UserInfoResponse struct {
Uid int64 json:"uid"
Name string json:"name"
Level int json:"level"
}

@server(
port: 2233
)
service user-api {
@doc(
summary: 获取用户信息
)
@server(
handler: UserInfo
)
get /user/info(UserInfoRequest) returns(UserInfoResponse)
}
定义好api文件之后我们执行如下命令生成api服务代码，一键生成真是能大大提升我们的生产力呢

goctl api go -api user.api -dir .
代码生成后我们对代码稍作改造以便后面部署后方便进行测试，改造后的代码为返回本机的ip地址

func (ul *UserInfoLogic) UserInfo(req types.UserInfoRequest) (*types.UserInfoResponse, error) {
addrs, err := net.InterfaceAddrs()
if err != nil {
return nil, err
}
var name string
for _, addr := range addrs {
if ipnet, ok := addr.(*net.IPNet); ok && !ipnet.IP.IsLoopback() && ipnet.IP.To4() != nil {
name = ipnet.IP.String()
}
}

return &types.UserInfoResponse{
	Uid:   req.Uid,
	Name:  name,
	Level: 666,
}, nil

}
到这里服务生成部分就完成了，因为本节为基础框架的搭建所以只是添加一些测试的代码，后面会继续丰富项目代码

生成镜像和部署文件
一般的常用镜像比如mysql、memcache等我们可以直接从镜像仓库拉取，但是我们的服务镜像需要我们自定义，自定义镜像有多重方式而使用Dockerfile则是使用最多的一种方式，使用Dockerfile定义镜像虽然不难但是也很容易出错，所以这里我们也借助工具来自动生成，这里就不得不再夸一下goctl这个工具真的是棒棒的，还能帮助我们一键生成Dockerfile呢，在api目录下执行如下命令

goctl docker -go user.go
生成后的文件稍作改动以符合我们的目录结构，文件内容如下，采用了两阶段构建，第一阶段构建可执行文件确保构建独立于宿主机，第二阶段会引用第一阶段构建的结果，最终构建出极简镜像

FROM golang:alpine AS builder

LABEL stage=gobuilder

ENV CGO_ENABLED 0
ENV GOOS linux
ENV GOPROXY https://goproxy.cn,direct

WORKDIR /build/zero

RUN go mod init blog/app/user/api
RUN go mod download
COPY . .
COPY /etc /app/etc
RUN go build -ldflags="-s -w" -o /app/user user.go

FROM alpine

RUN apk update --no-cache && apk add --no-cache ca-certificates tzdata
ENV TZ Asia/Shanghai

WORKDIR /app
COPY --from=builder /app/user /app/user
COPY --from=builder /app/etc /app/etc

CMD ["./user", “-f”, “etc/user-api.yaml”]
然后执行如下命令创建镜像

docker build -t user:v1 app/user/api/
这个时候我们使用docker images命令查看镜像会发现user镜像已经创建，版本为v1

REPOSITORY TAG IMAGE ID CREATED SIZE
user v1 1c1f64579b40 4 days ago 17.2MB
同样，k8s的部署文件编写也比较复杂很容易出错，所以我们也使用goctl自动来生成，在api目录下执行如下命令

goctl kube deploy -name user-api -namespace blog -image user:v1 -o user.yaml -port 2233
生成的ymal文件如下

apiVersion: apps/v1
kind: Deployment
metadata:
name: user-api
namespace: blog
labels:
app: user-api
spec:
replicas: 2
revisionHistoryLimit: 2
selector:
matchLabels:
app: user-api
template:
metadata:
labels:
app: user-api
spec:
containers:
- name: user-api
image: user:v1
lifecycle:
preStop:
exec:
command: [“sh”,"-c",“sleep 5”]
ports:
- containerPort: 2233
readinessProbe:
tcpSocket:
port: 2233
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 2233
initialDelaySeconds: 15
periodSeconds: 10
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: 1000m
memory: 1024Mi
到此生成镜像和k8s部署文件步骤已经结束了，上面主要是为了演示，真正的生产环境中都是通过持续集成工具自动创建镜像的

Jenkins Pipeline
jenkins是常用的继续集成工具，其提供了多种构建方式，而pipeline是最常用的构建方式之一，pipeline支持声名式和脚本式两种方式，脚本式语法灵活、可扩展，但也意味着更复杂，而且需要学习Grovvy语言，增加了学习成本，所以才有了声明式语法，声名式语法是一种更简单，更结构化的语法，我们后面也都会使用声名式语法

这里再介绍下Jenkinsfile，其实Jenkinsfile就是一个纯文本文件，也就是部署流水线概念在Jenkins中的表现形式，就像Dockerfile之于Docker，所有的部署流水线逻辑都可在Jenkinsfile文件中定义，需要注意，Jenkins默认是不支持Jenkinsfile的，我们需要安装Pipeline插件，安装插件的流程为Manage Jenkins -> Manager Plugins 然后搜索安装即可，之后便可构建pipeline了

pipeline_build
我们可以直接在pipeline的界面中输入构建脚本，但是这样没法做到版本化，所以如果不是临时测试的话是不推荐这种方式的，更通用的方式是让jenkins从git仓库中拉取Jenkinsfile并执行

首先需要安装Git插件，然后使用ssh clone方式拉取代码，所以，需要将git私钥放到jenkins中，这样jenkins才有权限从git仓库拉取代码

将git私钥放到jenkins中的步骤是：Manage Jenkins -> Manage credentials -> 添加凭据，类型选择为SSH Username with private key，接下来按照提示进行设置就可以了，如下图所示

gitlab_tokens
然后在我们的gitlab中新建一个项目，只需要一个Jenkinsfile文件

gitlab_jenkinsfile

在user-api项目中流水线定义选择Pipeline script from SCM，添加gitlab ssh地址和对应的token，如下图所示

jenkinsfile_responsitory
接着我们就可以按照上面的实战步骤进行Jenkinsfile文件的编写了

从gitlab拉取代码，从我们的gitlab仓库中拉取代码，并使用commit_id用来区分不同版本

stage(‘从gitlab拉取服务代码’) {
steps {
echo ‘从gitlab拉取服务代码’
git credentialsId: ‘xxxxxxxx’, url: ‘http://xxx.xxx.xxx.xxx:xxx/blog/blog.git’
script {
commit_id = sh(returnStdout: true, script: ‘git rev-parse --short HEAD’).trim()
}
}
}
构建docker镜像，使用goctl生成的Dockerfile文件构建镜像

stage(‘构建镜像’) {
steps {
echo ‘构建镜像’
sh “docker build -t user:${commit_id} app/user/api/”
}
}
上传镜像到镜像仓库，把生产的镜像push到镜像仓库

stage(‘上传镜像到镜像仓库’) {
steps {
echo “上传镜像到镜像仓库”
sh “docker login -u xxx -p xxxxxxx”
sh “docker tag user: ${commit_id} xxx/user:$ {commit_id}”
sh “docker push xxx/user:${commit_id}”
}
}
部署到k8s，把部署文件中的版本号替换，从远程拉取镜，使用kubectl apply命令进行部署

stage(‘部署到k8s’) {
steps {
echo “部署到k8s”
sh “sed -i ‘s/<COMMIT_ID_TAG>/${commit_id}/’ app/user/api/user.yaml”
sh “cp app/user/api/user.yaml .”
sh “kubectl apply -f user.yaml”
}
}
完整的Jenkinsfile文件如下

pipeline {
agent any

stages {
	stage('从gitlab拉取服务代码') {
		steps {
			echo '从gitlab拉取服务代码'
			git credentialsId: 'xxxxxx', url: 'http://xxx.xxx.xxx.xxx:9090/blog/blog.git'
			script {
			    commit_id = sh(returnStdout: true, script: 'git rev-parse --short HEAD').trim()
			}
		}
	}
	stage('构建镜像') {
	    steps {
	        echo '构建镜像'
	        sh "docker build -t user:${commit_id} app/user/api/"
	    }
	}
	stage('上传镜像到镜像仓库') {
	    steps {
	        echo "上传镜像到镜像仓库"
	        sh "docker login -u xxx -p xxxxxxxx"
	        sh "docker tag user:${commit_id} xxx/user:${commit_id}"
	        sh "docker push xxx/user:${commit_id}"
	    }
	}
	stage('部署到k8s') {
	    steps {
	        echo "部署到k8s"
            sh "sed -i 's/<COMMIT_ID_TAG>/${commit_id}/' app/user/api/user.yaml"
            sh "kubectl apply -f app/user/api/user.yaml"
	    }
	}
}

}
到这里所有的配置基本完毕，我们的基础框架也基本搭建完成，下面开始执行pipeline，点击左侧的立即构建在下面Build History中就回产生一个构建历史序列号，点击对应的序列号然后点击左侧的Console Output即可查看构建过程的详细信息，如果构建过程出现错误也会在这里输出

buid_step

构建详细输出如下，pipeline对应的每一个stage都有详细的输出

Started by user admin
Obtained Jenkinsfile from git git@xxx.xxx.xxx.xxx:gitlab-instance-1ac0cea5/pipelinefiles.git
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/lib/jenkins/workspace/user-api
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
Selected Git installation does not exist. Using Default
The recommended git tool is: NONE
using credential gitlab_token

git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url git@xxx.xxx.xxx.xxx:gitlab-instance-1ac0cea5/pipelinefiles.git # timeout=10
Fetching upstream changes from git@xxx.xxx.xxx.xxx:gitlab-instance-1ac0cea5/pipelinefiles.git
git --version # timeout=10
git --version # ‘git version 2.7.4’
using GIT_SSH to set credentials
git fetch --tags --progress git@xxx.xxx.xxx.xxx:gitlab-instance-1ac0cea5/pipelinefiles.git +refs/heads/:refs/remotes/origin/ # timeout=10
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision 77eac3a4ca1a5b6aea705159ce26523ddd179bdf (refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f 77eac3a4ca1a5b6aea705159ce26523ddd179bdf # timeout=10
Commit message: “add”
git rev-list --no-walk 77eac3a4ca1a5b6aea705159ce26523ddd179bdf # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (从gitlab拉取服务代码)
[Pipeline] echo
从gitlab拉取服务代码
[Pipeline] git
The recommended git tool is: NONE
using credential gitlab_user_pwd
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url http://xxx.xxx.xxx.xxx:9090/blog/blog.git # timeout=10
Fetching upstream changes from http://xxx.xxx.xxx.xxx:9090/blog/blog.git
git --version # timeout=10
git --version # ‘git version 2.7.4’
using GIT_ASKPASS to set credentials
git fetch --tags --progress http://xxx.xxx.xxx.xxx:9090/blog/blog.git +refs/heads/:refs/remotes/origin/ # timeout=10
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision b757e9eef0f34206414bdaa4debdefec5974c3f5 (refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f b757e9eef0f34206414bdaa4debdefec5974c3f5 # timeout=10
git branch -a -v --no-abbrev # timeout=10
git branch -D master # timeout=10
git checkout -b master b757e9eef0f34206414bdaa4debdefec5974c3f5 # timeout=10
Commit message: “Merge branch ‘blog/dev’ into ‘master’”
git rev-list --no-walk b757e9eef0f34206414bdaa4debdefec5974c3f5 # timeout=10
[Pipeline] script
[Pipeline] {
[Pipeline] sh

git rev-parse --short HEAD
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (构建镜像)
[Pipeline] echo
构建镜像
[Pipeline] sh
docker build -t user:b757e9e app/user/api/
Sending build context to Docker daemon 28.16kB

Step 1/18 : FROM golang:alpine AS builder
alpine: Pulling from library/golang
801bfaa63ef2: Pulling fs layer
ee0a1ba97153: Pulling fs layer
1db7f31c0ee6: Pulling fs layer
ecebeec079cf: Pulling fs layer
63b48972323a: Pulling fs layer
ecebeec079cf: Waiting
63b48972323a: Waiting
1db7f31c0ee6: Verifying Checksum
1db7f31c0ee6: Download complete
ee0a1ba97153: Verifying Checksum
ee0a1ba97153: Download complete
63b48972323a: Verifying Checksum
63b48972323a: Download complete
801bfaa63ef2: Verifying Checksum
801bfaa63ef2: Download complete
801bfaa63ef2: Pull complete
ee0a1ba97153: Pull complete
1db7f31c0ee6: Pull complete
ecebeec079cf: Verifying Checksum
ecebeec079cf: Download complete
ecebeec079cf: Pull complete
63b48972323a: Pull complete
Digest: sha256:49b4eac11640066bc72c74b70202478b7d431c7d8918e0973d6e4aeb8b3129d2
Status: Downloaded newer image for golang:alpine
—> 1463476d8605
Step 2/18 : LABEL stage=gobuilder
—> Running in c4f4dea39a32
Removing intermediate container c4f4dea39a32
—> c04bee317ea1
Step 3/18 : ENV CGO_ENABLED 0
—> Running in e8e848d64f71
Removing intermediate container e8e848d64f71
—> ff82ee26966d
Step 4/18 : ENV GOOS linux
—> Running in 58eb095128ac
Removing intermediate container 58eb095128ac
—> 825ab47146f5
Step 5/18 : ENV GOPROXY https://goproxy.cn,direct
—> Running in df2add4e39d5
Removing intermediate container df2add4e39d5
—> c31c1aebe5fa
Step 6/18 : WORKDIR /build/zero
—> Running in f2a1da3ca048
Removing intermediate container f2a1da3ca048
—> 5363d05f25f0
Step 7/18 : RUN go mod init blog/app/user/api
—> Running in 11d0adfa9d53
[91mgo: creating new go.mod: module blog/app/user/api
[0mRemoving intermediate container 11d0adfa9d53
—> 3314852f00fe
Step 8/18 : RUN go mod download
—> Running in aa9e9d9eb850
Removing intermediate container aa9e9d9eb850
—> a0f2a7ffe392
Step 9/18 : COPY . .
—> a807f60ed250
Step 10/18 : COPY /etc /app/etc
—> c4c5d9f15dc0
Step 11/18 : RUN go build -ldflags="-s -w" -o /app/user user.go
—> Running in a4321c3aa6e2
[91mgo: finding module for package github.com/tal-tech/go-zero/core/conf
[0m[91mgo: finding module for package github.com/tal-tech/go-zero/rest/httpx
[0m[91mgo: finding module for package github.com/tal-tech/go-zero/rest
[0m[91mgo: finding module for package github.com/tal-tech/go-zero/core/logx
[0m[91mgo: downloading github.com/tal-tech/go-zero v1.1.1
[0m[91mgo: found github.com/tal-tech/go-zero/core/conf in github.com/tal-tech/go-zero v1.1.1
go: found github.com/tal-tech/go-zero/rest in github.com/tal-tech/go-zero v1.1.1
go: found github.com/tal-tech/go-zero/rest/httpx in github.com/tal-tech/go-zero v1.1.1
go: found github.com/tal-tech/go-zero/core/logx in github.com/tal-tech/go-zero v1.1.1
[0m[91mgo: downloading gopkg.in/yaml.v2 v2.4.0
[0m[91mgo: downloading github.com/justinas/alice v1.2.0
[0m[91mgo: downloading github.com/dgrijalva/jwt-go v3.2.0+incompatible
[0m[91mgo: downloading go.uber.org/automaxprocs v1.3.0
[0m[91mgo: downloading github.com/spaolacci/murmur3 v1.1.0
[0m[91mgo: downloading github.com/google/uuid v1.1.1
[0m[91mgo: downloading google.golang.org/grpc v1.29.1
[0m[91mgo: downloading github.com/prometheus/client_golang v1.5.1
[0m[91mgo: downloading github.com/beorn7/perks v1.0.1
[0m[91mgo: downloading github.com/golang/protobuf v1.4.2
[0m[91mgo: downloading github.com/prometheus/common v0.9.1
[0m[91mgo: downloading github.com/cespare/xxhash/v2 v2.1.1
[0m[91mgo: downloading github.com/prometheus/client_model v0.2.0
[0m[91mgo: downloading github.com/prometheus/procfs v0.0.8
[0m[91mgo: downloading github.com/matttproud/golang_protobuf_extensions v1.0.1
[0m[91mgo: downloading google.golang.org/protobuf v1.25.0
[0mRemoving intermediate container a4321c3aa6e2
—> 99ac2cd5fa39
Step 12/18 : FROM alpine
latest: Pulling from library/alpine
801bfaa63ef2: Already exists
Digest: sha256:3c7497bf0c7af93428242d6176e8f7905f2201d8fc5861f45be7a346b5f23436
Status: Downloaded newer image for alpine:latest
—> 389fef711851
Step 13/18 : RUN apk update --no-cache && apk add --no-cache ca-certificates tzdata
—> Running in 51694dcb96b6
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
v3.12.3-38-g9ff116e4f0 [http://dl-cdn.alpinelinux.org/alpine/v3.12/main]
v3.12.3-39-ge9195171b7 [http://dl-cdn.alpinelinux.org/alpine/v3.12/community]
OK: 12746 distinct packages available
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/2) Installing ca-certificates (20191127-r4)
(2/2) Installing tzdata (2020f-r0)
Executing busybox-1.31.1-r19.trigger
Executing ca-certificates-20191127-r4.trigger
OK: 10 MiB in 16 packages
Removing intermediate container 51694dcb96b6
—> e5fb2e4d5eea
Step 14/18 : ENV TZ Asia/Shanghai
—> Running in 332fd0df28b5
Removing intermediate container 332fd0df28b5
—> 11c0e2e49e46
Step 15/18 : WORKDIR /app
—> Running in 26e22103c8b7
Removing intermediate container 26e22103c8b7
—> 11d11c5ea040
Step 16/18 : COPY --from=builder /app/user /app/user
—> f69f19ffc225
Step 17/18 : COPY --from=builder /app/etc /app/etc
—> b8e69b663683
Step 18/18 : CMD ["./user", “-f”, “etc/user-api.yaml”]
—> Running in 9062b0ed752f
Removing intermediate container 9062b0ed752f
—> 4867b4994e43
Successfully built 4867b4994e43
Successfully tagged user:b757e9e
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (上传镜像到镜像仓库)
[Pipeline] echo
上传镜像到镜像仓库
[Pipeline] sh

docker login -u xxx -p xxxxxxxx
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /var/lib/jenkins/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

docker tag user:b757e9e xxx/user:b757e9e
[Pipeline] sh
docker push xxx/user:b757e9e
The push refers to repository [docker.io/xxx/user]
b19a970f64b9: Preparing
f695b957e209: Preparing
ee27c5ca36b5: Preparing
7da914ecb8b0: Preparing
777b2c648970: Preparing
777b2c648970: Layer already exists
ee27c5ca36b5: Pushed
b19a970f64b9: Pushed
7da914ecb8b0: Pushed
f695b957e209: Pushed
b757e9e: digest: sha256:6ce02f8a56fb19030bb7a1a6a78c1a7c68ad43929ffa2d4accef9c7437ebc197 size: 1362
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (部署到k8s)
[Pipeline] echo
部署到k8s
[Pipeline] sh
sed -i s/<COMMIT_ID_TAG>/b757e9e/ app/user/api/user.yaml
[Pipeline] sh
kubectl apply -f app/user/api/user.yaml
deployment.apps/user-api created
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
可以看到最后输出了SUCCESS说明我们的pipeline已经成了，这个时候我们可以通过kubectl工具查看一下，-n参数为指定namespace

kubectl get pods -n blog

NAME READY STATUS RESTARTS AGE
user-api-84ffd5b7b-c8c5w 1/1 Running 0 10m
user-api-84ffd5b7b-pmh92 1/1 Running 0 10m
我们在k8s部署文件中制定了命名空间为blog，所以在执行pipeline之前我们需要先创建这个namespance

kubectl create namespace blog
服务已经部署好了，那么接下来怎么从外部访问服务呢？这里使用LoadBalancer方式，Service部署文件定义如下，80端口映射到容器的2233端口上，selector用来匹配Deployment中定义的label

apiVersion: v1
kind: Service
metadata:
name: user-api-service
namespace: blog
spec:
selector:
app: user-api
type: LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 2233
执行创建service，创建完后查看service输出如下，注意一定要加上-n参数指定namespace

kubectl apply -f user-service.yaml
kubectl get services -n blog

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
user-api-service LoadBalancer xxx.xxx.xxx.xx 80:32470/TCP 79m
这里的EXTERNAL-IP 即为提供给外网访问的ip，端口为80

到这里我们的所有的部署任务都完成了，大家最好也能亲自动手来实践一下

测试
最后我们来测试下部署的服务是否正常，使用EXTERNAL-IP来进行访问

curl “http://xxx.xxx.xxx.xxx:80/user/info?uid=1”

{“uid”:1,“name”:“172.17.0.5”,“level”:666}

curl http://xxx.xxx.xxx.xxx:80/user/info?uid=1

{“uid”:1,“name”:“172.17.0.8”,“level”:666}
curl访问了两次/user/info接口，都能正常返回，说明我们的服务没有问题，name字段分别输出了两个不同ip，可以看出LoadBalancer默认采用了Round Robin的负载均衡策略

总结
以上我们实现了从代码开发到版本管理再到构建部署的DevOps全流程，完成了基础架构的搭建，当然这个架构现在依然很简陋。在本系列后续中，我们将以这个博客系统为基础逐渐的完善整个架构，比如逐渐的完善CI、CD流程、增加监控、博客系统功能的完善、高可用最佳实践和其原理等等

工欲善其事必先利其器，好的工具能大大提升我们的工作效率而且能降低出错的可能，上面我们大量使用了goctl工具简直有点爱不释手了哈哈哈，下次见

由于个人能力有限难免有表达有误的地方，欢迎广大观众姥爷批评指正！

项目地址
https://github.com/tal-tech/go-zero

欢迎使用并 star 支持我们！👏

go-zero 系列文章见『微服务实践』公众号

好文要顶关注我收藏该文
Kevin Wan
关注 - 1
粉丝 - 58
+加关注
00
« 上一篇：缓存原理与微服务缓存自动管理
posted on 2021-01-06 08:53 Kevin Wan 阅读(69) 评论(0) 编辑收藏
刷新评论刷新页面返回顶部
登录后才能发表评论，立即登录或注册，访问网站首页
【推荐】News: 大型组态、工控、仿真、CADGIS 50万行VC++源码免费下载
【推荐】有你助力，更好为你——博客园用户消费观调查，附带小惊喜！
【推荐】AWS携手博客园为开发者送福利，注册立享12个月免费套餐
【推荐】七牛云新老用户同享 1 分钱抢 CDN 1TB流量大礼包！
【推荐】了不起的开发者，挡不住的华为，园子里的品牌专区
【推荐】未知数的距离，毫秒间的传递，声网与你实时互动
【推荐】新一代 NoSQL 数据库，Aerospike专区新鲜入驻

相关博文：
· dapr微服务.netcore sdk入门
· 微擎微赞密码重置
· 微信开发 -微信支付
· 微服务
· 微服务
» 更多推荐…

最新 IT 新闻:
· 产能利用率仅5.3%，柔宇上市是假扩张、真圈钱？
· 体检异常率99%，这届打工人的身体有多差？
· 虾米音乐停止运营：8年前被阿里收购曾一起走过洪荒岁月
· 那个想去网易云的女孩倒在了拼多多
· 蔚来首款旗舰轿车专利图曝光！续航有望超900km
» 更多新闻…
昵称： Kevin Wan
园龄： 14年8个月
粉丝： 58
关注： 1
+加关注
< 2021年1月 >
日一二三四五六
27 28 29 30 31 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31 1 2 3 4 5 6

搜索

常用链接
我的随笔
我的评论
我的参与
最新评论
我的标签
我的标签
exception(1)
java(1)
随笔分类
.NET(10)
C++(9)
eXtreme Programming(2)
Interview questions(7)
IT(9)
Java(1)
Linux(2)
Living(3)
Management(2)
Misc(17)
OO(2)
Python(4)
Working in Microsoft(4)
随笔档案
2021年1月(1)
2020年12月(9)
2020年11月(6)
2020年10月(10)
2013年6月(2)
2008年4月(1)
2008年1月(1)
2007年12月(1)
2007年8月(1)
2007年5月(2)
2007年4月(1)
2007年1月(3)
2006年12月(3)
2006年11月(4)
2006年10月(4)
更多
Microsofter
Dflying’s Night
Jeffrey Zhao
My Company
Flash Chat
My Projects
cppgen
Cpp Delegate
相关链接