docker

標籤：docker

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的分配策略就足夠，其餘就像是單機升級一樣。

Docker 中的非管理員用户 Docker non-root user

潮流特區
MacauYeah ・2025-03-14

Container USER為何重要 在制作Docker Image的過程中，有時會接觸到 USER 這個設定。這事關到最後的 Docker Container內部運行的那個 user 到底會有什麼權限。大家也要知道，Docker Container 其實也只是一個 Linux 上的程序，也就是如果Container內權限過大，也有機會從 Container 內部存取到 Host上的資料。 一般情況下，Docker Image 預設的 USER 就是 root，最基礎的base image都是一樣。而我們想換，其實也相當簡單，就像Linux上起User一樣，只要經指令RUN adduser xxx 或RUN useradd xxx 也可以在 Docker Image 中創建帳號和 home 資料夾，之後就隨時經USER xxx來切換 實際上是不是這麼簡單? 如果你將要Container中執行的程序，是一個binary，平常你在Linux中也是以 non-root 方式執行，那麼是的，就是那麼簡單。例如你執行系統中的java, node, python，原本在Linux中就已經是誰都可以，那麼你的docker container 也應該沒有難度。 但如果原本的安裝包，預設是由system service來啟動，我們就要花點力氣，看看那個service是怎樣呼叫binary的，然後就一步一步模擬它的做法。例如筆者有打包的codeserver，預設是system service啟動，但它也有提共binary的執行方法，安定好home資料夾後，我們也可以手動啟動。 泛生之檔案權限問題 上述binary的情境之所以簡單，是因為大部份情況下，我們都只對於container 內部運行考慮即可，因為預設投產情況下的運作模式，都是隨時起、隨時刪、隨時砍掉重練，只要container內部運作可以自給自足，就可以了。Docker Swarm的運作也是如此，所以它不預期有的持久化資料權限的問題。 而持久化資料權限的問題，其實早在單個Linux伺服器就已經存在。同一個伺服器中，不同process就有不同的UID，當他們需要共同讀/寫某些檔案，就會設定多人權限。同理，當多個Container要共同檔案，也是同樣問題。在討論共享檔案之前，我們先看看預設 Docker Storage Mount 會給我們什麼權限。 如果是bind mount，bind mount的權限預設會是Host內的檔案或者資料夾的權限。 如果Host是root，container內是non-root，container有機會無法讀寫bind mount內的檔案。 留意權限設置就可以解決問題 如果Host是non-root，但container 內是root，從container內生成的檔案，Host的non-root user就無法使用。 Host是non-root的話就一定無解，Host至少有sudo權限，臨時變成管理員，去修正問題。 如果host和container也是non-root，但UID不夾，其實也不能交換使用。 跟上述一樣，最後要靠sudo來解決問題。 如果host和container也是root，就沒有權限問題，但就有安全性的風險。 如果是volume mount，就還是看看 mount path 是docker image layer中現有的 path還是新起的path 大部份手動建立的named volume都是root 經docker compose起的named volume滿足以下條件的話，將會是non-root。 docker image 中的已有該path存在。 named volume未存在，docker compose會把對應path的內容在初次建立時抄到named volume 中。 例如ubuntu:24.04中的/home/ubuntu，存在於docker image中，它的擁有者就是UID 1000，我們經docker compose HOME_VOLUME:/home/ubuntu，在HOME_VOLUME建立時，就會是UID 1000。但如果是 NOT_EXISTS:/home/ubuntu/somethingNotExists，那麼NOT_EXISTS建立時，也會是root 上述討論的Storage mount是集中在單機情況下，使用HOST OS的本地儲存。若現在的場境是多機共享的share storage，就會更麻煩，還要看看那個share storage本身的屬性。例如常見的Linux NFS，其實有指定的權限，跟NFS的Login權限有關，如果你的process本身對檔案權限很敏感，就請先不要挑戰NFS(例如postgresql)。 Rootless mode - Rootless 模式 Rootless 模式指的是在Host中，執行Container的使用者，不需要是管理員，筆者就常用於開發環境中。投產環境中反而沒有聽過這樣的討論，因為投產環境很少可以讓非管理員去執行這麼重要的環境管理。 雖然只是開發環境，但這像前述的bind mount討論中，如果Host是non-root，但container 內是root，又或是兩者non-root，但UID不夾，也會出現權限問題。無腦的將host user加入docker group，只可以讓非管理員可以運行docker，但解決不了權限問題。 真正有條件解決的，可能就會向linux subgroup的方式發展。暫時筆者用得比較順的rootless mode，可以無腦用的，不是docker，是podman。有興趣的朋友可以經podman官網看看教學，它給筆者的感覺就像是自動轉換UID。 podman rootless mode 想看更多 筆者已經將過去的文章重新整理成gitbook，有興趣睇更多的讀者，可以來筆者的gitbook再翻一翻 https://macauyeah.github.io/AProgrammerPrepares/

快速做用 elasticsearch 做中文 n-gram 關鍵字全文搜尋

潮流特區
MacauYeah ・2025-01-16

有些時候，我們對一些文章資料，光是使用Ctrl-F文字區配搜尋，很難找到完全吻合的結果。這時候，我們可以試試看快速搭建自己的中文搜尋引擎，看看能不能更易地找到資料。而中文搜尋引擎，其實用免費的elasticsearch也可以做到。我們就來看看怎樣快速起lab吧。 經 docker 下載及運行 elasticsearch docker run -p 127.0.0.1:9200:9200 -d --name elasticsearch \ -e "discovery.type=single-node" \ -e "xpack.security.enabled=false" \ -e "xpack.license.self_generated.type=basic" \ -v "elasticsearch-data:/usr/share/elasticsearch/data" \ docker.elastic.co/elasticsearch/elasticsearch:8.17.0 建立資料庫。在elasticsearch 中，示作index，並建立自己的n-gram analyzer和tokenizer。 curl -X PUT "localhost:9200/book-ngram?pretty" -H 'Content-Type: application/json' -d' { "settings": { "index" : { "max_ngram_diff" : 4 }, "analysis": { "analyzer": { "my_analyzer": { "tokenizer": "my_tokenizer" } }, "tokenizer": { "my_tokenizer": { "type": "ngram", "min_gram": 1, "max_gram": 5, "token_chars": [ "letter", "digit" ] } } } } } ' 假設資料庫每筆記錄有 record_id，title 和 content 三個欄位，其title, content都是中文內容。它們都套用 n-gram analyzer 。 curl -X PUT "localhost:9200/book-ngram/_mapping?pretty" -H 'Content-Type: application/json' -d' { "properties": { "title": { "type": "text", "analyzer": "my_analyzer", "fields": { "keyword": { "type": "keyword" } } }, "content": { "type": "text", "analyzer": "my_analyzer", "fields": { "keyword": { "type": "keyword" } } }, "record_id" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword" } } } } } ' 批量上傳內容。(如果要上載json檔，請把 -d'xxx' 改為 --data-binary @FILENAME) curl -X POST "localhost:9200/_bulk?pretty" -H 'Content-Type: application/json' -d' { "index" : { "_index" : "book-ngram" } } {"record_id":"1","title":"紅樓夢","content":"甄士隱夢幻識通靈賈雨村風塵懷閨秀"} { "index" : { "_index" : "book-ngram" } } {"record_id":"2","title":"西遊記","content":"混沌未分天地亂，茫茫渺渺無人見。自從盤古破鴻蒙，開闢從茲清濁辨。覆載群生仰至仁，發明萬物皆成善。"} { "index" : { "_index" : "book-ngram" } } {"record_id":"3","title":"水滸傳","content":"張天師祈禳瘟疫洪太尉誤走妖魔"} ' 多欄位搜尋，並指定title的權重為content的兩倍。 curl -X GET "localhost:9200/book-ngram/_search?pretty" -H 'Content-Type: application/json' -d' { "query": { "multi_match": { "query" : "開天闢地", "fields": ["title^2", "content"], "analyzer": "my_analyzer" } } } '

Docker 來源掃瞄 - Docker Image Scan

潮流特區
MacauYeah ・2024-12-19

當網安要求越來越高時，我們也要留心 docker image 的來源是不是有漏洞問題。 docker hub 本身就已經有一些安全掃瞄報告，以 nginx 的 1.27.3 版本為例， docker hub nginx 1.27.3 ， docker hub 已經列出相當多的CVE漏洞。 不過對於不公開的 docker image ，安全描瞄可是要收費的。作為小團隊，可能想先尋求一些簡單的免費方案。如果你想同樣的需求，可能Trivy會幫到你。 Trivy Trivy 是一個用於描瞄軟件版本依賴或設定檔是否引用到一些有漏洞問題的軟件，它也能檢測 docker image 是否有漏洞或錯誤設定的問題。而且更好的是， Trivy 本身亦有 Docker Image 版本，我們就不用煩惱怎樣弄一個 Trivy 的執行環境，只要可以運行 docker ，有網路就可以了。但使用 Docker Image 版的 Trivy 有一個額外要求，就是它要有主機上的 docker.sock 權限。 描瞄的指令如下，其中 docker.sock 就是為了讓 containers 內部的程式可以存取主機的 docker daemon , .cache 則是為了方便暫在下載資源。 上面故意用 nginx 的兩個同版本號不同平台的 docker image，其實就是為了引出一些潛在問題。nginx 預設是使用的debain OS的，在筆者寫文章的當下，已經更新到最近的 image ，但始終有一大部份可能的漏洞。反觀 alpine OS 版本，就找不到這麼多問題。 這是因為 alpine 預設安裝的依賴較少，所以找到的漏洞也少。正所謂，做多錯多，唔做唔錯（大誤）。這其實有好有不好，因為在發生問題時，在 alpine 下可能連基本的除錯工具都沒有。除非大家有完整測試，或者對 alpine 有相當的認識，你才會選擇一個非官方預設的版本。但就以事論事，引用較少的依賴，長久之下的確是不會有那麼多隱患。大家如果有條件，也可以試試 alpine 或其他版本。 前一節我們可以看到，Trivy需要經過 socket 的方式才能存取主機上的 container daemon 操作權。但 podman 作為一個不主張 daemon (daemon less)，亦主張不需要 root (rootless)，那麼它該怎樣執行？ 其實podman也有user層面上的 socket，而且 trivy 也有對應的方式去轉用第三方 socket (有點像使用遠端主機 socket，但官方並未宣佈正式支援遠端的方式。) 具體使用方式，筆者亦已在 steam deck 上測試，使用方式如下。不過因為 steam deck 預設沒有 root，筆者就省略 cache 指令，免得之後要有權限問題要手動清理。 Ref Podman socket activation Trivy: Support for rootless podman

概有雲供應商的K8S，為何要自己弄Docker Swarm / 本地K8S ?

潮流特區
MacauYeah ・2024-11-19

其實筆者寫了這麼多篇docker 的文章，可能有朋友會問，為何要自己從零建立Container環境，使用供應商直接提供的K8S服務不是很好嗎？ 按照市場發展，各大雲供應商都越來多，競爭越嚟越激烈，作為用戶方，理應可以得到更合理的價格。不過作為使用VPS多年的筆者，真的沒有覺得雲服務的價格可以便宜到一個不用煩惱的水平，大家還是需要很㥀重地考量自己的業務是不是值得雲端化。 正常來講，在有足夠使用量的前提下，雲端化也是合適的，也真的有產到錢。但問題是大部份情況下公司內部自主開發的應用，都沒有去到這個程度。每個應用去租用一個VPS，即使使用最低配置，用起來的時候覺得不夠快，閒起來的時侯也是浪費錢。 這時，使用 Container 技術，就是讓多個不同的應用，共享同一個或多個VPS的好方法。因為 Container 可以簡易地做到應用之間的隔離，即使不同應用之間有依賴衝突，只要 Contianer 層面沒有衝突就可以共存。 Docker swarm 與 K8S 同為 container 技術，文章最前面，就提到了這個問題，為何不選現有的K8S，反而要自己弄Docker Swarm？其實關鍵亦是價錢的問題。使用K8S固然方便，但就每個節點都得使貴一級的雲端供應商服務，當我們的應用總是流量不足，就更易變得食之無味，棄之可惜。老實講，貴一級的雲端服務，有它存在的價值，很多東西可以做自動化擴展，例如概據流量自動擴容。另外，因為底層 Container 技術有供應商支援，也不用再另外購買支援服務。但這些都是業務有一定流量，才能展現出優勢。 反觀Docker Swarm，就是簡單可入手，初時一個VPS也可以。什至乎不上雲，找幾台舊電腦，實機做也可以。當然K8S也可以實機，不過就簡易程度來講，Docker Swarm 無得輸。待業務真正成長到一個有足夠流量的服務時，才進一步遷移到供應商的原生雲。在初期使用自建的Docker Swarm或小型K8S，可以先加入一些資源統計，以確定是否即裝滿負荷。

Swarm mode 上線 5 - load balancer | 還有那些事該考量？

潮流特區
MacauYeah ・2024-11-18

前面介紹了 ingress network ，亦介紹了 proxy gateway 。能做到的基本都做到了，再來就是考量安全性的問題。因為加了 proxy gateway ，前述的例子是所有 service ，都放在同一個 yaml 檔中。好處是，所有相關的東西存放在同一個檔中， gateway ，背後的 service 都一眼看到。但壞處就是有其中一個 service 更新，都要改那個 yaml 檔。更大的問題是， stack deploy 的指令，不單只更新其中一個 service ，就連其他 service 都會自動取得最新 image 而 redeploy 。 對於一個緊密的系統來講，同步更新可能不是大問題。但對於一些預定排程發佈的系統可不能這樣因為副作用而更新了。如果你也有這樣的分開管理需求，可以參考下面做法，把 gateway service 及 upstream service 放在不同的檔案中，然後經過 external network把所有 service 串連起來。 # nginx-stack.yaml, docker stack deploy -c nginx-stack.yaml nginx services: http-gateway: image: http-gateway ports: - 8080:8080 deploy: replicas: 1 update_config: delay: 10s restart_policy: condition: on-failure # manager-stack.yaml services: managerhttp: image: bretfisher/httpenv networks: - nginx_default - default deploy: replicas: 3 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==manager networks: nginx_default: external: true # dmz-stack.yaml services: dmzhttp: image: bretfisher/httpenv networks: - nginx_default - default deploy: replicas: 2 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==dmz networks: nginx_default: external: true 這樣，不同 service 的維護人員，就可以獨自控制自己的檔案。在第一次發佈時，確認 nginx-stack.yaml 先行發佈就可以了。對應的發佈指令是docker stack deploy -c nginx-stack.yaml nginx，它會自動産生一個 nginx_default （即 stack名字_default ）的網絡。之後其他service，就可以經networks的設定找到它了。 services: YOUR_SERVICE: networks: - nginx_default - default networks: nginx_default: external: true 上述即使分離檔案，在安全性考量時還是有一個問題，就是 ingress network 的問題。試想一下，dmzhttp （Demilitarized Zone）原本被設定的原因，就是想限制某些訪問只能一些可以公開的服務。但因為經過 ingress network 之後，它們會在所有機器上開放這些 port。那就是，以下面的例子來講，若 dmzhttp 是公開的服務， intrahttp 是內部服務，即使用 intrahttp 使用不同的port 8889。但一經 swarm mode 預設的 ingress network ，在node.labels.zone==dmz的那些節點，還是可以訪問到 intrahttp 。 services: dmzhttp: image: bretfisher/httpenv ports: - 8888:8888 deploy: replicas: 2 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==dmz intrahttp: image: bretfisher/httpenv ports: - 8889:8888 deploy: replicas: 3 update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==intra 我們前述介紹的 proxy gateway ，其實已經有一定程度可以解決這個問題。因為 proxy gateway 是根據 http 協定中的 host header 去做分流。在邊界網絡進來的「合法」訪問，道理上會好好地經引導到我們的 dmzhttp 。不過網路的邪惡可容小看， proxy gateway 也會有被騙的一日。有特定能力的攻擊者，只需找到目標域名，還是可以接觸到 intrahttp 。 若要做進一步隔離，在這種情況下，我們可以在 dmz , intra 機器中各設定一套 swarm ，完全獨立，這是最安全的做法。但這樣做的管理成本就會變高，因為兩個網段都會有自己的 manager 節點，而且在 dmz 網段的 manager 節點也有被攻擊的可能。 若我們回到單一 swarm 的方向，可以修改各個 service 中的 port 和 deploy 。利用 post mode 中的「host」，配合 deploy mode 中的「global」，完全跳開 ingress network。 services: dmzhttp: image: nginx ports: - target: 80 published: 8888 mode: host deploy: mode: global update_config: delay: 1s restart_policy: condition: any placement: constraints: - node.labels.zone==dmz intrahttp: image: bretfisher/httpenv ports: - target: 8888 published: 8888 mode: host deploy: mode: global update_config: delay: 10s restart_policy: condition: on-failure placement: constraints: - node.labels.zone==intra 上面的例子中， dmzhttp 會在所有 dmz 的機器中，每個節點只運行一份服務，而且直接使用該機的 8888 port ，外面不會再有 ingress network 的 存在。同樣地，intrahttp 會在 intra 的所有節點，運行一份服務，佔用它們的8888 。這兩個服務，即使使用一個 port ，swarm 也不會說有任何問題。因為它們不會經 ingress network 搶佔其他人的 8888。 可能會有讀者問，如果 host mode 這麼安全，為什麼預設會是 ingress network，那我們就要先了理清 ingress network 與 host mode 有有什麼分別？假設我們只運行一個service，它佔用8888。 功能ingress modehost mode replicas 數 同一個 service replicas 為任意數量，什至比節點的數目多 因為有 port 限制，每個節點最多只能運行一份 Virtual IP Virtual IP 任意在節點中跳轉也可以，因為 ingress 會自動找到對應的 service 所在的節點 Virtual IP必需要與 service 所在節點綁定，其他節點訪問不到 load balance 有 沒有 host mode 就像我們傳統在各自的節點上自行佈署自己的程序，各個節點只有一份。所以不會有自動 load balance 的效果，如果客戶端訪問固定的IP，就會得到是固定的接器接受請求。我們有需要，就要在前面加一個 Proxy Gateway (或 HA proxy )。 Virtual IP 也一樣， host mode 下需要好好地自動跟著 service 的生命期，不過幸運的是， Docker 預設己經有自動重啟 service 功能，即前文中的 restart_policy ，它在 host mode 下也適用。如果大家有配合 deploy 中的 global mode ， Virtual IP 的並沒有實際變動。但如果沒有 global mode ，就要再想想辦法了。 最後考慮 load balance 的問題，如果進入點的 service 的真的不太消耗資源，沒有 load balance 也是可以的 ，但若超負荷，就必需要自建 proxy gateway 。經過進入點後，若我有背後的 service 就沒有所謂的 ingress 和 host mode 選擇。

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

Swarm mode 上線 5 - load balancer | 負載平衡器

潮流特區
MacauYeah ・2024-10-28

前面我們一直談 swarm 的設定，但對於真實的服務，我們還要考慮客戶端是如何連接我們的伺服器群集。通常網路服務，客戶端都會經過域名轉換成IP，然而通過IP連線服務。 Ingress Network 假設我們 swarm 內有5個節點，那到底域名應該指向我們哪一個節點的 IP 呢？ 如果我們不考慮節點死機的話，其實5個節點的IP都可以。因為 swarm 會自動把同一個公開的 port ，在每一個節點上都可以訪問到。 以下例子，即使只有一個 container 運行，佔用 port 8888，它還是會在5個節點上全開。 swarm 通過自己的 ingress network，它所有節點的 8888 串連起來。 services: http: image: bretfisher/httpenv ports: - 8888:8888 deploy: replicas: 1 update_config: delay: 10s restart_policy: condition: on-failure 我們可以在每個節點上，都會找到這個 ingress network，而且那個Network ID，應該是一樣的 > docker network ls | grep ingress t7rmk6g9zybm ingress overlay swarm 如果上述的 service 的 replicas 調成大於1的數量， ingress network 還會方便地自動 round robin (輪替) 地分派流量，達到最簡單的負載平衡。 Virtual IP 前述的設定，我們有一最大的假設，就是節點不會死機。但實際情況下，各種原因，例如安全性更新、重啟中，都會讓節點暫時無法使用。即使所有 service 都是會自動 failover (故障轉移)，但客戶端還是用舊機 IP ，它還是無法訪問。因為該機 IP 已無法使用，除非我們連 IP 也懂 failover。這時， Virtual IP 就是我們的救命靈藥。 在 ubuntu 上，我們可以經過 keepalived 去設定 Virtual IP apt-get update && apt-get install keepalived -y 然後設定 keepalived ， 假設 172.22.1.5 是我們的 Virtual IP 。 然後每個節點都要加入conf # vim /etc/keepalived/keepalived.conf # assume failover ip is 172.22.1.5 vrrp_instance VI_1 { # change interface according to machine status interface eth1 state MASTER # 101 for node1, 102 for node2 # you can start seq from other value, remind unqiue for each node is ok; virtual_router_id 101 # lower 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 advert_int 1 authentication { auth_type PASS auth_pass YOUR_RANDOM_PASSWORD } virtual_ipaddress { 172.22.1.5 } } 上述需要特別注意的是 virtual_router_id : 每個節點應該都要不一樣，以作唯一標識。 priority : 每個節點應該都要不一樣，最大的那個節點，就會優先使用 Virtual IP 。 auth_pass : 每個節點都相同，但大家在抄時，記得更改。 還有的是開通 iptables ，讓各個節點可以經網絡廣播的方式互相看到對方。 iptables -I INPUT -d 224.0.0.0/8 -j ACCEPT iptables -I INPUT -p vrrp -j ACCEPT systemctl restart keepalived

Docker Tag 命名

潮流特區
MacauYeah ・2024-10-24

一般來講，同一個docker image會提供多個不同的版本，每個版本會附予不同的tag，以作標識。但以docker image的維護者來講，它的tag通常代表的是自己程式的版本號。不過這個版本號卻存在很多變數，就讓筆者好好地逐一說明。 程式的版本號 在沒有Docker的年代，其實所有軟件在發佈時，都會標示版本號，方便使用方明確追蹤問題，自行選擇升級、降級以解決相容性問題。大家要重現問題，也能清清楚地重現。所以docker image的tag，在某程度，都是代表發佈自己的程式版本號。但以前的年代，軟件底層的依賴，例如OS層面的共享程式庫，則不在發佈的管控中，所以過去的程式，在跨電腦安裝時，都會出現缺少某些共享庫的問題。而使用了Docker後，image以內的共享庫的都會在打包的那一刻固定和發佈，就不會有漏的問題。 庫更新，怎麼辦 上面說到image可以打包共享庫，但問題是共享庫也會有安全性更新問題，那麼對docker image的維護者來講，它自己的tag又該如何命名？ 因為庫的量可大可少，所以一般來說，都不可能完全把各個庫的版本號寫在自己的tag上。退而求其次，就是用"版本號+日期"，庫的細版本號，就存在原始碼當中。Ubuntu 就是這樣的例子。 不過"版本號+日期"的命名方式真的方便嗎？每次下遊用戶想更新去最近版本，都要自己找一次最近的日期。這樣對很多用戶來講都不夠方便。所以docker又提供了一個重tag的功能。例如ubuntu:noble，在早些時候指著noble-20240904.1，然後過幾天，又指向更新的noble-20241009。更常見的是latest，每次image都預設會存在，docker也希望大家會定期更新這個tag，讓大家可以更易地找到最新版本。 註: 這跟git tag有所不同，git tag並不預期會變的。當協作者收到tag後，那怕上遊刻意更新tag指針，協作者沒有刪除原tag之前，都不會知道tag更新去了哪裏。 我們該如何選 在發佈方和引用方來講，引用時可以明確使用唯一的"版本號+日期"，對穩定性來講是有意義的。不過多多少少，會產生額外的時間成本。發佈方來說，就是多用了一些儲存空間，方便引用方可以隨時找到舊(庫)版本。而引用方，就要手動修改引用號，作為驗收依據，自動更新的難度比較大。 但對於自動更新要求比較大的情況下，可能就是使用latest或者會隨時更新的share tag(共用tag)比較實際。但我們也依然要定一些方式去版本更新記錄，例如：同時使用 beta latest archive 每日自動更新beta，只有所有測試都通過時，才把archive指向現在的latest，再把latest指向現在的beta。這樣做的好處是，核心的docker stack檔案改變的機會較少，也可以免除docker swarm做太細緻的權限管理。

Swarm mode 上線 4 | IP 設定

潮流特區
MacauYeah ・2024-07-23

單機模式 IP設定 平常我們自己做測試，網絡功能通常用預設的就好。但當我們的Docker Container需要存取在區域網內的其他資源，避晚IP網段相衝是必需要的事。 大部份情況下，單機Docker使用的預設IP段會是 172.17.0.0/16 172.18.0.0/16 ... 若然現在區域網中，有一段172.18.0.0/24，大家不想Docker踩到其中，可以修改設定檔，加入預設的default-address-pools，以後它就只會從指定的區段使用。 # vim /etc/docker/daemon.json { "default-address-pools": [ { "base": "172.17.0.0/16", "size": 24 }, { "base": "172.19.0.0/16", "size": 24 }, { "base": "172.20.0.0/16", "size": 24 } ] } 其中base，是docker可以操作的總區域，size指的是Docker要自行分段的話，每段的大小是多少，上述的例子，就代表未來可能有以下Docker 網段。 172.17.0.0/24 172.17.1.0/24 ... 172.17.255.0/24 172.19.0.0/24 172.19.1.0/24 ... 172.19.255.0/24 172.20.0.0/24 172.20.1.0/24 ... 172.20.255.0/24 修改完設定後，重啟Docker就會生效。當然，重啟前，先刪除所有不在預設範圍的所有Container。 Swarm模式 IP設定 Swarm模式，與單機差不多，它需要在初始化Swarm就要定義，而且它不能與單機的網段有重疊。單機會預設使用Private IPv4 Class B，Swarm則是預設使用Private IPv4 Class A段，所以我們若就更改，就使用10.x.x.x吧。 docker swarm init --default-addr-pool 10.1.0.0/16 --default-addr-pool-mask-length 24 經上述例子初始化的 ingress 網段，將會是 10.1.0.0/24，隨後每個stack 則會是 10.1.1.0/24 10.1.2.0/24 10.1.3.0/24 重置Swarm 跟單機的情況類似，如果已建立Swarm後才修改網段，還是要整個刪掉重來。 每個節點都要執行以下指令。 docker swarm leave --force 實測swarm leave這個指令也會把所有運行中的stack刪掉。 各節點重新建立swarm # in node 1, init new swarm with new ip docker swarm init --default-addr-pool 10.1.0.0/16 --default-addr-pool-mask-length 24 # in node 1, get new manager token docker swarm join-token manager # in node 2 and node 3, join node 1 with new token docker swarm join --token XXXXX YOUR_NEW_NODE1_IP:2377 雙管齊下 如果大家同想要修定單機及Swarm的網段，還要留意有一個特別的網段docker_gwbridge。它雖然是Swarm的附帶產物，但它則是受單機的網段控制。也就是，如果大家有需要同時修改單機及Swarm的網段，則需要手動刪除Swarm及docker_gwbridge 在每個節點先刪掉舊有的Swarm及docker_gwbridge，並關掉docker docker swarm leave --force docker network rm docker_gwbridge 在每個節點為docker_gwbridge修改設定，然後重起docker # vim /etc/docker/daemon.json { "default-address-pools": [ { "base": "172.17.0.0/16", "size": 24 } ] } 然後像前述一樣，重起Swarm。

Docker Image打包建議

潮流特區
MacauYeah ・2024-07-10

之前筆者有分享過兩個不同的Docker Image打包方式 App直接打包成Image 只把底層程式打包在Image中(例如Tomcat)，再用Docker Volume的方式讓Container可以起動App。 筆者就兩種方式做了一個條列式的對比。詳見連結 https://macauyeah.github.io/AProgrammerPrepares/VMDockerNotes/DeployDockerClusterCN.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去提供。可以按自己步調去慢慢適應。

何謂 Infrastructure as code - IaC

潮流特區
MacauYeah ・2024-06-07

在雲端服務出現後，好多新的名字，或許大家都聽過，筆者也稍為再簡介一下。 Software as a Service (Saas)。就像我們的Web App，不用下載體件，可以直接經雲進行業務操作。 Platform as a service (Paas)。這個概念可能最含糊，筆者理解就是，雲端供應商提供一些底層的軟件，供IT人使用。像是資料庫，Web Engine。 Infrastructure as a Service (Iaas)。這個更底層，雲端供應商給出CPU, IP, Memory, Storage等，頂多就再多個預安裝OS的選項。IT人自己去配搭使用。 多得這些彈性服務，雲端應用才真的跟過去租用實體伺服器有所差異。 但對於IT人來講，要使用這麼多不同的服務，實在也不簡單。對於IT消費方，用錢換來實體硬件的靈活性，但因為硬件沒有邊界之後，軟件的量就暴增。管理也不能說是很方便。 在Docker, Kubernetes等Container(容器)出現後，又為這些管理問題帶來另一種希望，就是Infrastructure as code - IaC。它的目標是，管理基礎設施，要像管理原始碼一樣，checkout 就可以回覆到指定狀態。 初聽之下，大家可能覺得好玄，但其實這個概念，在之前筆者的Docker 教學中，已經有出現過。Docker compose 、Docker stack 指令，它們都是基於yaml檔的IaC。 當筆者更新了yaml 檔，執行一次stack deploy ，docker 就會對比之前狀態，如果replica(分身)不夠多，就自動增加所欠數量，如果image 也更新了，就排隊輪流重起換image 。最重要的是，當我們checkout 舊的yaml 檔，回到過去某個狀況，只要還是執行同一句stack deploy ，系統就自然減少所需的replica數量，下戴過去的image。這就代表，我們對於container 構建而成的環境，都可以放入Git等版本控制中，整個管理模式，就像管理程式碼一樣(GitOps)。 對於更進階的Kubernetes更是如些，除了container外，多種不同的network，storage配置，都通過yaml檔進行控制。這樣，架構即使複雜，但只少可以測試、重現和管理。還有一個，它比Docker stack要強的是，它某程度上支緩刪除的概念。雖然不完全，但總比完全沒有方便。 這個IoC的概念，可能還未達到一定廣泛地應用的階段，但它的核心在於，基建項目有檢測試差異的功能，自動去因為這個差異去加或減資源。用Programmer的講法，就是系統有Diff的功能，自動多除少補。

Docker環境參數化 - Arg VS Env

潮流特區
MacauYeah ・2024-03-26

Docker Variable control 我們在Docker Image的打包時，最簡單當然就是每個步驟都使用最新版本。例如Docker Base Image，大家可能選用latest tag，安裝linux package （Linux包）,也可能就apt install / yum 安裝最新的穩定版本。但如果我們想要更好地做測試，就要使用指定版本，方便追蹤問題。而Docker在打包和運行時，都有不同的方式讓大家定義或覆寫指定參數。 Docker build arg 我們先從打包Image開始。 例如我們需要使用一個Base image為 ubuntu，版本預設為22.04，但有需要時可以經build指令覆寫，可以這樣寫 ARG ubuntu_version=22.04 FROM ubuntu:${ubuntu_version} # default ubuntu_version=22.04 docker image build -t test2204 ./ # or overwrite by --build-arg docker image build -t test2404 --build-arg="ubuntu_version=24.04" 雖然Dockerfile的RUN指令都是使用linux shell，但在Dockerfile中想表達條件控制（if else statment）就不太易看。在外部加入script做控制，是另一個可行的後備選擇，它更可以連image名字也進行參數化。 # in bash script, you also can if [ $beta == true ] then ubuntu_version=24.04 else ubuntu_version=22.04 fi docker image build -t test:${ubuntu_version} --build-arg ubuntu_version=${ubuntu_version} Docker Container Run and Docker Compose 一般來講，Linux Container 在執行時，就等於進入Linux Shell。也就是，我們可以使用Shell中的環境變數。 我們在打包Image前，已經可以在Dockerfile中定義自己的ENV數參（也就是環境變數）。與前面的Build Arg有所不同的是，ENV是定義在Dockerfile中，在Container運行時以環境變數的形式存在，它也可以在運行中被改變。而Arg，則只在打包Image時存在，運行期間就不存在了。（當然，你在打包時，用Arg傳入Env，以運到這個目的。） 另一個更特別的性質是，那怕ENV沒有定義在Dockerfile中，我們運行時也可以加入更多的環境變數，大家就當成是一般Linux操作，隨時在自己的shell中加入變數。 # -e, --env for inline variable # --env-file for file docker container run -e MYVAR1 --env MYVAR2=foo --env-file ./env.list ubuntu bash 同樣地Docker compose，也支援環境變數。筆者建議environment可以使用Array格式，日後可以更方便地直接改為env_file。 # docker-compose.yaml services: ubuntu: image: ubuntu:22.04 environment: - RACK_ENV=development - SHOW=true - USER_INPUT 上述的寫法沒有任何問題，不過如果你的docker-compose.yaml是放在git等版本控制中，你更新環境變數就有可能會影響到其他人，這時你就會想轉成env_file。 docker-compose.yaml預設就會讀當前資料夾的.env，就算不存在，也可以正常運行。（當然，大家的Image/Container應該要有預設值） # docker-compose.yaml services: ubuntu: image: ubuntu:22.04 # if env_file is not defined, it will load .env. # or you can load the specific file. # env_file: # - ./a.env env_file內，每一行就是一個變數 # .env or a.env RACK_ENV=development SHOW=true USER_INPUT 使用預設的.env還有一個好處，就是我們可以把docker-compose.yaml也變成受環境變數控制。 # docker-compose.yaml with variable control, only works in default .env services: ubuntu: image: ubuntu:${ubuntu_version} # .env ubuntu_version=22.04

龐大的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。就像