最近公司內部多個專案都需要用到 RBAC (Role-based access control) 權限控管，所以決定來找尋 Go 語言的解決方案及套件，在 Go 語言比較常聽到的就是 Casbin，大家眾所皆知，但是隨著專案變大，系統複雜性更高，希望未來可以打造一套可擴充性的權限機制，故網路上看到一篇 ladon vs casbin 的介紹文章，文章留言有中國開發者對於 Casbin 的一些看法，以及最後他推薦另一套 CNCF 的專案叫 Open Policy Agent 來實作權限控管機制。本篇直接來針對 Open Policy Agent 簡稱 (OPA) 來做介紹，並且用 Go 語言來驗證 RBAC 權限。底下是文章內其他開發者用過 Casbin 的感想

1.使用覺得ladon的質量更好，支持類ACL和RBAC的權限系統，跟亞馬遜AWS的IAM非常契合 2.casbin那些庫的質量真的是無力吐槽，都沒有經常測試的東西就往github發，UI也到處bug，全都是畢業生寫的一樣，試用便知 3.casbin這個項目不讓提問題，提問題就給你關閉，作者很涉別人提問題 4.這些確實是本人的經歷，大家慎重選擇吧

最後的推薦

強烈推薦CNCF今年畢業的策略引擎OPA（維護團隊主要是Google，微軟，Styra等），可以實現ABAC，RBAC，PBAC等各種權限模型，目前我們已經在生產環境中使用。 也是基於OPA實現的。

本篇所使用的範例程式碼請從這邊下載或觀看。

如果不了解什麼是 buffer 或 unbuffer channel 的朋友們，可以參考這篇文章先做初步了解，本文要跟大家介紹為什麼 signal.Notify 要使用 buffered channel 才可以，底下先來看看如何使用 signal.Notify，當我們要做 graceful shutdown 都會使用到這功能，想要正常關閉服務或連線，透過 signal 可以偵測訊號來源，執行後續相關工作 (關閉 DB 連線，檢查 Job 是否結束 … 等)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

package main

import (
    "fmt"
    "os"
    "os/signal"
)

func main() {
    // Set up channel on which to send signal notifications.
    // We must use a buffered channel or risk missing the signal
    // if we're not ready to receive when the signal is sent.
    c := make(chan os.Signal, 1)
    signal.Notify(c, os.Interrupt)

    // Block until a signal is received.
    s := <-c
    fmt.Println("Got signal:", s)
}

上面例子可以很清楚看到說明，假如沒有使用 buffered channel 的話，你有一定的風險會沒抓到 Signal。那為什麼會有這段說明呢？底下用其他例子來看看。

當網站上線後，流量增加或短暫功能故障，都會造成使用者體驗相當不好，而這時該怎麼快速找到效能的瓶頸呢？通常 CPU 衝到 100% 時，有時候也蠻難複製及找出關鍵問題點。本篇會介紹一套工具叫 pyroscope，讓開發者可以快速找到效能瓶頸的程式碼。之前也寫了相關的效能瓶頸文章，可以參考看看『Go 語言用 pprof 找出程式碼效能瓶頸』或『善用 Go 語言效能測試工具來提升執行效率』，上述兩篇都是針對 Go 語言的效能分析文章，而 pyroscope 目前可以支援在 Python, Ruby 或 Go 的環境。底下筆者會針對 Go 環境做介紹。

兩台電腦之間該如何傳送檔案，其實方法有超多種的，像是 FTP 或透過 SSH 方式來傳送檔案，但是這些方法步驟都有點複雜，FTP 需要架設 FTP 服務，SSH 要學習 SCP 指令，那有沒有更好的方式從單一電腦點對點傳送檔案到另一台呢？傳送過程需要快速又要安全，本篇介紹一套用 Go 語言寫的工具叫 croc，詳細的介紹可以參考看看作者的 Blog 介紹，此工具有底下功能及優勢。

近期其中一個專案使用 Terraform 來管理 AWS 雲平台，初期預計只有我一個人在使用 Terraform，所以就沒有將 Backend State 放在 AWS S3 進行備份管理，這個粗心大意讓我花了大半時間來搶救 State (.tfstate) 檔案，而搶救過程也是蠻順利的，只是需要花時間用 terraform import 指令將所有的 State 狀態全部轉回來一次，當然不是每個 Resource 都可以正常運作，還是需要搭配一些修正才能全部轉換。

結論: 請使用 terraform import 指令，這是最終解法。

上一篇『初探 Pulumi 上傳靜態網站到 AWS S3 (一)』主要介紹 Pulumi 基本使用方式，而本篇會延續上一篇教學把剩下的章節教完，底下是本篇會涵蓋的章節內容:

1. 設定 Pulumi Stack 環境變數
2. 建立第二個 Pulumi Stack 環境
3. 刪除 Pulumi Stack 環境

讓開發者可以自由新增各種不同環境，像是 Testing 或 Develop 環境，以及該如何動態帶入不同環境的變數內容，最後可以透過單一指令將全部資源刪除。

上一篇作者提到了兩套 Infrastructure as Code 工具，分別是 Terraform 跟 Pulumi，大家對於前者可能會是比較熟悉，那本篇用一個實際案例『建立 AWS S3 並上傳靜態網站』來跟大家分享如何從無開始一步一步使用 Pulumi。本教學使用的程式碼都可以在 GitHub 上面瀏覽及下載。教學會拆成七個章節:

1. 建立 Pulumi 新專案
2. 設定 AWS 環境
3. 初始化 Pulumi 架構 (建立 S3 Bucket)
4. 更新 AWS 架構 (S3 Hosting)
5. 設定 Pulumi Stack 環境變數 (教學二)
6. 建立第二個 Pulumi Stack 環境 (教學二)
7. 刪除 Pulumi Stack 環境 (教學二)

想必大家對於 Infrastructure as Code 簡稱 (IaC) 並不陌生，而這個名詞在很早以前就很火熱，本篇最主要介紹為什麼我們要導入 IaC，以及該選擇哪些工具來管理雲平台 (AWS, GCP, Azure 等…)。觀看現在很火紅的 Terraform 及後起之秀 Pulumi 是大家可以作為選擇的參考，而底下會來歸納優缺點及技術比較，以及為什麼我最後會選擇 Pulumi。這兩套都是由 Go 語言所開發，現在選擇工具前，都要先考慮看看什麼語言寫的，以及整合進團隊自動化部署流程難易度。

不久之前寫過一篇『從 graphql-go 轉換到 gqlgen』，目前團隊舊有的專案還是繼續用 graphql-go 來撰寫，不過之後需求量越來越大，維護 graphql-go 就越來越困難，故有在想怎麼把 gqlgen 跟 graphql-go 相容在一起，那就是把這兩個套件想成不同的服務，再透過 Gateway 方式完成 single data graph。至於怎麼選擇 GraphQL Gateway 套件，最容易的方式就是使用 @apollo/gateway，但是由於個人比較偏好 Go 語言的解決方案，就稍微找看看有無人用 Go 實現了 Gateway，後來找到 nautilus/gateway，官方有提供文件以及教學 Blog 可以供開發者參考。底下會教大家使用 nautilus/gateway 將兩個不同的服務串接在一起。

之前介紹了一個開源工具『用 Docker 每天自動化備份 MySQL, Postgres 或 MongoDB 並上傳到 AWS S3』，讓開發者可以快速透過 Docker 方式來備份資料庫，而本篇要介紹我如何用 Go 語言來撰寫 CLI 並且整合 Docker 來實現備份。此工具都是透過各大資料庫官方提供的 CLI 指令 (pg_dump, mysqldump … 等)，故大家不用猜想是什麼神奇的技巧。底下來依序介紹整個目錄結構，及我如何實現。