上個月接手一個 PHP 老項目需要在 macOS 上把本地環(huán)境跑起來。我一開始的打算是裝個集成環(huán)境包但機器是 M 系列芯片試了幾個版本都不太對擴展還得專門去編譯折騰得人很煩躁。后來索性把 Nginx 和 PHP 全部塞進 Docker 容器用 Docker Compose 一套編排反而半個多小時就把開發(fā)環(huán)境立起來了。這篇文章就把這套完整流程記下來包括 macOS 上安裝 Docker 的注意點、Nginx 與 PHP-FPM 協(xié)作的原理、Compose 配置的寫法和幾個高頻報錯的排錯思路。適合想在 mac 上跑 PHP 項目的開發(fā)者不管是新手還是被多版本環(huán)境切換整怕了的老手按著這套走基本不會再在環(huán)境搭建上卡殼。1. 方案選型為什么我選了 Docker 而不是裝集成環(huán)境1.1 集成環(huán)境包的常見尷尬在 macOS 上做 PHP 開發(fā)身邊同事用得最多的方案是裝圖形化集成環(huán)境比如 MAMP、XAMPP或者用包管理器直接裝 Nginx、PHP 到系統(tǒng)里。這些方案對簡單項目確實快但一旦項目多起來就難受了。項目 A 用的是 PHP 7.4項目 B 要用 PHP 8.2項目 C 還需要擴展 gd、redis、swoole。集成環(huán)境通常只會給你一個固定的 PHP 版本想裝第二個版本就得切換配置弄不好全局依賴就亂了。更別提 M 系列芯片剛普及那會兒很多集成環(huán)境的二進制包還沒適配下載下來要么打不開要么運行卡到懷疑人生。包管理器裝的 Nginx 和 PHP 屬于系統(tǒng)級服務升級系統(tǒng)或者清理依賴的時候可能波及正在跑的項目這是我最害怕的點。1.2 Docker 方案到底解決了什么Docker 的思路是把每個項目的運行環(huán)境打包成獨立的容器。Nginx 是一個容器PHP-FPM 是一個容器MySQL 又是獨立的一個。它們就像三臺各自運行的小型虛擬機互相不干擾但又通過網(wǎng)絡聯(lián)在一起工作。換項目時互不沖突是 Docker 方案最大的紅利。項目 A 的 PHP 7.4 容器繼續(xù)跑著項目 B 的 PHP 8.3 容器也可以同時跑著互不侵犯系統(tǒng)環(huán)境。想刪掉一個項目的時候容器刪掉即可不會殘留一堆系統(tǒng)級的庫和配置。遷移到新電腦也簡單代碼和配置文件一起拷過去一條命令把容器拉起來環(huán)境就恢復了。這一點是集成環(huán)境給不了的。適用邊界我也說清楚如果你只是臨時跑一個 5 分鐘就完事的 PHP 文件或者電腦配置很低那裝個輕量級單文件環(huán)境可能更合適。Docker 需要一點學習成本但只要是正經(jīng)做 PHP 項目這個成本非常值得投入。1.3 方案確定的幾個關(guān)鍵點確定用 Docker 之后具體選型我還做了幾個明確決定使用 Docker Desktop 作為容器運行載體。macOS 本身跑不了 Linux 容器Docker Desktop 會在后臺自動維護一個輕量 Linux 虛擬機對使用者透明體驗最接近原生。使用 Docker Compose 管理容器編排。Nginx 和 PHP 兩個容器之間有固定關(guān)系寫成一個 compose 文件既能控制啟動順序又能讓它們自動加入同一個網(wǎng)絡比敲一長串 docker run 命令可靠得多。端口映射采用 8080 映射到容器內(nèi) 80。macOS 上 80 端口經(jīng)常被其他服務占掉本地開發(fā)用 8080 更省心必要時再改成別的端口。這些選擇不是隨手拍的后面配置過程中體現(xiàn)出來的便利性每一項都踩到了實處。2. macOS 上安裝 Docker 的實操細節(jié)2.1 先確認芯片架構(gòu)再下載安裝包macOS 安裝 Docker 第一步就藏著坑芯片架構(gòu)不同安裝包也不同。M 系列芯片和 Intel 芯片對應的安裝包必須分開選選錯的話最常見的結(jié)果是安裝后雙擊提示無法打開或者 Docker Desktop 一直報架構(gòu)錯誤。區(qū)分方法很簡單打開終端執(zhí)行uname -m輸出arm64的就是 M 系列芯片比如 M1、M2、M3輸出x86_64的就是 Intel 陣營。還可以再用sysctl -n machdep.cpu.brand_string這條命令直接把 CPU 型號打印出來一目了然。拿到架構(gòu)信息后去 Docker 官網(wǎng)的下載頁找對應的 Docker Desktop for Mac 安裝包?，F(xiàn)在官網(wǎng)頁面上通常會標清楚 Apple Silicon 版本和 Intel Chip 版本按終端里的結(jié)果選就行。下載下來的是一個 .dmg 文件雙擊打開后把 Docker 圖標拖進 Applications 文件夾就完成了最基礎(chǔ)的安裝。2.2 首次啟動時需要完成的設置拖進 Applications 后在啟動臺打開 Docker Desktop。第一次啟動會要求你接受使用條款部分場景下還會要求登錄 Docker Hub 賬號這是官方現(xiàn)在的常規(guī)流程按提示走就行。啟動后右上角菜單欄會出現(xiàn)一個小鯨魚圖標等它從動畫變成靜止狀態(tài)意味著 Docker 引擎已經(jīng)準備就緒。這個等待時間第一次可能比較久因為后臺虛擬機要初始化。打開終端驗證docker --version docker compose version能正常打印出版本號說明整體裝好了。我習慣順手跑一條docker info這條命令輸出內(nèi)容多不用全看重點是確認Operating System和Architecture兩個字段能直觀看出當前 Docker 引擎掛載在什么環(huán)境上方便早期發(fā)現(xiàn)問題。2.3 鏡像拉取慢的通用解法首次使用 Docker最直覺的操作是拉一個測試鏡像跑跑看但很多人卡在這里拉取鏡像速度十分感人一個幾十 MB 的鏡像可能要等半天。這個不是 Docker 本身的問題而是你的網(wǎng)絡到鏡像倉庫之間的鏈路質(zhì)量不穩(wěn)定。通用的解法是配置 registry-mirrors也就是鏡像源。在 Docker Desktop 的 Settings 里找到 Docker Engine 配置項在 JSON 配置里加一段{ registry-mirrors: [https://registry-mirror.example.com] }注意引號里的地址一定要換成你自己網(wǎng)絡環(huán)境實際可用的鏡像源地址。很多云廠商會提供公共服務公司內(nèi)網(wǎng)有時也會搭建私有鏡像源我建議優(yōu)先咨詢你所在公司的運維或者直接查云廠商文檔選一個延遲低的。配置完點擊應用并重啟 Docker再用docker pull試一次速度正常就說明生效了。我見過有些朋友在這個環(huán)節(jié)花了很多心思找各種鏡像源其實大可不必。如果基礎(chǔ)鏡像拉取只是慢可以耐心等一次后續(xù)本地有了緩存再次創(chuàng)建容器基本不會再走下載流程。2.4 用 hello-world 驗證鏈路是否完整安裝配置完之后建議先跑一個最基礎(chǔ)的測試容器確認整條鏈路是通的。執(zhí)行docker run --rm hello-world首次執(zhí)行會先拉取 hello-world 鏡像然后短暫運行一個容器并打印一段信息最后自動清理刪除?？吹浇K端里輸出那句 Hello from Docker 的經(jīng)典文案就表明安裝、拉取、創(chuàng)建容器、運行容器這條鏈路全部正常。這一步通過后就可以放心進入 Nginx 和 PHP 的部署環(huán)節(jié)了。如果這一步都報錯后面部署 Nginx 肯定也成不了先回頭檢查安裝和鏡像源配置。3. 先手工跑一套 nginxphp 容器鏈路3.1 理解 Nginx 和 PHP-FPM 是怎么配合的講解部署之前得先把 Nginx 和 PHP-FPM 的關(guān)系講清楚否則你后面看配置容易一頭霧水。Nginx 本身只會處理靜態(tài)資源和 HTTP 協(xié)議上的轉(zhuǎn)發(fā)邏輯。當瀏覽器請求一個 .php 文件時Nginx 看不懂 PHP 代碼它只能把這些請求按規(guī)則轉(zhuǎn)交給 PHP-FPM——一個獨立的 PHP 進程管理器。PHP-FPM 接收請求后定位到實際的 PHP 文件執(zhí)行 PHP 代碼把動態(tài)結(jié)果回傳給 Nginx再由 Nginx 返回給瀏覽器。這個轉(zhuǎn)交動作走的是 FastCGI 協(xié)議。配置里常見的fastcgi_pass php:9000;就是在告訴 Nginx把 PHP 請求轉(zhuǎn)發(fā)到名為 php 的那臺主機、9000 端口上。你可以把 Nginx 理解成前臺接待把 PHP-FPM 理解成后臺技術(shù)處理接待把活兒派給技術(shù)技術(shù)把結(jié)果交回前臺。正因為是這種協(xié)作關(guān)系兩個容器必須能夠互通。Docker 里容器之間互訪需要把它們放到同一個自定義網(wǎng)絡中。3.2 準備代碼目錄和測試文件我先手工跑一遍完整鏈路目的是讓你直觀看到 Nginx 和 PHP 兩個容器之間是怎么關(guān)聯(lián)的再來寫 Compose 時理解會深很多。先創(chuàng)建一個項目目錄這里以php-nginx-demo為例mkdir -p ~/www/php-nginx-demo/www mkdir -p ~/www/php-nginx-demo/nginx/conf.d cd ~/www/php-nginx-demo在www目錄下寫一個測試文件index.php?php phpinfo();phpinfo()會輸出當前 PHP 環(huán)境的完整信息用它驗證 PHP-FPM 是否被正確執(zhí)行是最直觀的。然后創(chuàng)建一個 Docker 自定義網(wǎng)絡讓兩個容器能通過域名互相訪問docker network create app-net3.3 啟動 PHP-FPM 容器執(zhí)行docker run -d --name demo-php \ --network app-net \ -v ~/www/php-nginx-demo/www:/var/www/html \ php:8.3-fpm-alpine拆開來看每個參數(shù)的意思-d后臺運行容器。--name demo-php給容器起名字后續(xù)別的容器可以通過這個名字訪問它。--network app-net加入剛才創(chuàng)建的網(wǎng)絡。-v ~/www/php-nginx-demo/www:/var/www/html把宿主機代碼目錄掛載到容器內(nèi)/var/www/html目錄。這樣代碼文件在宿主機修改容器內(nèi)立即同步。這里我沒加-p端口映射因為 PHP-FPM 的 9000 端口只需要被 Nginx 容器訪問不需要暴露到宿主機。這也是容器隔離的一個特點內(nèi)部服務按需開放。啟動后用一條命令確認狀態(tài)docker psdemo-php出現(xiàn)在列表里并且狀態(tài)是 Up說明 PHP-FPM 已經(jīng)跑起來了。3.4 編寫 Nginx 站點配置并啟動 Nginx寫一份 Nginx 站點配置nginx/conf.d/default.confserver { listen 80; server_name localhost; root /var/www/html; index index.php index.html; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass demo-php:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }這里有幾個關(guān)鍵點值得展開說。root /var/www/html;這條不是隨手寫的。前面啟動 PHP-FPM 容器的時候我把代碼目錄掛載到了容器內(nèi)的/var/www/html。Nginx 這邊也把同一目錄掛載到/var/www/html并且root也指向這里這樣 Nginx 轉(zhuǎn)交給 PHP-FPM 的SCRIPT_FILENAME路徑才和 PHP-FPM 實際看到的文件路徑完全一致。如果兩邊掛載路徑不統(tǒng)一PHP-FPM 就會拿著 Nginx 給的路徑找不到文件最終返回 404 或者報 File not found。這是整套配置里我踩過的最深的坑后面問題排查部分還會專門講。location ~ \.php$是正則匹配凡是請求路徑以.php結(jié)尾的都由這個塊處理。塊內(nèi)的fastcgi_pass demo-php:9000;是轉(zhuǎn)交目標demo-php是 PHP-FPM 容器的名字在這個網(wǎng)絡里可以直接當作主機名用。SCRIPT_FILENAME是 PHP-FPM 用來定位具體文件的關(guān)鍵參數(shù)$document_root表示 root 指令指定的根目錄$fastcgi_script_name表示請求的腳本路徑。啟動 Nginx 容器docker run -d --name demo-nginx \ --network app-net \ -p 8080:80 \ -v ~/www/php-nginx-demo/www:/var/www/html \ -v ~/www/php-nginx-demo/nginx/conf.d:/etc/nginx/conf.d:ro \ nginx:stable-alpine參數(shù)里新增的部分-p 8080:80把宿主機的 8080 端口映射到 Nginx 容器的 80 端口。反過來理解就是瀏覽器訪問http://localhost:8080時請求會進入 Nginx 容器的 80 端口。:ro掛載配置文件目錄時指定只讀防止容器內(nèi)部意外修改宿主機配置文件。然后在瀏覽器訪問http://localhost:8080如果能看到phpinfo()的黃色表格頁面就說明 Nginx 和 PHP-FPM 的整條鏈路已經(jīng)打通了。3.5 手工方案的優(yōu)勢和局限手工 docker run 的優(yōu)勢是把每個參數(shù)的含義展示得非常清楚適合第一次接觸的人理解原理。但它的局限也明顯兩條命令要手動指定網(wǎng)絡、掛載、端口一長串記不住容器之間依賴關(guān)系靠人腦記憶換臺電腦就得全部重敲一遍。所以在確認鏈路能跑通之后正確的下一步是把這套手動配置固化成 Docker Compose 文件。4. 用 Docker Compose 把環(huán)境固化下來4.1 Compose 到底在干什么Docker Compose 可以理解成一種基礎(chǔ)設施即代碼的寫法。你把需要運行的容器、它們之間的關(guān)系、掛載目錄、端口映射全部寫進一個 YAML 文件里然后執(zhí)行一條docker compose up -d所有容器按聲明的方式創(chuàng)建和啟動。這樣做的好處是項目環(huán)境定義化。團隊協(xié)作時把 compose 文件和項目代碼放進同一倉庫新人克隆代碼后執(zhí)行一條命令就能獲得和開發(fā)環(huán)境完全一致的容器編排。不再需要整理冗長的 shell 命令給人看文件本身就是文檔。4.2 編寫 docker-compose.yml在項目根目錄下創(chuàng)建docker-compose.yml文件內(nèi)容如下services: nginx: image: nginx:stable-alpine container_name: demo-nginx ports: - 8080:80 volumes: - ./www:/var/www/html - ./nginx/conf.d:/etc/nginx/conf.d:ro depends_on: - php networks: - app-net php: image: php:8.3-fpm-alpine container_name: demo-php volumes: - ./www:/var/www/html networks: - app-net networks: app-net: driver: bridge和手工方案對比內(nèi)容幾乎一一對應但有幾個新知識./www是相對路徑指向宿主機當前目錄下的 www 文件夾。使用相對路徑后整個項目目錄可以整體移動只要目錄內(nèi)部結(jié)構(gòu)不變就能繼續(xù)工作。container_name指定容器名不寫的話 Compose 會生成一個帶項目前綴的隨機名字但顯式指定便于用 docker exec 調(diào)試。depends_on聲明啟動順序讓 Nginx 等 PHP 先啟動避免啟動瞬間 Nginx 找不到解析目標而報錯。用php作為服務名網(wǎng)絡內(nèi)主機名就是php所以 Nginx 配置里fastcgi_pass php:9000;代替了手工方案中的demo-php:9000。新版 Docker Compose 已經(jīng)不需要寫version字段直接寫services即可寫到舊版本也不會報錯只是會有棄用提示。另外driver: bridge是默認網(wǎng)絡類型寫出來是為了明確語義不寫效果也一樣。4.3 啟動、停止和查看容器狀態(tài)啟動命令docker compose up -d-d表示后臺運行。首次執(zhí)行會拉取兩個鏡像可能需要一點時間。完成后查看狀態(tài)docker compose ps應該能看到 nginx 和 php 兩個服務都是 Up 狀態(tài)。此時訪問http://localhost:8080同樣能看到 phpinfo 頁面。日常開發(fā)中常用的相關(guān)命令我也一并列出來# 查看容器日志 docker compose logs -f # 進入 PHP 容器操作比如執(zhí)行 php -v docker compose exec php sh # 重新構(gòu)建鏡像修改了 Dockerfile 后執(zhí)行 docker compose up -d --build # 停止并刪除容器不會刪除代碼目錄和命名卷 docker compose down停掉再啟動是開發(fā)時最頻繁的操作之一。改完 nginx 配置文件要讓它生效可以執(zhí)行docker compose exec nginx nginx -s reload用 Nginx 自帶的平滑重載指令不用整個容器重啟。4.4 掛載路徑一致性的一個細節(jié)Compose 把代碼目錄掛載到了 Nginx 容器的/var/www/html也掛載到了 PHP 容器的/var/www/htmlNginx 配置里的root也指向/var/www/html。三個路徑必須保持一致是部署成功的關(guān)鍵。為什么是三個而不只是兩個因為 Nginx 配置里SCRIPT_FILENAME的$document_root取自root指令。如果 Nginx root 指向/usr/share/nginx/html而它的/var/www/html也掛著同一份代碼那么 PHP-FPM 容器里找/usr/share/nginx/html/index.php就會撲空。很多人在手工 docker run 時隨手加了一句-v ~/www:/usr/share/nginx/html導致 Nginx 容器里文件是存在的可配置的 root 路徑和它不一致問題就出現(xiàn)了。所以我的建議很直接所有容器掛載同一目錄時盡可能用相同的容器內(nèi)路徑Nginx 的 root 也寫這個路徑不要自作聰明地分開放。5. 開發(fā)中最高頻的 5 類問題與排查實錄5.1 80 端口和 8080 端口被占用本地開發(fā)最容易遇到的就是端口占用。macOS 上 80 端口經(jīng)常被系統(tǒng)自帶的 Apache 或其他服務占用8080 也可能被某個前端開發(fā)服務器占著。碰到這種情況先別急著猜用系統(tǒng)自帶命令查占用情況lsof -i :8080如果返回了進程信息就說明端口確實被占了。最簡單的處理方式是改映射端口把 compose 文件里的映射改成其他端口比如ports: - 8081:80然后重新docker compose up -d。不推薦去強行關(guān)閉占用進程容易被誤傷。保留原始容器內(nèi) 80 端口不變只改宿主機側(cè)的映射對容器內(nèi)部無感知。5.2 502 Bad Gateway為什么 Nginx 找不到 PHP-FPM502 是部署 Nginx PHP-FPM 時最常見的報錯含義是 Nginx 把請求轉(zhuǎn)發(fā)到了某個目標但目標服務沒有應答。排查方向就圍繞目標到底通不通展開。先確認 PHP 容器里 PHP-FPM 進程是否在運行docker compose exec php ps aux | grep php-fpm能看到主進程和多個 worker 進程說明服務本身沒掛。接著確認 Nginx 容器能否解析到 php 這個主機名docker compose exec nginx getent hosts php如果這一步?jīng)]有輸出對應的 IP說明網(wǎng)絡配置有問題比如兩個容器不在同一個網(wǎng)絡里。用docker compose inspect php看 php 服務的 Networks 部分再用同樣方法看 nginx 服務的 Networks確保兩者都掛載了 app-net。通常 502 的根源就是網(wǎng)絡不在同一張網(wǎng)里或者 php-fpm 進程崩潰了。網(wǎng)絡配置正確但進程不在則重新啟動 php 容器。5.3 訪問 PHP 文件變成下載或者直接空白請求一個 .php 文件Nginx 返回空白或者瀏覽器把它當成文件下載說明 Nginx 根本沒有把請求轉(zhuǎn)交給 PHP-FPM而是當作普通靜態(tài)文件處理了。原因基本集中在 Nginx 的 location 正則匹配上。檢查location ~ \.php$這一行是否寫對。容易犯的錯是寫成了location \.php$少了不區(qū)分大小寫的~修飾符或漏掉了結(jié)尾的$。另外檢查是否真的加載到了這份配置。我遇到過配置文件放錯目錄的情況放在/etc/nginx/的nginx.conf里而不是conf.d目錄下導致整份站點配置從未生效。加載配置文件的地方用docker compose exec nginx nginx -t這條指令會檢查配置文件的語法并打印出實際讀取了哪些配置文件是排查配置問題的第一利器。5.4 改了代碼不生效文件不同步或被權(quán)限卡住代碼改了但瀏覽器里沒變化最直接的原因是文件根本沒有同步進容器。先用一條命令驗證docker compose exec nginx ls -l /var/www/html看看容器內(nèi)的文件時間戳是不是最新的。如果不是檢查掛載路徑是否寫對。macOS 上 Docker Desktop 的文件共享本身有極小的延遲但正常情況下秒級就能同步。發(fā)現(xiàn)遲遲不同步就重啟一下 Docker Desktop 的文件共享服務或者在 Docker Desktop 設置里檢查文件共享目錄是否包含了項目路徑。另一種常見原因是 PHP 的 opcache 緩存了舊代碼。開發(fā)環(huán)境建議在 PHP 容器的配置中關(guān)閉 opcache或者啟用自動重載docker compose exec php php -m | grep opcache如果看到 opcache需要在Dockerfile或容器配置里設置opcache.validate_timestamps1并且opcache.revalidate_freq0。這樣每次文件變化PHP 都會重新加載。有些框架自己也會緩存配置比如 Laravel 的bootstrap/cache目錄改了.env后需要php artisan config:clear。這類框架緩存問題和 PHP 運行環(huán)境無關(guān)但也常讓人誤以為 Docker 壞了。5.5 Docker Desktop 啟動慢、電腦發(fā)熱、磁盤占用高M 系列芯片的機器跑 Docker Desktop正常情況下性能是夠用的但有些場景會明顯卡頓。最典型的是把整個項目目錄直接掛載進容器然后項目里又有幾萬個依賴文件比如node_modules、vendor。macOS 上的文件掛載走的是虛擬機文件共享通道海量小文件場景性能會明顯下降。對策是分清哪些需要實時同步哪些不用。代碼目錄用掛載依賴目錄則盡量放進鏡像或者使用命名卷。比如在 Compose 里為 vendor 目錄單獨建一個命名卷services: php: volumes: - ./www:/var/www/html - php-vendor:/var/www/html/vendor volumes: php-vendor:這樣 vendor 不會落到宿主機文件系統(tǒng)里讀寫性能由 Docker 的卷存儲管理比直掛目錄快不少。代價是執(zhí)行 composer install 時容器內(nèi)已經(jīng)有了 vendor宿主機項目目錄里沒有代碼提交時需要注意.gitignore策略。電腦發(fā)熱和磁盤占用通常是因為 Docker Desktop 里堆積了大量不再使用的鏡像、容器、日志。我是按月清理一次先查看占用docker system df看到懸空鏡像和無用緩存執(zhí)行docker system prune -af這條命令會刪除所有未使用的鏡像、容器和網(wǎng)絡磁盤空間能明顯回收。執(zhí)行前想清楚開發(fā)環(huán)境里跑著的容器不受影響。6. 再擴展一層定制 PHP 鏡像和加入 MySQL6.1 為什么需要定制的 PHP 鏡像官方php:8.3-fpm-alpine鏡像只包含最基礎(chǔ)的 PHP 環(huán)境很多常用的擴展沒有預裝。實際項目里幾乎必然會用到 PDO、pdo_mysql可能還需要 gd、redis、zip 等。定制鏡像是通過編寫 Dockerfile 實現(xiàn)的。在項目根目錄建一個php/DockerfileFROM php:8.3-fpm-alpine RUN docker-php-ext-install pdo pdo_mysql mysqli \ docker-php-ext-install opcache COPY ./php/conf.d/opcache.ini /usr/local/etc/php/conf.d/opcache.inidocker-php-ext-install是 PHP 官方鏡像自帶的擴展安裝腳本一條命令就能編譯并安裝擴展。如果需要 gd 這類依賴外部庫的擴展得先用apk add安裝系統(tǒng)依賴再執(zhí)行安裝這里不展開了按項目需求逐步加即可。然后修改 Compose 中 php 服務php: build: context: . dockerfile: php/Dockerfile image: php-nginx-demo-php container_name: demo-php volumes: - ./www:/var/www/html networks: - app-netbuild指令告訴 Compose 使用 Dockerfile 構(gòu)建鏡像而不是從遠程拉取。image字段則給構(gòu)建出來的鏡像一個本地標簽名。啟動命令改成docker compose up -d --build之后每次修改 Dockerfile都執(zhí)行帶--build的命令重新構(gòu)建。6.2 加入 MySQL 服務項目要跑動態(tài)數(shù)據(jù)就繞不開數(shù)據(jù)庫。在 Compose 中增加一個 MySQL 服務mysql: image: mysql:8.4 container_name: demo-mysql environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: demo MYSQL_USER: demo MYSQL_PASSWORD: demo123 ports: - 3306:3306 volumes: - mysql-data:/var/lib/mysql networks: - app-net volumes: mysql-data:注意幾個點MYSQL_ROOT_PASSWORD是初始化時設定的 root 密碼只在首次創(chuàng)建數(shù)據(jù)卷時生效。開發(fā)環(huán)境用簡單密碼可以生產(chǎn)環(huán)境絕對不行。mysql-data是一個命名卷數(shù)據(jù)庫文件不會隨著容器刪除而丟失。容器內(nèi)的 MySQL 會監(jiān)聽 3306 端口。ports映射后宿主機上的數(shù)據(jù)庫客戶端也能通過 localhost:3306 連接。關(guān)鍵點PHP 容器連接數(shù)據(jù)庫時主機名要寫mysql不能寫localhost。因為 localhost 在 PHP 容器內(nèi)部指向它自己而實際的 MySQL 服務是在另一個容器里DNS 解析mysql才能找到它。在 PHP 代碼里數(shù)據(jù)庫連接配置會是類似這樣$pdo new PDO(mysql:hostmysql;dbnamedemo;port3306, demo, demo123);這個連接池的問題和早期手工跑的時候 Nginx 容器內(nèi)部訪問 PHP-FPM 不能寫 localhost 是同一種邏輯只是現(xiàn)在把這條道理應用到了數(shù)據(jù)庫上。6.3 常用擴展與初始化數(shù)據(jù)的經(jīng)驗在開發(fā)階段我通常會把比較固定的擴展提前固化在 Dockerfile 里比如 pdo、pdo_mysql、opcache、redis避免每次容器重建都手動編譯。對國際化項目還會加 intl、bcmath。MySQL 初始化數(shù)據(jù)的做法我推薦把初始化 SQL 腳本放到mysql/init目錄并在 Compose 中掛載volumes: - ./mysql/init:/docker-entrypoint-initdb.d鏡像第一次啟動數(shù)據(jù)卷為空時會自動執(zhí)行這個目錄下的 SQL 腳本完成建表、導入初始數(shù)據(jù)。注意只有首次初始化會執(zhí)行數(shù)據(jù)卷已存在后腳本不會再次運行。需要重置時執(zhí)行docker compose down -v刪除數(shù)據(jù)卷再重新 up。這個-v參數(shù)會連命名卷一起刪除是個危險的命令確定不要數(shù)據(jù)才用。最后說點實際操作中的體會這套環(huán)境我前后搭過不止一次最大的感受是Docker 方案的復雜性集中在最開始一旦把標準目錄結(jié)構(gòu)和 Compose 文件定下來后面就變成機械操作。每次在新電腦上重建環(huán)境時我最常忘的就是 Nginx 的 root 路徑必須和代碼掛載路徑一致這個點我建議所有人都先在配置文件里反復確認能省下大量排錯時間。還有一個小技巧開發(fā)時盡量用docker compose exec nginx nginx -s reload做 Nginx 配置熱加載比反復重啟容器快得多。如果你也是 macOS 上的 PHP 開發(fā)者建議從手工 docker run 跑通一次再寫 Compose理解會扎實很多。這套流程跑順后后續(xù)加 Redis、加隊列、加定時任務都是在同一個模板上向外擴展而已。