总结 on F嘉阳

微服务平台开发总结（3）——第二代密码管理平台

Thu, 07 May 2020 21:38:00 +0800

背景

吸取前两代系统的失败经验，对第二代密码管理微服务进行重新规划，并且在探索过程中见识到了cloud-platform、SpringBlade、pigx等优秀的微服务项目，考虑基于开源项目二次开发

规划

为了尽快落地上线，第一期以实现最小功能为主，其他非必须功能尽可能往后放

第一期

SpringCloud微服务集成
Nacos、Sentinel、graylog、zipkin、 Turbine集成
前后端密码管理功能对接
操作日志记录
邮件通知
Excel导入导出
v1迁移到v2工具包

第二期

dble读写分离
支持忘记密码、密码锁定等
集成微信推送、微信注册功能
支持上传前端日志
页面排序、检索优化

第三期

增加用户反馈功能
接入Seata分布式事务
支持配置导入导出权限
支持录入标签
…

技术体系

前端

前后端分离-采用前后端分离模式，前端基于Vue
采用Vuex进行状态管理，采用ES6作为语法支持
前后端基于开源项目SpringBlade二次开发
前后端代码生成-定制针对两套前端与后端的代码生成模板，轻松生成整个模块的前后端代码，减少重复工作量
多租户顶部菜单配置-提供给每个租户独立的顶部菜单配置模块，可以自定义顶部菜单切换

后端

基于SpringCloud的分布式架构
采用Mybatis与MybatisPlus作为ORM持久层框架
多租户系统-完整的SaaS多租户架构
借鉴OAuth2，通过Jwt令牌实现了多终端认证系统，可控制子系统的token权限互相隔离
权限管理-精心设计的权限管理方案，角色权限精确到按钮
集成邮件服务，通过事件传播实现不依赖消息队列通知发送服务
集成微信推送服务，实现微信注册、敏感操作消息推送
动态聚合文档-实现基于Nacos的Swagger SpringCloud聚合文档
实现动态网关，不重启就能设置网关配置项
集成Turbine聚合熔断监控

数据架构

采用MySQL进行数据存储，底层配置为一主两从的高可用集群
采用ElasticSearch三节点集群进行日志数据存储

分布式支持

Nacos-集成阿里巴巴的Nacos完成统一的服务注册与配置
Sentinel-集成Sentinel从流量控制、熔断降级、系统负载等多个维度保护服务的稳定性
采用Docker打包，部署于Kubernetes集群上
Seata分布式事务-定制集成Seata，支持分布式事务，无代码侵入，不失灵活与简洁
使用graylog进行分布式日志采集，集中监控
通过zipkin进行分布式链路追踪，耗时统计和服务调用情况

DevOps

配置管理采用单仓库模式，集成docker打包插件，自动推送到harbor仓库
采用GitLab Runner CICD流水线自动部署到测试环境和生产环境
结合Maven私服和Harbor私服为内网自动化部署提供支持

官方架构图

截图

管理员

操作日志记录

错误日志系统内采集

Turbine集成熔断监控

通知发布

普通用户

主题切换

微信扫码注册

补全信息

主页资源权限控制

菜单资源权限控制

Excel导入导出

密码管理

运维

Nacos注册中心

Sentinel限流管控

SpringBoot Admin应用内指标监控

Harbor内网私服

Nexus内网私服，提供maven和npm包

graylog日志采集

三节点ES集群支持日志存储

耗时统计

新UI风格

动态服务依赖关系图

新UI依赖图

Prometheus指标采集

Grafana资源指标监控

Kuberneties服务部署监控

开发过程工具

Gitlab CICD流水线

看板

功能开发周期分析

gitlab集成k8s部署环境

Sonarqube代码质量检查

分支图

工程模块图

结果——成功

经过两个月的开发和调试，第一期工程符合预定计划，按期投产上线运行，并经过2周试运行和测试后，进入生产环境，迁移老版本数据，正式替换了运行一年半的第一代密码管理系统

时间线

2020年3月开始基于SpringBlade 2.6.2编码
2020年4月20日第一个测试版本进入k8s测试环境
2020年4月28日第一个稳定版进行试运行阶段
2020年5月4日试运行阶段结束，第一个稳定版1.1.2发布，正式进行数据迁移并投入使用

DevOps实践心得一

Fri, 16 Aug 2019 19:32:00 +0800

初遇DevOps

最早接触到DevOps是在2018年8月26日，那时首先接触到的就是大名鼎鼎的Jenkins，当时看了多篇关于持续集成和持续部署的文章，蠢蠢欲动，便开始了第一套DevOps环境的搭建

Jenkins

第一套DevOps是用Jenkins+Ansible+GitLab搭建的，那时只是了解Docker的好处，并没有使用Docker搭建整套环境，还是基于传统虚拟服务器搭建的整套流程。

Jenkins不仅可以编写groove脚本、pipeline 流水线等，还能与maven集成自动构建，深深感受到了Jenkins的强大，同时大量的用户为其贡献了许多插件，有很多实践问题都可以在网上搜索到解决方案

搭建过程：

最后顺利实现了静态网站持续集成、持续部署，详见：相关文章

Docker+GitLab

随着容器化技术在国内越来越流行，容器普及度越来越高，其带来的环境隔离极大推动了DevOps的落地，使得无需使用python环境隔离，可以直接利用容器技术实现跨平台和环境隔离，并且利于迁移和部署

于是在2019年4月开始研究GitLab官方文档，发现其早已原生支持流水线，并依托其GitLab-runner可以直接实现整套DevOps环境

因此，经过不断摸索，完整的搭建的基于Docker和GitLab的DevOps环境，搭建过程见：

由于国内当时对GitLab流水线使用的并不多，因此遇到的很多坑都需要翻查官方文档和国外的实践记录，比如：

DevOps 带来的好处

2019年7月将手上的一个小型项目尝试使用完整的DevOps流程开发，开发小组选择敏捷开发方法，所有的开发工具都尽量的适应快速的需求变化，同时投入非常少量的开发人员，分工明确，从一开始一周发布一次到最后一天可以发布多次

开发人员已经完全从运维中脱离，全团队没有专门的运维人员，极大的提高了开发效率，精简了人员构成，一旦构建失败，开发人员可以根据邮件通知的内容排查上线失败问题，调整代码和配置后重新提交

面板提供了流水线统计图，如果出现频繁的失败还是需要人工介入，查看问题原因

当前的问题

尽管使用了基于Docker+GitLab的流水线实现了完整的DevOps流程，但对于监控和日志部分仍然处在很多问题

尽管上线的是单体应用，服务器和应用的健康状态都无法得知，也没有相应的告警
应用的日志没有被外部服务收集，无法进行快速分析
没有实现完整的测试流程，生成测试覆盖率报告等
没有实现0停机上线，在容器切换时仍需停机1-2分钟
没有实现灰度上线、蓝绿部署等，上线失败需要手动回滚

未来探索方向

全面容器化服务治理方向
- 国内对容器化有非常多的实践
- kubernetes作为容器调度成为大多数服务治理的选择
- 容器隔离、迁移和伸缩带来的巨大优势
容器与传统应用部署结合方式
- 以半全自动方式落地DevOps，采用Mesos+marathon方式同时兼容传统服务部署和容器化部署
- 兼容分布式服务治理
- 国外有大量的实践案例
- 日志收集体系完备

DevOps GitLab CICD 实践3——CI文件编写

Wed, 03 Apr 2019 16:32:00 +0800

前置步骤：

Docker 版 GitLab CICD 实践1——GitLab 部署 [[Docker 版 GitLab CICD 实践]]
Docker 版 GitLab CICD 实践2——Runner 部署 [[Docker 版 GitLab CICD 实践——Runner 部署]]

官方文档

编写结构类似Jenkins pineline流水线

GitLab CI/CD Pipeline Configuration Reference

GitLab CI/CD Pipeline Configuration Reference
GitLab CI/CD pipelines are configured using a YAML file called .gitlab-ci.yml within each project.

The .gitlab-ci.yml file defines the structure and order of the pipelines and determines:

What to execute using GitLab Runner.

What decisions to make when specific conditions are encountered. For example, when a process succeeds or fails.

This topic covers CI/CD pipeline configuration. For other CI/CD configuration information, see:

GitLab CI/CD Variables, for configuring the environment the pipelines run in.

GitLab Runner advanced configuration, for configuring GitLab Runner.

We have complete examples of configuring pipelines:

For a quick introduction to GitLab CI, follow our quick start guide.

For a collection of examples, see GitLab CI/CD Examples.

To see a large .gitlab-ci.yml file used in an enterprise, see the .gitlab-ci.yml file for gitlab-ce.

目标

maven项目自动打包
~~自动测试~~
自动镜像构建并上传

官方参数表列出了作业的可用参数：

关键词	描述
`script`	由Runner执行的Shell脚本。
`image`	使用泊坞窗图像。也可用：`image:name`和`image:entrypoint`。
`services`	使用docker services图像。也可用：`services:name`，`services:alias`，`services:entrypoint`，和`services:command`。
`before_script`	覆盖在作业之前执行的一组命令。
`after_script`	覆盖作业后执行的一组命令。
`stages`	定义管道中的阶段。
`stage`	定义作业阶段（默认值:) `test`。
`only`	创建作业时限制。也可用：`only:refs`，`only:kubernetes`，`only:variables`，和`only:changes`。
`except`	在未创建作业时限制。也可用：`except:refs`，`except:kubernetes`，`except:variables`，和`except:changes`。
`tags`	用于选择Runner的标签列表。
`allow_failure`	让工作失败。失败的作业无助于提交状态。
`when`	什么时候开始工作。也可用：`when:manual`和`when:delayed`。
`environment`	作业部署到的环境的名称。也可用：`environment:name`，`environment:url`，`environment:on_stop`，和`environment:action`。
`cache`	后续运行之间应缓存的文件列表。也可用：`cache:paths`，`cache:key`，`cache:untracked`，和`cache:policy`。
`artifacts`	成功附加到作业的文件和目录列表。也可用：`artifacts:paths`，`artifacts:name`，`artifacts:untracked`，`artifacts:when`，`artifacts:expire_in`，`artifacts:reports`，和`artifacts:reports:junit`。在GitLab 企业版，这些都是可供选择：`artifacts:reports:codequality`，`artifacts:reports:sast`，`artifacts:reports:dependency_scanning`，`artifacts:reports:container_scanning`，`artifacts:reports:dast`，`artifacts:reports:license_management`，和`artifacts:reports:performance`。
`dependencies`	作业所依赖的其他作业，以便您可以在它们之间传递工件。
`coverage`	给定作业的代码覆盖率设置。
`retry`	在发生故障的情况下，可以自动重试作业的次数和次数。
`parallel`	应该并行运行多少个作业实例。
`trigger`	定义下游管道触发器。
`include`	允许此作业包含外部YAML文件。也可用：`include:local`，`include:file`，`include:template`，和`include:remote`。
`extends`	此作业将继承的配置条目。
`pages`	上传作业结果以用于GitLab Pages。
`variables`	在作业级别定义作业变量。

注：参数types和type被弃用。

参考

官方构建案例

Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD

参考其脚本

Configure GitLab CI/CD to deploy your application
Now we need to add the GitLab CI/CD configuration file (.gitlab-ci.yml) to our project’s root. This is how GitLab figures out what commands need to be run whenever code is pushed to our repository. We will add the following .gitlab-ci.yml file to the root directory of the repository, GitLab will detect it automatically and run the steps defined once we push our code:
image: java:8

stages:
 - build
 - deploy

build:
 stage: build
 script: ./mvnw package
 artifacts:
 paths:
 - target/demo-0.0.1-SNAPSHOT.jar

production:
 stage: deploy
 script:
 - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
 - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
 - ./cf push
 only:
 - master

配置

全局变量

进入工程CI设置配置全局变量脚本，包含镜像仓库登陆名称、密码、打包名称等

配置全局变量目的在于配置脚本中不应该包含密码等敏感信息

若希望使用GitLab内置环境变量，可参考官方表格

GitLab CI/CD environment variables

CI脚本

结合可用参数和样例配置，根据已经存在的SpringBoot项目编写响应的CI脚本.gitlab-ci.yml

image: docker:stable
services:
 - docker:dind

variables:
 DOCKER_DRIVER: overlay
 SPRING_PROFILES_ACTIVE: gitlab-ci

stages:
 - build
 - package

maven-build:
 image: maven:3-jdk-8
 stage: build
 script: "mvn package -B"
 artifacts:
 paths:
 - target/*.jar

docker-build:
 stage: package
 script:
 - docker build -t $CONTAINER_IMAGE:latest .
 - docker login -u $DOCKER_HUB_USER -p $DOCKER_HUB_PASS
 - docker push $CONTAINER_IMAGE:latest

该脚本对于满足脚本目标的工程都可复用，若需要测试，则增加相关的测试步骤即可

此处由于工程包含外部依赖关系，不在构建时测试

自动构建

默认的触发构建事件为commit等

触发后会自动执行任务

Maven自动触发构建，自动镜像打包

自动上传（推送）镜像

执行结果

若执行失败则会发送邮件给开发人员

CICD全套流程目标实现！

总结

不管使用GitLab CICD或者是使用Jenkins+Ansible的方式，目标都在于践行DevOps，打通开发与运维流程，一旦配置好CICD流程，往后开发人员便不再操心打包、构建等操作，可以专注开发

DevOps GitLab CICD 实践2——Runner 部署

Wed, 03 Apr 2019 16:31:00 +0800

前置步骤：DevOps GitLab CICD 实践1——GitLab 部署

官方文档

文档地址

虽然有官方指引，但个人感觉指引的不够清晰，导致初次配置可能频繁失败

Run GitLab Runner in a container
This is how you can run GitLab Runner inside a Docker container.

General GitLab Runner Docker image usage
GitLab Runner Docker images (based on Ubuntu or Alpine Linux) are designed as wrappers around the standard gitlab-runner command, like if GitLab Runner was installed directly on the host.

The general rule is that every GitLab Runner command that normally would be executed as:
gitlab-runner [Runner command and options...]
can be executed with:
docker run [chosen docker options...] gitlab/gitlab-runner [Runner command and options...]
For example, getting the top-level help information for GitLab Runner command could be executed as:
docker run --rm -t -i gitlab/gitlab-runner --help

NAME:
 gitlab-runner - a GitLab Runner

USAGE:
 gitlab-runner [global options] command [command options] [arguments...]

VERSION:
 10.7.0 (7c273476)

(...)
In short, the gitlab-runner part of the command is replaced with docker run [docker options] gitlab/gitlab-runner, while the rest of Runner’s command stays as it is described in the register documentation. The only difference is that the gitlab-runner command is executed inside of a Docker container.

Docker image installation and configuration
Install Docker first:
 curl -sSL https://get.docker.com/ | sh
You need to mount a config volume into the gitlab-runner container to be used for configs and other resources:
 docker run -d --name gitlab-runner --restart always \
 -v /srv/gitlab-runner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:latest
Tip: On macOS, use /Users/Shared instead of /srv.

Or, you can use a config container to mount your custom data volume:
 docker run -d --name gitlab-runner-config \
 -v /etc/gitlab-runner \
 busybox:latest \
 /bin/true
And then, run the Runner:
 docker run -d --name gitlab-runner --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 --volumes-from gitlab-runner-config \
 gitlab/gitlab-runner:latest
Register the runner you just launched by following the instructions in the Docker section of Registering Runners. The runner won’t pick up any jobs until it’s registered.

安装步骤

获取Gitlab Runner秘钥

可以通过Gitlab管理员账号获取，也可以让每一个用户自行配置

普通用户查看秘钥

进入任意一个仓库的设置中，查看CICD配置

准备注册专用Runner令牌

管理员查看令牌

进入总设置页面，配置全局Runner令牌

Runner注册

由于Runner一般运行复杂构建、打包任务，推荐配置在性能、带宽更大的机房

准备Docker环境

$ curl -sSL https://get.docker.com/ | sh
$ systemctl start docker

注册

可以根据需要选择注册Runner类型

同时，为了方便配置，使用单行注册并且关闭交互

单行注册官方文档

命令说明：

-v挂载的目的是为了将注册后的配置文件持久化，用于运行容器
--rm指定容器运行结束后自动删除停止的容器
-it指定使用命令行交互方式运行，便于查看注册结果

$ docker run --rm -it \
 -v /www/wwwroot/gitlab/srv/gitlab-runner/config:/etc/gitlab-runner \
 gitlab/gitlab-runner:alpine-v11.8.0 register \
 --non-interactive \
 --executor "docker" \
 --docker-image docker:stable \
 --url "Gitlab URL" \
 --registration-token "令牌" \
 --description "描述" \
 --tag-list "标签1,标签2" \
 --run-untagged \
 --docker-privileged \
 --locked="false"

注册成功提示

此时管理面板显示新的Runner已经注册

Runner 启动

挂载本地配置信息并启动Runner

$ docker run -d --name gitlab-runner --restart always \
 	-v /www/wwwroot/gitlab/srv/gitlab-runner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:alpine-v11.8.0

此时可见Runner已经保持和Gitlab的联系

DevOps GitLab CICD 实践1——GitLab 部署

Wed, 03 Apr 2019 16:30:00 +0800

配置目标

邮件提示
GitHub第三方授权登陆
GitLab Runner
Docker私服注册

官方介绍

目前微服务盛行环境下，服务部署优先考虑Docker方式，便于迁移和弹性伸缩

官方镜像介绍 GitLab Docker images

GitLab Docker images
Both GitLab CE and EE are in Docker Hub:

GitLab CE Docker image

GitLab EE Docker image

The GitLab Docker images are monolithic images of GitLab running all the necessary services on a single container.

In the following examples we are using the image of GitLab CE. To use GitLab EE instead of GitLab CE, replace the image name to gitlab/gitlab-ee:latest.

If you want to use the latest RC image, use gitlab/gitlab-ce:rc or gitlab/gitlab-ee:rc for GitLab CE and GitLab EE respectively.

The GitLab Docker images can be run in multiple ways:

Run the image in Docker Engine

Install GitLab into a cluster

Install GitLab using docker-compose

docker-compose 脚本

此处选择社区版(CE)安装，同时为了便于参数配置，使用docker-compose方式编写脚本文件

Install GitLab using docker-compose
With Docker compose you can easily configure, install, and upgrade your Docker-based GitLab installation.
Install Docker Compose
Create a docker-compose.yml file (or download an example):
 web:
 image: 'gitlab/gitlab-ce:latest'
 restart: always
 hostname: 'gitlab.example.com'
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 external_url 'https://gitlab.example.com'
 # Add any other gitlab.rb configuration here, each on its own line
 ports:
 - '80:80'
 - '443:443'
 - '22:22'
 volumes:
 - '/srv/gitlab/config:/etc/gitlab'
 - '/srv/gitlab/logs:/var/log/gitlab'
 - '/srv/gitlab/data:/var/opt/gitlab'
Make sure you are in the same directory as docker-compose.yml and run docker-compose up -d to start GitLab
Read “Pre-configure Docker container” to see how the GITLAB_OMNIBUS_CONFIG variable works.

Below is another docker-compose.yml example with GitLab running on a custom HTTP and SSH port. Notice how the GITLAB_OMNIBUS_CONFIG variables match the ports section:
web:
 image: 'gitlab/gitlab-ce:latest'
 restart: always
 hostname: 'gitlab.example.com'
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 external_url 'http://gitlab.example.com:9090'
 gitlab_rails['gitlab_shell_ssh_port'] = 2224
 ports:
 - '9090:9090'
 - '2224:22'
 volumes:
 - '/srv/gitlab/config:/etc/gitlab'
 - '/srv/gitlab/logs:/var/log/gitlab'
 - '/srv/gitlab/data:/var/opt/gitlab'
This is the same as using --publish 9090:9090 --publish 2224:22.

官方提示说明Docker CE版基于Omnibus版本，故环境配置也可参考相关文档

Omnibus文档目录

Installation and Configuration using omnibus package
Note: This section describes the commonly used configuration settings. Check configuration section of the documentation for complete configuration settings.

Installing GitLab

Manually downloading and installing a GitLab package

Setting up a domain name/URL for the GitLab Instance so that it can be accessed easily

Enabling HTTPS

Enabling notification EMails

Enabling replying via email

Installing and configuring postfix

Enabling container registry on GitLab

You will require SSL certificates for the domain used for container registry

Enabling GitLab Pages

If you want HTTPS enabled, you will have to get wildcard certificates

Enabling Elasticsearch

GitLab Mattermost Set up the Mattermost messaging app that ships with Omnibus GitLab package.

GitLab Prometheus Set up the Prometheus monitoring included in the Omnibus GitLab package.

GitLab High Availability Roles

结合配置目标编写yaml文件

注意：

此处邮件使用163邮箱（官方没有提供163邮箱支持案例）
Docker私服公钥执行从私服上获取
由于特殊原因，目标配置未启动SSL安全连接，但GitLab可以通过简单配置支持SSL并自动更新证书

配置文档

Let’s Encrypt Integration
Primary GitLab Instance

Note: Introduced in GitLab version 10.5 and disabled by default. Enabled by default in GitLab version 10.7 and later if external_url is set with the httpsprotocol and no certificates are configured.

Note: In order for Let’s Encrypt verification to work correctly, ports 80 and 443 will need to be accessible to the Let’s Encrypt servers that run the validation. Also note that the validation currently does not work with non-standard ports.
Caution Administrators installing or upgrading to GitLab version 10.7 or later and do not plan on using Let’s Encrypt should set the following in /etc/gitlab/gitlab.rb to disable:
letsencrypt['enable'] = false
Add the following entries to /etc/gitlab/gitlab.rb to enable Let’s Encrypt support for the primary domain:
letsencrypt['enable'] = true # GitLab 10.5 and 10.6 require this option
external_url "https://gitlab.example.com"	 # Must use https protocol
letsencrypt['contact_emails'] = ['foo@email.com'] # Optional

生成163邮箱授权密码

生成GitHub授权秘钥

最终配置

version: '3.1'

services:

 gitlab:
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 external_url '外部访问地址'
 gitlab_rails['gitlab_shell_ssh_port'] = 外部SSH端口
 registry_external_url 'Docker私服地址'
 registry_nginx['ssl_certificate'] = "Docker 私服CA证书 crt文件"
 registry_nginx['ssl_certificate_key'] = "Docker 私服公钥 pem文件"
 gitlab_rails['smtp_enable'] = true
 gitlab_rails['smtp_address'] = "smtp.163.com"
 gitlab_rails['smtp_port'] = 465
 gitlab_rails['smtp_user_name'] = "邮件发送者名称"
 gitlab_rails['gitlab_email_from'] = '邮件发送地址'
 gitlab_rails['smtp_password'] = "授权密码"
 gitlab_rails['smtp_domain'] = "163.com"
 gitlab_rails['smtp_authentication'] = "login"
 gitlab_rails['smtp_enable_starttls_auto'] = true
 gitlab_rails['smtp_tls'] = true
 gitlab_rails['omniauth_enabled'] = true
 gitlab_rails['omniauth_allow_single_sign_on'] = true
 gitlab_rails['omniauth_block_auto_created_users'] = true
 gitlab_rails['omniauth_providers'] = [
 {
 "name" => "github",
 "app_id" => "Client ID",
 "app_secret" => "Client Secret",
 "url" => "https://github.com/",
 "args" => { "scope" => "user:email" }
 }
 ]
 image: gitlab/gitlab-ce:latest
 hostname: gitlab.fjy8018.top
 restart: always
 networks:
 - devops-service-bridge
 ports:
 - '8443:443'
 - '8099:8099'
 - '8022:22'
 volumes:
 - ./srv/gitlab/config:/etc/gitlab
 - ./srv/gitlab/logs:/var/log/gitlab
 - ./srv/gitlab/data:/var/opt/gitlab
 - /etc/docker/certs.d:/etc/docker/certs.d


networks:
 devops-service-bridge:
 driver: bridge