Blog

GitHub ActionsでpushされたらEC2に自動デプロイする

2025/04/24

下記記事を参考にGitHub ActionsでEC2に自動デプロイする方法を試してみました。

https://qiita.com/kaino5454/items/bae4bca47e6f409e072f

ちょっと変えたので、備忘録。

前提条件

• GitHubにアカウントとリモートリポジトリがある
• EC2インスタンスにローカルリポジトリが配置されており、SSHでGitHubにpushできる状態である
• AWSアカウントを持っている
• EC2インスタンスにキーペアを使ってSSH接続できる

GitHub Actions用のシークレットの追加

自動デプロイを適用したいリポジトリのページを開き、右上の「Settings」タブをクリックします。

続いて左側のメニューから「Secrets and variables」→「Actions」を選択します。

上記の画像の「New repository secret」ボタンをクリックして、GitHub Actionsで使用するシークレットを追加することができます。

下記のSecretsをこれから一つずつ追加していきます。

• AWS_ACCESS_KEY
• AWS_SECRET_ACCESS_KEY
• USER_HOST_NAME
• EC2_SECURITY_GROUP_ID
• PRIVATE_KEY

AWS_ACCESS_KEYとAWS_SECRET_ACCESS_KEY

まずはAWSのIAMロールを作成して、アクセスキーとシークレットキーを追加します。

1. AWS Management Consoleにログインし、IAMサービスを開きます

   

2. 左側のメニューから「ユーザー」を選択し、「ユーザーの作成」ボタンをクリックします

   

3. ユーザー名を入力し、「次へ」を選択します

   

4. 「ポリシーを直接アタッチする」をチェック、許可ポリシーに「AmazonEC2FullAccess」にチェックし「次へ」をクリック

   

5. 「ユーザーの作成」をクリック

   

6. 作成したユーザーを選択し、「アクセスキーを作成」ボタンをクリックします

   

7. コマンドラインインターフェース、確認にチェックを入れ「次へ」をクリックします

   

8. 「アクセスキーを作成」ボタンをクリックします

   

9. 「アクセスキーID」と「シークレットアクセスキー」をコピーします。

   

10. 先ほどコピーした値をGitHubのSecretsに追加します。下記二つとして追加します。

    • AWS_ACCESS_KEY
    • AWS_SECRET_ACCESS_KEY

これでAWSのIAMロールにシークレットキーを追加できました。

USER_HOST_NAME

続いてEC2インスタンスのユーザー名とホスト名をGitHubのSecretsに追加します。

1. EC2インスタンスのページを開き、インスタンスにチェックを入れ、「接続」ボタンをクリックします。

   

2. 「SSHクライアント」タブを開き一番下の「例:」と書かれた部分のユーザー名とホスト名が一つになった部分をコピーします。

   

3. コピーした部分を下記の名前でGitHubのSecretsに追加します。

   • USER_HOST_NAME

これでEC2インスタンスのユーザー名とホスト名を追加できました。

PRIVATE_KEY

Github ActionsからEC2インスタンスにSSH接続するために、秘密鍵をGitHubのシークレットに登録する必要があります。

EC2インスタンス作成時にSSH接続のためのキーを作成してあるはずなので、そちらを使用して、EC2インスタンスにSSH接続できるようにします。

今回はpemファイルの場合を想定しています。

下記のコマンドを実行してファイルの内容をコピーします。

bash/zsh

cat {ファイルパス}

大抵は下記に保存されていると思います。

cat ~/.ssh/{ファイル名}.pem

PowerShell

Get-Content {ファイルパス}

大抵は下記に保存されていると思います。

Get-Content ~\.ssh\{ファイル名}.pem

コピーした部分を下記の名前でGitHubのSecretsに追加します。

• PRIVATE_KEY

EC2_SECURITY_GROUP_ID

EC2のインスタンスのセキュリティグループIDをGitHubのSecretsに追加します。

• EC2_SECURITY_GROUP_ID

GitHub Actionsワークフローの作成

リポジトリのルートディレクトリに .github/workflows/ec2-deploy.yml ファイルを作成し、以下の内容を記述します。

下記の場合は、リポジトリのmainブランチにpushされたときに実行されます。

46行目のリポジトリのファイルパスと書かれた部分は、実際のリポジトリのパスに置き換えてください。

また、このコードではdocker composeで起動することを想定していますが、必要に応じて変更してください。

ec2-deploy.yml

name: Deploy to EC2

on:
  push:
    branches:
    - main

jobs:
  build:
  runs-on: ubuntu-latest
  steps:

    # IP取得ライブラリをインストール
    - name: Public IP Install
      id: ip
      uses: haythem/[email protected]

    # BranchをCheckout
    - name: Checkout
      uses: actions/checkout@v2

    # AWS CLIをインストールする
    - name: AWS CLI install
      run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          sudo ./aws/install --update
          aws --version

        # AWS CLIにキーを設定をする
    - name: AWS set Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-1

        # デプロイする
    - name: Deploy
      run: |
        # SSHのセキュリティグループを開放する
        aws ec2 authorize-security-group-ingress --group-id ${{ secrets.EC2_SECURITY_GROUP_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32
        # SSH接続して、git pullする
        echo "${{ secrets.PRIVATE_KEY }}" > private_key
        chmod 600 private_key
        ssh -oStrictHostKeyChecking=no ${{ secrets.USER_HOST_NAME }} -i private_key "cd リポジトリのファイルパス && git fetch --prune && git checkout main && git pull origin main && sudo docker compose down && sudo docker system prune --all --force && sudo docker compose up -d --build"
        # SSHのセキュリティグループを閉じる
        aws ec2 revoke-security-group-ingress --group-id ${{ secrets.EC2_SECURITY_GROUP_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

動作確認

設定が完了したら、mainブランチに変更をpushして自動デプロイが正常に動作するか確認します。

git add .
git commit -m "Setup GitHub Actions auto-deploy"
git push origin main

GitHubリポジトリの「Actions」タブでワークフローの実行状況を確認できます。

タグ:

• GitHub Actions
• EC2
• AWS

CloudflareのサブドメインをAWSのRoute53に登録する

2025/04/17

CloudflareのドメインをAWSのRoute53にサブドメインとして登録してみたので、備忘録を残します。

この方法を使えば、Cloudflareで管理しているドメインの一部をAWSのサービスで利用できるようになります。

前提条件

• Cloudflareで管理しているドメイン（例: example.com）
• AWSアカウント

まず、CloudflareでサブドメインのDNS委任を行うための準備をします。

この例では、aws.example.comというサブドメインをRoute53に委任する想定で進めます。

Route53でホストゾーンを作成する

CloudflareのドメインをRoute53に委任するためには、まずRoute53でホストゾーンを作成する必要があります。

1. AWSマネジメントコンソールにログインします

   

2. 左上のアイコンから「ネットワーキングとコンテンツ配信」>> 「Route53」をクリックします。

   

3. 左上のメニューアイコンから「ホストゾーン」を選択肢、「ホストゾーンの作成」ボタンをクリックします。

   

4. ドメイン名に委任したいサブドメイン（例: aws.example.com）を入力、「パブリックホストゾーン」を選択して「ホストゾーンの作成」ボタンをクリックします。

   

ホストゾーンが作成されると、自動的に4つのNSレコード（ネームサーバー）が生成されます。これらのNSレコードの値をメモしておきます。

例えば以下のようなものです：

ns-1234.awsdns-12.org
ns-567.awsdns-34.com
ns-890.awsdns-56.net
ns-1234.awsdns-78.co.uk

CloudflareでNSレコードを設定する

次に、CloudflareのDNS設定画面で、Route53のネームサーバーを指定したNSレコードを追加します。

1. Cloudflareのダッシュボードにログインし、対象のドメイン（example.com）を選択します。

   

2. 左側メニューの「DNS」タブをクリックし、「レコード」セクションに移動します。

   

3. 「レコードの追加」をクリックします

   

4. タイプに「NS」を選択し、「名前」欄にサブドメイン名（例: aws）、ネームサーバーにRoute53で取得したNSレコード(例: ns-1234.awsdns-78.co.uk)を入力し「保存」ボタンをクリックします。

   

5. Route53で取得したNSレコードは4つあるので、全てで手順4を行います。

DNSの伝播を待つ

DNS設定の変更が反映されるまでには時間がかかることがあります。

通常は数分から数時間程度で反映されますが、最大で48時間かかる場合もあります。

設定の確認

DNSの設定が反映されたかどうかを確認するには、以下のコマンドを使用できます：

bash/zsh

dig NS aws.example.com

PowerShell

Resolve-DnsName -Type NS -Name aws.example.com

正しく設定されていれば、Route53のネームサーバーが返ってくるはずです。

例えば出力の一部に以下のような値が得られます：

;; ANSWER SECTION:
aws.example.com.    3600    IN  NS  ns-1234.awsdns-12.org.
aws.example.com.    3600    IN  NS  ns-567.awsdns-34.com.
aws.example.com.    3600    IN  NS  ns-890.awsdns-56.net.
aws.example.com.    3600    IN  NS  ns-1234.awsdns-78.co.uk.

これで、aws.example.comのDNS管理はRoute53に委任されました。

Route53のホストゾーンで、このサブドメインに対して必要なDNSレコード（A、CNAME、MXなど）を追加できます。

タグ:

• Cloudflare
• AWS
• Route53
• DNS

Astroを使っていてCould not find Sharp.エラーが出た時の対処法

2025/03/20

Astroを使っていて「Could not find Sharp.」というエラーに対処したので備忘録です。

エラーの概要

Astroでビルド時に2種類のエラーが出ました。

エラー内容

title: ‘Could not transform image.’, hint: ‘This is often caused by a corrupted or malformed image. Re-exporting the image from your image editor may fix this issue.’, frame: undefined, type: ‘AstroError’,

エラー内容

title: ‘Could not find Sharp.’, hint: “See Sharp’s installation instructions for more information: https://sharp.pixelplumbing.com/install. If you are not relying on astro:assets to optimi ze, transform, or process any images, you can configure a passthrough image service instead of installing Sharp. See https://docs.astro.build/en/reference/errors/ missing-sharp for more information.\n” + ‘\n’ + ‘See https://docs.astro.build/en/guides/images/#default-image-service for more information on how to migrate to another image service.’, frame: undefined, type: ‘AstroError’

このエラーは通常、Astroプロジェクトで画像の最適化を行おうとした際に発生し、Sharpライブラリが見つからないことが原因です。

解決方法

そのままですが、Sharpライブラリが見つからないというエラーなので、Sharpをインストールすることで解決できます。

以下の手順に従って進めてください。

1. まず、Sharpをプロジェクトにインストールしましょう。

   pnpm

   pnpm add sharp

   npm

   npm install sharp

   yarn

   yarn add sharp

   
   

2. astro.config.mjsファイルで、Sharpが正しく設定されているか確認します。

   astro.config.mjs

   import { defineConfig } from 'astro/config';
   
   export default defineConfig({
       image: {
           service: { entrypoint: 'astro/assets/services/sharp' },
       },
   });

3. もし上記の手順で解決しない場合は、キャッシュをクリアしてみましょう。

   pnpm

   pnpm store prune

   npm

   npm cache clean --force

   yarn

   yarn cache clean

4. 最後に、依存関係を再インストールし、プロジェクトを再ビルドします。

   pnpm

   pnpm install --force
   pnpm build

   npm

   npm ci
   npm run build

   yarn

   yarn install --force
   yarn build

参考リンク

• Astro公式ドキュメント
• Sharpライブラリ

タグ:

• Astro
• JavaScript

Cloudflare PagesでNode.jsのバージョンを変更したいとき

2025/03/20

Cloudflare Pagesのビルド時にNode.jsのデフォルトバージョンが古くてエラーになることがありました。

Node.jsのバージョンを変更できたので、その方法を備忘録として残します。

デフォルトのNode.jsバージョン

Cloudflare Pagesのガイドによると、デフォルトでNode.js 10が使用されるとされています。ただし、実際のビルドログを確認すると、v12.18.0が使用されているケースもあるようです。これはプロジェクトの設定やランタイムによって異なる可能性があります。

Node.jsバージョンの変更方法

Node.jsのバージョンを変更するには、以下の2つの方法があります。

1. Cloudflare Pagesの環境変数を使用
2. ローカルファイルで環境変数を指定

どちらの方法でも、使用したいNode.jsのバージョンを指定することができます。

Cloudflare Pagesの環境変数を使用

1. Cloudflareダッシュボードにログインします。
2. 「Workers & Pages」を選択し、該当するPagesプロジェクトを開きます。
3. 「設定」→「変数とシークレット」と進み、NODE_VERSIONという名前の変数を追加します。
4. 値に希望するNode.jsのバージョン（例：20.9.0）を入力します。

ローカルファイルで環境変数を指定

プロジェクトのルートディレクトリに.nvmrcまたは.node-versionファイルを作成し、使用したいNode.jsのバージョンを記述します。

.nvmrc または .node-version

20.9.0

タグ:

• Cloudflare
• Node

Cloudflare PagesでNode.JS Compatibility Errorが出たとき

2025/03/20

Cloudflare PagesでNext.jsプロジェクトをデプロイする際に、Node.JS Compatibility Errorに遭遇して解決したので備忘録。

エラー内容

デプロイ後、以下のようなエラーメッセージがページに表示されました。

エラー内容

Node.JS Compatibility Error no nodejs_compat compatibility flag set

このエラーは、Cloudflare PagesプロジェクトでNode.jsの組み込みモジュールにアクセスできないことを示しています。

解決方法

Cloudflareダッシュボードから設定する方法

1. Cloudflareダッシュボードにログインします。
2. 「Workers & Pages」を選択し、該当するPagesプロジェクトを開きます。
3. 「設定」→「ランタイム」→「互換性フラグ」と進みます。
4. 「nodejs_compat」フラグを追加します。

注意: フラグは nodejs_compat とだけ入力します。引用符やその他の文字は不要です。

wrangler.tomlファイルで設定する方法

プロジェクトのルートディレクトリにある wrangler.toml ファイルに以下の行を追加します：

compatibility_flags = [ "nodejs_compat" ]

注意点

• Compatibility Flagsを設定した後は、変更を反映させるために再デプロイが必要です。
• 設定方法によっては、ダッシュボードの「Functions」オプションが見つからない場合があります。その場合は wrangler.toml ファイルでの設定をお試しください。

参考リンク

• Cloudflare Developers - Compatibility Flags
• Stack Overflow - Cloudflare Pages Node.JS Compatibility Error

このエラーに遭遇した際は、ぜひこの方法をお試しください。デプロイの成功をお祈りしています！

タグ:

• Cloudflare
• Node
• Next

古い投稿