搜尋

搜尋結果

Docker Tag 命名
科技新知
MacauYeah・2024-10-24

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

Ceph Storage 水很深
科技新知
MacauYeah・2024-09-25

筆者不才,早前為大家介紹了一篇關於Ceph Storage的最入門安裝教學。但在後續測試中,發現了一些概念上的問題,需要盡早說明,不然就會像筆者一樣,要砍掉重來很多次。 OSD HDD Ceph Storage的主要功能,就是為Contiainer提供外置儲存空間,它對儲存空間有特定的要求。我們最好在建立ceph clustercephadm bootstrap之前,就為每個node上增加合適的HDD 引述官方說明 OSD Object Storage Daemons The device must have no partitions. The device must not have any LVM state. The device must not be mounted. The device must not contain a file system. The device must not contain a Ceph BlueStore OSD. The device must be larger than 5 GB. 簡而言之,大家需要準備新的HDD,不要做任何格式化,讓OS見到HDD但不作任何操作。筆者試過,使用hyperv VM hyperv HDD,也是可以做到的。不過之前筆者於教學中用的 multipass 就沒有這個模擬HDD功能,我們需要使用比較強大的VM作為實驗。 若然HDD是在ceph clustercephadm bootstrap建立之前,就存在的。我們可以經過ceph的網頁介面,或經指令自動加入。 ceph orch apply osd allavailabledevices 若然HDD是在ceph clustercephadm bootstrap建立之後,才加入的。那麼ceph有機會沒法自動發現它,筆者當前的dev版本就出現這問題。我們就需要經指令手動增加 ceph orch daemon add osd NODENAMEdevsdb OSD 官方說明文件 httpsdocs.ceph.comenreefcephadmservicesosd#cephadmdeployosds Reset 在我們做實驗時,若我們想回復到上一個狀態,測試不同的參數差異,Ceph指令並不會即時執行。例如前一句的add osd,想倒回來自行刪掉一些osd,即 ceph orch osd rm OSDID 它就會排隊慢慢做刪除。 但這個過程筆者未有成功過,OSD一直處於繁忙狀態。有機會是因為系統需要保持同步狀態,待成功遷移資料前,什麼都不能動,所以一直都在待刪除的狀態中。 同樣地,當我們想要刪除一些node時,我們使用以下指令 ceph orch host drain NODENAME ceph orch host rm NODENAME 最後也是會卡在刪除OSD的情況 Removing Hosts 官方說明文件 httpsdocs.ceph.comenreefcephadmhostmanagement Static IP 因為 container 技術,很多都需要固定 IP ,我們做實驗之前,最好先了解你的VM engine如果提供Static ip 。以 hyperv 建立的 VM ,其實可以同時建立兩張網卡的,一張為預設網卡,用於連網用,另一張則設定為內部網絡。在安裝 ceph 時,經 cephadm bootstrap 所引用的IP則設定為內部網絡的IP。之後基本上使用任何一張網卡的 ip ,也可以訪問到cephadm的網頁介面。如果不是在一開始的階段上準備Static IP ,我們又會在重設解綁cluster時,同樣因為機器繁忙而卡在不上不下的狀況。

Coding | Test Case 值得寫嗎?
科技新知
MacauYeah・2023-11-02

很多做軟件開發的朋友,其實都會聽過Testdriven的開發模式。就像Scrum一樣,名氣很高,但試過的人很少。為何會這樣呢?筆者認為,並非開發者懶,而是編寫Test Case的難度真的高。對比開發程式本身的成本,寫Test Case的時間學習成本一樣高。 造成這些高成本的原因很多。一來是因為開發者並不像過往一樣,慢慢從零寫程式,一般都應用Framework去預構建一些東西,例如打包Database connection pool,Dependency injection。Framework是好用的,但就令你要模擬Mock up特定資源,變得越來越複雜。所以一般中、小型開發,都鮮有人懂得做Test Case除了大神獨立開發者外。筆者對於Spring boot等Framework,都摸索了很久,才能模擬一些特定資源。但Framework一更新,就很多部份都要重寫。所以筆者沒有很強調要做Test Case,因為成本認真大。 最近,在摸清一些test case 基本concept後,筆者又重新開始嘗試編寫test case。以下假設用的是object oriented programming 在開發自己的class,為每個public function,都寫test case。很多IDE, 都有提供相關自動生成test case function signature的功能(就是為你的目標function,起一個只有外框的test function。)vscode雖然不是原生支援java,但只安裝基本的java test package,就可以達到同樣效果。 在不依靠framework的情況下,自己class要『引用』的其他class object,不要經過自己使用new來生成object。全部經set function來傳入你要引用的class object。除非你的class是作為Factory Pattern(工商模式)生產某些object,不然你就不會再有new字眼。 在為自己class編寫test case時,就會可以模擬被『引用』Object的行為。這個object在傳統上可以使用oop中的interface類型來達到模擬又不會影響到原結構的做法。實在不想做interface,java還可以用mackito 這個libraray來硬改Object的行為。 同理,自己class要『引用』一些外部資源,那些設定資源的config,都應該要set function傳入。這樣你在test case中才能起一個臨時的模擬外部資源。 在不使用framework的情況,要全數去自行模擬,當然很痛苦,但至少你可以做一些很簡單的測試。 在使用framework的情況下,還有些教學都是教你mockito繼續模疑。但這會是很痛苦的,因為這樣叫做unit test,單元測試,你要模擬所有東西。在折衷的情況下,應該底層元件做unit test,但上層的元件就做integration test,整合測試。 在做integration test時,就差不多等同使用framework行起部份或必要的資源。而那些必要資源,可能指是的database service, network service。我們可以在test case中設立不同的config,從而把framework指向一些備用資源。 Database好貴,腦細不會付錢set up多一套,自己電腦不夠強,也不能跑起多個開發用Database。好在還有h2 database可以幫你,它是memory可以操作的。只要你的framework支緩就好。在初次使用Framework時,你總會覺得為何Database層要設得這些抽像,其實為的就是讓你可以隨時換Database。不論做測試還是做移植,都會少很多問題。 模擬Network service還是沒有銀彈,要麼就mockito硬改行為,要麼就是提供一套測試用service。筆者曾經為模擬別人的Network Http API,也花了相當時間自己建立dummy server,提供模擬效果。無論dummy的效果有多假,有多局限,例如if id == 1,always return true,也是有一定價值。當你做source code refactoring (重構),又或是做framework升級時,還是讓你可以安心一點。

Design Pattern: Observer / Subscribers - Push vs Pull
手機‧電玩
MacauYeah・2023-09-29

相信一般入行IT不久的朋友,都會知道IT系統更新時,有推和拉push、pull兩種方式。特別是Programer,對於觀察者模式又或者是訂閱者模式Observer Subscriber 會有更多的使用經驗,例如OS programing要處理event bus,Mobile App要做的推送通知Push Notification。 但一般來說,很少人討論推和拉push、pull的問題,筆者就著一些踩過的坑來說說差異。 首先,在一個通訊相對穩定的系統中,Push、Pull都很好用。例如同一個OS內,它的socket或pipe可以看作很穩定,可以假設那些要廣播的消息可以正常傳遞出好。但好用歸好用,這個模式對於越來越複雜的交互系統都有一個無法明確處理的問題:怎樣去處理觀察者訂閱者自己的操作失敗問題。 對於非IT行業的讀者來說,只要你接觸過手機即時聊天程式IM,如whatsapp, wechat, facebook messenger應該都會遇到一個問題就是:你收到OS提示通知,但打開聊天程式卻看不到新的對話內容;又者是你連續收到多個同一個內容的提示通知,那怕你已經讀過了。這些都代表了,手機端當初時沒有好好即時回應是否已經操作成功,不需要重複通知的問題。有可能是手機當時掛了,也有可能是網絡不太好。 上述的例子,對一般人來說,可能影響不太。因為重複收到訊息,又或是漏了訊息,也不會怎樣。但對於業務系統,例如定期收費,多收一次又或是少收一次,都會引起某部份關係者的不滿,即使事後有退費機制,但有些匯率問題,始終會有差異。在傳統架構上,有規模的公司系統都可能會使用內部的中央資料庫等做交易transaction管理,整個過程,都要嚴謹地記錄廣擴是否成功、觀察者自己的操作是否成功。 在近代,分散式系統又或是微服務的出現,令上述的中央資料庫無法實行。如何好好地重新定義好Transaction管理,就是一大挑戰。筆者最近亦實作了一個要在微服務的上廣播的觀察者模式,但雪上加霜的是,在互聯網的環境下,廣播的消息沒法保證可以正常傳遞出好。觀察者訂閱者可能已經正常收到消息,也做了相應的操作,只是來不及回應,網路就斷了。這令重複發送信號的可能增加了。 如果說,要以平民的方式去實作這類廣播,Pull會比較有大的容錯。廣播者只是通知觀察者訂閱者來拉資料,保證廣播當時的資料量可以盡量地少。廣播者開放盡量大的查閱權,觀察者訂閱者可以自由決定事後更新要取得的資料量。但這樣每個觀察者訂閱者都要重做一次同步機制,不過好處是,主動權在於他們自己手上。 相對地,Push的容錯就低一點,但要付出的成本也跟Pull差不多。因為網路環境,大家要重現一個基於TCPIP而有commitrollback的難度較大。當網路出現斷線,廣播者無法確定是否需要重做。在重複收到訊號時,最後還是需要觀察者訂閱者來決定怎樣處理重複記錄。但比Pull好的是,Push可以限制單次訊號的傳送量,也可以確保觀察者訂閱者一定收到特定的記錄。 上述就是筆者在這一年來遇過的坑,如有什麼不足,很歡迎大家一起來作更多討論。

Git Submodule
科技新知
MacauYeah・2023-09-15

Git Submodule 初次實務上使用submodule來同時管理幾個project的更新。如果有任何理解上的錯誤,請在github中提issue或pull request。 Why Submodule 假設你的團隊中有三個人,A君做A Project,B君做B Project,C君做Main Project。如果可以,A,B各提供已編譯的Binary或Library,給C君直接使用就最好。 但要做到好好管理,A,B都要有自己的發佈系統,即是把Binary上傳到某個分享Repo中,這樣C君就能有條理地通過IDE或Compile工具下載對應的版本。如果是javascript,Repo可能就是npm repo,如果是java,可能就是maven repo。這亦代表A,B君對程式編譯、打包、版本命名等都要很熟悉,不能一輩子都命名為v1.0.0。 如果團隊對這些都不熟悉,C君還有什麼方法呢其實靠著Submodule的功能,C君也可以硬把A,B的Source code取出,做最後打包。 這跟A、B君自己把source code壓縮然後Email寄給C君是有不同的。因為這樣C君並不清楚A,B的git脈絡:C君需要自己做好A、B的版本記錄。想要只回滾A,B的版本普不容易。但經過git Submodule後,C君可以清楚知道現在正使用的是A、B的那一個commit版本。假如有一天,A、B、C三個都更新了,但發現合起來時就跑不動。C君可以保持A、C的版本不變,單獨提取B的某個版本進行測試。當然,你可以說原本Email也可以這樣管理,但始終你不清楚B的版本記錄,Email的日期並不代表Source Code的進度。因為有時候,Bug Fix是針對舊版本的做更新,新功能的Email日期反而比Bug Fix要早 同理,如果大家要連結多個沒有發佈系統的文字資料,也可以利用Submodule。例如筆者正在編輯一本書,當中不同的主題,就是使用Submodule的功能串連起。 Command 馬上看來來Submodule可以怎樣做。 假設你已經知道git 怎樣用,也起了git repo。假設你是C君,進入你的本機repo資料夾內,使用submodule參數。 上面的效果,就是把C君當前repo的狀態,連結到B君submodule當時預設分枝default branch的最後一個commit 中。然後C君在自己的repo怎樣更新,它引用到B君的submodule版本都不會變。 直到某一刻,B君說他加了一個穩定的新功能,請C也連帶更新一下。C君也做好自己的準備後,使用submodule參數進行更新。 注意,如果C君有多於一個submodule,上述指令會全部一口氣更新。另外,如果你覺得B君的最新版本不能用,還是可以針對B君取得特定的版本。

Git Co-Work Flow
科技新知
MacauYeah・2023-06-23

Git CoWork Flow 雖然git面世已很久,但相當一部份澳門朋友都是solo man,很少合作寫code,對git branch始終都有些恐懼。所以這次來解召一個基本原則,至少你不會爛了code救不回來。 若然大家未熟悉git,初次利用git合作寫program,請盡量減少使用共同分支branch,可以極大地減少問題。 第一個大原則 建立一條自己分支 在一個repo中,為自己建立一條分支branch,可以減少Remote repo中有人比你先commit,而令你push失敗的情況。 Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 除非你的隊友故意你用的分支名先commit,又或者你自己有幾台電腦,幾台一起做改動。不然push 應該不會有問題。 第二個大原則 用fetch取代pull 很多人在取用Remote Repo的更新時,都會使用pull。但pull其實是fetch及merge的混合,而且merge還要考慮source branch是那條分支的問題,若然大家都有一條獨立branch,那麼這個無腦pull並不存於每人只有一台電腦下的多人協作中。 fetch的過程中,還可以加入參數prune,順便依照Remote Repo的指示,同步刪掉本機中一些不再存在的originbranch。 Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 第三個大原則 Merge前先Commit 經過前述fetch後,其實他人的改動並未加入自己的分支中,必需經過merge才會出現。但並不是沒有conflict就無腦merge。 假若自己有改動,未commit,應該老虎蟹都先commit。這是為了在merge後,還有機會可以無腦reset,回到之前那個commit。這就像是做任何更新前,先做backup。 Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 第四個大原則 由某個特定的人來管理master或main branch main branch以前叫master branch,是他人下載時的預設分支,也是Github、Gitlab的預設顯示分支。所以該分支存放著的source code,應該在代表信心度比較高。 在協作的環境中,每人都有自己分支,那就代表要有一位人員做管理,他負責checkout main, 然後合併其他已驗證的分支。 Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 在某些比較嚴僅的環境中例如Github、Gitlab,main分支可能會被系統機制鎖定,必需通過系統內鍵的Pull Request,才能通過審核,合併到main。另外,也有一些關於開發上的Git workflow,主要針對功能管理、版本發佈、錯誤修正等控制。有機會再為大家介紹。 希望以上的流程,可以有效且容易地讓大家協作。如果有任何command錯誤或更新,都可以經Github Pull Request通知筆者。

[翻書倒櫃] 最強讀心術?察言觀色的28堂課
文化創意
君尋・2020-10-07

日本的人際互動關係中存在一種「空気を読む」的文化,字面意思是閱讀當下的空氣,亦即是指在溝通的期間,要觀察整個氛圍並推測出對話者字裡行間的實際意思,最終做出符合該場面應有的行動和說話。因此,對日本人而言,察者觀色是在社會上生活的必修的技能。這本《日本頂尖執事教你察言觀色的28堂課》能教會讀者如何善用雙眼,注意以往重未留意到的細節,從而看清實況、找出真相。要成功學會這種技巧,作者認為要把練習觀察,化為習慣,透過在日常生活中遇上的事件鍛鍊「觀察力」、「分析力」和「假設力」。「觀察力」是察覺細微變化的能力;「分析力」是定義觀察後所獲得的想法、整理事物及有系統地思考和歸納的能力;「假設力」是利用上述所蒐集到的資訊來預測未來的能力。本書的28堂課中以日常生活遇到的事件為例子,舉出該注意的細節,以及如何利用這些事件鍛鍊這三種能力。 作者在書中提到的其中一個鍛練方法是,為會議做筆記。會議上夾雜非常多的不必要內容,要學會看穿會議上的重點,以盡量簡短的方式歸納下來。透過長期的書寫習慣,培養看出本質的眼光。作者亦教會我們,如何從座位位置,判斷對方信任的人。同時,亦可透過觀察我方坐下時對方的反應,進一步分析雙方的親密程度。書中教的並非萬能的方程式,而是一種方式讓我們學習「察言觀色」,並透過重覆觀察某個人或事件,讓自己在將來重遇相同的、或者類似的人與事時,能以過去的經驗和當下的觀察,重而推導出在該狀況下如何作出最佳的行動。這種練習不但只在職場,在其他環境也能進行,甚至乎別人家中的冰箱亦是練習對象之一。簡單地歸納,冰箱內的食物反映的是這戶人的健康狀況,內裡的食物量會否過多儲存的是健康還是垃圾食物?這些資訊都可以更進一步瞭解這戶人的生活習慣。「行為改變習慣」,一個人如何使用餐具、文具,可能與其生活水平有關。習慣使用昂貴用具的人仕,行為舉止應相對優雅,因要避免粗暴的使用方式對其造成損傷。當然這只是推論的其中一種方向,若遇到暴發戶則未必適用上述的推論,因此重要的還是要將「觀察力」、「分析力」和「假設力」的練習落實於生活中,不斷的重複練習後發展成自己獨有的能力,才能真正做到觀言察色、聞一而知十,不但有利於職場上的成功,也有利於人際關係。 關於今回翻書倒櫃的推介書本: 書名: 日本頂尖執事教你察言觀色的28堂課 作者: 新井直之 出版社: 商周出版 出版日期:20151107