搜尋

搜尋結果

Ubuntu 的簡易日常更新
科技新知
MacauYeah・2025-12-17

早陣子跟新認識的朋友聊天,聽到他們因為要轉伺服器平台,煩惱如何做作業系統層面的定期更新。筆者亦都分享一下自己是如何做 Ubuntu OS 層面的定期維護。 沒錢,就用最原始的方式解決 因為Ubuntu也算是常見的linux品牌,所以基本有有商用軟件可以偵測OS的狀態,並針對它推送更新。不過如果你像筆者一樣,是個貧窮的革命家,那就只有土炮一點自己做鏡像點及做測試。 建立一個 ubuntu 的 deb 包 mirror。手動單次地用步 mirror,確保自己其他 server 同一個時間段都只會取得同一個更新。 停了 ubuntu 的 kernal 自動更新。不然的話,mirror 有更新,ubuntu 亦會偷偷地自動安裝了新的kernal,只是等待你的重啟。 使用一個測試機,先經 mirror 更新到最新的狀態。運行一段日子後,其他機再陸續更新。如果你投産環境有多於一種配置,就考慮要多個不同的測試機。更新指令直接做成 script,方便在其他機器中重複。 輪流 ssh 登入各台機,執行相同的更新指令。更新指令經 git 同步到其他機器。為確保不受 ssh 斷線的風除,必要時還需加入 tmux 。 多機器的煩惱 上述的做法雖然可行,不過當你有十台以上的機器,重複做 ssh, tmux, git checkout, script 互動,也是很累人。考慮一次性地全自動化執行,還是有必要的。筆者對上述的第四步驟,作出一些取捨,以確保更新速度足夠快,可以順暢地執行。 什麼是必需要更新的? 筆者觀察到,在 container 技術出現後,其實很多時安裝應用都不會直接在 OS 層安裝 deb / rpm 包,都是直接經 docker image 去做。所以OS層面,或者很多服務都不會被啟動。筆者亦發現,至少在ubuntu下,只更新kernel,對比無腦全更新所有 deb 包,會快很多很多。 如果可以,我們只更新kernel,再加對應的 container runtime,是不是更新對令相對地穩定,而且可以經外部統一管理。也就是不用在每一台機中進行 tmux + git checkout ,全數在外部推送 ssh 指令? 筆者就用 multipass VM + ssh key,表達一下執行概念。 ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get autoremove -y ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get update ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get install -y linux-generic linux-headers-generic linux-image-generic ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- reboot 上述最大的假設,是第一、三步,更新 kernel 時不會因為網絡問題導致 ssh 斷線,因為它們都是系統級別的改寫,中斷後並不能確保可以重來。第二步就很安全,隨時重來也沒有問題。 這樣,我們就可以在任一台管理機,經過一個 shell script for loop,更新所有其他機器。 如果我們對於網絡還是有些疑慮,我們也可以試用一次性排程式的方式去做。 ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 echo '/your/script/location' | at 08:00 PM 17.12.2025 這樣的好處是,我們可以連 tmux 的開啟也省略,git checkout 也可以經固定的 script 執行(只是很煩鎖)。但這也會有壞處,就是看不到執行的情況,只能事後檢查系統狀態,是否已更新過。 當然前述 ssh key 的方法也可以加入 git checkout 更加深化不同的更新 script,但這又會增大斷線可能。ssh key 還是以快速完成指令更實際。 註:因為網安原因,筆者把上述 script 中的 S U D O 關鍵字去掉,這樣 blog 才能發出。

docker swarm 回到最基礎的群集組建
科技新知
MacauYeah・2025-11-21

雖然筆者都知道,全世界在講 k8s ,全世界都叫筆者放棄 docker swarm,但無獨有偶,docker swarm 還是有使用的價值。 你只有單個服務在運行,只想要做冗餘或分流。快速地用 docker swarm 做最小可行性産品,推出市場。 傳統的HA功能做到了,但你沒有中央匯整日誌的功能。而你也不想把事情攪得太複雜,使用docker swarm 可以讓你在任何一個管理節點上查看不同 container 的日誌。 你的客戶只提供VM,他可能有自己的k8s平台,但不讓你使用。自建一套docker swarm ,先入場,事後擴展再要求客戶提供k8s,對於客戶來講,先證明系統是有價值的,在金錢成本上或能力上,一定是件比較可以接受的事。 筆者之前介紹過一系列的 docker swarm 教學,但生成群集的部份一直沒有做介紹。因為實在太簡單,所以一直都沒有收納在教學內容當中。但現在考慮其完整性,以及為了讓大家感受一下它有多簡單,所以重新寫了組建群集的步驟。 組成群集 以前各家不同的軟件,想要起一個群集,要左攪右攪,又要重啟。而docker swarm真的很簡單,只要各機中有 docker ,再在各機中順序打指令就好。 node 1 使用docker swarm init docker swarm join-token manager # node 1 > docker swarm init > docker swarm join-token manager To add a manager to this swarm, run the following command: docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxx xxx.xxx.xxx.xxx:2377 其餘的管理員節點就根據上述的提示,使用 docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxx xxx.xxx.xxx.xxx:2377 就好。只要總數的管理員節點有奇數個就可以了(包括當初的node 1)。即是1、3、5等都可以。這是因為在容錯的情況下,必需由管理節點作出多數決,才能容易地知道判斷是哪些節點出現問題。 如果不為容錯,只想增加可工作的機器,那麼我們只需要增加工作節點。我們可以在任何管理員節點生成docker swarm join-token worker > docker swarm join-token worker To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-yyyyyyyyyyyyyyyyyyyyyyy yyy.yyy.yyy.yyy:2377 若想要檢查各個節點的工作狀態,在管理員節點上執行 docker node ls 看到了。 docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION xxxxxxxxxxxxxxxxxxxxxxxxx * node1hostname Ready Active Leader 28.5.1 yyyyyyyyyyyyyyyyyyyyyyyyy * node2hostname Ready Active Reachable 28.5.1 全部教學請見 https://macauyeah.github.io/AProgrammerPrepares/VMDockerNotes/SwarmModeCommandCN.html

Tmux - 繼 Screen以後的Linux多工神器
科技新知
MacauYeah・2024-10-08

因為各硬件/軟件的發難,筆者又不得不回到那個只有純純linux tty console的世界。很多時候,那怕使用tty,我們在Desktop mode,也有現代terminal 可以用,需要多分頁,滑鼠選取文字、複制、貼上,都可以輕易做到。 但在mobile / tablet device 上,手指操作真的很不方便。又或者你像筆者一樣,即使有電腦,但要操作一些Linux VM,它們連ssh都沒有,只能直接登入它們的tty,那麼懂得使用Tmux進行分頁及複制、貼上,就變得很重要。 Tmux 是什麼? Tmux 就是可以在Linux Terminal 同一個窗口中,實現多工處理的小程式。就像我們利用多分頁一樣,不同分頁做不同的事。不過最大的差異就是,生成分頁,排列分頁,我們都要使用鍵盤來完成。有時筆者也會用它來作為背景程式,以免不小心關了Terminal就會把所有運行中的指令都停掉。 我們就馬上來看實際例子吧 前置事項: 安裝Tmux及運行Tmux Debain & Ubuntu 安裝: sudo apt-get update && sudo apt-get install tmux 運行:tmux 進入tmux後,你就會至少有一個分頁,而且不會因為Terminal關閘而中斷 用法一: 建立兩個分頁,並切換 增加分頁: 先按 “Ctrl + b” (前置鍵),再按”c” (create) 切換分頁: 在多於一個分頁的情況下,先按 “Ctrl + b” (前置鍵),再按”n” (next) 用法二: 同一個分頁中,建立左右並排的窗口 增加水平窗口: 先按 “Ctrl + b” (前置鍵),再按 “ (雙引號) 切換窗口: 在多於一個窗口的情況下,先按 “Ctrl + b” (前置鍵),再按方向鍵左或右 用法三: 回到前一個tmux session中 因為不小必關閉了terminal,又或是remote ssh中,ssh斷線後,需要回到之前的工作狀態 未進入tmux 的狀態下:tmux attach 要留意tmux 可以有很多個session,要去到指定的session,就要為session命名。但這個不是筆者常用的情境,原本多個分頁已經很夠用,還要多個session,會很混亂。但不排除它在某些情況下有特別用途,有興趣的朋友可以自行挖挖看。 進階: 回頭看過去的terminal screen output 在現代的Terminal中,原本按滑鼠滑輪向上滾,就可以看到過去的資訊,但tmux下反而不行,所以我們需要進入特殊模式 進入Copy Mode: 先按 “Ctrl + b” (前置鍵),再按 [ (開括號中括號) 向上翻頁: 上方向鍵或PageUp 離開Copy Mode: Copy Mode中任何時候按”q” 進階: 複制貼上 進入Copy Mode: 先按 “Ctrl + b” (前置鍵),再按 [ (開括號中括號) 選擇範圍: 移到需要複制的文字起點,“Ctrl + Space” ,然後再移動到結束點,再按”Ctrl + w” 複制 貼上: 離開Copy Mode後,再按”Ctrl + b” ,然後 ] (關括號中括號) 進行貼上 進階: 複制貼上2 某些情況下,我們不允許使用“Ctrl + Space” 或 ”Ctrl + w”,因為它們可能跟系統的組合鍵有衝突,所以需要改為單鍵。 讓tmux使用類似vim的操作模式: echo “set-window-option -g mode-keys vi” >> ~/.tmux.conf 關掉所有使用中的tmux,重開tmux 進入Copy Mode: 先按 “Ctrl + b” (前置鍵),再按 [ (開括號中括號) 選擇範圍: 移到需要複制的文字起點,按單鍵“Space” ,然後再移動到結束點,再按”Enter” 複制 貼上: 離開Copy Mode後,再按”Ctrl + b” ,然後 ] (關括號中括號) 進行貼上 筆者常用的功能就這些,有興趣的朋友可以再深挖一下。 Reference https://tmuxcheatsheet.com/

Github flow 沒有提及的發佈 - 佈署 | Release - Deployment
科技新知
MacauYeah・2024-08-23

不知道之前為大家介紹的github flow,大家覺得怎樣?好用嗎?今天,筆者又來講講筆者心中認為它沒有好好給出指引的地方。 我們的信心指數,其實沒有那麼高 在前文中,經過 pull request 、 code review 、 auto test ,道理上,開發者可以做的都已經做過了,然後就是等待發佈 - Release。 對於單純的庫類型的程式碼,筆者認為,的確沒有事可以再做,實務上就是直接找人其他程多員試用最新版本,看看有沒有問題。只要 main / master 上,明確的表示版本號的變更,就差不多等於直接發佈。有需要提供binary版本的,就還需要觸發上載binary的流程,但這個跟 pull request 觸發 auto test 差不多, auto test 成功後就上載。 對於服務類型的程式碼,例如 Web App 等,直接發佈到正式環境還是有些不妥吧?始終會即時影響到業務,我們至少有個測試場,經用戶做實際的業務操作去驗收。但這個時機,應該是在Github flow的什麼時候做? 在原始的git flow中,有一個叫做 develop 的相對穩定分支,僅次於 main 。它是功能開發完成後第一次pull request 的地方,我們可以用這個概念來做自動發佈到測試場。但若在github flow 中加入了這個 develop / uat / staging 分支,其實就等於複雜地回到過去傳統的 git flow中,對好多新手來講難以接受。Github flow 的成功簡化,其實很大依賴著自動化測試。現在的測試用例,並不再限於單元測試。就連整合測試,也可以經Docker等容器化技術去做,只要我們的自動化測試有足夠信心,就可以發佈。但反觀我們的 Web App 例子,我們認為自動化測試難似涵蓋所有情境,也難以開發。所以我們還在有個時間發佈到測試場,進行人工測試。 pull request + 快速迭代 筆者結合自己的經驗,配上國外討論區 Stack overflow 的內容,筆者認為Github flow上進行 pull request 後,就是最好的發佈測試場時機。所以我們需要盡快進行驗收測試,完成後在Git commit上加上Tag,以示通過驗收測試,可以發佈正式環境的版本。 不過這個模式是有一個很重要的前題假設:快速迭代。當我們驗收完成後,盡可能快地發佈到正式環境,不然會阻礙下一個功能的pull request驗收,或是覆蓋了上一個pull request的驗收環境。 用反面的例子來說明,如果我們有很多功能需要驗收,或變化很多,或存在多輪的里程碑開發,我們就不適宜那上述模式。最保險的做法,還是回到傳統的 git flow ,引入 develop / uat / staging 分支。但如果大家還是那麼討厭傳統 git flow,筆者還是有另一個提議。 既不想回到傳統 git flow ,但又需要慬㥀的考慮驗收發佈流程 如果開發的功能變化比較大,需要多方面協調、測試、驗收,經歷多次里程碑後,才有一個對外發佈的版本,大家可以考慮分開 Repository 做開發。例如: v1,v2的 Repository 完全獨立。 v1 是已發佈的版本,有獨立的測試場,任何即時候需要修正,就在v1的 Repository 做 pull request。 v2 則是未發佈版本,亦有獨立的測試場。加入任何新功能後,就在v2的 Repository 做 pull request,用自己專用的測試場做驗收。到 v2 正式發佈後, v1 就封存處理,再開一個 v3 作為下一個大版本的開發。這個模式,那怕在庫類型的程式碼也用得上。 這樣做的好處是 git Repository 和歷史記錄都會獨立,自動發佈的腳本程也會簡單明確一些。壞處則是 v1 v2 難以做功能對比,我們只能靠人腦記著 v1 有沒有什麼後期加入的修正和功能,需要同步移植到 v2 中 (相對的,著是同一個Repository,可以利用merge 功能確保 v1 有的,v2 都己處理,只是必需要很懂處理版本衝突問題。

型別對程式語言的重要性
科技新知
MacauYeah・2024-07-08

JavaScript等程式語言的流行,好大一個原因是因為它很簡潔。而筆者認為,動態語言的特性,即是可以省略型別,是讓它簡潔的一個很大原因。(動態、靜態與強型別、弱型別並一定對等,詳見Ref) 動態語言的特性,就是同一個變數,在不同時候可能代表不同的數據類型,有時候是String,有時候是Integer。所以編寫時,乾脆就不寫數據類型,因為寫了也可能是白寫。 因此初學者並不需要處理大多導入(import)問題,也不用考慮很多compile error問題,至少程式可以運行一半,到了最後出錯的地方才停下,也就是不會因為型別問題而整個程式開不了。 不過筆者在接觸了JavaScript後,始終沒有大量使用。一來因為筆者慣用的Java,有著更大的基礎套件,改用JavaScript未必有優勢。而且動態語言還有一個長久的管理問題,我們該如何知道更新的影響有多大? 測試用例不是萬能藥 有一部份的人認為,動態語言管理難,是因為大家不愛寫測試用例。的確,若然大家寫的測試覆蓋率足夠多,一定可以預先發現問題。但筆者在Java上實踐了寫測試的習慣一段時間,依賴測試報錯,其實也是後知後覺。 IDE的界入 筆者認為,若想好好地管理程式碼,光寫測試是不夠的,我們還需要好好地讓IDE了解我們的程式碼,認它可以很有效地重構我們的程式碼。更強的IDE,還有機會可以提醒我們有一些設計上問題。 老實講,寫Java多的朋友,都可能都知道Intellij Ultimate的名字。筆者試用後,的確很有幫助。相較之下,vscode對於Java的支援,並不十分智能。但這裏筆者還覺得vscode對於java的編寫、重構、測試,在免費的情況下,都已經足夠是足夠佛心。對於網頁應用來講,vscode差的是對javascript的支援。 vscode對javascript的支援有限,其實不能怪它不夠努力。你想多一個免費的IDE怎樣去了解你的javascript程式? 我們連型別都沒有寫出來,它能怎樣推敲? 實時去模擬各種輸入?CPU又會不會耗乾?那麼寫到一半的程式碼又怎樣輸入? 直到最近筆者採用TypeScript之後,筆者看到曙光了 TypeScript - 一個變相的JavaScript的靜態型別 原本的JavaScript其實也有型別的,只是不強制。若想IDE支援,需要以特定型式寫註解。但這樣寫註解,工作量並不比引用靜態型别來得輕鬆。所以最後,筆者還是覺得直接套用TypeScript,讓自己在每一次引用參數,都要好好地先了解函數的輸入輸出型別寫法。 說實在,從JavaScript到TypeScript並不輕鬆。一些原本很無腦的Axios, Promise, Vue語句,TypeScript寫起上來,都變得很複雜。但這個套用,對於IDE來講,真的很大幫忙。它就像突然讀懂了我們的程式一樣,可以跳入跳出,可以知道在多少處被引用。重構也變得更有信心,而不是等待事後測試報錯。 有一點要補充,TypeScript並不像Java那般需要完全預先宣告型別。例如函數的回傳結果,TypeScript就不會強制要求寫出型別,因為它可以有限度地猜得出來。當然,如果大家願意宣告,就更好。 總結 總括來講,型別就像厠所的衛生情況一樣。初期當然什麼都不處理也可以,但越用越久也沒有人理會,大家也不想用下去。若然大家都願意努力維持它的品質,大家會更有意願重複使用。 參考資訊 「靜態型別 vs. 動態型別」與「強型別 vs. 弱型別」 https://blog.tarswork.com/post/programming-language-type-system Typed JavaScript https://depth-first.com/articles/2021/11/03/typed-javascript/

git 分支整合問題
科技新知
MacauYeah・2024-02-20

不知道大家的開發團隊、專案規模有多大,但只要系統或程式已發佈,同時又要做維護更新,git 庫都至少會有兩條分枝: 新功能 - main / feature 最新的穩定發佈版本 - Release / v1.x.x 最好的情況下,在開發完新功能之前,穩定版本都沒有需要緊急修正的地方,開發者可以專心開發新功能(main / feature)。然而這個情況並不能經常維持。 情況1:有Bug要馬上修正 最常見到的情況,就是穩定發佈版本有瑕疵,可以經過小修小改來止血,由v1.x.x ⇒ v1.x.y,這些可能對用戶來說,是沒有太大感覺的改動。不過對於開發流程,就免不了由v1.x.y整合(merge)回main時,出現修改衝突的問題。 建議 若屬於日後不再需要的改動,不需於整合到main中, 當然什麼都不用做。但若屬於必要的更新,就需要早早整合到main中。整合雖然痛苦,但延後整合沒有好處。以筆者的經驗,每次整合時有衝突,而越早整合越有條件知道該取用自動混合的那個版本。以整合工具的語言來說,就是更容易的作出use mine / use theirs / edit。 情況2: 不同功能之間有衝突 上述情況1,已經算是可控的。主要因為穩定發佈版本都只會接受小修小改,大改都會直接在main中開當為新功能開發。當你有多個很重要的功能在不同時期被提出,而有些功能你沒有信心在下個發佈中提出,你就會選擇以獨立分支來實現不同的功能,最後選擇信心度高、權重也比較高的功能來發佈。這樣的好處是你可以有限時間先完成最必要的功能,但問題是多個功能分支之間,更容易地有衝突,後期也需要很廢心力地整合。 建議 少做資料夾層面的改動,因為git rename的功能並不是萬能的,會令很多git自動選擇版變得不可讀。筆者的經驗,就是錯把後端和前端的資料夾混在一起,令後端的一些重命名影響到前端。前端也因為有重寫的需要,對資料夾結構大改。最後結果就是很多看不懂的git自動選擇版。有一些有選對,但有一些就選錯。 可以做一些事前處理,來減經痛苦。在筆者的資料夾問題情境,在把後端將要整合的多個commit中,挑選最早前沒有命名問題的commit先整合一次。然後前端先手動模擬後端的人工命名,自行commit一次,最後再把後端剩餘的commit再做整合。這個做法不是完全解決問題,但至少可以讓use mine / use theirs / edit更新易理解。 而另一個建議是,縮短發佈週期,逼使其他開發中的功能越早做整合,也逼使每個功能不要做太大規模的改動。如果真的做大規模改動,就要有心理準備要多次重要的整合。 情況3: 多個穩定發佈版本需要同時維護 若然大家面對的工作規模真的很大,同時有多個版運行版本,就如gitlab,每一個月都有一個新功能版本(16.0.x, 16.1.x, 16.2.x,… 16.9.x),但它不會強逼大家更新,對於過去一段時間的功能版本,也會推出安全性更新(前述的x會不斷修正問題)。 這是一個很負責任的發佈模式,不過對於開發者來講就一定很地獄。因為16.0.x的安全更新並不能無痛地整合到16.9.x中,可能每個版本重新人工修改還要來得穩健。 建議 各個分支人工修改可能更適合。最後就是取決於商業政策的考量,到底公司願意為已發佈的功能版本提供多久的支援。就以gitlab為例,其實它也只承諾維持兩三個月前的功能版本。是否會backport到多個月之前的版本,就看問題的嚴重性和backport難易度。 也分享一些筆者朋友的經驗,他們開發的是軟件跟硬件整理的軟件庫。但因為硬件有限制,例如庫的大小、算力的差異,所以最後分支多到爆炸。這也是軟硬整合的痛,問題暫時無解。除非老闆肯放棄市場。

排程執行任務 | Linux Schedule Job
科技新知
MacauYeah・2023-09-07

在Linux底下,crontab是一個最簡單建立Schedule Job的方法。大家用crontab -e 就可以進入設定。 # crontab -e */1 * * * * /opt/run.sh 其中每個星號,順序代表的是分、時、日、月、星期。上面的例子就是不論何月何日何時,只要每一分鐘就執行一次/opt/run.sh Singleton Job 問題是,實際情況下,你想執行程式的時間都不一定會少於1分鐘。所以你總是有機會上一個job未跑完,下一個job就開始了。為了保障自已,需要一些參考機制,去決定是否讓job開始跑。 有些情況,可能你會想用job server去做監管,但若只為單線執行的工作,起一個job server還是會增加管理上的複雜性。 最簡單的做法,就是根據不同的程式語言,使用file lock(鎖上)的機制,先上鎖,再做事。但要注意考慮有沒有出現異常情況,令你自己反鎖自己。即是你的process死了,但不懂自己解鎖,這樣以後你也不能再執行了。 在Linux Bash Shell下,就有一個很簡單的做法,就是使用flock指令。用它的最大好處,就是從OS層面下,去鎖上。只要process結束了,不論正常還是不正常結束,都會自動解鎖。 以下例子就是在執行/opt/run.sh前,先要取得/tmp/run.lockfile的鎖。如果沒法取鎖,就自動放棄執行後面的指令。 flock -n /tmp/run.lockfile /opt/run.sh # crontab -e */1 * * * * flock -n /tmp/run.lockfile /opt/run.sh Timeout 引入singleton的概念後,其實會引發另一個問題。因為異常的情況,還有機會是不生不死,process hang。所以我們還需要設定一個最大的執行時間,讓你的process在異常的情況下,被強行清走。 例如,ping指令在linux預設是永遠不會自動停止的,可以模擬process hang的情況。如果我們想定時從外部收走ping process,就可以使用timeout指令。以下指令就是2分鐘後殺指ping process。 # in file /opt/run.sh timeout 2m ping localhost # to check process id, you could use # > ps aux | grep ping # you will see two different id for ping and timeout 配合errorcode使用,你可能還會在想在timeout時送出一個email通知自已。 # in file /opt/run.sh timeout 2m ping localhost exitCode=$? if [[ $exitCode -eq 124 ]]; then echo "timeout" # enter email alert with timeout elif [[ $exitCode -gt 0 ]]; then echo "exit with error" # enter email alert with timeout else echo "exit normal" fi 配合docker使用,你可能需要考慮signal怎樣傳遞。 在筆者測試的環境中,似乎SIGTERM會被擋,也有可能是SIGTERM太強,它只把前景的docker container run收走,但其內的ping process還在docker daemon中行走。所以最後改用SIGINT,讓docker container run可以好好地把SIGINT傳入其內。 # It seems that docker captured the SIGTERM. Send SIGINT instead # in file /opt/run.sh timeout --signal=SIGINT 10s docker container run --rm pingtest -c 20 exitCode=$? if [[ $exitCode -eq 124 ]]; then echo "timeout" # enter email alert with timeout elif [[ $exitCode -gt 0 ]]; then echo "exit with error" # enter email alert with timeout else echo "exit normal" fi Full demo, github repo cronjobWithDocker

兒童小說 | 陳康妮:啤啤“斷捨離”
文化創意
陳康妮・2023-08-28

本想在週末放假睡個懶覺的啤啤被客廳產生的噪音吵醒了,啤啤不情願地從床上爬起來,懶洋洋地伸了一個懶腰,慢吞吞地走出了房間。原來是媽媽在整理家務,啤啤看見自己小時候玩壞的玩具被一件一件地扔進了袋子裡。 “啤啤!你要是再把媽媽扔掉的東西搬回家,媽媽就真的生氣了!”啤啤的媽媽因為收拾東西已經累得滿頭大汗,看到啤啤又將自己收拾完的東西搬回家十分生氣,媽媽的眼睛裡似乎要冒出一團火。 “媽媽,這是去年夏天小美送我的糖,我還沒有吃呢。”啤啤的手心裡握著一塊已經融化了糖。 “啤啤,就是因為這塊糖,你的一件毛衣上面沾滿了融化的糖,糖已經沒有辦法吃了,就丟棄了吧。”媽媽無奈地說道。 “哦,知道了。”啤啤覺得十分委屈,眼淚像斷了線的珠子一樣流了下來。那些玩具、那些朋友之間互贈的禮物,都是滿滿的回憶呀。 “啤啤,起床了嗎。”媽媽的聲音從門外傳來,“媽媽,要進來了喔。” 熟悉的聲音傳來,啤啤睜開眼睛,“原來剛才只是一場夢啊。” 啤啤看了看房間角落裡已經落灰的玩具,鬆了一口氣。 媽媽端著一杯熱牛奶走進了啤啤的屋子,啤啤覺得自己有些口渴,就立刻喝了一口杯子裡的牛奶。 “啊,好燙!”因為牛奶是剛剛微波過的,十分燙。 “啤啤,小心!”媽媽看到啤啤被熱牛奶燙到,十分心疼。 “媽媽,啤啤沒有事情。”啤啤怕媽媽擔心,立即補充了一句話。 “啤啤,你的眼睛怎麼紅紅的。” “媽媽,我剛才做了一個夢。”啤啤為媽媽講述了剛才做的夢。 “小美送給我的糖十分珍貴呀,為什麼偏要將糖扔掉呢?” “小美和你是好朋友,所以小美才會將糖送給你,但是你因為沒有捨得吃糖,所以糖壞掉了,糖還將一件毛衣弄髒了,所以才要將糖扔掉呀。” “可是⋯⋯” “只要大家記得那份珍貴的情誼,扔掉一塊已經壞掉的糖又會有什麼影響呢,重要的不是糖,而是朋友之間彼此珍貴的心意呀,從某個角度來說,這也是斷捨離。”啤啤的媽媽對啤啤解釋道。 “斷捨離?聽起來好深奧的樣子。” “好啦,現在熱牛奶不那麼燙了,可以喝掉啦。”啤啤媽媽將已經變溫的的牛奶拿給啤啤,“媽媽一定會尊重啤啤的想法,如果啤啤覺得傷心,媽媽是不會將糖直接扔掉的。” “嗯!”啤啤雖然沒有理解斷捨離的意思,但是他感受到了媽媽對他的尊重。 今天的陽光很好,啤啤決定出門散步,啤啤在家附近的公園處,看見了一隻被繫上了牽引繩的泰迪狗。啤啤走到泰迪狗的面前,蹲下來,想要逗一逗泰迪狗。 小動物天生好動,正在等主人的泰迪狗發現來了一位小朋友,十分開心,泰迪狗先是用頭蹭了蹭啤啤,接著就轉起圈來。牽引繩被繫在了一個柱子上,由於泰迪狗的不斷纏繞,牽引繩留給泰迪狗活動的空間越來越少,慢慢地,泰迪狗沒有辦法活動了,泰迪狗“汪汪汪汪”地叫起來。 “泰迪狗,你別著急,我來幫你。”啤啤幫助泰迪狗一圈一圈地將繩子繞回去,可是泰迪狗總是不聽話,明明繞好了繩子,卻因為泰迪狗亂動,繩子又繞了回去,啤啤累極了。 “泰迪狗,你現在不要著急亂動,你又想亂動又想將繩子繞回去,這是沒有辦法做到的,如果你想重新獲得廣闊的活動空間,你就要乖乖聽話。”啤啤耐心地對泰迪狗說道。 這時,啤啤想起了早上媽媽說過的斷捨離的話,他突然發現,斷捨離並不只是丟棄一些東西,斷捨離是在丟棄一些東西的基礎上,獲得更好的東西。就好像是泰迪狗一樣,只有放棄了暫時的自由,才能將繩子繞開,獲得更大的自由。 泰迪狗好像是聽懂了啤啤說的話,慢慢地安靜下來,最終在啤啤的幫助下,繩子終於被繞開。 回到家,啤啤發現媽媽正在收拾衣櫃,因為快要過年了,啤啤媽媽想為全家人購置一些新的衣服,所以想要請一些舊的衣服。由於啤啤成長的十分快,很多之前買的衣服已經沒有辦法穿了。 “啤啤,媽媽將這些衣服清理出來可以嗎?”媽媽詢問啤啤。 “當然可以啦,等一等,媽媽我有東西給你。”啤啤跑回自己的房間。 “這些舊的玩具也一起扔掉吧!” “啊?啤啤,你不是一直捨不得扔掉這些玩具嗎?” “今天不是平日的啤啤,而是懂得了斷捨離的啤啤哦!”啤啤挺起胸膛,驕傲地笑了。 2021年5月29日 陳康妮Miss Chan Connie澳洲墨爾本大學教育管理學碩士愛爾蘭都柏林大學工商管理學士澳門教育家澳門教育專欄作家澳門教育學作家:澳門教育創新澳門國際培訓師(創新創業)澳門兒童文學作家澳門斷捨離學會主席

熊神進:2019年豬年羊生肖運程(附星象)
玄學星相
熊神進・2019-01-12

熊老師提醒:今個流年盤見“白虎”小人星,請不要過份在意某個人,又或過份在乎他/她的一些事,順其自然吧,以最佳的心態面對。每個人的性格中,都有某些無法讓人接受的部分,你我他也是一樣,再美好的人,也有缺點。如果你是愛他,缺點也可以看成優點。 整體運: 吉星 華蓋 凶星 白虎 天雄 天哭 陽刃 羊為未土,豬年為亥水,從命理上講,亥(卯)未三合木,有一定的力量,而土(羊)克水為財,所以屬羊的人今年走財星和貴人運,只可惜“陽刃”是暴力星,代表做生意的人,會遇上同業競爭者割價搶客,最明顯就是在年底的“雙十一”日子。 雖然整體已較去年為佳,但仍要注意容易受金屬所傷,“天雄”是三十六天罡星的第六星,攻擊力大,如果你的姓氏中是“金”字旁,提防中伏。 你自己或雙親的健康會出現問題,因此得好好照料他們和你自己。你容易感冒和發燒,甚至會有毫無明顯因由的精神憂慮。健康問題會困擾著你。 事業運: 《卦辭》上說:“華蓋星甲木,陽木,主孤高,有科名、文章、威儀,入命身宮,宜僧道不宜凡俗。” 華蓋,其實在事業上幫助的力度是有限,只能有利一些從事文職(又稱白領)工作,教育事業的人,這顆星一直以來都是獨行獨往,不喜歡跟人聚在一起,比較性定氣堅,下半年8月1日,水星在巨蟹座(巨蟹座的對應星座是未,即是羊)23度56分停滯並轉為順行,這些日子遇貴人,澳門風水師熊神進認為羊生肖的人8月1日開始事業運好轉,尤其是從事寫作人士,傳媒工作者必定是飛黃騰達。 “白虎”則較為衝擊人際關係,肖羊者除留心會遇上某些脾氣剛烈、無理取鬧的同事,大家在工作中會為了主觀問題而爭吵。今年的小組會議非常多,亦要去回訪客戶公司,在頻密交往中,大家不再客氣,有時候會為了某些利益而爭吵。 女性今年外出工作頻繁,亦要時刻注意道路安全,以免意外受傷。至於“天雄”則是出門後的突發事件,尤其要注意航班延誤、行李或財物損失,建議可預先購買旅遊及醫療保險,亦可於立春後捐血或洗牙,應驗輕微的“陽刃”之災。今年下半年有機會把事業或工作大步地往前推進,要把握時機,積極發展,自當有意外收穫,大展鴻圖。難得的好運,應好好珍惜,上班一族不但不會被裁員,還有利升遷,並有加薪的機會,也宜調動,到新的行業發展。 愛情運: 常言道十羊九哀,今年羊又遇上“華蓋”這孤獨星,桃花來了又走,走了又來,你不享受這種離離合合的遊戲,仿佛自己被坑。對於單身的羊,這不是喜訊年,你必須有意識地尋找,必須佩戴“幸福小狐仙”吊墜,如果甚麼都不做,新的愛情機會也難以來到你身邊。在紫微鬥數中,“華蓋”代表孤傲、孤寂、超然的命象,如果真的不想結婚,就休息一年吧,不要為結婚而結婚。 由於受到“天哭”星的影響,再加上“華蓋”,華蓋是孤獨星,這種心態不值得推廣,懷著這種心態的人,都不會認真對待愛人,愛情的保鮮期很快消失,佩戴“幸福小狐仙”吊墜,還回昔日的愛,憧憬未來的幸福,希望有點兒改變。有的夫妻結婚好幾年,感情時好時壞,今年將面臨巨大的挑戰,費心的維持或者狠心的分開,是一個艱難的選擇。澳門政府註冊玄學家有個請求,希望女生們佩戴“財佛添姻緣手繩”,船到江心補漏難,我們愈早維修愈好。 已有伴侶者,今年的人脈關係很弱,你會留給愛人的朋友/家人一個不好印象,戀愛再不是二人的事,要多關懷愛人的朋友/家人,否則,他們就是你的小人,恐成了婚姻上的絆腳石,如果以戀愛亮了紅燈,則危險了。 “天哭”“陽刃”串在一起就是宮外孕、人流、打胎等愛情的情傷,大家要注意,不要過分床上熱身,如果真的被凶星所傷,請為憐嬰超度及燒“水子地藏香”。 財運: 在社交圈中你會贏得許多尊重與榮譽,玄學上俗稱貴人,也許這些貴人為妳增加財富,你會購買新的住宅,享受各種樂趣。但不要忘記,“天雄”是偏財星,你的財富也不是來自正路,在玄學上,走偏門的人找到錢後必須做善事,例如放生等,否則就受到“陽刃”凶星懲罰。 澳門是全中國唯一合法的賭錢地方,今年“天雄”受偏財星影響,幾乎所有羊人都沉不住寂寞,很想來澳門娛樂一下,筆者熊神進提醒你三件事: 1) 身上不能攜帶虎牙; 2) 家中要佈置五鬼運財局; 3) 同行人不可以是鼠生肖、狗生肖、牛生肖。 很多輸錢的人都說,賭博是不對的,不應該公然鼓吹,亦有離婚的人說,婚姻是痛苦的,同樣不應該公然鼓吹,筆者是玄學家,只是站在玄學角度分析,對與不對,應該交由讀者分析。 除了偏財外,羊的財運又如何?一般來說,“華蓋”利於打工人士,凡事順達,事業有更進一步發展,但宜小心暗箭,遭人陷害,注意勞逸結合,六親無靠。增財運方法:在辦公室或房間放一套“巴西聚寶盤”。 趨吉避凶方法: 1) 眾所周知,北位是文昌星加臨,而命中有華蓋,這些星重疊後產生一種強大力量,你今年有很多讀書機會,可以在學校認識新的有緣人,如果未有戀愛或失婚的人,留心農曆三月,以及農曆十二月,常常配戴“天河石手鏈”會令你明豔照人,桃花旺盛。 2) 財運比較集中在偏財,可以考慮炒股,而愛情飄忽不定,筆者建議你佩帶“財佛添姻緣手繩”,每個人都是犯貪,有了愛情亦想有財,這條手繩經過開光後把財富帶來給你。男生工作壓力大,財運大起大落,見好就收,須防因不測之災而破財,筆者建議你佩帶“怒目羅漢金剛手繩”。 3) 幸運顏色是咖啡色、玫瑰紅、橙色、棕色作為搭配的幸運色。需要顧忌的顏色是黑色。 4)下列年份羊人士要注意: 2015年:沒有病星,只是啼哭星,孩子夜半常哭,又或見到一些普通人見不到的影像,建議小孩在床頭擺放一個“黑曜十勝石小八卦”,減少夜啼星的恐嚇。 2003年:家長可為屬羊小孩報名一些課外輔導,提高孩子的綜合素質。家長尤其需要注意的是,不要因為事業而忽略孩子的感受,多和孩子交流,瞭解他們的想法,對以後的相處有益。 1991年:有利於締結良緣,未婚者應把握每次約會的機會!上班一族則應多加倍努力,自會有貴人提攜,事事稱心。 1979年:今年地位、工作上有新的突破,宜積極進取,財利雙收!事業有更進一步發展。打工一族今年是幸運年,有晉升、增薪之機會,宜充分把握時機,發揮所長! 1967年:今年合夥對你有利,無論是個人還是工作領域。打工一族今年要充分發揮你的聰明才智,必有意想不到的收穫! 1955年:你辦事順利、盡責、品行優良。你還會對宗教或靈性忽然產生興趣。生活中的變動將令你深有感觸,並會持續發生。你會享受著異性的陪伴。至於感情生活方面,則是無比美好。 命運掌握在強者手上,並不是決定在玄學家口邊,以上的運程只是按照2019年九星的進、退,金、水、木、火、土五行相沖、相克、相刑、相合做一個大膽提點,並不是百分百應驗,我們不要迷信宿命,反而要多行善,多關心別人,提升正能量,解除凶星的干擾,從而趨吉避凶,迎接新的一年。 在此澳門政府註冊風水學家熊神進恭祝大家身體健康,心想好事成。