潮流特區

焦點文章

CyberCom3合1充電數據線 — 一條線搞掂晒,充電超方便!

科技新知
Lifemagtechie・2025-06-12

而家大家手上嘅電子產品多到數唔清,手機、平板、藍牙耳機、遊戲機……每部機都有自己嘅充電線,仲有啲好舊款用USB,iPhone用Lightning,最新又係Type-C,搞到充電時成日手忙腳亂,尤其去旅行,帶幾多條線都唔夠! 呢條 CyberCom3合1充電數據線,就係為咗解決呢個煩惱而生。佢集合多種接口於一身,無論你係用緊iPhone定Android,甚至其他電子裝置,都可以用一條線搞掂晒,方便又慳位,真係你嘅生活充電好幫手! 一條線,多種接口,無懼設備多 CyberCom3合1充電數據線支援 Micro USB、USB A、Type C 同 Lightning 四大接口,無論你係iPhone、Samsung定係其他品牌,甚至係藍牙耳機、遊戲機,都可以用呢條線充電同傳輸數據。旅行唔使再帶一大堆線,行李又有位可以擺多啲戰利品啦! 快充快傳,效率up up! • 支援QC快充技術,最高60W輸出,手機、平板、智能手錶都可以超快充滿,唔使等成日。 • 傳輸速度高達480Mbps,無論係工作文件定係娛樂影片,一link就傳,節省你寶貴時間。
 耐用又防纏繞,攜帶超方便 • 採用彈性TPE物料,線身唔易打結,收納方便,唔怕亂晒。 • 線材耐用又有彈性,日常用或者出街旅行都好啱用。
 產品小百科 • 1米長度,無論係屋企、公司定旅行都啱用。 • 建議零售價 $99,依家優惠價$79就可以帶走。
 由此開始,充電更快更簡單! 設計貼心,性能強勁,係你工作同生活嘅好拍擋。無論係手機、平板、遊戲機定藍牙耳機,呢條線都幫你搞掂晒充電同數據傳輸,令你嘅數碼生活更輕鬆自在。了解CyberCom3合1充電數據線嘅詳情同優惠,幫你打造更智能、更方便嘅充電新體驗!購買網站: www.cyberportcom.com查詢電郵: info@cyberportcom.com

最新文章

為程所困-是什麼讓你不想寫自動化測試?

科技新知
MacauYeah・2025-01-08

測試場 VS 自動化測試 筆者一直地更新自己過去所編寫的程式,很恐怖的是,那時的自己很少思考過怎樣寫測試Test Case。致使每次做更新時,都膽戰心驚,要手動建立測試場,人肉去測試每個可能有受影響的地方。在那些年的時候,有能力自己搭建測試場,已經是萬幸。但當面對一些要長期維護的程式,測試場的人肉測試並不是一個有效的方法,一來費時間,二來人腦記憶並不可靠。單靠自己去想想那些地方受影響,再測試,某程度是在挑戰人腦的記憶上限。如果是團隊合作,就更麻煩,你以為修改不會影響到其他人,結果卻是翻天覆地。 所以為求長治久安,編寫自動化測試,是有必要的。這些自動化測試,都算是回歸測試,每次程式有任何地方改動,都確保所有自動化測試被通過。理想始終是理想,但實際操作又會遇到怎麼的問題? 以筆者剛更新的程式為例,難以測試主要是當初沒有想過要測試這件事,所以程式結構通常是【連續順序】地執行。想分段測試?除非先重構。 Function中太多自己創建的Object 回顧自己的程式,初期編寫時,總會我手寫我心,每想要創建任何資源,在java中就會使用 new 字眼,或是自行呼叫某些 builder 類來取得資源,這是其中一個令自己無法寫測試的原因。 我們要想想,這些資源,是不是自己Function中所關心的核心。如果這個資源是被直接回傳的,我們要保留,如果它是HttpClient,只是要來獲取其他資源的媒介,我們或許可以利用依賴注入來取得它,即是把 HttpClient 改為經呼叫方傳入。注入的好處時,我們可以在Test中,修改那些資源的行為和結果。更進一步的是,把那些資源改為 interface 的方式存取,那麼在 Test 中就能更任意地控制該資源的行為。 首次重構某些資源成為依賴注入,大部份都會影響呼叫方,很多地方都要重寫。不論使用constructor injection, setter injection, annotation injection 等,上傳呼叫方,或多或少都會要加減改變參數。極致地,我們把構建都交給Program 框架去做,例如Spring Boot中,各種資源,都交給框架去自動配致。當然,這種做法的學習成本高,除錯成本也高。 【注入】其實是想在控作那些資源,在測試中運行得到固定的行為。使用前述的HttpClient例子,當我們業務邏輯是先訪問外部Web API,再根據結果做處理,那麼我們測試時,就會想模擬Web Api的結果。如果要做到自動化測試,最強硬的手段,就修改自己的HttpClient,模疑給出固定結果。 想要做到這種,在傳統的Java中,我們需要透過進一步抽離Interface去做。但這樣做很累,所以筆者通常會用如Mockito的程式庫,去修改HttpClient的行為。有興趣直接看程式碼的讀者,可以去看 github 。 當然,上述的 HttpClient 例子,使用測試場也有可做測試,自己再去模擬那些Web Api的回傳,有些情況下,這樣會更真實,但大家就必需好好定義測試場的行為。因為測試場可能與團隊的其他成員所共用,有機會其他人可能想要更多互動的測試方式,而非固定的結果。但並上非固定結果的測試場,自動化要測試的可控度就減少。

免費自用的私人AI助理 | Ollama - 本地大型語言模型

科技新知
MacauYeah・2025-01-06

不知道在澳門的朋友,有多少可以正常接觸openai?因為地方政策問題,像openai這種國外的大型語言模型(下稱LLM),澳門區都沒法接觸到。但隨著時間過去,即使我們不能直接接觸到算力很強的收費AI,我們只要有電腦,也可以佈署一些開源版本的LLM。只要我們可以安裝到ollama這套本地運算軟件就好 ollama是一個giuthub上的開源工具,讓用戶能夠在自己的電腦上運行各種大型語言模型(LLM)。基本上只要電腦是普通的桌上型windows, linux, mac,都可以運行它。下以面就介紹一下筆者的安裝經驗。 windows windows ollama windows 本地安裝ollama,真的很簡單,就是直接去官網下載就好 - https://ollama.com/download/windows 安裝完成後,在windows cmd再加一個基本的模型就可以了 ollama pull llama3.2 之後就可以開始跟llama問問題 ollama run llama3.2 windows openwebui 如果大家不習慣windows cmd的醜醜介面,想經過瀏覽器存取,我們可以再加裝openwebui。但這個必需要經第三方python或docker安裝。openwebui github指引 - https://github.com/open-webui/open-webui 經python pip install open-webui open-webui serve 經docker docker run -d -p 8080:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main 最後,打開browser,訪問 http://localhost:8080,openwebui就會要求大家先設立管理員帳號。 就那麼簡單,大家就有一個真正的私人AI助理。 steamdeck steamdeck 因為很多linux功能都有被限制,所以筆者就直接使用 podman 安裝 git clone https://github.com/macauyeah/ollama-steamdeck-podman.git cd ollama-steamdeck-podman podman compose -f podman-compose.yaml up -d podman exec -it ollama ollama pull llama3.2 同樣地,打開browser,訪問 http://localhost:8080就可以了,因為這個版本已有預設的管理員帳號,立即打開就可以使用了。 Ollama的開源模型 上文中一直提及 llama3.2 其實是 Meta 公司的開源模型,因為它的參數相對少,算力要求較低,可以在沒有GPU的環境下執行。若然大家算力足夠,可以使用其他模型,詳見 https://ollama.com/library 。見到合心水的模型,大家可以經 pull 指令下載。例如:小紅書的網紅們很多都推薦qwen2,我們可以 ollama pull qwen2 備註: openwebui 及 ollama 並不直接支援自己建立自己的資料庫。我們需要其他工具去補完,但筆者觀看各種教學,自己建資料庫的效果都不太好,所以暫時不做任何教學。 只要我們一直經ollama pull,就可以更新語言模型。但如果大家追求即時的網絡最新資料,大家可以看看LLM RAG的相關文章。但筆者亦未有成功的案例,有更新會另作教學。 opewebui並不是PDF閱讀器,但它可以預覽PDF中的文本,我們需要手動複制PDF中的文件後,才能經ollama分析文件內容。 若想切換模型,在指令介面中,我們多開一個分頁就可以了。若經openwebui,則可以在每句對話之前,經左上方選擇不同模型。

Steam OS 內建 podman DNS 問題解決方法

科技新知
MacauYeah・2024-12-20

前幾天筆者在介紹SteamDeck 內建的podman時,沒有測試得很清楚。在長期使用下,的確有些問題需要進一步處理,這裏就補充一下解決方法。 我們前一篇介紹的 Steam Deck 內建 podman ,配上再自行安裝 podman-compose 有時會出現warning :`WARN[0002] aardvark-dns binary not found, container dns will not be enabled`。這不單影響到沒有在 service 之間自動産生 DNS 記錄,還會令互聯網功能失效,因為它會是整個 DNS 解釋功能丢失了,只是在 service 中定義 DNS 的地址並不會解決問題。筆者亦測試過,照著原本的 docker 思路,使用最傳統的做法,自己起 network ,自己起 container ,然後再串連在一起,依然會出現問題:`Error: "slirp4netns" is not supported: invalid network mode`。所以根源問題應該不在 podman-compose 上,而是在內建的 podman 依賴上。 緊急的解決方案,我們需要用到 "network_mode: host" 的方式去解決。例如以下例子 "network_mode: host" 的主要作用,就是讓 container 直接在主機的網段上執行。上面的例子中的 postgres 資料庫,它預設使用5432端口,我們並不需要再獨立宣告,即使在 container 內外,都可以直接使用 localhost:5432 溝通。而使用了主機的網段後,DNS 也可以正常運作。但這個做法的缺點就是 container 內的所有 port 都自動佔用了 host 上的使用,有時候那怕我們並不需要,它也會被暴露在外。更可能的是增加了不同 container 之間的 port 衝突。不過筆者要用於開發環境,所以這並不會是很太大的問題。

Docker 來源掃瞄 - Docker Image Scan

科技新知
MacauYeah・2024-12-19

當網安要求越來越高時,我們也要留心 docker image 的來源是不是有漏洞問題。 docker hub 本身就已經有一些安全掃瞄報告,以 nginx 的 1.27.3 版本為例, docker hub nginx 1.27.3 , docker hub 已經列出相當多的CVE漏洞。 不過對於不公開的 docker image ,安全描瞄可是要收費的。作為小團隊,可能想先尋求一些簡單的免費方案。如果你想同樣的需求,可能Trivy會幫到你。 Trivy Trivy 是一個用於描瞄軟件版本依賴或設定檔是否引用到一些有漏洞問題的軟件,它也能檢測 docker image 是否有漏洞或錯誤設定的問題。而且更好的是, Trivy 本身亦有 Docker Image 版本,我們就不用煩惱怎樣弄一個 Trivy 的執行環境,只要可以運行 docker ,有網路就可以了。但使用 Docker Image 版的 Trivy 有一個額外要求,就是它要有主機上的 docker.sock 權限。 描瞄的指令如下,其中 docker.sock 就是為了讓 containers 內部的程式可以存取主機的 docker daemon , .cache 則是為了方便暫在下載資源。 上面故意用 nginx 的兩個同版本號不同平台的 docker image,其實就是為了引出一些潛在問題。nginx 預設是使用的debain OS的,在筆者寫文章的當下,已經更新到最近的 image ,但始終有一大部份可能的漏洞。反觀 alpine OS 版本,就找不到這麼多問題。 這是因為 alpine 預設安裝的依賴較少,所以找到的漏洞也少。正所謂,做多錯多,唔做唔錯(大誤)。這其實有好有不好,因為在發生問題時,在 alpine 下可能連基本的除錯工具都沒有。除非大家有完整測試,或者對 alpine 有相當的認識,你才會選擇一個非官方預設的版本。但就以事論事,引用較少的依賴,長久之下的確是不會有那麼多隱患。大家如果有條件,也可以試試 alpine 或其他版本。 前一節我們可以看到,Trivy需要經過 socket 的方式才能存取主機上的 container daemon 操作權。但 podman 作為一個不主張 daemon (daemon less),亦主張不需要 root (rootless),那麼它該怎樣執行? 其實podman也有user層面上的 socket,而且 trivy 也有對應的方式去轉用第三方 socket (有點像使用遠端主機 socket,但官方並未宣佈正式支援遠端的方式。) 具體使用方式,筆者亦已在 steam deck 上測試,使用方式如下。不過因為 steam deck 預設沒有 root,筆者就省略 cache 指令,免得之後要有權限問題要手動清理。 Ref Podman socket activation Trivy: Support for rootless podman

steam deck 辦公用途工具資訊 2024/12更新

科技新知
MacauYeah・2024-12-17

購入steam deck 已經有一年多的時間,之前亦發過一些安裝教學。適逢筆者系統重裝,又有機會重新檢視工具的可用性。 Podman / Distrobox 一項很重要的更新,Steam OS已經有預安裝podman,不需要經home brew安裝。但預裝的podman 沒有內置DNS,可能會對K8S等進階應用有影響,不過筆者只作為單機測試用,普通的podman compose沒有問題。 另一項很重要的更新,就是 distrobox,它可以經 podman 讓大家方便地執行不同的 linux 版本,想在Steam OS上使用Ubuntu?沒問題,開箱即用;想用VScode官方維護版本,沒問題,安裝指定Linux再按裝VScode就好。 詳見上一期的介紹。Steam OS 3.5更新,內建 podman, distrobox 中文輸入法 我們不需要再安裝Fcitx5 + Rime,如果大家在遊戲模式下,已經設定好中文輸入法,那麼在輸到桌面模式下,照樣以Steam Button + X Button的方式,打開內鍵輸入法。你會見到有虛擬鍵盤彈出,它會覆寫桌面模式的。此時,即使你關掉虛擬鍵盤,並用實體鍵盤,中文輸入法都會保留。不過大家要確認,彈出當下必需要是【中文】。 若然你彈出的虛擬鍵盤是英文,請按【地球】轉換到【中文】後,關掉虛擬鍵盤,再重來一次(重按Steam Button + X Button),確保彈出的時候是經【中文】覆寫。 Discovery Discovery 是 Steam OS 預設用來安裝第三方程式的地方,它經 flathub / flatpak 存取程式。但筆者一定要先強調,它提供的第三方程式,並不一定會得到原開發者的支援,它屬於打包移植之類。 例如 flathub 中可以找到 Google Chrome (https://flathub.org/apps/com.google.Chrome) ,但它實際是經過一個github 專案移植過去的 (https://github.com/flathub/com.google.Chrome)。它有提供持續更新,但筆者不保證當中有沒有任何被植入過任何不正當軟件。 相反,flathub中有一些程式是經過原開發者支援的,例如 Firefox (https://support.mozilla.org/en-US/kb/install-firefox-linux), Gnome Boxes (https://gitlab.gnome.org/GNOME/gnome-boxes), Gimp (https://www.gimp.org/downloads/) ,這類可以比較放心使用。 筆者過去使用 Discovery ,的確有遇到一些權限問題,但最後估計應該是筆者安裝 Homebrew 所影響。筆者在重裝 Steam OS 後,直接使用 Discovery,就沒有問題。過去需要經 Homebrew 安裝的東西,現在經 podman , distrobox 或 Gnome boxes 就可以了,不再需要經Homebrew去折騰一輪。而且Homebrew也不是萬能的,因為Steam OS有限制一些套件的事用,即使安裝Homebrew也解決不了。若想要完全開放套件限制或解決依賴問題,還不如直接開啟Steam OS覆寫權限,轉用Arch Linux的安裝包。

Steam OS 3.5更新,內建 podman, distrobox

科技新知
MacauYeah・2024-12-10

之前筆者有介紹過如何在Steam OS上安裝podman,但都必需要自行折騰一番,特別是遇到一些依賴缺失時,還要逐個除錯。在Steam OS 3.5更新之後,官方已經有預安裝的 podman,筆者建議,如果有機重刷OS,就直接使用預安裝版本就好。更重要的是,不但有預設podman,連另一個神器distrobx,也在Steam OS 3.5之後引入。 podman-compose Steam OS 3.5,雖然已經有預安裝 podman ,但在實際環境下,多安裝一個 podman-compose 可以更方便地一體化操作。 我們可以經 python 安裝。 剛安裝 podman-compose ,會出現在自己的 home 目標的隱藏目錄。最後一步就是要加到自己的 PATH 環境變數裏面。 修改保存後,就重啟。之後 podman-compose 的指令就可以任意存取了。 要補充一點,就是官方預安裝的 podman 還是缺少了一些 DNS 的元件,大家會看到 warning 提示。不過在筆者單個 container 的使用情境下,並不受影響。之後要在其上二次引用的 distrobox 也可以順利執行。 神器 distrobox 在 Steam OS 3.5 中,除了 podman 外,還有預裝 distrobox 。 distrobox 其實是基於 container 技術的擴展應用,它目標是讓用經過 container 就可以輕鬆使用到不同 linux 的發佈版本。例如我想在 Steam OS 中使用 Ubuntu ,經過 distrobox 就可以用到。道理上, distrobox 基於 container (podman) 操作的,所以它能做到的,其實自己手動經 podman 也是可以做到。但若果大家想使用跨 Linux 版本的 GUI 程式,筆者還是建議優先使用 distrobox 。因為 distrobox 預設已為不同版本的 Linux 的 Image (來源影像檔) 加入部份調整,在運行時亦有x11等互通,指令也較為簡單。 以下做來例子,示範在 Steam OS 中就執行 Ubuntu 版本的 vscode。 註: Distrobox 也不是萬能的,例如它的 Ubuntu 版本內沒有 snap ,所以不能執行 Ubuntu 版本的 Firefox。 snap will not works (firefox not works)

概有雲供應商的K8S,為何要自己弄Docker Swarm / 本地K8S ?

科技新知
MacauYeah・2024-11-19

其實筆者寫了這麼多篇docker 的文章,可能有朋友會問,為何要自己從零建立Container環境,使用供應商直接提供的K8S服務不是很好嗎? 按照市場發展,各大雲供應商都越來多,競爭越嚟越激烈,作為用戶方,理應可以得到更合理的價格。不過作為使用VPS多年的筆者,真的沒有覺得雲服務的價格可以便宜到一個不用煩惱的水平,大家還是需要很㥀重地考量自己的業務是不是值得雲端化。 正常來講,在有足夠使用量的前提下,雲端化也是合適的,也真的有產到錢。但問題是大部份情況下公司內部自主開發的應用,都沒有去到這個程度。每個應用去租用一個VPS,即使使用最低配置,用起來的時候覺得不夠快,閒起來的時侯也是浪費錢。 這時,使用 Container 技術,就是讓多個不同的應用,共享同一個或多個VPS的好方法。因為 Container 可以簡易地做到應用之間的隔離,即使不同應用之間有依賴衝突,只要 Contianer 層面沒有衝突就可以共存。 Docker swarm 與 K8S 同為 container 技術,文章最前面,就提到了這個問題,為何不選現有的K8S,反而要自己弄Docker Swarm?其實關鍵亦是價錢的問題。使用K8S固然方便,但就每個節點都得使貴一級的雲端供應商服務,當我們的應用總是流量不足,就更易變得食之無味,棄之可惜。老實講,貴一級的雲端服務,有它存在的價值,很多東西可以做自動化擴展,例如概據流量自動擴容。另外,因為底層 Container 技術有供應商支援,也不用再另外購買支援服務。但這些都是業務有一定流量,才能展現出優勢。 反觀Docker Swarm,就是簡單可入手,初時一個VPS也可以。什至乎不上雲,找幾台舊電腦,實機做也可以。當然K8S也可以實機,不過就簡易程度來講,Docker Swarm 無得輸。待業務真正成長到一個有足夠流量的服務時,才進一步遷移到供應商的原生雲。在初期使用自建的Docker Swarm或小型K8S,可以先加入一些資源統計,以確定是否即裝滿負荷。

Swarm mode 上線 5 - load balancer | 還有那些事該考量?

科技新知
MacauYeah・2024-11-18

前面介紹了 ingress network ,亦介紹了 proxy gateway 。能做到的基本都做到了,再來就是考量安全性的問題。因為加了 proxy gateway ,前述的例子是所有 service ,都放在同一個 yaml 檔中。好處是,所有相關的東西存放在同一個檔中, gateway ,背後的 service 都一眼看到。但壞處就是有其中一個 service 更新,都要改那個 yaml 檔。更大的問題是, stack deploy 的指令,不單只更新其中一個 service ,就連其他 service 都會自動取得最新 image 而 redeploy 。 對於一個緊密的系統來講,同步更新可能不是大問題。但對於一些預定排程發佈的系統可不能這樣因為副作用而更新了。如果你也有這樣的分開管理需求,可以參考下面做法,把 gateway service 及 upstream service 放在不同的檔案中,然後經過 external network把所有 service 串連起來。 # nginx-stack.yaml, docker stack deploy -c nginx-stack.yaml nginx services: http-gateway: image: http-gateway ports: - 8080:8080 deploy: replicas: 1 update_config: delay: 10s restart_policy: condition: on-failure # manager-stack.yaml services: managerhttp: image: bretfisher/httpenv networks: - nginx_default - default deploy: replicas: 3 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==manager networks: nginx_default: external: true # dmz-stack.yaml services: dmzhttp: image: bretfisher/httpenv networks: - nginx_default - default deploy: replicas: 2 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==dmz networks: nginx_default: external: true 這樣,不同 service 的維護人員,就可以獨自控制自己的檔案。在第一次發佈時,確認 nginx-stack.yaml 先行發佈就可以了。對應的發佈指令是docker stack deploy -c nginx-stack.yaml nginx,它會自動産生一個 nginx_default (即 stack名字_default )的網絡。之後其他service,就可以經networks的設定找到它了。 services: YOUR_SERVICE: networks: - nginx_default - default networks: nginx_default: external: true 上述即使分離檔案,在安全性考量時還是有一個問題,就是 ingress network 的問題。試想一下,dmzhttp (Demilitarized Zone)原本被設定的原因,就是想限制某些訪問只能一些可以公開的服務。但因為經過 ingress network 之後,它們會在所有機器上開放這些 port。那就是,以下面的例子來講,若 dmzhttp 是公開的服務, intrahttp 是內部服務,即使用 intrahttp 使用不同的port 8889。但一經 swarm mode 預設的 ingress network ,在node.labels.zone==dmz的那些節點,還是可以訪問到 intrahttp 。 services: dmzhttp: image: bretfisher/httpenv ports: - 8888:8888 deploy: replicas: 2 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==dmz intrahttp: image: bretfisher/httpenv ports: - 8889:8888 deploy: replicas: 3 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==intra 我們前述介紹的 proxy gateway ,其實已經有一定程度可以解決這個問題。因為 proxy gateway 是根據 http 協定中的 host header 去做分流。在邊界網絡進來的「合法」訪問,道理上會好好地經引導到我們的 dmzhttp 。不過網路的邪惡可容小看, proxy gateway 也會有被騙的一日。有特定能力的攻擊者,只需找到目標域名,還是可以接觸到 intrahttp 。 若要做進一步隔離,在這種情況下,我們可以在 dmz , intra 機器中各設定一套 swarm ,完全獨立,這是最安全的做法。但這樣做的管理成本就會變高,因為兩個網段都會有自己的 manager 節點,而且在 dmz 網段的 manager 節點也有被攻擊的可能。 若我們回到單一 swarm 的方向,可以修改各個 service 中的 port 和 deploy 。利用 post mode 中的「host」,配合 deploy mode 中的「global」,完全跳開 ingress network。 services: dmzhttp: image: nginx ports: - target: 80 published: 8888 mode: host deploy: mode: global update_config: delay: 1s restart_policy: condition: any placement: constraints: - node.labels.zone==dmz intrahttp: image: bretfisher/httpenv ports: - target: 8888 published: 8888 mode: host deploy: mode: global update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==intra 上面的例子中, dmzhttp 會在所有 dmz 的機器中,每個節點只運行一份服務,而且直接使用該機的 8888 port ,外面不會再有 ingress network 的 存在。同樣地,intrahttp 會在 intra 的所有節點,運行一份服務,佔用它們的8888 。這兩個服務,即使使用一個 port ,swarm 也不會說有任何問題。因為它們不會經 ingress network 搶佔其他人的 8888。 可能會有讀者問,如果 host mode 這麼安全,為什麼預設會是 ingress network,那我們就要先了理清 ingress network 與 host mode 有有什麼分別?假設我們只運行一個service,它佔用8888。 功能ingress modehost mode replicas 數 同一個 service replicas 為任意數量,什至比節點的數目多 因為有 port 限制,每個節點最多只能運行一份 Virtual IP Virtual IP 任意在節點中跳轉也可以,因為 ingress 會自動找到對應的 service 所在的節點 Virtual IP必需要與 service 所在節點綁定,其他節點訪問不到 load balance 有 沒有 host mode 就像我們傳統在各自的節點上自行佈署自己的程序,各個節點只有一份。所以不會有自動 load balance 的效果,如果客戶端訪問固定的IP,就會得到是固定的接器接受請求。我們有需要,就要在前面加一個 Proxy Gateway (或 HA proxy )。 Virtual IP 也一樣, host mode 下需要好好地自動跟著 service 的生命期,不過幸運的是, Docker 預設己經有自動重啟 service 功能,即前文中的 restart_policy ,它在 host mode 下也適用。如果大家有配合 deploy 中的 global mode , Virtual IP 的並沒有實際變動。但如果沒有 global mode ,就要再想想辦法了。 最後考慮 load balance 的問題,如果進入點的 service 的真的不太消耗資源,沒有 load balance 也是可以的 ,但若超負荷,就必需要自建 proxy gateway 。經過進入點後,若我有背後的 service 就沒有所謂的 ingress 和 host mode 選擇。

Swarm mode 上線 5 - load balancer | proxy gateway 代理伺服器

科技新知
MacauYeah・2024-11-11

前面的例子,我們已經成功設定 ingress Network,也加了 virtual ip 。如果大家的目標是單一 web 應用,應該就已經很足夠。但作為一個足夠節儉的老闆,怎會讓一個 Swarm 只跑一個 Web 應用?但問題來了,一個 docker swarm service 就已經佔用一個公開端口 (例如上述的8888,或是更常見的443)。怎麼可以做到多個 service 分享同一個端口?答案就是回到傳統的 Web Server 當中,使用它們的 virtual host 及 proxy 功能,以達到這一效果。我們就以 Nginx 為例,去建立一個守門口的網關 (gateway) 。 以下就是一個最簡單的例子,最前端的 http-gateway (nginx) 對外公開端口 8080 ,它根據 virtual host,去分派對應的請求去 dmzhttp (bretfisher/httpenv) 及 managerhttp (bretfisher/httpenv) 。構架圖就是以下這樣。 ┌───────────┐ ┌──────────────►│ dmzhttp │ │ └───────────┘ │ ┌───────────────┐ │ http-gateway │ ────────►│ (nginx:8080) │ └──┬────────────┘ │ │ ┌─────────────┐ └─────────────►│ managerhttp │ └─────────────┘ 換成 docker stack ,就大概如下 services: http-gateway: image: http-gateway ports: - 8080:8080 deploy: replicas: 1 update_config: delay: 10s restart_policy: condition: on-failure dmzhttp: image: bretfisher/httpenv deploy: replicas: 2 update_config: delay: 10s restart_policy: condition: on-failure managerhttp: image: bretfisher/httpenv deploy: replicas: 3 update_config: delay: 10s restart_policy: condition: on-failure docker stack有一個很好的功能,就是 service 名會自動成為同一段網絡中的 hostname 。即是http-gateway中,它可以經DNS,找到 dmzhttp 、 managerhttp,也就是它的 nginx 可以設定成如下的樣子。 # default.conf server { listen 8080; listen [::]:8080; server_name managerhttp; resolver 127.0.0.11 valid=30s; location ^~ / { set $upstream_manager managerhttp; proxy_cache off; proxy_pass http://$upstream_manager:8888$request_uri; } } server { listen 8080; listen [::]:8080; server_name dmzhttp; resolver 127.0.0.11 valid=30s; location ^~ / { set $upstream_dmz dmzhttp; proxy_cache off; proxy_pass http://$upstream_dmz:8888$request_uri; } } 上面的例子中,就是一般的 virtual host + nginx proxy 設定。特別要說明的是 resolver 那一行,它指向 docker DNS (127.0.0.11), 而且還可以讓nginx在找不到上游時,不要馬上死亡。這樣 docker swarm 中各個 service 隨時加加減減,有保命的作用。 最後我們的 http-gateway 就是 nginx image + default.conf 上述的 docker 就可以用以下方式打包。 # Dockerfile # docker image build -t http-gateway ./ FROM nginx:latest COPY default.conf /etc/nginx/conf.d/default.conf 上面的 docker stack 和 nginx config,只要同步增加 service 及對應的 proxy pass,就可以o讓同一個端口,根據不同hostname做分流。當然,如果大家可以共用端口及 hostname 也可以,分流就改用 nginx location 來設定,不過這是更加偏向 nginx 的內容,日後有機會再介紹。本篇就先集中於 docker 相關的議題。 在安全性的角度, docker 還有一些配置可以做,就是讓 dmzhttp 和 managerhttp 在不同的機器上發佈。假設我們的網絡分開兩段,一段是 manager 專用,一段是 dmz 專用。在建立 docker swarm 後,我們可以為不同的節點加入對應的標簽。 docker node update --label-add zone=manager YOUR_MANAGER_NODE docker node update --label-add zone=dmz YOUR_DMZ_NODE 然後我們通過修改 docker stakc 中的 placement -> constraints ,限制不同的 service 在不同的節點上運行。 services: http-gateway: image: http-gateway ports: - 8080:8080 deploy: replicas: 1 update_config: delay: 10s restart_policy: condition: on-failure dmzhttp: image: bretfisher/httpenv deploy: replicas: 2 update_config: delay: 10s restart_policy: condition: on-failure + placement: + constraints: + - node.labels.zone==dmz managerhttp: image: bretfisher/httpenv deploy: replicas: 3 update_config: delay: 10s restart_policy: condition: on-failure + placement: + constraints: + - node.labels.zone==manager 使用上面的例子,我們就可以達到簡單分離的效果。但大家緊記,這個分離效果始終是一個規則式功能,它與防火牆的隔離還是有本質上的區別。除了利用傳統的防火牆技術外,我們的docker swarm network,其實也可以做更多隔離,我們日後再慢慢加強這個例子。

Git 歴史修正

科技新知
MacauYeah・2024-10-29

有時候,我們修正一系統檔案,例如某個commit中,多了一個不該放的檔案,又或者想修改該commit的作者,我們就要追搜到某個commit,然後用rebase隨個改。 例如本次repo,有一個githubAction.md,因為錯誤原因,被加到了main中,也藏了很久。如果我們想連根拔起,我們需要加出它第一次出現的commit。 $ git log githubAction.md commit 60ccd70f6b768138cbe23c93ffcfa32574ce895c 那我們就以它前一個commit作為rebase的根據,進行逐個commit修正。 $ git rebase -i 60ccd70f6b768138cbe23c93ffcfa32574ce895c^ pick 60ccd70 draft some content pick e2ee9a3 add some senario. pick b91afc1 refine submodule; pick 98cd366 add notes about submodule specific checkout; pick 064b06f test directly commit in submodule main pick 7b648d2 update git submodules notes pick 556f25e add notes about merge timing pick 5244804 Create git-continuous-integration-strategy.md pick 107e486 add more pratical nodes about ci; pick d93cbee add mono repo challenge pick 1c471b6 add worktree notes pick 9063ccb notes about different of git flow and github flow; pick b72e89e Update github-flow.md, add ref more link pick 0b8f2a9 draft github flow release problem pick 8b333fc finalize github flow release strategy 在rabase選項中,把需要改的commit由pick改為edit。(rebase會以舊到新顯示)。然後儲存。例如 edit 60ccd70 draft some content edit e2ee9a3 add some senario. edit b91afc1 refine submodule; pick 98cd366 add notes about submodule specific checkout; pick 064b06f test directly commit in submodule main pick 7b648d2 update git submodules notes pick 556f25e add notes about merge timing pick 5244804 Create git-continuous-integration-strategy.md pick 107e486 add more pratical nodes about ci; pick d93cbee add mono repo challenge pick 1c471b6 add worktree notes pick 9063ccb notes about different of git flow and github flow; pick b72e89e Update github-flow.md, add ref more link pick 0b8f2a9 draft github flow release problem pick 8b333fc finalize github flow release strategy 我們第一次會在60ccd70,我們作出想要的改動,然後經amend去改掉60ccd70 $ rm githubAction.md $ git add -u $ git commit --amend --author="newuser " 確定無誤的話,就可以去下一步,即是到了e2ee9a3 $ git rebase --continue 因為已經rebase過,你此時看到的不會再是hash不再是e2ee9a3,而是自動rebase完的e2ee9a3。若大家有東西要改,就使用commit --amend。如果沒有東西要改,也沒有conflict,可以繼續rebase --continue下去。

Swarm mode 上線 5 - load balancer | 負載平衡器

科技新知
MacauYeah・2024-10-28

前面我們一直談 swarm 的設定,但對於真實的服務,我們還要考慮客戶端是如何連接我們的伺服器群集。通常網路服務,客戶端都會經過域名轉換成IP,然而通過IP連線服務。 Ingress Network 假設我們 swarm 內有5個節點,那到底域名應該指向我們哪一個節點的 IP 呢? 如果我們不考慮節點死機的話,其實5個節點的IP都可以。因為 swarm 會自動把同一個公開的 port ,在每一個節點上都可以訪問到。 以下例子,即使只有一個 container 運行,佔用 port 8888,它還是會在5個節點上全開。 swarm 通過自己的 ingress network,它所有節點的 8888 串連起來。 services: http: image: bretfisher/httpenv ports: - 8888:8888 deploy: replicas: 1 update_config: delay: 10s restart_policy: condition: on-failure 我們可以在每個節點上,都會找到這個 ingress network,而且那個Network ID,應該是一樣的 > docker network ls | grep ingress t7rmk6g9zybm ingress overlay swarm 如果上述的 service 的 replicas 調成大於1的數量, ingress network 還會方便地自動 round robin (輪替) 地分派流量,達到最簡單的負載平衡。 Virtual IP 前述的設定,我們有一最大的假設,就是節點不會死機。但實際情況下,各種原因,例如安全性更新、重啟中,都會讓節點暫時無法使用。即使所有 service 都是會自動 failover (故障轉移),但客戶端還是用舊機 IP ,它還是無法訪問。因為該機 IP 已無法使用,除非我們連 IP 也懂 failover。這時, Virtual IP 就是我們的救命靈藥。 在 ubuntu 上,我們可以經過 keepalived 去設定 Virtual IP apt-get update && apt-get install keepalived -y 然後設定 keepalived , 假設 172.22.1.5 是我們的 Virtual IP 。 然後每個節點都要加入conf # vim /etc/keepalived/keepalived.conf # assume failover ip is 172.22.1.5 vrrp_instance VI_1 { # change interface according to machine status interface eth1 state MASTER # 101 for node1, 102 for node2 # you can start seq from other value, remind unqiue for each node is ok; virtual_router_id 101 # lower value will become master # ex, node1 priority 100, node2 priority 200, node3 priority 150. # if node 1, 2, 3 alive, node2 will become master. # if node 2 gone, node 3 will become master. priority 100 advert_int 1 authentication { auth_type PASS auth_pass YOUR_RANDOM_PASSWORD } virtual_ipaddress { 172.22.1.5 } } 上述需要特別注意的是 virtual_router_id : 每個節點應該都要不一樣,以作唯一標識。 priority : 每個節點應該都要不一樣,最大的那個節點,就會優先使用 Virtual IP 。 auth_pass : 每個節點都相同,但大家在抄時,記得更改。 還有的是開通 iptables ,讓各個節點可以經網絡廣播的方式互相看到對方。 iptables -I INPUT -d 224.0.0.0/8 -j ACCEPT iptables -I INPUT -p vrrp -j ACCEPT systemctl restart keepalived

Docker Tag 命名

科技新知
MacauYeah・2024-10-24

一般來講,同一個docker image會提供多個不同的版本,每個版本會附予不同的tag,以作標識。但以docker image的維護者來講,它的tag通常代表的是自己程式的版本號。不過這個版本號卻存在很多變數,就讓筆者好好地逐一說明。 程式的版本號 在沒有Docker的年代,其實所有軟件在發佈時,都會標示版本號,方便使用方明確追蹤問題,自行選擇升級、降級以解決相容性問題。大家要重現問題,也能清清楚地重現。所以docker image的tag,在某程度,都是代表發佈自己的程式版本號。但以前的年代,軟件底層的依賴,例如OS層面的共享程式庫,則不在發佈的管控中,所以過去的程式,在跨電腦安裝時,都會出現缺少某些共享庫的問題。而使用了Docker後,image以內的共享庫的都會在打包的那一刻固定和發佈,就不會有漏的問題。 庫更新,怎麼辦 上面說到image可以打包共享庫,但問題是共享庫也會有安全性更新問題,那麼對docker image的維護者來講,它自己的tag又該如何命名? 因為庫的量可大可少,所以一般來說,都不可能完全把各個庫的版本號寫在自己的tag上。退而求其次,就是用"版本號+日期",庫的細版本號,就存在原始碼當中。Ubuntu 就是這樣的例子。 不過"版本號+日期"的命名方式真的方便嗎?每次下遊用戶想更新去最近版本,都要自己找一次最近的日期。這樣對很多用戶來講都不夠方便。所以docker又提供了一個重tag的功能。例如ubuntu:noble,在早些時候指著noble-20240904.1,然後過幾天,又指向更新的noble-20241009。更常見的是latest,每次image都預設會存在,docker也希望大家會定期更新這個tag,讓大家可以更易地找到最新版本。 註: 這跟git tag有所不同,git tag並不預期會變的。當協作者收到tag後,那怕上遊刻意更新tag指針,協作者沒有刪除原tag之前,都不會知道tag更新去了哪裏。 我們該如何選 在發佈方和引用方來講,引用時可以明確使用唯一的"版本號+日期",對穩定性來講是有意義的。不過多多少少,會產生額外的時間成本。發佈方來說,就是多用了一些儲存空間,方便引用方可以隨時找到舊(庫)版本。而引用方,就要手動修改引用號,作為驗收依據,自動更新的難度比較大。 但對於自動更新要求比較大的情況下,可能就是使用latest或者會隨時更新的share tag(共用tag)比較實際。但我們也依然要定一些方式去版本更新記錄,例如:同時使用 beta latest archive 每日自動更新beta,只有所有測試都通過時,才把archive指向現在的latest,再把latest指向現在的beta。這樣做的好處是,核心的docker stack檔案改變的機會較少,也可以免除docker swarm做太細緻的權限管理。