纯 k8s 部署实现 gitlab CICD 保姆级教程
gitlab CICD
k8s 安装 GitLab
GitLab 具有三个需要进行持久化的目录,它们分别是 /etc/gitlab、/var/log/gitlab、/var/opt/gitlab,它们分别为 Gitlab 的运行提供配置、日志、数据的持久化。我们使用 nfs 来作为 GitLab 的持久化方式(当然,你也可以选择其他方式),为此,我们需要先安装 NFS,并且在 NFS 的配置文件中进行如下修改:
vim /etc/exports
# 注意,用户的访问权限一定要设置为 no_root_squash,因为 gitlab 需要 root 权限来操作这些文件。
/data/nfs/gitlab/config 172.17.33.152(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/gitlab/logs 172.17.33.152(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/gitlab/data 172.17.33.152(rw,insecure,sync,no_root_squash,subtree_check)
# 启用新的配置文件
exportfs -r
随后在 k8s 中安装 gitlab 及其各个组件
kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
name: gitlab-svc
namespace: gitlab
spec:
type: NodePort
ports:
- port: 443
targetPort: 443
nodePort: 31443
name: https
- port: 80
nodePort: 31080
targetPort: 80
name: http
selector:
app: gitlab
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitlab-dep
namespace: gitlab
spec:
selector:
matchLabels:
app: gitlab
revisionHistoryLimit: 2
template:
metadata:
labels:
app: gitlab
spec:
containers:
- image: gitlab/gitlab-ce
name: gitlab
imagePullPolicy: IfNotPresent
ports:
- containerPort: 443
name: https
- containerPort: 80
name: http
- containerPort: 22
name: ssh
volumeMounts:
- name: gitlab-config
mountPath: /etc/gitlab
- name: gitlab-logs
mountPath: /var/log/gitlab
- name: gitlab-data
mountPath: /var/opt/gitlab
volumes:
- name: gitlab-config
nfs:
server: 172.17.33.149
path: /data/nfs/gitlab/config
- name: gitlab-logs
nfs:
server: 172.17.33.149
path: /data/nfs/gitlab/logs
- name: gitlab-data
nfs:
server: 172.17.33.149
path: /data/nfs/gitlab/data
完成后,查看 gitlab 网页暴露在哪个端口:
kubectl get svc -n gitlab
########################################## 返回结果 #########################################
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE #
# gitlab-svc NodePort 10.102.48.248 <none> 443:31443/TCP,80:31080/TCP 153m #
###########################################################################################
访问 gitlab 页面,进入登录界面
管理员用户为 root,其登录密码在容器目录 /etc/gitlab/initial_root_password 文件中,即 nfs 服务器的 /data/nfs/gitlab/config/initial_root_password 文件。获取初始密码:
kubectl exec -it -n gitlab $(kubectl get pods -n gitlab | grep gitlab | awk '{print$1}') -- cat /etc/gitlab/initial_root_password | grep Password:
登录进入系统,修改初始密码(一定要修改,因为这个临时密码的有效时间只有 24 小时)。页面路径为:右上角头像->Edit profile->左边导航栏->Password
随后可以创建一个普通用户,测试是否能正常使用 git 进行操作。
修改外部 URL
通常情况下,gitlab 会根据机器内部的 FQCN 来标记一个仓库的 url。这就导致了在 gitlab 中复制 clone url 时,其使用的不是 IP 而是一个域名。如果在局域网内部署 gitlab,这个 DNS 显然是不可以使用的。如果我们希望 gitlab 中的 url 直接使用 IP 地址,那么就需要修改配置文件 gitlab.rb
# 由于我们之前将 gitlab 的配置文件挂载到了 /data/nfs/gitlab/config 上,因此通过修改宿主机的配置文件即可
vim gitlab.rb
# 在其中添加一行:
external_url 'http://<ip>:<port>'
# 例如: external_url 'http://172.17.33.149:31080'
# 修改完配置文件后,删除原本的 gitlab pod,让其自动重启,加载配置文件
kubectl delete pod -n gitlab gitlab-5xjfiosd2jn
执行完上述操作后,我们尝试登录在外网登录 gitlab,发现无法登录。这是因为 external_url
修改后,导致 Pod 内部,gitlab 的端口也发生了变化。在没有设置之前,gitlab 是暴露在 80 端口,修改之后,gitlab 就暴露在我们设置的那个端口。因此,还需要修改 service 的 tagetPort 字段,才能让外部正常访问到 gitlab:
kubectl edit svc -n gitlab gitlab-svc
# 将 targetPort 设置为之前修改的端口
此时,我们已经可以正常访问 gitlab,查看 clone 中的 url,如下图所示:
安装 Harbor
由于 Harbor 的组件实在是太多,因此,使用 helm 作为安装手段来简化安装过程。具体过程参照文档:https://goharbor.io/docs/2.7.0/install-config/harbor-ha-helm/
helm
是一种 k8s 安装工具,它通过模板化的方式,一次性构造出一个大型项目。
# 下载 harbor chart
helm repo add harbor https://helm.goharbor.io
# 将 chart 下载至本地,执行完这一步后,当前路径会出现一个 harbor 文件夹,里面是各种安装文件
helm fetch harbor/harbor --untar
为了简化过程,我们不对其中的任何一个组件进行外部定制,只为这些组件提供必要的持久化手段。
我们先自行创建 pv 和 pvc:
# 此处使用 nfs 支持持久卷,为此需要创建多个目录以供挂载
for i in chartmuseum database jobservice redis registry trivy;do mkdir -p /data/nfs/harbor/$i; done
cat >> /etc/exports << EOF
/data/nfs/harbor/registry *(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/harbor/chartmuseum *(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/harbor/jobservice *(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/harbor/database *(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/harbor/trivy *(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/harbor/redis *(rw,insecure,sync,no_root_squash,subtree_check)
EOF
# 更新 nfs
exportfs -r
# 查看 nfs 当前提供的挂载点
showmount -e
# 创建 pv pvc
cat >> pvc-pv-chartmuseum.yaml << EOF
apiVersion: v1
kind: PersistentVolume
# pv 没有命名空间的限制
metadata:
name: harbor-chartmuseum-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
nfs:
server: 172.17.33.149
path: /data/nfs/harbor/chartmuseum
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: harbor-chartmuseum-pvc
namespace: harbor
spec:
accessModes:
- ReadWriteMany
volumeMode: Filesystem
resources:
requests:
storage: 5Gi
EOF
for i in database jobservice redis registry trivy;do cat pvc-pv-chartmuseum.yaml | sed "s/chartmuseum/$i/g" > pvc-pv-$i.yaml; done
kubectl apply -f .
# 查看 pvc、pv
kubectl get pv
kubectl get pvc -n harbor
现在,我们需要让 helm 创建的 harbor 组件使用我们的 pvc,因此,我们需要定制化这一部分功能。helm 的 chart 安装包,通常的文件结构如下:
<chart>--- conf # 通常不需要关心
|
|- template # 模板文件,就是 k8s 的 yaml 文件,在调用 helm install 指令时,helm 会根据这些模板,生成真正的 yaml 文件,并调用 kubectl apply 来启动
|
|- values.yaml # 重点关心的文件,这个文件里面存放了所有可以定制化的参数。所谓的定制化,实际上就是将模板中的一些默认参数修改为我们希望的值,而这些值,就存放在 values.yaml 文件中。
我们进入到 harbor 安装包,修改 value.yaml
文件,让 harbor 的组件使用我们自己的持久卷——不要被 value.yaml 文件的内容吓到了,我们关心的只有很小的一部分。
-
修改服务暴露方式。在自行搭建的小集群内,通常使用的暴露方式是
NodePort
,因此我们修改expose.type: nodePort
,如下图: -
修改外部 URL,即
externalURL:http://<your_k8s_ip>:30002
。如果不修改,成功部署 harbor 之后,无法登录到 harbor 管理界面,因为 harbor 只信任以这个 URL 访问的 http 请求。这也意味着,之后你也只能使用这个 url 才能登录到 harbor 中。
- 修改持久化方式。重点是修改
persistence
字段下的各个existingClaim
字段为我们之前创建的 PVC 名称
修改完成后,保存退出。最后安装即可:
# helm install 命令的格式是这样的:
# helm install <name> -n <namespace> <chart_path>
# name: 名称,不重要,给人看的
# namespace: 命名空间,指定后,所有组件都会被安装到这个命名空间下
# chart_path: 安装包的路径
helm install harbor -n harbor harbor/
你可能遇到的问题:
- 执行完安装程序后,过了很久后,pod 一直处在
CrashLoopxxx
状态:创建 harbor 是一个很久的过程,你需要耐心等待,如果 10 分钟后还有大量 Pod 没有安装成功,建议从网络、集群状态方向入手解决问题。如果只有个别 Pod 没有启动成功,你可以尝试把这些 Pod 删除,让它们自动重建。
安装 gitlab runner
config.toml 文件中的配置项及其功能可以查看官方文档: https://docs.gitlab.com/runner/executors/kubernetes.html#default-annotations-for-job-pods
概述
gitlab-runner 是 gitlab 提供的一种执行 CICD pipline 的组件。它有多种执行器,每一个执行器都提供一种实现 pipline 的方式,例如:shell 执行器是使用 shell 指令实现,docker 执行器是使用 docker api 实现。其中,最有难度的一种是 kubernetes 执行器。这种执行器会使用 k8s api 来实现 CICD pipline。
runner 的 k8s 执行器是这样执行 pipline 的:
- 首先,runner 会通过 RBAC 认证获取到调用 k8s 集群 API 的权限。
- runner 会监听 gitlab,当有合适的
job
时,runner 会自动抓取任务执行。请注意,一个流水线中可以有很多个stage
,这些stage
是串行执行的,而一个stage
中又可以有多个并行的job
,runner 抓取的任务是以job
为单位,而不是stage
,更不是pipline
。 - 随后,runner 会调用 k8s API,创建一个用于执行该 job 的 pod。通常来说,runner 创建的所有 pod 有一个通用模板,我们需要在 runner 的
config.toml
配置文件中配置这个模板。但 pod 中具体使用什么镜像、在 pod 中执行什么命令,这些都是在后续的.gitlab-ci.yml
文件中配置,并且随着 job 的不同而不同。 - 在完成了 job 内的工作后,runner 会将这个临时 pod 删除。
配置 ConfigMap
将主节点 kubeconfig 内容添加到 secret 中。这个文件的内容是 kubectl 访问 k8s 集群的准入 Token,只有在指定了该 Token 后,才能使用 kubectl 指令来对集群内的各种资源进行增删改查。由于 runner 在 CICD 过程中需要对 k8s 集群进行操作,因此,每一个 runner 中都必须具备 Token以供 gitrunner 的 k8s 执行器使用。
使用 secrete 将这个 Token 以卷挂载的方式加入到 runner 创建的 pod 中。
温馨提示:请务必保证 config 文件中包含的证书与密钥没有过期
kubectl create secrete generic -n gitlab --from-file ~/.kube/config
接下来配置 runner 的 config.toml
文件
apiVersion: v1
kind: ConfigMap
metadata:
name: gitlab-runner-config
namespace: gitlab
data:
# 以下是 gitlab-runner 的配置文件模板,gitlab-runner 会实时读取 config.toml 配置文件并热加载,因此,在 gitlab-runner 部署后,可以直接通过修改 config.toml 文件来更新配置
config-template.toml: |-
[[runners]]
# cache 不是必要的。它的作用是缓存项目的依赖包,从而大大减少项目构建的时间
[runners.cache]
# Type 可以选择 s3 和 gc3 两种对象存储协议
Type = "s3"
# Shared 字段控制不同 runner 之间的缓存是否共享,默认是 false
Shared = false
[runners.cache.s3]
ServerAddress = <s3_host:s3_port>
# 相当于用户名
AccessKey = <key>
# 相当于密码
SecretKey = <secret>
# 桶名
BucketName = <bucket_name>
Insecure = true
# 重要,用于配置 kubernetes 执行器。
[runners.kubernetes]
# 容器镜像拉取规则
pull_policy = "if-not-present"
# CICD 产生的 Pod 所在的命名空间,这个 namespace 需要和后续创建的所有资源所在 namespace 保持一致,否则会导致角色和它需要创建的资源不在同一个 namespace 从而失败
namespace = "gitlab"
poll_time = 600
cpu_request = "1"
service_cpu_request = "200m"
dns_policy = "none"
# 用于配置该 Executor 生成的 Pod 中的 /etc/hosts 文件
[[runners.kubernetes.host_aliases]]
ip = "127.0.0.1"
hostnames = ["localhost"]
# 用于配置 Pod 的 DNS 配置
[runners.kubernetes.dns_config]
nameserver = [
<DNS_1>
<DNS_2>
...
]
searches = [
<searches_1>
<searches_2>
...
]
# 共用宿主机的 docker
[runners.kubernetes.volumes]
[[runners.kubernetes.volumes.host_path]]
name = "docker"
mount_path = "/var/run/docker.sock"
read_only = true
host_path = "/var/run/docker.sock"
# 将 kubeconfig 内容挂载在
[[runners.kubernetes.volumes.secret]]
name = "kube-config"
mount_path = "/home/"
read_only = true
# 以下这些配置是用于后续注册 runner 时使用
group_runner_concurrent: "10"
group_runner_executor: "kubernetes"
group_runner_name: "gitlab-runner"
group_runner_tag: "gitlab-runner"
# 这个地方需要修改为 gitlab 的地址
group_runner_url: "http://bdcgit.cuc.edu.cn:8089/"
# 修改为 gitrunner 注册的 token
group_runner_token: "UwYRJp8vw4S-MbbJxgoT"
获取上述配置中的 token 如下:
-
如果要将 runner 注册在全局下(所有项目都能使用):
a. 登录 root 管理员账户
b. Admin --> CI/CD --> Register an instance runner
如下图所示:
-
如果要将 runner 注册在一个组下:
a. 只要你是组管理员即可,进入组管理界面
b. CI/CD --> Register a group runner
如下图所示:
配置 gitlab-runner 注册脚本
将 runner 部署到 k8s 上之后还需要将 runner 注册到 gitlab 上才能使用,为此,我们需要写一个脚本,让 runner 部署完成后自行执行,从而完成注册。我们通过 configmap 来将这个脚本挂载到 runner 所在的 Pod 中,这样,只要在之后创建容器时使用启动脚本就能自动执行。
apiVersion: v1
kind: ConfigMap
metadata:
name: gitlab-runner-register
namespace: gitlab
data:
run.sh: |
# !/bin/bash
# 这里的 --non-interactive 是指使用非交互模式注册,如果不用该限定符,就会使用交互式注册,那需要我们手动键入所有必要的配置,这显然不符合自动化的宗旨
# 下面所涉及到的所有环境变量都是在后续的 Deployment 中配置的
gitlab-runner register --non-interactive --name $GROUP_RUNNER_NAME --url $GROUP_RUNNER_URL --registration-token $GROUP_RUNNER_TOKEN --executor $GROUP_RUNNER_EXECUTOR --template-config /config/config-template.toml --tag-list $GROUP_RUNNER_TAG --locked
Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitlab-runner
namespace: gitlab
spec:
replicas: 1
selector:
matchLabels:
name: gitlab-runner
template:
metadata:
labels:
name: gitlab-runner
spec:
#nodeName: bdcenter-k8s-worker9
serviceAccountName: gitlab-runner-admin
imagePullSecrets:
- name: harbor-secret
containers:
- image: gitlab/gitlab-runner:latest
imagePullPolicy: IfNotPresent
name: gitlab-runner
env:
# 将我们之前在 configmap 中设置的项通过环境变量的方式注入到容器中
- name: GROUP_RUNNER_CONCURRENT
valueFrom:
configMapKeyRef:
name: gitlab-runner-config
key: group_runner_concurrent
- name: GROUP_RUNNER_NAME
valueFrom:
configMapKeyRef:
name: gitlab-runner-config
key: group_runner_name
- name: GROUP_RUNNER_TAG
valueFrom:
configMapKeyRef:
name: gitlab-runner-config
key: group_runner_tag
- name: GROUP_RUNNER_TOKEN
valueFrom:
configMapKeyRef:
name: gitlab-runner-config
key: group_runner_token
- name: GROUP_RUNNER_URL
valueFrom:
configMapKeyRef:
name: gitlab-runner-config
key: group_runner_url
- name: GROUP_RUNNER_EXECUTOR
valueFrom:
configMapKeyRef:
name: gitlab-runner-config
key: group_runner_executor
lifecycle:
# 在容器启动之后,执行注册脚本
postStart:
exec:
command: ["/bin/sh", "-c", "sh /foo/run.sh && sed -i 's/concurrent = 1/concurrent = '$GROUP_RUNNER_CONCURRENT'/g' /etc/gitlab-runner/config.toml"]
resources:
requests:
cpu: "100m"
limits:
cpu: "100m"
volumeMounts:
- name: gitlab-runner-config
mountPath: /config
- name: script-volume
mountPath: /foo
volumes:
- name: gitlab-runner-config
configMap:
name: gitlab-runner-config
items:
- key: config-template.toml
path: config-template.toml
- name: script-volume
configMap:
name: gitlab-runner-register
items:
- key: run.sh
path: run.sh
mode: 0755
---
# 创建角色,runner 生成的 pod 会使用下述角色信息通过 k8s 的 RBAC,从而能够创建 k8s 的相应资源
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab-runner-admin
namespace: gitlab
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: gitlab
name: gitlab-admin
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitlab-admin
namespace: gitlabE
subjects:
- kind: ServiceAccount
name: gitlab-runner-admin
namespace: gitlab
roleRef:
kind: Role
name: gitlab-admin
apiGroup: rbac.authorization.k8s.io
最后,将上述所有资源应用到 k8s 集群中,等待 runner 启动完成。
如果能够在 gitlab 管理员界面查看到 runner,说明 runner 安装注册成功。
使用 gitlab CICD
配置 gitlab 环境变量
在 Group——>Your Group——>Settings——>CI/CD——>Variables 中填入相关环境变量
这些环境变量可以在后续的 .gitlab-ci.yml
文件中使用。
# 镜像仓库密码
REGISTRY_PASSWORD: Harbor12345
# 镜像仓库 url,例如:172.17.33.146:1180
REGISTRY_URL: <your_harbor_url>
# 镜像仓库用户名
REGISTRY_USERNAME: admin
请注意,添加变量时默认会将其设置为 “Protected”,这会让该变量只能被保护分支使用(保护分支通常是 default 分支),如果我们想要所有分支都能使用这个变量,应当将取消其 Protected 属性,如下图:
配置 .gitlab-ci.yml
Pipeline 文件
下例为 npm 前端项目部署的 .gitlab-ci.yml 演示,对该文件有以下几点需要说明:
- 每个 stage 都会选择一个 runner 来执行,这意味着可以根据 stage 的不同,选择具有特定功能的 runner
- 在 kubernetes executor 模式中,每一个 stage,runner 都会使用 k8s api 在指定的命名空间中创建一个专用于 pipline 的临时 Pod,在这个 Pod 中执行完当前 stage 的所有 script,随后自动销毁
- CI 过程中,可以简单的认为,runner 将当前 git 代码仓库整个拷贝到了容器当中,而工作目录则是项目的根目录,因此,如果有什么文件需要进行拷贝、修改、删除,请尤其注意这一点。
# .gitlab-ci.yaml
# 选取全局基础镜像为node:latest
image: $REGISTRY_URL/library/node:latest
# 表示 pipeline 分几个阶段进行,下例中表示 pipeline 分 package - build - depoly 三个阶段依次执行
stages:
- package
- build
- deploy
# 表示package阶段的开始
package:
stage: package
# 表示此阶段的基础镜像为node
image: $REGISTRY_URL/library/node:latest
# (可选)使用cache进行缓存
# cache:
# 缓存git中没有被跟踪的文件
# untracked: true
# key表示指定分支的指定Job使用此cache
# key: "$CI_COMMIT_REF_SLUG"
# 表示要缓存的目录,这里的node_modules目录是安装的依赖包目录
# paths:
# - node_modules/
# 表示缓存的拉取策略
# policy: pull-push
# 表示要执行的脚本
script:
- npm install --registry=https://registry.npm.taobao.org
# 将项目打包
- npm run build
# tag 表示执行此阶段的 gitlab-runner
tags:
- [group_runner_name]
# 使用 artifacts 来传递 stage 间的文件,这里需要将 build 生成的 dist 文件夹传至下一阶段进行镜像的制作
artifacts:
paths:
- dist
build:
# 使用docker作为基础镜像,使用 docker 的目的是生成镜像,并推送到本地镜像仓库
image: $REGISTRY_URL/library/docker:19.03.0-dind
# 声明一些参数
services:
- name: docker:19.03.0-dind
command: ["--registry-mirror=https://dockerhub.azk8s.cn/"]
command: ["--insecure-registry=$REGISTRY_URL"]
stage: build
script:
# 查看docker信息
- docker info
# 登录Harbor私有仓库
- docker login -u $REGISTRY_USERNAME -p $REGISTRY_PASSWORD $REGISTRY_URL
# docker build命令制作镜像,注意-t后面为镜像名称,此镜像名称需和deployment.yaml文件中的镜像名称对应。
# 确保项目根目录中已经存在一个 Dockerfile
- docker build -t $REGISTRY_URL/$CI_PROJECT_NAMESPACE-$CI_PROJECT_NAME:v$CI_PIPELINE_ID .
# 将制作的镜像push到远程私有仓库
- docker push $REGISTRY_URL/$CI_PROJECT_NAMESPACE-$CI_PROJECT_NAME:v$CI_PIPELINE_ID
tags:
- [group_runner_name]
deploy:
stage: deploy
tags:
- [group_runner_name]
# 使用kubectl基础镜像,dockerhub 的 kubectl 基础镜像由于遵循最简化的原则,往往不符合我们的要求,因此,这个 kubectl 镜像是我们自己构建的,Dockerfile 在后文中会展示
image: $REGISTRY_URL/kubectl:latest
script:
- kubectl version
# 使用 kubectl apply命令部署应用,至于 kubectl 的构建文件,此处不再展示,只是
- kubectl apply -f deployments/
当做好这一切的工作之后,就可以在 gitlab 上运行流水线了,如下图所示:
kubectl 镜像 Dockerfile
# alpine 镜像是一个轻量级的调试容器,它具有比 busybox 更完善的工具
FROM alpine:latest
# 这里的 KUBECONFIG 环境变量为 kubectl 指示出证书、密钥文件的路径
ENV KUBECONFIG=/home/config
# 将 kubectl 可执行文件拷贝到镜像中。这里是在主节点中执行的,你也可以在网上下载 kubectl 再复制到镜像中
COPY kubectl /usr/local/bin/
# 将 kubectl 设置为可执行权限
RUN chmod x /usr/local/bin/kubectl
这篇好文章是转载于:学新通技术网
- 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
- 本站站名: 学新通技术网
- 本文地址: /boutique/detail/tanhiafkik
-
photoshop保存的图片太大微信发不了怎么办
PHP中文网 06-15 -
photoshop扩展功能面板显示灰色怎么办
PHP中文网 06-14 -
word里面弄一个表格后上面的标题会跑到下面怎么办
PHP中文网 06-20 -
《学习通》视频自动暂停处理方法
HelloWorld317 07-05 -
TikTok加速器哪个好免费的TK加速器推荐
TK小达人 10-01 -
Android 11 保存文件到外部存储,并分享文件
Luke 10-12 -
excel下划线不显示怎么办
PHP中文网 06-23 -
微信公众号没有声音提示怎么办
PHP中文网 03-31 -
excel图片置于文字下方的方法
PHP中文网 06-27 -
微信运动停用后别人还能看到步数吗
PHP中文网 07-22