初次使用

本文旨在通过软件研发全生命周期的案例演示,帮助您了解 Erda 平台的基本使用流程,带您快速上手。

预备知识

  1. 了解容器的运行机制和使用方法

    Erda 是一站式云原生 PaaS 平台,其运行核心便是容器。掌握容器的运行机制和使用方法,可以帮助您更好地了解平台设计及操作。

  2. 熟知 Java 的基本概念,例如 Maven 构建、基于 Java 的微服务部署形式等

    下文将以 Java 程序作为案例,了解 Java 的基本概念将有助于您快速上手。

  3. 本文将以如下两则微服务代码作为案例,请提前获取便于后续使用。

安装配置

Erda 提供多种快速安装的方式:

您也可以选择 erda.cloud,注册个人账号后即可使用。

准备环境

tip 提示 若您已加入项目,可跳过本章节。

加入组织

  • 若您使用的是自建 Erda 平台,请登录 Admin 账号,根据界面提示创建组织。

    初次使用 - 图1

    tip 提示 若无 Admin 账号,请联系平台管理员处理。

  • 若您使用的是 erda.cloud,作为新用户,您可以登录个人账号自行创建组织。

    初次使用 - 图2

    您也可以选择浏览公开组织,查看具体项目信息。

加入项目

tip 提示 创建项目需由组织管理员操作。请确认您的账号拥有组织管理员权限,或联系组织管理员处理。

请进入 管理中心 > 项目列表 > 添加项目,进行项目创建。

初次使用 - 图3

tip 提示 若您没有可选集群,请参见 集群管理 完成集群添加。

加入项目后,您的操作将主要涉及以下两大功能:

  • DevOps
    • 协同
    • 代码托管
    • CI/CD
    • API 管理
    • 测试(包括手动测试和自动化测试)
  • 微服务治理
    • 应用监控
    • API 网关
    • 注册中心&配置中心

下文案例将进行全流程演示,并覆盖多数功能。为保证操作顺利,请再次确认您的项目已配置集群资源,且资源充足(大约需要 2 核 CPU 和 8 GB 内存),具体设置方式请参见 集群管理

软件研发全生命周期案例

通常情况下,一个软件研发项目的实现包含以下五个阶段,对应 Erda 功能罗列如下:

  1. 需求分析:协同
  2. 架构设计:API 管理
  3. 研发实现:代码托管 + CI/CD
  4. 质量保障:自动化测试 + 应用监控(微服务治理)
  5. 长期运营:微服务治理

下文将按照以上软件研发全生命周期过程,结合一个虚拟的客户案例(一个高可用的博客网站)展开演示:

  1. 需求分析:协同,包括需求的收集、跟进及落地
  2. 研发实现:代码托管 + CI/CD,包括软件构建、部署及管理
  3. 质量保障:自动化测试 + 应用监控(微服务治理)

需求分析

软件研发是一项多人分工、协作的经营活动。当团队人数增长至一定规模时,口头协作已无法满足工作需求,此时便需要借助系统或工具来解决问题。

若您是一位个人开发者,同样建议您阅读本章节内容。协同工具不仅能够解决团队扩充带来的沟通问题,还能够帮助开发者有效记录和管理个人的工作。

针对该案例,您需要完成以下操作:

  1. 分析和抽象客户需求,进入 DevOps 平台 > 项目协同 > 需求 > 新建需求,将需求录入协同。

    初次使用 - 图4

    通常情况下,产品经理(PD)会将该需求内容补充完整,包括详细的需要描述、验收标准等。

  2. 需求最初列于 待规划 中,迭代开始前将通过评审确定是否放入 迭代 进行开发。

    初次使用 - 图5

    本案例假设该需求已通过评审,纳入 1.0 迭代开发。

    初次使用 - 图6

  3. 团队领导(TL)组织团队进行架构设计和任务拆解,拆解的任务即需求的关联事项,可通过需求跟踪进展。

    初次使用 - 图7

    任务、缺陷中的 关联合并请求 能够将研发和协同更紧密地结合起来,具体请参见 事项关联

    初次使用 - 图8

    项目管理者还可以通过效能度量分析协同的效率和瓶颈。

    初次使用 - 图9

研发实现

tip 提示 本案例中涉及的软件架构设计无法作为真实研发活动的指导,仅供快速入门参考。

在本案例中,假设 TL 已完成架构设计如下:

  1. 设计两个微服务 Service 和 Web,通过 Dubbo 协议通信,使用 Zookeeper 或其他兼容的注册中心(例如 Nacos)。
  2. Service 启用两个实例以保证可靠性。
  3. 使用 MySQL 业务数据存储,Redis 用于存放 Session 和缓存。

针对该设计,您需要完成以下操作:

  1. 进入 DevOps 平台 > 应用中心 > 应用 > 新建应用, 创建两个应用。关于应用的更多信息,请参见 应用管理

    初次使用 - 图10

  2. 完成代码推送后,创建 pipeline.yml。pipeline.yml 是用于描述 CI/CD 自动化过程的文件,具体请参见 pipeline.yml

    • 首先完成 CI 部分:

      1. version: "1.1"
      2. stages:
      3. - stage:
      4. - git-checkout:
      5. - stage:
      6. - buildpack:
      7. alias: blog-server
      8. params:
      9. context: ${git-checkout}
      10. modules:
      11. - name: service
      12. path: service
      13. - buildpack:
      14. alias: blog-web
      15. params:
      16. context: ${git-checkout}
      17. modules:
      18. - name: web
      19. path: web

      将此文件提交代码,随后即可以在界面上进行构建。

      1. git add pipeline.yml
      2. git commit -m 'add pipeline'
      3. git push

      初次使用 - 图11

      您也可以通过 UI 界面直接操作,省去本地推送步骤。

      初次使用 - 图12

    • 完成 CD 部分:

      1. version: "1.1"
      2. stages:
      3. - stage:
      4. - git-checkout:
      5. - stage:
      6. - buildpack:
      7. alias: blog-server
      8. params:
      9. context: ${git-checkout}
      10. modules:
      11. - name: service
      12. path: service
      13. - buildpack:
      14. alias: blog-web
      15. params:
      16. context: ${git-checkout}
      17. modules:
      18. - name: web
      19. path: web
      20. - stage:
      21. - release:
      22. params:
      23. dice_yml: ${git-checkout}/dice.yml
      24. image:
      25. service: ${buildpack:OUTPUT:image-service}
      26. web: ${buildpack:OUTPUT:image-web}
      27. - stage:
      28. - deploy:
      29. params:
      30. release_id: ${release:OUTPUT:releaseID}

      由上可见新增了 release 和 deploy 两个步骤,并且出现了新文件 dice.yml。关于 dice.yml 更多信息,请参见 dice.yml

      将文件补充完整后提交代码。

      1. services:
      2. web:
      3. ports:
      4. - 8095
      5. deployments:
      6. replicas: 1
      7. resources:
      8. cpu: 0.5
      9. mem: 512
      10. disk: 0
      11. expose:
      12. - 8095
      13. service:
      14. deployments:
      15. replicas: 1
      16. resources:
      17. cpu: 0.5
      18. mem: 512
      19. disk: 0
      20. ports:
      21. - 20880
      22. expose:
      23. - 20880
      24. addons:
      25. mysql:
      26. plan: "mysql:basic"
      27. options:
      28. version: "5.7.23"
      29. redis:
      30. plan: "redis:basic"
      31. options:
      32. version: "3.2.12"

      dice.yml 最终需通过 Docker 镜像部署,但上文的 dice.yml 并未填写镜像。

      通过 pipeline.yml 示例可以发现,镜像是在 CI 过程中编译而成的:通过 Buildpack 将代码编译打包为 Docker 镜像,经 Release 将镜像自动塞入 dice.yml,并基于生成后的 dice.yml 完成部署。

  3. 待流水线执行完成后,即可在部署中心查看已发布的实例。运维管理相关的操作(例如重启、回滚、查看日志等),请参见 应用管理

质量保障

质量保障涉及研发过程中的所有环节,例如前期的代码审查,集成时的自动化测试、人工探索和回归测试等。本文将以自动化测试为例展开介绍,更多测试相关内容,请参见 质量保障和测试

在本案例中,假设已完成功能设计如下:

  1. 文章列表
  2. 点击文章查看详情
  3. 用户每点击进入一次,阅读量加一

针对该设计,您需要完成以下操作:

  1. 进入 DevOps 平台 > 测试管理 > 自动化测试,创建场景目录 文章

    初次使用 - 图13

  2. 创建单个场景 文章阅读数

    初次使用 - 图14

  3. 在场景中添加步骤进行场景编排,所添加的每个步骤为具体的接口调用,通过配置接口参数以及断言推进自动化的实现。

    初次使用 - 图15

软件上线后,可通过全链路追踪、日志分析、告警等功能及时发现问题或故障,并辅助定位原因。具体请参见 微服务治理场景示例,本文仅针对主要功能以及使用场景进行简单的阐述和引导。

进入微服务治理平台,即可查看整个项目的全局拓扑。

初次使用 - 图16

tip 提示

您可通过以下方式进入微服务治理页面:

  1. 在左侧菜单栏选择 微服务治理平台,随后搜索项目进入。
  2. 在应用部署详情中点击 应用监控 插件进入。

全局拓扑可作为项目上线后日常运维工作的入口。通过拓扑图能够清晰查看项目内部的流量走向及负载情况,点击红色的错误率即可快速跳转至链路追踪列表,迅速定位问题。

初次使用 - 图17

通过错误分析可快速明确堆栈异常,并向上追溯至错误的来源。

初次使用 - 图18

每个节点即代表一个微服务,点击节点了解该微服务详情,通过详细分析可进一步查看该微服务的具体数据。

初次使用 - 图19