部署
要为生产环境构建网站的静态文件,请运行:
- npm
- Yarn
- pnpm
- Bun
npm run build
yarn build
pnpm run build
bun 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
- Bun
npm run serve
yarn serve
pnpm run serve
bun run serve
默认情况下,这将在 http://localhost:3000/
加载你的站点。
尾随斜杠配置
Docusaurus 有一个 trailingSlash
配置,允许自定义 URL/链接和生成的文件名模式。
默认值通常可以正常工作。不幸的是,每个静态托管提供商的行为都不同,将完全相同的站点部署到不同的主机可能会导致不同的结果。根据你的主机,更改此配置可能会很有用。
使用 slorber/trailing-slash-guide 更好地了解你的主机的行为并适当配置 trailingSlash
。
使用环境变量
将潜在的敏感信息放在环境中是常见做法。然而,在典型的 Docusaurus 网站中,docusaurus.config.js
文件是唯一与 Node.js 环境交互的接口(参见我们的架构概述),而其他一切(MDX 页面、React 组件等)都是客户端的,并且无法直接访问 process
全局变量。在这种情况下,你可以考虑使用 customFields
将环境变量传递到客户端。
// 如果你正在使用 dotenv (https://www.npmjs.com/package/dotenv)
import 'dotenv/config';
export default {
title: '...',
url: process.env.URL, // 你可以使用环境变量来控制站点特定设置
customFields: {
// 在这里放置你的自定义环境变量
teamEmail: process.env.EMAIL,
},
};
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
export default function Home() {
const {
siteConfig: {customFields},
} = useDocusaurusContext();
return <div>通过 {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 等持续部署功能,但需要更多的工作。通常,你会指定一个特定的人来管理部署,工作流不会像其他两个选项那样基于 Git。
- 🟢 Netlify 和 Vercel 为每个拉取请求提供部署预览,这对团队在合并到生产环境之前审查工作很有用。你还可以管理具有不同成员访问权限的团队。
- 🟡 GitHub Pages 无法以非复杂的方式进行部署预览。一个仓库只能与一个站点部署相关联。另一方面,你可以控制谁有权访问站点的部署。
没有万能的解决方案。在做出选择之前,你需要权衡自己的需求和资源。
自托管
可以使用 docusaurus serve
自托管 Docusaurus。使用 --port
更改端口,使用 --host
更改主机。
- npm
- Yarn
- pnpm
- Bun
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
bun 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,不带尾随斜杠
baseUrl: '/', // 相对于你的仓库的站点基本目录
// ...
};
在设置站点时,按如下方式指定构建命令和目录:
- 构建命令:
npm run build
- 发布目录:
build
如果你未配置这些构建选项,可以在站点创建后转到"站点设置" -> "构建和部署"。
一旦使用上述选项正确配置,你的站点应该部署并在合并到默认部署分支(默认为 main
)时自动重新部署。
一些 Docusaurus 站点将 docs
文件夹放在 website
之外(很可能是早期的 Docusaurus v1 站点):
repo # git 根目录
├── docs # MD 文件
└── website # Docusaurus 根目录
如果你决定使用 website
文件夹作为 Netlify 的基本目录,Netlify 将不会在更新 docs
文件夹时触发构建,你需要配置自定义 ignore
命令:
[build]
ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF . ../docs/"
默认情况下,Netlify 会为 Docusaurus URL 添加尾随斜杠。
建议禁用 Netlify 设置 后处理 > 资源优化 > 漂亮的 URL
以防止小写 URL、不必要的重定向和 404 错误。
请非常小心:全局复选框 禁用资源优化
是损坏的,实际上并不真正禁用 漂亮的 URL
设置。请确保独立取消选中它。
如果你想保持 Netlify 的 漂亮的 URL
设置,请适当调整 Docusaurus 的 trailingSlash
配置。
请参考 slorber/trailing-slash-guide 了解更多信息。
部署到 Vercel
将你的 Docusaurus 项目部署到 Vercel 将为你提供性能和易用性方面的各种优势。
要使用 Vercel 的 Git 集成部署你的 Docusaurus 项目,请确保它已推送到 Git 仓库。
使用导入流程将项目导入 Vercel。在导入过程中,你会发现所有相关选项都已为你预配置;但是,你可以选择更改任何这些选项。
项目导入后,所有后续推送到分支的操作都将生成预览部署,对生产分支(通常是 "main" 或 "master")所做的所有更改都将导致生产部署。
部署到 GitHub Pages
Docusaurus 提供了一种简单的方法来发布到 GitHub Pages,每个 GitHub 仓库都有免费的 GitHub Pages 服务。
概述
通常,发布过程涉及两个仓库(至少两个分支):包含源文件的分支和包含要由 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 从默认分支(通常是 master
/ main
)或 gh-pages
分支,以及根目录或 /docs
文件夹中获取可部署的文件(docusaurus build
的输出)。你可以通过仓库的 设置 > 页面
进行配置。这个分支将被称为"部署分支"。
我们提供 docusaurus deploy
命令,帮助你从源分支一次性部署站点到部署分支:克隆、构建和提交。
docusaurus.config.js
设置
首先,修改你的 docusaurus.config.js
并添加以下参数:
名称 | 描述 |
---|---|
organizationName | 部署仓库的 GitHub 用户或组织。 |
projectName | 部署仓库的名称。 |
deploymentBranch | 部署分支的名称。它默认为 'gh-pages' 对于非组织 GitHub Pages 仓库(projectName 不以 .github.io 结尾)。否则,需要明确为配置字段或环境变量。 |
这些字段也有其环境变量对应项,优先级更高:ORGANIZATION_NAME
、PROJECT_NAME
和 DEPLOYMENT_BRANCH
。
GitHub Pages 默认情况下为 Docusaurus URL 添加尾随斜杠。建议设置 trailingSlash
配置(true
或 false
,不是 undefined
)。
示例:
export default {
// ...
url: 'https://endiliey.github.io', // 你的网站 URL
baseUrl: '/',
projectName: 'endiliey.github.io',
organizationName: 'endiliey',
trailingSlash: false,
// ...
};
默认情况下,GitHub Pages 运行发布文件通过 Jekyll。由于 Jekyll 将丢弃任何以 _
开头的文件,建议你禁用 Jekyll 并添加一个空文件名为 .nojekyll
文件到你的 static
目录。
环境设置
名称 | 描述 |
---|---|
USE_SSH | 设置为 true 以使用 SSH 而不是默认的 HTTPS 连接到 GitHub 仓库。如果源仓库 URL 是 SSH URL(例如 git@github.com:facebook/docusaurus.git ),则 USE_SSH 被推断为 true 。 |
GIT_USER | 具有推送访问权限的 GitHub 帐户的 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 企业安装应与 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。根据部署仓库的位置,选择相关选项卡:
- 源仓库和部署仓库是同一个仓库。
- 部署仓库是一个远程仓库,与源不同。此场景的说明假设发布源是
gh-pages
分支。
- Same
- Remote
虽然你可以在同一个工作流文件中拥有两个作业,但原始 添加这两个工作流文件: 如果 Docusaurus 项目不在仓库的根目录中,你可能需要配置默认工作目录,并相应调整路径。deploy
作业将始终在 PR 检查套件状态中列为跳过,这并不表示实际状态,也不提供任何价值来审查过程。我们因此建议将它们作为单独的工作流来管理。GitHub action files
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: npm
- name: Install dependencies
run: npm ci
- name: Build website
run: npm 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@v4name: 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: npm
- name: Install dependencies
run: npm ci
- name: Test build website
run: npm buildname: 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@v4name: 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
并将其作为 部署密钥 添加到部署仓库中。复制文件内容,如果命令行对你不起作用。检查框以允许写入访问权限,然后保存你的部署密钥。 - 你需要将你的私有密钥作为 GitHub 秘密 添加到源仓库中,以便 Docusaurus 可以为你运行部署。
- 将你的私有密钥复制到剪贴板,使用
pbcopy < ~/.ssh/id_rsa
并将其添加到源仓库中的 GitHub 秘密,并保存秘密。 - 创建你的 文档工作流 在
.github/workflows/
目录中。在此示例中,它是deploy.yml
文件。
此时,你应该有:
- 源仓库与 GitHub 工作流设置为使用私有 SSH 密钥作为 GitHub 秘密,
- 你的部署仓库设置为在 GitHub 部署密钥中具有公共 SSH 密钥。
GitHub action file
请确保将 actions@github.com
替换为你的 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-agent@v0.5.0
with:
ssh-private-key: ${{ secrets.GH_PAGES_DEPLOY }}
- name: Deploy to GitHub Pages
env:
USE_SSH: true
run: |
git config --global user.email "actions@github.com"
git config --global user.name "gh-actions"
yarn install --frozen-lockfile
yarn deploy
站点未正确部署?
推送后,如果看不到你的站点发布到所需位置(例如,它说“这里没有 GitHub Pages 站点”,或者它显示你的仓库的 README.md 文件),请尝试以下操作:
- 等待大约三分钟并刷新。可能需要几分钟才能让 GitHub pages 获取新文件。
- 检查你的仓库的登录页面,查看最后一个提交标题旁边是否有小绿勾,表示 CI 已通过。如果你看到交叉,则表示构建或部署失败,你应该检查日志以获取更多调试信息。
- 点击勾并确保你看到一个“部署到 GitHub Pages”工作流。名称如“pages build and deployment / deploy”是 GitHub 的默认工作流,表示你的自定义工作流未触发。确保 YAML 文件放置在
.github/workflows
文件夹中,并且触发条件设置正确(例如,如果默认分支是“master”而不是“main”,你需要更改on.push
属性)。 - 在仓库的设置 > 页面下,确保“源”(这是部署文件的源,而不是“源”作为我们的术语)设置为“gh-pages” + "/ (root)",因为我们使用
gh-pages
作为部署分支。
如果你使用自定义域名:
- 验证你是否设置了正确的 DNS 记录,如果你使用自定义域名。请参阅 GitHub pages 文档以配置自定义域名。还要注意,DNS 更改可能需要 24 小时才能通过互联网传播。
使用 Travis CI 触发部署
持续集成(CI)服务通常用于在每次向源代码控制提交新提交时执行例行任务。这些任务可以是运行单元测试和集成测试、自动化构建、发布到 npm、部署到你的网站等。所有你需要做的就是调用 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
脚本部署。
使用 Buddy 触发部署
Buddy 是一个易于使用的 CI/CD 工具,允许你自动化将门户部署到不同的环境,包括 GitHub Pages。
按照以下步骤创建一个管道,每当对项目选择的分支进行新提交时,自动部署新版本的网站:
- 转到 https://github.com/settings/tokens 并生成一个新的 个人访问令牌。在创建令牌时,授予它
repo
范围,以便它具有所需权限。 - 登录到你的 Buddy 帐户并创建一个新的项目。
- 选择 GitHub 作为 git 托管提供程序,并选择包含代码的仓库。
- 使用左侧导航面板切换到
Pipelines
视图。 - 创建一个新的管道。定义其名称,将触发模式设置为
On push
,并选择触发管道执行的分支。 - 添加一个
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
将你的网站部署到 GitHub Pages。阅读 此指南 了解更多关于为 Docusaurus 设置 CI/CD 管道。
使用 Azure Pipelines
- 转到 https://azure.microsoft.com/en-us/services/devops/pipelines/ 并注册,如果你还没有注册。
- 创建一个组织。在组织内,创建一个项目并连接你的仓库。
- 转到 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 作业以发布你的网站。
部署到 Flightcontrol
Flightcontrol 是一个服务,它可以直接从你的 Git 仓库将你的 Web 应用部署到 AWS Fargate,而无需传统的 PaaS。它让你完全访问检查和进行基础设施更改,而无需限制。
按照 Flightcontrol 的 Docusaurus 指南 开始。
部署到 Koyeb
Koyeb 是一个开发者友好的服务器无服务器平台,可以在全球范围内部署应用程序。该平台允许你无缝运行 Docker 容器、Web 应用程序和 API,使用基于 git 的部署、本机自动扩展、全球边缘网络和内置服务网格和发现。查看 Koyeb 的 Docusaurus 部署指南 开始。
部署到 Render
Render 提供免费的静态站点托管,具有完全管理的 SSL、自定义域名、全球 CDN 和从你的 Git 仓库连续自动部署。只需几分钟即可开始,请按照 Render 的 Docusaurus 部署指南 开始。
部署到 Qovery
Qovery 是一个完全托管的云平台,它运行在你的 AWS、Digital Ocean 和 Scaleway 帐户上,你可以在一个地方托管静态站点、后端 API、数据库、cron 作业和所有其他应用程序。
- 创建一个 Qovery 帐户。访问 Qovery 仪表板 创建一个帐户,如果你还没有。
- 创建一个项目。
- 点击 创建项目 并给项目命名。
- 点击 下一步。
- 创建一个新的环境。
- 点击 创建环境 并给环境命名(例如,staging, production)。
- 添加一个应用程序。
- 点击 创建应用程序,给应用程序命名并选择你的 GitHub 或 GitLab 仓库,其中包含你的 Docusaurus 应用程序。
- 定义主分支名称和应用程序路径。
- 点击 创建。应用程序创建后:
- 导航到你的应用程序 设置
- 选择 端口
- 添加用于你的 Docusaurus 应用程序的端口
- 部署
- 现在你只需要导航到你的应用程序并点击 部署。
就是这样。查看状态并等待应用程序部署。要打开应用程序,请在应用程序概览中点击 操作 并 打开。
部署到 Hostman
Hostman 允许你免费托管静态网站。Hostman 自动化一切,你只需要连接你的仓库并按照这些简单的步骤操作:
-
创建一个服务。
- 要部署 Docusaurus 静态网站,请在 仪表板 左上角点击 创建,然后选择 前端应用程序或静态网站。
-
选择要部署的项目。
-
如果你使用 GitHub、GitLab 或 Bitbucket 帐户登录 Hostman,你将看到包含项目的仓库,包括私有仓库。
-
选择要部署的项目。它必须包含项目文件的目录(例如
website
)。 -
要访问不同的仓库,请点击 连接另一个仓库。
-
如果你没有使用你的 Git 帐户凭据登录,你将能够访问必要的帐户,然后选择项目。
-
-
配置构建设置。
-
接下来,网站自定义窗口将出现。从列表中选择 静态网站 选项。
-
目录与应用程序指向将包含项目文件的目录。如果你在步骤 2 中选择了包含网站内容的仓库(或
my_website
)目录,你可以将其保留为空。 -
Docusaurus 的标准构建命令是:
- npm
- Yarn
- pnpm
- Bun
npm run build
yarn build
pnpm run build
bun run build
-
如果你需要,你可以修改构建命令。你可以输入多个命令,用
&&
分隔。
-
-
部署。
-
点击 部署 以开始构建过程。
-
一旦开始,你将进入部署日志。如果代码中存在任何问题,日志中将出现警告或错误消息,指定问题的原因。通常,日志包含所有调试数据,你将需要。
-
当部署完成时,你将收到一封电子邮件通知,并在日志中看到条目。全部完成!你的项目已启动并准备就绪。
-
部署到 Surge
Surge 是一个静态 Web 托管平台,你可以使用它从命令行在几秒钟内部署你的 Docusaurus 项目。部署你的项目到 Surge 很容易且免费(包括自定义域名和 SSL 证书)。
只需几秒钟即可使用 Surge 部署你的应用程序,如下所示:
- 首先,使用 npm 安装 Surge,运行以下命令:
- npm
- Yarn
- pnpm
- Bun
npm install -g surge
yarn global add surge
pnpm add -g surge
bun add --global surge
- 要为生产环境在项目根目录中构建静态文件,请运行:
- npm
- Yarn
- pnpm
- Bun
npm run build
yarn build
pnpm run build
bun run build
- 然后,运行此命令,在项目根目录中:
surge build/
第一次使用 Surge 的用户将被提示从命令行创建帐户(这只会发生一次)。
确认你要发布的站点在 build
目录中。将随机生成的子域名 *.surge.sh 子域名
始终给出(可以编辑)。
使用你的域名
如果你有一个域名,你可以使用命令部署你的站点:
surge build/ your-domain.com
你的站点现在免费部署在 subdomain.surge.sh
或 your-domain.com
取决于你选择的方法。
设置 CNAME 文件
将你的域名存储在 CNAME 文件中,以便将来使用:
echo subdomain.surge.sh > CNAME
你可以使用命令 surge
部署任何其他未来的更改。
部署到 Stormkit
你可以将你的 Docusaurus 项目部署到 Stormkit,这是一个用于静态网站、单页应用程序(SPAs)和无服务器功能的部署平台。有关详细说明,请参阅此 指南。
部署到 QuantCDN
查看 文档 和 博客 了解更多示例和使用案例,用于部署到 QuantCDN。
部署到 Cloudflare Pages
Cloudflare Pages 是一个 Jamstack 平台,用于前端开发人员协作和部署网站。只需几分钟即可开始,请按照 此页面 开始。
部署到 Azure Static Web Apps
Azure Static Web Apps 是一个服务,它可以直接从代码仓库将全栈 Web 应用部署到 Azure,简化 CI/CD 开发人员体验。Static Web Apps 将 Web 应用程序的静态资产与动态(API)端点分离。静态资产从全球分布的内容服务器中提供,使客户端能够更快地使用服务器附近的服务器检索文件。动态 API 使用基于事件的函数驱动方法,更高效且按需扩展。只需几分钟即可开始,请按照 此步骤指南 开始。
部署到 Kinsta
Kinsta Static Site Hosting 允许你免费部署最多 100 个静态站点,自定义域名与 SSL、100 GB 每月带宽和 260+ Cloudflare CDN 位置。
只需几次点击即可开始,请按照我们的 Docusaurus 在 Kinsta 文章开始。