[實作筆記] 初體驗設定 Nvidia GPU 的 Azure VM

前情提要

隨著深度學習和 AI 的普及,許多工作和研究需要強大的運算能力,
而 GPU 提供了相較於傳統 CPU 更高效的計算能力。
因此,我選擇在 Azure 上設定 Nvidia GPU 虛擬機來滿足這些需求。
這篇文章將分享我在 Azure 上設定 Nvidia GPU 虛擬機的初體驗,並記錄實作過程中的一些重點。

前置作業

在開始設定 GPU 虛擬機之前,需要先完成以下準備工作:

  1. Azure 帳戶:確保你已經擁有 Azure 的帳戶,並且帳戶中有足夠的配額來創建 GPU 虛擬機。
  2. 選擇適合的虛擬機規格:Azure 提供多種 GPU 虛擬機型號,如 NV 系列和 NC 系列,根據需求選擇合適的型號。
  3. 安裝 Azure CLI:透過 Azure CLI 可以更方便地管理和配置虛擬機,可以在本地環境中安裝並配置 Azure CLI。
  4. 創建資源群組與虛擬機
1
az group create --name <myResourceGroup> --location eastus
1
2
3
4
5
6
7
az vm create \
--resource-group myResourceGroup \
--name myT4VM \
--image UbuntuLTS \
--size Standard_NC6s_v3 \
--admin-username azureuser \
--generate-ssh-keys

實作步驟

可以參考官方手冊),
本文大量引用 3. Package Manager Installation 中 3.9 的篇幅

登入到虛擬機後,安裝 Nvidia 驅動程式

1
2
3
sudo apt-get update
sudo apt-get install -y nvidia-driver-470
sudo reboot

安裝當前運行的內核版本所需的 Linux 標頭文件

1
sudo apt-get install linux-headers-$(uname -r)

刪除過時的金鑰(實作上,跟本沒有這個金鑰,所以跳過也沒關係)

1
sudo apt-key del 7fa2af80

查詢作業系統與晶片架構

1
2
3
4
5
6
7
8
> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
> uname -m
x86_64

安裝 CUDA-Keyring

1
wget https://developer.download.nvidia.com/compute/cuda/repos/$distro/$arch/cuda-keyring_1.1-1_all.deb

參考前一步驟將 $distro 換成 ubuntu2204$arch 換成 x86-64,
也可以直接到此 https://developer.download.nvidia.com/compute/cuda/repos 找到你合適的 deb 檔
下載:

1
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86-64/cuda-keyring_1.1-1_all.deb

安裝:

1
sudo dpkg -i cuda-keyring_1.1-1_all.deb

安裝 CUDA SDK

1
sudo apt-get install cuda-toolkit

安裝 Nvidia GDS 驅動,提升 GPU 和存儲間的高效數據傳輸性能

1
sudo apt-get install nvidia-gds

重啟主機

1
sudo reboot

確認是否安裝成功

1
nvidia-smi

 看到下面的畫面就是成功

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
> nvidia-smi
Mon Jul 1 09:21:24 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.183.01 Driver Version: 535.183.01 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 Tesla T4 Off | 00000001:00:00.0 Off | Off |
| N/A 31C P8 9W / 70W | 140MiB / 16384MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 1095 G /usr/lib/xorg/Xorg 130MiB |
| 0 N/A N/A 1356 G /usr/bin/gnome-shell 7MiB |
+---------------------------------------------------------------------------------------+

參考

(fin)

[實作筆記] 建立 Azure VM 的快照(Snapshot)

前情提要

這次記錄實作 Azure VM 的快照(Snapshot)與還原,與 VM images 不同,
快照是針對磁碟的即時捕捉,而不是整個虛擬機器的範本。
VM images 用於創建新的虛擬機器,是在固定的狀態下保存整個 VM,
包括操作系統、應用程式和所有配置。

相比之下,快照則僅保存特定磁碟的狀態,適合於快速還原或備份目前正在運行的 VM。
選擇快照主要因為它的快速性和簡便性,可以在短時間內恢復 VM 到指定狀態,
以我的例子來說,我因為 AI 需求建了昂貴的 Azure VM ,使用 Image 會會佔用我們的 Quotas。
所以 Snapshot 會是較好的還擇

前置作業

在開始建立快照之前,請確保以下條件已經準備妥當:

  1. 已經擁有一個可操作的 Azure 帳戶並能夠登入 Azure 入口網站。
  2. 目標 VM 已經啟動並運行正常,且確定需要為其建立快照。
  3. 已經分配足夠的儲存空間來保存快照數據。

實作步驟

建立 Snapshot

  1. 登入 Azure 入口網站 並進入虛擬機器(Virtual Machines)頁面。
  2. 從虛擬機器列表中,選擇您想要建立快照的 VM。
  3. 在左側導航欄中,找到並點擊 “磁碟(Disks)”。
  4. 在磁碟頁面中,選擇想要建立快照的磁碟(通常是 OS Disk)。
  5. 點擊上方的 “快照(Snapshot)” 按鈕,進入快照配置頁面。
  6. 在快照配置頁面中,輸入快照名稱,並選擇儲存帳戶和資源群組。
  7. 檢查所有設定無誤後,點擊 “建立(Create)” 按鈕,開始建立快照。這個過程可能需要幾分鐘。
  8. 快照建立完成後,就可以在資源群組或儲存帳戶中找到該快照,並隨時使用它來還原 VM 的狀態。

從 Snapshot 到 OS Disk 到 VM

  1. 在 Azure 入口網站中,進入 “快照(Snapshots)” 頁面,選擇您之前建立的快照。
  2. 點擊快照名稱進入詳細資訊頁面,然後選擇 “建立磁碟(Create Disk)”。
  3. 在磁碟配置頁面中,輸入磁碟名稱,並選擇合適的儲存帳戶和資源群組。
  4. 檢查所有設定無誤後,點擊 “建立(Create)” 按鈕,開始將快照轉換為磁碟。
  5. 磁碟建立完成後,進入 “磁碟(Disks)” 頁面,選擇您剛建立的磁碟。  
  6. 在磁碟詳細資訊頁面中,點擊上方的 “建立 VM(Create VM)” 按鈕。
  7. 在虛擬機器配置頁面中,完成其他配置,如名稱、大小、網路設定等,然後點擊 “檢閱 + 建立(Review + create)” 按鈕。  
  8. 檢查所有設定無誤後,點擊 “建立(Create)” 按鈕,開始建立新的虛擬機器。  
  9. 新的虛擬機器建立完成後,登入並驗證其狀態是否與快照拍攝時一致。

  

問題

我發現使用 Security Type 為 Trusted Launch 的 VM 所建立的 Snapshot;  
與其建立的 Disk 與 VM 其 Security Type 也會是 Trusted Launch。  
但是當我嚐試透過 SSH using Azure CLI 連線 VM,
會遇到無法連線的問題,同樣的步驟,Security Type 為 Standard 就不會有問題。  
待確認原因…  

參考

  1. Microsoft 官方文件: 建立和管理虛擬機器磁碟的快照
  2. Azure 入口網站指南
  3. Azure 虛擬機器文檔

(fin)

[生活筆記] 2024 常用工具整理

輸入法

  • 無蝦米 (加速打字,未來不太看好,考慮更換中…)

網站

資訊收集/廢文發佈/社群媒體

觀察名單(待汰換)

  • Slant 工具比較
  • 文字比較工具 - Win Merge(Window限定)
  • Evernote
    • 專案分類
    • 職涯規劃
    • 已完成的項目

Macbook 工具

  • Git GUI
    • Fork
  • KeyCastr
    • 顯示鍵盤點擊歷程
  • 跨 PC 存放檔案
    • Dropbox
  • 截圖錄影工具
    • QuickTime
  • Terminal

筆記工具

  • Notion
    • GTD
    • 周記劃
  • HackMD
    • 暫存的記錄
    • 會議/社群活動即時記錄
    • Blog 草稿
    • 共筆
  • Blog
    • 技術實作記錄
    • 社群活動記錄
  • NotebookLM
    • RAG AI 整合筆記

瀏覽器 & 外掛

都使用 Chromium 內核相關

  • Brave
  • Chrome
  • Edge
  • FireFox
  • Arc 觀察中

Chrome

  • tampermonkey
    • 撰寫網頁小工具
  • One Tab
    • 快速收攏大量分頁,常用在特殊主題搜尋的暫存
  • Trancy
    • 沉浸式翻譯與影片翻譯
  • Bitbucket Diff Tree
    • Bitbucket PR 差異比較
  • JSONView
    • 當 response 為 json 時更為好讀
  • Bitwarden
    • 密碼管理
  • Wappalyzer
    • 分析網站使用的框架與技術
  • cVim
    • 使用 Vim 的習慣操作網頁

開發工具

  • Vim
  • VSCode
  • JetBrain 全系列
  • Docker Desktop

(fin)

[實作筆記] Azure Communication Services email

前情提要

隨著現代企業在數位轉型中的步伐加快,電子郵件仍然是最重要的溝通工具之一。
公司現在的寄信服務採取了一個特別的解決方案,透過 App registrations 進行郵件發送。
實作的細節不展開,但這樣作有幾個問題:

  • App registrations 首次需人工授權取得 refresh_token
  • 有了 refresh_token 仍需交換到 access_token 才能寄信
  • 更新 refresh_token 失敗時,就需要人工重新介入

而 Microsoft Azure 提供了強大的 Email Communication Service,可以幫助企業輕鬆、有效地發送大量電子郵件。
優點有整合簡單、高可擴展、安全性高、可靠性強等等優點…

本篇文章將記錄我如何在 Azure 中實作 Email Communication Service。

實作步驟

  1. 建立 Azure Communication Services 資源
    首先,登入 Azure 入口網站,然後依序進行以下步驟:
    點選「建立資源」按鈕,搜尋並選擇「Communication Services」。
    點選「建立」按鈕,填寫必要的資訊如資源名稱、訂閱和資源群組等。
    選擇地區並設定其餘選項後,點選「檢閱 + 建立」,檢查設定並點選「建立」。

  2. 配置電子郵件通道
    在 Communication Services 資源建立完成後,需要進行電子郵件通道的配置:
    在資源概覽頁面中,找到並點選「Email」。
    點選「新增郵件域」,並按照提示設定 SMTP 資訊及其他相關設定。
    驗證郵件域並完成配置。
    這裡你需要有 domain 管理者的權限,用來在 DNS Records 建立相關的記錄(CNAME、TXT)

  3. 生成 API 金鑰
    接下來,我們需要生成 API 金鑰,以便應用程式能夠通過此金鑰進行認證和發送電子郵件:
    在 Communication Services 資源頁面中,找到並點選「密鑰」。
    點選「生成/管理密鑰」,生成新的 API 金鑰並保存。

  4. 發送電子郵件
    有了 API 金鑰和配置好的電子郵件通道,現在可以使用 Azure 提供的 SDK 或 REST API 發送電子郵件。
    以下範例展示了如何使用 Nodejs 發送郵件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import { EmailClient, type EmailMessage } from '@azure/communication-email'
//...
sendMail = async (req: Request, res: Response): Promise<void> => {
const connectionString = env('COMMUNICATION_SERVICES_CONNECTION_STRING')
const senderAddress = env('EMAIL_SENDER_ADDRESS')
const client = new EmailClient(connectionString)
const { to, subject, html } = req.body
const attachments = (req.files != null)
? (req.files as Express.Multer.File[]).map(file => ({
name: file.originalname,
contentType: file.mimetype,
contentInBase64: file.buffer.toString('base64')
}))
: []
const emailMessage: EmailMessage = {
senderAddress,
content: {
subject,
html
},
attachments,
recipients: {
to: [{ address: to }],
bcc: [{ address: '[email protected]' }]
}
}

const poller = await client.beginSend(emailMessage)
const result = await poller.pollUntilDone()
console.log('result:', result)
res.status(200).json({ message: `Email ${subject} Sent!` })
}

在 Azure Portal 執行整合測試

在 Azure Portal > Communication Service > Email > Try Email,
非常貼心的提供了 C#、JavaScript、Java、Python、cUrl 的範本,
也可以取得連線字串。

使用上限與新增寄件帳號

原則上預設的使用量對開發人員來說,是非常足夠的
但是如果想增加上限,或是新增其它的寄件者帳號,需要開 support ticket 進行升級,
這是為了避免郵件的濫用,另外需新增 MX Record 可以避免當成垃圾郵件。
升級後就可以在 Azure Portal > Email Communication Service > Provision domains > MailFrom addresses
新增寄件者,實際上 Azure Communication Service 只會寄件無法收件,
即使在 O365 有相同的帳號,在寄件備份中也看不到透過 ECS 寄出的郵件。  

小結

實作上比較有風險大概是 DNS Records 的設定,最久大約需等到 1 小時生效。
而開發上非常的容易,甚至程式範例都整合到 Portal,非常方便。  
但是其它方面需要開票等待 Azure 協力升級與設定,就會比較麻煩。  

參考

(fin)

[踩雷筆記] Gitlab CI/CD 與 GCP - 靜態網站部署整合 404 與 `/`

前情提要

最近將公司的所有靜態網站轉換到 GCS 上了,遇到一些情境,特此記錄
這篇會以 Vue 與 Nuxt 的角度出發。
在前後端分離的情況下,SEO 變成一個問題,SSR 可以解決這個問題,
我們可以使用 Nuxt 建立我們的專案,並透過 generate 生成靜態檔案。

再進一步來說,我們可以整合 GCS 進行靜態網站的部署

題外話

Nuxt 的幾種建置方式

  1. npx nuxt build
    The build command creates a .output directory with all your application, server and dependencies ready for production.
    這個命令會建立一個 .output 目錄,裡面包含了你的應用程式、伺服器和所有必要的依賴,準備好用於生產環境。
    預設的行為,可以實作 SSR(Server Side Render),適用有 SEO 需求,且變化快速的網站,Ex: 電商產品頁

  2. npx nuxt build --prerender
    –prerender false Pre-render every route of your application. (note: This is an experimental flag. The behavior might be changed.) .
    –prerender false 會對應用程式的每個路由進行預渲染。(注意:這是一個實驗性的標誌。行為可能會更改。);
    它會先產生好 HTML,適合 SSG 網站(內容不常改動,但有 SEO 需求)。Ex: BLOG

  3. npx nuxt generate

The generate command pre-renders every route of your application and stores the result in plain HTML files that you can deploy on any static hosting services. The command triggers the nuxi build command with the prerender argument set to true
這個命令會對你的應用程式的每個路由進行預渲染,並將結果存儲在普通的 HTML 文件中,你可以部署到任何靜態托管服務上。  
該命令會觸發 nuxi build 命令,並將 prerender 參數設置為 true。
它適合純靜態的網頁(SPA)。Ex: Landing Page. 與前者最大的差異是,前者會建置成不同的 HTML,

問題

當我們在建置好靜態網站並部署到 GCS 上時,我遇到了一個異常的問題,
當我複製貼上網址時會發生 404 Not Found,主因是當我的網址結尾不是/時,
瀏覽器會轉導到 /index.html
舉例說明:

https://marsen.me/sample 複製貼上,會轉導到 https://marsen.me/sample/index.html
而這頁不存在,導致產生 404 的錯誤

解法

採取升級 Nuxt 到 v3.8.0 以上,
這是實驗性的功能,雖然目前有效,仍需觀注未來更新的狀況。
若不打算升級,另外有用 middleware 處理重定向,
可參考此 issue 的討論串,
要寫比較多,而且留言者在部署到 vercel 有遇到其他問題。故採升級的方式解決此題。

參考

(fin)

[實作筆記] 清理 CI/CD (Gitlab-runner)

寫在前面

NM;DR
沒有什麼意義,不需要讀這篇

緣由

  • CI/CD 執行失敗,檢查錯誤發現是 Gitlab-runner[*1] 主機空間不足。

處理歷程

  • 連線 Gitlab-runner 主機
  • 查詢空間使用狀況,找到佔磁區的資料

    marsen@gr00:~$ sudo du -h --max-depth=1 /
    24K /tmp
    0 /sys
    74M /boot
    … skip …
    24K /root
    94G /var
    97G /

  • 用指令作深層的搜尋 sudo du -h --max-depth=3 /var
  • 發現 docker 的問題最大

    252K /var/lib/docker/containers
    4.0K /var/lib/docker/trust
    4.0K /var/lib/docker/runtimes
    91G /var/lib/docker

  • 不選擇清理磁碟,而用 docker 指令檢查 docker images
  • 批次刪除指令 docker images -f "dangling=true" -q | xargs docker rmi
  • 再次檢查

    marsen@gr00:~$ sudo du -h --max-depth=1 /
    24K /tmp
    0 /sys
    74M /boot
    … skip …
    24K /root
    16G /var
    20G /

後續

  • 可能要建立一個排程定期去清理 CI/CD 無用的 image
    • 可以的話想整入 CI/CD 作業中,但在 DinD[*2] 的環境不確定怎麼實作
  • log 與 cache 也有看到較高的資料成長曲線,未來也要納入評估

註解

  1. Gitlab-Runner 是 Gitlab Solution 中執行工作的實體,可以是多台,此案只有單台
  2. Dind: Docker In Docker,如同字面意思,在 Docker 中跑 Docker,是 Gitlab-runner 的實作方法之一

(fin)

[實作筆記] Gitlab CI/CD 與 GCP - Cloud Run 方案選擇過程記錄

前情提介

在我的實務經驗上,很常與新創團隊合作,而架構選擇常常是第一個問題,
最常見的解法是,由技術負責人選擇最熟悉的技術…
這樣真的好嗎?
比如說,T 社早期由某群工程人員開發,
選擇了 Go、Nodejs、C# 等多語言與雲端 GKE(K8S) 作為開發架構,
事後不負責任離職後,對持續的運作與維護都造成了困難
這件事對我的警鐘是 — 作為管理者,如果不具備識別專業的能力,就只能透過信賴某人或團隊;這是非常脆弱且危險的。

執行環境的選擇

作為 Web 開發者,最常用的執行環境由簡入繁如下:

地端到雲端到

  • 開發機就是正式機: 通常只是用來展示,開發者最常這樣作
  • 地端的主機: 沒有技術能力公司,很有可能都是這樣的架構,直接向開發商買主機放機房或是由開發商部署
  • 地端的虛擬機(VM): 會用較高規格的機器部署多台 VM,可以更有效使用資源
  • 雲端的虛擬機(VM): 使用上與上面差不多,但是由大廠來維持高可用性,學習門檻低
  • 雲端的 Server Less: 需要熟悉不同雲的相關產品,算是有點門檻,完成後可以精準控制預算、減少人力成本、透過雲維持高可用性
  • 雲端的 K8s: 門檻較上面更高,也有相同的優點,但是會有更高的可控性,適合有一定使用規模後,需要細部彈性調整資源的公司。
  • 再回地端: 如果規模再繼續成長,雲端的成本變得高不可攀時,或控制力下降,在有一定的技術水準情況下,有的公司會選擇回到地端。參考 37signals 的例子

GCP Cloud Run

回歸本文,我選擇了 GCP Cloud Run,這是一種雲端的 Server Less 的解決方案。
產品的規模沒有大到需要 K8s,團隊成員的具備足夠的能力,
類似的方案還有 Cloud Function,
作為一個 Web API Base 的輕量專案,我評估 Cloud Run 更適合
Cloud Function 較適合 Event Driven 的片段行為
Cloud Run 較適合有點複雜度,但是可以容器化的應用。

相關作業

首先準備好我的程式,這是一個透過 Azure 寄信程式,需要在 Azure Registered APP 設定,
基本的讀取組態、寫 Log 到雲端與錯誤處理(Error Handle)、相依注入與測試等…
其中一個功能需要將 token 存儲在 GCS(gcloud storage) 裡,
並透過 Cloud Scheduler 定期更新,所以需要為其提供必要的權限與帳號(GCP Service Account).

使用 Cloud Run 前,Docker 也是必要的前置知識,
你會需要撰寫 Dockerfile ,並且需要在 GCP 上建立一個 Artifacts Registry
如此一來,就可以透過 Cloud Build 建立並部署 Cloud Run
用 GCP Workload Identity Federation 管理 Service Account
管理的對像有 2 個,CI 的 Service Account 與執行程式的 Cloud Run 的 Service Account.

後續有考慮透過 Cloud Run 提供 Swagger 之類的 API 文檔,但現階段先共享 Postman 資訊處理。

20240427 更新

我的 CI 腳本如下

1
2
3
export CLOUDSDK_AUTH_ACCESS_TOKEN={provider by workload identify federation}
gcloud builds submit --tag your-registry/your-app:latest .
gcloud run services update your-app --image=your-registry/your-app:latest

我的 Gitlab Runner 是透過 GCP 上 A Project 的 VM 建立並註冊的,
而我的 Cloud Run 需要部署並運作在 GCP B Project 上,
預設執行的身份會是 AProj 的 Compute Engine default service account,以下簡稱 A_CE_Account,
CLOUDSDK_AUTH_ACCESS_TOKEN 代表的是 B Project 的 Gitlab Runner Service Account,以下簡稱 B_GR_Service_Account,
另外在運作 B Project 的 Cloud Run 需要的是 B Project 的 Cloud Run Service Account,以下簡稱 B_CR_Service_Account,

Gitlab Runner 在執行時,執行 gcloud auth list 會顯示 A_CE_Account
但是由於有設定 CLOUDSDK_AUTH_ACCESS_TOKEN,所以相關命令的執行身份是 B_GR_Service_Account
這會有足夠的權限執行 gcloud builds submit --tag your-registry/your-app:latest .
但是沒有權限執行 gcloud run services update your-app --image=your-registry/your-app:latest
原因是 Cloud Run 的執行身份是 B_GR_Service_Account
為此,我們需要賦予 B_GR_Service_Account 角色 Service Account User

參考關鍵字

參考

(fin)

[實作筆記] MacBook Terminal 美化與設計

前情提要

參考前文,受同事啟發,改用 zim 取代 oh-my-zsh,
用更高效與精煉的方式設定 terminal 環境,
看看下面的小故事與 Zim 的官網
這就我選擇更換的原因。

小故事

可以參考此文

當前流行的 Zsh 框架有三個主要選項:Oh My Zsh、Prezto 和 Zim。
Oh My Zsh 是最受歡迎的,但因其過於龐大、混亂和性能問題而受到批評。
Prezto 是對其的重大改進,但未被合併回 Oh My Zsh。
而 Zim 是一個從頭重寫的框架,非常快速、高效,並將許多最佳想法結合在一起。
Zim 還提供了各種主題和模塊,並且易於安裝和管理。
這些框架在定製 Zsh 提示符、增加功能和優化性能方面提供了不同的選擇。

Overview

  • 下載與設定 iTerm2
  • 安裝 zim
  • 安裝 powerlevel10k

第一步 下載並安裝 iTerm2

設定 iTerm2 的外觀

  1. 從網站 iTerm2-Color-Schemes (https://github.com/mbadolato/iTerm2-Color-Schemes) 下載你喜歡的配色方案,
  2. 例如 “DimmedMonokai.itermcolors”。
  3. 開啟 iTerm2,點擊菜單欄的 “iTerm2”,選擇 “Preferences”。
  4. 在偏好設定視窗中,選擇 “Profiles” 選項卡,然後選擇你要更改配色方案的會話配置文件。
  5. 在 “Colors” 選項卡下,點擊 “Color Presets” 按鈕,選擇 “Import…”。
  6. 找到剛才下載的配色方案檔案,例如 “DimmedMonokai.itermcolors”,點擊 “Open”。
  7. 選擇 “DimmedMonokai” 作為你的 iTerm2 配色方案。

import .itemcolors

Profiles 裡有更多的設定, 字型、顏色
比如說, 調整啟始視窗大小與背景透明度, 可以前往 Windows 進行設定.
更多的細部設定可以自行摸索.  
記得重新載入才能看到效果

第二步, 安裝 zim

1
curl -fsSL https://raw.githubusercontent.com/zimfw/install/master/install.zsh | zsh

即可完成安裝,並預設定一些相當實用的模組,可以參考

設定

一般來說不需要這些額外的設定,我的情況是同時需要移除 oh-my-zsh 才會有額外的項目需要進行
進入 ~/.zshrc 修改

一、刪除 oh-my-zsh 的區塊
常用的一些工具,都被整合在 zim 之中了
例如 zsh-syntax-highlighting 原本在 zshrc 的設定如下
現在都可以全數刪除

1
2
3
4
5
6
7
8
9
10
11
12
13
# Install zsh-syntax-highlighting if it's not installed
if [ ! -d ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting ]; then
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
fi

# Load zsh-syntax-highlighting plugin
plugins+=(zsh-syntax-highlighting)

# Set name of the theme to load --- if set to "random", it will
# load a random theme each time oh-my-zsh is loaded, in which case,
# to know which specific one was loaded, run: echo $RANDOM_THEME
# See https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
ZSH_THEME="powerlevel10k/powerlevel10k"

由於zim本身就有包含 zsh-syntax-highlighting,
所以其它相關的設定不會有問題。
例如:

1
2
3
4
ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE='fg=177'
ZSH_HIGHLIGHT_HIGHLIGHTERS=(main brackets)
typeset -A ZSH_HIGHLIGHT_STYLES
ZSH_HIGHLIGHT_STYLES[comment]='fg=242'

Prompt 設定

Prompt 主要影響 terminal 的外觀,
一般來說社群主流會推薦的 Powerlevel10k 後面會提供實作步驟,
但是 zim 已經提供足夠的 theme作選擇,
下面選用 minimal (zim 提供的輕量版主題)作範例  
我們可以修改 ~/.zimrc 即可完成設定

1
2
# A heavily reduced, ASCII-only version of the Spaceship and Starship prompts.
zmodule minimal

安裝 Powerlevel10k

不過 zim 一樣可以使用 Powerlevel10k
前往 Powerlevel10k
我們使用 zim 的方式安裝

修改 ~/.zimrc

1
zmodule romkatv/powerlevel10k --use degit

後執行 zimfw install

之後重啟 iTerm2 將會有一連串設定問題, 依照喜歡的設定即可,
可以參考這個影片,
如果設定完後不喜歡, 可以執行 p10k configure 重新設定
比較一下,效果我覺得都不錯

爆
爆

參考

(fin)

[學習筆記] TypeScript 的 Using 與 Symbol.dispose

介紹

TypeScript 在 5.2 引入了一個新關鍵字 using - 可用於在離開作用域時使用 Symbol.dispose 函數處理任何內容。

看一下官方的說明

TypeScript 5.2 introduces support for the forthcoming Explicit Resource Management feature in ECMAScript,
which aims to address the need for “cleaning up” after creating an object.
This feature allows developers to perform necessary actions such as closing network connections,
deleting temporary files, or releasing memory.

usingawait 的目的在於釋放資源上會非常有用。

在舉例子之前先看一下新的全域 Symbol:Symbol.disposeSymbol.asyncDispose,
任何將函數分配給 Symbol.dispose 的物件都將被視為「資源」(“具有特定存留期的物件”),並且可以與 using 關鍵字一起使用。

舉例來說:

1
2
3
4
5
6
7
8
9
10
11
{
const getResource = () => {
return {
[Symbol.dispose]: () => {
console.log('Hooray!')
}
}
}

using resource = getResource();
} // 'Hooray!' logged to console

當程式離開 resource 所在的 scope 後,就會觸發 Symbol.dispose 的 function

應用

比較常見的場景在於存取 DB、File System 等…
我們現在的作法需要用 try...finally 進行處理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
export function processFile(path: string) {
const file = fs.openSync(path, "w+");

try {
// use file...

if (someCondition()) {
// do some more work...
return;
}
}
finally {
// Close the file and delete it.
fs.closeSync(file);
fs.unlinkSync(path);
}
}

而改用 using 後可以變得如此簡單

1
2
3
4
5
6
7
8
9
10
export function processFile(path: string) {
using file = new TempFile(path);

// use file...

if (someCondition()) {
// do some more work...
return;
}
}

參考

(fin)

[實作筆記] Gitlab CI/CD 與 GCP - Workload Identity Federation

前情提介

現況用 Service Account 會有什麼問題?
當我們希望與第三方的服務與 GCP 作整合時,
傳統的(我之前的)作法是透過建立 Service Account Key 去提供給第三方資源存取的權限。
這會產生資安隱患,主要是這把 Key 的權粒度大難以稽核,有效期長風險,
而要定期更換 Key 會變成一個麻煩的管理問題。

需求介紹

我目前透過 GCS 並掛載 Load Balancing 部署靜態網站,
而 CI/CD 是透過 Service Account 的 Key 去執行工作,
這是一種有資安隱憂的作法,所以我試著使用 Workload Identity Federation 取代

概念

TLDR;

而 Workload Identity Federation 是基於 IAM 機制,允許第三方服務整合 GCP 資源,
背後的技術原理是基於 OIDC, 在這裡我們不過度展開,簡單描述如下:

  1. Gitlab CI/CD 首先取 Gitlab OIDC Token,取得 Token 的作法可以參考官方文件,下面是個簡單的範例:
1
2
3
4
5
6
7
8
9
10

job_with_id_tokens:
id_tokens:
FIRST_ID_TOKEN:
aud: https://first.service.com
SECOND_ID_TOKEN:
aud: https://second.service.com
script:
- first-service-authentication-script.sh $FIRST_ID_TOKEN
- second-service-authentication-script.sh $SECOND_ID_TOKEN

|OIDC 是基於 Oauth2 的標準,簡單可以想成 Oauth2 再加上身份驗証。
2. 有了 Gitlab OIDC Token,我們可以透過 GOOGLE STS(Security Token Service) API 取得 Federated Token
在這裡我們需要先建立好 Workload Identity Provider(IdP),而可以設定 Attribute Conditions 來作限制
3. 這個時候可以用 Federated Token 與 GCP IAM API 交換來一個短周期的 Access Token
4. 本質上還是用 Service Account 在作事,但是用短周期的 Access Token 取代 Key, 從而簡化了 Key 的管理工作

實作步驟

  1. 建立 Workload Identity Pool

    1
    2
    3
    4
    5
    6
    #Update $GCP_PROJECT_ID value
    gcloud iam workload-identity-pools create gitlab-test-wip \
    --location="global" \
    --description="Gitlab demo workload Identity pool" \
    --display-name="gitlab-test-wip" \
    --project=$GCP_PROJECT_ID
  2. 設定 workload identity pool provider 並建立 Attribute conditions,
    這步的關鍵是讓只符合你條件設定的 User 才能取得 Token

    1
    2
    3
    4
    5
    6
    7
    8
    9
    #Update GITLAB_NAMESPACE_PATH value
    gcloud iam workload-identity-pools providers create-oidc gitlab-identity-provider --location="global" \
    --workload-identity-pool="gitlab-test-wip" \
    --issuer-uri="https://gitlab.com" \
    --allowed-audiences=https://gitlab.com \
    --attribute-mapping="google.subject=assertion.sub,attribute.aud=assertion.aud,attribute.project_path=assertion.project_path,attribute.project_id=assertion.project_id,attribute.namespace_id=assertion.namespace_id,attribute.namespace_path=assertion.namespace_path,attribute.user_email=assertion.user_email,attribute.ref=assertion.ref,attribute.ref_type=assertion.ref_type" \
    #--attribute-condition="assertion.namespace_path.startsWith(\"$GITLAB_NAMESPACE_PATH\")" \
    --attribute-condition="assertion.namespace_path.startsWith(\"marsen\")" \
    --project=$GCP_PROJECT_ID
  3. 建立 GCP Service Account
    在我的例子中

    1
    2
    3
    4
    5
    6
    7
    #Create a service account
    gcloud iam service-accounts create gitlab-runner-sa --project=$GCP_PROJECT_ID

    #Add sample permissions to the Service account
    gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member=serviceAccount:gitlab-wif-demo@${GCP_PROJECT_ID}.iam.gserviceaccount.com \
    --role=roles/storage.admin
  4. 建立 Service Account 與 WIP 的角色關係綁定

    可以先取得專案的 GCP Project Id

    1
    PROJECT_NUMBER=$(gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\) --project $GCP_PROJECT_ID)

    設定 Service Account 的角色為 workloadIdentityUser,並將其設定為 workloadIdentityPools 的服務帳戶

    1
    2
    3
    gcloud iam service-accounts add-iam-policy-binding gitlab-runner-sa@${GCP_PROJECT_ID}.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/gitlab-test-wip/*"
  5. 建立 Gitlab CI/CD 進行測試

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
image: node:20.9.0-alpine

.gcp_wif_auth: &gcp_wif_auth
#id_tokens to create JSON web tokens (JWT) to authenticate with third party services.This replaces the CI_JOB_JWT_V2
id_tokens:
GITLAB_OIDC_TOKEN:
aud: https://gitlab.com
before_script:
- apt-get update && apt-get install -yq jq
#Get temporary credentials using the ID token
- |
PAYLOAD=$(cat <<EOF
{
"audience": "//iam.googleapis.com/${GCP_WORKLOAD_IDENTITY_PROVIDER}",
"grantType": "urn:ietf:params:oauth:grant-type:token-exchange",
"requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
"scope": "https://www.googleapis.com/auth/cloud-platform",
"subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
"subjectToken": "${GITLAB_OIDC_TOKEN}"
}
EOF
)
- |
echo "Payload: ${PAYLOAD}"
- |
FEDERATED_TOKEN=$(curl -s -X POST "https://sts.googleapis.com/v1/token" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data "${PAYLOAD}" \
| jq -r '.access_token'
)
#- |
# echo "Federated Token: ${FEDERATED_TOKEN}"
#Use the federated token to impersonate the service account linked to workload identity pool
#The resulting access token is stored in CLOUDSDK_AUTH_ACCESS_TOKEN environment variable and this will be passed to the gcloud CLI
- |
WHAT_IT_IS=$(curl -s -X POST "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${SERVICE_ACCOUNT_EMAIL}:generateAccessToken" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer ${FEDERATED_TOKEN}" \
--data '{"scope": ["https://www.googleapis.com/auth/cloud-platform"]}' \
| jq -r '.'
)
- |
echo "WHAT_IT_IS: ${WHAT_IT_IS}"
- |
export CLOUDSDK_AUTH_ACCESS_TOKEN=$(curl -s -X POST "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${SERVICE_ACCOUNT_EMAIL}:generateAccessToken" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer ${FEDERATED_TOKEN}" \
--data '{"scope": ["https://www.googleapis.com/auth/cloud-platform"]}' \
| jq -r '.accessToken'
)

stages:
- deploy-prod

deploy-prod:
variables:
GCP_PROJECT_NAME: my-project-9527
GCP_WORKLOAD_IDENTITY_PROVIDER: "projects/000009527/locations/global/workloadIdentityPools/gitlab-test-wip/providers/gitlab-identity-provider"
SERVICE_ACCOUNT_EMAIL: "[email protected]"
<<: *gcp_wif_auth
stage: deploy-prod
image: google/cloud-sdk:latest
script:
- echo "Deploying artifacts to PROD GCS🚀🚀🚀"
- echo $CLOUDSDK_AUTH_ACCESS_TOKEN
- gcloud config set project ${GCP_PROJECT_NAME}
- gcloud storage cp -r $CI_PROJECT_DIR/dist/* gs://my-static-website/

參考

(fin)

Please enable JavaScript to view the LikeCoin. :P