デプロイメント
本番環境用のウェブサイトの静的ファイルをビルドするには、以下のコマンドを実行します。
- npm
- Yarn
- pnpm
npm run build
yarn build
pnpm run build
完了すると、静的ファイルがbuild
ディレクトリに生成されます。
Docusaurusの役割は、サイトをビルドし、build
ディレクトリに静的ファイルを生成することだけです。
これらの静的ファイルをどのようにホストするかは、ユーザーの責任となります。
Vercel、GitHub Pages、Netlify、Render、Surgeなどの静的サイトホスティングサービスにサイトをデプロイできます。
Docusaurusサイトは静的にレンダリングされるため、一般的にJavaScriptなしでも動作します!
設定
ルーティングを最適化し、正しい場所からファイルを提供するには、docusaurus.config.js
で以下のパラメーターが必要です。
名前 | 説明 |
---|---|
url | サイトのURL。https://my-org.com/my-project/ にデプロイされたサイトの場合、url はhttps://my-org.com/ です。 |
baseUrl | プロジェクトのベースURL(末尾にスラッシュが必要)。https://my-org.com/my-project/ にデプロイされたサイトの場合、baseUrl は/my-project/ です。 |
ローカルでのビルドテスト
本番環境にデプロイする前に、ローカルでビルドをテストすることが重要です。Docusaurusは、そのためのdocusaurus serve
コマンドを提供しています。
- npm
- Yarn
- pnpm
npm run serve
yarn serve
pnpm run serve
デフォルトでは、サイトはhttp://localhost:3000/
でロードされます。
末尾のスラッシュの設定
Docusaurusには、URL/リンクと出力されるファイル名のパターンをカスタマイズできるtrailingSlash
設定があります。
デフォルト値は通常問題ありません。しかし、各静的ホスティングプロバイダーは**異なる動作**を示し、まったく同じサイトをさまざまなホストにデプロイすると、異なる結果になる可能性があります。ホストによっては、この設定を変更することが役立つ場合があります。
ホストの動作を理解し、trailingSlash
を適切に設定するには、slorber/trailing-slash-guideを参照してください。
環境変数の使用
機密性の高い情報を環境変数に格納することは一般的です。しかし、通常のDocusaurusウェブサイトでは、docusaurus.config.js
ファイルがNode.js環境への唯一のインターフェースであり(アーキテクチャの概要を参照)、それ以外のもの(MDXページ、Reactコンポーネントなど)はクライアントサイドであり、process
グローバル変数に直接アクセスできません。この場合、customFields
を使用して、環境変数をクライアントサイドに渡すことができます。
// If you are using dotenv (https://www.npmjs.com/package/dotenv)
import 'dotenv/config';
export default {
title: '...',
url: process.env.URL, // You can use environment variables to control site specifics as well
customFields: {
// Put your custom environment here
teamEmail: process.env.EMAIL,
},
};
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
export default function Home() {
const {
siteConfig: {customFields},
} = useDocusaurusContext();
return <div>Contact us through {customFields.teamEmail}!</div>;
}
ホスティングプロバイダーの選択
一般的なホスティングオプションをいくつか紹介します。
- 自己ホスティング(Apache2やNginxなどのHTTPサーバーを使用)。
- Jamstackプロバイダー(例:NetlifyとVercel)。ここではこれらを参考として使用しますが、同じロジックは他のプロバイダーにも適用できます。
- GitHub Pages(定義上、これもJamstackですが、ここでは別途比較します)。
どれを選択するか迷ったら、以下の質問を検討してください。
このためにどれだけのリソース(お金、時間など)を投資できますか?
- 🔴 自己ホスティングには、ネットワーク、Linux、Webサーバー管理の経験が必要です。最も難しいオプションであり、成功させるためには最も多くの時間が必要です。費用面では、クラウドサービスはほとんど無料ではなく、オンプレミスサーバーの購入/デプロイはさらに高額になる可能性があります。
- 🟢 Jamstackプロバイダーは、ほぼ瞬時に動作するウェブサイトを設定でき、簡単に構成できるサーバーサイドリダイレクトなどの機能を提供します。多くのプロバイダーは、無料プランでもほとんど到達しないような寛大なビルド時間クォータを提供しています。ただし、無料プランには制限があり、その制限に達したら支払う必要があります。詳細については、プロバイダーの価格表を確認してください。
- 🟡 GitHub Pagesのデプロイワークフローは、設定が面倒です。(証拠:GitHub Pagesへのデプロイの長さをご覧ください!)ただし、このサービス(ビルドとデプロイを含む)は、パブリックリポジトリでは常に無料であり、動作させるための詳細な手順を用意しています。
どの程度のサーバーサイドのカスタマイズが必要ですか?
- 🟢 自己ホスティングでは、サーバー全体の構成にアクセスできます。リクエストURLに基づいて異なるコンテンツを提供するように仮想ホストを設定したり、複雑なサーバーサイドリダイレクトを実行したり、認証を実装したりすることができます。多くのサーバーサイド機能が必要な場合は、ウェブサイトを自己ホストしてください。
- 🟡 Jamstackは通常、いくつかのサーバーサイド設定(例:URLフォーマット(末尾のスラッシュ)、サーバーサイドリダイレクトなど)を提供します。
- 🔴 GitHub Pagesは、HTTPSの適用とCNAMEレコードの設定以外、サーバーサイドの設定を公開していません。
共同作業に適したデプロイワークフローが必要ですか?
- 🟡 自己ホスト型サービスはNetlifyなどの継続的デプロイ機能を利用できますが、より多くの作業が必要です。通常、特定の担当者をデプロイ管理に割り当て、他の2つのオプションとは異なり、ワークフローはそれほどgitベースではありません。
- 🟢 NetlifyとVercelは、プルリクエストごとにデプロイプレビューを提供しており、チームが本番環境にマージする前に作業を確認するのに役立ちます。また、デプロイへのアクセス権限が異なるメンバーでチームを管理することもできます。
- 🟡 GitHub Pagesは、複雑でない方法ではデプロイプレビューを実行できません。1つのリポジトリは、1つのサイトデプロイメントのみに関連付けることができます。一方、サイトのデプロイへの書き込みアクセス権を持つユーザーを制御できます。
万能な解決策はありません。選択を行う前に、ニーズとリソースを比較検討する必要があります。
自己ホスティング
Docusaurusは、docusaurus serve
を使用して自己ホストできます。--port
と--host
を使用してポートとホストを変更します。
- npm
- Yarn
- pnpm
npm run serve -- --build --port 80 --host 0.0.0.0
yarn serve --build --port 80 --host 0.0.0.0
pnpm run serve --build --port 80 --host 0.0.0.0
静的ホスティングプロバイダー/CDNと比較して、最適なオプションではありません。
以降のセクションでは、いくつかの一般的なホスティングプロバイダーと、Docusaurusサイトを最も効率的にデプロイするための設定方法を紹介します。Docusaurusはこれらのサービスと提携しておらず、この情報は便宜上提供されているものです。一部の記述はサードパーティによって提供されており、最新のAPIの変更が反映されていない場合があります。古いコンテンツを見つけた場合は、PRを送信していただけます。
ベストエフォートベースでのみコンテンツを提供できるため、新しいホスティングオプションを追加するPRの受付を停止しました。ただし、独自のサイト(ブログやプロバイダーの公式ウェブサイトなど)に記述を公開し、リンクの追加を依頼することは可能です。
Netlifyへのデプロイ
DocusaurusサイトをNetlifyにデプロイするには、まず以下のオプションが正しく設定されていることを確認してください。
export default {
url: 'https://docusaurus-2.netlify.app', // Url to your site with no trailing slash
baseUrl: '/', // Base directory of your site relative to your repo
// ...
};
次に、Netlifyでサイトを作成します。
サイトを設定する際に、ビルドコマンドとディレクトリを次のように指定します。
- ビルドコマンド:
npm run build
- 公開ディレクトリ:
build
これらのビルドオプションを設定しなかった場合でも、サイト作成後に「サイト設定」->「ビルドとデプロイ」に移動できます。
上記のオプションで適切に設定されると、サイトはデプロイされ、デプロイブランチ(デフォルトはmain
)にマージされると自動的に再デプロイされます。
一部のDocusaurusサイトでは、docs
フォルダがwebsite
フォルダの外側に配置されています(おそらく以前のDocusaurus v1サイト)。
repo # git root
├── docs # MD files
└── website # Docusaurus root
website
フォルダをNetlifyのベースディレクトリとして使用する場合、docs
フォルダを更新してもNetlifyはビルドをトリガーしません。この場合は、カスタムignore
コマンドを設定する必要があります。
[build]
ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF . ../docs/"
デフォルトで、NetlifyはDocusaurusのURLに末尾のスラッシュを追加します。
小文字のURL、不要なリダイレクト、および404エラーを防ぐために、Netlifyの設定「Post Processing > Asset Optimization > Pretty Urls」を無効にすることをお勧めします。
非常に注意してください:「資産の最適化を無効にする」グローバルチェックボックスは壊れており、実際には「Pretty URLs」設定を無効にしません。必ず個別にチェックを外してください。
Netlifyの「Pretty Urls」設定を有効にしたい場合は、trailingSlash
のDocusaurus設定を適切に調整してください。
詳細については、slorber/trailing-slash-guideを参照してください。
Vercelへのデプロイ
DocusaurusプロジェクトをVercelにデプロイすると、パフォーマンスと使いやすさの点でさまざまなメリットが得られます。
VercelのGit統合を使用してDocusaurusプロジェクトをデプロイするには、Gitリポジトリにプッシュされていることを確認してください。
インポートフローを使用して、プロジェクトをVercelにインポートします。インポート時に、関連するすべてのオプションが事前に設定されていますが、これらのオプションを変更することもできます。
プロジェクトがインポートされると、ブランチへの後続のプッシュによってプレビューデプロイメントが生成され、本番ブランチ(通常は「main」または「master」)に加えられたすべての変更は、本番デプロイメントになります。
GitHub Pagesへのデプロイ
Docusaurusは、すべてのGitHubリポジトリで無料で提供されるGitHub Pagesに簡単に公開する方法を提供します。
概要
通常、公開プロセスには2つのリポジトリ(少なくとも2つのブランチ)が関与します。ソースファイルを含むブランチと、GitHub Pagesで提供されるビルド出力を含むブランチです。以降のチュートリアルでは、それぞれ「ソース」と「デプロイ」と呼びます。
各GitHubリポジトリには、GitHub Pagesサービスが関連付けられています。デプロイリポジトリがmy-org/my-project
(my-org
は組織名またはユーザー名)と呼ばれる場合、デプロイされたサイトはhttps://my-org.github.io/my-project/
に表示されます。デプロイリポジトリがmy-org/my-org.github.io
(組織GitHub Pagesリポジトリ)と呼ばれる場合、サイトはhttps://my-org.github.io/
に表示されます。
GitHub Pagesでカスタムドメインを使用する場合は、static
ディレクトリにCNAME
ファイルを作成します。static
ディレクトリ内のものはすべて、デプロイのためにbuild
ディレクトリのルートにコピーされます。カスタムドメインを使用する場合は、baseUrl: '/projectName/'
からbaseUrl: '/'
に戻し、url
をカスタムドメインに設定できます。
詳細については、GitHub Pagesのドキュメントユーザー、組織、およびプロジェクトページを参照してください。
GitHub Pagesは、デプロイ準備完了ファイル(docusaurus build
からの出力)をデフォルトブランチ(master
/main
、通常)またはgh-pages
ブランチから、ルートまたは/docs
フォルダから取得します。これはリポジトリの「設定 > Pages」で設定できます。このブランチは「デプロイブランチ」と呼ばれます。
ソースブランチからデプロイブランチへのサイトのデプロイを1つのコマンドで実行できるdocusaurus deploy
コマンドを提供しています。クローン、ビルド、コミットを行います。
docusaurus.config.js
の設定
最初に、docusaurus.config.js
を変更し、以下のパラメーターを追加します。
名前 | 説明 |
---|---|
organizationName | デプロイリポジトリを所有するGitHubユーザーまたは組織。 |
projectName | デプロイリポジトリの名前。 |
deploymentBranch | デプロイブランチの名前。組織以外のGitHub Pagesリポジトリ(projectName が.github.io で終わらない場合)では、デフォルトで'gh-pages' になります。それ以外の場合は、設定フィールドまたは環境変数として明示的に指定する必要があります。 |
これらのフィールドには、優先順位が高い対応する環境変数(ORGANIZATION_NAME
、PROJECT_NAME
、DEPLOYMENT_BRANCH
)もあります。
GitHub PagesはデフォルトでDocusaurusのURLに末尾のスラッシュを追加します。trailingSlash
設定(true
またはfalse
、undefined
ではない)を設定することをお勧めします。
例
export default {
// ...
url: 'https://endiliey.github.io', // Your website URL
baseUrl: '/',
projectName: 'endiliey.github.io',
organizationName: 'endiliey',
trailingSlash: false,
// ...
};
デフォルトでは、GitHub Pagesは公開されたファイルをJekyllで処理します。Jekyllは_
で始まるファイルをすべて破棄するため、static
ディレクトリに.nojekyll
という名前の空のファイルを追加してJekyllを無効にすることをお勧めします。
環境設定
名前 | 説明 |
---|---|
USE_SSH | GitHubリポジトリへの接続に、デフォルトのHTTPSではなくSSHを使用する場合はtrue に設定します。ソースリポジトリのURLがSSH URL(例:[email protected]:facebook/docusaurus.git )の場合、USE_SSH はtrue と推測されます。 |
GIT_USER | デプロイリポジトリへのプッシュアクセス権を持つGitHubアカウントのユーザー名。自分のリポジトリの場合は、通常はGitHubのユーザー名になります。SSHを使用していない場合に必要で、それ以外の場合は無視されます。 |
GIT_PASS | 非対話型デプロイ(例:継続的デプロイ)を容易にするため、gitユーザー(GIT_USER で指定)のパーソナルアクセストークン。 |
CURRENT_BRANCH | ソースブランチ。通常、ブランチはmain またはmaster ですが、gh-pages 以外の任意のブランチにすることができます。この変数に何も設定されていない場合、docusaurus deploy が呼び出された現在のブランチが使用されます。 |
GIT_USER_NAME | デプロイリポジトリにプッシュする際に使用するgit config user.name の値。 |
GIT_USER_EMAIL | デプロイリポジトリにプッシュする際に使用するgit config user.email の値。 |
GitHub Enterpriseインストールはgithub.comと同じように動作します。組織のGitHub Enterpriseホストを環境変数として設定するだけです。
名前 | 説明 |
---|---|
GITHUB_HOST | GitHub Enterpriseサイトのドメイン名。 |
GITHUB_PORT | GitHub Enterpriseサイトのポート。 |
デプロイ
最後に、GitHub Pagesにサイトをデプロイするには、以下を実行します。
- Bash
- Windows
- PowerShell
GIT_USER=<GITHUB_USERNAME> yarn deploy
cmd /C "set "GIT_USER=<GITHUB_USERNAME>" && yarn deploy"
cmd /C 'set "GIT_USER=<GITHUB_USERNAME>" && yarn deploy'
2021年8月以降、GitHubでは、パスワードの代わりにパーソナルアクセストークンを使用するすべてのコマンドラインサインインが必要です。GitHubでパスワードの入力を求められたら、代わりにPATを入力してください。詳細については、GitHubのドキュメントを参照してください。
または、SSH(USE_SSH=true
)を使用してログインできます。
GitHub Actionsを使用したデプロイのトリガー
GitHub Actionsを使用すると、リポジトリ内でソフトウェア開発ワークフローを自動化、カスタマイズ、および実行できます。
以下のワークフローの例では、ウェブサイトのソースがリポジトリのmain
ブランチ(ソースブランチはmain
)にあり、公開ソースがカスタムGitHub Actionsワークフローを使用した公開用に設定されていることを前提としています。
目標は次のとおりです。
main
に新しいプルリクエストが作成されると、サイトが正常にビルドされることを確認するアクションがあり、実際にはデプロイされません。このジョブはtest-deploy
と呼ばれます。- プルリクエストが
main
ブランチにマージされた場合、または誰かがmain
ブランチに直接プッシュした場合、ビルドされてGitHub Pagesにデプロイされます。このジョブはdeploy
と呼ばれます。
GitHub Actionsを使用してドキュメントをデプロイするための2つの方法があります。デプロイリポジトリの場所に基づいて、以下の関連するタブを選択してください。
- ソースリポジトリとデプロイリポジトリは同じリポジトリです。
- デプロイリポジトリは、ソースとは異なるリモートリポジトリです。このシナリオの手順では、公開ソースが
gh-pages
ブランチであることを前提としています。
- 同じ
- リモート
同じワークフローファイルに両方のジョブを定義できますが、元のdeploy
ワークフローは常にPRチェックスイートの状態にスキップ済みとしてリストされます。これは実際の状態を表しておらず、レビュープロセスに価値をもたらしません。そのため、代わりに別々のワークフローとして管理することを提案します。
GitHubアクションファイル
以下の2つのワークフローファイルを追加します。
これらのファイルは、Yarn を使用していることを前提としています。npm を使用している場合は、cache: yarn
、yarn install --frozen-lockfile
、yarn build
をそれぞれ cache: npm
、npm ci
、npm run build
に変更してください。
Docusaurus プロジェクトがリポジトリのルートにない場合は、デフォルトの作業ディレクトリ を設定し、パスを適宜調整する必要がある場合があります。
name: Deploy to GitHub Pages
on:
push:
branches:
- main
# Review gh actions docs if you want to further define triggers, paths, etc
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on
jobs:
build:
name: Build Docusaurus
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 18
cache: yarn
- name: Install dependencies
run: yarn install --frozen-lockfile
- name: Build website
run: yarn build
- name: Upload Build Artifact
uses: actions/upload-pages-artifact@v3
with:
path: build
deploy:
name: Deploy to GitHub Pages
needs: build
# Grant GITHUB_TOKEN the permissions required to make a Pages deployment
permissions:
pages: write # to deploy to Pages
id-token: write # to verify the deployment originates from an appropriate source
# Deploy to the github-pages environment
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
name: Test deployment
on:
pull_request:
branches:
- main
# Review gh actions docs if you want to further define triggers, paths, etc
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on
jobs:
test-deploy:
name: Test deployment
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 18
cache: yarn
- name: Install dependencies
run: yarn install --frozen-lockfile
- name: Test build website
run: yarn build
クロスリポジトリのパブリッシュは、権限チェック付きで別のリポジトリにプッシュする必要があるため、設定がより困難です。認証には SSH を使用します。
- 新しい SSH キー を生成します。この SSH キーは CI で使用されるため、パスフレーズを入力しないようにしてください。
- デフォルトでは、公開キーは
~/.ssh/id_rsa.pub
に作成されます。それ以外の場合は、前の手順で指定した名前を使用して、キーを GitHub デプロイキー に追加します。 pbcopy < ~/.ssh/id_rsa.pub
でキーをクリップボードにコピーし、デプロイキー としてデプロイメントリポジトリに貼り付けます。コマンドラインで動作しない場合は、ファイルの内容をコピーしてください。「書き込みアクセスを許可する」チェックボックスをオンにしてから、デプロイキーを保存してください。- Docusaurus がデプロイを実行できるように、GitHub シークレット として秘密キーが必要になります。
pbcopy < ~/.ssh/id_rsa
で秘密キーをコピーし、ソースリポジトリにGH_PAGES_DEPLOY
という名前で GitHub シークレットとして貼り付けます。コマンドラインで動作しない場合は、ファイルの内容をコピーしてください。シークレットを保存してください。- ドキュメントワークフローファイル を
.github/workflows/
に作成します。この例では、deploy.yml
です。
この時点で、以下の状態になっているはずです。
- GitHub シークレットとして秘密 SSH キーが設定されたソースリポジトリと、
- GitHub デプロイキーに公開 SSH キーが設定されたデプロイメントリポジトリ。
GitHub アクションファイル
[email protected]
をあなたの GitHub メールアドレスに、gh-actions
をあなたの名前に置き換えてください。
これらのファイルは、Yarn を使用していることを前提としています。npm を使用している場合は、cache: yarn
、yarn install --frozen-lockfile
、yarn build
をそれぞれ cache: npm
、npm ci
、npm run build
に変更してください。
name: Deploy to GitHub Pages
on:
pull_request:
branches: [main]
push:
branches: [main]
permissions:
contents: write
jobs:
test-deploy:
if: github.event_name != 'push'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 18
cache: yarn
- name: Install dependencies
run: yarn install --frozen-lockfile
- name: Test build website
run: yarn build
deploy:
if: github.event_name != 'pull_request'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 18
cache: yarn
- uses: webfactory/ssh-[email protected]
with:
ssh-private-key: ${{ secrets.GH_PAGES_DEPLOY }}
- name: Deploy to GitHub Pages
env:
USE_SSH: true
run: |
git config --global user.email "[email protected]"
git config --global user.name "gh-actions"
yarn install --frozen-lockfile
yarn deploy
サイトが正しくデプロイされない場合?
main ブランチにプッシュした後、サイトが目的の場所に公開されない場合(たとえば、「ここに GitHub Pages サイトはありません」と表示される場合、またはリポジトリの README.md ファイルが表示される場合)、次の手順を試してください。
- 約3分待ってから更新してください。GitHub Pages が新しいファイルを取得するまでに数分かかります。
- リポジトリのランディングページで、最新のコミットのタイトルの横に小さな緑色のチェックマークが表示されていることを確認してください。これは CI が成功したことを示しています。バツ印が表示されている場合は、ビルドまたはデプロイが失敗したことを意味し、ログを確認してデバッグ情報を調べる必要があります。
- チェックマークをクリックし、「GitHub Pages へのデプロイ」ワークフローが表示されていることを確認してください。「pages build and deployment / deploy」などの名前は GitHub のデフォルトのワークフローであり、カスタムデプロイワークフローがまったくトリガーされなかったことを示しています。YAML ファイルが
.github/workflows
フォルダーに配置され、トリガー条件が正しく設定されていることを確認してください(たとえば、デフォルトブランチが「main」ではなく「master」の場合は、on.push
プロパティを変更する必要があります)。 - リポジトリの設定 > Pages で、「ソース」(これはデプロイメントファイルのソースであり、私たちの用語における「ソース」とは異なります)が「gh-pages」+「/ (root)」に設定されていることを確認してください。これは、デプロイブランチとして
gh-pages
を使用しているためです。
カスタムドメインを使用している場合
- カスタムドメインを使用している場合は、正しい DNS レコードが設定されていることを確認してください。GitHub Pages のカスタムドメインの設定に関するドキュメント を参照してください。また、DNS の変更がインターネット全体に伝播するまでに最大 24 時間かかる場合があります。
Travis CI を使用したデプロイのトリガー
継続的インテグレーション(CI)サービスは通常、新しいコミットがソースコントロールにチェックインされるたびにルーチンタスクを実行するために使用されます。これらのタスクは、単体テストと統合テストの実行、ビルドの自動化、npm へのパッケージの公開、Web サイトへの変更のデプロイなど、あらゆる組み合わせを行うことができます。Web サイトのデプロイを自動化するために必要なことは、Web サイトが更新されるたびに yarn deploy
スクリプトを呼び出すだけです。次のセクションでは、人気の継続的インテグレーションサービスプロバイダーである Travis CI を使用してこれを行う方法について説明します。
- https://github.com/settings/tokens にアクセスして、新しい パーソナルアクセストークン を生成します。トークンを作成する際に、必要な権限を持つように
repo
スコープを付与します。 - GitHub アカウントを使用して、Travis CI アプリ をアクティブ化したいリポジトリに追加します。
- Travis CI ダッシュボードを開きます。URL は
https://travis-ci.com/USERNAME/REPO
のようになります。リポジトリのその他のオプション > 設定 > 環境変数
セクションに移動します。 - 新しく生成したトークンを値として持つ
GH_TOKEN
という名前の新しい環境変数を作成し、次にGH_EMAIL
(メールアドレス)とGH_NAME
(GitHub ユーザー名)を作成します。 - リポジトリのルートに
.travis.yml
を作成し、以下を記述します。
language: node_js
node_js:
- 18
branches:
only:
- main
cache:
yarn: true
script:
- git config --global user.name "${GH_NAME}"
- git config --global user.email "${GH_EMAIL}"
- echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
- yarn install
- GIT_USER="${GH_NAME}" yarn deploy
これで、新しいコミットが main
に追加されるたびに、Travis CI はテストスイートを実行し、すべてが合格すると、yarn deploy
スクリプトを介して Web サイトがデプロイされます。
Buddy を使用したデプロイのトリガー
Buddy は、ポータルを GitHub Pages を含むさまざまな環境に自動的にデプロイできる使いやすい CI/CD ツールです。
プロジェクトの選択したブランチに変更をプッシュするたびに、Web サイトの新しいバージョンを自動的にデプロイするパイプラインを作成するには、次の手順に従います。
- https://github.com/settings/tokens にアクセスして、新しい パーソナルアクセストークン を生成します。トークンを作成する際に、必要な権限を持つように
repo
スコープを付与します。 - Buddy アカウントにサインインして、新しいプロジェクトを作成します。
- Git ホスティングプロバイダーとして GitHub を選択し、Web サイトのコードを含むリポジトリを選択します。
- 左側のナビゲーションパネルを使用して、
パイプライン
ビューに切り替えます。 - 新しいパイプラインを作成します。名前を定義し、トリガーモードを
プッシュ時
に設定し、パイプラインの実行をトリガーするブランチを選択します。 Node.js
アクションを追加します。- アクションのターミナルに次のコマンドを追加します。
GIT_USER=<GH_PERSONAL_ACCESS_TOKEN>
git config --global user.email "<YOUR_GH_EMAIL>"
git config --global user.name "<YOUR_GH_USERNAME>"
yarn deploy
この単純なパイプラインを作成した後、選択したブランチにプッシュされた新しいコミットごとに、yarn deploy
を使用して Web サイトが GitHub Pages にデプロイされます。このガイド を読んで、Docusaurus の CI/CD パイプラインの設定についてさらに学習してください。
Azure Pipelines の使用
- まだ行っていない場合は、Azure Pipelines にサインアップしてください。
- 組織を作成します。組織内でプロジェクトを作成し、GitHub からリポジトリを接続します。
- https://github.com/settings/tokens にアクセスして、
repo
スコープを持つ新しい パーソナルアクセストークン を生成します。 - プロジェクトページ(
https://dev.azure.com/ORG_NAME/REPO_NAME/_build
のようになります)で、次のテキストを使用して新しいパイプラインを作成します。また、編集をクリックして、新しく生成したトークンを値として持つGH_TOKEN
という名前の新しい環境変数を作成し、次にGH_EMAIL
(メールアドレス)とGH_NAME
(GitHub ユーザー名)を作成します。それらをシークレットとしてマークすることを確認してください。または、リポジトリのルートにazure-pipelines.yml
という名前のファイルを追加することもできます。
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- checkout: self
persistCredentials: true
- task: NodeTool@0
inputs:
versionSpec: '18'
displayName: Install Node.js
- script: |
git config --global user.name "${GH_NAME}"
git config --global user.email "${GH_EMAIL}"
git checkout -b main
echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
yarn install
GIT_USER="${GH_NAME}" yarn deploy
env:
GH_NAME: $(GH_NAME)
GH_EMAIL: $(GH_EMAIL)
GH_TOKEN: $(GH_TOKEN)
displayName: Install and build
Drone の使用
- プロジェクトの デプロイキー になる新しい SSH キーを作成します。
- 秘密キーと公開キーに具体的な名前を付け、他の SSH キー を上書きしないようにします。
https://github.com/USERNAME/REPO/settings/keys
にアクセスし、新しく生成した公開キーを貼り付けることで、新しいデプロイキーを追加します。- Drone.io ダッシュボードを開き、ログインします。URL は
https://cloud.drone.io/USERNAME/REPO
のようになります。 - リポジトリをクリックし、リポジトリのアクティブ化をクリックし、新しく生成した秘密キーの値を使用して
git_deploy_private_key
という名前のシークレットを追加します。 - リポジトリのルートに
.drone.yml
を作成し、以下のテキストを記述します。
kind: pipeline
type: docker
trigger:
event:
- tag
- name: Website
image: node
commands:
- mkdir -p $HOME/.ssh
- ssh-keyscan -t rsa github.com >> $HOME/.ssh/known_hosts
- echo "$GITHUB_PRIVATE_KEY" > "$HOME/.ssh/id_rsa"
- chmod 0600 $HOME/.ssh/id_rsa
- cd website
- yarn install
- yarn deploy
environment:
USE_SSH: true
GITHUB_PRIVATE_KEY:
from_secret: git_deploy_private_key
これで、新しいタグを GitHub にプッシュするたびに、このトリガーによって Drone CI ジョブが開始され、Web サイトが公開されます。
Flightcontrol へのデプロイ
Flightcontrol は、Git リポジトリから直接 Web アプリを AWS Fargate に自動的にビルドしてデプロイするサービスです。従来の PaaS の制限を受けることなく、インフラストラクチャの検査と変更を自由に実行できます。
まずは、Flightcontrolの段階的なDocusaurusガイドに従って始めましょう。
Koyebへのデプロイ
Koyebは、開発者フレンドリーなサーバーレスプラットフォームで、グローバルにアプリをデプロイできます。このプラットフォームを使用すると、Gitベースのデプロイ、ネイティブな自動スケーリング、グローバルエッジネットワーク、組み込みのサービスメッシュとディスカバリーを備えたDockerコンテナ、ウェブアプリ、APIをシームレスに実行できます。KoyebのDocusaurusデプロイガイドを参照して開始してください。
Renderへのデプロイ
Renderは、完全に管理されたSSL、カスタムドメイン、グローバルCDN、Gitリポジトリからの継続的な自動デプロイを備えた無料の静的サイトホスティングを提供しています。RenderのDocusaurusデプロイガイドに従って、数分で開始できます。
Qoveryへのデプロイ
Qoveryは、AWS、Digital Ocean、Scalewayアカウント上で動作するフルマネージドクラウドプラットフォームで、静的サイト、バックエンドAPI、データベース、cronジョブ、その他のすべてのアプリを1つの場所にホストできます。
- Qoveryアカウントを作成します。まだアカウントをお持ちでない場合は、Qoveryダッシュボードにアクセスしてアカウントを作成してください。
- プロジェクトを作成します。
- 「プロジェクトの作成」をクリックして、プロジェクト名を入力します。
- 「次へ」をクリックします。
- 新しい環境を作成します。
- 「環境の作成」をクリックして、名前(例:ステージング、本番)を入力します。
- アプリケーションを追加します。
- 「アプリケーションの作成」をクリックし、名前を入力して、Docusaurusアプリが配置されているGitHubまたはGitLabリポジトリを選択します。
- メインブランチ名とルートアプリケーションパスを定義します。
- 「作成」をクリックします。アプリケーションが作成された後
- アプリケーションの設定に移動します。
- ポートを選択します。
- Docusaurusアプリケーションで使用されているポートを追加します。
- デプロイ
- あとは、アプリケーションに移動して「デプロイ」をクリックするだけです。
以上です。ステータスを確認し、アプリがデプロイされるまで待ちます。ブラウザでアプリケーションを開くには、アプリケーションの概要で「アクション」と「開く」をクリックします。
Hostmanへのデプロイ
Hostmanを使用すると、静的ウェブサイトを無料でホストできます。Hostmanはすべてを自動化するため、リポジトリを接続してこれらの簡単な手順に従うだけです。
-
サービスを作成します。
- Docusaurus静的ウェブサイトをデプロイするには、ダッシュボードの左上隅にある「作成」をクリックし、「フロントエンドアプリまたは静的ウェブサイト」を選択します。
-
デプロイするプロジェクトを選択します。
-
GitHub、GitLab、またはBitbucketアカウントでHostmanにログインしている場合、プライベートなプロジェクトを含むプロジェクトのリポジトリが表示されます。
-
デプロイするプロジェクトを選択します。プロジェクトファイルを含むディレクトリ(例:
website
)が含まれている必要があります。 -
別のリポジトリにアクセスするには、「別のリポジトリを接続」をクリックします。
-
Gitアカウントの資格情報を使用してログインしなかった場合は、ここで必要なアカウントにアクセスし、プロジェクトを選択できます。
-
-
ビルド設定を構成します。
-
次に、「ウェブサイトのカスタマイズ」ウィンドウが表示されます。フレームワークのリストから「静的ウェブサイト」オプションを選択します。
-
「アプリを含むディレクトリ」は、ビルド後にプロジェクトファイルを含むディレクトリを指します。手順2でウェブサイトの内容(または
my_website
)ディレクトリを含むリポジトリを選択した場合は、空のままにしておくことができます。 -
Docusaurusの標準ビルドコマンドは次のとおりです。
- npm
- Yarn
- pnpm
npm run build
yarn build
pnpm run build
-
必要に応じてビルドコマンドを変更できます。
&&
で区切られた複数のコマンドを入力できます。
-
-
デプロイ。
-
「デプロイ」をクリックしてビルドプロセスを開始します。
-
開始されると、デプロイログが表示されます。コードに問題がある場合、問題の原因を指定する警告またはエラーメッセージがログに表示されます。通常、ログには必要なすべてのデバッグデータが含まれています。
-
デプロイが完了すると、メール通知を受け取り、ログエントリも表示されます。完了しました!プロジェクトの準備ができました。
-
Surgeへのデプロイ
Surgeは静的ウェブホスティングプラットフォームで、コマンドラインから数秒でDocusaurusプロジェクトをデプロイできます。Surgeへのプロジェクトのデプロイは簡単で無料です(カスタムドメインとSSL証明書を含む)。
次の手順に従って、Surgeを使用して数秒でアプリをデプロイします。
- まず、次のコマンドを実行してnpmを使用してSurgeをインストールします。
- npm
- Yarn
- pnpm
npm install -g surge
yarn global add surge
pnpm add -g surge
- プロジェクトのルートディレクトリで本番環境用のサイトの静的ファイルをビルドするには、次のコマンドを実行します。
- npm
- Yarn
- pnpm
npm run build
yarn build
pnpm run build
- 次に、プロジェクトのルートディレクトリ内でこのコマンドを実行します。
surge build/
Surgeの初回ユーザーには、コマンドラインからアカウントを作成するように促されます(1回のみ発生します)。
公開するサイトがbuild
ディレクトリにあることを確認します。ランダムに生成されたサブドメイン*.surge.sh サブドメイン
が常に与えられます(編集できます)。
ドメインの使用
ドメイン名をお持ちの場合は、次のコマンドを使用してサイトをデプロイできます。
surge build/ your-domain.com
選択した方法に応じて、サイトはsubdomain.surge.sh
またはyour-domain.com
で無料でデプロイされます。
CNAMEファイルの設定
次のコマンドを使用して、将来のデプロイのためにドメインをCNAMEファイルに保存します。
echo subdomain.surge.sh > CNAME
将来、surge
コマンドを使用して他の変更をデプロイできます。
Stormkitへのデプロイ
静的ウェブサイト、シングルページアプリケーション(SPA)、サーバーレス関数のデプロイプラットフォームであるStormkitにDocusaurusプロジェクトをデプロイできます。詳細な手順については、このガイドを参照してください。
QuantCDNへのデプロイ
- Quant CLIをインストールします。
- サインアップしてQuantCDNアカウントを作成します。
quant init
を使用してプロジェクトを初期化し、資格情報を入力します。quant init
- サイトをデプロイします。
quant deploy
QuantCDNへのデプロイの詳細な例とユースケースについては、ドキュメントとブログを参照してください。
Layer0へのデプロイ
Layer0は、ヘッドレスフロントエンドの開発、デプロイ、プレビュー、実験、監視、実行を行うオールインワンプラットフォームです。大規模で動的なウェブサイトと、EdgeJS(JavaScriptベースのコンテンツ配信ネットワーク)、予測プリフェッチ、パフォーマンス監視による最高のパフォーマンスに重点を置いています。Layer0は無料プランを提供しています。Layer0のDocusaurusデプロイガイドに従って、数分で開始できます。
Cloudflare Pagesへのデプロイ
Cloudflare Pagesは、フロントエンド開発者が協力してウェブサイトをデプロイするためのJamstackプラットフォームです。この記事に従って、数分で開始できます。
Azure Static Web Appsへのデプロイ
Azure Static Web Appsは、コードリポジトリからAzureにフルスタックウェブアプリを自動的にビルドおよびデプロイするサービスであり、CI/CDの開発者エクスペリエンスを簡素化します。Static Web Appsは、ウェブアプリケーションの静的アセットと動的(API)エンドポイントを分離します。静的アセットはグローバルに分散されたコンテンツサーバーから提供されるため、近くのサーバーを使用してクライアントがファイルをより高速に取得できます。動的APIは、イベント駆動型の関数ベースのアプローチを使用するサーバーレスアーキテクチャでスケーリングされるため、よりコスト効率が高く、オンデマンドでスケーリングされます。このステップバイステップガイドに従って、数分で開始できます。
Kinstaへのデプロイ
Kinsta Static Site Hostingを使用すると、最大100個の静的サイトを無料でデプロイできます。カスタムドメインとSSL、月間100GBの帯域幅、260以上のCloudflare CDNロケーションが利用可能です。
KinstaでのDocusaurusの記事に従って、数回クリックするだけで開始できます。