云原生架构与 GitOps 实战
王炜
前腾讯云 CODING 架构师
5442 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
云原生架构与 GitOps 实战
15
15
1.0x
00:00/00:00
登录|注册

27|开发互不干扰,如何实现自动多环境管理?

你好,我是王炜。
从这节课开始,我们开始学习 GitOps 的多环境管理和安全方面的内容。
聊起多环境,你可能会立即想到下面几个常见的环境:
开发环境
测试环境
预发布环境
生产环境
为了让不同职责的人员在不同的环境下独立工作,我们一般会将不同环境隔离。通常,开发环境主要用于开发人员的日常开发,测试环境则是为测试团队而准备的,预发布是正式发布到生产环境之前的最后一道防线,除了数据以外,应该尽量和生产环境保持一致。
当然,对有些团队来说,他们可能还希望开发人员之间相互隔离,也就是为每一个开发者分配一个独立的开发环境,使他们互不干扰。
在非云原生技术架构体系下,环境一般是由特定的团队人工维护的。所以,要想得到一个新的环境,由于文档和技术方面的原因,过程并不简单。但是,在云原生的业务架构体系下,应用是通过标准的 Kubernetes 对象被“定义”出来的。所以,在这种情况下,得到一个新的环境就变得非常容易了。
在之前介绍的 GitOps 工作流中,我们都是以部署单个环境作为例子的。那么,如果我希望为同一个应用创建新的环境,甚至是为不同的开发者创建隔离的开发环境,怎么做才最合适呢?除了手动创建重复的 ArgoCD 应用,还有没有更好的技术方案?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《云原生架构与 GitOps 实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • 邵涵
    思考题,将一套应用定义部署在多个集群中,ApplicationSet定义示例 apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: echo-server spec: generators: - list: elements: - cluster: production url: https://47.91.XX.XX:6443 - cluster: staging url: https://47.111.XX.XX:6443 template: metadata: name: '{{cluster}}-echo-server' spec: project: default source: repoURL: https://code.aliyun.com/shuwei.hsw/echo-server.git targetRevision: main path: manifests/directory/{{cluster}} destination: server: '{{url}}' namespace: multi-echo-server

    作者回复: 👍🏻正确,看来已经掌握了 list gennerators 类型了,赞!

    归属地:北京
    2
  • 邵涵
    几个问题: 1. applicationset.yaml 中可以使用 values.yaml 中定义的变量吗? 2. applicationset.yaml 中定义的 application 模板,是否可以像23讲介绍的那样使用 ArgoCD Image Updater?换句话说,能在发现符合allow-tags过滤条件的新版本的镜像之后,更新工作负载并回写各个环境的values.yaml吗? 3. 如果上边两个问题都是“可以”的话,个人认为应该是可以实现“dev、test、prod环境分别使用从不同的源码分支构建的镜像”这种需求的,但如果上边两个问题是“不可以”的话,要如何实现这个需求呢?为每个环境创建独立的git仓库保存该环境对应的应用定义,进而为每个环境单独创建Application对象,而不使用ApplicationSet?

    作者回复: 非常好的问题。 两个问题都能实现,applicationset 可以为 Deployment 工作负载定义 Annotations 字段,你只需要把 Image updater 相关的字段定义好就能满足。

    归属地:北京
    1
  • 这种方式感觉比较适合独立开发测试的服务,如果有比较多关联的上下游服务的话,感觉就会直接拉起一套很庞大的环境,这种情况是不是就不适合这么搞了。

    作者回复: 几十个微服务其实也还好,结合合理的 resource request 和 limit 可以实现资源超卖。不过对于大型的服务来说,共用一套基础服务的方式也是一个不错的方案。

    归属地:北京
  • po
    首先,「不用分支」会使我们面临差异和合并的问题,这对长期维护来说成本较高,并且在更新环境时,需要切换到不同的分支去操作,这更容易导致人为的错误。其次,分支的管理方式没有目录管理方式来得直观。 ============================== 看上下文内容,这里应该是 不用分支 --> 用分支?

    作者回复: 是的,感谢指正。

    归属地:上海
  • 橙汁
    有种实际场景借助applicationset在不同集群中创建了各自的环境,接下来想进行镜像更新想到两种实现方案。 1. 借助images updater插件,根据23章内容来看是修改application资源,当前application是自动创建不确定修改后是否会有问题。 2. 将打包成功后镜像的tag更新到helm仓库中,也就是value.yaml文件。假设代码和部署是两个仓库,就需要在ci最后阶段更新helm仓库的value.yaml。 希望老师能指正下思路是否正确。

    作者回复: 第二种方案是可行的。 第一种方案值得实践一下。

    归属地:北京
    2
  • ghostwritten
    总结: Git & k8s & argocd & ApplationSet 1.安装 kind 2. 安装argo 3. 安装 ingress 4. 下载 kubernetes-example 5. 明确helm-env名录 6. 定义 template 的ingress.yaml、fronted.yaml变量,例如:命名空间、镜像名称版本 7. 重点理解applationset.yaml的参数定义 扩展:https://argo-cd.readthedocs.io/en/stable/ Argocd ApplationSet有以下Generator: - List Generator (实现多集群) - Cluster Generator - Git Generator - Matrix generator 玩法多多 问题: ArgoCD + ApplationSet VS ArgoCD +kustomize 多环境(多集群多空间)谁更出色?
    归属地:北京
    1
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部