簡介Kitematic 0.17.11是一款適用于macOS平臺的圖形化Docker管理工具面向希望在Mac上通過直觀界面運行與維護容器的開發(fā)者、運維人員及Docker初學者。基于Electron框架構建支持從Docker Hub搜索鏡像、一鍵創(chuàng)建容器并能在圖形界面與Docker CLI之間無縫切換同時內置端口映射、環(huán)境變量修改、數(shù)據(jù)卷配置和日志查看等常用功能可顯著降低命令行操作門檻適合日常開發(fā)與容器化學習場景。壓縮包共182個文件整體約56.37MB以C/C頭文件、Electron運行時pak資源、plist配置、current版本標識及resources資源文件為主另有asar歸檔、dylib動態(tài)庫與主程序組件結構完整屬于可直接解壓使用的Mac應用分發(fā)格式。已有294人瀏覽學習適合剛接觸容器化或希望提升開發(fā)效率的macOS用戶。解壓后即可獲得完整可運行的Kitematic.app相關組件省去自行搭建Docker GUI環(huán)境的額外配置步驟便于快速開始容器實踐。1. Kitematic 0.17.11Mac 上一鍵式運行 Docker 的圖形入口拿到一臺 Mac想在本地跑 Docker最直接的反應是裝桌面版客戶端但很多項目到現(xiàn)在還只用 Docker 的基礎功能拉鏡像、開端口、掛目錄、看日志。這些操作在命令行里不難卻架不住每次都要回憶參數(shù)。Kitematic 0.17.11 就是為這個場景生的一個 zip 包解壓后可以一鍵式安裝在 Mac 上把 Docker 跑起來然后給你一個圖形窗口。反直覺的是這個停更多年的老版本反而成了穩(wěn)定代名詞——它不追新功能資源占用小界面樸素適合不想被新版桌面端綁架的人。如果你剛開始接觸容器或者只想把 Docker 當本地工具用這個舊版圖形客戶端仍然值得試一遍。2. Mac 上跑 Docker 的選型為什么還要留一份 Kitematic2.1 Docker 在 Mac 上為什么非要一層虛擬機Docker 容器本身用的是 Linux 內核的 namespace 和 cgroup而 macOS 的內核是 XNU不能直接運行 Linux 容器。所以在 Mac 上跑 Docker本質上繞不開一層虛擬化先啟動一個帶 Linux 內核的虛擬機虛擬機里跑 Docker daemon再讓客戶端與 daemon 通信。Kitematic 0.17.11 那個年代的常見做法是用輕量虛擬機工具創(chuàng)建一臺名為 default 的虛擬機虛擬機上跑 Linux 和 Docker 引擎圖形界面只是前端。Kitematic 把創(chuàng)建虛擬機、啟動引擎、連接客戶端這一整套流程封裝成按鈕和進度條。你看不到 docker-machine 的細節(jié)但如果你打開過系統(tǒng)監(jiān)控會看到一個虛擬機進程一直占著內存和 CPU。理解這一點很重要Kitematic 不是容器運行時它是一個殼真正干活的是后面那臺 Linux 虛擬機。所以當你遇到“Kitematic 打不開”“引擎啟動失敗”這類問題時第一反應不應該是重裝 Kitematic而是去看那臺虛擬機還在不在、能不能啟動。正好這個版本的 Kitematic 通常和 docker-machine 是同一套體系。裝完后打開終端執(zhí)行 docker-machine ls經(jīng)常能看到一臺名為 default 的機器。它的狀態(tài)是 Running 還是 Stopped基本決定了 Kitematic 能不能工作。默認配置下這臺虛擬機的內存和 CPU 都很保守如果你要跑多容器應用內存不夠是常態(tài)。常見做法是先停掉虛擬機把內存調到 2GB 以上再啟動。docker-machine stop default VBoxManage modifyvm default --memory 2048 --cpus 2 docker-machine start default這里 VBoxManage 是虛擬機工具提供的命令--memory 2048 表示把內存設為 2048MB--cpus 2 表示分配兩個 CPU 核心。先 stop 再改參數(shù)是必須的因為虛擬機運行中改配置會不生效甚至把配置寫壞。Kitematic 打開時如果你繞過了這個步驟很多容器會啟動很慢或者在編譯前端項目時直接卡死。調完內存后在 Kitematic 里重啟容器通常體感會好很多。2.2 Kitematic、docker CLI、Docker Desktop 三者怎么選現(xiàn)在 Mac 上跑 Docker 的主流方式大致有三類命令行 docker、Docker Desktop 這類現(xiàn)代客戶端以及 Kitematic 0.17.11 這種老圖形界面。命令行 docker 靈活適合寫腳本和持續(xù)集成但每次都要手敲參數(shù)Docker Desktop 功能全支持 compose、Kubernetes、BuildKit但體積大、啟動慢而且某些老項目在它上面反而因為環(huán)境差異跑不起來。Kitematic 的優(yōu)勢是輕、直接、打開就能看到容器。Kitematic 創(chuàng)建的容器和你在終端命令行里創(chuàng)建的容器沒有任何本質差別。它只是把 docker run 的參數(shù)翻譯成表單提交給同一個 Docker daemon。所以你完全可以一半操作在 Kitematic 里點一半操作在終端里敲。比如你在 Kitematic 里創(chuàng)建了一個 nginx 容器回到終端執(zhí)行 docker ps能看到同一個容器。這種“圖形界面看狀態(tài)命令行做精細操作”的組合是我用 Kitematic 最常見的姿勢。如果你比較依賴 docker-compose可能會覺得 Kitematic 不夠用。0.17.11 這個版本畢竟更擅長單個容器的創(chuàng)建與查看而不是多服務編排。但即使這樣它仍然能當 Compose 項目的“顯示器”用命令行把 compose 的服務啟動起來然后在 Kitematic 里刷新容器列表看日志和端口映射。對于不想長時間盯著終端的人來說這種搭配反而比純命令行順手。還有一個邊界問題終端里跑 docker 命令時如果提示 cannot connect to the Docker daemon大概率是環(huán)境變量沒有指向 Kitematic 管理的虛擬機。常見做法是執(zhí)行 eval $(docker-machine env default)讓當前終端連接到 default 這臺機器。Kitematic 自己啟動時已經(jīng)做好了這件事但終端是獨立的默認不會繼承。把這一行加到 shell 配置里之后每次開終端就能直接 docker ps。方式上手成本適合場景維護狀態(tài)docker CLI中等腳本、CI、精細控制持續(xù)更新Docker Desktop低新項目、多服務編排持續(xù)更新Kitematic 0.17.11極低看容器、看日志、快速驗證已停更穩(wěn)定這張表是我日常做選型時的大致判斷。如果你的項目需要 BuildKit、多平臺構建、Kubernetes 這類新能力用 Kitematic 會很不舒服因為它的功能邊界停留在那個年代。反過來如果只是想本地跑一個數(shù)據(jù)庫、一個 Nginx或者臨時起一個 RedisKitematic 的輕量反而更省資源。所謂“要不要留一份 Kitematic”本質不是新舊之爭而是你的工作流需不需要那個圖形入口。3. 安裝 Kitematic 0.17.11從 zip 解壓到跑通 hello-world3.1 解壓 zip 與安裝兩個命令解決拿到 Kitematic-0.17.11-Mac.zip 之后雙擊 zip 雖然也能解壓但我建議直接用命令行這樣能看到解壓結果也能順手處理 macOS 的隔離屬性。打開終端進入下載目錄執(zhí)行 unzip 解壓解壓出來通常是 Kitematic.app把它移動到應用程序目錄然后刪掉 quarantine 屬性這一步是為了繞過 Gatekeeper 的攔截。cd ~/Downloads unzip Kitematic-0.17.11-Mac.zip mv Kitematic.app /Applications/ xattr -dr com.apple.quarantine /Applications/Kitematic.app open /Applications/Kitematic.app第一行是進入下載目錄不要省如果你把 zip 放在別的位置把路徑換成實際路徑即可。unzip 解壓后建議用 ls 看一下目錄內容確認是不是真的有一個 .app 文件。mv 是移動到應用程序目錄這樣 Launchpad 和聚焦搜索都能直接找到。xattr -dr com.apple.quarantine 是關鍵一行它把“來自網(wǎng)絡”的標記刪掉否則新版本 macOS 會提示應用已損壞或無法驗證開發(fā)者。最后 open 直接啟動。如果你不想用 xattr也可以右鍵點 Kitematic.app選擇“打開”然后在系統(tǒng)彈窗里點“仍要打開”。兩種方式本質一樣都是繞過 Gatekeeper 的一次性攔截。不過右鍵打開之后以后每次啟動可能還會再彈一次用 xattr 清掉隔離屬性后后續(xù)啟動會更干凈。需要注意的是這條命令只對當前這臺機器有效換一臺機器重新下載 zip還是需要再處理一次。3.2 第一次啟動引擎檢測、虛擬機創(chuàng)建與鏡像源打開 Kitematic 后它會自動檢測本機有沒有可用的 Docker 引擎。如果是干凈環(huán)境界面會走到虛擬機創(chuàng)建流程讓你等待引擎初始化。這一步經(jīng)常會給人一種“卡住”的錯覺因為進度條可能長時間停在某個階段。建議先打開活動監(jiān)視器看有沒有虛擬機相關的進程在跑。如果進程存在但界面不動通常是網(wǎng)絡問題或虛擬機配置不兼容如果根本沒有相關進程再考慮引擎是否被系統(tǒng)攔截。驗證引擎是否正常最直接的方法是打開終端執(zhí)行 docker-machine ls。如果能看到 default 這臺機器并且狀態(tài)是 Running就說明 Kitematic 背后的引擎是好的。如果 docker-machine 命令不存在說明你的環(huán)境還缺工具鏈常見做法是補裝對應版本的工具。安裝過程中Kitematic 一般會提供引導你不需要手動做太多事。docker-machine ls eval $(docker-machine env default) docker version第一行列出所有虛擬機第二行讓當前終端連到 default 這臺機器第三行顯示客戶端和引擎的版本?？吹?Server 和 Client 兩段信息都正常才算真正連通。eval 命令只會影響當前終端窗口關掉終端就失效如果你不想每次都手動執(zhí)行可以把第二行追加到 ~/.zshrc 或 ~/.bashrc 里。但要注意這臺虛擬機的 IP 地址可能變化追加到配置文件里之后要定期確認環(huán)境變量是否仍然有效。鏡像源這一塊Kitematic 0.17.11 提供了設置入口。如果你拉鏡像特別慢常見做法是找一個所在網(wǎng)絡環(huán)境下可達的鏡像站填到 Docker 引擎的 Registry mirror 配置里。這里我不給你具體地址因為不同網(wǎng)絡環(huán)境可信度差很多。改完鏡像源之后記得重啟 Docker 引擎否則配置不會生效。如果你只是跑 hello-world其實不太受鏡像源影響所以建議先不調等真遇到拉不動時再動手。3.3 跑通第一個容器hello-world引擎啟動后Kitematic 主界面上會有一個搜索框。在里面輸入 hello-world搜索結果會出現(xiàn)官方示例鏡像點 Create 就會開始拉取并創(chuàng)建容器。這個容器和命令行創(chuàng)建出來的完全一樣界面下方會顯示日志區(qū)域。如果一切正常你會在日志里看到一段帶感嘆號的提示文本說明 Docker daemon 已經(jīng)把容器跑起來了。如果你想在這個環(huán)節(jié)順便驗證一下命令行環(huán)境也可以不用圖形界面直接在終端執(zhí)行docker run --name hello-world-example hello-world--name 是給容器起一個固定名字方便后續(xù)用 docker logs、docker inspect 精確引用。hello-world 是一個一次性容器它打印完歡迎信息后就會退出不是常駐進程。所以你在 Kitematic 里看到這個容器狀態(tài)為 Exited并不代表有問題反而說明流程已經(jīng)走通。退出碼為 0 就是正常的。如果日志里出現(xiàn)了 exec format error 或者找不到鏡像常見原因是拉到了和當前 CPU 架構不匹配的鏡像或者是網(wǎng)絡問題導致鏡像層不完整。先確認鏡像名拼寫無誤再看本機架構是不是 Apple Silicon。Kitematic 0.17.11 是 Intel 時代的產品在老 Intel Mac 上通常很順在 M 系列芯片上則需要額外關注鏡像架構。hello-world 這類系統(tǒng)鏡像一般會自帶多架構支持但如果你的工程鏡像沒有就需要手動指定平臺參數(shù)。4. Kitematic 核心操作鏡像、容器、端口映射與數(shù)據(jù)卷4.1 圖形界面創(chuàng)建 nginx 容器及等價 docker 命令跑通 hello-world 之后可以試一個真正常駐的服務比如 Nginx。在 Kitematic 搜索框輸入 nginx選擇 latest 標簽點 Create。創(chuàng)建完成后進入容器詳情頁找到端口設置區(qū)域把容器內部的 80 端口映射到 Mac 的 8080 端口。設置好之后瀏覽器訪問 localhost:8080就能看到 Nginx 默認頁面。這一串圖形操作對應的命令行是docker run -d --name web -p 8080:80 nginx:latest-d 表示后臺運行容器不會因為終端關閉而退出--name web 給容器起名叫 web-p 8080:80 表示把 Mac 上的 8080 端口轉發(fā)到容器內的 80 端口nginx:latest 是鏡像名和標簽。如果你在 Kitematic 里創(chuàng)建時把容器名寫成了別的等價命令里 --name 也要跟著改。這個等價關系是理解 Kitematic 的關鍵界面上的每一個輸入框背后幾乎都能對應到一個 docker run 參數(shù)。如果你在界面里設置了環(huán)境變量比如 NGINX_HOSTlocalhost那么等價命令里會多一個 -e 參數(shù)。環(huán)境變量在容器啟動時被注入進程里可以直接讀取。常見用法是給應用配置數(shù)據(jù)庫地址、緩存地址、運行模式。例如docker run -d --name web -p 8080:80 -e NGINX_HOSTlocalhost -e NGINX_PORT80 nginx兩個 -e 可以分別定義不同的變量。這里 NGINX_HOST 和 NGINX_PORT 不是 Docker 的保留參數(shù)而是 Nginx 官方鏡像里的模板變量它會根據(jù)這些值生成配置。換成別的鏡像變量名可能需要跟著鏡像文檔走。UI 里設置環(huán)境變量的好處是不容易漏掉引號壞處是如果你不確定變量名排查起來比命令行更麻煩。在容器列表頁面你可以對容器做停止、啟動、刪除操作。停止等價于 docker stop啟動等價于 docker start刪除等價于 docker rm。這里有個容易混淆的地方刪除容器和刪除鏡像不是一回事。容器是鏡像運行出來的實例刪掉容器不會把鏡像刪掉下次還能再創(chuàng)建。Kitematic 的界面里通常分開顯示鏡像和容器操作前先看清當前選中的是哪個對象。4.2 端口映射和數(shù)據(jù)卷參數(shù)在哪設注意什么端口映射是 Kitematic 里最常用的設置之一。圖形界面上通常會有一個端口列表左邊是 Mac 上的端口右邊是容器內的端口。填寫時要注意順序左邊是本機端口右邊是容器端口。如果你把 8080:80 寫反成 80:8080訪問 localhost:80 時不一定有進程監(jiān)聽而容器里 8080 端口通常也沒服務結果就是連接被拒絕。端口沖突是常見的翻車點。如果你同時跑了兩個容器都要映射到 Mac 的 8080 端口后一個會啟動失敗界面里會顯示端口綁定錯誤。解決辦法是給第二個容器換一個本機端口比如 8081。如果你不確定哪些端口被占用可以在終端執(zhí)行 lsof -i :8080看看是哪個進程占著。Kitematic 不會幫你自動換端口它只會把錯誤擺出來。數(shù)據(jù)卷的設置稍微隱蔽一點。在 Kitematic 里選中容器后進入設置找到目錄或卷相關的區(qū)域選擇一個 Mac 上的文件夾把它和容器內路徑對應起來。這樣做的意義是容器內寫文件時數(shù)據(jù)實際落到 Mac 的文件夾里容器刪掉后數(shù)據(jù)還在。命令行的表達方式是用 -v 參數(shù)。docker run -d --name web -p 8080:80 -v ~/demo-site:/usr/share/nginx/html:ro nginx-v 的參數(shù)格式是 本機路徑:容器路徑:權限。上面的例子把 Mac 上 ~/demo-site 目錄掛載到容器內 Nginx 的頁面目錄 /usr/share/nginx/htmlro 表示只讀容器內不能反過來修改宿主機文件。如果去掉 ro容器內就能寫入這樣會帶來文件權限問題。比如容器進程以 root 運行寫入的文件在 Mac 上可能變成 root 所有你以后在 Finder 里刪都刪不掉。掛載路徑如果有空格一定要用引號包住否則 Docker 會把路徑拆成兩段最后報錯。常見做法是先把項目目錄整理成沒有空格的路徑比如 ~/demo-site避免不必要的坑。掛載生效后修改宿主機文件容器內會立即看到不需要重啟容器。這跟你用 docker cp 拷文件完全不同docker cp 是一次性拷貝掛載是持續(xù)同步。驗證數(shù)據(jù)卷是否生效最簡單的方法是先在宿主機寫一個文件再進容器里看一下echo h1hello kitematic/h1 ~/demo-site/index.html docker exec web ls -l /usr/share/nginx/html curl -I http://localhost:8080第一行在宿主機創(chuàng)建頁面文件第二行進入容器列出目錄內容第三行用 curl 請求本地端口。如果你看到 index.html 存在并且 curl 返回 200說明掛載鏈路沒問題。如果第二行報目錄不存在多半是容器鏡像里的路徑不是 /usr/share/nginx/html需要用 docker inspect 確認實際路徑。4.3 日志與終端日常調試最常用的兩個入口Kitematic 的容器詳情頁通常有兩個很顯眼的面板Logs 和 Terminal。Logs 顯示的是容器進程的標準輸出和標準錯誤也就是 docker logs 看到的內容。排錯時先看日志比瞎猜更高效。比如你啟動一個容器后訪問不到服務日志里如果有 “port already in use”就說明容器內端口被占用如果有 “Address already in use”則要懷疑端口映射配置。終端面板相當于讓你直接進入容器內部等價于 docker exec -it 容器名 bash。這個功能在處理容器內文件結構時很有用。但要注意不是所有鏡像都自帶 bash某些精簡鏡像只有 sh。如果終端打開后報 “bash: not found”把命令換成 sh 再試一次。docker logs --tail 100 web docker exec -it web bashdocker logs 是查看容器日志的通用命令--tail 100 表示只看最后 100 行適合容器運行很久、日志刷屏的情況。不加 --tail 會輸出全部日志可能很長。docker exec 是進入運行中的容器執(zhí)行命令-i 表示保持標準輸入打開-t 分配一個偽終端后面的 bash 是你要執(zhí)行的程序。退出容器時輸入 exit 即可。此外docker inspect 是比日志更底層的排查工具。它返回容器的完整配置包括端口綁定、環(huán)境變量、掛載卷、網(wǎng)絡模式。Kitematic 面板里顯示給你的信息很多都來自 inspect 的某個字段。在終端里執(zhí)行 docker inspect 可以確認你在界面上設置的參數(shù)到底有沒有生效。如果界面設置后容器沒有明顯變化先 inspect再重啟容器。5. 避坑 Kitematic 0.17.11Mac 上 6 個常見問題與排查5.1 安裝期Gatekeeper、VM 創(chuàng)建失敗、架構不匹配先說安裝期最常見的翻車?，F(xiàn)象是雙擊 Kitematic.app 后系統(tǒng)彈窗提示“應用程序已損壞無法打開”或者“無法驗證開發(fā)者”。原因是這個版本太老沒有經(jīng)過新版 macOS 的公證Gatekeeper 默認不允許運行。解決方式在前面已經(jīng)提過用 xattr 清除隔離屬性是相對徹底的辦法如果你不想用命令就右鍵打開再點“仍要打開”。處理完之后再啟動通常就不會彈了。第二個問題是打開 Kitematic 后一直卡在 Creating VM或者直接提示虛擬機啟動失敗?，F(xiàn)象是進度條長時間不動日志里出現(xiàn) VBox 相關的錯誤。原因是新版 macOS 對內核擴展的管控越來越嚴老版本虛擬機工具裝不進系統(tǒng)或者 CPU 虛擬化沒有被正常啟用。解決時先到系統(tǒng)設置里確認虛擬化相關的開關是否打開然后把虛擬機工具重裝一遍如果仍然失敗說明這個版本的 Kitematic 和你當前的 macOS 跨度太大最省時間的辦法是換用 Docker Desktop 或更新的圖形客戶端。第三個問題是在 Apple Silicon 上跑出 exec format error。現(xiàn)象是容器創(chuàng)建后立刻退出日志提示無法執(zhí)行某個二進制格式甚至報出 qemu 相關字樣。原因是鏡像和宿主機的 CPU 架構不匹配。Kitematic 0.17.11 是 Intel 時代的產物如果 Mac 是 M 系列芯片老鏡像里大量 x86_64 內容可能沒辦法原生運行。解決方式是在拉鏡像時優(yōu)先選擇 arm64 版本或者干脆別在這臺機器上堅持用這個老版本。老工具在老硬件上穩(wěn)定在新型號上并不一定。5.2 運行期端口沖突、數(shù)據(jù)丟失、拉鏡像慢第四個問題是端口映射后訪問不到?，F(xiàn)象是容器看起來在運行docker ps 也能看到端口映射但瀏覽器訪問 localhost:8080 就是打不開。原因通常是映射方向寫反了把 8080:80 寫成了 80:8080。解決方式是先確認界面或命令行里的參數(shù)順序左邊一定是 Mac 的端口右邊才是容器端口。如果確認沒寫反再用 curl 在本機試一下排除瀏覽器緩存干擾。第五個問題是容器重啟后數(shù)據(jù)丟失。現(xiàn)象是你在容器里創(chuàng)建了一個數(shù)據(jù)庫或者寫了一個文件容器 stop 之后再 start數(shù)據(jù)還在一旦把容器刪除再重新創(chuàng)建數(shù)據(jù)全沒了。原因是數(shù)據(jù)寫在容器自帶的可寫層里docker rm 會連帶刪除這一層。解決方式是不要依賴容器內部存儲把數(shù)據(jù)目錄掛載到 Mac 上。在 Kitematic 里給容器添加數(shù)據(jù)卷或者在命令里加 -v 參數(shù)之后刪除容器重建只要掛載路徑不變數(shù)據(jù)就不會丟。第六個問題是拉取鏡像速度極慢或者超時?，F(xiàn)象是創(chuàng)建鏡像時進度條幾乎不動最后提示 net/http: TLS handshake timeout。原因是默認鏡像倉庫在當前網(wǎng)絡環(huán)境下連接不穩(wěn)定。解決方式有兩條路一是給 Docker 引擎配置可用的鏡像源在 Kitematic 的引擎設置里填 registry mirror填完必須重啟引擎二是通過離線方式導入鏡像。如果你有另一臺機器已經(jīng)拉好了鏡像可以用 docker save 導出成 tar 包再拿過來 docker load 導入。docker save nginx:latest -o nginx.tar docker load -i nginx.tardocker save 把鏡像保存成本地文件-o 指定輸出文件名docker load 讀取 tar 包并導入鏡像。這種方式不依賴網(wǎng)絡速度適合內網(wǎng)環(huán)境或跨機器復制。Kitematic 的界面里不會直接提供這個功能所以我會在終端里處理鏡像導入再回到界面里創(chuàng)建容器。導入成功后容器列表里就能看到這個鏡像。6. 進階用法把本地項目掛進容器實現(xiàn)開發(fā)熱更新Kitematic 0.17.11 做成日常開發(fā)環(huán)境最關鍵的一步是把項目目錄掛載進容器。以 Node.js 項目為例我把當前目錄掛到容器內的 /app容器里啟動開發(fā)服務器改代碼后頁面會自動刷新完全不用手動重啟容器。這個玩法在微信小程序、前端后臺、后端 API 的本地聯(lián)調里都適用。docker run -d --name dev-server \ -p 3000:3000 \ -v $PWD:/app \ -e NODE_ENVdevelopment \ node:18 \ npm run dev--name dev-server 是給容器起名-p 3000:3000 把宿主機 3000 端口映射到容器 3000 端口-v $PWD:/app 把當前終端所在目錄掛載為容器內 /app-e NODE_ENVdevelopment 設置運行環(huán)境node:18 作為基礎鏡像npm run dev 是容器啟動后執(zhí)行的命令。掛載目錄之后你在 Mac 上對源代碼的每一次保存都會立刻同步到容器內開發(fā)服務器監(jiān)聽到文件變化后會觸發(fā)熱更新。驗證方法很簡單瀏覽器打開 http://localhost:3000看到頁面后修改項目里的一個標題文本保存再回瀏覽器頁面會自己刷新。如果項目沒有配置熱更新至少也能看到容器日志里出現(xiàn)文件變化觸發(fā)的重新編譯記錄。這時候再回到 Kitematic點開容器的日志面板你會看到和終端里一樣的輸出日常調試就不用來回切窗口了。我個人的習慣是Kitematic 0.17.11 的 zip 包會一直備份著遇到老項目、低配機器、臨時演示環(huán)境時優(yōu)先用它遇到需要 compose 或 Kubernetes 的新項目才切換到現(xiàn)代客戶端。不要為了追新把一個已經(jīng)跑通的環(huán)境反復重裝很多看起來像玄學的問題其實都出在環(huán)境被折騰壞了。希望幫到你。本文還有配套的精品資源點擊獲取