cloud

標籤:cloud

龐大的Docker Logs該如何處理? | 傳統的syslog幫到你

潮流特區
MacauYeah ・2024-02-02

平常大家在做單機app時,寫log有很多選擇,最簡單就是寫在檔案中。但在docker container裏面,寫檔案時要注意怎樣保留log檔,避免因為重建container時不見了。 docker 大部份官方預設image,都把log導向至stdout和stderr。這是方便docker做管理,也方便大家使用統一的docker logs指令來查看,即使到了Swarm mode底下,docker service logs也是同樣原理,使用差異不大,頂多就是不保證log的實時性。 如果網路延遲不計較的話,最大問題也是logs怎樣保存的做法。預設就是container刪走的時候,logs也會一借走。單機模式下,沿用最普遍的方法寫log的做法不是不可行,只是考慮到在極端情況下,同一個node(節點)中,有可能同時運作同一個service(服務)的多個分身(replica),這裏它們寫檔案時就有機會互相搶佔。 筆者認為,比較合理的是外部提供的服務,例如syslog,把寫檔的操作交給節點的Host OS處理。然後就保證好每筆log都會是一條完整的記錄。 以下就以linux Host裏面的syslog,為大家簡介一下設定的步驟。 設定docker 導向 syslog 把該主機的docker daemon (/etc/docker/daemon.json),設定使用syslog driver,並以特定的方式編寫syslog tag。 { "log-driver": "syslog", "log-opts": { "tag": "dockercontainer/{{.ImageName}}/{{.Name}}/{{.ID}}" } } 無腦設定已完成,重啟docker就可以了。 但為了日後管理方便,能把docker log放進獨立的一個檔案中,會更易找問題。所以我們可以進一步設定syslog。我們以Ubuntu 22.04為例,可以在/etc/rsyslog.d/下增加一個設定檔(/etc/rsyslog.d/*.conf),指定看到syslog tag以dockercontainer為首的記錄,都要獨立抽出來。 # file: /etc/rsyslog.d/51-docker.conf :syslogtag,startswith,"dockercontainer" -/var/log/dockercontainer.log 為免有檔案權限問題,手動指定檔案的所有權後,才正式重啟syslog。然後所有相關記錄都會寫在/var/log/dockercontainer.log 滾滾滾滾滾動的log檔 檔案一天一天地長大,如果可以,還是自動清掉太舊的記錄為妙。Linux Syslog,通常也會配著logrotate使用。 筆者亦以Ubuntu 22.04為例子,做了個最簡單的自動滾Log功能。目標就是當log檔案大於1M後,就要重開log檔。舊的log檔最多保留7份,多了就刪掉最舊的。 # file: /etc/logrotate.d/rsyslog-dockercontainer /var/log/dockercontainer.log { rotate 7 size 1M missingok notifempty compress delaycompress sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript } 加了設定後,什麼都不用重啟,因為它是Ubuntu 的排程動作,到執行時就會以最新的設定檔執行,詳見/etc/cron.daily/logrotate. 有需要手動測試的話,需要手動呼叫/usr/sbin/logrotate。加入-d參數後,會被視為debug mode,這是官方的說法,但因為debug mode沒有執行效果,更加像是linux中常見的dry run mode。

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。就像

Docker Swarm mode 指令教學 | docker service

潮流特區
MacauYeah ・2023-08-22

之前一直都討論Image 的打包形式,現在聊聊部署上線時的一些指令。 Docker Service swarm mode 主要通過"docker service" 指令去產生一堆可以在不同節點上運行的container。為了更加形象地講,我把container稱為Image的分身。 docker service create跟docker container run的感覺很像,兩者都可以指定image # swarm mode $ docker swarm init $ docker service create --name nginx_s nginx # container mode $ docker container run -d --name nginx_c nginx 兩者的差別在於docker service 可以指定多少個分身,可以隨時加減數目,而且如果你有多過一台機器,分身就會在不同的機器上遊走。而docker container就是只對本機有操作,也不會散播到其他機器。 # swarm mode $ docker service create --replicas=2 --name nginx_s nginx $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS uro4rwy6nelh nginx_s replicated 2/2 nginx:latest $ docker service update --replicas=5 nginx_s $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS uro4rwy6nelh nginx_s replicated 5/5 nginx:latest # container mode $ docker container run -d --name nginx_c1 nginx $ docker container run -d --name nginx_c2 nginx $ docker container run -d --name nginx_c3 nginx $ docker container run -d --name nginx_c4 nginx $ docker container run -d --name nginx_c5 nginx $ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c45771f06612 nginx "/docker-entrypoint.…" 7 seconds ago Up 6 seconds 80/tcp nginx_c5 a587a718da3a nginx "/docker-entrypoint.…" 9 seconds ago Up 9 seconds 80/tcp nginx_c4 079f206f8645 nginx "/docker-entrypoint.…" 9 seconds ago Up 9 seconds 80/tcp nginx_c3 e10dc525fd22 nginx "/docker-entrypoint.…" 10 seconds ago Up 9 seconds 80/tcp nginx_c2 dcaa2b4bb3de nginx "/docker-entrypoint.…" 10 seconds ago Up 9 seconds 80/tcp nginx_c1 在建立網段時也差不多,service需要的是overlay network,而container用一般network就可以。 # swarm mode $ docker network create --driver overlay nginx_s_gateway $ docker service update --network-add name=nginx_s_gateway,alias=gateway nginx_s $ docker service ps nginx_s ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS fxqtheyvr914 nginx_s.1 nginx:latest dockertest Running Running 33 seconds ago u0pvj1leoizw \_ nginx_s.1 nginx:latest dockertest Shutdown Shutdown 33 seconds ago q7arumjlxduv nginx_s.2 nginx:latest dockertest Running Running 36 seconds ago kurlwqfmopbg \_ nginx_s.2 nginx:latest dockertest Shutdown Shutdown 37 seconds ago zd0zlkhxafv0 nginx_s.3 nginx:latest dockertest Running Running 40 seconds ago 3kapr00fs6pt \_ nginx_s.3 nginx:latest dockertest Shutdown Shutdown 40 seconds ago 5o4afd3whygo nginx_s.4 nginx:latest dockertest Running Running 35 seconds ago oxocropolbo8 \_ nginx_s.4 nginx:latest dockertest Shutdown Shutdown 35 seconds ago x5y94jf3ok51 nginx_s.5 nginx:latest dockertest Running Running 38 seconds ago cgld3au0w1i9 \_ nginx_s.5 nginx:latest dockertest Shutdown Shutdown 39 seconds ago # container mode $ docker network create nginx_c_gateway $ docker network connect --alias gateway nginx_c_gateway nginx_c1 $ docker network connect --alias gateway nginx_c_gateway nginx_c2 $ docker network connect --alias gateway nginx_c_gateway nginx_c3 $ docker network connect --alias gateway nginx_c_gateway nginx_c4 $ docker network connect --alias gateway nginx_c_gateway nginx_c5 不過比較大的差異是service會停了原有的分身,重開新的分身去加入網段。所以上面的docker service ps nginx_s執行結果,就有一半是停掉的。 類似地,docker service也不能單獨地停掉分身,頂多只能調整--replicas=NUMBER,來控制分身數量。而單機則可以經過docker container stop來暫停分身。

Docker打包 App還是打包底層程式作為Image ?

潮流特區
MacauYeah ・2023-07-28

雖然筆者對於Docker Swarm Mode的資歷尚淺,但由於後期更動的難點越來越多,筆者很想早一點討論其中不同操作的差異 Docker Swarm Docker Swarm Mode其實是Docker提供的一個Cluster(群集)環境。在其中運行的Image,都可以比較方便地隨時分身到不同的node(節點)上,對於提高負載或可用性,都是一個不錯的解決。 只要該Image跑起的Container是Stateless(前後兩次執行的結果互不相干涉),或者是把Stateful的部份(有干涉的部份)外包到第三方(例如儲存空間使用NFS,或記憶體暫存改為Key-Value Database),就可以方便地運作在Docker Swarm mode上。 部署Docker Swarm的選項 Docker Swarm可以把Image變成分身Container,但並不沒有硬性改變傳統App操作方式。大部份App在執行時,都需要另一個底層程式的支緩。例如 Php Web App,需要底層php fpm + nginx或apache Java Web App,就需要java + Tomcat 所以在發佈App時,可以選擇把 App直接打包成Image 只把底層程式打包在Image中(例如Tomcat),再在跑起Container時再動態接起App。 兩者有何差別? 就信心層面上,一定是把App直接打包成Image實際一點。因為這樣可以極大地減少測試環境和正式環境的差異而出現的問題。筆者一開始也不完全讚成,但也越來越傾向這種做法。 在解釋筆者為何有這個結論前,先條列式地對比一下兩種差別。 事項打包App成為Image打包底層程式成為Image 打包複雜度 需要把App用到的一些環境變數引入設定Image的entrypoint中,方便配合不同的環境可以改變App的行為。打包次數根據App數量有關。比較靈活,但比較需要學習和試錯。 底層程式統一設定環境變數,其中所有App都會使用類似或相同的設定,設定方式跟傳統方式無異。打包次數根據底層程式數量有關。比較死版,但要試錯的成本較低 發佈流程 打包App成Image。再靠Docker Swarm設定Image有多少分身,每個分身不需要特別再設定。 原來的底層程式已存在於Docker Swarm中,只需把新建或更新了的App放入不同分身的儲存空間,讓底層程式動態跑起App。 管理複雜度 每個App都是獨立的,代表有任何更新也是獨立更新。在微服務的協作環境中,需要管理員從Image層面為每個App設定網絡(network)或開放端口(Port)。但每個App可以設定不同的分身數量,靈活性一定比只打包底層程式要高。 使用同一個底層程式Image的App都會使用同一個網路和端口設定。在微服務的協作環境中,管理員要應付的設定數量一定比打包App要少。但由於是Conatiner分身是針對底層程式,所以若然某個App有不同需求,就要重新設定另一套底層程式。 上述幾個點,最後其實都是複雜度和靈活度的取捨。雖然打包App的工序更多,但提供的靈活性也更多。如果考慮要從傳統模式中過渡,方便與完成不懂Docker的同事協作,就首選打包底層程式。如果考慮可重複性和信心保證,還是打抱App比較直接,要複制一個環境到另一個環境,也比較易測試。

自己架設Docker的共享儲存空間

潮流特區
MacauYeah ・2023-07-21

Docker很好用,在單機環境下真的很好用。Docker原本的設計,是為了快速迭代而設計成Image的。在一般設定下,每次新建或重建container,都會根據Image重設一下各方面的環境,包括儲存空間。重設CPU,Memory,大家都很易理解,但重設儲存空間,真的不是每一個使用情況都可以這樣。 又或者說,未必所有使用情況都會有一個第三方的儲存空間可以用。所以良心的Docker在單機環境下也有提供bind mount或是docker named volume,作為可以長期保存,不受container生死的影響,以達到長期存在Data的存在。 單機-儲存空間 單機情況下很簡單,就用一個docker compose做例子 其中html就是一個bind mount,而nginxlogs就是一個docker named volume,兩者都可以長期保存data,除非各位自己手動刪除,否則不會因為container的興亡而不見了。 但有兩個很重要的分別 bind mount,直接跟host os連接,實際上是每次folder有更新,docker都要同步host和container之間的資料。 bind mount在linux下很暢順,因為大部份docker image/container原本就是linux engine,所以folder mount真的可以互通。 bind mount在windows / mac下,就會不斷抄資料。面對大量檔案,例如node_module,就會有速度上的問題 docker named volume,就是docker 分離一些獨立空間,然後再綁到container上 相對bind mount,即使在windows / mac下,都沒有那個速度上的問題。筆者猜測,即使是獨立空間,其實本身都已經限定在linux enginx下,所以沒有需要抄資料。 但在windows / mac下,因應docker 底層建立Linux VM的技術不同,你可能沒法在windows / mac預設環境下直接讀取docker named volume。 若要讀取docker named volume,最好的做法,還是連上docker container,然後用docker cp 來抄回資料。一但抄資料,其實都會有速度上問題,不過docker cp是手動決定何時做的,不做docker cp,其實container也是可以用。 Cluster-儲存空間 雖然良心的bind mount和named volume解決了單機上的儲存問題,但到了cluster環境,就沒有可以跨機同步儲存空間的做法,要做就自己建立。 筆者也稍為研究了一下同步的問題,不過對技術真的很有要求。所以退而求其次,筆者還是選擇簡單的第三方儲存空間。就是做一個可以分享存取的NAS。 建立nfs linux下要安裝nfs其實很簡單,不過要注意資料夾和防火牆權限,以下安裝教學以ubunut 22.04為例,記得把下面的YOUR_DOCKER_NODE_ADDRESS_RANGE轉為你的真實IP段落 修改docker compose 最後,你在原來的docker-compose的docker volume上加driver_opts就大功告成。 記得把下面的YOUR_NFS_IP轉為你的真實IP

使用 Multipass 建立Docker Cluster

潮流特區
MacauYeah ・2023-06-02

以下流程,假設各位已經 在Ubuntu Server中開設了virtual bridge 供Multipass設定Static IP,並且network interface定為 localbr 使用Packer template制成docker.img , 並存放於當前資料夾內 使用docker.img 起三個node,並使用network interface localbr,各有一個指定的mac address multipass launch file://$PWD/docker.img --name node21 --network name=localbr,mode=manual,mac="52:54:00:4b:ab:21" multipass launch file://$PWD/docker.img --name node22 --network name=localbr,mode=manual,mac="52:54:00:4b:ab:22" multipass launch file://$PWD/docker.img --name node23 --network name=localbr,mode=manual,mac="52:54:00:4b:ab:23" 對運行中的三個node,為它們設定static ip multipass exec -n node21 -- sudo bash -c 'cat /etc/netplan/10-custom.yaml network: version: 2 ethernets: extra0: dhcp4: no match: macaddress: "52:54:00:4b:ab:21" addresses: [10.13.31.21/24] EOF' multipass exec -n node22 -- sudo bash -c 'cat /etc/netplan/10-custom.yaml network: version: 2 ethernets: extra0: dhcp4: no match: macaddress: "52:54:00:4b:ab:22" addresses: [10.13.31.22/24] EOF' multipass exec -n node23 -- sudo bash -c 'cat /etc/netplan/10-custom.yaml network: version: 2 ethernets: extra0: dhcp4: no match: macaddress: "52:54:00:4b:ab:23" addresses: [10.13.31.23/24] EOF' multipass exec -n node21 -- sudo netplan apply multipass exec -n node22 -- sudo netplan apply multipass exec -n node23 -- sudo netplan apply 使用node21作為Leader (Manager),與其他兩個node一起組成Cluster multipass exec -n node21 -- sudo docker swarm init --advertise-addr 10.13.31.21 multipass exec -n node21 -- sudo docker swarm join-token manager managerToken=$(multipass exec -n node21 -- sudo docker swarm join-token manager -q) multipass exec -n node22 -- sudo docker swarm join --token $managerToken 10.13.31.21:2377 multipass exec -n node23 -- sudo docker swarm join --token $managerToken 10.13.31.21:2377 Cluster就建立完成。 若想刪掉重來 multipass delete node21 multipass delete node22 multipass delete node23 multipass purge 備註 在直正使用時,大部份時間還需要做port forwarding。multipass沒有自己的port forward,可以用ssh tunnel來模擬。 例如把Ubuntu Server的8080指向node21的8080,可以這樣 sudo ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa -L 0.0.0.0:8080:10.13.31.21:8080 ubuntu@10.13.31.21 完整的script可以參考initDockerCluster.sh。 沒有Bare Metal Ubuntu或者沒有static ip也可以參考initDockerClusterWithoutStaticIp.sh。只是因為network brandwidth問題,我就不會在每次更新時都測試。

[教學] 平民雲端服務不是夢 | 5分鐘教你如何快速起VM

潮流特區
MacauYeah ・2023-05-11

前言 原本筆者只是想做docker cluster,但因為在實機中建VM極其麻煩,所以就研究了好一陣子如何快速起VM。 Hyper-V有預設的Ubuntu template,但只有ubuntu desktop版,沒有server版。而且desktop gui顯得浪費資源,要clone VM也很廢時,放棄。 Windows Subsystem Linux起VM很方便,但同一個Linux version只有一個instance,沒法起cluster,放棄。 Virtual box沒有Ubuntu template,若要clone的話就變得跟Hyper-V差不多,放棄。 經過一輪資料搜集,發現了一個Ubuntu multipass engine,聲稱可以跨平台快速起VM。裏面有一些很吸引的功能,可以自己建立images、使用固定IP。 那怕即使是沒有snapshot,在自定義images的配合下預裝docker,要隨時加減cluster node都是一件容易的事。 重大決策點 醜話說在前頭。經過一輪測試,multipass最大的問題,就是custom image、fix IP都只能在bare metal ubuntu 中才能使用。如果你沒有一台閒置實體機安裝Ubuntu,還是要再多考慮一下。 重點 詳細的流程,筆者記錄了在Packer template 和Multipass Static IP中,在這裏就只說一些重點。 packer是使用cloud-init和qemu的技術,行起template中指定的cloud image (在筆者的例子中就是ubuntu-22.04-server-cloudimg-amd64.img) 大家可以定義image行起後進行一些操作,而那些操作都是經過qemu vnc、ssh進去操作的。 操作完後就會直接儲存當時的image。所以在操作結束之前,盡可能地刪cache或刪去不要的user / group settings。 最後生成的image,還是一個cloud image。若要再運行它,必需要使用支援cloud-init的VM來讀取。 cloud-init是用來指定初次運行時要設定的事,例如:hdd size, user account password, ssh key import等。 使用工具cloud-localds可以生成一個seed.img,這樣qemu也可以cloud-init。 Hyper-V應該也可以經過類似方式,進行cloud-init,但筆者未有去實測。如有更簡便的方法請告知。 multipass預設就已經有cloud-init,在bare metal ubuntu就可以直接執行。 multipass也可以設定不同的cloud-init參數。 成品 最後筆者就選擇了用packer用來預裝docker,經mulitpass無腦起VM,再使用shell script對多個node設定docker,達到即時起docker node的功能。這樣就減省了VM的安裝時間,也省去了docker的安裝問題。 說到底,如果只想測試docker cluster,其實windows, macOS中的multipass也可以實現相同的功能。因為安裝docker那些都可以經過shell script自動化,只是每次重複操作,都變得相當慢。另外,因為multipass在windows, macOS不支援fix ip,對於指定docker cluster interface又會再多一重功夫。

你今日揀啱要 Send 嘅 Emoji 未呢?

澳城生活
Chrysalids 少爺 ・2017-08-03

好多時候我地都會用一個甚至係幾個唔同嘅表情符號 (Emoji) 配搭黎回覆訊息, 可能係因為忙,又或者係想表現得有型啲 cool 啲等等原因。 但每一次用 Emoji 嘅時候,你會唔會煩用邊一個先至啱或者夠 chok 呢? 今日筆者想推薦一部新上映嘅電影 “Emoji 大冒險”。 有睇過預告嘅都大慨知道故事係講述表情符號 “阿基” 天生可以做唔到嘅表情, 但係表情符號世界裹面,每個表情符號只能夠允許做一個獨特嘅表情, 所以 “阿基” 被認為係有問題,需要被刪除。 “阿基” 希望可以揾到幫手修復自已,所以離開手機。 途中更遇到俾個五(High Five) 同埋駭客 JB (JailBreak) 一齊展開冒險旅程。 雖然網上評論大多都係負面,評分也較低, 甚至用呢套戲同 “腦筋急轉彎 (Inside Out)” 等其它相似電影一齊比較, 以顯得呢部電影有幾失敗,有幾遜色, 但筆者認為一定要入戲院睇一睇。 第一個原因係想像力。 雖然筆者仲未睇呢部電影,或者欠缺說服力, 但如果單單從想像力方面黎睇, 呢套電影有一定高分數。 表情符號無時無刻只會做一個表情, 無人會想像下如果表情符號都識郁、識講野、有自己嘅諗法係幾咁得意架咩? 第二個原因係教育意義。 “阿基” 因為天生可以做到其它所有表情符號都做唔到嘅野, 所以被評定為有問題,要趕走,要消除。 相反地,筆者認為 “阿基” 係最傑出最出色嘅表情符號, 佢甚至可以創造出全新獨有嘅表情。 就好似現今社會,不公平嘅狀況周不時發生係我地嘅左右, 有傑出能力嘅人、有不凡智慧嘅人、 有才華洋溢嘅人往往因為周邊嘅人妒忌而無法把自身能力發揮出黎,甚至被趕絕。 所以呢部電影好值得我地去反思探討下點解會出現「有志難伸」呢種境況。 基於以上兩個原因,筆者個人認為呢部電影有一定嘅趣味性和娛樂性, 所以如果有時間有興趣,不妨入戲院觀賞一下。 睇完戲,可以順便去埋南灣雅文湖畔抽 Emoji 扭蛋機! P.S.: 依家天氣咁熱,筆者請大家 “睇” 杯雪糕涼下! 以上圖片均取自網路,所有版權歸原作者所有。