Faryne的程式設計館

A.I. 當道後， 什麼以文生文、以文生圖、以文生聲（？）等玩意陸續蹦出來。 別的先不說， 光是以文生圖就有像是 MidJourney 還是 Dall-E 等模型提供相關服務。 而後 NovelAI 自爆自己的以文生圖模型是透過 Danbooru 上收集的圖片所訓練， 外加相關程式碼也不小心外洩後， 你各位紳士們就開始在以文生圖這塊領域中尋找自己的婆了。 不過以上都不是重點， 本文只是想要記錄下 Stable Diffusion WebUI （以下簡稱 SDWebUI）的架設步驟而已。 其實安裝步驟出乎意料的簡單（當然是指在 Google CoLab 上）， 只要以下幾個步驟，基本上就能把 SDWebUI 跑起來並且開始生圖： * 確保機器上有 Python 3 以上環境 * 下載 SDWebUI 原始碼，可以直接在 Github 上 clone 下來。 * 下載所需的模型：在產生 ACG 相關圖片的話，目前推薦使用 Anything 或是 Hentai Diffusion 等模型。不過要注意一點：模型檔案越大的話，硬體要求會更高（主要是顯卡的 GPU 和記憶體等級）。如果沒滿足需求的話可能會跑不起來 * 切換到 SDWebUI 目錄，執行以下指令開始跑 SDWebUI 的設定，會在這個步驟安裝其相依的 Python 套件並處理相關設定： COMMANDLINE_ARGS="--exit" REQS_FILE="requirements.txt" python launch.py *  把前面步驟所下載的模型檔案，搬移到 SDWebUI檔案目錄/models，例如 clone 到 /home/user/stable-diffusion-webui 的話，就把模型檔複製到 /home/user/stable-diffusion-webui/models 下。 * 執行以下指令，等待跑完以後，畫面應該會顯示一組 xxx.gradio.xxx 的網址，可以讓自己或朋友連進來玩（網址 72 小時內有效）。如果只是自用的話，也可以用 localhost 的網址開啟服務： COMMANDLINE_ARGS="--share --gradio-debug" REQS_FILE="requirements.

最近因為要把用 Go 寫的一些 API 搬到專用平台跑又不想花錢， 想到 App Engine 有免費方案， 所以看了一下就先搬一兩隻進去跑了一個禮拜後， 昨天好奇瞄了一下帳單後大吃一斤， 發現才跑一個星期就有 16 鎂的帳單！ 再仔細翻一下文件發現這其中的奧秘...... App Engine 分成兩種運作環境， 一為標準，另一個則為彈性。 前者有提供免費方案，依照選擇的類型不同，可能會有一天 28 或 9 個的免費時數可用； 後者完全沒有免費方案，一開下去就立刻算錢。 而我用的正是彈性，所以一開下去就馬上燒錢 Orz 話說回來了，到底標準和彈性環境有什麼差別？ 標準環境的特色： 使用的程式語言版本基本按照 App Engine 要求。以 Go 為例，他該死的就只支援到 1.16 ，想用 1.17 以上的版本，你只能使用彈性環境。 有免費方案（不是重點 運作系統規格只有籠統的 F1 / B1 這種讓你選，就算想要記憶體多一點你也只能選更高的等級。 AutoScaling 只能設定標準由 App Engine 自行控制 想在運作環境裝一些額外的東西嘛......應該是不行。 彈性環境的特色： 可以自己寫 Dockerfile ，所以要什麼東西用什麼語言環境，你自己決定 沒有免費方案（依然不是重點 運作所需的 CPU 核心和記憶體數量可以自訂，只要符合基本要求即可 AutoScaling 機制可以手動也可以自動控制 可以 SSH 登入，想查什麼東西還蠻方便的說 所以你知道為什麼彈性環境沒有免費方案了吧（眼神死 ====================== 不過根據使用和昨天翻文件下來， 我覺得 App Engine 彈性環境遠比 AWS 的 ECS Fargate 更懶人包。 前者只需要專注在程式撰寫和設定所需運作的環境，基本上沒什麼事要做了； 但後者除了上述的東西外， 還需要自己設定從 VPC / Security Group / Load Balancer 等一狗票東西， 老實說還挺麻煩的。 ====================== 不過地雷還是有， 在寫 App Engine 的 app.yaml （運作環境設定檔）時， 關於 auto_scaling 的相關設定必須要特別注意， 如果沒特別宣告的話， 會讓你的服務可能一開始就開出兩個 instance 運作

通常為了要達成 IaC 的目標， 架構師還是 DevOps 工程師都會用很多工具來達成目標。 而比較通用的工具大概會是 Terraform / Ansible 之類的。 不過實際狀況是因為 AWS 服務眾多反而是使用 AWS 自家工具來做還比較方便。 所以用個表格來比較： 比較表 AWS CDK / CDK For Terraform GoFormation 原生 CloudFormation JSON / YAML 優勢 較為高階，有些細節不用特別處理（例如建立 Subnet 不用自己額外寫 RouteTable 那些東西） 跟程式語言結合，使用起來比較可讀好懂 跟 Terraform 結合的話要學的東西相對比較少一點 最接近原生 JSON / YAML 寫法，但又擁有建立每個資源時很快就可以知道要丟什麼東西進去的優勢 跟程式語言結合，可以做一些靈活變化 原生寫法不解釋 如果有新東西的話通常會第一支援 弱勢 因為太高階，比較細項的修改反而變得很麻煩 老實說，我覺得好像沒什麼弱勢！大概只有部分函式不能用還有需要產生檔案比較麻煩一點 很低階，所以在寫的時候要搭配文件才能知道需要丟什麼東西進去 一不小心會寫出上千行的檔案，也會不小心改錯項目出包

大概是去年聖誕節前夕， 不知道被什麼打到， 突然想考一張 AWS 認證考試， 所以就很突然地報了 AWS Certified Solutions Architect - Associate 的考試！ 為了那場考試我還買了對岸出的翻譯教科書（ 原文版 、 簡體版 ）讀。 只是......因為我真的很不會讀書， 外加我上班真的超懶， 那本書我只看了前面幾章， 然後隨便做了書內的練習題和 Google 到的考古題， 就直接上場考試了！ 雖然是很有驚無險地通過了啦（720 分通過，我考 761 分）..... 然後今年十一月左右也是因為很突然就離職， 所以也是很突然就決定再去報 AWS Certified Solutions Architect - Professional 的考試！ 這次考試比之前稍微認真一點， 除了把那本教科書的後面幾章......的練習題重做外， 也開始狂 K 官方的訓練課程， 外加又多冥想了各種考題方向， 也順便自己開了一些不常用的服務練習（估計帳單也......）， 大概是花了一個星期時間專心（？）準備！ 這次也依然是很驚險地通過（750 分通過，我考 797 分） ====== 以上都是廢話 ===== 其實我去年考的時候還不知道認證架構師是最難的考試， 不過考完架構師考試後， 其實就會理解到 AWS 認證架構師就某種程度是最了解 AWS 架構的人， 如果一間公司全部使用 AWS 服務的話， 這傢伙應該就是部門的 Center ！ 只是有沒有必要考到 Professional 等級就因人而異啦， 畢竟 Professional 級的考題很刁鑽， 遠比 Associate 級更為刁鑽， 除了出現一堆你壓根沒聽過的 AWS 服務外（我看到考題才知道有 EFA 這玩意）， 還需要你從安全面、成本面、可維護性去思考架構該怎麼設計（其實 Professional 級這幾個面向的考題遠比 Associate 多）， 這就很吃使用經驗和你有沒有想過最佳實踐。 如果是半吊子以為只是比 Associate 難一點點就上場去考的話， 保證很容易就會 GG ！ 再次聲明：我真的只是好運考過的 QQ ====== 怎麼準備 ===== 其實不是很建議無謀地只讀教科書就去考！ 最好是先有一段時間的 AWS 操作經驗， 至少要理解 VPC / SecurityGroup

說到 K8S 喔，就不得不提到那精美的 YAML ， 當你想佈個 Service / Deployment 時， 可能會因為你常打還知道怎麼打出來！ 一旦你要用的元件是不常用的時候， 你應該會很幹的去翻 K8S 官網文件查！ （就跟我之前為了要寫 AWS Cloudformation 時還要翻那該死的文件一樣） 因此 AWS 推出 CDK8S ， 讓你開發時比較不需要花太多時間翻文件！ CDK8S 目前支援 TypeScript / Python / Java， 不過這裡直接用 TypeScript 做個說明好了。 安裝 CDK8S 工具 npm install -g cdk8s-cli 建立新專案 mkdir /helloworld cd /helloworld cdk8s init typescript-app 開始開發 打開專案的 main.ts ，那就是開發的起點了！ 部署 雖然一般都會直覺想到用 npm run build ， 但是實際上這會跑 compile / test / generate yaml 三個動作。 在還沒有寫測試之前，建議直接跑 npm run compile && npm run synth ， 這樣就能直接產生 K8S 所需要的 YAML（在 dist/ 目錄內） 接著輸入 kubectl apply -f dist/* 就可以開始部署到你的 K8S Cluster 上。 感想 老實說，這其實是個還蠻方便的玩意， 除了常用的一堆元件外， 也可以針對各種少見但就是會用到的元件寫自己的宣告（？）， 下次要寫的時候可以提示哪些參數是必須或是該填些什麼， 能夠省下每次翻文件的時間。

AWS 之前推出了 Cloud Development Kit （CDK） 工具， 讓以前寫 YAML 透過 CloudFormation 建立資源的麻煩和不便減少許多， 只是彼時只支援 C#、Java、JavaScript / TypeScript 以及 Python。 不過最近開始支援 Go 了， 所以我就來稍微試用一下！ 為了要使用 CDK Go， 必須確認開發機器上是否有以下工具： aws-cdk ：CDK 工具，可以透過這個工具進行建立新專案 / 部署等動作，最新版本： 1.100.0。 Go ：由於 CDK 會使用到 Go 內建的 embed 套件，所以版本必須為 1.16.x 以上 aws-cdk-go ：CDK 的 Go 函式庫，目前還在 preview 階段，最新版本是：1.100.0 以上工具安裝完後，即可開始建立新專案。 建立新專案 建立一個目錄後並切換到該目錄， 接著輸入： cdk init --language go  然後就會在該目錄下建立出相關的專案檔 開發 使用你習慣的 IDE，打開以該目錄為檔名的 .go 檔， 你所有需要的程式碼即會集中在這裡。 部署 輸入以下指令即可開始部署作業： cdk deploy 輸入以下指令則可以確認這次修改後會有什麼樣的資源變動 cdk diff 輸入以下指令則可以刪除 cdk destroy 注意事項  CDK 有兩種類型的物件： awscdk.NewCfn* 和 awscdk.New* ， 前者是為了仍在使用 YAML 操作重複類型資源的狀況下使用， 只需要帶入模板檔路徑與該模板所需參數即可建立相應資源； 後者則偏向懶人包， 可以在建立資源時一併設定其他相依資源的屬性以便一起建立， 如果未設定的狀況下也會以預設的屬性直接建立。