- 1Spring Boot+WebSocket向前端推送消息
- 2web前端：从index.html开始_前端 index.html
- 3Serverless和PaaS之间就“差”了一个负载均衡
- 4如何使用 AutoDL 云实例基于LangChain-Chatchat 和 ChatGLM 搭建本地知识库模型详细教程（更新中）_langchain chatchat github
- 5CSS特性_css继承父级样式
- 6准备跳槽了（仍然底层为主，ue独立游戏为辅）
- 7AI网络爬虫：批量爬取豆瓣图书搜索结果
- 8QNX为什么是安全的操作系统？
- 9[数据结构] 基于选择的排序 选择排序&&堆排序
- 10VUE2用elementUI实现父组件中校验子组件中的表单_vue 详细子表 的校验
gitlab 迁移_VPGAME的Kubernetes迁移实践
赞
踩
快速、可预测地部署服务
拥有即时扩展服务的能力
滚动升级，完成新功能发布
优化硬件资源，降低成本
GitLab CI 基本概念
在介绍 GitLab CI 之前，首先简单介绍一下 GitLab CI 里的一些基本概念，具体如下：
Pipeline：Gitlab CI 里的流水线，每一次代码的提交触发 GitLab CI 都会产生一个 Pipeline。
Stage：每个 Pipeline 由多个 Stage 组成，并且每个 Stage 是有先后顺序的。
Job：GitLab CI 里的最小任务单元，负责完成具有一件事情，例如编译、测试、构建镜像等。每个 Job 都需要指定 Stage ，所以 Job 的执行顺序可以通过制定不同的 Stage 来实现。
GitLab Runner：是具体执行 Job 的环境，每个 Runner 在同一时间只能执行一个 Job。
Executor：每个 Runner 在向 GitLab 注册的时候需要指定 Executor，来决定通过何种类型的执行器来完成 Job。
shared：所有项目使用
group：group下项目使用
specific：指定项目使用
GitLab Runner 的 Executor
Runner 在实际执行 Job 时，是通过调用 Executor 来完成的。Runner 在注册时提供了 SSH、Shell、Docker、docker-ssh、VirtualBox、Kubernetes 等不同类型的 Executor 来满足不同的场景和需求。其中我们常用的有 Shell 和 Docker 等 Executor，Shell 类型主要是利用 Runner 所在主机的环境进行 Job的执行。而 Docker 类型的 Executor 在每个 Job 开始时，拉取镜像生产一个容器，在容器里完成 Job，在 Job 完成后，对应的容器就会被销毁。由于 Docker 隔离性强、轻量且回收，我们在使用时选用 Docker 类型的 Executor 去执行 Job，我们只要提前做好 Job 所需环境的 Docker 镜像，在每个 Job 定义好 image 即可使用对应的环境，操作便捷。
GitLab Runner 安装与配置
Docker 安装由于我们需要使用 Docker 类型的 Executor，所以需要在运行 Runnner 的服务器上先安装 Docker，具体步骤如下(CentOS 环境)：安装需要的软件包，yum-util 提供 yum-config-manager 功能，另外两个是 DeviceMapper 驱动依赖：
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install docker-ce -y
systemctl start docker
systemctl enable docker
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
sudo yum install gitlab-runner -y
gitlab-runner start
其他两种类型在对应的页面下( group 或 project 主页)的 setting—>CI/CD—>Runner 可以获取到 token。Runner 的注册方式分为交互式和非交互式两种。其中交互式注册方式，在输入 gitlab-runner register 命令后，按照提示输入注册所需要的信息，包括 gitlab url、token 和 Runner 名字等。这边个人比较推荐非交互式命令，可以事先准备好命令，完成一键注册，并且非交互式注册方式提供了更多的注册选项，可以满足更多样化的需求。按如下示例即可完成一个 Runner 的注册：
gitlab-runner register --non-interactive \
--url "http://git.xxxx.cn" \
--registration-token "xxxxxxxxxxx" \
--executor "docker" \
--docker-image alpine:latest \
--description "base-runner-docker" \
--tag-list "base-runner" \
--run-untagged="true" \
--docker-privileged="true" \
--docker-pull-policy "if-not-present" \
--docker-volumes /etc/docker/daemon.json:/etc/docker/daemon.json \
--docker-volumes /etc/gitlab-runner/key/docker-config.json:/root/.docker/config.json \
--docker-volumes /etc/gitlab-runner/find_diff_files:/usr/bin/find_diff_files \
--docker-volumes /etc/gitlab-runner/key/id_rsa:/root/.ssh/id_rsa \
--docker-volumes /etc/gitlab-runner/key/test-kube-config:/root/.kube/config
{ "insecure-registries" : ["http://docker.vpgame.cn"] }
gitlab-runner restart
此外，如果一台服务需要注册多个 Runner ，可以修改 /etc/gitlab-runner/config.toml 中的 concurrent 值增加 Runner 的并发数，修改完之后同样需要重启 Runner。Docker 基础镜像制作
按照一定规则自动构建镜像，可以快速便捷地新建和更新镜像
根据规则可以找到镜像对应的 Dockerfile，明确镜像的具体组成
团队成员可以通过提交 Merge Request 自由地构建自己需要的镜像
运行时基础镜像：提供各个语言运行时必须的工具和相应的 package。
CI 镜像：基于运行时基础镜像，添加单元测试、lint、静态分析等功能，用在 CI/CD 流程中的 test 环节。
打包上线镜像：用在 CI/CD 流程中的 build 和 deploy 环节。
以 PHP 镜像为例：
php/
├── 1.0
│ ├── Dockerfile
│ ├── ci-1.0
│ │ └── Dockerfile
│ ├── php.ini
│ ├── read-zk-config
│ ├── start_service.sh
│ └── www.conf
└── nginx
├── Dockerfile
├── api.vpgame.com.conf
└── nginx.conf
FROM php:7.1.16-fpm-alpine3.4
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories\
&& apk upgrade --update && apk add --no-cache --virtual build-dependencies $PHPIZE_DEPS \
tzdata postgresql-dev libxml2-dev libmcrypt libmcrypt-dev libmemcached-dev cyrus-sasl-dev autoconf \
&& apk add --no-cache freetype libpng libjpeg-turbo freetype-dev libpng-dev libjpeg-turbo-dev libmemcached-dev \
&& cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
&& echo "Asia/Shanghai" > /etc/timezone \
&& docker-php-ext-configure gd \
--with-gd \
--with-freetype-dir=/usr/include/ \
--with-png-dir=/usr/include/ \
--with-jpeg-dir=/usr/include/ \
&& docker-php-ext-install gd pdo pdo_mysql bcmath opcache \
&& pecl install memcached apcu redis \
&& docker-php-ext-enable memcached apcu redis \
&& apk del build-dependencies \
&& apk del tzdata \
&& rm -rf /var/cache/apk/* \
&& rm -rf /tmp/* \
&& rm -rf /working/* \
&& rm -rf /usr/local/etc/php-fpm.d/*
COPY start_service.sh /usr/local/bin/start_service.sh
COPY read-zk-config /usr/local/bin/read-zk-config
COPY php.ini /usr/local/etc/php/php.ini
COPY www.conf /usr/local/etc/php-fpm.d/www.conf
WORKDIR /work
CMD ["start_service.sh"]
FROM docker.vpgame.cn/infra/php-1.0
ENV PATH="/root/.composer/vendor/bin:${PATH}"
ENV COMPOSER_ALLOW_SUPERUSER=1
RUN mkdir -p /etc/ssh && echo "StrictHostKeyChecking no" >> /etc/ssh/ssh_config
RUN apk --update add --no-cache make libc-dev autoconf gcc openssh-client git bash &&\
echo "apc.enable_cli=1" >> /usr/local/etc/php/conf.d/docker-php-ext-apcu.ini
RUN pecl install xdebug && docker-php-ext-enable xdebug &&\
echo -e "\nzend_extension=xdebug.so" >> /usr/local/etc/php/php.ini
RUN wget https://vp-infra.oss-cn-beijing.aliyuncs.com/gitlab-ci/software/download/1.6.5/composer.phar -O /bin/composer && \
chmod +x /bin/composer && \
composer config -g -q repo.packagist composer https://packagist.laravel-china.org
RUN composer global require -q phpunit/phpunit:~5.0 squizlabs/php_codesniffer:~3.0
WORKDIR /
CMD ["/bin/bash"]
镜像自动构建基本原理由于各个镜像通过 Dockerfile 进行管理， Master 分支有新的合并，可以通过 git diff 命令找出合并前后新增或更新的 Dockerfile，然后根据这些 Dockerfile 依据一定的命名规则构建镜像，并上传到 Docker Harbor 上。
for FILE in `bash ./find_diff_files|grep Dockerfile|sort`;
do
DIR=`dirname "$FILE"`;
IMAGE_NAME=`echo $DIR | sed -e 's/\//-/g'`;
echo $CI_REGISTRY/$HARBOR_DIR/$IMAGE_NAME;
docker build -t $CI_REGISTRY/$HARBOR_DIR/$IMAGE_NAME -f $FILE $DIR;
docker push $CI_REGISTRY/$HARBOR_DIR/$IMAGE_NAME;
done
Alpine Linux Package Management(APK)镜像地址：http://mirrors.aliyun.com
一些海外软件下载会比较慢，可以先下载下来上传至阿里云 OSS 后下载。Dockerfile 使用阿里云 OSS 作为下载源，减少构建镜像时间。
stages:
- build
- test
- deploy
首先，所有 build 里的 Job 会并行执行；
当 build 里所有 Job 执行成功， test 里所有 Job 会并行执行；
如果 test 里所有 Job 执行成功， deploy 里所有 Job 会并行执行；
如果 deploy 里所有 Job 执行成功， 当前 Pipeline 会被标记为 passed；
当某个 stage 的 Job 执行失败， Pipeline 会标记为为 failed，其后续stage 的 Job 都不会被执行。
unittest:
stage: test
image: docker.vpgame.cn/infra/php-1.0-ci-1.1
services:
- name: docker.vpgame.cn/infra/mysql-5.6-multi
alias: mysql
- name: redis:4.0
alias: redis_default
script:
- mv .env.tp .env
- composer install --no-dev
- phpunit -v --coverage-text --colors=never --coverage-html=coverage --stderr
artifacts:
when: on_success
paths:
- vendor/
- coverage/
expire_in: 1 hour
coverage: '/^\s*Lines:\s*\d+.\d+\%/'
only:
- branches
- tags
tags:
- base-runner
dependencies:
- unittest
job:
only:
- /^issue-.*$/
except:
- branches
在测试环境验证通过之后，我们再通过打 tag 进行正式环境的上线。此处的 Pipelines 包含了 unittest、build-pro 和 deploy-pro 三个 Job。
在 .gitlab-ci.yml 文件中，test 阶段主要完成 lint 和 unitest 两个 Job，不同的语言在进行 Job 定义时会各有不同。我们重点来看一下 build 和 deploy 两个 stage 的 Job 描述。build stage：
# Build stage
.build-op:
stage: build
dependencies:
- unittest
image: docker.vpgame.cn/infra/docker-kubectl-1.0
services:
- name: docker:dind
entrypoint: ["dockerd-entrypoint.sh"]
script:
- echo "Image name:" ${DOCKER_IMAGE_NAME}
- docker build -t ${DOCKER_IMAGE_NAME} .
- docker push ${DOCKER_IMAGE_NAME}
tags:
- base-runner
build-test:
extends: .build-op
variables:
DOCKER_IMAGE_NAME: ${DOCKER_REGISTRY_PREFIX}/${CI_PROJECT_PATH}:${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}
only:
- /^testing/
- master
build-prod:
extends: .build-op
variables:
DOCKER_IMAGE_NAME: ${DOCKER_REGISTRY_PREFIX}/${CI_PROJECT_PATH}:${CI_COMMIT_TAG}
only:
- tags
# Deploy stage
.deploy-op:
stage: deploy
image: docker.vpgame.cn/infra/docker-kubectl-1.0
script:
- echo "Image name:" ${DOCKER_IMAGE_NAME}
- echo ${APP_NAME}
- sed -i "s~__NAMESPACE__~${NAMESPACE}~g" deployment.yml service.yml
- sed -i "s~__APP_NAME__~${APP_NAME}~g" deployment.yml service.yml
- sed -i "s~__PROJECT_NAME__~${CI_PROJECT_NAME}~g" deployment.yml
- sed -i "s~__PROJECT_NAMESPACE__~${CI_PROJECT_NAMESPACE}~g" deployment.yml
- sed -i "s~__GROUP_NAME__~${GROUP_NAME}~g" deployment.yml
- sed -i "s~__VERSION__~${VERSION}~g" deployment.yml
- sed -i "s~__REPLICAS__~${REPLICAS}~g" deployment.yml
- kubectl apply -f deployment.yml
- kubectl apply -f service.yml
- kubectl rollout status -f deployment.yml
- kubectl get all,ing -l app=${APP_NAME} -n $NAMESPACE
# Deploy test environment
deploy-test:
variables:
REPLICAS: 2
VERSION: ${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}
extends: .deploy-op
environment:
name: test
url: http://example.com
only:
- /^testing/
- master
tags:
- base-runner
# Deploy prod environment
deploy-prod:
variables:
REPLICAS: 3
VERSION: ${CI_COMMIT_TAG}
extends: .deploy-op
environment:
name: prod
url: http://example.com
only:
- tags
tags:
- pro-deploy
可以看到，通过对 Job 的关键字进行配置，我们可以灵活地编排出我们所需要的 CI/CD 流程，非常好地满足多样化的场景。Deployment 与 Service 配置
定义 Deployment 来创建 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment
上图中 deployment.yml 分为8个部分，分别如下：
apiVersion 为当前配置格式的版本
kind 指定了资源类型，这边当然是 Deployment
metadata 是该资源的元数据，其中 name 是必需的数据项，还可以指定 label 给资源加上标签
spec 部分是该 Deployment 的规格说明
spec.replicas 指定了 Pod 的副本数量
spec.template 定义 Pod 的基本信息，通过 spec.template.metadata 和 spec.template.spec 指定
spec.template.metadata 定义 Pod 的元数据。至少需要定义一个 label 用于 Service 识别转发的 Pod， label 是通过 key-value 形式指定的
spec.template.spec 描述 Pod 的规格，此部分定义 Pod 中每一个容器的属性，name 和 image 是必需项
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: __APP_NAME__
group: __GROUP_NAME__
name: __APP_NAME__
namespace: __NAMESPACE__
Kubernetes 中运行的 Service 以及 Deployment 名称由 GitLab 中的 groupname 和 projectname 组成，即 {{groupname}}-{{projectname}}，例：microservice-common。此名称记为 app_name，作为每个服务在 Kubernetes 中的唯一标识。这些变量可以通过 GitLab-CI 的内置变量中进行获取，无需对每个 project 进行特殊的配置。
Lables 中用于识别服务的标签与 Deployment 名称保持一致，统一设置为 app:{{app_name}}。
...
spec:
...
template:
...
spec:
...
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: group
operator: In
values:
- __GROUP_NAME__
...
...
spec:
...
template:
...
spec:
...
containers:
- name: fpm
livenessProbe:
httpGet:
path: /__PROJECT_NAME__
port: 80
initialDelaySeconds: 3
periodSeconds: 5
readinessProbe:
httpGet:
path: /__PROJECT_NAME__
port: 80
initialDelaySeconds: 3
periodSeconds: 5
...
...
我们还可以设置 maxSurge 和 maxUnavailable 的值分别控制升级过程中最多可以比原先设置多出的 Pod 比例以及升级过程中最多有多少比例 Pod 处于无法提供服务的状态。
...
spec:
...
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
...
...
spec:
...
template:
...
spec:
...
containers:
- name: fpm
env:
- name: aliyun_logs_vpgame
value: stdout
- name: aliyun_logs_vpgame_tags
value: topic=__APP_NAME__
...
...
...
spec:
...
template:
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "80"
prometheus.io/path: /{{ project_name }}/metrics
...
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/alicloud-loadbalancer-address-type: intranet
labels:
app: __APP_NAME__
name: __APP_NAME__
namespace: __NAMESPACE__
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: __APP_NAME__
type: LoadBalancer
如上图所示，EXTERNAL-IP 即为 SLB 的 IP。总结
