打造最小 Python Docker 容器

cover

現在已經是容器 (container) 的時代,團隊之間合作肯定要打包統一的 Docker Image 來解決環境不一致的問題,但是容器的大小決定了部署微服務的時間,本篇來介紹如何打造最小的 Python 容器。如果你需要跨部門合作,Docker 絕對是最棒的工具,讓大家不用為了環境煩惱。底下透過 Flask Application 來介紹如何撰寫 Dockerfile

[Read More]

AI 團隊整合導入 AWS SageMaker 流程

Flow

團隊困境

如果團隊未來想把機器學習推廣成一個服務,可以讓開發者帶入不同的參數進行客製化的學習,最終拿到學習過的 Model。或是團隊資源不夠,想要使用大量的 GPU 資源來加速 AI Model Training,這時就是要朝向使用第三方資源像是 AWS SageMaker 來進行整合。而在團隊內會分成機器學習團隊,及後端團隊,前者是專門進行資料分析及 AI Model 演算法及程式碼開發,後者則是專攻全部工作流程,從產生測試資料,前置準備,到 Training Model,及將產生的結果發送給開法者,這整段流程會由後端團隊進行串接。所以當我們要用第三方服務時 AWS SageMaker,對於機器學習團隊來說,要將整個環境打包成容器模式,並且符合 SageMaker 所規定的格式,過程相當複雜,而為了讓開發環境統一,我們使用了容器技術 (Docker Container) 來進行 SageMaker 串接,本篇會教大家如何整合 SageMaker 流程,讓機器學習團隊可以專注於 Model 流程開發,而不需要花時間在整合容器技術並符合 SageMaker 格式。

[Read More]

用 docker-compose 優雅關閉服務

logo

大家應該遇過如果服務還有工作還沒處理完,服務要進行更新,需要等到全部工作處理完成才可以將服務的停止,而當服務收到關閉通知信號時,第一要先停止接受 Job 任務,接著等待 Worker 將手上 Job 處理完畢後,才停止服務,接著更新再上線。而這狀況怎麼透過 docker-compose 來處理停止服務,這就是本篇的重點。文章內會用 Go 語言當教學範例,如何接受 Docker 傳來的 Signal 訊號,接受訊號後該如何處理,及如何設定 docker-compose 的 YAML 檔案確保所有的工作都可以正常執行完畢。

之前已經有寫過幾篇關於 Graceful Shutdown 教學文章,大家有興趣可以先閱讀底下教學連結資訊,而本篇最主要是紀錄在如何用 docker 指令優雅關閉容器服務,尤其是關閉服務前,可以讓原本服務內的工作可以正常做完,才正式關閉。在本文開始前,先將 dockerdocker-compose 版本資訊貼出來,避免有資訊的落差,畢竟 docker-compose 在不同版本之間有不同的設定方式。

[Read More]

Go 語言內 new 跟 make 使用時機

logo

大家接觸 Go 語言肯定對 newmake 不陌生,但是什麼時候要使用 new 什麼時候用 make,也許是很多剛入門的開發者比較不懂,本篇就簡單筆記 newmake 的差異及使用時機。

[Read More]

如何取得上傳進度條 progress bar 相關數據及實作 Graceful Shutdown

由於專案需求,需要開發一套 CLI 工具,讓 User 可以透過 CLI 上傳大檔案來進行 Model Training,請參考上面的流程圖。首先第一步驟會先跟 API Server 驗證使用者,驗證完畢就開始上傳資料到 AWS S3 或其他 Storage 空間,除了上傳過程需要在 CLI 顯示目前進度,另外也需要將目前上傳的進度 (速度, 進度及剩餘時間) 都上傳到 API Server,最後在 Web UI 介面透過 GraphQL Subscription 讓使用者可以即時看到上傳進度數據。

而 CLI 上傳進度部分,我們選用了一套開源套件 cheggaaa/pb,相信有在寫 Go 語言都並不會陌生。而此套件雖然可以幫助在 Terminal 顯示進度條,但是有些接口是沒有提供的,像是即時速度,上傳進度及剩餘時間。本篇教大家如何實作這些數據,及分享過程會遇到相關問題。

[Read More]

MongoDB 效能調校紀錄

mongodb

最近剛好在實作 Prometheus + Grafana 的時候,對 MongoDB 做了容器 CPU 使用率 (container_cpu_usage_seconds_total) 的監控,Metrics 寫法如下:

1
2
3
sum(
    rate(container_cpu_usage_seconds_total{name!~"(^$|^0_.*)"}[1m]))
by (name)

從上面的 Metrics 可以拉長時間來看,會發現專案的 MongoDB 非常不穩定,起起伏伏,這時候就需要來看看資料庫到底哪邊慢,以及看看哪個語法造成 CPU 飆高?

接著為了看 MongoDB 的 Log 紀錄,把 Grafana 推出的 Loki,也導入專案系統,將容器所有的 Log 都導向 Loki,底下可以看看 docker-compose 將 Log 輸出到 loki

1
2
3
4
5
6
7
    logging:
      driver: loki
      options:
        loki-url: "http://xxxxxxx/loki/api/v1/push"
        loki-retries: "5"
        loki-batch-size: "400"
        loki-external-labels: "environment=production,project=mongo"

先看看結論,做法其實很簡單,找出相對應 Slow Query,把相關的欄位加上 Index,就可以解決了

[Read More]

使用 RESTful API 串接 Open Policy Agent

Open Policy Agent

上一篇『初探 Open Policy Agent 實作 RBAC (Role-based access control) 權限控管』介紹了如何透過 Go 語言直接嵌入 Open Policy Agent (簡稱 OPA)設定檔,並透過 Go 套件直接查詢使用者權限。由於目前 OPA 只有支援三種模式串接各種不同的 Application,一種是透過 Go 語言直接整合,詳細請看上一篇教學,另一種是透過 RESTful API,也就是本篇的教學,最後一種是透過 WebAssembly 讓其他 application 可以直接讀取。之後有機會再來寫 WebAssembly 教學。而本篇將帶您了解如何透過 RESTful API 方式來完成 RBAC 權限控管,其實我比較期待支援 gRPC 模式,但是看到這篇 issue 提到,OPA 現在已經支援 Plugin 模式,大家想擴充的,可以自行處理。

[Read More]

初探 Open Policy Agent 實作 RBAC (Role-based access control) 權限控管

Open Policy Agent

最近公司內部多個專案都需要用到 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實現的。

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

[Read More]

為什麼 signal.Notify 要使用 buffered channel

golang logo

如果不了解什麼是 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。那為什麼會有這段說明呢?底下用其他例子來看看。

[Read More]