现代应用程序开发快速迭代和以高度动态规模运行。在一个拥有成熟 DevOps 文化的组织中,每天可以将代码部署到生产环境中数百次。然后,应用程序可以在从少数用户到数百万用户的高度动态负载下运行。现代基础设施需要具有弹性。可以动态配置和取消配置的容量能够与负载保持同步,从而保持最佳性能和最小成本。随着对当今基础设施的需求,以稳健和连贯的管理基础设施自动化变得越来越重要。
GitOps == IaC + MRs + CI/CD
GitOps 是一个操作框架,它将 DevOps 最佳实践应用于应用程序开发,如版本控制、协作、合规和 CI/CD流水线,并将它们应用于基础设施自动化。
GitOps 涉及使用软件开发中众所周知的实践(如版本控制、代码审查和 CI/CD 流水线)来管理您的IT基础设施。例如,实践 GitOps 的基础架构团队使用存储为代码的配置文件。类似于每次构建应用程序源代码都会生成相同的应用程序二进制文件,每次部署GitOps 配置都会生成相同的基础设施环境。
与任何新兴技术术语一样,“GitOps” 并不是行业中每个人都严格地以相同的方式定义的。GitOps 出现在云原生社区,一些定义限制了 GitOps,说“Kubernetes 被要求做 GitOps。” 极狐 GitLab 采用了更广泛的方法。我们已经看到极狐 GitLab用户和客户将 GitOps 原理应用于所有类型的基础设施自动化,包括虚拟机和容器,以及Kubernetes集群。
虽然许多工具和方法都承诺在代码和基础设施之间进行更快的部署和无缝管理,但 GitOps 的不同之处在于它专注于以开发人员为中心的体验。通过 GitOps 进行的基础设施管理与应用程序开发在同一个版本控制系统中进行,使团队能够在一个中心位置进行更多协作,同时受益于 Git 的所有内置功能。
GitOps 是将 基础设施作为代码 使用的规范工作流。GitOps 和 极狐 GitLab 可以帮助您管理物理、虚拟和云原生基础设施(包括 Kubernetes 和无服务器技术),使用与业界领先的基础设施自动化工具(如 Terraform、AWS cloud Formation、Ansible、Chef、Puppet 等)紧密集成。
与任何新兴技术一样,GitOps 有不同的方法,每种方法都有各自的优点(Pro)和缺点(Con)。
推 (Push) 或无代理的 GitOps 在这种方法中,您的CI/CD工具将更改推送到您的环境。这种方法与用于应用程序部署的方法一致。Pro
拉 (Pull)或 有代理的 GitOps 在这种方法中,在集群中安装一个代理,以便在偏离所需配置时进行更改。Pro
基础设施即代码要求理解平台和应用程序环境的理想状态。“基础设施即代码”的用户很好地理解了作为 SCM 工具的 Git 以及它们期望提供和管理的平台。下面是一些高级用户的基础设施代码:
基础设施即代码的买家通常是领导基础设施/自动化计划的领导者。典型的买家角色有:
列出这个用例的关键分析师覆盖范围‘
以下是 GitOps 的市场需求
描述:该解决方案旨在支持和促进团队成员之间的协作。协作系统包括手动闸门和审批以及自动化的工作流程。
一组展示 极狐 GitLab 的GitOps功能的简短演示。
市场需求 | 极狐 GitLab 如何交付 | 极狐 GitLab 阶段/类别 | Demos |
---|---|---|---|
促进合作 | 讨论,用户标签,一般评论,内联评论,内联建议,未解决的线程跟踪,从评论中创建问题,建议管理,CODEOWNERS,批准 | 讨论,CODEOWNERS,MR 批准 | |
审计 | 极狐 GitLab的CI/CD流水线中内置了合规性测试和审计控制。 | 极狐 GitLab 的遵从性,管理阶段:审计事件、审计日志、审计报告、合规管理、发布证据、监管链、细粒度用户角色和权限、职责隔离。安全阶段:许可证遵从性,依赖项扫描,代码所有者,MR 批准, | |
版本控制环境 | 使用极狐 GitLab 版本控制存储 XaC (基础设施、策略、配置等)有助于维护变更的跟踪。此外,当部署失败时,可以自动回退,以便回退到之前的成功部署 | 环境回滚,极狐 GitLab 代理 Kubernetes | |
自动化测试 | 将可用性、性能测试作为流水线的一部分,并在出现问题时回滚到成功的部署 | 发布版本控制,支持高级部署策略,如 canary,增量推出,蓝绿部署,功能标志,审查应用程序,性能测试和验证 | |
流水线配置管理 | 极狐 GitLab Pipeline Authoring 允许用户使用最小配置创建流水线,如果需要的话,还可以通过有向无环图创建和可视化复杂的流水线。这有助于基础设施工程师最大限度地减少手工工作,并创建可重复的流程,以最大限度地提高生产力 | 流水线配置,流水线配置的类型,有向无环图 |
差异 | 价值 | Proof Point |
---|---|---|
选择基于代理和无代理的方法 | 客户可以根据自己的环境选择正确的方法。使用无代理方法,用户可以让极狐 GitLab 管理和编排 K8s 和非K8s平台的 GitOps 流程,而不必在每个目标基础设施组件上安装和维护代理,从而减少资源消耗和成本节约。使用基于代理的方法,位于防火墙后面的安全基础设施组件的用户可以利用极狐 GitLab代理来保持其安全基础设施的最新状态,从而降低安全漏洞和意外停机的风险。 | TBD |
内部部署和云——物理、虚拟、云原生基础设施 | 极狐 GitLab 满足客户的需求。大多数竞争对手只支持云原生基础设施的 GitOps,而极狐 GitLab支持云部署的 GitOps ——无论是物理服务器、虚拟服务器还是云原生基础设施。您不需要为不同类型的基础设施购买和维护不同的 GitOps 解决方案,从而节省成本,并在整个组织中执行GitOps时获得一致的用户体验。 | TBD |
单个应用程序促进基础设施、开发和运营团队之间的协作 | 极狐 GitLab 是一个单独的应用程序,它包含了 GitOps 的大部分必要成分——版本控制、CI/CD和容器注册表,以及用于配置管理、编排和基础设施配置的开箱即用集成。大多数有竞争力的解决方案需要5-6个集成来实现相同的功能。将所有的 GitOps 整合到极狐 GitLab 中可以节省成本,并提供一致的用户体验和集成功能,有助于提高工作效率,提高环境的稳定性和可靠性 | TBD |
用例的消息屋提供了一个结构来描述和讨论用例的值和区别。
当前消息可以在本页的市场观点部分和回答什么是 GitOps 的主题页中找到?这里还有一些额外的说明:
“基础设施平台”是与 GitOps 和 极狐 GitLab 联系起来使用的一个很好的短语。我们需要小心使用它,这样我们就不会把自己描绘成不是我们自己的样子。在过去,我们曾因为声称拥有类似 Chef、Ansible 和Terraform 的功能而被呼吁,但我们并没有在极狐 GitLab 中包含这些功能,而是寻求与这些工具集成。如果我们清楚地表明,我们通过集成提供基础设施平台功能,那么我们就可以与 I&O 买家联系起来。请参阅主题页上的示例使用。
异议 | 回应 |
---|---|
我们的环境对 GitOps 来说太复杂了 | 大的变化总是复杂的。但是您可以考虑迭代地做这件事——从您最简单的测试环境开始。极狐 GitLab还拥有强大的专业服务团队,可以帮助您开始GitOps之旅。 |
GitOps 为开发人员提供了更多的访问权限来摆弄部署,而基础设施团队对此并不满意 | GitOps 允许开发人员与基础架构团队协同工作。带有 极狐 GitLab 的 GitOps 通过合并请求批准、审计报告、合规性仪表板提供了足够的控制,您的基础设施团队可以使用这些仪表板来确保他们能够监控进入生产的内容。 |
(基础设施/开发运维工程师)我将放松对工作和环境的控制 | GitOps 允许开发人员与基础架构团队协同工作。带有 极狐 GitLab 的 GitOps 通过合并请求批准、审计报告、合规性仪表板提供了足够的控制,您的基础设施团队可以使用这些仪表板来确保他们能够监控进入生产的内容。 |
我不使用 Kubernetes,所以 GitOps 与我无关 | GitOps 和 极狐 GitLab将满足您的需求-我们支持部署到物理、虚拟和云原生环境-无论是在本地还是在云上。 |
我不喜欢基于推送/无代理的方法,这种方法要求我打开防火墙或给予极狐 GitLab CI/CD的集群访问权。 | 我们最近发布了一款用于 Kubernetes 的 极狐 GitLab 代理,它将允许 Kubernetes 集群和 极狐 GitLab CI/CD之间使用基于代理的方法进行安全通信。这将不需要客户打开他们的防火墙或提供对 极狐 GitLab CI/CD的集群访问。我们目前支持这两种选项,您可以选择最适合您特定需求的方法。 |
ArgoCD 是 Kubernetes 的 GitOps部署的开源解决方案。它由Intuit发起,现在是 CNCF 孵化项目。它是阿尔戈项目系列产品的一部分。
ArgoCD 直接与 极狐 GitLab 代理竞争 Kubernetes。
ArgoCD 与 极狐 GitLab 合作。它可以补充 极狐 GitLab CI/CD 中运行的构建和安全步骤。
差异 | 竞争对手是怎么做的 | 极狐 GitLab有何不同 |
---|---|---|
实现 GitOps 的多种产品 | ArgoCD 专门关注部署部分。还有其他 Argo 项目用于特性标志和高级部署策略支持。 | 极狐 GitLab 在一个平台中集成了所有所需的工具 |
多个部署目标 | 只关注云原生部署 | 可以部署到本地部署和云,物理设备,虚拟,云原生基础设施 |
基于推拉的自动化部署 | ArgoCD 监视新的映像,并根据客户选择的策略更新K8S集群中的服务。不支持基于推送的部署。 | 极狐 GitLab Agent for Kubernetes 监视新的 K8S 清单,并相应地更新K8S集群。 |
使用GitOps原则来安装和管理自我 | ArgoCD 可以自我引导 | 极狐 GitLab 代理可以设置为管理自身 |
回滚部署时同步状态 | 由于回滚是一个新的 git 提交或恢复,这是设计好的 | 由于回滚是一个新的 git 提交或恢复,这是在使用极狐 GitLab 代理时设计的 |
Flux 是 Kubernetes 持续和渐进交付的开源解决方案。Flux 创办于 weeworks,现在是 CNCF 的一个孵化项目。它是用于 GitOps 的 weeworks 云解决方案的一部分。
Weaveworks 云解决方案还与 极狐 GitLab 合作—— 极狐 GitLab SCM 和 CI 与 Flux CD 合作创建 GitOps 解决方案。
差异 | 竞争对手是怎么做的 | 极狐 GitLab有何不同 |
---|---|---|
实现 GitOps的多种产品 | Weaveworks 的工具链是版本控制的 GitHub, CI的 CircleCI, Quay。io 用于容器注册,Weave Flux 用于 CD,以及其他用于配置管理、基础设施供应和容器编排的工具。客户也可以选择他们所选择的任何其他 Git、CI 和容器注册表 | 客户需要管理的工具至少减少了 3 个。版本控制、CI/CD 和容器注册由 极狐 GitLab 提供,同时我们与其他工具集成用于配置管理、基础设施供应和容器编排(类似于 Weaveworks)。 |
多个部署目标 | 只关注云原生部署 | 可以部署到内部部署和云,物理设备,虚拟,云原生基础设施 |
基于推拉的自动化部署 | Flux 监视新的映像,并根据客户选择的策略更新 K8S 集群中的服务。不支持基于推送的部署。 | 极狐 GitLab Agent for Kubernetes 监视新的 K8S 清单,并相应地更新 K8S 集群。仅在 SaaS 的自部署和邀请上可用。目前支持基于推送的部署,不需要代理。路线图包括基于推送的部署支持以及使用代理。 |
使用 GitOps 原则来安装和管理自我 | Flux v2 可以创建一个 git 回购,使用 GitOps 原则管理通量清单和更新 | TBD? |
回滚部署时同步状态 | TBD? | TBD? |
对于当前了解极狐 GitLab 在此用例中的功能的分析师列表,请通过 Slack (# Analyst- Relations) 联系分析师关系,或提交问题并选择 “AR-Analyst-Validation” 模板。
此表显示了推荐采用的用例、到产品文档的链接、用例各自的订阅层以及产品分析指标。
功能/用例 | 社区版 | 专业版 | 旗舰版 | 产品分析 | Notes |
---|---|---|---|---|---|
尝试 Kubernetes 的极狐 GitLab 代理 | ✓ | ✓ | ✓ | counts.kubernetes_agents_with_token | |
从自定义 CI 解决方案迁移 | ✓ | ✓ | ✓ | counts.kubernetes_agent_gitops_sync | |
使用基于推送的部署 | ⤬ | ✓ | ✓ | counts.kubernetes_agents_with_token | |
CI连接的高级权限管理 | ⤬ | ✓ | ✓ | counts.kubernetes_agent_gitops_sync |
极狐 GitLab 不是现有基础设施自动化工具的替代品,而是对它们的补充,以提供全面的解决方案。根据JetBrains DevOps 生态系统2019年的调查,Terraform 是客户使用的最流行的基础设施配置工具。Terraform 与云无关,可以帮助管理分布式应用程序的复杂基础设施。极狐 GitLab 将专注于对 Terraform 的支持,这是构建一个全面的 GitOps 解决方案的第一步。