如何使用Bedrock和Trellis進行WordPress開發？

這篇文章是寫給所有 WordPress 開發者的！

今天我們將講解如何在 Kinsta 上使用和整合 Bedrock 和 Trellis。

如果您之前沒有聽說過這兩個工具，我們也會進行介紹，並希望能夠幫助您理解為什麼您應該選擇它們而不是傳統的設定。

Bedrock和Trellis

Bedrock 和 Trellis 的存在都是為了簡化 WordPress 網站的開發、維護和部署。

• Bedrock 提供了一種管理 WordPress 安裝的替代方法，它擁有改進的資料夾結構、現代化的開發工具和更高的安全性。
• Trellis 與 Bedrock 配合使用，可以使用 Vagrant 建立開發環境，並實現一鍵部署。

使用 Bedrock 的主要原因是為 WordPress 專案提供適當的依賴項和包管理。您可能已經熟悉 JavaScript 的 npm 或 Ruby 的 Bundler。PHP 也不例外，它的對應工具是 Composer。

雖然使用包管理器很常見，但對於 WordPress 本身來說卻不太常見，因為 WordPress 已經有了自己的外掛概念。Bedrock 整合了 Composer 來管理外掛、主題，甚至 WordPress 核心本身的依賴項。

Trellis 是一款可以輕鬆建立開發和生產伺服器來託管 WordPress 網站的工具。它也專門用於與基於 Bedrock 的網站配合使用。 Trellis 的預設用例是使用 Vagrant 進行開發，並在生產環境中使用，以便在這兩個環境之間保持平衡。

這篇文章解釋了一個略有不同的用例：Trellis 用於開發伺服器，Kinsta 用於生產（和/或預釋出）伺服器。

為什麼選擇 Kinsta 等專業的 WordPress 託管伺服器而不是 Trellis 配置的 VPS？因為有時您想付費請人管理伺服器，而不是自己動手（尤其是在您有很多客戶的情況下）。專業的 WordPress 託管伺服器還可以更輕鬆地進行擴充套件，而無需處理多伺服器、負載均衡器和雲上傳。

Bedrock與常規WordPress

您可能想知道為什麼要使用 Bedrock 而不是傳統的 WordPress 安裝。原因是 Bedrock 專為現代 Web 開發者打造：

• 特定於環境的配置檔案，儲存在公共 Web 根目錄之外
• 環境變數將配置與程式碼分離在單個 .env 檔案中
• 透過限制對非 Web 檔案的訪問以及使用 bcrypt 雜湊密碼來增強安全性
• 名為 app 的自定義 wp-content 目錄
• 用於管理 WordPress、外掛、主題和其他 PHP 依賴項的 Composer
• 排除 WordPress 核心、外掛和上傳檔案的 .gitignore

Raspberry Pi、Snopes、JetBlue 等公司都選擇使用 Bedrock 來支援他們的 WordPress 網站。

讓我們並排檢視一下這兩個資料夾結構：

Bedrock vs WordPress

Bedrock 將 WordPress 安裝到子目錄中提升到了一個新的高度。Bedrock 背後的許多理念都受到 Twelve-Factor 應用方法論（包括 WordPress 特定版本）的啟發。

為Kinsta配置Trellis

首先，請確保您的 SSH 公鑰已新增到 MyKinsta 資訊中心。

只需進行少量更新，Trellis 即可部署到 Kinsta。由於 Kinsta 從 Web 伺服器的角度提供了所有內容，因此無需配置您的預釋出環境和生產環境。

Trellis 中的一鍵部署功能只需少量配置即可與 Kinsta 相容。配置完成後，您可以透過在 Trellis 中執行部署手冊來部署您的 WordPress 網站：

ansible-playbook deploy.yml -e env=staging -e site=example.com --limit=kinsta_staging

開啟您的 MyKinsta 資訊中心並導航到您使用 Bedrock 和 Trellis 設定的 WordPress 網站，同時開啟程式碼編輯器並導航到專案中的 trellis 目錄。

首先編輯 trellis/ansible.cfg，將以下內容新增到頂部的 [defaults] 中：

forks = 3
host_key_checking = False

暫存配置

確保 trellis/group_vars/staging/wordpress_sites.yml 已為您的暫存網站配置正確的 canonical：

wordpress_sites:
example.com:
site_hosts:
- canonical: staging-example.kinsta.com

然後開啟 trellis/group_vars/staging/main.yml 並將以下內容新增到檔案末尾：

project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

將 project_root 和 www_root 路徑替換為 MyKinsta 儀表板中為您的 Kinsta 暫存環境提供的正確路徑。

在 MyKinsta 中找到您的公共根目錄。

接下來，執行 ansible-vault edit group_vars/staging/vault.yml 命令，開啟 trellis/group_vars/staging/vault.yml 檔案進行編輯。

我們需要將 db_user、 db_name 和 db_password 新增到 env 檔案中。您可以在 MyKinsta 資訊中心中您網站的主資訊螢幕上找到這些值。

MyKinsta 中的 SFTP 和資料庫憑據。

vault_wordpress_sites:
example.com:
env:
db_user: "example"
db_name: "example"
db_password: "xxxxxxxxxxxxxxx"
# Generate your keys here: https://roots.io/salts.html
auth_key: ""
secure_auth_key: ""
logged_in_key: ""
nonce_key: ""
auth_salt: ""
secure_auth_salt: ""
logged_in_salt: ""
nonce_salt: ""

最後，開啟 trellis/hosts/staging 並將內容替換為：

kinsta_staging ansible_host=104.154.94.123 ansible_ssh_port=12345 ansible_ssh_extra_args='-o StrictHostKeyChecking=no'
[web]
kinsta_staging
[staging]
kinsta_staging

確保主機和 SSH 埠與 MyKinsta 儀表板中列出的相匹配。

您的暫存環境的 SFTP 主機和埠詳細資訊。

注：在某些情況下，尤其是在使用非標準 WordPress 設定（例如 Bedrock）的情況下，Kinsta 可能無法自動檢測您的資料庫憑據。這可能會導致在執行克隆環境、恢復備份或更新資料庫密碼等操作時出現問題。

為避免這種情況，您需要在 Bedrock 網站的配置檔案 ( bedrock/config/application.php ) 中手動定義特定的 PHP 常量。此步驟對於確保 Kinsta 能夠正確管理您網站的資料庫憑據至關重要。

定義必要常量的方法如下：

define('DB_NAME', defined('SERVER_SECRET_DB_NAME') ? SERVER_SECRET_DB_NAME : 'your_db_name');
define('DB_USER', defined('SERVER_SECRET_DB_USER') ? SERVER_SECRET_DB_USER : 'your_db_user');
define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB_PASSWORD : 'your_db_password');
define('DB_HOST', defined('SERVER_SECRET_DB_HOST') ? SERVER_SECRET_DB_HOST : 'localhost');

透過將這些行新增到您的配置檔案中，您可以確保 MyKinsta 可以正確管理您的資料庫憑據，這對於維持順利和無錯誤的部署過程至關重要。

生產環境配置

現在，讓我們在生產環境中重複上述步驟。請確保在 MyKinsta 儀表板中切換到“即時”環境。

切換到 MyKinsta 中的即時環境。

開啟 trellis/group_vars/production/main.yml 並將以下內容新增到檔案末尾：

project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

請務必將 project_root 和 www_root 路徑替換為 MyKinsta 儀表板中為您的即時環境提供的正確路徑。

接下來，執行 ansible-vault edit group_vars/production/vault.yml 開啟 trellis/group_vars/production/vault.yml 進行編輯：

vault_wordpress_sites:
example.com:
env:
db_user: "example"
db_name: "example"
db_password: "xxxxxxxxxxxxxxx"
# Generate your keys here: https://roots.io/salts.html
auth_key: ""
secure_auth_key: ""
logged_in_key: ""
nonce_key: ""
auth_salt: ""
secure_auth_salt: ""
logged_in_salt: ""
nonce_salt: ""

最後，開啟 trellis/hosts/production 並將內容替換為：

kinsta_production ansible_host=104.154.94.123 ansible_ssh_port=12345 ansible_ssh_extra_args='-o StrictHostKeyChecking=no'
[web]
kinsta_production
[production]
kinsta_production

修改部署任務

Trellis 部署會嘗試重新載入 php-fpm，我們需要將其從 Kinsta 伺服器上的嘗試執行中移除。我們還需要在部署時觸發清除 Kinsta 快取的事件。

開啟 trellis/roles/deploy/hooks/finalize-after.yml 並滾動到檔案底部。刪除最後一個 Reload php-fpm 任務，並新增以下內容：

- name: Clear Kinsta cache
uri:
url: "{{ site_env.wp_home }}/ask-support-rep/"
method: GET

向 Kinsta 支援代表詢問清除您網站上的快取的 URL 後，替換上面的 ask-support-rep。

可選：安裝Composer依賴項

如果您看到提示您執行“Composer Install”的螢幕，請在上面“Clear Kinsta cache”程式碼之前新增以下內容：

- name: Install Composer dependencies
composer:
command: install
working_dir: >/www/example123/public/final-path

/final-path 可能會根據您的 Bedrock/Trellis 設定而有所不同。

將kinsta-mu-plugins新增到Bedrock

Bedrock 網站已自動安裝 mu-plugins，但您需要透過引入 kinsta-mu-plugins 包來安裝 Kinsta MU 外掛。此外掛（在您透過 MyKinsta 建立 WordPress 網站時預設安裝）負責處理諸如全頁面快取和 Kinsta CDN 整合等任務。

開啟 site/composer.json 並在 repositories 陣列中新增以下內容：

{
"type": "package",
"package": {
"name": "kinsta/kinsta-mu-plugins",
"type": "wordpress-muplugin",
"version": "2.3.3",
"dist": {
"url": "https://kinsta.com/kinsta-tools/kinsta-mu-plugins.zip",
"type": "zip"
}
}
}

然後從您的 Bedrock/site 目錄執行以下命令（或在 composer.json 檔案中指定 kinsta/kinsta-mu 外掛作為要求）：

composer require kinsta/kinsta-mu-plugins:2.3.3

可能需要以下常量來修復 CDN 路徑和共享外掛資源 URL 的問題。將以下程式碼新增到您網站的配置檔案（Bedrock 網站中的 bedrock/config/application.php）：

/**
* Kinsta CDN fix for Bedrock
*/
define('KINSTA_CDN_USERDIRS', 'app');
/**
* Fix Kinsta MU Plugins URL path with Bedrock
*/
$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';
define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");

如需瞭解更多資訊，包括如何更新外掛，請檢視 Kinsta MU 外掛指南。

最後步驟

最後一步是告知 Kinsta 將文件根目錄設定為何。登入 MyKinsta，請求支援團隊將您的文件根目錄更新為 public/current/web。

注：您現在可以使用 Kinsta API 自行設定，而無需聯絡支援人員。以下是一個簡單的示例：

curl -X POST \
'https://api.kinsta.com/v2/sites/environments/{env_id}/change-webroot-subfolder' \
-H 'Authorization: Bearer YOUR_API_TOKEN' \
-H 'Content-Type: application/json' \
-d '{
"web_root_subfolder": "current/web",
"clear_all_cache": true,
"refresh_plugins_and_themes": true
}'

確保將 current/web 替換為您用作文件根目錄的實際子資料夾路徑。該資料夾必須已存在且包含 index.php 檔案。

如果您之前尚未獲取清除快取的 URL，也請諮詢您的支援代表，並確保 trellis/roles/deploy/hooks/finalize-after.yml 已更新為正確的 URL，以便在成功部署後清除 Kinsta 的快取。

完成此更改後，您只需一行程式碼即可部署到暫存環境和生產環境：

# Deploy staging
ansible-playbook deploy.yml -e env=staging -e site=example.com --limit=kinsta_staging
# Deploy production
ansible-playbook deploy.yml -e env=production -e site=example.com --limit=kinsta_production

更好的是…設定一個持續整合服務，例如 CircleCI，當您提交到 staging 或 master 時自動為您執行部署！