概览

    • 你是否正准备创建一个 web 应用/后端 API 微服务？
    • 你是否使用 GitHub 存储你的源代码？
    • 你是否渴望快速而自动地在你的开发/测试环境中部署你的服务，一触即发？

    请听我细细道来。

    • 由于你使用 GitHub 作为 SCM，而 CI 与代码仓库交互频繁，因此使用 GitHub Actions 作为你的 CI 选择是方便的。
      • 当然，你可以选择其他 CI，如 Travis CI、CircleCI 等，它们需要与 GitHub 进行一些额外集成操作；而使用 GitHub Actions，实际上几乎不需要集成。
      • 此外，因为用的人多了，你遇到的问题大概率别人已经遇到过，所以你可以轻松地通过简单的 Google 搜索找到解决方案。
    • 你希望在开发环境中快速且自动地部署你的服务。
      • GitOps 可能是你的最佳选择，因为它快速、自动化。
      • 你的环境不多，这可以避免一些棘手的问题，比如如果你使用 GitOps 部署到多个环境，你可能会遇到 Version propagation(多环境下的版本发布，例如将某个通过测试环境的版本发布到生产环境）的问题。

    我们想要构建一个基于这些工具的 DevOps 平台，而这个平台可以做到非常复杂的事情：

    • 在你的 GitHub 账户中创建一个仓库，并生成一些代码（一个 Python Flask 应用程序，包含 Dockerfile、helm chart 等）。
    • 创建持续集成（CI）流水线，于是：
      • 当 pull request 被创建时，会自动触发一个任务，以运行单元测试。
      • 当 pull request 被合并到主分支时，另一个任务将被触发，来构建 Docker 镜像，并推送到 Dockerhub，再触发部署流程。
    • 安装 Argo CD 以进行持续部署（CD）。
    • 以 GitOps 的方式触发 CD：当 pull request 被合并到主分支时，它将应用程序部署到 Kubernetes 集群。

    让我们”大展宏图”吧！

    1. 一个 GitHub 账户和一个用于 API 访问的访问令牌，以及一个 Dockerhub 账户和一个用于 API 访问的 access token。