在自托管基础设施上使用 GitOps 部署 MinIO

David Cannan David Cannan 于 DevOps 2024年3月5日

Deploying MinIO with GitOps on Self-Hosted Infrastructure

基于 MinIO Weaviate Python GitOps 探讨的见解，本文致力于增强软件部署流程的自动化。

通过将 GitHub Actions 与 Docker Swarm 集成产生的协同效应，辅以自托管基础设施的稳健性，标志着 CI/CD 实践的重大进步。这种方法不仅利用容器化优势来部署软件应用程序，而且强调了 MinIO S3 在促进 GitOps 驱动的工作流方面的重要作用。利用自托管环境为组织提供了无与伦比的控制权和改进的安全保障，为定制 CI/CD 管道铺平了道路。

自托管的必要性

目标侧重于使用内部管理的自定义 GitHub Actions 运行器来实现 MinIO。这种方法超越了单纯采用自动化前沿；它关乎在定制环境中利用一流存储解决方案的全面功能。此环境强调绝对控制和适应性，突破了运营卓越的界限。选择自托管运行器而不是 GitHub 托管的替代方案，可以获得完整的环境控制权，并能够在专用硬件上运行工作流的灵活性，从而最大限度地优化部署流程。

此外，自托管运行器可以通过限制内部网络暴露于外部威胁的可能性来最大程度地减少潜在的攻击媒介。通过在内部运行运行器，组织可以实施严格的安全措施，例如网络分段和访问控制，以有效解决漏洞。

此配置的主要目标是提高 CI/CD 管道的自动化、效率和可扩展性，尤其适用于以 Docker 为中心的应用程序和服务。通过集成使用 GitHub Actions、自托管运行器和 MinIO，团队可以简化开发工作流，实现更可靠的部署并优化资源分配，同时确保其部署环境保持安全且高度可控。

确保基础设施就绪

在深入研究部署和配置之前，务必确保本地已准备好基础元素。这涉及设置一台服务器充当 Docker Swarm leader，并准备一个包含运行器专用存储库的 GitHub 帐户。

服务器要求：启用了 Docker Swarm 的基于 Linux 的服务器是此设置的基石。服务器将充当 Docker Swarm 配置中的 leader，协调跨多个节点的容器部署。
GitHub 帐户准备：需要一个 GitHub 帐户，其中包含一个存储库，GitHub Actions 自托管运行器将在其中进行配置。此存储库将保存运行器将执行的代码库和工作流。

安装命令

要准备服务器环境，必须安装以下软件包。

sudo apt update -y && sudo apt install docker.io docker-compose python3

命令行先决条件命令

这些命令确保 Docker、Docker Compose 和 Python 已安装并可以使用，为顺利的部署流程奠定了基础。

使用 Docker Swarm 打下基础

Docker Swarm 将一组 Docker 主机转换为单个虚拟 Docker 主机，从而为部署的应用程序提供高可用性和负载平衡。配置 Swarm 涉及在 leader 上对其进行初始化，然后连接其他节点。

在 Leader 节点上初始化 Docker Swarm

在将任何工作节点添加到 swarm 之前，需要初始化 leader 节点。这可以通过以下命令完成：

docker swarm init

初始化 docker swarm

此命令将输出一个 docker swarm join 命令以及一个令牌。复制此命令以供下一步使用。

将工作节点添加到 Swarm

在每个工作节点（在本例中为 Raspberry Pi）上，执行从 leader 节点初始化输出中复制的命令。它看起来类似于以下内容：

docker swarm join --token <SWARM_JOIN_TOKEN> <LEADER_IP_ADDRESS>:2377

将其他工作节点加入到 docker swarm

将 <SWARM_JOIN_TOKEN> 和 <LEADER_IP_ADDRESS> 替换为初始化期间提供的实际令牌和 IP 地址。

这些步骤创建了一个具有凝聚力和协调性的节点集群，能够托管和管理容器化应用程序。

配置 GitHub 自托管运行器

GitHub 自托管运行器是您管理和维护的机器或容器，使您能够完全控制环境和自定义选项。与由 GitHub 提供的短暂虚拟机 GitHub 托管运行器不同，自托管运行器在操作系统、软件和配置方面提供了灵活性。

在本例中，运行器将托管在本地运行的 Docker Swarm leader 节点上，以确保与现有基础设施的无缝集成并保持对部署流程的控制。

将 GitHub Actions 与 Docker Swarm 集成

将 GitHub Actions 自托管运行器集成到 Docker Swarm 中涉及几个关键步骤，从设置运行器环境到下载和配置运行器软件。

设置运行器环境

通过 GitHub UI，导航到存储库设置以添加新的自托管运行器。选择合适的操作系统和架构，使其与 Swarm leader 的环境匹配。

下载和配置运行器

GitHub 提供了一组命令来下载、配置和启动 Swarm leader 上的自托管运行器。这些步骤将运行器注册到 GitHub，使其可用于执行工作流。

首先，您需要导航到 GitHub 存储库的设置，访问 Actions 选项卡，并添加一个新的运行器。按照 GitHub 提供的说明操作，其中包括下载运行器并对其进行配置。

每个运行器必须为每个存储库实现，并且独立运行；能够拥有跨多个存储库的 GitHub 运行器是 GitHub Enterprise 的功能。这些说明看起来类似于以下命令，但请使用 GitHub 提供的确切命令，因为它们包含唯一的令牌。

# Create a directory for the runner
mkdir action-runner && cd action-runner

# Download the runner package
curl -o actions-runner-linux-arm64-<RUNNER_VERSION>.tar.gz -L <https://github.com/actions/runner/releases/download/v><RUNNER_VERSION>/actions-runner-linux-arm64-<RUNNER_VERSION>.tar.gz

# Extract the runner package
tar xzf ./actions-runner-linux-arm64-<RUNNER_VERSION>.tar.gz

# Configure the runner
./config.sh --url <https://github.com/><GITHUB_USERNAME>/<GITHUB_REPO> --token <GITHUB_TOKEN>

GitHub 提供的代码示例

确保将 <RUNNER_VERSION>、<YOUR_USERNAME>、<YOUR_REPO> 和 <YOUR_TOKEN> 分别替换为实际版本号、您的 GitHub 用户名、您的存储库名称和 GitHub UI 提供的令牌。

交互式测试运行

最初，使用提供的脚本启动运行器以确认其设置成功并已准备好处理作业。

# Start the runner interactively

./run.sh

执行运行脚本

这些命令建立了自托管运行器与 GitHub 存储库之间的连接，为直接从 Docker Swarm leader 执行 CI/CD 工作流奠定了基础。

为运行器创建 Systemd 服务

配置运行器后，下一步是将其操作化，确保它能够无缝处理工作流执行。交互式启动运行器测试其功能，而创建 Systemd 服务则确保其持久性和弹性。

1. 创建 Systemd 服务文件

此步骤涉及创建 systemd 服务文件以将 GitHub Actions 运行器作为服务进行管理，确保它自动启动并保持运行。

使用您喜欢的文本编辑器（如 nano 或 vim）创建一个新的服务文件。

sudo nano /etc/systemd/system/github-runner.service

创建服务文件

插入以下内容，并根据需要调整路径。

[Unit]
Description=GitHub Actions Runner
After=network.target

[Service]
ExecStart=/home/<USER>/action-runner/run.sh
User=<USER>
WorkingDirectory=/home/<USER>/action-runner
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

服务文件内容示例

将 <USER> 替换为您安装运行器的帐户的用户名。

2. 启用并启动服务

保存并关闭服务文件后，重新加载 systemd 以识别新服务，启用它在启动时启动，然后立即启动服务。

sudo systemctl daemon-reload
sudo systemctl enable github-runner.service
sudo systemctl start github-runner.service

3. 验证服务状态

要确保 GitHub Actions 运行器服务处于活动状态并正在运行，请执行以下命令：

sudo systemctl status github-runner.service

您应该会看到指示服务处于活动状态的输出。如果出现任何问题，输出还将包含可帮助进行故障排除的错误消息。

在 GitHub Actions 选项卡中，选择 Runners 选项卡，这将显示两个“选项卡”。选择 Self-hosted runners 以查看您已配置的存储库运行器。

使用自托管运行器在 Docker Swarm 上部署 MinIO

当将 GitHub Actions 工作流适配到自托管运行器上执行时，特别是针对像 "rpi-swarm" 这样的为 Docker Swarm 基础设施定制的运行器，务必设计工作流以充分利用其独特环境。这意味着不仅要运行测试，还要部署像 MinIO 这样的真实应用，MinIO 是一款高性能分布式对象存储服务器。以下是关于如何配置 GitHub Actions 工作流以在您的 "rpi-swarm" 运行器上部署 MinIO 的示例，展示了运行器处理更复杂 CI/CD 任务的能力，例如使用 Docker 和 Docker Compose 部署服务。

在您的仓库中 .github/workflows 目录下创建一个文件，例如 .github/workflows/deploy-minio-on-rpi-swarm.yml，并插入以下工作流配置

name: Deploy MinIO on RPI Swarm

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  deploy-minio:
    name: Deploy MinIO to RPI Swarm
    runs-on: [self-hosted, rpi-swarm]

    steps:
    - name: Check out repository code
      uses: actions/checkout@v2

    - name: Load Docker Compose File
      run: |
        echo "Loading Docker Compose for MinIO Deployment..."
        docker-compose -f docker-compose.yml config

    - name: Deploy MinIO Stack
      run: |
        echo "Deploying MinIO on RPI Swarm..."
        docker stack deploy -c docker-compose.yml minio_stack

    - name: Verify Deployment
      run: |
        echo "Verifying MinIO Deployment..."
        docker service ls | grep minio_stack

此工作流举例说明了如何利用 GitHub Actions 自托管运行器将 MinIO 等应用程序部署到 Docker Swarm 设置中，展示了运行器能够胜任超越简单测试的复杂 CI/CD 任务。

name: 标识工作流，此处命名为“在 RPI Swarm 上部署 MinIO”。
on: 定义工作流的触发事件，设置为在推送到 main 分支和拉取请求时激活。
jobs: 包含工作流要执行的作业，在本例中只有一个名为 "deploy-minio" 的作业。
runs-on: 指示作业在标记为 "rpi-swarm" 的自托管运行器上执行，确保工作流利用 Docker Swarm 的特定环境。
steps: 列出作业将执行的操作序列
- 检出仓库代码: 使用 actions/checkout@v2 将代码库获取到运行器上。
- 加载 Docker Compose 文件: 准备 Docker Compose 文件进行部署，这对于验证文件的语法和输出有效配置很有用。
- 部署 MinIO 堆栈: 利用 Docker Compose 将 MinIO 作为堆栈部署到 Docker Swarm，展示了自托管运行器处理 Docker Swarm 部署的能力。
- 验证部署: 通过列出 Docker 服务并筛选 MinIO 堆栈来确认 MinIO 堆栈部署，确保部署成功。

使用 MinIO 和 GitOps 提升部署实践

强调 MinIO 致力于完善现代应用程序的存储解决方案，与 GitHub 自托管运行器在 CI/CD 领域带来的演变无缝融合。拥抱 GitOps 原则将 MinIO 置于向更自主、安全和高效的部署工作流进行战略性转向的前沿，从而显著增强开发人员体验。

GitOps 引入应用程序开发的灵活性是 MinIO 能力大放异彩的另一个领域。开发人员发现自己能够充分利用 MinIO 进行简化的数据存储和管理，从而自信地改进应用程序层并部署微服务。这种结构化和自动化的方式加速了开发，增强了应用程序的弹性和可扩展性。GitHub Actions 和自托管运行器的整合简化了跨各种环境的部署，充分利用了 MinIO 的对象存储优势。

我们鼓励各位开发人员和工程师与我们一起踏上这段旅程，探索潜力，并分享他们的见解和疑问。如需更深入的讨论、协作或疑问，请随时通过 MinIO Slack 频道与我们联系。让我们携手利用我们集体的专业知识和 MinIO 及 GitOps 的强大功能，塑造部署实践的未来。