linux

標籤：linux

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

潮流特區
MacauYeah ・2025-07-18

前幾天，我們就使用traefik做了個最簡單的http反向代理。 做完上述的使用驗證後，我們可以正式開始看官方的例子，該例子加入了SSL，這就更充份地體現反向代理的用途。 官方教學連結 官方的yaml也很長，筆者實測了一個簡化版本。 services: traefik: image: traefik:v3.4 ports: - target: 443 published: 443 protocol: tcp networks: - traefik_proxy volumes: - /var/run/docker.sock:/var/run/docker.sock:ro configs: - source: dynamic-tls.yaml target: /dynamic/tls.yaml secrets: - source: certs-local.key target: /certs/local.key - source: certs-local.crt target: /certs/local.crt command: - --api.dashboard=true - --log.level=INFO - --accesslog=true - "--providers.file.filename=/dynamic/tls.yaml" - --providers.swarm.exposedByDefault=false - --providers.swarm.network=traefik_proxy - --entrypoints.websecure.address=:443 - --entrypoints.websecure.http.tls=true deploy: replicas: 1 placement: constraints: - node.role==manager whoami: image: traefik/whoami networks: - traefik_proxy deploy: labels: - "traefik.enable=true" - "traefik.http.routers.whoami.rule=Host(`whoami.swarm.localhost`)" - "traefik.http.routers.whoami.tls=true" - traefik.http.services.whoami.loadbalancer.server.port=80 networks: traefik_proxy: name: traefik_proxy driver: overlay attachable: true configs: dynamic-tls.yaml: file: ./dynamic/tls.yaml secrets: certs-local.key: file: ./certs/local.key certs-local.crt: file: ./certs/local.crt 餘下的就照跟官方設定 生成cert file。（或大家有正式的證書，就可以免去這一步。） mkdir -p certs openssl req -x509 -nodes -days 365 -newkey rsa:2048 \\ -keyout certs/local.key -out certs/local.crt \\ -subj "/CN=*.swarm.localhost" 指向cert的動態設定檔。 tls: certificates: - certFile: /certs/local.crt keyFile: /certs/local.key 然後我們就可以這樣測試 curl -v -k -H 'host:whoami.swarm.localhost' 筆者在一開始時，始終無法設定 dyanmic/tls.yaml ，其實是筆者誤會了 traefik 的讀取方式。本個例子中，traefik 其實會動態讀取 swarm 及 file provider 的設置，而dyanmic/tls.yaml是經過file provider的方式生效。也就是 traefik-ssl.yaml 中的"--providers.file.filename=/dynamic/tls.yaml"。 本個例子與官方例子最大的不同，是官方的cert, tls, 是直接使用bind mount的方式存取，如果你有多過一個manager，這個方式不太有效。本文就用了swarm config及swarm secret，方便多個manager自動配置。不過swarm config及swarm secret都有個缺點，若要更新它們的內容，就必需要重命名（例如dynamic-tls.yaml=> dynamic-tls.yaml2） ，否則swarm不允許發佈。 完整 yaml 請見 github

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

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/

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/

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

Tmux - 繼 Screen以後的Linux多工神器

潮流特區
MacauYeah ・2024-10-08

因為各硬件/軟件的發難，筆者又不得不回到那個只有純純linux tty console的世界。很多時候，那怕使用tty，我們在Desktop mode，也有現代terminal 可以用，需要多分頁，滑鼠選取文字、複制、貼上，都可以輕易做到。 但在mobile / tablet device 上，手指操作真的很不方便。又或者你像筆者一樣，即使有電腦，但要操作一些Linux VM，它們連ssh都沒有，只能直接登入它們的tty，那麼懂得使用Tmux進行分頁及複制、貼上，就變得很重要。 Tmux 是什麼? Tmux 就是可以在Linux Terminal 同一個窗口中，實現多工處理的小程式。就像我們利用多分頁一樣，不同分頁做不同的事。不過最大的差異就是，生成分頁，排列分頁，我們都要使用鍵盤來完成。有時筆者也會用它來作為背景程式，以免不小心關了Terminal就會把所有運行中的指令都停掉。 我們就馬上來看實際例子吧 前置事項: 安裝Tmux及運行Tmux Debain & Ubuntu 安裝: sudo apt-get update && sudo apt-get install tmux 運行：tmux 進入tmux後，你就會至少有一個分頁，而且不會因為Terminal關閘而中斷 用法一: 建立兩個分頁，並切換 增加分頁: 先按 “Ctrl + b” (前置鍵)，再按”c” (create) 切換分頁: 在多於一個分頁的情況下，先按 “Ctrl + b” (前置鍵)，再按”n” (next) 用法二: 同一個分頁中，建立左右並排的窗口 增加水平窗口: 先按 “Ctrl + b” (前置鍵)，再按 “ (雙引號) 切換窗口: 在多於一個窗口的情況下，先按 “Ctrl + b” (前置鍵)，再按方向鍵左或右 用法三: 回到前一個tmux session中 因為不小必關閉了terminal，又或是remote ssh中，ssh斷線後，需要回到之前的工作狀態 未進入tmux 的狀態下：tmux attach 要留意tmux 可以有很多個session，要去到指定的session，就要為session命名。但這個不是筆者常用的情境，原本多個分頁已經很夠用，還要多個session，會很混亂。但不排除它在某些情況下有特別用途，有興趣的朋友可以自行挖挖看。 進階: 回頭看過去的terminal screen output 在現代的Terminal中，原本按滑鼠滑輪向上滾，就可以看到過去的資訊，但tmux下反而不行，所以我們需要進入特殊模式 進入Copy Mode: 先按 “Ctrl + b” (前置鍵)，再按 [ (開括號中括號) 向上翻頁: 上方向鍵或PageUp 離開Copy Mode: Copy Mode中任何時候按”q” 進階: 複制貼上 進入Copy Mode: 先按 “Ctrl + b” (前置鍵)，再按 [ (開括號中括號) 選擇範圍: 移到需要複制的文字起點，“Ctrl + Space” ，然後再移動到結束點，再按”Ctrl + w” 複制 貼上: 離開Copy Mode後，再按”Ctrl + b” ，然後 ] (關括號中括號) 進行貼上 進階: 複制貼上2 某些情況下，我們不允許使用“Ctrl + Space” 或 ”Ctrl + w”，因為它們可能跟系統的組合鍵有衝突，所以需要改為單鍵。 讓tmux使用類似vim的操作模式: echo “set-window-option -g mode-keys vi” >> ~/.tmux.conf 關掉所有使用中的tmux，重開tmux 進入Copy Mode: 先按 “Ctrl + b” (前置鍵)，再按 [ (開括號中括號) 選擇範圍: 移到需要複制的文字起點，按單鍵“Space” ，然後再移動到結束點，再按”Enter” 複制 貼上: 離開Copy Mode後，再按”Ctrl + b” ，然後 ] (關括號中括號) 進行貼上 筆者常用的功能就這些，有興趣的朋友可以再深挖一下。 Reference https://tmuxcheatsheet.com/

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。

Steam Deck 也可以作為文字創作

潮流特區
MacauYeah ・2024-01-23

之前筆者就介紹了，如何使用Steam Deck作為程式開發機使用。這可能對於一般讀者來講不太常用，更常用的是做一些文書處理。筆者最近也拿著Steam Deck，也一步步地補充文書處理所缺少的軟件，正式踏入Steam Deck日常之路。 如果你沒有對系統做過任何更改，在桌面模式中，只要打開「Discover」，輸入後逐的軟件的唯一package name，就可以找到相關軟件。 但如果你像筆者之前一樣，加了homebrew等第三方系統，可能所有軟件都需要在terminal中，經過指令sudo flatpak install PACKAGE_NAME。 Chrome 唯一碼: com.google.Chrome 系統預設瀏覽器只有Firefox，不習慣的話可以另外下載Chrome。有了Chrome，至少所有的雲端文書軟件都可以用，想用Google Doc也沒有問題。 中文輸入法：Fcitx5 + Rime 唯一碼：org.fcitx.Fcitx5 唯一碼：org.fcitx.Fcitx5.Addon.Rime Steam Deck原本有自帶的輸入法，但只適用於螢幕虛擬鍵盤使用（即使用Steam key + X，打開虛擬鍵盤），而實體鍵盤就無法轉輸入法了。這時就需要Linux上的Fcitx5和Rime了。安裝很簡單，之後還要設定一下。 首次安裝後，在啟動器（桌面左下角）搜㝷及啟動 fcitx5，然後在右下角就會見到有個新的鍵盤圖示出現。 按鍵盤圖示，滑鼠右鍵，點選configure，把Rime 加入Fcitx裏面，然後Apply → Close 然後按鍵盤圖示，滑鼠左鍵，應該就會切會成中文輸入法了。這時原本的鍵盤圖示會變成中文輸入法的圖示（或者你經Ctrl-Space也可以） 最後對著中文輸入法圖示，再滑鼠右鍵，可以選擇不同的中文輸入法，例如拼音、注意、倉頡等。 有了輸入法，有了瀏覽器，世界已經都是你的了。 下載器 JDownloader 唯一碼：org.jdownloader.JDownloader 它可以用來下載大部份隱藏文件，例如YouTube video / audio 。但需要注要，首次下載JDownloader 後，還要經過軟件內部更新，否則不能使用。（就像很多手遊，下了主程式後還要下更新檔） 其他 如果你不是長期有網絡，還需要真離線版文書處理器，還可以看看LibreOffice，WPS Office。但這些都不能保證跟windows office 百分百轉換，可能還是使用雲版的Microsoft office 365還要實際。

Steam Deck With Podman

潮流特區
MacauYeah ・2023-10-06

Steam Deck With Podman 眾所週知，Steam Deck預裝的是一台Linux主機。但它的系統比較特別，為了可以安全更新，所以系統最主要的部份都設定為唯讀(read only)。也就是，傳統你可以直接在Linux上經管理員權限安裝的軟件包，全部都會被擋，即使你把唯讀部份設為可讀寫(read / write)，在下次更新時，都會被一次過覆蓋掉。 筆者作為一個負責任的機迷+開發者，怎樣可以白白讓一台Linux機只可以玩遊戲呢? (怎樣跟老婆交代呢?) 所以筆者千辛萬苦，找到一個折衷方案，讓他可以當為開發機使用，那就是Podman。(當然，若果大家有條件有金錢，直接改裝Windows就可以了。) Podman是什麼? Podman跟Docker一樣，都是一些管理和運行Container的主程式。跟Docker不一樣的是，它是Open source，而且是daemonless。 所謂的daemonless，就是不會有一個背景程式去長期管理Container。好處是不會因為背景程式死了，就全部Container一起掛掉，預設也不需要走管理員權限路線。但也因此跟Docker有一些使用上的差異，例如Podman沒有原生的docker-compose結構，即使坊間有python寫的podman-compose去硬對應docker-compose，但某些network是跟結構還是不能直接從Docker轉移過來。 就筆者早期的踩雷經驗而言，用Podman跑起一兩個獨立固定Port的Container來說，都很夠用，也不會遇到奇怪的Bug。所以這次，亦用來作為Steam Deck運行整合式開發的Container。 不平凡的安裝之路 install homebrew Steam OS 3，雖然可以使用更改read / write，再使用pacman來安裝podman。但因為Steam OS更新後，全部要重來，工作量和網路流量都不少，所以筆者改為使用homebrew來安裝podman。homebrew只需要首次安裝時使用管理員權限，之後就會在/home資料夾下留下可執行的程式，所以它不會被Steam OS更新所破壞。 install podman 記得記得重新開機，之後應該就可以成功運行container