搜尋

搜尋結果

Oracle Database in Docker
科技新知
MacauYeah・2023-09-22

雖然筆者之前有提過,Docker並不是萬能,Docker在管理有狀態應用Stateful Application的情況下,只能走單機路線。但因為Docker實在很方便,所以連Oracle Database這類強狀態應用也有出Docker版本。當然,它在預設的情況下,只能在單機下操作。 不過即使在單機操作下,還是有一些跟其他Docker Image有差異的地方,需要特別拿出來聊聊。 假設根據官方的教學,跑起了一個oracle19c的Docker Container。再查看當中的Process,你會發現有一個內部PID為1的runOracle.sh 在Docker中這個PID為1的Process是很重要的,它是判斷整個Container有沒有運行的依據。它就是當初在Docker Image中Entrypoint或CMD指定的那個指令生起的Process。Docker daemon要進行停止指令,要停止container時,也是對著PID為1的那個process來處理。 一般的情況下,如果PID為1的那個process可以無腦地停了、重開,那一切都好辦。但在Oracle Database的情況下,就不適合。因為Database始乎都是有交易概念的Transaction,它的停止並不是殺了process就了事,它還要考慮HDD操作中,有那些可以被考慮為完成,有那些下次要還原undo、重做redo。如果殺了process就等於Oracle 的Shutdown Abort,有機會下次開機會,就會有交易異常而且無法決定該如何操作。 大家需要先進入Docker container,經sqlplus進行必要的關閉Database指令。但此時,PID為1的那個process,其實還在進行中,在Docker 層面,它就像是Docker Container還在正常運行中,只是Database離線了。又因為sqlplus關閉Database並不是馬上有結果的,所以在整體關閉時可能需要串連command。就像

MHR Sunbreak 體驗日記-3 那些過於硬核的打擊機制
手機‧電玩
MacauYeah・2022-11-18

Monster Hunter系列出了名的硬核,並不是單純的是敵人AI很強、攻擊有多猛,更重要的是對於操作細節的要求。 筆者一開始並不認同MH有很強的打擊感,因為以筆者初入門的水平來感覺,只會感到自己在打牆。在打牆的情況下,不論怎樣有打擊感,都只感覺到被反彈,一點打擊樂趣都沒有。玩著玩著,打到正篇的後期,感覺從打牆變成了打空氣,因為魔物越走越快,越走越遠。大家若想體會打擊感,online組野團可能會比較有感覺。 但這些打牆、打空氣,其實都是制作組故意為之,好讓大家感到有壓力,讓大家嘗試以不同的裝備性能對反制魔物。打牆、打空氣的成因主要是因為累積傷害和DPS的不足所致,雖然打到肉質(弱點)好的位置,但魔物總是有霸體,一手把你反彈走;魔物招式打空了,你想大招反擊,但你大招出來時,牠又剛好走了。 在不斷的熟習自己武器的性能,讓普通攻擊可以恆常地命中後,各積異常狀況就會在魔物身上累積,那怕你拿一把純物理武器,魔物被恆常攻擊後,都會出現倒地狀態。在裝備或貓飯加持的性況下,這地倒地狀態就更容易地在拼刀中出現。那些直正痛快的感覺,就是在倒地後的一波大輸出中體現。 可是萬惡的制作組,怎樣讓你這麼容易地感覺得快樂呢?這遊戲還有一個「打點」的重要設定,一下打歪了,資源就會完全浪費。這是筆者從正篇打到來DLC都還沒有掌握好的東西,欲哭無淚。 玩壞了的MHR 充能斧

電子競技 - 是否會令人沉迷
手機‧電玩
MacauYeah・2020-04-02

最近總是有新聞說,有玩家因為沉迷遊戲和比賽,忽略了妻子家人。有一個案更嚴重,妻子在生死悠關時,醫生要通知丈夫,丈夫當時卻關掉電話以防止被打擾,丈夫回覆時,妻子已過世。 原文事件就不再詳述。不過因為最近疫情出現,大家都只有困在家,接觸電玩的機會提高了,所以筆者更想推廣一些正面的資訊,讓大家更健康地接觸電玩。 首先,競技遊戲與一般單機遊戲的最大差異,就是競技類通常都是online對戰,而且quot;不能暫停quot;。這因為這個quot;不能暫停quot;,令大部份人會覺得玩者就像著魔一樣,完全忽略外界的原因。 但直正的競技比賽,講究的是對策以及練習量,它是一份職業和專業。如果想在比賽中取得成績,需要的是合理的訓練和作息。大部份有成績的選手,都會設定獨立的分項練習和練習賽時間,而不是為了逃避現實去玩遊戲。對認真的人來說,電子競技是一份很花時間的職業和事業,而不是一個脫離現實的避風港。 講了這麼多,其實只是想表達,在正途的路上,這份職業跟其他職業一樣,是quot;沒法quot;令人沉迷。也只有有責任的情況下,選手才能真正向上流動。 如果大家跟我一樣,都支持正常規律作息的電玩活動,咁就快啲一齊黎支持一下本地競技團隊KIX TEAM。 KIX 最近在組織 Clash Royale, Brawl Stars 社群比賽 詳情可見 httpsloot.fvesl.com 比賽時間固定,每日賽程都不會超過2小時。做個好榜樣,不會打深夜遊戲。 重點重點是,比賽開放網上報名,而且世界百大排名選手也會來,想試一試世界級的差距,就一定要來報名看看。 httpstwitter.comkix_teamlang=enhttpswww.facebook.comKIXteam

Docker 101 - 為何要做成Docker (Container - 容器化)
科技新知
MacauYeah・2025-07-21

筆者更新了之前的Docker入門筆記(httpsgithub.commacauyeahVMDockerNotesblobmainDockerConcept101CN.md),順便補充了一些內容。如果各位讀者還在糾結要不要進行容器化,可以看看這些特性有沒有讓你心動。 Container 容器化的便利 1. 做到隔離效果 傳統上,同一機器安裝不同的 lib dependency ,可能出現衝突。在 docker 的環境下,不同 container 之間可以隔離開,除了是網路之間出現引用關係的衝突外,動態庫的衝突就沒有見過。一般處理好 Persistent Volume 的考量,單機下是沒有什麼問題的。 2. 遷移的過程比較簡單 傳統上,要把程式從一台機器搬到另一台機器,要預先安裝好相關的 lib dependency 。但使用 docker container 後,只要 docker 版本相容就好。docker image 本身,就已包括所有的 lib dependency 。另一個常見的傳統問題,就是 Linux 檔案的擁有權問題,特殊情況下,新機同一個 user 的 ID 編號也不一樣,可能要手動恢復權限。如果是 container 的 bind mount 檔案,只要使用 tar command (`tar sameowner xvf file.tar`)保留權限解壓就好。 3. 垂直水平擴容 因為有隔離及遷移方便的優勢,原本的機器達到上限,可以隨時換到其他機器上,修改對應的用戶入口就可以了(或更改DNS,可以更無縫連接)。一台機器不夠,亦可以多台機器一起來。即使不使用 docker swarm k8s 方案,有傳統的 proxy gateway 再加單機的 docker ,就可以做到分流的效果。 當然使用 docker swarm k8s 才是正解,可以更簡化 proxy gateway 的設定。而傳統的分佈式問題,例如 Share Storage 等,其實就沒有簡化到,但也沒有增加難度。所以大家若考慮擴容的問題,更適合考慮使用 Container 的方案。 筆者總結這兩三年來的使用經驗,只要大家一直有用開Linux,其實單機容器化不太難,頂多就是配置外置Persistent Volume Share Storage會帶來不習慣。而大家也可以想,Storage 這問題,是隨時隨地佈署應用程式的不可或缺的思考方式。Docker 沒有帶來更多的麻煩,而是帶來更多標準化的應用,例如傳統的NAS NFS,也是這個Storage問題的其中一個解法。

Docker Image打包建議
科技新知
MacauYeah・2024-07-10

之前筆者有分享過兩個不同的Docker Image打包方式 App直接打包成Image 只把底層程式打包在Image中例如Tomcat,再用Docker Volume的方式讓Container可以起動App。 筆者就兩種方式做了一個條列式的對比。詳見連結 httpsmacauyeah.github.ioAProgrammerPreparesVMDockerNotesDeployDockerClusterCN.html 因為兩種方式筆者都有實作過,也算用了很段時間,所以也有一些實際經驗可以分享。 如果大家上正式的Docker課程,Docker導師通常會推薦為每個App打包成獨立Image,因為底層程式的Overhead通常不大,例如底層程式是Tomcat、Apache、Nignx這類網頁伺服器,重量級的開銷並不是因為多幾個Web Engine的分身造成,通常都是因為業務本身。但如果你講的底層程式是資料庫等的大型程式,才可能會有明顯的差異。 但實務上的建議,就是必需考慮自身的經驗,到底那個方案自己比較有把握。獨立打包App,在正式環境也需要考慮跟蹤問題的情況,多個不同App要溝通,也是了解Container網絡。如果打包底層程式,所有App都可以當成是本機下運行,更有信心追蹤問題,也是一個很好的出發點,到了有需要彈性改變不同App的需要,才轉向獨立打包的做法。 筆者最初也是走這個打包底層程式的方向,到了自己有信心試用Docker Swarm,才走向獨立打包的做法。筆者親身經驗,因為到了Docker Swarm,網段會變得暴增,這跟公司現有的內部網絡相衝的機會就會變多。在Swarm起立初時,筆者並沒有意識到這件事,所以當初排查問題,也花了一些時間才知道要向網段衝突上著手。 另一個出自Docker導師實務上的建議,就是正式環境中不要做用Docker compose,應該使用Docker Swarm。那怕Swarm只有一個節點,也應該用Swarm,導師的主要理據是Swarm有Rolling Update (滾動更新)的機制。同一個node也可以有多個分身,每個分身輪流更新,就不會出現大中斷的情況。筆者就自身經驗,Tomcat可以同時容納一個App的多個版本,Nginx也有Failover(故障轉移)等,如果你很熟這些功能,不一定要需要靠Swarm去提供。可以按自己步調去慢慢適應。