本文主要是介绍在自托管基础设施上使用 GitOps 部署 MinIO，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
基于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 领导者，并为运行器准备一个带有特定存储库的 GitHub 帐户。
-
服务器要求：启用了 Docker Swarm 的基于 Linux 的服务器是此设置的基石。服务器将充当 Docker Swarm 配置的领导者，跨多个节点编排容器部署。
-
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 涉及在领导者上初始化它，然后连接其他节点。
在领导节点上初始化 Docker Swarm
在将任何工作线程添加到群之前，需要初始化领导节点。这是通过以下命令完成的：
docker swarm init
此命令将输出带有令牌的 docker swarm join 命令。复制此命令以在下一步中使用。
将工作节点添加到 Swarm
在每个工作节点（在本例中为 Raspberry Pis）上，执行从领导节点初始化输出复制的命令。它看起来像这样：
docker swarm join --token <SWARM_JOIN_TOKEN> <LEADER_IP_ADDRESS>:2377
<LEADER_IP_ADDRESS>替换 <SWARM_JOIN_TOKEN> 为初始化期间提供的实际令牌和 IP 地址。
这些步骤将创建一个有凝聚力且协调的节点集群，能够托管和管理容器化应用程序。
配置 GitHub 自托管运行器
GitHub Self-Hosted Runner 是您管理和维护的计算机或容器，允许您完全控制环境和自定义选项。与 GitHub 托管的运行器（由 GitHub 提供的临时虚拟机）不同，自托管运行器在操作系统、软件和配置方面提供了灵活性。
在这种情况下，运行器将托管在本地运行的 Docker Swarm 领导节点上，以确保与现有基础结构无缝集成并保持对部署过程的控制。
将 GitHub Actions 与 Docker Swarm 集成
将 GitHub Actions 自托管运行器集成到 Docker Swarm 中涉及几个关键步骤，从设置运行器环境到下载和配置运行器软件。
设置 Runner 环境：
通过 GitHub UI，导航到存储库设置以添加新的自托管运行器。选择合适的操作系统和架构，与 Swarm 领导者的环境相匹配。
下载和配置运行器：
GitHub 提供了一组命令来下载、配置和启动 Swarm leader 上的自托管运行器。这些步骤将运行器注册到 GitHub，使其可用于执行工作流。
首先，您需要导航到 GitHub 存储库的设置，访问“操作”选项卡，然后添加新的运行器。按照 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>
请确保 <RUNNER_VERSION> 、 <YOUR_USERNAME> 、 <YOUR_REPO> 和 <YOUR_TOKEN> 实际版本号、GitHub 用户名、仓库名称和 GitHub UI 提供的令牌。
交互式测试运行
最初，使用提供的脚本启动运行器，以确认其设置成功并准备好处理作业。
# Start the runner interactively./run.sh
这些命令在自托管运行器和 GitHub 存储库之间建立连接，为直接从 Docker Swarm 领导者执行 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 选项卡，这将显示两个“选项卡”。选择“自承载运行器”以查看已配置的存储库运行器。
使用自托管运行器在 Docker Swarm 上部署 MinIO
在调整 GitHub Actions 工作流以在自托管运行器上执行时，尤其是为 Docker Swarm 基础结构（如“rpi-swarm”）量身定制的工作流时，必须设计工作流以充分利用独特的环境。这意味着不仅要运行测试，还要部署真正的应用程序，例如高性能分布式对象存储服务器 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 Swarmon:push:branches:- mainpull_request:jobs:deploy-minio:name: Deploy MinIO to RPI Swarmruns-on: [self-hosted, rpi-swarm]steps:- name: Check out repository codeuses: actions/checkout@v2- name: Load Docker Compose Filerun: |echo "Loading Docker Compose for MinIO Deployment..."docker-compose -f docker-compose.yml config- name: Deploy MinIO Stackrun: |echo "Deploying MinIO on RPI Swarm..."docker stack deploy -c docker-compose.yml minio_stack- name: Verify Deploymentrun: |echo "Verifying MinIO Deployment..."docker service ls | grep minio_stack
此工作流举例说明了如何利用 GitHub Actions 自托管运行器将 MinIO 等应用程序部署到 Docker Swarm 设置，展示了运行器在简单测试之外促进复杂 CI/CD 任务的能力。
-
name：标识工作流，此处名为“在 RPI Swarm 上部署 MinIO”。
-
on：定义工作流的触发器事件，设置为在推送到主分支和拉取请求时激活。
-
jobs：包含工作流要执行的作业，在此示例中，单个作业名为“deploy-minio”。
-
runs-on：指示作业在标记为“rpi-swarm”的自托管运行器上执行，确保工作流利用 Docker Swarm 的特定环境。
-
steps：列出作业将执行的操作顺序：
1 . 检出存储库代码：使用 actions/checkout@v2 将代码库提取到运行器上。
2 . 加载 Docker Compose 文件：准备要部署的 Docker Compose 文件，可用于验证文件的语法和输出有效配置。
3 . 部署 MinIO 堆栈：利用 Docker Compose 将 MinIO 作为堆栈部署到 Docker Swarm，展示自托管运行器处理 Docker Swarm 部署的能力。
4 . 验证部署：通过列出 Docker 服务并筛选 MinIO 堆栈来确认 MinIO 堆栈部署，确保部署成功。
利用 MinIO 和 GitOps 提升部署实践
这突显了 MinIO 致力于为当代应用程序完善存储解决方案的奉献精神，并与 GitHub 自托管运行器在 CI/CD 领域带来的演变无缝融合。采用 GitOps 原则使 MinIO 成为战略支点的先锋，朝着更加自力更生、更安全和更高效的部署工作流程迈进，从而显著增强了开发人员体验。
GitOps 在应用程序开发中引入的灵活性是 MinIO 功能大放异彩的另一个领域。开发人员发现自己有能力完善应用层并有把握地部署微服务，利用 MinIO 简化数据存储和管理。这种结构化的自动化方法可加速开发，增强应用程序的弹性和可扩展性。GitHub Actions 和自托管运行器的结合使各种设置的部署更加顺畅，充分利用了 MinIO 的对象存储优势。
这篇关于在自托管基础设施上使用 GitOps 部署 MinIO的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
