使用 Zinnector® 部署：链接、检查、推送

当项目在本地运行后，有四个命令可以将其部署到 Zinn Digital® 托管的线上站点：登录、将项目关联到托管槽位、读取预检以及推送。本文将逐一介绍这些命令、它们的输出内容，以及之后会用到的命令——重新部署、部署历史记录和构建日志。

使用 API 密钥登录

在控制面板的 Settings → API keys 下创建一个密钥，然后运行：

zinnector login

该密钥在提示符处输入——绝不会在命令行中直接接受，因此它不会最终进入您的 shell 历史记录或进程列表中。在 CI 中，通过管道传入：echo "$ZINN_API_KEY" | zinnector login --profile ci，或者设置 ZINNECTOR_TOKEN 并完全跳过 login。密钥在存储前会经过验证，并以文件权限 600 进行存储。zinnector whoami --scopes 显示您登录的是哪个组织以及该密钥具有哪些权限；沙盒密钥会被标记为沙盒密钥。

将项目关联到槽位

zinnector link                                   # 从列表中选择一个站点
zinnector link example.com --repo acme/site --branch main

link 会将站点的 ID 写入 zinnector.json 中，并且除非传入 --no-repo，否则会将项目的 git 远程仓库连接到平台上的站点，以便通过推送进行部署。提交 zinnector.json：克隆仓库的同事随后无需额外说明即可部署到同一位置。它不包含任何机密信息。

读取预检

zinnector check

这就是 CLI 存在的意义。它会将您的项目与即将部署到的槽位进行比较，并打印出每一个不匹配项——以及所有未能完成的比较：

• PHP 版本，主版本差距被评为高（因为这肯定会破坏站点），次版本差距评级较低，因为如果把所有问题都评为严重，就会教导人们忽略警告。
• 槽位是否能够切换到您构建时所用的版本、槽位的 PHP 是否已过生命周期结束期（EOL），以及机器是已应用该版本还是仅仅收到了通知。
• 您的项目大小和文件数与槽位上实际剩余的磁盘和 inode 剩余空间进行对比——WordPress 树状结构在远未达到磁盘上限时就可能耗尽文件数。
• 双方的 WordPress 版本、槽位是否已完成配置，以及是否连接了用于推送的仓库。

它只发出警告，从不进行阻止。每一个发现都可以通过 zinnector push --force 来覆盖，因为您比检查程序更了解您自己的站点。无法进行的比较会被报告为未知，绝不会报告为通过，并且摘要总是会说明有多少个此类项。默认情况下，本地 PHP 版本是在 zinnector.json 中声明的版本；--probe 则会启动本地运行时并对其进行测量。--strict 在遇到未知项时也会返回非零退出码，这正是 CI 门禁（gate）所需要的。

推送

zinnector push

push 运行预检、推送您的提交、触发部署并监视其完成，最后打印出最终状态和已部署的提交。--dry-run 执行除部署之外的所有操作；--no-wait 触发部署并退出；--no-git 则在不推送的情况下部署平台已有的内容。如果已部署的提交不是刚刚推送的提交，它会予以说明。

出现问题时

zinnector deploys example.com        # 部署历史记录 —— 状态、提交、触发器、消息
zinnector logs example.com --build   # 最近一次部署的构建日志
zinnector logs example.com --error   # 站点的错误日志
zinnector deploy example.com         # 重新部署平台已有的内容
zinnector ai "why is my deploy failing?"

zinnector ai 在平台上针对您的帐户运行，因此它可以查看相同的部署历史记录和日志。在项目内部，它发送项目的结构（目录名称、版本和站点 ID），绝不发送文件内容。

相关内容

• 入门指南 · 本地开发 · 命令参考 · 故障排除