今回は、WordPressの開発者の皆さんのための記事となります。

KinstaでBedrockとTrellisを使用、統合する方法をご説明します。

また、この2つのツールについてご存じない方のために、その紹介をしながら、従来のセットアップではなくこの2つのツールを使用するメリットにも迫りたいと思います。

BedrockとTrellis

BedrockとTrellisは、WordPressサイトの開発、メンテナンス、デプロイを簡単にしてくれるものです。

  • Bedrockは、フォルダ構造の改良、最新の開発ツール、セキュリティの向上など、WordPressを用いた管理をあらゆる面で支援してくれます。
  • Trellisを使えば、Bedrockと連携し、Vagrantによる開発環境とワンコマンドデプロイを実現することができます。

Bedrockを使う主な目的は、WordPress関連プロジェクトで適切な依存関係とパッケージ管理を行うことです。JavaScriptのnpmやRubyのBundlerはすでにおなじみかもしれません。PHPも同様で、これに相当するのがComposerです。

パッケージマネージャを使うのが一般的ですが、WordPress自体となると、すでにプラグインの概念があるためあまり一般的ではありません。Bedrockを使えば、Composerを統合し、プラグイン、テーマ、そしてWordPressコアそのものを依存関係として管理することができます。

Trellisは、WordPressサイトの開発用サーバーと本番用サーバーを簡単に作成するのに便利なサービスです。特にBedrockベースのサイトと連動する作りになっています。Trellisのデフォルトの使用法は、Vagrantで開発し、「本番環境でも」使用することで、2つの環境間の整合性を取ることです。

この記事では、少し異なる用途を扱います。Trellisを開発サーバーに、Kinstaを本番（そしてステージング）サーバーに使用します。

なぜ、TrellisでプロビジョニングされたVPSの代わりに、Kinstaを使うのか。そんな疑問をお持ちの方もいるかもしれません。答えは簡単です。自分でサーバーを管理するのではなく、プロにお金を払って管理してもらうことにメリットがあるからです（特に多くのクライアントを抱えている場合）。Kinstaではまた、スケーリングも容易です。複数のサーバー、ロードバランサー、およびクラウドのアップロードに手を焼く必要はありません。

多くのWordPressサーバーが開発者思いとは言えず、TrellisとBedrockの使用に必要なSSH接続、ComposerやWP-CLIの統合をサポートしていません。一方で、KinstaはStarterからEnterpriseまですべてのホスティンプランでSSH接続に標準対応し、上記すべての操作が可能になっています。また、調整のためにルートパスを変更することもできます。

Bedrockと通常のWordPressの違い

なぜ、普通のWordPressではなく、Bedrockを使うのか。その理由は、Bedrockが特に現代のウェブ開発者を念頭に置いて構築されているからです。

  • 環境固有の設定ファイルを、公開されているウェブルートの外側に保存
  • 環境変数により、設定とコードを分離し、単一の.envファイルに格納
  • ウェブ以外のファイルへのアクセスを制限し、bcrypt ハッシュ化されたパスワードでセキュリティを強化
  • 特別なwp-contentディレクトリ（appという名称）
  • Composerで、WordPress、プラグイン、テーマ、その他のPHPの依存関係を管理
  • .gitignoreでWordPressコア、プラグイン、アップロードファイルを除外

Raspberry Pi、Snopes、JetBlueなどがWordPressサイトの運営にBedrockを活用しています。

それでは、2つのフォルダ構造を並べて見てみましょう。

BedrockとWordPress
BedrockとWordPress

この2つのフォルダ構造を並べて見てみましょう。

Bedrockを使うと、通常とは比べものにならないほどに、WordPressのサブディレクトリへのインストールが捗ります。ちなみにBedrockを形作る指針の多くは、WordPress固有のバージョンを含む12ファクターアプリの方法論に触発されたものです。

KinstaにあわせたTrellisの設定

まず、公開SSH鍵がMyKinstaで追加済みであることを確認してください。

ちょっとした調整をするだけで、TrellisからKinstaにデプロイすることができます。Kinstaが、ウェブサーバーの観点から必要とされるすべてを担うので、ステージングと本番環境のプロビジョニングは必要ありません。

少しの設定でKinstaと連動可能なので、Trellisのワンコマンドデプロイが便利です。一度設定すれば、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のパスを、Kinstaステージング環境（MyKinstaで確認可能）の実際のパスに置き換えます。

MyKinstaでパブリックルートを確認する
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とデータベースの認証情報
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ホストとポートの情報
ステージング環境のSFTPホストとポートの情報

本番環境の構成

続いて、本番環境でも同じ作業を繰り返しましょう。MyKinstaで「本番（Live）」環境に切り替えてください。

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

サイト上のキャッシュクリアのためのURLをKinstaカスタマーサポートに問い合わせた上で、上記のask-support-repの部分にそれを記述します。

（任意）Composerの依存関係をインストールする

「Composerインストール/Composer Install」の実行を指示する画面が表示された場合、上記の「Clear Kinsta cache」コードの直前に、以下を貼り付けてください。

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

/final-pathは、Bedrock/Trellisの設定により異なる場合があります。

Bedrockにkinsta-mu-pluginsを追加する

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 pluginsを要件として指定）。

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カスタマーサポートとの最終確認

最後に、もう一つやるべきことがあります。ドキュメントルートの設定に関する、Kinstaカスタマーサポートへの通知です。MyKinstaにアクセスし、チャットを使って、ドキュメントルートをpublic/current/webに変更するようお知らせください。

キャッシュクリアURLをまだ取得していない場合は、こちらもサポートに質問してください。そして、trellis/roles/deploy/hooks/finalize-after.ymlファイルにて、デプロイ成功時にはKinstaのキャッシュクリア用URLが正しく参照されることを確認します。

この変更により、1行でステージング環境と本番環境の両方にデプロイできるようになります。

# 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のいずれかにコミットし、デプロイを自動で実行することも可能でしょう。