說(shuō)實(shí)話Docker 的命令行看一遍文檔誰(shuí)都會(huì)難的是把“能敲出幾條命令”變成“腦子里有一套完整的操作邏輯”。尤其那些天天上熱搜的問(wèn)題docker 安裝失敗、desktop 起不來(lái)、權(quán)限報(bào)錯(cuò)、網(wǎng)絡(luò)不通、MySQL 和 Redis 裝好卻連不上根源大多不是命令本身記不熟而是對(duì) Docker 的命令行體系、對(duì)象關(guān)系、網(wǎng)絡(luò)和數(shù)據(jù)卷的底層工作原理缺少一個(gè)整體認(rèn)知。這篇內(nèi)容沒(méi)有太多“介紹”和“概述”我直接把自己這些年從入門(mén)到能獨(dú)立維護(hù)生產(chǎn)環(huán)境的經(jīng)驗(yàn)拆開(kāi)了寫(xiě)。全文圍繞 Docker 命令行核心命令展開(kāi)從環(huán)境初始化、鏡像和容器管理、Compose 編排到網(wǎng)絡(luò)、數(shù)據(jù)卷、高頻排錯(cuò)一路寫(xiě)到日常維護(hù)習(xí)慣。適合兩類(lèi)人一類(lèi)是剛接觸 Docker想系統(tǒng)性把命令學(xué)扎實(shí)的新手另一類(lèi)是已經(jīng)在用 Docker但遇到問(wèn)題只能靠百度、搜完還是不知道原因的實(shí)踐者。讀完這篇至少你拿到任何一個(gè)容器項(xiàng)目都能用命令行把它盤(pán)清楚。1. 先把環(huán)境盤(pán)明白安裝、守護(hù)進(jìn)程與命令行入口命令行本質(zhì)上只是一個(gè)客戶端真正干活的是后臺(tái)的 Docker 守護(hù)進(jìn)程。很多人剛上手就卡在環(huán)境上所以我先把安裝、版本選擇和 Socket 權(quán)限這幾個(gè)基礎(chǔ)問(wèn)題說(shuō)透。1.1 Linux 安裝 Docker 時(shí)我為什么推薦走官方源而不是無(wú)腦一鍵腳本Linux 上安裝 Docker常用的方式有三種系統(tǒng)自帶包管理器里的舊版本、官方一鍵腳本、手動(dòng)配置官方源的完整安裝。我的建議是——生產(chǎn)環(huán)境不要用系統(tǒng)源里的 docker.io版本太老一鍵腳本雖然快但有時(shí)會(huì)默認(rèn)拉取你不太想要的版本而且腳本執(zhí)行過(guò)程不可控。以 Ubuntu 為例我習(xí)慣手動(dòng)配置 Docker 官方源步驟并不復(fù)雜sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg隨后寫(xiě)入源文件注意 Ubuntu 版本代號(hào)要和官方路徑匹配echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null接著執(zhí)行sudo apt-get update安裝核心組件sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin這里有幾個(gè)點(diǎn)需要解釋。docker-ce是社區(qū)版守護(hù)進(jìn)程docker-ce-cli是命令行工具這兩者分開(kāi)裝的好處是以后即使你只要個(gè)遠(yuǎn)程客戶端也不需要在服務(wù)器上跑守護(hù)進(jìn)程。containerd.io是運(yùn)行時(shí)底座鏡像真正由 containerd 管理Docker CLI 只是上層封裝。docker-buildx-plugin和docker-compose-plugin一個(gè)是多架構(gòu)構(gòu)建工具一個(gè)是 Compose v2 插件后面編排都會(huì)用到。安裝完成后用docker version驗(yàn)證。如果只看到 Client 版本而 Server 部分是空的說(shuō)明守護(hù)進(jìn)程沒(méi)起來(lái)先查systemctl status docker必要時(shí)手動(dòng)sudo systemctl start docker。這一步很多人忽略導(dǎo)致后面所有命令都報(bào)“Cannot connect”。1.2 單機(jī)環(huán)境與 Docker DesktopCLI 行為差異很多 Windows 和 macOS 用戶接觸 Docker 是從 Docker Desktop 開(kāi)始的。它的本質(zhì)是在本機(jī)虛擬化一個(gè) Linux 環(huán)境CLI 只是發(fā)指令的窗口。Desktop 的優(yōu)勢(shì)是圖形化、免 Linux 安裝劣勢(shì)是它在操作系統(tǒng)和 Docker Engine 之間多了一層一旦虛擬化層出問(wèn)題命令行就會(huì)報(bào)一堆看起來(lái)很?chē)樔说腻e(cuò)。安裝 Docker Desktop 后先運(yùn)行docker context ls看一下當(dāng)前使用的是哪個(gè)上下文。你會(huì)看到類(lèi)似desktop-linux *的條目星號(hào)表示當(dāng)前環(huán)境。如果誤刪或切換了 context可以用docker context use desktop-linux切回來(lái)。這個(gè)命令知道的人不多但排錯(cuò)時(shí)很關(guān)鍵。Desktop 環(huán)境下還要注意命令行報(bào)npipe:////./pipe/dockerDesktopLinuxEngine連不上絕大多數(shù)不是你的命令寫(xiě)錯(cuò)了而是 Docker Desktop 里 Linux Engine 沒(méi)起來(lái)。常見(jiàn)原因有三個(gè)宿主機(jī)沒(méi)有開(kāi)啟硬件虛擬化WSL2 內(nèi)核或系統(tǒng)組件版本過(guò)舊以及 Desktop 服務(wù)被安全軟件攔截。第一個(gè)問(wèn)題要到 BIOS 里找 Intel VT-x 或 AMD SVM 開(kāi)關(guān)Windows 功能里也要確?！疤摂M機(jī)平臺(tái)”和“適用于 Linux 的 Windows 子系統(tǒng)”兩項(xiàng)已勾選。做完這些再重啟 Docker Desktop基本都能解決。1.3 最常見(jiàn)的啟動(dòng)失敗Socket 權(quán)限與守護(hù)進(jìn)程檢查L(zhǎng)inux 下首次運(yùn)行docker ps新手最容易碰到的是permission denied while trying to connect to the Docker daemon socket這個(gè)報(bào)錯(cuò)的原因很簡(jiǎn)單Docker CLI 默認(rèn)通過(guò)/var/run/docker.sock和守護(hù)進(jìn)程通信這個(gè) socket 文件屬于 root 用戶和 docker 組普通用戶不在 docker 組里自然沒(méi)權(quán)限。解決方案兩條路。臨時(shí)用sudo沒(méi)問(wèn)題但如果天天sudo docker文件歸屬和權(quán)限會(huì)變得一團(tuán)糟而且很多生成物比如掛載出來(lái)的文件都會(huì)帶 root 權(quán)限后續(xù)清理很煩。推薦把當(dāng)前用戶加入 docker 組sudo usermod -aG docker $USER newgrp docker執(zhí)行后重新登錄終端再docker ps即可。這里要潑一盆冷水把用戶加入 docker 組等同于授予該用戶 root 級(jí)別的宿主機(jī)權(quán)限因?yàn)槿萜骺梢話燧d宿主機(jī)目錄、甚至直接讀寫(xiě)/。所以只對(duì)可信用戶這么做生產(chǎn)服務(wù)器上盡量用 sudo 臨時(shí)提權(quán)別圖省事。還有一種情況是守護(hù)進(jìn)程完全沒(méi)起來(lái)。systemctl status docker會(huì)顯示 active (running) 才是正常如果不是查看journalctl -u docker -n 50看具體失敗原因。常見(jiàn)的有網(wǎng)絡(luò)橋接創(chuàng)建失敗、iptables 配置被安全軟件改寫(xiě)、磁盤(pán)滿等。這些問(wèn)題在命令行階段暴露得越早越好。2. 鏡像與容器兩個(gè)核心對(duì)象吃透Docker 的日常操作里鏡像和容器幾乎占據(jù)所有高頻命令。鏡像是一個(gè)只讀模板容器是模板運(yùn)行后的實(shí)例。很多命令就是圍繞這兩個(gè)對(duì)象增刪改查理解它們的關(guān)系命令就背住了三分之二。2.1 鏡像命令pull/images/tag/rmi/save/load先看拉取鏡像。默認(rèn)從 Docker Hub 拉取docker pull nginx:1.25-alpine后面附帶的標(biāo)簽tag非常重要。:1.25-alpine表示 Nginx 1.25 的 Alpine 精簡(jiǎn)版本體積小、攻擊面少適合做基礎(chǔ)鏡像。不寫(xiě) tag 默認(rèn)拉latest但latest是一個(gè)滑動(dòng)標(biāo)簽昨天是 1.25明天可能變成 2.0生產(chǎn)環(huán)境最忌諱這種不確定性。所以我會(huì)給線上服務(wù)固定一個(gè)具體 tag必要時(shí)再附帶摘要digest鎖定鏡像版本。查看本地鏡像用docker images也可以簡(jiǎn)寫(xiě)為docker image ls。輸出里包含 REPOSITORY、TAG、IMAGE ID、CREATED、SIZE。SIZE 看著很小不表示完整系統(tǒng)占用因?yàn)樗@示的是單層大小多層累加可能更大。打標(biāo)簽是給鏡像起別名docker tag nginx:1.25-alpine registry.example.com/prod/nginx:1.25-alpine這一步在做私有倉(cāng)庫(kù)推送前幾乎必用把項(xiàng)目名、環(huán)境、版本都寫(xiě)進(jìn)標(biāo)簽里。刪除鏡像用docker rmi image_id或docker image rm。遇到容器還在使用鏡像時(shí)會(huì)報(bào) conflict需要先刪容器再刪鏡像或者直接加-f強(qiáng)刪——但我不推薦輕易用強(qiáng)刪容易把還在運(yùn)行的依賴層關(guān)系搞亂。離線傳輸和備份我會(huì)用 save/loaddocker save -o nginx.tar nginx:1.25-alpine docker load -i nginx.tardocker save保留了鏡像的所有歷史層和元數(shù)據(jù)適合跨機(jī)器遷移。對(duì)應(yīng)地還有docker export但它導(dǎo)出的是容器文件系統(tǒng)不是鏡像常用于緊急取文件不要混用。看鏡像內(nèi)部細(xì)節(jié)用docker inspect返回的是 JSON 格式包含了 entrypoint、環(huán)境變量、端口暴露、掛載點(diǎn)等大量信息。我最常搭配--format輸出指定字段比如只查看入口命令docker inspect --format{{.Config.Entrypoint}} nginx:1.25-alpinedocker history則能看到每一層執(zhí)行了什么命令排查“為什么鏡像這么大”時(shí)非常有用。2.2 容器生命周期run/ps/logs/exec/rm容器的完整生命周期是創(chuàng)建-啟動(dòng)-運(yùn)行-暫停/停止-刪除。但日常用docker run一條命令直接完成創(chuàng)建和啟動(dòng)它也是最復(fù)雜的核心命令沒(méi)有之一。先看一個(gè)綜合示例docker run -d \ --name nginx-web \ -p 8080:80 \ -v /data/nginx:/usr/share/nginx/html \ -e TZAsia/Shanghai \ --restart unless-stopped \ nginx:1.25-alpine各參數(shù)的含義我拆開(kāi)講-d后臺(tái)運(yùn)行容器終端輸出不掛住。--name給容器起名比用隨機(jī) ID 有辨識(shí)度。-p 8080:80宿主機(jī) 8080 映射到容器 80。端口沖突時(shí) Docker 不會(huì)自動(dòng)換端口而是直接報(bào)錯(cuò)所以我習(xí)慣先ss -tlnp | grep 8080檢查端口占用。-v掛載數(shù)據(jù)卷或目錄。-e傳入環(huán)境變量。時(shí)間是容器里最容易忽略的很多容器默認(rèn) UTC 時(shí)區(qū)必須用TZAsia/Shanghai指定。--restart unless-stopped容器異常退出會(huì)自動(dòng)拉起手動(dòng) stop 后不會(huì)重啟。這是最推薦的?；畈呗詀lways在某些主動(dòng)停止場(chǎng)景下反而會(huì)反復(fù)拉起。查看容器運(yùn)行狀態(tài)docker ps只看存活容器docker ps -a看全部包括已退出的容器。輸出里的 STATUS 字段很重要Up 3 hours正常Exited (0)是正常退出Exited (137)通常是內(nèi)存溢出被 killRestarting要重點(diǎn)關(guān)注。查看日志是排錯(cuò)第一手段docker logs -f --tail 200 nginx-web-f實(shí)時(shí)跟蹤輸出--tail 200只顯示最后 200 行。想做時(shí)間范圍過(guò)濾可以加--since 10m否則大日志會(huì)直接刷爆終端。進(jìn)入正在運(yùn)行的容器分兩種docker attach和docker exec。attach是把當(dāng)前終端接到容器主進(jìn)程上容易掛住甚至導(dǎo)致容器等主進(jìn)程退出排錯(cuò)時(shí)我極少用它。exec是在容器內(nèi)新起進(jìn)程更安全docker exec -it nginx-web sh-i保持標(biāo)準(zhǔn)輸入-t分配偽終端。兩個(gè)參數(shù)經(jīng)常一起用少一個(gè)都可能出現(xiàn)輸入無(wú)效或排版錯(cuò)亂。停止和刪除也有講究。docker stop會(huì)先給容器一個(gè)優(yōu)雅停止時(shí)間默認(rèn) 10 秒超時(shí)再?gòu)?qiáng)制 kill。數(shù)據(jù)庫(kù)類(lèi)容器我建議docker stop -t 60給更多時(shí)間刷盤(pán)。刪除容器用docker rm刪除正在運(yùn)行的容器需要先停再刪或者docker rm -f直接強(qiáng)制刪。但我遇到過(guò)很多次-f導(dǎo)致數(shù)據(jù)沒(méi)來(lái)得及落盤(pán)的案例所以生產(chǎn)環(huán)境我盡量不用。2.3 用 MySQL 8.0 實(shí)戰(zhàn)驗(yàn)證常用參數(shù)理論說(shuō)多了容易暈這里用一個(gè)具體的 MySQL 8.0 部署把命令串起來(lái)。很多網(wǎng)上教程會(huì)直接讓你跑一條 run但實(shí)踐中我的步驟是分層的。第一步準(zhǔn)備好宿主機(jī)數(shù)據(jù)目錄避免 mysql 容器以 root 身份在目錄里創(chuàng)建文件后難以維護(hù)mkdir -p /data/mysql/{data,conf,logs}第二步運(yùn)行容器docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDRoot123456 \ -e TZAsia/Shanghai \ -v /data/mysql/data:/var/lib/mysql \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/logs:/var/log/mysql \ --restart unless-stopped \ mysql:8.0 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_unicode_ci鏡像后面跟的--character-set-serverutf8mb4不是 docker 命令參數(shù)而是傳給 MySQL server 的啟動(dòng)參數(shù)這是 run 的一種經(jīng)典透?jìng)魈匦浴Ｈ绻环奖銓?xiě)在命令行還可以放在掛載的/etc/mysql/conf.d下寫(xiě)一個(gè)character-set.cnf效果一樣。第三步驗(yàn)證。先看啟動(dòng)日志里是否出現(xiàn) ready for connectionsdocker logs mysql8 21 | grep -E ready for connections然后進(jìn)入容器用 MySQL 客戶端測(cè)試docker exec -it mysql8 mysql -uroot -p如果外部工具連不上優(yōu)先檢查宿主機(jī)防火墻、-p 3306:3306是否生效以及 MySQL 里 root 的 host 是否被限制為 localhost。很多人第一次部署 MySQL 都在最后一步翻車(chē)因?yàn)?root 用戶默認(rèn)只能從容器內(nèi)登錄。這時(shí)候在容器里執(zhí)行一條授權(quán)即可CREATE USER dev% IDENTIFIED BY Dev123456; GRANT ALL PRIVILEGES ON *.* TO dev%; FLUSH PRIVILEGES;2.4 用 Redis 主從理解自定義網(wǎng)絡(luò)與內(nèi)部通信Redis 主從部署看起來(lái)只是多跑一個(gè)容器但其中藏著一個(gè) Docker 網(wǎng)絡(luò)的重要考點(diǎn)容器之間不要依賴宿主機(jī) IP而應(yīng)該用容器名通信。先創(chuàng)建一個(gè)自定義網(wǎng)絡(luò)docker network create redis-net再啟動(dòng)主節(jié)點(diǎn)docker run -d --name redis-master \ --network redis-net \ -p 6379:6379 \ redis:7-alpine \ redis-server --appendonly yes從節(jié)點(diǎn)啟動(dòng)時(shí)指向的不是宿主機(jī)127.0.0.1:6379而是容器名redis-masterdocker run -d --name redis-slave \ --network redis-net \ -p 6380:6379 \ redis:7-alpine \ redis-server --replicaof redis-master 6379驗(yàn)證主從狀態(tài)docker exec -it redis-slave redis-cli info replication輸出里master_link_status:up表示主從正常。這里的關(guān)鍵是自定義網(wǎng)絡(luò)上啟用了 Docker 內(nèi)置 DNS容器名可以被同網(wǎng)絡(luò)下的其他容器解析成對(duì)應(yīng) IP。如果用默認(rèn) bridge 網(wǎng)絡(luò)舊版本容器之間只能靠 IP 訪問(wèn)一旦容器重建 IP 就變了非常痛苦。所以從 Redis 主從這個(gè)需求開(kāi)始我就建議養(yǎng)成“先建網(wǎng)絡(luò)再跑容器”的習(xí)慣。3. 用 Compose 把多容器編排成一條命令當(dāng)容器數(shù)量超過(guò)三四個(gè)逐條 run 已經(jīng)不適合維護(hù)了。Compose 的價(jià)值不是省那幾行命令而是把容器、網(wǎng)絡(luò)、卷、依賴關(guān)系寫(xiě)進(jìn)一個(gè)聲明式文件讓整套環(huán)境可移植、可追蹤、可審計(jì)。Docker 官方現(xiàn)在的推薦是docker composev2 插件而不是老舊的docker-compose。3.1 Compose 的核心配置字段與啟動(dòng)命令一個(gè)最小可用的 compose 文件長(zhǎng)這樣services: web: image: nginx:1.25-alpine ports: - 8080:80 restart: unless-stopped不用寫(xiě)頂層的version字段新版本 Compose 已經(jīng)忽略它寫(xiě)了反而可能帶來(lái)舊版兼容提示。核心是services映射里面每個(gè) key 都是一個(gè)服務(wù)名也就是網(wǎng)絡(luò)上的主機(jī)名。常用字段我需要單獨(dú)說(shuō)幾個(gè)image直接指定鏡像。如果下面還有build則優(yōu)先構(gòu)建。build指定 Dockerfile 目錄例如build: ./backend配合docker compose up --build使用。ports端口映射寫(xiě)成宿主機(jī)端口:容器端口。注意就算值看起來(lái)是數(shù)字也建議加引號(hào)避免 YAML 解析成其他類(lèi)型。environment環(huán)境變量可以寫(xiě)成列表或字典推薦字典格式更清晰。volumes數(shù)據(jù)卷或目錄掛載。depends_on依賴啟動(dòng)順序。但這只是“等容器啟動(dòng)”不保證“等容器可用”。比如數(shù)據(jù)庫(kù)容器雖然起來(lái)了但初始化還沒(méi)完成后端連接就失敗。要解決這個(gè)問(wèn)題需要配合healthcheck。healthcheck健康檢查定義常用test、interval、timeout、retries。啟動(dòng)命令整套如下docker compose up -d docker compose ps docker compose logs -f backend docker compose exec backend sh docker compose down其中down本身不刪數(shù)據(jù)卷默認(rèn)只停容器和網(wǎng)絡(luò)。如果要清掉所有關(guān)聯(lián)卷用down -v。這個(gè)-v相當(dāng)危險(xiǎn)會(huì)把數(shù)據(jù)庫(kù)數(shù)據(jù)一起刪掉操作前一定確認(rèn)有沒(méi)有持久化。3.2 一個(gè)后端 MySQL Redis 的微服務(wù)項(xiàng)目落地方案空講字段不夠直觀我用一個(gè)常見(jiàn)的微服務(wù)啟動(dòng)場(chǎng)景完整展示。假設(shè)項(xiàng)目有 backend 服務(wù)依賴 MySQL 和 Redis后端 Dockerfile 在./backend目錄。compose 文件services: mysql: image: mysql:8.0 container_name: demo-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: Root123456 MYSQL_DATABASE: demo TZ: Asia/Shanghai volumes: - mysql-data:/var/lib/mysql ports: - 3306:3306 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -pRoot123456] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine restart: unless-stopped command: redis-server --appendonly yes volumes: - redis-data:/data ports: - 6379:6379 healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 3s retries: 5 backend: build: ./backend restart: unless-stopped ports: - 8080:8080 environment: DB_HOST: mysql DB_USER: root DB_PASSWORD: Root123456 REDIS_HOST: redis TZ: Asia/Shanghai depends_on: mysql: condition: service_healthy redis: condition: service_healthy執(zhí)行docker compose up -d注意觀察依賴。MySQL 容器只有通過(guò)mysqladmin ping檢查才算健康backend才會(huì)真正創(chuàng)建。這套機(jī)制比單純depends_on可靠得多是我在 dev 和測(cè)試環(huán)境反復(fù)驗(yàn)證后的標(biāo)準(zhǔn)做法。進(jìn)入后端排查時(shí)容器名或者服務(wù)名backend在網(wǎng)絡(luò)里可以直接訪問(wèn)mysql:3306和redis:6379一點(diǎn)都不需要關(guān)心宿主機(jī) IP。這也是 Compose 帶來(lái)的最大便利。3.3 Compose 與生產(chǎn)環(huán)境相關(guān)的幾個(gè)坑第一容器內(nèi)時(shí)區(qū)。很多鏡像基礎(chǔ)層是 UTC如果不在environment里加TZAsia/Shanghai日志和數(shù)據(jù)庫(kù)時(shí)間都會(huì)偏 8 小時(shí)。別指望所有鏡像默認(rèn)設(shè)置好時(shí)區(qū)加一個(gè)環(huán)境變量是最穩(wěn)的。第二掛載目錄的權(quán)限。bind mount宿主機(jī)目錄到容器里很容易出現(xiàn)Permission denied本質(zhì)是 UID/GID 不匹配。簡(jiǎn)單粗暴的方案是把宿主機(jī)目錄權(quán)限改成 777但生產(chǎn)環(huán)境不推薦。更好的方式是在鏡像或 compose 里指定運(yùn)行用戶組或者在 Dockerfile 里useradd一個(gè)和宿主機(jī) UID 相同的用戶。第三端口沖突。compose 里如果把多個(gè)項(xiàng)目都映射到3306:3306第二個(gè)項(xiàng)目啟動(dòng)就會(huì)失敗。一個(gè)很有用的思路是應(yīng)用之間的內(nèi)部訪問(wèn)盡量走容器網(wǎng)絡(luò)不要每次都映射到宿主機(jī)端口。只有真正需要外部訪問(wèn)的服務(wù)才暴露端口。4. 網(wǎng)絡(luò)與數(shù)據(jù)卷持久化與互聯(lián)的底層原理很多人 docker 命令敲得溜但一遇到網(wǎng)絡(luò)不通、數(shù)據(jù)丟失就懵。這一節(jié)把兩個(gè)最容易被表面命令掩蓋的底層機(jī)制講清楚。4.1 四種網(wǎng)絡(luò)模式與自定義網(wǎng)絡(luò)的工作方式Docker 網(wǎng)絡(luò)先看大框架默認(rèn)存在四種模式。bridge是默認(rèn)模式通過(guò)虛擬網(wǎng)橋?yàn)槿萜鞣峙鋬?nèi)網(wǎng) IP容器和外界通信經(jīng)過(guò) NAT 轉(zhuǎn)換。host模式直接共享宿主機(jī)網(wǎng)絡(luò)棧沒(méi)有端口映射概念性能好但隔離差網(wǎng)絡(luò)配置容易沖突。none模式關(guān)閉網(wǎng)絡(luò)用于極端隔離場(chǎng)景。overlay模式主要用于 Swarm 集群跨節(jié)點(diǎn)通信日常單機(jī)用得少。命令層面掌握三條docker network ls docker network create app-net docker network inspect app-netinspect能看到具體有哪些容器掛在網(wǎng)絡(luò)下、每個(gè)容器的 IP、網(wǎng)關(guān)、子網(wǎng)掩碼。排查網(wǎng)絡(luò)不通時(shí)第一步不是 ping而是“你倆到底在不在一張網(wǎng)里”。不同網(wǎng)絡(luò)下的容器不能直接互通除非通過(guò)宿主機(jī)端口映射。為什么自定義網(wǎng)絡(luò)比默認(rèn) bridge 好用核心是內(nèi)置 DNS。在默認(rèn) bridge 中Docker 舊版本不提供 DNS 解析容器間訪問(wèn)只能靠--link或固定 IP自定義 bridge 則會(huì)為每個(gè)容器記錄主機(jī)名容器名就是域名。只要兩個(gè)容器在同一個(gè)app-net里我用docker exec app1 ping app2直接就通了。這一點(diǎn)在 2.4 的 Redis 主從里已經(jīng)體現(xiàn)過(guò)。生產(chǎn)環(huán)境排網(wǎng)絡(luò)問(wèn)題我的固定順序是檢查docker network inspect確認(rèn)容器在同一網(wǎng)絡(luò)。進(jìn)入容器 ping 網(wǎng)關(guān)和對(duì)方容器名。如果內(nèi)部通、外網(wǎng)不通查宿主機(jī)防火墻和端口映射。如果端口映射不通查ss -tlnp看宿主機(jī)端口有沒(méi)有被占用或防火墻放行。4.2 數(shù)據(jù)卷、綁定掛載與容器權(quán)限容器刪除后文件系統(tǒng)并不會(huì)消失但只有寫(xiě)在掛載卷或數(shù)據(jù)卷里的內(nèi)容才能持久保留。理解三種掛載方式的區(qū)別很重要bind mount把宿主機(jī)目錄掛到容器目錄例如-v /data/mysql:/var/lib/mysql。好處是文件直接可見(jiàn)、方便備份壞處是宿主機(jī)目錄權(quán)限直接決定容器內(nèi)訪問(wèn)權(quán)限目錄不存在時(shí)需要先創(chuàng)建。named volume由 Docker 管理例如-v mysql-data:/var/lib/mysql。數(shù)據(jù)存放在/var/lib/docker/volumes/mysql-data/_data作用上像一個(gè)數(shù)據(jù)抽屜容器刪了數(shù)據(jù)還在。tmpfs寫(xiě)入宿主機(jī)內(nèi)存不落盤(pán)適合放臨時(shí)文件。常用命令docker volume create app-data docker volume ls docker volume inspect app-data docker volume rm app-data備份數(shù)據(jù)卷最直接的方式是先用一個(gè)臨時(shí)容器把卷打包出來(lái)docker run --rm \ -v app-data:/data:ro \ -v /backup:/backup \ alpine tar czf /backup/app-data.tar.gz -C /data .這里--rm表示臨時(shí)容器用完自動(dòng)刪除:ro表示以只讀方式掛載原卷避免備份過(guò)程中寫(xiě)壞數(shù)據(jù)。4.3 GitLab 社區(qū)版部署80/22 端口沖突與數(shù)據(jù)卷規(guī)劃把 GitLab 社區(qū)版用 Docker 跑起來(lái)是很多團(tuán)隊(duì)維護(hù)內(nèi)部代碼倉(cāng)庫(kù)的常見(jiàn)需求。它有明確的“官方 docker run 最佳實(shí)踐”直接抄即可但里面有兩個(gè)坑必須提前說(shuō)清楚。先看部署命令docker run -d \ --name gitlab \ --restart always \ -p 8080:80 \ -p 8443:443 \ -p 2222:22 \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:16.4.0-ce.0第一個(gè)坑是宿主機(jī) SSH 端口。GitLab 鏡像內(nèi)部的 SSH 默認(rèn)監(jiān)聽(tīng) 22但宿主機(jī) 22 通常已經(jīng)被 system sshd 占用所以映射成2222:22。這意味著 git clone 地址要改成ssh://gityourhost:2222/group/repo.git而且需要在 GitLab 配置里同步修改docker exec -it gitlab editor /etc/gitlab/gitlab.rb配置項(xiàng)是gitlab_rails[gitlab_shell_ssh_port] 2222。改完執(zhí)行docker exec -it gitlab gitlab-ctl reconfigure第二個(gè)坑是初始密碼。新部署的 GitLab 會(huì)生成一個(gè)隨機(jī)初始 root 密碼保存在容器的/etc/gitlab/initial_root_password文件中且 24 小時(shí)后自動(dòng)刪除。如果你沒(méi)設(shè)置環(huán)境變量務(wù)必第一時(shí)間查看docker exec -it gitlab grep Password: /etc/gitlab/initial_root_password生產(chǎn)環(huán)境我還會(huì)把external_url改成正式域名例如http://gitlab.example.com否則生成的 clone 地址永遠(yuǎn)是容器主機(jī)名。5. 命令行排錯(cuò)實(shí)錄那些年我踩過(guò)的坑這條線上踩坑多了自然就能形成一套快速排查的直覺(jué)。我把最高頻的幾類(lèi)問(wèn)題拿出來(lái)把原因和解決路徑一次講清。5.1 Permission denied 與 npipe 連接失敗Linux 下的權(quán)限問(wèn)題前面已經(jīng)提到加入 docker 組。但如果已經(jīng)加入 docker 組依舊報(bào)錯(cuò)另一個(gè)常見(jiàn)原因是 docker 守護(hù)進(jìn)程沒(méi)起來(lái)或者 socket 文件權(quán)限被改動(dòng)。先檢查ls -l /var/run/docker.sock如果這個(gè)文件不存在說(shuō)明守護(hù)進(jìn)程根本沒(méi)有正常啟動(dòng)服務(wù)拉起來(lái)再說(shuō)。Windows 下 Docker Desktop 報(bào)npipe:////./pipe/dockerDesktopLinuxEngine連接失敗我遇到最多的情況是引擎還沒(méi)啟動(dòng)完成。命令行等個(gè)十幾秒再敲命令往往就通了因?yàn)?Desktop 的圖形面板啟動(dòng)很慢但 CLI 不會(huì)告訴你“再等等”。如果一直失敗就回到 1.2 檢查虛擬化、WSL2 和系統(tǒng)組件。不要在還沒(méi)有確認(rèn) Engine 狀態(tài)時(shí)反復(fù)重啟終端這會(huì)誤導(dǎo)判斷。5.2 bind: address already in use 端口排查啟動(dòng)容器時(shí)最常見(jiàn)的報(bào)錯(cuò)之一docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:3306 failed: port is already allocated原因明確了端口被占用。排查順序ss -tlnp | grep 3306 netstat -tlnp | grep 3306 lsof -i:3306如果是另一個(gè)容器占用了同端口docker ps就能看到。如果是宿主機(jī)進(jìn)程占用就要決定是殺掉舊進(jìn)程還是給新容器換端口。我一般傾向換端口而不是強(qiáng)殺未知進(jìn)程尤其生產(chǎn)服務(wù)器上你并不知道那個(gè)進(jìn)程在干什么。5.3 鏡像拉不動(dòng)、超時(shí)怎么辦docker pull超時(shí)或者極慢是最常見(jiàn)的問(wèn)題之一。原因大多是默認(rèn) Docker Hub 的 registry 鏡像源在我們這邊訪問(wèn)不穩(wěn)定。解決方案是配置加速源也就是registry-mirrors。Linux 下改/etc/docker/daemon.json{ registry-mirrors: [https://docker.mirrors.example.com] }改完執(zhí)行sudo systemctl daemon-reload sudo systemctl restart dockerDocker Desktop 用戶則可以在設(shè)置界面的 Docker Engine 配置里加入同樣的 JSON 字段然后重啟 Desktop。配置好之后再用docker pull會(huì)明顯順暢。需要注意不要每個(gè)鏡像都寫(xiě)死某個(gè)私有加速源團(tuán)隊(duì)環(huán)境里最好統(tǒng)一維護(hù)一份標(biāo)準(zhǔn)配置否則換一個(gè)人排錯(cuò)頭大如斗。5.4 容器秒退/反復(fù)重啟的檢查順序docker ps -a里經(jīng)?？吹紼xited (1)或Restarting這種狀態(tài)通常不是 Docker 的問(wèn)題而是容器內(nèi)應(yīng)用的問(wèn)題。檢查順序我固定為第一步看日志docker logs --tail 200 --details 容器名日志里如果顯示配置文件不存在、環(huán)境變量為空、端口連不上先去補(bǔ)這些外部依賴。第二步看入口命令。如果鏡像默認(rèn)入口是nginx -g daemon off;但你覆蓋成了/bin/bash沒(méi)有附加-it的情況下 bash 拿到無(wú)終端輸入會(huì)立刻退出。此時(shí)改成docker run -it就能看到退出前的真實(shí)輸出。第三步檢查健康檢查是否過(guò)嚴(yán)。Compose 里 healthcheck 連續(xù)失敗會(huì)觸發(fā)重啟但不說(shuō)明應(yīng)用真掛了有時(shí)只是mysqladmin ping的密碼不對(duì)導(dǎo)致一直被認(rèn)為不健康。6. 提升效率的命令習(xí)慣與日常維護(hù)命令本身學(xué)會(huì)不難難在把它變成肌肉記憶和高效習(xí)慣。最后這部分是我個(gè)人日常維護(hù)里最常用的小技巧不寫(xiě)長(zhǎng)篇大論都是可以直接抄作業(yè)的。6.1 格式化輸出與批量操作docker ps默認(rèn)打印所有列列一多就眼花。我更推薦的寫(xiě)法是自定義格式docker ps --format table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}甚至可以把它設(shè)置成 shell 別名比如alias dpsdocker ps --format table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}查看資源占用用docker stats但默認(rèn)是持續(xù)刷新的跑完就退出可以加docker stats --no-stream批量操作容器時(shí)docker ps -q是核心docker stop $(docker ps -q) docker rm $(docker ps -aq)xargs也很常用比如批量刪除所有 exited 容器docker ps -aq --filter statusexited | xargs docker rm6.2 空間清理prune 的正確打開(kāi)方式磁盤(pán)被鏡像和容器日志占滿是我接手服務(wù)器后最常見(jiàn)的故障。docker system df可以先看整體占用docker system df輸出會(huì)按鏡像、容器、卷、構(gòu)建緩存分別顯示占用。然后謹(jǐn)慎使用清理命令docker container prune docker image prune docker volume prune docker system prune -asystem prune -a會(huì)清掉所有未使用的鏡像、停止的容器和網(wǎng)絡(luò)但默認(rèn)不會(huì)刪數(shù)據(jù)卷。加上--volumes才刪卷。反向警示這條命令一旦執(zhí)行很多本地的歷史鏡像和舊卷將無(wú)法恢復(fù)。我的習(xí)慣是準(zhǔn)備清理前先docker image ls確認(rèn)沒(méi)有需要保留的版本確認(rèn)后再加-a -f并且永遠(yuǎn)不要把生產(chǎn)庫(kù)所在的數(shù)據(jù)卷交給 prune 自動(dòng)處理。6.3 我的日常命令組合拳最后分享一個(gè)我自己的習(xí)慣。每次接手新項(xiàng)目我第一步永遠(yuǎn)是docker ps -a加docker inspect看狀態(tài)而不是直接啟動(dòng)服務(wù)。第二步看日志第三步看環(huán)境變量和掛載。這個(gè)順序永遠(yuǎn)不會(huì)錯(cuò)。另一個(gè)習(xí)慣是把常用命令寫(xiě)成腳本。比如我本地有個(gè)dc.sh內(nèi)容類(lèi)似docker compose ps docker compose logs -f --tail 100 docker compose down --remove-orphans docker compose up -d --build這樣即使換了新機(jī)器只要腳本文件在環(huán)境很快就能搭起來(lái)。命令行不是背出來(lái)的是每天在真實(shí)場(chǎng)景里敲出來(lái)的。多部署幾個(gè) MySQL、Redis、GitLab多把 compose 編排理解透再遇到報(bào)錯(cuò)你不需要搜遍全網(wǎng)光看字段和日志就能猜到問(wèn)題在哪。