什么是CI/CD？

• 持续集成（CI）是一种实践，涉及开发人员对其代码进行小的更改和检查。由于需求的规模和所涉及的步骤的数量，这个过程是自动化的，以确保团队可以以可靠和可重复的方式构建，测试和打包他们的应用程序。CI有助于简化代码更改，从而增加开发人员进行更改并为改进软件做出贡献的时间。

• 持续交付（CD）是将完成的代码自动交付到测试和开发等环境。CD为代码提供了一种自动化和一致的方式来交付到这些环境中。

配置新Linux远程服务器SSH允许秘钥登录

1. 生成 SSH 密钥对（如果还没有）

• t rsa：t —type，指定使用 RSA 算法类型。

• b 4096：指定密钥长度为 4096 位。

• C "your_email@example.com"：为密钥添加注释（可选）。

2. 将公钥复制到服务器

3. 配置 SSH 服务以启用密钥登录

• PubkeyAuthentication yes：启用公钥认证。

• AuthorizedKeysFile .ssh/authorized_keys：指定公钥文件路径。

• PasswordAuthentication no：如果想强制只使用密钥登录，可以禁用密码登录。

4. 重启 SSH 服务

5. 测试 SSH 密钥登录

6. 确保正确的权限设置

配置.ssh/authorized_keys

默认行为

• PubkeyAuthentication yes：启用公钥认证。当设置这一选项时，SSH 服务器将允许使用公钥进行身份验证。

• AuthorizedKeysFile：指定用户公钥的存放位置。默认情况下，它的值是 ~/.ssh/authorized_keys。如果没有显式设置 AuthorizedKeysFile，SSH 会使用默认值 ~/.ssh/authorized_keys。

示例

验证SSH或者Git是否能正常与本地内往穿透的本地服务器正常通信

验证 SSH 连接

• <port>：内网穿透使用的外部端口号。

• <username>：本地服务器上的用户名。

• <public_ip_or_hostname>：内网穿透服务分配的公共 IP 地址或主机名。

常见问题

• 连接超时或拒绝：检查内网穿透工具的配置是否正确。确认防火墙设置允许该端口的流量，并且服务器的 SSH 服务在运行。

• 身份验证失败：确认使用的 SSH 密钥对是正确的，并且在服务器上已经正确配置了公钥（通常放在 ~/.ssh/authorized_keys 中）。

使用 ssh -v 查看详细输出

测试 Git SSH 连接

• 该命令不会启动一个交互式 shell，而是测试连接的可用性。

• 如果连接成功，可能会看到类似 “Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.” 的信息（这取决于服务器配置）。

验证 Git 推送和拉取

• 如果这些操作成功，那么说明 SSH 和 Git 配置是正确的。

检查 SSH 配置

验证 SSH 连接

命令格式解释

• ssh: 这是用于启动 SSH 客户端的命令行工具。

• T: 这个选项表示不分配伪终端（pseudo-tty）。使用 T 可以防止启动交互式 shell。这在仅仅想要测试连接而不进入交互式终端时非常有用。例如，当连接到 Git 服务器时，这样做会更快，因为不需要打开一个 shell 会话。

• p <port>: 指定 SSH 连接使用的端口号。默认情况下，SSH 使用端口 22。如果的内网穿透或 SSH 服务配置使用了非标准端口，例如 30576，需要使用 p 来指定。

• <username>: 这是在目标主机上的用户名。在许多 Git 服务（如 GitHub、GitLab）中，这个用户名通常是 git。

• <public_ip_or_hostname>: 目标主机的公共 IP 地址或域名。在使用内网穿透时，这个可以是内网穿透服务提供的公共 IP 或域名。

示例

常见场景和用途

1. 测试 SSH 连接是否可用：使用这个命令可以快速验证 SSH 服务是否正常工作，以及是否能够正确进行身份验证。

2. 测试 Git SSH 连接：如果在使用 Git 通过 SSH 协议与远程仓库通信，可以使用 T 来测试 SSH 是否能正常连接到 Git 服务。例如，GitHub 提供的 SSH 访问可以通过以下命令测试：
成功连接时，可能会看到类似 "Hi username! You've successfully authenticated, but GitHub does not provide shell access." 的信息，表明 SSH 连接已成功验证的身份。

3. 调试 SSH 连接问题：如果连接失败，可以使用 v 标志来查看详细的调试信息。这将显示连接建立过程中的所有步骤，有助于诊断问题所在：

1. SSH 公钥认证未配置或配置不正确

• 的本地机器没有正确配置 SSH 私钥，或者私钥的路径不对。

• 服务器端没有设置公钥认证，或者公钥文件没有正确放在服务器上的 ~/.ssh/authorized_keys 中。

• 服务器 SSH 配置文件中未启用公钥认证。

解决方法

1. 生成 SSH 密钥对（如果尚未生成）：
在本地机器上生成 SSH 密钥对：
这将在 ~/.ssh/ 目录中生成一个公钥（id_rsa.pub）和一个私钥（id_rsa）。

2. 将公钥添加到服务器：
将生成的公钥内容（~/.ssh/id_rsa.pub）复制到服务器的 ~/.ssh/authorized_keys 文件中。可以使用以下命令复制公钥到服务器：
或者手动将 id_rsa.pub 的内容添加到服务器上的 ~/.ssh/authorized_keys 文件中。

3. 检查服务器 SSH 配置：
确保服务器的 SSH 配置文件（通常是 /etc/ssh/sshd_config）启用了公钥认证：
确保 AuthorizedKeysFile 设置指向正确的文件路径（通常是 .ssh/authorized_keys）。

4. 重启 SSH 服务：
如果修改了 SSH 配置文件，需要重启 SSH 服务以使更改生效：

检查本地 SSH 配置

3. 密钥权限问题

确认权限设置

• ~/.ssh 目录权限应为 700：

• 私钥文件（id_rsa）权限应为 600：

• 公钥文件（authorized_keys）权限应为 600：

Actions→Host key verification failed.

检测secret.名称

Actions secret引用名错误引用了不存在的key或者内容复制粘贴错了key内容导致引用了错误的key→error in libcrypto.

检查内容

git仓库通过SSH通信方式使用前提之known_hosts

使用 ssh-keyscan 查询主机密钥

1. 运行 ssh-keyscan 命令：使用以下命令来获取的服务器 s15.zzip.top 在端口 30576 上的 SSH 主机密钥：
运行此命令后，它会输出类似以下格式的主机密钥：
这条输出包括主机名、端口号、密钥类型（如 ssh-rsa）以及密钥内容。

2. 将主机密钥添加到 ~/.ssh/known_hosts 文件：将输出直接追加到 known_hosts 文件中，可以使用以下命令：
这样，主机密钥将被追加到的本地 known_hosts 文件中。下一次尝试连接时，SSH 会自动使用该文件中的密钥来验证服务器的身份。

手动查看并复制主机密钥

使用 SSH 首次连接获取密钥指纹

在 GitHub Actions 中自动添加密钥

ssh-keyscan -p 和 -t参数的含义

1. p 选项：指定端口号

• 语法：p port

• 功能：指定要连接到的远程主机的端口号。默认情况下，SSH 使用端口号 22 进行连接。但如果的 SSH 服务运行在一个非标准端口上（如 30576），需要用 p 选项来明确指定端口号。

• 示例用法：在这个示例中，ssh-keyscan 将连接到 s15.zzip.top 主机的 30576 端口来获取 SSH 主机密钥。

2. t 选项：指定密钥类型

• 语法：t keytype

• 功能：指定要扫描的 SSH 密钥类型。SSH 协议支持多种密钥类型，如 rsa、ecdsa、ed25519 等。使用 t 选项可以限定 ssh-keyscan 只获取特定类型的密钥。

• 示例用法：在这个示例中，ssh-keyscan 将只获取 s15.zzip.top 主机上的 rsa 类型的 SSH 主机密钥。

组合使用

实现自动化部署一个被 fork 的 GitHub 仓库到个人服务器，同时保持与原始仓库的同步。

1. 设置 Fork 仓库与原始仓库的同步

1.1. 添加上游（原始）仓库的远程链接

1. 克隆 fork 的仓库到本地（或在服务器上）：

2. 添加原始仓库为上游：

3. 验证远程链接：
应该看到类似的输出：

1.2. 配置 GitHub Actions 自动同步

• cron: '0 0 * * 0'：每周自动同步一次（在周日的午夜），可以根据需求修改为不同频率。

• workflow_dispatch：允许手动触发同步工作流。

• GITHUB_TOKEN：GitHub 提供的内置 token，用于自动推送更改。

2. 自动化部署到个人服务器

2.1. 在 GitHub 中添加服务器的 SSH 部署密钥

1. 生成 SSH 密钥对（在的个人电脑或服务器上）：
将生成的公钥添加到的服务器的 ~/.ssh/authorized_keys 中，并将私钥存储为 GitHub 仓库的一个 secret。

2. 将私钥添加为 GitHub Secret：
• 在 GitHub 仓库中，导航到 Settings -> Secrets -> Actions。
• 创建一个新的 secret，命名为 DEPLOY_KEY，并粘贴私钥内容。

2.2. 配置 GitHub Actions 自动部署

• uses: webfactory/ssh-agent@v0.5.3：这个 GitHub Action 用来设置 SSH 代理和密钥。

• rsync：将文件同步到的服务器，-delete 选项会删除目标目录中不存在于源目录的文件，以确保源和目标完全同步。

3. 流程总结

1. fork 的仓库通过 GitHub Actions 设置自动与原始仓库同步。

2. 一旦 fork 仓库有新的更新（通过同步或直接 push），GitHub Actions 会自动将代码部署到的个人服务器。

在同步时排除上游仓库原.github文件，保留我自定义的.github文件

方法：通过 Git 合并时排除 .github 文件夹

1. 使用分支来隔离上游更新：首先，使用一个专门的分支来从上游仓库拉取更新，然后将这些更新合并到主分支（master）时，排除掉 .github 目录。

2. 创建专门用于同步的分支：例如，创建一个名为 upstream-sync 的分支，用于拉取上游更新。

3. 从上游仓库拉取更新：
• 添加上游仓库（如果还没有添加的话）：
• 从上游仓库获取更新：

4. 合并更新时排除 .github 文件夹：
• 使用 git merge 的 -no-commit 和 -no-ff 选项进行合并。这些选项允许在合并时暂停，以便进行手动调整：
• 合并暂停后，可以删除或排除 .github 目录中的更改：
这会将 .github 目录从暂存区移除，并恢复到合并前的状态。
• 提交合并更改：

5. 将合并后的更改应用到的主分支：
切换回 master 分支并合并 upstream-sync 分支：

自动化同步过程

只对上游某一两个文件夹同步其他全部不处理，也不删除仓库本来有的文件方式

方法一：使用 Git Sparse Checkout（稀疏检出）

步骤：

1. 设置稀疏检出：
假设想从上游仓库中只同步 folder1 和 folder2。
使用稀疏检出设置后，只有 folder1 和 folder2 目录会被同步到的工作树中，其他目录将被忽略。可以随时在需要时添加更多目录。

2. 合并更改到主分支：
切换回 master 分支，并合并从 upstream-sync 分支中的特定文件夹更改。
这样，的 master 分支将包含从 upstream-sync 分支同步的 folder1 和 folder2 中的更新，而不会影响其他文件。

方法二：手动拷贝和合并

1. 克隆上游仓库到一个临时目录：

2. 进入临时目录并复制需要的文件夹：

3. 在的 fork 仓库中提交这些更改：

方法三：Git 过滤器分支策略

1. 创建过滤器分支：
在本地创建一个基于上游仓库的临时分支，并过滤掉不需要的文件夹。

2. 合并过滤分支：
切换回的主分支，将过滤后的分支合并：

方法四：GitHub Actions 和脚本

1. 创建一个 GitHub Actions 工作流（例如 sync-specific.yml）：
这种方式使用 GitHub Actions 来自动同步指定的文件夹，并将更改推送到的 fork 仓库中。

总结

• 稀疏检出 是在同步时排除特定文件夹的一种强大工具。

• 手动拷贝和合并 适用于不频繁的同步情况。

• 过滤器分支策略 是处理复杂仓库的高级方法。

• GitHub Actions 可以自动化同步特定文件夹的过程。

git连接到没有公网IP进行穿透代理的远程服务器

1. 测试 SSH 连接：通过 ssh -p 6000 user@[FRP_SERVER_IP/Domian] 连接到的服务器，确保 SSH 代理工作正常。

2. 配置 Git：在的本地 Git 仓库中，配置远程仓库为通过 FRP 暴露的 SSH 地址：
然后可以使用 git push 推送代码到服务器。

部署远程仓库使用 Git 钩子自动化更新文件目录为最新推送文件状态

post-receive钩子

• 每次当有人 git push 到 blog.git 裸仓库时，post-receive 钩子会被触发。

• 钩子脚本中的命令会自动将最新的代码检出到 /path/blog 目录中。

• 这样，/path/xxxx 将始终保持最新的推送内容，类似于一个实际的工作目录。

1. 进入远程仓库的 hooks 目录：

2. 创建或编辑 post-receive 文件：

3. 编写 post-receive 钩子的内容：
添加以下内容到 post-receive 文件中：
• GIT_WORK_TREE：设置为希望更新的工作目录路径。
• rm -rf $GIT_WORK_TREE/*：删除工作目录中的所有文件。请小心使用这条命令，确保在正确的目录上执行，以免丢失重要数据。
• git --work-tree=$GIT_WORK_TREE checkout -f：强制将最新的提交检出到工作目录。

4. 赋予 post-receive 文件执行权限：
保存文件后，确保这个脚本具有执行权限：

post-update钩子

post-update

post-update 钩子的作用和用途

1. 引用更新后执行：post-update 钩子在每次成功更新一个或多个引用（例如分支、标签）后被触发。引用更新意味着新的提交已经被添加到这些引用中。

2. 常用于通知系统：该钩子经常用于触发通知机制，比如更新缓存、发送邮件通知、触发其他系统的更新（如持续集成服务器通知）。它可以用来通知其他系统或服务某些分支或标签发生了变化。

3. 权限管理：在一些场景下，post-update 钩子可以用于控制权限。例如，阻止某些用户在特定分支上执行推送操作或进行特定的合并。

4. 缓存更新：post-update 可以用于更新仓库浏览器的缓存，尤其是在 Web 接口上显示 Git 仓库的内容时，例如使用 GitWeb 或类似工具。

5. 执行自定义脚本：像其他 Git 钩子一样，post-update 可以执行任何自定义脚本，例如运行测试、生成报告、触发其他自动化工作流。

post-update 的典型使用场景

• Web 仓库服务通知：例如，在 GitWeb 或 cgit 这样的系统中，post-update 可以用来更新网页上的显示，使得最新的推送内容立即可见。

• 触发钩子通知：在团队开发环境中，post-update 钩子可以触发通知邮件或发送消息到团队的聊天应用（如 Slack、Microsoft Teams），告知团队成员某些分支已被更新。

• 系统管理：系统管理员可以使用 post-update 钩子来执行一些管理操作，如备份更新后的分支或触发其他服务器上的脚本。

post-update 钩子文件示例

如何启用和使用 post-update 钩子

1. 找到钩子文件：进入 Git 裸仓库的 hooks 目录（如 /path/to/blog.git/hooks/）。

2. 编辑或创建钩子：如果没有 post-update 文件，可以创建一个，并确保去掉 .sample 后缀。

3. 赋予执行权限：

4. 编写钩子逻辑：根据的需求，编写钩子的执行脚本，例如通知系统、刷新缓存、更新日志等。

总结

• post-update 钩子用于在 Git 引用更新后执行操作，常用于通知、缓存刷新、权限管理等场景。

• 可以自定义钩子的行为，例如通知团队、触发自动化工作流、管理服务器端操作等。

• 需要手动创建或修改钩子文件 并确保其具有执行权限。

通过SSH-SFTP方式利用 Github Actions 定时任务来完成自动更新

工作原理

1. SFTP 协议：
• SFTP 是一种通过 SSH 协议进行的安全文件传输协议，提供加密的文件传输能力。它在传输文件时使用 SSH 通道进行加密，以确保数据的安全性。
• 与 FTP 不同，SFTP 使用加密连接来传输数据，这增加了安全性。

2. GitHub Actions 插件：
• wlixcc/SFTP-Deploy-Action@v1.0 插件通过使用 SFTP 协议将文件从 GitHub 仓库部署到远程服务器。
• 插件的配置需要指定远程服务器的 SFTP 连接信息，如主机名、端口、用户名和密钥或密码。

配置示例

配置选项

• host：远程 SFTP 服务器的主机名或 IP 地址。

• port：SFTP 服务器的端口（默认是 22）。

• username 和 password：用于身份验证的凭据。也可以使用 SSH 密钥进行身份验证（通过 private-key 配置项）。

• local-dir：要上传的本地目录路径。

• remote-dir：要将文件上传到的远程目录路径。

与git推送部署代码的对比

使用 Git

1. SSH 私钥（如果使用 SSH 协议）：
• 用于通过 SSH 协议进行身份验证。如果使用 SSH URL（如 git@github.com:user/repo.git），需要在本地配置 SSH 密钥对，并将公钥添加到远程 Git 服务器上。

2. Git 用户名和邮箱：
• 这些信息用于提交代码时标识提交者。可以在本地 Git 配置中设置这些信息：

3. 远程仓库地址：
• 这是推送代码的目标地址，可以是 SSH URL 或 HTTPS URL。例如：
• SSH URL：git@github.com:user/repo.git
• HTTPS URL：https://github.com/user/repo.git

使用 wlixcc/SFTP-Deploy-Action@v1.0

1. SFTP 主机名：
• 远程 SFTP 服务器的主机名或 IP 地址。

2. SFTP 端口：
• 通常为 22，但可以根据实际配置进行更改。

3. SFTP 用户名：
• 用于进行身份验证的用户名。

4. SFTP 密码或私钥：
• 如果使用密码进行身份验证，需要提供密码。如果使用私钥进行身份验证，需要提供私钥文件或内容。

5. 本地目录和远程目录：
• local-dir：要上传的本地目录路径。
• remote-dir：上传文件到远程服务器上的目录路径。

配置示例