Blogs

::: info 雖然文章內大多指令都是使用 docker，但由於是標準的 OCI image，使用 Podman 也是一樣的效果。 ::: 某段時間內，我會將所有需要執行的 binary 使用 containerize 給打包起來執行，例如： 需要將前端環境給跑起來，我會啟動一個 node 環境的 container: docker run --rm -it --name f2e --net=host -v $(pwd):/app \ docker.io/library/node:20-bookworm \ bash 需要安裝某個基於 golang 的 cli 工具，會使用自己寫的腳本，在 container 內進行建構。 需要透過 Liquibase 來進行 db migration，並不會選擇在本地安裝 maven 環境，一樣是啟動一個 container 來執行。 這麼做的好處是，「目前」大多數的 server/cli tools 至少會編譯 x86 架構下的可執行檔，我只需要確保 container 環境內可以工作，就可以在不同硬體的開發環境下游走。極度偏激的來說，無法確保安裝的 binary 有沒有受過污染，無論開源或閉源與否，也可以透過 Podman 來啟動 rootless 的 container 確保本機的安全。 但有時候會遇到別人打包的 image 十分肥大，即便程式可執行檔只需要幾 MB，編譯後的 image 確有幾百 MB（大多數是腳本語言），蒙生了從 image 中提取 executable 的想法，藉此也學習 docker layer 間的關係。...

RBAC 概念簡介 在我們探討如何利用 Open Policy Agent (以下簡稱 OPA) 和 Golang 建立一個彈性的 RBAC 模組之前，先讓我們來了解一下 RBAC的基本概念。 RBAC（Role-Based Access Control，基於角色的訪問控制）是一種廣泛應用的訪問控制策略，在軟體安全性領域尤為重要。其核心思想是將系統訪問權限與用戶的角色（職位、責任或職務）關聯起來，而不是直接與個別用戶關聯。這意味著訪問權限被捆綁到角色上，然後將用戶分配給這些角色。舉個例子，一個「管理員」角色可能有權訪問系統的所有資源，而「員工」角色則只能訪問特定部分的資源。 RBAC 的主要優勢在於其靈活性和簡化的權限管理。當需要變更權限時，只需修改角色的訪問權限，而不需要為每個用戶單獨設定。這不僅使權限管理更為高效，也減少了錯誤配置的可能性，提高了整體的系統安全性。 在實踐中，RBAC 允許創建精細且靈活的策略，以滿足複雜的商業和安全需求。無論是大型企業還是小型團隊，RBAC 都提供了一個可靠的框架，來確保正確的用戶擁有適當的訪問權限，從而保護關鍵資源免受未授權訪問。 可以參考 Cloudflare 的文章，簡單來說就是什麼「角色」能夠對什麼「資源」做什麼「操作」。 Open Policy Agent (OPA) 介紹 OPA 是一個「Strategy as Code」的開源專案，專門設計用於統一地管理和執行跨不同系統的策略。它不僅提供了一個高級的策略語言——Rego，還支援將策略作為代碼與應用程式的其他部分一同存儲、版本控制和部署。OPA 的這種設計使其能夠輕鬆集成到微服務、Kubernetes、CI/CD 管道、API 網關等多種環境中。顯著特點是其策略的編寫方式。Rego 是一種專門為策略和規則定制的查詢語言，它使開發者能夠以聲明式方式描述策略和規則，從而確保這些策略既容易理解又易於維護。這對於建立複雜的 RBAC 系統尤為重要，因為它允許策略的靈活性和可擴展性，同時又保持了清晰和易於審查的結構。 我們可以利用 OPA 提供的 API 來評估和執行這些策略。這意味著開發者可以在 Golang 程式碼中直接嵌入策略判斷的邏輯，從而實現動態、細粒度的訪問控制。這種方法的一個優點是，它支援在 runtime 動態更新策略，或是編譯進 binary，從而提供更大的靈活性和即時性。 整合 OPA 與 Golang 透過官方案例來了解如何使用 參考了 OPA 官方的 rbac 章節，並加以修改。使用最簡單的例子： admin can read user bob is admin ------------------- bob can read user 轉化成 RBAC 模型即為：...

Golang 作為一個偏向 server 應用的程式語言，一般的 web server 並不會直接使用原生的 package net/http，而更多的使用 gin-gonic/gin 或是 gorilla/mux，後來也有 labstack/echo 以及 go-chi/chi 等等選擇，在效能、輕量、好維護、好擴充中，都能找到對應的 third party package，其中的原因不外乎是原生的 package 提供的功能過於簡潔。 好在 1.22 中，官方改進了 net/http 中對於多工器、路由，甚至出了一篇部落格，現在更可以「大膽的」直接使用 standard library。 Path Parameter 若要將應用的 Web API 定義成 RESTful，我們會使用 /資源/{資源唯一識別符}/子資源/{子資源唯一識別符} 來定義路徑。假如要獲取一個使用者的訂單，則會使用 GET /users/1/orders 來獲取。在 1.22 以前，我們只能定義到 /users，再自行解析往後的 path： http.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) { subPath := strings.TrimPrefix(req.URL.Path, "/users/") if len(subPath) == 0 { xxx } else { ooo } ... }) 而在 1.22 中新增了 net....

鋪墊：敏捷開發價值觀、原則與實踐 有什麼開發，就有什麼測試，傳統開發就有傳統測試，敏捷開發就應該要推行敏捷測試。在討論敏捷測試前，應該先理解敏捷開發模式，否則理解敏捷測試會很困難。 敏捷開發是一種思想或稱作方法論，通過不斷迭代與增量發布，最終交付符合用戶價值的產品。 書中提到一些敏捷開發的歷史、演進與框架 PDCA 循環 輕量級軟體開發 減少複雜的文件，強調人員的互動 敏捷宣言 XP（eXtreme Programing）：較多是著重在軟體開發，例如 TDD、pair programing、CI 等等。 BDD（行為驅動開發）：使用「通用語言」來描述測試案例，將 User Story 的細節進行完整地描述。 Feature（特性）: 購物車功能 Scenario（情境）: 添加商品到購物車 Given（假設）: 用戶已經登錄到購物平台並且正在瀏覽商品 When（當）: 用戶點擊某個商品的「添加到購物車」按鈕 Then（那麼）: 該商品應該被添加到用戶的購物車中 And（並且）: 購物車中的商品總數應該更新 FDD（特性驅動開發）：使用制式結構來建構特性列表 <action> the <result> <by|for|of|to> a(n) <object> Scrum：確保每天、每個階段都向著目標明確進行的一種「方法」。 推薦看 Scrum 提倡者自己寫的 SCRUM：用一半的時間做兩倍的事 DevOps 與敏捷的關係 DevOps 可以看作是敏捷的延伸，打通軟體開發、測試、交付、維護中的層層牆壁。 敏捷宣言 藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。透過這樣的努力，我們已建立以下價值觀： 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 也就是說，雖然右側項目有其價值，但我們更重視左側項目。 敏捷測試之道 敏決測試不是一種測試方法，而是為了適應敏捷開發而設計的一套軟體測試解決方案。 敏捷測試宣言 Full Lifecycle Testing OVER Isolated Testing Phase Team Shared Responsibility OVER Testers Ensure Quality Continuous Targeted Automation OVER Widespread Regression Testing Quality Built-in OVER Defect Detection Full Lifecycle Testing 強調測試左移與右移，並非將測試「移動」到兩個端點，而是全程測試的介入。...

《最高學以致用法》、《最高學習法》這兩本書是我在 2023 年上半年讀了覺得挺有意思的書，核心概念就是「產出」，例如唸書時能夠回答同學問題的，肯定都已經精通該知識點了。 加入 KryptoGO 後，因為團隊的成長，Leader 開始嘗試舉行兩週一次的 Backend Sharing，不僅是分享工作上遇到的疑難雜症，更可以交流不同的知識點。 起初，我可以我分享了一些過去用過的工具與知識點，隨著時間的流逝，開始感受到黔驢技窮，於是我也仿效了《刻意練習》，不斷的為了能有更好的分享品質而學習。 以下是這半年來我在 Backend Sharing 中或多或少提及或是討論到的，又分為解決方案、小工具、方法論。 小工具 由於喜歡折騰 Homelab，時不時會到 r/selfhosted、r/opensource/ 尋找一些開源的自架方案或小工具，有一些大幅度的改善了我的開發流程，而有一些則漸漸的不再使用 exa & eza & bat eza、exa、bat 都是基於 rust 寫成的 cli 替代品，exa、eza 對標 cd，而 bat 對標 cat，我會在 .zshrc 中寫上 alias。 if command -v bat &> /dev/null; then alias cat=bat; fi if command -v eza &> /dev/null; then alias ls="eza --icons" alias ll="eza --icons -lh" alias tree="eza --icons --tree" fi 還有其他性質相同的 rust 寫的小工具諸如： zoxide、topgrade、alacritty、bottom...

接續著 KDE neon / Ubuntu 啟用 PipeWire 與 LDAC/AAC/AptX 藍芽編碼，每當連線到藍芽耳機時，語音設定檔在使用 LDAC 後，就無法同時使用麥克風，這樣一來在開會時，就需要手動到設定裡面去調整語音設定檔。 身為一個懶惰鬼，可以用鍵盤解決的就不會用滑鼠去點，發現可以通過 pactl（PulseAudio）在 cli 直接設定 audio profile。 首先，我們通過 bluetoothctl 列出藍芽設備的實體位置 $ bluetoothctl > [EAH-A800]# devices > Device 88:C9:E8:B1:5D:AE WF-1000XM4 > Device DC:22:D2:85:85:15 MX Master 3S > Device B8:20:8E:35:CB:D0 EAH-A800 文章內舉例的目標為 EAH-A800，也就是 B8:20:8E:35:CB:D0 接著需要確認目前藍牙裝置支持的音訊設定檔。可以透過 pactl list cards short 來列出目前啟用的設備 $ pactl list cards short 47 alsa_card.usb-Shure_Inc_Shure_MV7-00 alsa 48 alsa_card.pci-0000_00_1f.3-platform-skl_hda_dsp_generic alsa 49 alsa_card.usb-NuPrime_NuPrime_DAC-9H-00 alsa 1002 bluez_card.B8_20_8E_35_CB_D0 module-bluez5-device.c 發現目標為 1002 bluez_card.B8_20_8E_35_CB_D0 再來通過 pactl list cards 來獲取所有音訊設定檔...

在使用 Golang 時，我們可能會遇到一種稱為隱式記憶體別名（Implicit Memory Aliasing）的問題。這篇文章將探討這個問題以及如何使用工具和語言特性來解決它。 隱式記憶體別名的問題 隱式記憶體別名主要發生在 range 語句中。當使用 range 對一個切片 slice 或映射 map 進行迭代時，Iterator 在每次迭代中並不是唯一的實例。這可能導致意外的行為，特別是在並發環境或當迭代變量被指針引用時。 slice with Implicit Memory Aliasing 下面示例可能是基本的 golang 面試題，會問你迭代後的 pointers 內的 Name 為何 答案是 Joe Joe Joe package main import "fmt" type Person struct { Name string Gender string } func main() { persons := []Person{ {Name: "John", Gender: "M"}, {Name: "Jane", Gender: "F"}, {Name: "Joe", Gender: "X"}, } pointers := make([]*string, len(persons)) for index, person := range persons { fmt....

概述 在家裡面架著一台 lab，使用 proxmox ve 作為 vm server 透過 qemu 虛擬化一台 ubuntu server vm 在這個 vm 上使用 k3s，啟動 kubernetes 的服務 在 kubernetes 內跑著眾多 dockerize 的 containers。 雖然我不是資深維運專家，但我知道這可能很搞笑。 會需要這麼麻煩還不是為了省一點點 GKE 的成本（即便可能沒省到），但在自家建一個 lab 環境而不用計算由時間計價的 infra 成本，還是挺省腦袋的。 過去僅是將 service 使用 nodePort 來讓家裡面的其他裝置可以連線，或是使用 wireguard 作為 VPN 來從遠端連線，就是沒有動力處理好 http service 與 TLS，趁這個假日剛好需要把 自架 vaultwarden 後端 給 expose 出來，便誕生了這篇。 在當前的雲端運算時代，許多開發者和 IT 專業人員都面臨著一個共同的挑戰：如何有效地將位於不同網絡環境中的服務整合並暴露給公眾。特別是對於那些希望將家用網絡中的服務有效連接到公共雲端（如 GCP,AWS,Azure,OCI）的用戶來說，這一挑戰尤為突出。文內主要講述通過在 GCP VM 上部署 FRP（Fast Reverse Proxy）服務器，結合家中的 kubernetes cluster 上配置的 FRP 客戶端，來實現一個高效且安全的服務部署流程。 透過此方式，我們不僅可以利用 GCP VM 作為公共 IP 的代理，實現從互聯網到家庭網絡的無縫連接，還能藉助 kubernetes 的強大功能進行快速的服務部署和管理。同時，利用 ingress-nginx 作為 ingress 控制器和 cert-manager 進行 TLS 設定，我們能夠確保服務的安全性和可靠性。...

Ubuntu 22.10 將 Audio Server 從 PulseAudio 切換成 PipeWire 遇到了什麼問題 明明使用著有 LDAC 或是 AptX 解碼能力的藍芽耳機，卻只能被迫接受 sbc 的低傳輸率音質嗎，身為規格黨怎麼可以忍受這件事（即便大部份時間都只使用 Youtube Music 的 128K bps opus） 解決方法 我們可以在 KDE neon 上啟用 PipeWire，並安裝更多藍芽轉碼器 安裝 WirePlumber（PipeWire Manager） sudo apt install -y pipewire-media-session- wireplumber 透過 systemd 管理 WirePlumber 的開機自啟 daemon systemctl --user --now enable wireplumber.service 安裝 ALSA sudo apt install -y pipewire-audio-client-libraries 安裝藍芽轉碼器 sudo apt install -y \ libfdk-aac2 \ libldacbt-{abr,enc}2 \ libopenaptx0 sudo apt install -y \ libspa-0....

先前在「在 AWS 上使用 EC2 建立 FRP 玩玩內網穿透」一文中敘述了如何透過 AWS 實現虛擬穿透，也在內文中提到或許可以使用 wireguard 搭建內網，其原因也很簡單：每更新一個 port 都要重新設定 server side 實在是太麻煩了，拖更了進一年終於要開始寫 wireguard 的使用了。（AWS 免費也快到期了） 遇到了什麼問題 在使用 wireguard 來搭建 VPN 前，我是使用 zerotier 搭配 Mikrotik RB5009 所執行的 RouterOS 7.x 版本，讓外網可以連回家裡的網路環境 但 zerotier 的網路拓樸是存在他們官方伺服氣上，與其相信 zerotier，我想在 vps 上建立虛擬機，並只許特定 ip 登入，可能更加可靠（？ 解決方法 於是我在 frp tunnel VM 上建立了 wireguard 節點，作為外網與內網溝通的橋樑。 wireguard 是一個高效的現代化 VPN，目標是比 IPsec 更快。在 2020 年時正式推出 1.0.0 版本。 wireguard 的拓樸實際上是 peer2peer，甚至可以達到 full mesh，但礙於錢錢不夠，單一個節點作為 server side 就足夠了。 server 使用 docker-compose 能快速部署 wireguard 服務，我們使用的是 wg-easy 簡單換掉一些參數: WG_HOST: vps 的公網 IP WG_DEFAULT_ADDRESS: 預設內網 ip 範圍，比如 10....