一般来说，监控 Substrate 框架开发的区块链节点，可以使用官方推荐的 Prometheus + Grafana 技术栈。在节点数量比较多的情况下，这套方案的优势比较容易体现出来，我给公司的官方节点也是这么配的。不过近期 Darwinia 主网上线，有不少同事想要跑自己的验证人（validator）节点。对于他们来说： 搭建一套 Prometheus 还要自己调面板和规则，成本实在太高； 只用 PM2、Supervisord、Systemd 之类的守护进程通常只能保证进程没挂，但节点是否正常出块是未知的（例如断网、0 Peer 的情况，节点进程还在，其实已经掉线了）。 为了解决以上这两个问题，我搞了一套非常简易的、基于日志的监控预警方法。
阿里云收购万网之后，几乎不赚钱的邮件服务还真是不维护不迭代了 — 不支持 DKIM，没法配 DMARC，就连 SMTP 也不支持 STARTTLS 587 端口。
While I deploying v2ray-exporter with Kustomize, I realized that commonLabels in kustomization.yaml doesn’t take care of the spec.selector.matchLabels field in ServiceMonitors. That makes sense, as ServiceMonitor is a part of CoreOS’s Prometheus Operator project, neither included nor maintained by Kubernetes. But how can we direct Kustomize to fill the labels in ServiceMonitors or even any fields in customized resources?
The official doc of OpenWrt on VMware HowTo seems already outdated, and there’s no explaination of how to fix Unsupported or invalid disk type 2 for 'scsi0:0'. Ensure that the disk has been imported. on ESXi 6.7. Here after looked into some clues on Chinese router forums, I found an usable method to convert the image into ESXi VMDK format on macOS.
最近在探索「如何发布 NPM 包」的过程中，发现多数人的思路要么完全不用 CI，修改 package.json 内版本号之后手动发布；要么结合 CI，但需要 CI 生成新版本号之后修改 package.json，最后机器人执行 Git Commit + Git Tag 并推送到仓库内。这两种做法我都不是很喜欢，前者没有 CI 不能忍，后者不仅要求 CI 有写权限，而且会仓库内增加许多形如 Release v... 之类的提交，强迫症表示接受不了。 不过经过一番研究，我还是找到了两种比较「干净」的思路，来看看吧。
As you probably heard Terraform before, it’s a great DevOps tool that can help you build your infrastructures with configurations and codes, aka Infrastructure as Code. Terraform has a bunch of great integrations with cloud platforms, some of them are maintained by Terraform official, such as Azure provider and AWS provider. However, Alibaba Cloud (which is the biggest public cloud company in China mainland) provider is created and maintained by alibaba itself so far. Lack of quick start guide and documentation makes it a little bit hard to get started with.
已发布的 DevOps 自动化实践 - 定时任务监控的进化之路 一次 KubeCPUOvercommit 告警排查过程小记 DevOps 自动化实践 — 在 K8s 上自动化执行 Database Migration 基于 UniFi 全家桶的企业 Wi-Fi 客户端管理 DevOps 自动化实践 — 管理 Incident 工作流 迁移至个人博客的 由于相关人员长期拖延审稿、发稿，将部分文章迁移至个人博客发布。
在开发过程中，我们经常需要使用到国外的资源，例如各种包依赖等。国内目前比较普遍的做法是使用由知名第三方维护的国内镜像。虽然方便，但也存在一些无法避免的问题，例如： 镜像可靠性未知，出问题时我们无能为力，只能等待第三方修复。 镜像同步时间未知，可能存在数据滞后。 存在安全隐患（尽管可能性较小）。 因此，我个人更加推荐依赖代理来实现快速访问所需资源的目的。本文不会涉及任何违反法律法规的内容，只来谈谈 macOS 下如何让不同应用的流量通过 本地的 代理服务。
在之前的文章中，我介绍了： 如何使用 GitLab CI 实现持续部署。 如何使用 Helm 和 Helmfile 部署应用到 Kubernetes 集群中。 但这其中缺少了关键的一环：创建一个属于你的项目的 chart，这样才能把我们开发的项目通过 Helm 部署到集群中。本文将会为大家介绍我们如何创建并维护 chart，从而打通从提交代码到部署的完整流程。
在 Kubernetes 中实现 TLS termination 非常容易。Ingress 资源包含一 secretName 属性，用于指定 Secret 资源名称。在取得证书后，通过 kubectl create secret tls tls-secret --key tls.key --cert tls.crt 创建 Secret 存储证书，便可以被 Ingress 使用了。 唯独有些不方便的是，证书的申请以及创建 Secret 的过程需要手动执行。在证书即将过期前，还需要人工续期。在传统 VM 部署的场景下，可以使用例如 certbot 或 acme.sh 等项目，配合 Let’s Encrypt 自动申请并定期续签证书。而在 K8s 集群中如何降低证书维护成本？来看看我们是怎么做的。