網頁

2023年2月15日 星期三

[野人獻曝] 開個 Stable Diffusion WebUI 的懶人包

前篇提到 Stable Diffusion WebUI,
這次要利用 Google Colab 服務來跑這玩意。

主要流程其實很簡單:

如果還沒有下載模型檔的話,
請先打開主要作業的區塊執行開啟 Google Drive 的權限,
然後再到第三個大區塊中的下載輸入模型檔下載路徑,
下載完成後就可以開始下載 Stable Diffusion WebUI 並準備執行。

如果已經執行過下載模型的話,
可以直接按下主要作業那個大區塊中的執行即可。

當不想玩了以後,請記得按下第二個大區塊的執行。
這個步驟會把該次產生的圖片存回到 Google Drive 內。

網址:https://colab.research.google.com/drive/1irIstg03GHVtXJLVhYLOtNuUy3z7ELz_?usp=sharing


2023年2月12日 星期日

[野人獻曝] 架個 Stable Diffusion WebUI 來生個香香的老婆圖

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.txt" python launch.py

接下來就是發揮你的想像力開始產生圖片了(茶 

2022年3月19日 星期六

[野人獻曝] Google App Engine ...... 的踩雷

最近因為要把用 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 運作,
在只是實驗的狀況下可能會莫名噴出一堆成本。

參考文件:

2021年12月5日 星期日

[野人獻曝] 關於建立 AWS 服務架構的工具

通常為了要達成 IaC 的目標,
架構師還是 DevOps 工程師都會用很多工具來達成目標。
而比較通用的工具大概會是 Terraform / Ansible 之類的。

不過實際狀況是因為 AWS 服務眾多反而是使用 AWS 自家工具來做還比較方便。

所以用個表格來比較:

比較表
AWS CDK / CDK For Terraform GoFormation 原生 CloudFormation JSON / YAML
優勢
  • 較為高階,有些細節不用特別處理(例如建立 Subnet 不用自己額外寫 RouteTable 那些東西)
  • 跟程式語言結合,使用起來比較可讀好懂
  • 跟 Terraform 結合的話要學的東西相對比較少一點
  • 最接近原生 JSON / YAML 寫法,但又擁有建立每個資源時很快就可以知道要丟什麼東西進去的優勢
  • 跟程式語言結合,可以做一些靈活變化
  • 原生寫法不解釋
  • 如果有新東西的話通常會第一支援
弱勢
  • 因為太高階,比較細項的修改反而變得很麻煩
  • 老實說,我覺得好像沒什麼弱勢!大概只有部分函式不能用還有需要產生檔案比較麻煩一點
  • 很低階,所以在寫的時候要搭配文件才能知道需要丟什麼東西進去
  • 一不小心會寫出上千行的檔案,也會不小心改錯項目出包

2021年12月4日 星期六

[野人獻曝] AWS Certified Solutions Architect 認證考試心得

大概是去年聖誕節前夕,
不知道被什麼打到,
突然想考一張 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 / IAM / S3 / EC2 等基本甚至比較進階的東西後,
再搭配一些考古題和概念補強後再去考 Associate 會比較保險一點!

如果沒自信的話可以買官方出的練習考試(Associate 20 鎂,Professional 40 鎂),
題目數是正式考試的三分之一左右,
但是出題方向和概念跟正式考試無異,
考完也會出現成績和提示你需要加強的領域,
對於增加通過考試的信仰是個不錯的選項!

另外由於題目是單選搭配多選的方式出題,
所以真的不知道的話就每個選項仔細看清楚後採取排除法會對回答比較有幫助。
只是要注意一下不要在不確定答案的問題浪費時間,
可以選擇標記後繼續作下一題,
全部做完後會出現檢查畫面,
可以在那邊再次檢查確認問題答案。

====== 再次聲明 =====

千萬不要以為 Professional 好像很帥氣就直接跳過 Associate 去考,
畢竟一場考試可是要 300 鎂喔,
考不過的話那可是當場八千多新台票就掰掰!
如果不是我有之前考過 Associate 級送的半價券,
我搞不好也不會特別去考這個 Professional !

2021年5月20日 星期四

[野人獻曝] AWS CDK8S 初步使用筆記

說到 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 上。

感想

老實說,這其實是個還蠻方便的玩意,
除了常用的一堆元件外,
也可以針對各種少見但就是會用到的元件寫自己的宣告(?),
下次要寫的時候可以提示哪些參數是必須或是該填些什麼,
能夠省下每次翻文件的時間。



2021年4月21日 星期三

[野人獻曝] AWS Go CDK 初步使用筆記

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 操作重複類型資源的狀況下使用,
只需要帶入模板檔路徑與該模板所需參數即可建立相應資源;
後者則偏向懶人包,
可以在建立資源時一併設定其他相依資源的屬性以便一起建立,
如果未設定的狀況下也會以預設的屬性直接建立。