使用 Kubernetes Liveness 來檢查 ASP.NET Core gRPC 回應合乎預期 今天要紀錄透過 Kubernetes 搭配 使用 ASP.NET Core middleware 進行 gRPC healthy check (當然 使用 ASP.NET Core BackgroundService 進行 gRPC healthy check 也是可行的) 與 讓 container 中的 ASP.NET Core 也有憑證 來確保 service

讓 container 中的 ASP.NET Core 也有憑證 之前筆記 使用 ASP.NET Core middleware 進行 gRPC healthy check、使用 ASP.NET Core BackgroundService 進行 gRPC healthy check 以及 ASP.NET Core gRPC 無法在 macOS 上啟動？！ 都有提到過 gRPC 的原生限制：採用 HTTP2 協定

使用 dotnet-grpc-cli 取得 gRPC Service 內容 之前筆記 使用 grpc-cli 呼叫 gRPC Service 紀錄到 gprc 官方 command line tool 的使用方式，後來偶爾間發現竟然有 dotnet 版：dotnet-grpc-cli，還是 C# 撰寫的

使用 dotnet-grpc-cli 呼叫 gRPC Service 之前筆記 使用grpcurl 呼叫gRPC Service 紀錄到 grpcurl (curl for grpc) 的使用方式，最近在查其他資料時這才發現原來 gRPC 官方也有提供：grpc-cl

在 ASP.NET Core 上啟用 gRPC Reflection 系統功能愈來愈多，自然而然地 proto 檔也就熟變得愈來愈龐大，如果每次想要手動測試 gRPC 功能時都要手 key proto 實在沒效率 (測試工具可以參考之前

建立 MongoDB 自訂角色 (role) 最近在為系統的 storage 服務加上 data archival 流程，其中 MongoDB 的做法跟一般流程不同，雖然 MongoDB 有許多內建的角色權限 (Built-In Roles)，但沒找到適合的，我的

使用 ASP.NET Core BackgroundService 進行 gRPC healthy check 之前筆記 使用 ASP.NET Core middleware 進行 gRPC healthy check 紀錄到如何使用 ASP.NET Core 內建的 Health Check middleware 來進行 gRPC service 的檢查，當時有看到 Steve Gordon 的 HEALTH CHECKS WITH GRPC AND ASP.NET CORE 3.0 使用 serive 本身的

使用 ASP.NET Core middleware 進行 gRPC healthy check 這個需求來自於某次的 issue：有個 service 的回應時好時壞，沒有規律，這讓我想起當年在壽險公司資訊部門使用 asp 提供服務的故事，當

kubectl patch 錯誤 這件事實在太瞎了，不得不紀錄一下 這幾天正在進行團隊各環境的 service 升級，其中的重點就是 kubernetes 版本，重新 refactor 所有 ansible scripts 後，終於沒有出錯，但在部署時都

Ansible 安裝 Redis Cluster 之前筆記 Ansible 安裝 Redis Cluster 紀錄了以 ansible 內建 function 為主的 redis cluster 安裝 script，最近因為需要將 redis5 更新至 redis6，重新 review 了 script，做了些調整

yum 安裝指定版本套件 這個問題起因於要追查線上問題，但另建環境卻怎樣也模擬不出錯誤，後來才發現另建的環境使用的套件是較新版本，原本的 bug 也被修復；

CentOS 使用 yum 安裝 Redis6 之前筆記 使用 Yum 安裝 Redis 5 中提到預設的 centos yum repository 中僅能安裝 redis3，透過使用 ius repository 才能使用 yum 來安裝 redis5，不過 redis6 已經問市一陣子

在 Centos 上新增磁區 最近在調整公司的 Ansible 各 service 的安裝腳本，而身為工程師出身的 SRE，當然不能沒有測試呀。之前寫單一目的 ansible role 時，都是透過建立 azure vm 來進行測

Container 中執行 apt-get update 時遇到 GPG KEYEXPIRED 之前筆記 執行 apt-get update 時遇到 GPG KEYEXPIRED 紀錄到在使用 image : confluentinc/cp-kafka:5.5.0 建立 container 後需要安裝其他套件，但 apt-get update 卻遇到 GPG KEYEXPIRED 的錯誤，當時透過進到 container 中手動調整

讓特定 message 在 kafka 中可以有順序性 之前專案為了保證 message 的順序性捨棄當時還在 0.8 版的 kafka 而選用 RabbitMQ，雖然 RabbitMQ 在效能數據上跟 kafka 不是同個量級水準，但已