搜尋

搜尋結果

Vmware下建立Docker Cluster
科技新知
MacauYeah・2023-06-16

之前都使用Multipass作為Proof of Concept,自己做測試用。直正上Production,Network環境就多少有點差異。 假設大家為Application Admin,但無條件處理Vmware層面上的事項,只可以從VM內部install setup application。 安裝Docker script 都來自Docker 官方網,筆者微調了一些auto accept選項。 Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 假設三台VM已經安裝docker,ip分別為 10.13.31.21, 10.13.31.22, 10.13.31.23。 在其中一台VM上,例如ip 10.13.31.21上, Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 與前述Multipass不同的是,這裏的datapathport要自定義,因為預設的port 4789在Vmware的有特殊同途。 之後部份就跟傳統做法一樣,先取得manager join token, 然後在其他VM上使用該token加入cluster Code block由於安全性問題,沒有獨立寫了LifeMag 網誌中,請移到github repo。 這樣,在swarm上的application,就會自動在10.13.31.21, 10.13.31.22, 10.13.31.23,上遊走。 即使你的app container目前是跑在10.13.31.238080上,但因為swarm mode routing mesh,你經過10.13.31.218080都可以連到該app。 如果你只是做stateless app load balance分流,這樣就足夠了,不用考慮ip fail over。但如果你要做到ip fail over,還要額外設定keepalive virtual ip,這個virtual ip會自動依付到某台活著的VM上,這樣外界才不會連到一個死ip上。又或者額外建一台load balancer,可以偵測到swarm node上那台機還活著,從而達到fail over效果。但這台load balancer也有一些穩定性要求,若然大家只是用一個普通的nginx做load balance,還是會有單點故障問題single point of failure。

github flow - github 開發流程
科技新知
MacauYeah・2024-06-20

那些年那個很穩定卻又不受歡迎的 git flow 開發流程 多年前,朋友就向筆者介紹git的團隊整操作流程。筆者深思過後,的確實用,那些年的gitflow,很美滿,由開發、測試,到發佈、修補漏動(backport),都有清楚明確的指引。 原作者連結:gitflow 大家如果沒有更複雜的需求,真的可以照搬,筆者也很推這一個模型。 但在長期推廣下,筆者發現大部份人其實都不熟git的基本操作,什至連git graph也不看,現在看git flow,就更不可能接受。那怕是有常用git的個人團隊,也是不怎使用分支模型。 前一兩年,筆者也不懂,筆者也努力地簡化git flow。例如把master和develop合而為一,但最後也是少有人可以接受,很多人還是卡在分支那邊,對checkout、merge還是很陌生。在跟更多不同人的協作過後,筆者總於意會到一件事。其實大部份人,只想知道最後、最新的狀態,只會更新 master main ,也因為個人開發,所以連衝突也不會有,更不需要使用merge。那怕是少型團隊,頂多也是維護main的衝突,間中用用merge,而checkout還是用不著。 其實這個情況,並不限於小型團隊。因為 web app 和 DevOps 的流行,所以越來越少機會要維護多個舊的穩定版本。大家都專心於最後一個開發及發佈版本就完事,用戶的某個版本有問題?更新到最新版本吧。(註:越底層的應用開發模式,因為相容性問題,不可能只保留一個穩定版本。) 那麼我們就大力簡化吧 github flow 開發流程 既然大部份情況,大家都只在乎 main master 預設分支,那我們也沒有必要跟著複雜的 git flow 走。但在 DevOps 的角度下,為保證 main master 穩定性,大家還是至少要遵守branching 、pull merge request 、code review 、auto test 原則 。 github就最簡單的branching 、pull request 、code review 提出了它們的 github flow。 簡而言之,就是每個人在開發時,都先從 main 起一個新分支,不斷更新。待合適的時候,就透過 pull requst,向原項目負責人提出申請,只要項目負責人點頭,就可以把改動傳入 main 中。又因為Github 原本的定位在於個人與個人之間的協作,初時已經需要通過fork建立獨立的倉庫,那怕你不愛分支也必需分支。所以 pull request,code review 的作用更明顯,後逐的協作更理所當然。 但若果回到公司團隊協,Github flow 就應該像筆者之前提出協作方案,各自起分支,最後由某個人守門,把所有結果放到 main 中。(前文連結)

《周柏豪2017巡迴演唱會 澳門站》
音樂聯合國
LifeMag Editor・2017-08-08

《周柏豪2017巡迴演唱會 澳門站》將於2017年10月21日 在澳門威尼斯人金光綜藝館登場 演唱會門票於8月11日起公開發售 香港實力型男歌手周柏豪將於10月21日在澳門威尼斯人reg;金光綜藝館為樂迷帶來由澳門威尼斯人、樂福文化、香港樂福娛樂、智樂文化聯合主辦,璨思文化協辦的《周柏豪2017巡迴演唱會 澳門站》。門票將於8月11日起透過金光票務售票處公開發售。 身兼作曲家、歌手及演員的周柏豪於2007年加入樂壇,曾推出多張暢銷的專輯,其代表作有首支出道歌曲《同天空》、第二首單曲《六天》、以及與香港女歌手鄭融合唱的《一事無成》。 周柏豪希望藉著今次演唱會帶出一直以來抱持的信念,與歌迷真誠地分享其努力的成果。《周柏豪2017巡迴演唱會 澳門站》不單回顧柏豪出道十年的歷程,以及見證其音樂與人生的成長,亦是一次感謝祭,藉此答謝他的歌迷、台上的音樂與舞蹈團隊、還有最重要的家人。歌迷可在欣賞柏豪表演多首感動的經典歌曲的同時與他一起分享滿滿的回憶。 於2017年10月21日親臨《周柏豪2017巡迴演唱會 澳門站》,在現場感受香港流行歌手周柏豪的音樂才華及魅力。 ICBC金沙時尚萬事達卡持卡人於是次演唱會可享高達8折的門票優惠,更可在全球各地旅遊之同時購物簽賬賺取積分,於澳門金沙度假區內換領獎賞。 演唱會詳情: 活動 周柏豪2017巡迴演唱會 澳門站 日期及時間 2017年10月21日(星期六),晚上8時 場地 澳門威尼斯人 金光綜藝館 票價 澳門幣 港幣 1,080元 (VIP 區) 澳門幣 港幣 880元 (A 區) 澳門幣 港幣 680元 (B 區) 澳門幣 港幣 480元 (C 區) 澳門幣 港幣 280元 (D 區) 船票套票 觀眾可另加澳門幣港幣108元購買包括金光飛航往返港澳雙程船票的套票 售票處 金光票務 網上訂購:www.cotaiticketing.com 售票處: o 澳門巴黎人 ndash; 一樓正門大堂售票處 o 澳門威尼斯人 ndash; 金光綜藝館及酒店正門大堂售票處 o 澳門四季酒店 ndash; 百利宮trade;售票處 o 澳門金沙reg; ndash; 一樓售票處 o 金沙城中心 ndash; 喜來登酒店正門及假日酒店正門售票處 電話訂購: o 澳門熱線:853 2882 8818 o 香港熱線:852 6333 6660 o 中國內地免費熱線:4001 206 618 澳門廣星傳訊 網上訂購:www.macauticket.com 門市據點資料請瀏覽:www.macauticket.comTicketWebServiceStations.aspx 電話訂購:853 2855 5555 香港快達票(將額外收取每張門票的顧客服務費) 網上訂購:www.HKTicketing.com 電話訂購:852 31 288 288

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通知筆者。

十大日本賞櫻排行榜:No.9 京都嵐山風景區
走遍世界
環球旅人 // BJM・2016-02-29

大家去日本京都,會不會想起去感受一下大自然之美呢?我相信如果大家有充裕的時間,絕對會將嵐山風景區寫入你的行程之中,原因是嵐山真的非常美,而且又可以搭乘小火車穿梭行走景區,是很愜意的一件事。 當然,賞櫻季節也不少得嵐山的份,因為嵐山除了秋葉出名之外,櫻花同樣很有看頭的,如果不去這裡,絕對是可惜的。 由日本國家旅遊局嚴選出來的第九位,就是嵐山風景區賞櫻啦! 嵐山(日語:嵐山)是日本京都府京都市的一個觀光地,以賞楓葉(秋季)和櫻花(春季)而知名。「嵐山」這地名原本是專指位於桂川右岸、屬於京都市西京區一部份的嵐山地區,而河對岸、屬於右京區的地區則名為嵯峨野,但近年來許多觀光導覽資料都概括性地,將以橫跨桂川的渡月橋為中心之河左右兩岸周邊地區,合稱為嵐山。 位於京都市區以西的嵐山自平安時代以來就是許多貴族的別莊所在地,其名稱經常出現在歷史故事與古典文學作品之中。由於桂川河岸在每年春季與秋季都有大面積的野生櫻花與楓林可觀賞,因此長期以來也是觀光旅遊的熱門點之一。整個嵐山地區是以橫跨桂川的渡月橋作為中心,這條橋的命名起源於龜山上皇的一句「似滿月過橋般」的詩作而得名,雖然外觀上渡月橋有著木橋般的造型,但今日的渡月橋實際上是座鋼筋混凝土構造、能夠讓汽車行走其上的現代化橋樑,只是採用復古的木製護欄以配合周遭的景致。在渡月橋附近的桂川河段習慣上又被稱為大堰川(おおいかわ)。 除了自然景觀外,嵐山地區也是很多日本知名古剎神社的所在地,與多位古代日本天皇的安葬之處,因此前來此地參拜廟宇神社也是遊客主要的觀光重點之一。在諸多神社廟宇之中,地位最重要的應屬名列世界遺產名單的天龍寺,除此之外像是曾經出現在日本文學名著源氏物語中的野宮神社,與收藏有日本國寶級佛像的清涼寺,也是非常重要的歷史建築與景點。 嵐山地區有多條鐵路路線通過,而利用JR山陰本線改線之後遺留下來的舊路線,所改築而成的嵯峨野觀光鐵道線,是一條沿著保津川(桂川部分河段)河谷行駛的觀光鐵路線。除了冬季停止營運之外,每天都有固定的觀光小火車(トロッコ列車)自嵐山地區的小火車嵯峨車站(トロッコ嵯峨駅)與小火車龜岡車站(トロッコ亀岡駅)出發,往返於嵐山與保津川下游的龜岡之間。

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 。 以下就是一個最簡單的例子,最前端的 httpgateway nginx 對外公開端口 8080 ,它根據 virtual host,去分派對應的請求去 dmzhttp bretfisherhttpenv 及 managerhttp bretfisherhttpenv 。構架圖就是以下這樣。 ┌───────────┐ ┌──────────────►│ dmzhttp │ │ └───────────┘ │ ┌───────────────┐ │ httpgateway │ ────────►│ nginx8080 │ └──┬────────────┘ │ │ ┌─────────────┐ └─────────────►│ managerhttp │ └─────────────┘ 換成 docker stack ,就大概如下 services httpgateway image httpgateway ports 80808080 deploy replicas 1 update_config delay 10s restart_policy condition onfailure dmzhttp image bretfisherhttpenv deploy replicas 2 update_config delay 10s restart_policy condition onfailure managerhttp image bretfisherhttpenv deploy replicas 3 update_config delay 10s restart_policy condition onfailure docker stack有一個很好的功能,就是 service 名會自動成為同一段網絡中的 hostname 。即是httpgateway中,它可以經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_manager8888$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_dmz8888$request_uri; 上面的例子中,就是一般的 virtual host nginx proxy 設定。特別要說明的是 resolver 那一行,它指向 docker DNS 127.0.0.11, 而且還可以讓nginx在找不到上游時,不要馬上死亡。這樣 docker swarm 中各個 service 隨時加加減減,有保命的作用。 最後我們的 httpgateway 就是 nginx image default.conf 上述的 docker 就可以用以下方式打包。 # Dockerfile # docker image build t httpgateway . FROM nginxlatest COPY default.conf etcnginxconf.ddefault.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 labeladd zone=manager YOUR_MANAGER_NODE docker node update labeladd zone=dmz YOUR_DMZ_NODE 然後我們通過修改 docker stakc 中的 placement gt; constraints ,限制不同的 service 在不同的節點上運行。 services httpgateway image httpgateway ports 80808080 deploy replicas 1 update_config delay 10s restart_policy condition onfailure dmzhttp image bretfisherhttpenv deploy replicas 2 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==dmz managerhttp image bretfisherhttpenv deploy replicas 3 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==manager 使用上面的例子,我們就可以達到簡單分離的效果。但大家緊記,這個分離效果始終是一個規則式功能,它與防火牆的隔離還是有本質上的區別。除了利用傳統的防火牆技術外,我們的docker swarm network,其實也可以做更多隔離,我們日後再慢慢加強這個例子。

本週手遊重點推介 2021/05/17-2021/05/23
手機‧電玩
MacauYeah・2021-05-24

二之國 quot;二之國quot;一直在主機平台都有不錯的表現,從JRPG來說,它的畫面和音樂,都是一個美妙的特別存在。現在終於到開發手遊版本啦,而且事前預約開始左啦,並於6月10日於港澳台同步推出。 大家快啲預約,在手機上感受宮崎駿的美妙童話世界 https2worlds.netmarble.comtw httpsyoutu.beFyNA15a8q6o 本作除了繼承主機系列的畫面和音樂之外,還由傳統的故事劇情改為MMORPG,讓玩家之間有更多的互動。 槍彈辯駁 另一款要解紹的,同樣是主機平台都評價不錯的槍彈辯駁系列。不過這不是一個免費+課金的手遊,而是切切實實的買斷式遊戲 玩過主機版的Youtuber都會話你聽,這是一個劇情推動的遊戲。(手機版未經測試,可能與主機版有點不同) httpswww.youtube.comwatchv=aTZNn6PMA0Q 筆者也過去在評價遊戲時,一直都很著重性價比的問題,如果以原本主機版4XX MOP價錢來說,當然不會推薦給大家;但比起主機版價錢,手機版的價錢真的很吸引,14.99 USD,兌換起來,也才130MOP以下。不論怎麼看,也是一個值得收藏的選擇。 皇輿爭霸 Dominion 卡片桌上遊戲《皇輿爭霸 Dominion》將於 2021 年登陸 PC、iOS、Android 平台 皇輿爭霸跟三國殺一樣,原本都是桌遊,但大家都不滿足於桌遊版本,從而發展到電子平台上。其實它的桌遊版本早在2008年就已經推出,在遊戲背景上,它讓玩家建立自己的王國(牌組),玩起上來更像大富翁的以持有資源,讓對手失去競爭力的方式來推行遊戲。它比大富翁有更多的牌組,也能更體現出連續技的操作。 從2019年末,大家就因為疫情關係,減少外遊的比例,原本有玩開桌遊的朋友,也絕對是受影響的娛樂之一,受桌遊的朋友,不防就趁著這個機會入坑電子版桌遊,本作還是以基本遊玩免費的方式營運。實在可以大大地為大家止止桌遊癮。