版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 导读 萌叔的API服务内部使用了localcache服务，这个localcache是有状态的。 我在Grafana中配置的初始图表如下 这里读者可以看出localcache的状态是数值型的，对此业务陌生的情况下，无法理解其含义，能否把数值转换为文本呢？ 2. 使用value mapping配置 Grafana提供value mapping，可以根据value值来修改显示内容 改进后，效果如下 状态以中文显示，并且增加了背景颜色 在上图中，inuse表示缓存实际使用量，萌叔希望根据inuse的数值范围，给出文字提示。那么，再来改一下。 改进后，效果如下 3. 总结 value mapping是一个非常有用的功能，感兴趣的朋友可以试试。 参考资料 1.Configure value mappings
注意: 本文基于 vearne/autotest v0.0.9 1. 引言 萌叔手上的API服务不少，核心的项目都有CI和单元测试。 但是毕竟在单元测试中，对外部数据库、微服务的调用都是mock的，缺乏对整个链路的自动化测试 这段时间开发了一个自动化测试框架 vearne/autotest 初步实现了对HTTP协议API服务的支持，后期应该还会支持gRPC协议的API服务 2. 框架的优势 无需进行程序开发，只需要编写配置文件 可以指定testcase之间的依赖关系 无依赖关系的testcase可以并发执行，执行速度更快 使用xpath提取变量，书写方便 支持从文件中导入变量，支持从response中提取变量 3. 完整的示例 3.1 启动API服务 使用docker compose启动一个HTTP RESTful API服务 cd docker-compose docker compose up -d 这个服务是book管理服务，它支持对book的增删改查 添加 curl -X POST 'http://localhost:8080/api/books' \ --header 'Content-Type: application/json' \ --data '{"title": "book3_title", "author": "book3_author"}' 接口返回 { "id": 3, "title": "book3_title", "author": "book3_author" } 修改 curl -X PUT 'localhost:8080/api/books/3' \ --header 'Content-Type: application/json' \ --data '{"title": "book3_title", "author": "book3_author-2"}' 接口返回 { "id": 3, "title": "book3_title", "author": "book3_author-2" } 3.2 自动化测试 autotest run -c=./config_files/autotest.yml -e=./config_files/.env.dev 自动化测试中的每一个测试用例都是 ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 1.前言 使用docker buildx 可以在一次build中生成支持多个平台的image。但在推动给私有仓库时，报"x509: certificate signed by unknown authority"。经过确认是，私有仓库使用的证书是自签名证书，导致SSL握手失败导致的。 2. 解决 docker buildx使用的builder配置方式与docker配置方式不同，需要在创建builder时，即指定 1) 创建配置文件 cat <<EOF > ./config.toml debug = true # root is where all buildkit state is stored. root = "/var/lib/buildkit" # insecure-entitlements allows insecure entitlements, disabled by default. insecure-entitlements = [ "network.host", "security.insecure"] [registry."my-registry.abc.local"] http = true insecure = true EOF 2) 创建builder 指定以./config.toml作为mybuilder的配置文件 docker buildx create --use --name=mybuilder —-config=./config.toml --bootstrap --bootstrap 表示启动builder ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.简介 你听说过docker-compose吗？在萌叔看来，docker-compose相当于单机且简化版的k8s。 可以简单的编写一个yaml文件，在yaml文件指定多个container。然后可以通过docker-compose，一次性启动和停止多个服务。 它有几个应用场景： 开发 自动化测试 持续集成 特别是自动化测试这个场景。比如有一个服务依赖数据库MySQL，要完成自动化测试，显然我们需要一个干净的MySQL。用k8s来完成服务和MySQL的部署成本太高，有点杀鸡用牛刀的感觉。并且多个人同时运行的话，还有可能产生冲突。docker-compose由于是单机运行，可以确保多人同时运行互相不冲突。 2.minio示例 该示例包含一个由4个container组成的minio集群，以及一个nginx container对外暴露minio集群的管理后台和API接口 Deploy MinIO on Docker Compose 创建本地目录 mkdir -p ~/mydata/minio/data1-1 mkdir -p ~/mydata/minio/data1-2 mkdir -p ~/mydata/minio/data2-1 mkdir -p ~/mydata/minio/data2-2 mkdir -p ~/mydata/minio/data3-1 mkdir -p ~/mydata/minio/data3-2 mkdir -p ~/mydata/minio/data4-1 mkdir -p ~/mydata/minio/data4-2 编写nginx的配置文件 ~/mydata/minio/proxy.conf upstream minio_console { server minio1:9001 max_fails=3 fail_timeout=5s; server minio2:9001 max_fails=3 fail_timeout=5s; server minio3:9001 max_fails=3 fail_timeout=5s; server minio4:9001 max_fails=3 fail_timeout=5s; } upstream minio_api { # 多个服务之间可以通过服务名称相互访问 server minio1:9000 max_fails=3 fail_timeout=5s; server minio2:9000 max_fails=3 fail_timeout=5s; server minio3:9000 max_fails=3 fail_timeout=5s; server minio4:9000 max_fails=3 fail_timeout=5s; } server { listen 9001; location / { proxy_pass http://minio_console; } } server { listen 9000; location / { proxy_pass http://minio_api; } } 创建一个文件夹minio-distributed mkdir minio-distributed 编写docker compose需要的YAML文件 在minio-distributed目录下编写文件docker-compose.yaml 在docker的体系中，以包含docker-compose.yaml文件的文件夹作为一个项目，文件夹的名称就是项目名称。 ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.引言 前段时间利用grafana/grafana-image-renderer 做了一个自动截图服务。 见萌叔的文章抓取GRAFANA PANEL视图。但是我发现了一个问题(grafana版本v6.0.1)，如果grafana的实例数量超过1个，在grafana中访问grafana render link时，就会有一定的概率失败，图片无法成功渲染。这到底是是为什么？ 本文将给出完整的问题排查和解决过程，希望读者可以从中汲取一些养分，为以后排查其它问题提供一些思路。 2. 日志，一切从日志开始 看到这种问题，首先看看日志中是否有线索 2.1 首先看grafana的日志 只能了解到点击grafana render link之后，会触发一个GET请求，访问grafana服务的 /render/d-solo/P3a2p0cZz/redis-and-mysql-and-cache，然后引起一个内部错误 2.2 看看grafana-image-renderer的日志 我们已经知道，图片渲染的过程，grafana要调用grafana-image-renderer，让我们来看下grafana-image-renderer的日志。 需要注意，grafana-image-renderer的日志默认是打印在标准输出和标准错误输出里的。 对比成功和失败的case我发现，在失败的case中，日志中会多了一条401 (Unauthorized)的日志 对应的链接，就是我们要渲染成图片的panel所对应的网页地址 猜测1 现在我们可以猜测grafana-image-renderer可能是请求grafana服务对应的网页资源失败，然后导致图片渲染失败。 2.3 抓包，需要API入口 2.3.1 对grafana-image-renderer抓包 为了进一步验证这个上面的猜测,抓包看一下，grafana-image-renderer所收到的请求 萌叔抓包使用的是buger/goreplay ./gor --input-raw :8081 --output-stdout 1 1a1a5c7c2e733bf0ed41f7ce35bee28da845ab49 1616730655714291898 2541293 GET /render?domain=grafana.example.com&encoding=&height=500&renderKey=HPXorbVBhC6taLHFEe6Jg9O3e5w6R5xn&timeout=60&timezone=Asia%2FShanghai&url=http%3a%2f%2fgrafana.example.com%2fd-solo%2fP3a2p0cZz%2fredis-and-mysql-and-cache%3forgId%3d1%26from%3d1616719854090%26to%3d1616730654091%26var-instance%3d192.168.1.100%3a9090%26panelId%3d8%26width%3d1000%26height%3d500%26tz%3dAsia%2fShanghai%26render%3d1&width=1000 HTTP/1.1 X-Forwarded-Proto: http Host: grafana-image-renderer.example.com Connection: keep-alive User-Agent: Go-http-client/1.1 Accept-Encoding: gzip 展开来看 将url参数解码以后，确实就是grafana中panel对应的网页地址, 到这里猜测1，已经被证实了。 猜测2 请求的参数中有个renderKey非常的可疑，它会不会是请求grafana获取对应网页时，用来鉴权的token呢？ 2.3.2 对grafana抓包 这里使用tcpdump抓取之后，然后用wireshark中观察 tcpdump -i eth0 host 192.168.1.102 and port 3000 -w /tmp/xxx.cap grafana-image-renderer请求grafana时，确实在Cookie中携带了renderkey。离真相越来越近了。 ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 本文使用的安装工具为easzlab/kubeasz 2. 步骤 2.1 修改docker目录 通过软连接的方式修改docker 数据存储路径 ansible new-node -i hosts -m shell -a 'mkdir /data/docker' ansible new-node -i hosts -m shell -a 'cd /var/lib/ && ln -s /data/docker docker' 2.2 安装gluster fs依赖 如果pod需要用到gluster fs才需要执行此步骤 ansible new-node -i hosts -m shell -a 'yum install centos-release-gluster glusterfs-fuse -y' 2.3 安装ntpd确保时钟同步 # 安装ntd ansible new-node -i hosts -m shell -a 'yum -y install ntp' # 设置开机自启动 ansible new-node -i hosts -m shell -a 'systemctl enable ntpd' # 启动ntpd服务 ansible new-node -i hosts -m shell -a 'systemctl start ntpd' # 手动执行一次同步 ansible new-node -i hosts -m shell -a 'ntpdate -u 0.centos.pool.ntp.org' 2.4 添加新节点 easzctl add-node 192.168.1.11 新增kube-node节点大致流程为：tools/02.addnode.yml 见参考资料1 ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.前言 xuxueli/xxl-job是一个分布式任务调度平台。它在github上有1w多个star，有多家公司都已经用在生产实践中。 在萌叔看来这是一个"Less is more"的典型。它的设计的非常简单，最大的优点是实用。 2.主要结构和逻辑 XXL-JOB任务调度平台分为2个部分，Scheduler和Executor。具体的实现Scheduler对应是xxl-job-admin,同时xxl-job-admin还配有web UI，可以配置管理任务。 Scheduler和Executor之间通过HTTP API交互，因此Executor可以通过各种语言实现。比如Golang的 xxl-job/xxl-job-executor-go 以上图为例，scheduleThread将任务通过Executor是的/run api推送给Executor { "jobId": 3, "executorHandler": "task.test", "executorParams": "x=100", "executorBlockStrategy": "SERIAL_EXECUTION", "executorTimeout": 0, "logId": 17, "logDateTime": 1606100913829, "glueType": "BEAN", "glueSource": "", "glueUpdatetime": 1606099566000, "broadcastIndex": 0, "broadcastTotal": 1 } Executor会根据executorHandler找到对应的handler，执行完之后，又会调用xxl-job-admin的/xxl-job-admin/api/callback回报任务的执行结果。从上面的描述我们可以知道，xxl-job-admin和excutor都必须暴露出api服务(都是HTTP接口)。 Scheduler可以有多个。它们之间通过MySQL进行同步。 主要的调度逻辑在JobScheduleHelper中 在每一轮执行调度逻辑之前, Scheduler必须先获得行锁 while (!scheduleThreadToStop) { ... // 加行锁 try { preparedStatement = conn.prepareStatement( "select * from xxl_job_lock where lock_name = 'schedule_lock' for update" ); preparedStatement.execute(); ... } catch (Exception e) { ... } finally { ... // 注意:锁必须正常释放 conn.commit(); ... } 由于xxl_job_lock 表中只有一条记录，所以这个逻辑与请求表锁类似，开销是比较大的。 ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 要让一个k8s + istio的集群真正能够在生产可用，我们需要考虑如下几类指标。 Node Metrics Container Resource Metrics Kubernetes API Server Etcd metrics Kube state-metrics 对于准备上集群的服务而言，我们会比较关注 服务所在容器的CPU、内存、网络流量、磁盘使用率等 业务指标：QPS、StatusCode、ErrorCode、请求延迟、缓存使用情况，连接池等 其中很大一部分其实都是标准指标，所有的服务都应该会有。另外istio已经对container的输入和输出流量进行了拦截，基于这些条件。萌叔希望达到如下效果 目标 通过prometheus的自动发现功能，发现并监控Container Resource Metrics 通过prometheus的自动发现功能，发现并监控envoy拦截到的部分指标 3）通过prometheus的自动发现功能，发现并监控app暴露的prometheus metrics 对于标准指标实现在grafana上的自动配置(生成Dashboard和Graph) 显然对于1）2）中的指标都是标准指标 2. 配置 根据参考资料4的说法 spec: template: metadata: annotations: prometheus.io/scrape: true # determines if a pod should be scraped. Set to true to enable scraping. prometheus.io/path: /metrics # determines the path to scrape metrics at. Defaults to /metrics. prometheus.io/port: 80 # determines the port to scrape metrics at. Defaults to 80. 服务本身如果想暴露自己的指标，可以通过在pod上增加注释prometheus.io/scrape prometheus.io/path prometheus.io/port。 但是实际使用中我发现注入了istio之后，这3项的值已经被修改为 ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 可以使用istio可以做灰度发布，下面简单记录一下步骤 2. 原理&配置 基于istio做灰度发布需要用到envoy的负载均衡功能。 回想一下我们再nginx中是如何配置负载均衡的 upstream backend { server 192.168.101.10:8080 weight=1; server 192.168.101.12:8080 weight=2; } 2.1 配置 可用通过配置权重来控制流向上游服务的流量 类似的，在istio中需要用到VirtualService apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: vs-backend namespace: test spec: gateways: - gateway-backend-gateway-io.istio-system.svc.cluster.local hosts: - backend.gateway.io http: - retries: {} route: - destination: host: sv-backend.test.svc.cluster.local subset: v0-0-1 weight: 20 - destination: host: sv-backend.test.svc.cluster.local subset: v0-0-2 weight: 80 timeout: 3s The proportion of traffic to be forwarded to the service version. (0-100). Sum of weights across destinations SHOULD BE == 100.If there is only one destination in a rule, the weight value is assumed to be 100. ...
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 注意: 本文涉及的服务版本 k8s: v1.18.2 istio: 1.7.3 1. 前言 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 最近重新部署了一套k8s + istio的集群，在安装istio遇到了些问题，简单的记录一下。 2. 安装 istio 1.7.3 不再支持helm方式安装。仅支持istioctl和Operator模式进行安装。 istioctl模式 使用命令行的方式与k8s集群进行交互 Operator模式 会启动一个IstioOperator容器（常驻，不退出） 容器，然后用户可以通过kubectl提交配置文件给IstioOperator容器，由IstioOperator容器来完成istio核心模块或者相关插件的安装 2.1 istioctl模式安装 2.1.1 下载 curl -L https://istio.io/downloadIstio | sh - cd istio-1.7.3 samples/ 目录下，有示例应用程序 bin/ 目录下，包含 istioctl 的客户端文件。istioctl 工具用于手动注入 Envoy sidecar 代理。 manifests/profiles 目录中有具体的配置文件 2.1.2 将 istioctl 客户端路径增加到 path 环境变量中 export PATH=$PWD/bin:$PATH 2.1.3 显示可用配置文件的列表 $ istioctl profile list Istio configuration profiles: remote separate default demo empty minimal 2.1.4 安装 不同的配置文件区别在于安装的模块有多有少，建议使用default配置 ...