先日、フロントエンド開発に関連する技術系記事をまとめてチェックできる 「TechDeck」 という Web サイトを Next.js + Tailwind CSS + いくつかの API + Vercel という組み合わせで作ってみましたという記事を書きました。
このサイトは Next.js で SSG (Static Site Generation / 静的サイト生成) していますが、公開するためのサーバを、前から一度使ってみたかった Vercel でやってみようということで、GitHub と連携し、main
ブランチへのプッシュによる Vercel への自動デプロイ、さらにカスタムドメインの設定と、記事データを一定時間ごとに更新するため、GitHub Actions を使用した定期的なビルド & デプロイの設定を行ってみました。
ここではその一連の設定について簡単にまとめておきたいと思います。
Vercel へのログインと利用料金
Vercel への基本的なデプロイ方法は非常に簡単で、管理画面上で必要な操作をするだけで誰でも Web サイトやアプリケーションを公開できるように考えられています。
Vercel のサインアップ画面 に進み、GitHub、GitLab、もしくは Bitbucket のアカウントでログインしてアカウントを連携すればすぐにはじめることができます。
料金プランは、個人的な非営利目的の使用に限定して無料で使用可能な 「Hobby」 プランに加え、有料の 「Pro」、「Enterprise」 プランが用意されていますが、Hobby プランでいわれている 「非営利目的の使用」 というのは、「Fair Use Policy」 内の 「Commercial Usage (商用利用)」 の項目に書かれていること 「以外」 ですね。
具体的には、
- Any method of requesting or processing payment from visitors of the site.
Web サイトの訪問者に支払いを要求したり、支払いを処理する行為 - Advertising the sale of a product or service.
製品やサービスの販売を宣伝する行為(要するに特定の製品・サービスの販促用 Web ページなど) - Affiliate linking as the primary purpose of the site.
Web サイトの主な目的がアフィリエイトリンクの場合
が 「商用利用」 であると定義されていますので、それ以外の Web サイトであれば、「Hobby」 プランが利用できます。
「Web サイトの主な目的がアフィリエイトリンクの場合」 という定義になっているので、例えば個人が趣味の Blog などを公開して (要するにその Blog の内容自体が主なコンテンツで) そこにちょこっとアフィリエイトリンクや Google AdSense などのような広告を貼り付ける程度であれば、商用利用とは見なされないと思われますが、同ページにも、「商用利用か判断に迷って心配な場合はサポートチームに問い合わせてね」 と書かれていますので、微妙だなという場合は聞いてみるとよいかと思います。
なお、Hobby プランには下記のような制約があります。
Hobby | Pro | Enterprise | |
---|---|---|---|
Deployments Created per Day (実行可能なデプロイ回数 / 1日) |
100 | 3000 | Custom |
Serverless Functions Created per Deployment (サーバーレス関数の数 / デプロイ毎) |
12 | - | - |
Serverless Function Execution Timeout (Seconds) (サーバーレス関数のタイムアウト(秒)) |
10 | 60 | 900 |
Proxied Request Timeout (Seconds) (プロキシタイムアウト(秒)) |
30 | 30 | 30 |
Deployments Created from CLI per Week (CLI から実行可能なデプロイ回数 / 1週間) |
2000 | 2000 | Custom |
Team Members per Team (チームメンバー / 1チーム) |
- | 10 | Custom |
Vercel Projects Connected per Git Repository (連携可能なリポジトリ数 / 1プロジェクト) |
3 | 10 | Custom |
Build Time per Deployment (Minutes) (ビルド実行時間 / デプロイ毎) |
45 | 45 | 45 |
Pro プランにしても月額 20ドル (1メンバーあたり) ですので、本格的に利用したい場合や、Web サイトからのマネタイズなどを視野に入れている場合は Pro プランを契約しておくとよいと思われます。
今回は、Hobby プランを利用している前提で話を進めます。
Vercel へのデプロイ手順
今回は、Vercel と GitHub 上にあるリポジトリと連携して、main
ブランチへのプッシュごとに自動的にデプロイされるように設定するのと、GitHub Actions を設定して、cron による定期的なデプロイ処理を実行するというところまでやっていきます。なお、デプロイする先は Vercel の本番環境を対象にします。
あと、おまけとして、Vercel でのカスタムドメインを設定するところも簡単に触れます。
Git リポジトリとの連携
GitHub アカウントで Vercel にサインアップすると、「Import Git Repository」 として、アカウント連携した GitHub アカウントの管理下にあるリポジトリが選択可能になっていると思います。
アカウントを選択して進むと、リポジトリ選択画面に進みますので、今回デプロイする TechDeck のリポジトリを選択して進みます。
リポジトリを選択したら、「Import」 で次のステップに進みましょう。
Hobby プランを利用しているので、「Select Vercel Scope」 の画面では、パーソナルアカウントに紐付けます。
使用しているフレームワークなどは自動的に検出してくれますし、package.json の中身をみて、「Build and Output Setting」 も適切に値が入ると思いますので、基本的にはそのままで問題ないと思います。
環境変数の設定
.env
ファイルも GitHub リポジトリにプッシュしていて、環境変数がそこから読み込める場合、あるいは環境変数自体使ってないですという場合はこれで 「Deploy」 ボタンを押せば Web サイトが公開されるんですが、.env
ファイルは GitHub リポジトリにはプッシュしてないですよという場合は、この画面で必要な環境変数を設定可能です。「Environment Variables」 の設定を開いて環境変数を登録しましょう。
基本的には .env
ファイルにおける Key=Value
の組み合わせを、それぞれ Name / Value に入れておけば問題ありません。どの環境で使用するかも設定できますので、例えば本番環境とプレビュー環境で別々の環境変数を使用したい場合はそれぞれ登録することもできます。
今回の TechDeck で実際に登録した環境変数は下記のような感じです。
設定に問題がなければ、「Deploy」 ボタンを押すことで、Web サイトが公開されます。
カスタムドメインの設定
Vercel でデプロイすると、自動的に example.vercel.app
という形でドメインが割り当てられるのですが、これを独自ドメインでもアクセスできるようにします。独自ドメインは取得済みという前提で進めます。
プロジェクトの設定画面に進み、「Domains (ドメイン)」 設定に進みましょう。ここで使用したいドメインを入力し、「Add」 します。すると、リダイレクト設定はどうするかを聞かれますので、好みの方法を選択しましょう。
www.example.com
を追加して、example.com
から転送example.com
を追加して、www.example.com
から転送example.com
を追加 (リダイレクトはしない / つまりwww.example.com
は設定しない)
ドメインの追加が完了すると、ネームサーバの設定方法が表示されますので、ドメインの管理側で設定を行います。
設定が正しく反映されると、Vercel のコンソール側でも 「Valid Configuration」 と表示され、カスタムドメインでのアクセスが可能になります。 SSL の設定などもすべて自動でやってくれるので手間いらずです。
Vercel への定期デプロイを設定
前のセクションまでの設定が終われば、プロジェクトの main
ブランチにプッシュするだけで自動的にビルド / デプロイが行われるのですが、今回は、一定時間ごとに自動的にデプロイして、掲載されている記事を最新の状態に更新していきたいため、定期デプロイの仕組みを作ります。
作るといっても、GitHub Actions で比較的簡単にできますので、その手順を以下にまとめます。
Vercel CLI を使用できるようにする
まずは、対象となるプロジェクトで、Vercel CLI を使用できるようにします。
下記のコマンドを実行し、Vercel CLI をインストールしましょう。
npm i -g vercel # or with yarn yarn global add vercel
Vercel でデプロイしているプロジェクトのルートディレクトリに移動し、
vercel
コマンドを実行すると、ルートディレクトリに .vercel/project.json
というファイルが生成されます。
内容的には下記のようになっていると思いますが、
{ "projectId":"*******", "orgId":"*******" }
projectId
と orgId
をメモしておきましょう。
GitHub Actions の設定
次に、Vercel の管理画面にアクセスし、アカウントの設定 (パソコンのブラウザで閲覧している場合は画面右上の自分のアイコンから移動できます) から、「Tokens」 と進んで、「Create」 をクリックし、トークンを発行しておきます。これも忘れずにメモりましょう。
発行したトークン、そして、projectId
と orgId
の内容をメモしたら、GitHub にログインします。
そして、リポジトリの設定メニューから、「Secrets」 の設定に進み、それぞれ下記のように設定します (Name はわかりやすいものであれば下記と同じである必要はありません)。
Name | Value |
---|---|
VERCEL_TOKEN | 生成したトークンの値 |
VERCEL_ORG_ID | orgId の値 |
VERCEL_PROJECT_ID | projectId の値 |
.yml ファイルの作成と実行
次に、プロジェクトのルートディレクトリに、.github/workflows
という構成でディレクトリを作成し、その中に、deploy_website.yml
ファイルを新規作成します。
deploy_website.yml
ファイルの中身は下記の通りです。
name: deploy website on: workflow_dispatch: inputs: ref: description: branch|tag|SHA to checkout default: "main" required: true schedule: - cron: "*/30 * * * *" jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 with: ref: ${{ github.event.inputs.ref }} - uses: amondnet/vercel-action@v20 with: vercel-token: ${{ secrets.VERCEL_TOKEN }} vercel-org-id: ${{ secrets.VERCEL_ORG_ID}} vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID}} vercel-args: "--prod" working-directory: ./
Vercel へのデプロイに関しては、amondnet/vercel-action を利用させて頂きます。
やりたいことは、cron で 30 分おきに Vercel へのデプロイ処理を実行するということなので、内容自体はシンプル。vercel-args: "--prod"
を指定することでデプロイ対象が本番環境になります。このオプションがない場合は、プレビュー環境にデプロイが行われる形になります。
deploy_website.yml
ファイルをリポジトリにプッシュすると、GitHub リポジトリの Actions タブにワークフローとして登録されると思いますので、実際に処理を実行してみましょう。
問題なければ上記のように処理が実行され、エラーなく完了するとその旨が表示されます。エラーがある場合はログに書き出されますので、内容を確認して修正します。
同時に Vercel のダッシュボード上でも、プロジェクトの 「Deployments」 からデプロイ履歴が確認できますので、エラーなどが出ていないかを確認、問題なければこれで 30 分おきの自動デプロイが実行されるようになりますので、しばらく経ってから Vercel のダッシュボードで正しくデプロイが行われているか確認すればよいでしょう。
cron によるデプロイの実行間隔は cron: "*/30 * * * *"
の部分で設定できますが、前述したとおり、Hobby プランの場合は 1 日あたりのデプロイ回数が 100 回までと決まっていますので、あまり高頻度で実行するのは避けましょう。頻繁に更新されなくてよい場合は 1 日に 1 回実行するみたいな感じでもよいかもしれません。
ちなみに、GitHub Actions におけるワークフローの実行頻度は、最短で 5 分ごとに 1 回となっています。
ということで、Vercel と GitHub Actions を使用して、定期的なデプロイを行う方法でした。通常の Web サイトであれば、ページの内容を更新したときだけ手動でデプロイすればよいので定期デプロイの仕組みは不要かと思いますが、今回私が作った、TechDeck のように、外部で更新されている情報を定期的に取得して、常にサイトの内容を最新の状態に保ちたい、みたいな場合には、この定期デプロイの仕組みは役に立つかと思います。