iT邦幫忙

2024 iThome 鐵人賽

DAY 20
0

颱風結束,開工回來重新對了需求,有些細節果然還是要跟成員對過,要不是颱風放假,下次可能會研究完大概就會先對需求是否符合。

需求跟昨天考慮的差不多,但有些東西要調整。當 Backend 開了 VM 及對應的 Jupyter Container 給 DS 開發,DS 除了改 Code,還會進行”環境的變動”,像是 Apt-get install 等操作。Code 的變動可以用 Git 抓,但是環境的變動無法,過去的方法是請 Backend 直接在環境上進行 Code Review 及調整接口,並直接使用 Docker commit 建立新的 image 並且讓 Prod 使用。但這樣有一個缺點,是舊的 Dockfile 會一直在舊的版本,且 Code 不是經過 Code Review 過後上版的,導致後端的工非常多。另外,此專案更改頻率不高,基本上是從每月的準確度來觀察,如果有往下掉才要進行調整。

針對這題,我們會進行幾個更改點

DS

  1. 針對環境的改變,改成使用 sh file 調整

  2. 讓 VM 改成用 workbench

  3. git commit 會需要有特定標準

BE

  1. 調整直接使用 predict.py 進行操作。這段會直接由 eventarc trigger GKE JOB。如此 BE 就不用調整接口。這段要研究一下 GCP batch,或是採用接 cloud function 再打 job(如果 cloud run GPU 有支援台灣 region 就簡單多了,可惡)

  2. 打包 image 的時候,環境安裝從 dockerfile 直接撰寫,改成引用 sh file。

  3. 將 Deployment 改為 Gitlab runner 打包及部署

其實關於 VM 上 DS 直接改環境的解法我不是很確定這樣是否為最佳解,但目前想到的解法就是這樣了。接下來我會進行 eventarc trigger GKE JOB 的 PoC。發現花了很多時間還在調整預期的結構,有點體會到之前有 DevOps 大神說的所謂的 DevOps 就是好好的把東西改順改好就是好的做法了。

https://ithelp.ithome.com.tw/upload/images/20241004/20118525Di121jNHwV.png


上一篇
颱風天 從頭跑一次流程
下一篇
PoC
系列文
從 AWS 轉生到 GCP 世界,還順便轉職成 DevOps 的 SRE30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言