文章列表

Swarm mode 上線 7 - load balancer | 反向代理

科技新知
MacauYeah・2025-06-30

前述我們介紹了負載平衡器的概念,也使用了nginx作為反向代理,管理網絡訪問,分流到對應的服務上( docker service )。 nginx是穩定的,大家初次使用 reverse proxy (反向代理),請選擇它,因為相對簡單,也易於在單機上做對比測試。 而nginx有個麻煩的地方,就是每次加 docker service,都需要更改 nginx 的設定。我們service 越多,config檔就越長。一個不少心,某些設定有衝突,就會讓 nginx 無法重起。 所以,我們在一定規模後,就需要改用自動化的反向代理。 traefik 就是其中之一。所恨的是,官方沒有提供 swarm 的範例,需要自行摸索。幸好筆者找到一個Github網路資源,bluepuma77 traefik-best-practice,內有一個traefik在docker swarm上的基本設定,足以解開筆者的某些謎思,至少可以讓筆者進行使用驗證。 bluepuma77 提供的範例可能還有些複雜,筆者就再簡化一下,讓大家可以從最基本的環境中開始。 下述 docker service 中 traefik: 自動偵測 swarm 中,有那些其他 service 需要經過traefik 代理。 whoami: 一個官方提供的簡單版http 回應,它正常可以回應 http 80的請求。 有一些重要的地方需要特別說明: 需要設定 --providers.swarm.exposedByDefault=false,不然traefik自己也需要定義反向代理的port。設定了這個,也可以讓 swarm 中某些 service 得以被忽略。有需要經 traefik 對外的,就在 label 下設定 traefik.enable=true 需要設定--providers.swarm.network=proxy,swarm中也需要有該網絡的存在。不然traefik 沒有預設的網絡可以走。 現時 docker service 使用是的 ingress mode,方便 traefik service 可以在不同的 manager 上遊走。測試時需要注意使用 ipv4 ,例如 curl 需要指定 ipv4 的 ip 即curl -v -H 'host:whoami.localhost' http://127.0.0.1/ ,若直接使用 whoami.localhost ,有機會會指向 ivp6 , ingress mode 就接不到。 Reference: https://github.com/bluepuma77/traefik-best-practice/blob/main/docker-swarm-traefik/docker-compose.yml https://doc.traefik.io/traefik/routing/routers/#path-pathprefix-and-pathregexp

重入膠坑 10|JMS(集模社)的馬克兔作品分享

手機‧電玩
MacauYeah・2025-06-26

回鍋模型制作已經好一段時間,亦做了不少的嘗試。但如果大家覺得新嘗試有點怕怕,可以試一試以國産KO(高仿)作為實驗對像。 筆者並不支持KO,因為質量真的有差,但以練手的角度出發,要做很多白老鼠實驗,那麼KO的價錢絕對是一個合適的選擇。可能有朋友會問,做實驗為何不使用廢件?廢件做一些基本實驗是可以的,例如切削、顔料,使用單件就可以做到。但如果要做流程實驗,廢件很難折開重來。比例實在的,還是從零剪件容易一點。實驗的流程可能是板噴、局部取件、打磨+刻線+滲線等。 筆者最近就開了一盒 JMS(集模社)的馬克兔 21世紀配色,主要試一下加深刻線+打磨+滲線配色+水貼的流程。 先上作品圖 外貎很可以 工具 刻線:0.15刻線刀 打磨:400 600 800砂紙、陶瓷推刀 滲線液:田宮滲線液 水貼:KO自帶的水貼 流程 因為水貼原因,原本有打算用司特力的水性滲線液,但在個別區域試過後,就知道會被水貼的水引流的問題,所以馬上改回田宮的琺瑯滲線液。 加深刻線部份,想少錯,就用刻線膠帶,不然出界就要用打磨的方式修正。筆者就懶得貼,所以不少地方都有打磨的痕跡。修正時,感覺上先用推刀刮,再使用600、800號砂紙打磨,後期再消光漆,就已經足夠。有些地方,什至只用推刀,感覺上差異也不大。 滲線液的部份,本次試用黑色,作為大反差配色。個人覺得在馬克兔 21世紀下,效果配色不差,可以跟軀幹部份相對應。 至於JMS品質,真的是練手的好選擇,組合度OK。但我們不能要求關強度,對把玩有要求的朋友請勿嘗試。

如果把一款課金手遊當成單機speedrun遊戲玩會怎樣?04

手機‧電玩
MacauYeah・2025-06-25

ZZ、Seed 2 Lv40 起跳 個人感覺跟之前W差不多,不易,但也不難,原本有經過W的提升,相信大家的自由部隊應該很有實力。再加上ZZ和Seed 2 可以沿用Z和Seed的機體,原本遊戲機制,限制你的出場機體,所可能的影響相對少很多,大部份都可以自動去打。間中有不滿三星的關卡,再強化機體重新挑戰應該都可以達成。 水星的魔女 Lv50 起跳 經過ZZ後,主線關卡後段開放,玩家可以自由選擇不同系列。筆者就選了水星的魔女系列。水星前半關卡不能說是很難,但就是沒法自動取得三星評價,致使本系列SR機體難以開發。那怕你把系列機體升級到50、70,自由系列升級到滿級(80, 90, 100),自動操作都只可以取得二星。主要是關卡中敵方雜兵太強,系列部隊只有送頭的份。筆者回頭重複挑戰,必需轉為手動操作,調配自由組隊(即2隊)才有等級優勢。 為了之後的其他關卡團積優勢,筆者進一步強化自由組隊的機體,魔女系列真的得過扯過。 00系列 Lv50 起跳 筆者自由組隊的機體已有5台主力基本等級升滿,(武裝及突破未升)。在00前期關卡,攻擊力還可以,可以一發攻擊收掉一個敵方機體。但後期則出力不足,自由部組隊也需要協力才能收走對方。更嚴重的是,開自動模式的話,可能會出現我方重要機體被擊破而Game Over的問題。為了穩定,基本也要手動操作過關。00開發路線中,也因為沒有取得足夠的開發資源,筆者在後半亦只有開發出四小強中的三台,實在有些勉強。如果未有遊玩的讀者們,可以試一下別的系列,團一下機體突破資源。 機體數值 雖然每個系列最後都可以最後SSR機體,但因為素材取得難,需要不斷重打困難關卡,而且困難關卡無法用免費/付費課金石去回覆略過次數,所以真要升級只能逐關掛機刷。筆者現況,SSR最多只可以突破至一星(主線首次通關數素+困難關卡的首次完成獎勵),但這個時間成本相當,所以有必要嘗試替補策略。 筆者育成機體不多,就以泛用性以前題下,用兩台seed系機體作為測試 SSR完美突擊,初始90級上限,一星突破,海陸空三地適用。 SR自由,初始80級上限,二星突破,海陸空三地適用。 只看攻擊力的話,SR自由有高一點點,勉強可以作為替代戰力。但防禦力及機動力明顯有差,自動模式下抗壓性不高。需要手動打Combo,以減少自動分散攻擊引發的被反擊問題。日後筆者可能會以其他系列作實驗,粗略計算一下二星SR及一星SSR的時間成本比較。

重入膠坑 9 |加深刻線

手機‧電玩
MacauYeah・2025-06-20

之前就為大家介紹過,想有效率地消除Gunpla山積,事前計劃好一個概定的流程,絕對是件很重要的事。筆者亦有分享一過自己使用取件表的效果,對素組黨是有一定的好處。有時筆者亦會使用極簡版的素組流程,完全制作局部的部件,再進行下一部份,就只需兩個零件盒就夠。 最近,筆者就想再次升級,進行刻線加深再滲線,然後補色,那麼之前極簡版的步驟就不完全適用了。主要因為滲線部份,依據刻線的熟練度及不同顏料的特性,某些步驟要提前,關於顏料的部份可能一次性地使用會更佳。 簡單回顧之前素組流程:剪件→修件→打磨→組合→滲粗線→補色→保護漆。 現在,我們想利用刻線的方式為更多高低面滲線,至少要在完全組合之前就去刻。又因為刻線容錯率問題,刻線出界時,很多時需要利用打磨的方式修正。而且打磨之後,因為表面不夠光滑,水性滲線液比較難以擦乾淨,所以就在打磨之前滲線,可以避免一些奇怪的情況。 現在可以改成:剪件→修件→刻線→滲線→打磨→組合→補色→保護漆。 如果你的是琺瑯漆滲線液,只要刻線夠深,比較沒有擦不乾淨的問題,所以你可以考慮以下組合。 琺瑯漆滲線流程:剪件→修件→刻線→打磨→組合→滲線/補色→保護漆。 到底是先滲線還是先補色,就視乎補色顏料的附著力和互相溶解的問題。道理上補色marker附著力不強,怕在抹滲線漬時同時抺走marker,可能先滲線後補色會好一點。 最後,就再補充一下極簡步驟中,想完整完成一個局部區域再去下一步,這個想法理論上可行,只要大家不計較滲線液、水性漆的消耗率(利用率),是可行的。 全件修件後,之後再全件滲線,這樣滲線性就一次性地使用。這樣可以減少滲線性濃度不一致的問題,也差少在攪拌時出現的浪費(司特力的原裝瓶實在很易出意外,不如田宮的穩定)。補色方面也是,即使是經過調色,如果可以一次性地使用,就可以減少色差和消耗。如果大家不在意這些問題,也就不需要全件完成才進入下一步。即使在全件規劃的情況下,有時還是會因為失誤,而需要反工。

Virtual IP | 為客戶端提供的流動IP

科技新知
MacauYeah・2025-06-11

Virtual IP 雖然我們Docker Swarm、Galera等服務可以很容易地提供到Cluster的功能。但以用戶來講,怎樣知道該連線去那台伺服器,又是另一個問題。用戶不可能逐台伺服器逐台IP去訪問。通常,大家會以為在Cluster服務外部,加個 Load Balancer(負載均衡器)就已經可以解決問題。但其實Load Balancer本身也需要做Cluster,其中一個掛了,別的也需要頂上。那麼用戶到底是怎樣訪問伺服器的? 我們簡單地,可以經過 Virtual IP (簡稱VIP) 來解決這件事。即是把我們網絡服務的域名,綁到VIP上,然後這個VIP可以在不同伺服器上游走,只要有一台伺服器活著,都可以回應這個VIP的請求。而這個VIP的功能,可以經keepalived簡單地做到。 配置 假設我們的配置如下 node 1 IP: 192.168.0.2, network interface: eth1 node 2 IP: 192.168.0.3, network interface: eth1 node 3 IP: 192.168.0.4, network interface: eth1 virtual IP: 192.168.0.5 每個node,都有自己的IP,而virtual IP只會附在其中一台機上。 如果在 GaleraCluster 的情況下,可以看成只有virtual IP剛好附在其上的那台機工作,即是以 active passive 的方式運作。 如果在 Docker Swarm 的情況下,在預設模式下就已經有的mesh IP的機制,即使用virtual IP只在其中一台機上運作,但ingress networks都會擴散到所有機器上,所以是active active的方式運作。 設定 Keepalived 在三個node上,都各自安裝 keepalived。以下以 ubuntu 24.04 為例 # ubuntu 24.04 apt-get update && apt-get install keepalived -y node 1 的 keepalived 設定 # vim /etc/keepalived/keepalived.conf vrrp_instance VI_1 { # change interface according to machine status interface eth1 # one node is MASTER, other nodes are BACKUP state MASTER # all nodes in same group must be same value virtual_router_id 101 # higher 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 # VRRP Advert interval in seconds (e.g. 0.92) (use default) advert_int 1 virtual_ipaddress { 192.168.0.5 } } node 2 的 keepalived 設定 # vim /etc/keepalived/keepalived.conf vrrp_instance VI_1 { # change interface according to machine status interface eth1 # one node is MASTER, other nodes are BACKUP state BACKUP # all nodes in same group must be same value virtual_router_id 101 # higher value will become master priority 99 # VRRP Advert interval in seconds (e.g. 0.92) (use default) advert_int 1 virtual_ipaddress { 192.168.0.5 } } node 3 的 keepalived 設定 # vim /etc/keepalived/keepalived.conf vrrp_instance VI_1 { # change interface according to machine status interface eth1 # one node is MASTER, other nodes are BACKUP state BACKUP # all nodes in same group must be same value virtual_router_id 101 # higher value will become master priority 98 # VRRP Advert interval in seconds (e.g. 0.92) (use default) advert_int 1 virtual_ipaddress { 192.168.0.5 } } 然後在各node上執行。 systemctl restart keepalived 上述設定中,除了 priority 外,應該所有 config 都一樣。state指的是初始化狀態,在 priority 不為255的情況下,即使設定 MASTER 或 BACKUP ,也會動態改變。又因為 priority 不是動態改變的,為方便管理及人眼辨識,筆者認為priority最高的那個node應該預設為MASTER,可以減少日後發生誤會。 如果一切正常的話,192.168.0.5只會出現在node1上。當node1掛了,192.168.0.5才會出現在node2。當node1、node2同時掛了,192.168.0.5才會出現在node3上。這個VIP,同一時間只會出現當時活著的機器中,priority最高的那一台。priority 最高的那一台,它的狀態為MASTER。這些狀態,我們可以經以下指令確認 # confirm state systemctl status keepalived # confirm ip ip a | grep 192.168.0.5 Keepalived 可能的異常 如果 Keepalived 之間無法溝通,每個node都自認為MASTER,192.168.0.5會同時出現在所有node上。這個情況下,網絡請求還是可能的,但當真正出現 failover (故障轉移)時,因為 ARP (Address Resolution Protocol) 等問題,路徑可能無法那上跳到活著的機器上,通常要等個十幾秒才會恢復。在前述的設定中, advert_int 就是各node溝通的時間間隔,以秒為單位。正常若果只有一個MASTER的話,failover可以在一至兩秒內完成。 造成 keepalived 無法溝通的原因很多,其中一個就為設定上的失誤,筆者初期就試過誤設定 virtual_router_id 。在有需要溝通的機器中,應該設定為相同的值。另一個原因則是防火牆,所幸的是 ubuntu 24.04 中, iptables 預設就接受它們之間的連線。如果是其他 Linux 版本,遇到無法溝通的情況,所以先關掉 iptables 服務,或者把 iptables 上的所有 rule 刪掉再試試。

不用Multipass,自動化還有什麼選擇?

科技新知
MacauYeah・2025-05-28

因為multipass 升級同時轉換driver的關係,很久之前筆者介紹的multipass static ip 慢慢開始失效。如果大家只是為了做lab,雖然multipass預設的不是fix ip,但它的dhcp ip並不常更換,在multipass上起VM還是有一定優勢。 但若大家在更大的環境下,不可能有類似multipass exec 的型式去下指令,又或者,我們本地也沒有足資源做VM,必需使用公有雲,我們還有其他可以自動化的方法嗎? 有的。那就最初的ssh。 假設在公有雲,開了三台Linux VM,要作為聯機實驗用。我們只需要再一台Linux跳板機(可以是cloud VM或是local Mac / Linux,就可以順序以ssh為三台VM下指令。我們不需要開三台terminal,在不同VM之間切換,我們是直接在跳板機下指令,也就在跳板機上,實現自動化為三台機進行一系列的設定。 即是如果之前可以經multipass exec 完成的自動化,只要不涉及重置網絡操作,道理上也可以經ssh 實現。例如筆者之前的docker init可以這樣改寫 # local multipass exec -n NODE_NAME -- docker swarm init # remote ssh USERNAME@NODE_NAME -- docker swarm init 抄檔案也可以改寫 # local multipass transfer SOME_SCRIPT_FILE NODE_NAME:. # remote scp SOME_SCRIPT_FILE NODE_NAME:. 也因為公有雲或某些公司網絡,我們什少可以改變它的網絡設定,我們基本只可以使用預留的IP進行設定。不過也因為這樣,我們什少再作出重置網絡的操作。 但大家還是要留意,如果要真順暢ssh或scp,需要預先綁定ssh key。這些預先綁定ssh key的功能,一般在各大的public cloud都會有。如果沒有,我們也可以自動化開始之前,先使用ssh-copy-id為所有VM加入ssh key,這邊筆者就不再重複敍述。 參考資料 https://www.cyberciti.biz/faq/what-does-double-dash-mean-in-ssh-command/

賢者模型工作室模型展

文化創意
MacauYeah・2025-05-23

上週日,賢者模型工作室三週年,同場舉辦了首次的作品展出,筆者當然趁熱鬧去遊覽。這次展覽主要展示了工作室租戶的作品,每款作品的水準一流,無論在打磨、上色還是陰影處理上,都展現了很高的完成度。作為一名全素組玩家,能夠近距離欣賞這些精心制作的模型,是多麼的喜悅。 在展覽中,有一款特別吸引筆者的眼球作品:PG EXIA。 雖然它沒有很高完成度,就是素組加燈改造,但該作品的展出效果,增添了模型的立體感和視覺刺激,令筆者很難不去回想動畫中的臨場感,讓筆者感受到模型製作的無限可能性。 更有趣的是,這位製作人還分享了一個特別的故事,一個關於歷史傳承的故事。因為PG EXIA,推出已經是多年前(2017年)的事,相關的動畫,則是更早期的系列(據WIKI資料,最早於日本2007年首播,最晚於香港2010年完播)。而這位制作人,年紀輕輕,不太可能有接觸過這款作品。 經訪問後,原來該套件是制作人的父親所傳承下來的。因為不忍心看見父親的心意長期被塵封,制作人正式踏入了初階模型師之路。由素組、燈組、造型,逐一完成。筆者也是一名父親,也因為不同原因放下了過去的手藝,即使現也是主要以攝影為主,不再有條件組裝套件。這位制作人悉心地完成了套件的每一個基本處理,相信其父亦會很欣慰,多年收藏的套件終於得見天日。這樣的交流讓筆者體會到模型製作不僅僅是一種技藝,更是一種文化的延續。 總的來說,這次模型展讓筆者收穫良多。筆者非常期待下一次展覽,能夠再次沉浸在這個充滿熱情的世界中!

如果把一款課金手遊當成單機speedrun遊戲玩會怎樣?03

手機‧電玩
MacauYeah・2025-05-19

前兩期筆者分享了前個4個故事線的心得,(連結一、連結二)。本篇分享一些素材關卡及挑戰關卡的情況 之前一直著重解主線,但如果主線無法突破,團素材也是無可以避免的事。首先我們簡單講一講這遊戲的最基本素材 開發素材 通過主線故事取得,可以自動重複刷,但效率很低。解主線時,每一關若得到三星評價,每天可以跳過首三場的重複刷,直接用體力換素材。第四次需要用鑽石(免費或付費的課金道具)重置數次,或者當作普通遊戲,掛機自動刷 基本等級強化素材 分為機體強化、角色強化、支援人員強化,可以經素材關卡取得,但一天只能打三場,不論使用跳過還是掛機刷。也可以隨時間經過,基地會補足一些免費的強化素材。 資本 多種取得方式,但因為通常在資本用完之前,開發或強化素材已經用完。沒有很特別研究它的消耗性。 挑戰關卡-永恆之路 現時筆者經過團素材,升級必要機體,再去通關少量的故事-Hard關卡或挑戰永恆之路Normal關卡,目的是解新手任務,因為完成它可以取得GQX的突破界限(三),突破後會有40%增幅。不過跟前述一樣,這並不一定是最優解,因為GQX是攻擊屬性,未來還要計算一下,是否多台的支緩屬性機體,可以堆到更多發攻擊。 難題 因為之前的Speedrun規則限制,我們無法經過鑽石買體力或重置跳過次數,我們若想取得開發素材,只能盡量在不同的主線中關卡中最得三星評價,取得定量的開發素材。而且等級強化素材的機制,一天有上限,所以若真要Speedrun的話,不可能依靠它們。但現時暫時無解,只能先用正規方式體驗一次遊戲,再計算一下目標機體的最低等級要求,再倒推開發素材的最低要求。 就筆者現時對遊戲機制的了解,Speedrun時,可能只開發SR機體,並突破N或R系列的機體,以達到加成效果。

重入膠坑 8 | HG Mighty Strike Freedom 取件表

手機‧電玩
MacauYeah・2025-05-16

之前就為大家介紹過,想有效率地消除Gunpla山積,事前計劃好一個概定的流程,絕對是件很重要的事。 而流程中,預制取件表,絕對素組檔的一件神器,筆者習慣後,可以極大地減少筆者換剪、打磨工具的次數,也減少找不到零件的機會。 筆者就分享一下自己制作的Mighty Strike Freedom 取件表 (Google Drive連結),有需要的讀者,可以直接下載或列印。 在這邊再簡介一下如何利用取件表作為素組之用 準備粗剪、薄刃剪、打磨砂紙(400, 600, 800號)、十二個零件盒 按照取件表,分區粗剪取件: 完整地粗剪頭部所有零件 放入頭零件盒 完整地粗剪身體所有零件 放入身體零件盒 依次粗剪各部份零件,放入對應的零件盒...... 分區薄刃剪修件: 完整地修剪頭部所有零件 完整地修剪身體所有零件 依次完整地修剪各部份所有零件...... (選擇性)分區打磨零件: 完整地打磨頭部所有零件 完整地打磨身體所有零件 依次完整地打磨各部份所有零件...... 回到說明書,分區組合: 依次地分區組合 (選擇性)記錄需要額外補色的位置。 (選擇性)滲線、補色 於粗坑線條上水性滲線液 Marker筆補色 (選擇性)保護漆 最後一定要提醒,在第4步組合以外,就必需要決定是否進行打磨,若是組合完再拆散,就有斷件風險。亦有因為上述流程不刻線,其實第5步很安全,沒有進一步打磨修補問題。 最後附上筆者速刷前四個步驟的HG Mighty Strike Freedom美照。

如果把一款課金手遊當成單機speedrun遊戲玩會怎樣?02

手機‧電玩
MacauYeah・2025-05-13

筆者近日有繼續測試G世代永恆當作單機Speedrun的可行性。最近就成功挑戰Gundam Seed、Z Gundam, Gundam W的故事。Seed、Z以機體LV 20為起點(可以視為第二章),W則為LV 40為起點(可以視為第三章開端)。因為整體編排還在排列組合中,筆者就以現時的進度,分享一下Seed、Z可能可以逃課的加速玩法。 Seed關卡 由於Seed、Z還是相對前期的機體,可以通過投資自由組隊的機體,以達到戰力補充的效果。但遊戲本身就設計的很考妙,它會限制本篇可以出動的機體數量及類型。以Seed為例,初期就只有三台機可用,駕駛員也不多給你。到中期會因為【宇宙/空中/水面】地型關係,令到機體無法出擊或行動力減半,必需要推進開發【空裝突擊高達】,才可以多場景使用,但如此一來,攻擊力就有取捨。 當初筆者就投資在【劍裝】及【炮裝】,最後被逼著要再來一次【空裝】。如果不追求SSR的完美突擊,Speedrun時可以試兩台空裝+自由高達。因為SSR完美突擊的開發,必需要等打完Seed的Normal終關,再加上劍裝、炮裝、空裝做祭品,才可以煉成,所以對於同一章的Speedrun未必有用。完美突擊還可以經過Seed Hard 第一關取得,不過戰力要求很高,煉成的方式應該更實際。 Z關卡 筆者吸收了Seed的教訓,Z中一遇到不適合出戰的關卡,就即時調整,印像中主要還是缺空戰的機體,向著MK-II的開發路線,選超級高達出戰就可以了。而自由部隊,如果之前有先挑戰Seed的話,它們的空戰系列都可以借過來用,自由高達、正義高達、空裝突擊、完美突擊(註:完後Seed Boss關後,一定會解放SSR相關機體的素材,流星號萬用性能不佳,先投資給完美突擊應該有著數一點) W關卡 因為入場的等級已經升到40,如果前述Seed、Z已經把強化素材用完話,就要慢慢人手挑戰,或等個一兩天,團積一下強化素材,暫時還沒有特別需要注意的策略。 強化目標 最後講講強化素材投資方向,現階段集中等級提升就可以了。首抽及開局送的GQX機,都可以無腦升Lv,之後都有很發揮。而Seed 或Z中機體,升到戰力夠就可以了。而且開發路線有指定最低等級,順著點選就夠用。實在戰力不夠,就算自己鍾愛的機體略為升級就好,筆者就除GQX外,還有投放自由高達、正義高達,主要是兩者都有地圖炮。某些想要拿3星分數的關卡,想避免受反擊的,就靠地圖炮了。而且它們是SR萬用機,不需要挑戰Hard模式也可以取得。

Galera 4 (Mariadb cluster) on ubuntu 24

科技新知
MacauYeah・2025-04-28

前述我們一直在介紹docker cluster,但docker也不是萬能的。某些依賴HDD的程式,而且檔案權限相對有要求的程式,例如:資料庫,用docker去接入共享的HDD (mout share storage),反而更麻煩。一來需要程式本身支援,二來要修改官方docker的初始化程序,過程相關折騰。所以有這方法需求的,都可以先考慮原本的VM做成Cluster。 本文就介紹一下傳統的Mariadb 做成Cluster的方式。老實講,Mariadb 官方手冊可能因為要適配各個不同的OS品牌,並沒有提供一個平台完整的安裝流程。最後筆者也是轉向一些非官方的網絡教學,才成功設定。 Galera 4 (Mariadb cluster) on ubuntu 24 https://www.linode.com/docs/guides/how-to-set-up-mariadb-galera-clusters-on-ubuntu-2204/ 筆者參考上述文章,配合自己測試的結果,以下簡介一下在Ubuntu 24.04的安裝過程 準備3台VM,假設它們的IP為 192.168.0.2, 192.168.0.3, 192.168.0.4 ,確保它們之間的網路可以互通,每一台機都執行以下的安裝script NODE1 192.168.0.2 修改/etc/mysql/mariadb.conf.d/60-galera.cnf, 留意 wsrep_node_address, wsrep_node_name 部份,要與本機相同。 設定好後,我們可以關掉mariadb,經galera 新起cluster的方式叫起它,然後經sql 在內部查看現時成功有加到cluster的機器數量。 應該要看到數量為1 NODE2 192.168.0.3 在node2,跟進述一樣,修改 /etc/mysql/mariadb.conf.d/60-galera.cnf,記得wsrep_node_address, wsrep_node_name要換成新機的值。 設定好後,就重啟mariadb,順便看看現時成功有加到cluster的機器數量。應該要看到數量為2 NODE3 192.168.0.4 在node3,跟進述一樣,設定值筆者就省略了。我們可以在測試一次真實的改動,是否可以同步到其他node。 我們先試在node3加入新的資料庫test1,然後在node2查看是否存在。 node2應該是可以找到test1的,不然就要經過查wsrep_cluster_size看看node3是否成功接入。 然後我們再在node2試試修改root的密碼,看看會不會同步到其他node。 最後node1, node3都需要使用新的password才能登入。 當一切都如預期,你的Mariadb Galera cluster就成功了。

如果把一款課金手遊當成單機speedrun遊戲玩會怎樣?

手機‧電玩
MacauYeah・2025-04-24

很久沒有介紹遊戲了,適逢最近有新的高達手遊推出,筆者親試下,遊戲整體還算不錯。所以打算就來個企畫,試試看用不同的方式去攻略這款遊戲。 以前的手遊玩不下去主要有幾點: 【農】味高,重要資源取得有限,有些需要週期性登入才能取得。登入取得資源,但過程又無聊;不登入又會浪費,多少有點壓力。 課金抽角色+練滿的金錢及時間成本極高,所以錯誤投資角色的成本就更高 所以最近筆者都鮮少有開始新手遊。這次的G世代,也是一款課金手遊,但為免陷入上述的困局當中,筆者就打算以研究Speedrun的角度去切入遊戲。即是不追求完美或者穩定通關的做法,只要本篇的能過關,越快過關越好。除此之外,Speedrun項目一般都會因為有公平性考量,在手遊上會禁止任何課金、什至是抽卡的做法,排除因為錢作怪,而非玩家的技巧。所以筆者也會跟隨這一方面的考量,除首抽可以選取特定的EX高達外,之後一律不會抽卡,即使有免費的抽卡卷或課金額,都不會抽卡。Speedrun也可以設定不同的比賽目標,例如限定從零到第一章結尾,並不一定要直到終章。目標一般會設定為可以重複為主。 這樣的做法可以讓自己免受前述情緒困境之中。 不需要為每日任務、完美過關的免費石而登入。想玩、有空玩時,再玩。 不需要為稀有角色的進一步團積它們的資源,因為它們的資源一般更難最得、更耗時間。 集中於本篇可以取得的機體,以不同的方式實驗不同的戰術效果,取代【農】的策略。 以推進本篇的主線為目標,而非收集角色為目標,也不是以平衝育成角色為目標。即使刪號重來也不心痛。 上圖為遊戲的第一、二、三章節 筆者經過零碎時間,剛通過了元祖本篇的章節,感受還不錯。筆者在開局,主要目標是選擇有【額外行動】、【支援攻擊】的機體為主,其次才考慮【支援反擊】、【支援防禦】的使用。當然這個遊戲推出時間還短,不同的機體取得時間上也有差異,筆者的策略絕對不是普偏的最優解。 上圖為開始攻略第二章所有在主線中取得的機體 如果各位讀者,覺得這個策略可以幫到你保持遊玩的好心情,就一齊來留言分享你的Speedrun策略吧。如果各位讀者想睇到更多關於這遊戲的策略更新,歡迎留言1212,讓筆者知道大家的期待。

Coding Anywhere: 依賴服務的選擇

科技新知
MacauYeah・2025-04-22

年多前,筆者購入steamdeck, 經過一輪軟件定制,把它變成一個可以作為IT從業員開發機的方案,也介紹了一些coding anywhere的想法 https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/14175/Coding Anywhere 工作方案 https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/14352/Steam OS 3.5更新,內建 podman, distrobox https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/14149/開發者在Steamdeck上的另一個選擇: Gnome box 在試驗了一年多後,筆者對於依賴服務的模疑,又有另一層感受。什麼是依賴服務?就像你寫的程式庫,可能需要資料庫儲存、可能需要問AI等等。所以在開發時,都要確保這些服務的存在。一般,要麼就是在本機上自行安裝,要麼就是經過互聯網使用雲服務(public cloud或者你團隊提供的private cloud),也就是本地模擬還是互聯網模擬。 本地模擬的得失 本地模擬,主要是考慮金錢上的優勢與資源的獨立性。 金錢成本 - 互聯網資源大部份都不會是免費的,如果本機的硬件足夠,可以在本地完全模疑,有一定上的優勢。但如果該服務在本地安裝,都要計授權,可能不沒有太大差異,例如那些report engine, report designer,即使本地開發都要逐台開發機計算。但其他大部份,如資源庫的實現,都有本地開發免費授權。所以本地安裝道理上有一定的成本優勢。 資源獨立性 - 當一個團隊共用一些互聯網服務時,可能會互相干援。即使團隊在開發時,可以經profile使用不同的資源,但發生誤用的情況還是很常見。(除非大家已經有一套很健全的開發用profile,只在本機生效,亦只在必要時才會被提升到程式碼的版本控制當中,不會誤會地覆蓋他人,也不會忘了提交。但這是很有挑戰的一件事)。反觀本地模擬,因為那些服務並不會在團隊中分享,就保證不會被誤用。 學習成本高 - 本地模擬,就有一個莫大的痛點,就是學習成本高。我們可以找到很多本也安裝資料庫的教學,本地LLM AI的架設也不少。但我們並不是很輕易地就可以無師自通,有時為了初次安裝,所花的時間成本也大得令人卻步。 coding anywhere轉移成本高 - 因為全部本地模疑,代表我們必需要有一台足夠強大的主機。但如果我們的移動接入點,綁定了在某台特定的強大主機,我們活動空間也相對減少。 互聯網模擬的得失 直接使用互聯網的服務,主要體現於用錢解決問題的優勢 即開即用 - 能用現成的就用現成的。例如你目標是使用mysql cloud database,就直接伸請使用。如果你還要在本地安裝或使用Cloud VM安裝,就還要自行安裝管理介面等工具。因為成本問題,實在要自行安裝,使用cloud vm也有一定的方便性。使用cloud vm 有一定的快取,可以減少安裝所需要的時間。當我們養成自動化的習慣,clould VM 也可以隨時刪掉,有需要才重起。 解決單機無法模擬的情況 - 某性依賴,並不能簡單地經過本地單一部主機去做到。例如我們要模擬一些叢集功能。我們可能要在主機或網絡設備作出一定的調整,才可能提供bridge network。這一點在辦公室網絡下限制更多,不是隨便就可以建一個可以互通,又可以訪問互聯網的環境。另一些如block storage等資源,還會對硬件有一定的要求,也不是軟件模擬就可以做到。我們若不經過互聯網取得,至少也要在團隊下的private cloud上去建立。(不過如果是從零自建private cloud環境,初次投入的成本可能直接使用public cloud 低。 ) coding anywhere轉移成進一步下降 - 作為移動接入點,就剩下那些不可互聯網化的部份,例如domain name,有時還是localhost比較方便,又例如有一些硬件相關開發,硬件部份必需經過本地接入。 就以筆者的個人經驗來講,除非public cloud的價錢實在不可接受又或是自動化幾乎不可能,否則使用public cloud會有時間成本上的絕對優勢。如果要走本機模擬方向,必需要對Container、VM、網絡等有深刻的了解,才會成事。

Swarm mode 上線 6 - 2| 升級陷阱

科技新知
MacauYeah・2025-04-14

上一期筆者就介紹寺過swarm的相容性,可以任意地刪除其中node、加入新的node,系統會自動同步各機狀態。今日,我們就來討論一下加減的流程吧。 實戰輪調流程 假設我們有5個 node,都為manager,各個 docker 版本都為28.0.4 ,我們將要關掉node 5 (ubuntu 22),並加入node 6 (ubuntu24),輪調流程如下 如果node5有vvip,login node 5,關掉vvip systemctl stop keepalived login node1, 把node5降為drain模式,變為worker,並從群集中刪除 docker node update --availability drain node5 docker node demote node5 若然node5不是直接關機、刪除,只想好好地離開群集,可以 login node5, 在node5上預先執行 docker swarm leave docker node rm --force node5 如果之前node5有好好地離開群集,而且狀態已經轉為down,那麼就不用"force"了,用最保守的刪除指令就可以 docker node rm node5 login node1, 取得manager token docker swarm join-token manager node5關機,新增node6,使用相容的ip段,或者使用node5的ip login node6, 加入群集,設定vvip docker swarm join --token xxxx XX_IP:XX_PORT systemctl stop keepalived 這陷阱這陷阱 偏我遇上 上述的操作,有一些可能的陷阱,筆者就剛好踩過,未來不知道會不會有官方保證 docker的版本需要相同,不同版本可能不能加入群集,例如 docker 28.0.4 不能加到 docker 27.5.1。 docker 27.2.x 不能加到 docker 27.5.1。 docker swarm,官方雖然宣稱支援不同版本共存,但這指的是已加入的node,在不解綁的情況下原機升級。 在swarm已有多版本共存的情況下,有一個node選擇完全脫離,它想再加入,也是會失敗的。可能這不是docker自身的限制,而是底層library的相容性問題。筆者在實測不同版本時,就得到這樣的error。docker credentials: cannot check peer: missing selected ALPN property

Swarm mode 上線 6 | OS升級前的準備

科技新知
MacauYeah・2025-04-08

如果大家一直有跟進安全更新,基本上每個一至兩個月,都會有OS kernel和Docker Engine Update。也許大家習慣還是以不變應萬變,但有些時候還是不可避免地遇到嚴重漏動,需要強制更新。那麼當我們在這個情況時,我們該如何做呢?在開始做之前,我們先測試一下Swarm的容錯率有多高。 官方就宣稱,只要swarm中,manager例下的數目沒有超過半數,就依然可以運行。這個部份,筆者相信大家一早就感受過。但筆者認為,在直正出意外的情況是,少於半數的manager倒下了,但其餘的manager又不幸要重啟,到底又些活著的manager,又可否成功重新啟動?所以下面就來做些測試。 測試1 測試REPO 初始化script initDockerCluster.sh 筆者在原本的教學中,就有一個3個manager node + 2 worker node的範例,我們只要安裝ubuntu OS, packer, 並使用 # run setupMultipassWithFixIP.sh will install multipass and config fix ip ./setupMultipassWithFixIP.sh # install packer, please refer to https://github.com/macauyeah/ubuntuPackerImage/blob/main/README.md packer init template.pkr.hcl packer build template.pkr.hcl # initialize docker cluster in multipass ./initDockerCluster.sh 在上述的環境中,node21, node22, node23是manager, node24, node25則是worker。在全關的情況下,只要正常啟動兩台manager,worker就可以成功復活。 測試2 測試REPO 初始化script initDockerClusterLoopJoin.sh 筆者寫了另一個起始方案,會有5個manager node,而且依賴順序如下 node22 => node21 node23 => node22 node24 => node23 node25 => node24 node21 => node22 # initialize docker cluster in multipass ./initDockerClusterLoopJoin.sh 在上述的環境中,5台機也是manager。 initDockerClusterLoopJoin 的前半部份,它會建立順序依賴,即每一台機器,都經前一台機器進行加入的動作。而後半部份會把node21刪掉,並經multipass用一個全新的guest os重起,重新加入到。 在全關的情況下,只要正常啟動三台manager,它們都可以繼續運行。 這個測試的例子表明,即使原本作為依賴的機器死了,只要群齊中其餘多數manager仍然存在,它們也是可以復活的。更重要的是,即使最初引領一切的node21死掉了,什至是被刪掉重來,也是相安無事的。 結論 更新時,最保守的做法,是先加入新的manager,再除去舊有的manager。但這個做法下,manager的IP就不可避免地被改變。若然DNS或者防火牆沒有相應的自動化幫忙,先加入再替換就變得很痛苦了。 而上述的測試,其實代表了我們可以先暫停或移除舊有的manager,更新完後再接回去,這樣部份IP就可以重用。我們只要維持多於原本半數的manager活著,然後逐一替換或升級原有的機器,也不會有問題。即使在升級途中,其他manager不幸地斷線,重啟後它們還是有條件自行修復。我們也不需要顧及更新順序,只需想好Virtual IP的分配策略就足夠,其餘就像是單機升級一樣。