継続的デプロイメントは、今日のウェブ開発には欠かせない要素です。バージョン管理システムから本番環境への変更を自動デプロイすることで、開発者の人為的ミスが減り、開発プロセスが効率化され、ウェブサイトを常に最新のコード変更が適用された状態に保つことができます。
Kinstaのお客様は、SSH経由でサーバーに変更を直接反映することができます。そしてGitHub Actionsを使用すると、デプロイプロセス全体を自動化して、シームレスに本番サイトに変更をデプロイ可能です。
今回は、GitHub Actionsを使用して、KinstaでホスティングするWordPressサイトに継続的デプロイメントを設定する方法をご紹介します。ローカル環境のセットアップからGitHubへのプッシュ、本番サイトへの自動デプロイまですべて網羅します。
前提条件
KinstaでWordPressサイトの継続的デプロイメントを設定するには、以下が必要になります。
- KinstaでホスティングされているWordPressサイト
- DevKinsta、またはサイトのバックアップ(ローカルにサイトを取り込むため)
- サイトのコードを保存してプッシュするためのGitHubリポジトリ
- Gitの基礎知識(コードのプッシュや
.gitignore
ファイルの使用など)
ローカルにサイトを取り込んでGitHubをセットアップする
Kinstaをご利用の場合、WordPressサイトのローカルファイルにアクセスする最も簡単な方法は、DevKinstaを使用することです。数回のクリックで、サイトをKinstaサーバーからDevKinstaに取り込み、ローカル環境ですぐにサイト開発を行うことができます。
手順は以下のとおりです。
- DevKinstaを開き、「サイトの追加」をクリック
- 「Kinstaからインポートする」を選択すると、サイト全体がダウンロードされてローカルで開発ができるように
サイトをローカルで開発できるようになったら、任意のコードエディターでサイトのフォルダを開きます。ファイルをGitHubにプッシュする前に、WordPressコアファイルやアップロードしたデータ、機密情報などの不要なファイルのアップロードを避けるため、プロジェクトのルートディレクトリに.gitignore
ファイルを追加してください。WordPress標準の.gitignore
テンプレートを使用し、テンプレートの内容をコピーして保存します。
次にGitHubリポジトリを作成し、サイトのファイルをGitHubにプッシュします。
Kinsta用のGitHubのシークレットを作成する
GitHubからKinstaへのデプロイを自動化するには、ユーザー名、パスワード、ポート、IPアドレスなどのSSH情報が必要になります。これらは機密情報のため、GitHubのシークレットとして保存します。
GitHubでシークレットを作成するには、以下の手順に従ってください。
- GitHubの自分のリポジトリにアクセスする
- 「Settings」>「Secrets and variables」>「Actions」>「New repository secret」をクリックする
- 以下のシークレット情報を追加する。
KINSTA_SERVER_IP
(SFTP/SSHセクションの「ホスト」)KINSTA_USERNAME
(SFTP/SSHセクションの「ユーザー名」)PASSWORD
(SFTP/SSHセクションの「パスワード」)PORT
(SFTP/SSHセクションの「ポート」)
上記の情報は、MyKinstaの「WordPressサイト」>(サイト名)>「情報」画面で確認できます。
これで、WordPressサイトの継続的デプロイメントを設定できます。
Kinstaサーバーを設定する
GitHub Actionsでデプロイプロセスを自動化する前に、GitHubリポジトリからコードを受信してデプロイできるよう、Kinstaサーバーを設定します。
具体的には、1. Kinstaサーバー上にGitのベアリポジトリを作成すること、2. 最新の変更を本番サイトに自動的にデプロイするためのpost-receive
フックを設定することの2つのステップが必要になります。
1. KinstaにGitのベアリポジトリを作成する
Gitのベアリポジトリは、GitHubがコードをプッシュするリモートリポジトリの役割を果たすものです。このリポジトリには作業ディレクトリがなく、中央リポジトリとしてコードを管理・保存する場所になります。
まずは、MyKinstaで利用可能な「SSHターミナルのコマンド」を使用してSSHでKinstaサーバーに接続します。
続いて、サーバー上のプライベートフォルダに移動します(存在しない場合は作成)。
mkdir -p /www/your-site/private
cd /www/your-site/private
your-site
は、MyKinstaの「WordPressサイト」>(サイト名)>「情報」画面の「環境情報」セクションで確認できます。「パス」にあるサイトの実際のフォルダ名に置き換えてください。
最後に、Gitのベアリポジトリを作成します。
git init --bare your-repo.git
your-repo
は任意の名前に置き換えることができます。一貫性を保つためにGitHubリポジトリ名を使用するのもOKです。
このベアリポジトリが、GitHubからプッシュされたコードを受け取ることになります。
2. コード受信後のフックを設定する
ベアリポジトリを作成したら、続いてpost-receive
フックを設定します。このスクリプトは、GitHubのmain
ブランチに更新がプッシュされると、自動的にコードを本番サイトにデプロイします。
これを行うには、Gitベアリポジトリのhooksディレクトリに移動します。
cd /www/your-site/private/your-repo.git/hooks
post-receive
フックを作成して編集します。
nano post-receive
次に、post-receive
ファイルに以下のスクリプトを追加します。このスクリプトは、本番サイトのpublic
ディレクトリに最新のコードを確認します。
#!/bin/bash
TARGET="/www/your-site/public"
GIT_DIR="/www/your-site/private/your-repo.git"
while read oldrev newrev ref
do
BRANCH=$(git rev-parse --symbolic --abbrev-ref $ref)
if [[ $BRANCH == "main" ]];
then
echo "Ref $refを受信しました。${BRANCH}ブランチを本番環境にデプロイ中..."
git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
else
echo "Ref $refを受信しました。何もしません。このサーバーではmainブランチのみがデプロイ可能です。"
fi
done
上のスクリプトは、main
ブランチのコードのみをデプロイします。TARGET
変数は、本番サイトのファイルがあるディレクトリ(/www/your-site/public
)を、GIT_DIR
変数はベアリポジトリを指します。
Ctrl + X、次にY、最後にEnterを押してファイルを保存して終了します。
最後にスクリプトを実行可能にして、各プッシュ後に自動的に実行できるようにします。
chmod +x post-receive
これで、GitHubリポジトリのmain
ブランチに変更がプッシュされた際に、自動的にコードをデプロイするpost-receive
フックの準備が完了です。
3. 個人用アクセストークン(PAT)を生成・追加する
GitHubでは現在、パスワードによる認証を行えないため、SSH経由でGitHubにコードをプッシュする際は、個人用アクセストークン(PAT)を使用して認証する必要があります。このトークンにより、安全にプッシュすることができます。
個人用アクセストークンの作成手順は、以下のとおりです。
- GitHubアカウントにアクセスし、プロフィール画像をクリックして、「Settings」をクリックする
- 左サイドバーで「Developer settings」をクリックする
- 「Personal access tokens」>「Tokens (classic)」をクリックする
- 「Generate new token」をクリックして名前を付ける(「Kinsta Deployment Token」など)
- 「Select scopes」で
repo
を選択する(プライベートリポジトリを完全に制御するため) - 「Generate token」をクリックしてトークンをコピーする(今後トークンは表示されることがないため必ずコピーする)
次に、以下のコマンドを実行して、GitHubリポジトリをリモートとして追加します。プレースホルダーは実際の詳細情報に置き換えてください。
git remote add origin https://your-username:[email protected]/your-username/your-repo.git
それぞれ以下に置き換えます。
your-username
:GitHubのユーザー名YOUR_PERSONAL_ACCESS_TOKEN
: 先ほど生成したトークンyour-repo
:GitHubリポジトリ名
自動デプロイ用のGitHub Actionsワークフローを作成する
WordPressサイトをローカルマシンにインポートして、GitHubにプッシュし、必要なGitHubのシークレットを設定したら、GitHub Actionsのワークフローを作成していきます。このワークフローは、main
ブランチにプッシュするたびに変更を自動的にKinstaにデプロイするものです。
デプロイを自動化するには、デプロイ方法を定義したYAMLファイルを作成します。
- GitHubリポジトリに
.github/workflows
という名前のディレクトリを作成する - このディレクトリの中に
deploy.yml
というファイルを作成する deploy.yml
ファイルに以下の内容を貼り付ける
name: Deploy to Kinsta
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Deploy to Kinsta via SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.KINSTA_SERVER_IP }}
username: ${{ secrets.KINSTA_USERNAME }}
password: ${{ secrets.PASSWORD }}
port: ${{ secrets.PORT }}
script: |
cd /www/your-site/private/your-repo.git # KinstaのGitベアリポジトリに移動
git --work-tree=/www/your-site/public --git-dir=/www/your-site/private/your-repo.git fetch origin main # GitHubから最新の変更点を取得
git --work-tree=/www/your-site/public --git-dir=/www/your-site/private/your-repo.git reset --hard origin/main # 変更を本番サイトにデプロイ
ワークフローの詳細
ワークフローの詳細は、以下のようになっています。
- トリガー:GitHubリポジトリの
main
ブランチにコードがプッシュされるたびに起動します。 - ジョブ:
deploy
というjob
がひとつ含まれ、Ubuntuの仮想マシン(ubuntu-latest
)上で実行されます。 - コードの確認:
actions/checkout@v2
アクションを使って、GitHubリポジトリから最新のコードを取り出します。 - SSH経由でデプロイ:
appleboy/ssh-action
は、設定したシークレット(サーバーIP、ユーザー名、パスワード、ポート)を使用して、SSH経由でKinstaサーバーに安全に接続するために使用されます。このステップのスクリプトは、次のコマンドを実行します。cd /www/your-site/private/your-repo.git
─Kinstaサーバー上のGitベアリポジトリに移動git fetch origin main
─GitHubリポジトリのmain
ブランチから最新の変更を取得git reset --hard origin/main
─WordPressがホスティングされているpublic
ディレクトリの本番サイトを更新して変更を適用
ワークフローをテストする
ワークフローを設定したら、GitHubリポジトリのmain
ブランチに小さな変更をプッシュしてテストしてみてください。変更をプッシュするたびに、GitHub Actionsが自動的にデプロイをトリガーし、コードの最新バージョンをプルして、Kinsta上の本番サイトにデプロイするようになれば成功です。
デプロイのステータスは、GitHubリポジトリの「Actions」タブで監視可能です。ワークフローでエラーが発生した場合は、トラブルシューティングや問題の修正に役立つログが詳細に表示されます。
まとめ
GitHub Actionsを使って、WordPressサイトの継続的デプロイメントを設定することで、開発ワークフローを自動化し、GitHubにプッシュされたすべての変更が自動的にKinsta上の本番サイトにデプロイされるようになります。
また、@wordpress/scriptsパッケージを使ったテストやフォーマットなど、追加のワークフローをパイプラインに統合することもできます。
コメントを残す