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